Redigera

Dela via

Använda Azure Synapse Analytics för att utforma en ENTERPRISE BI-lösning

Power BI
Azure Synapse Analytics
Azure Data Factory
Microsoft Entra ID
Azure Blob Storage

Den här artikeln beskriver hur du överför data från ett lokalt informationslager till en molnmiljö och sedan använder en BI-modell (Business Intelligence) för att hantera data. Du kan använda den här metoden som ett slutmål eller ett första steg mot fullständig modernisering med molnbaserade komponenter.

Den här vägledningen bygger på scenariot Azure Synapse Analytics från slutpunkt till slutpunkt. Den här processen använder Azure Synapse Analytics-pipelines för att mata in data från en SQL-databas i SQL-pooler. Sedan utför den datatransformering för analys. Den här artikeln fokuserar på Azure Synapse Analytics-pipelines, men du kan också använda Azure Data Factory-pipelines eller Fabric Data Factory-pipelines för att utföra dessa uppgifter.

När du ska använda den här arkitekturen

Du kan använda olika metoder för att uppfylla affärskraven för enterprise BI. Olika aspekter definierar affärskrav, till exempel aktuella teknikinvesteringar, mänskliga färdigheter, tidslinjen för modernisering, framtida mål och om du föredrar plattform som en tjänst (PaaS) eller programvara som en tjänst (SaaS).

Överväg följande designmetoder:

Arkitekturen i den här artikeln förutsätter att du använder Azure Synapse Analytics-informationslagret som det beständiga lagret i företagets semantiska modell och att du använder Power BI för business intelligence. Den här PaaS-metoden har flexibiliteten att hantera olika affärskrav och inställningar.

Arkitektur

diagram som visar företags-BI-arkitekturen med Azure Synapse Analytics.

Ladda ned en Visio-fil med den här arkitekturen.

Arbetsflöde

Data source

Inmatning och datalagring

Analys och rapportering

Komponenter

I det här scenariot används följande komponenter:

  • Azure SQL Database är en Azure-värdbaserad PaaS SQL-server. Den här arkitekturen använder SQL Database för att demonstrera dataflödet för migreringsscenariot.

  • Data Lake Storage tillhandahåller flexibel molnlagring för ostrukturerade data som används för att bevara mellanliggande migreringsresultat.

  • Azure Synapse Analytics är en företagsanalystjänst för datalagerhantering och stordatasystem. Azure Synapse Analytics fungerar som huvudberäkning och beständig lagring i företagets semantiska modellering och service.

  • Power BI Premium är ett BI-verktyg som presenterar och visualiserar data i det här scenariot.

  • Microsoft Entra ID är en paket för identiteter och nätverkslösningar med flera moln som stöder autentiserings- och auktoriseringsflödet.

Förenklad arkitektur

diagram som visar den förenklade arkitekturen för enterprise BI.

Information om scenario

I det här scenariot har en organisation en SQL-databas som innehåller ett stort lokalt informationslager. Organisationen vill använda Azure Synapse Analytics för att utföra analys och sedan leverera dessa insikter via Power BI till användare och analys.

Autentisering

Microsoft Entra ID autentiserar användare som ansluter till Power BI-instrumentpaneler och appar. Enkel inloggning ansluter användare till datakällan i en etablerad Azure Synapse Analytics-pool. Auktorisering sker på källan.

Inkrementell inläsning

När du kör en automatiserad process för extrahering, transformering, inläsning (ETL) eller extrahering, inläsning, transformering (ELT) bör du bara läsa in de data som har ändrats sedan föregående körning. Den här processen kallas för en inkrementell belastning. Omvänt läser en fullständig belastning in alla data. Om du vill utföra en inkrementell belastning ska du bestämma hur du ska identifiera ändrade data. Du kan använda metoden högvattenmärke värde, som spårar det senaste värdet för en datum-tid-kolumn eller en unik heltalskolumn i källtabellen.

Du kan använda temporala tabeller i SQL Server. Temporala tabeller är systemversionstabeller som lagrar dataändringshistorik. Databasmotorn registrerar automatiskt historiken för varje ändring i en separat historiktabell. Om du vill köra frågor mot historiska data kan du lägga till en FOR SYSTEM_TIME-sats i en fråga. Internt frågar databasmotorn historiktabellen, men den är transparent för programmet.

Temporala tabeller stöder dimensionsdata, som kan ändras över tid. Faktatabeller representerar vanligtvis en oföränderlig transaktion, till exempel en försäljning, i vilket fall det inte är meningsfullt att behålla systemversionshistoriken. I stället har transaktioner vanligtvis en kolumn som representerar transaktionsdatumet. Kolumnen kan användas som vattenstämpelvärde. I adventureworks-informationslagret har till exempel de SalesLT.* tabellerna ett LastModified fält.

Här är det allmänna flödet för ELT-pipelinen:

  1. För varje tabell i källdatabasen spårar du tidsgränsen när det senaste ELT-jobbet kördes. Lagra den här informationen i informationslagret. Vid den första installationen är alla tider inställda på 1-1-1900.

  2. Under dataexportsteget skickas tidsgränsen som en parameter till en uppsättning lagrade procedurer i källdatabasen. Dessa lagrade procedurer kör frågor mot alla poster som ändras eller skapas efter bryttiden. För alla tabeller i exemplet kan du använda ModifiedDate kolumnen.

  3. När datamigreringen är klar uppdaterar du tabellen som lagrar bryttiderna.

Datapipeline

I det här scenariot används AdventureWorks-exempeldatabasen som datakälla. Mönstret för inkrementell datainläsning säkerställer att endast data som har ändrats eller lagts till efter den senaste pipelinekörningen har lästs in.

Verktyg för metadatadriven kopiering

Det inbyggda metadatadrivna kopieringsverktyget i Azure Synapse Analytics-pipelines läser in alla tabeller som finns i relationsdatabasen stegvis.

  1. Använd ett guidegränssnitt för att ansluta verktyget Kopiera data till källdatabasen.

  2. När den har anslutit konfigurerar du inkrementell inläsning eller fullständig inläsning för varje tabell.

  3. Verktyget Kopiera data skapar de pipelines och SQL-skript som behövs för att generera kontrolltabellen. Den här tabellen lagrar data, till exempel värdet för högvattenstämpel eller kolumn för varje tabell, för den inkrementella inläsningsprocessen.

  4. När skripten har körts läser pipelinen in alla källdatalagertabeller i den dedikerade Azure Synapse Analytics-poolen.

Skärmbild som visar det metadatadrivna verktyget Kopiera data i Azure Synapse Analytics.

Innan verktyget läser in data skapas tre pipelines som itererar över tabellerna i databasen.

Pipelines utför följande uppgifter:

  • Räkna antalet objekt, till exempel tabeller, som ska kopieras i pipelinekörningen.

  • Iterera över varje objekt som ska läsas in eller kopieras.

  • När en pipeline itererar över varje objekt utför den följande uppgifter:

    • Kontrollerar om en deltainläsning krävs. Annars slutför pipelinen en normal full belastning.

    • Hämtar värdet för högvattenstämpel från kontrolltabellen.

    • Kopierar data från källtabellerna till mellanlagringskontot i Data Lake Storage.

    • Läser in data i den dedikerade SQL-poolen via den valda kopieringsmetoden, till exempel polybase- eller kopieringskommandot.

    • Uppdaterar värdet för högvattenstämpel i kontrolltabellen.

Läsa in data i en Azure Synapse Analytics SQL-pool

Den kopieringsaktiviteten kopierar data från SQL-databasen till Azure Synapse Analytics SQL-poolen. Det här exemplets SQL-databas finns i Azure, så den använder Azure Integration Runtime för att läsa data från SQL-databasen och skriva data till den angivna mellanlagringsmiljön.

Kopieringssatsen läser sedan in data från mellanlagringsmiljön till den dedikerade Azure Synapse Analytics-poolen.

Använda Azure Synapse Analytics-pipelines

Pipelines i Azure Synapse Analytics definierar en ordnad uppsättning aktiviteter för att slutföra ett inkrementellt belastningsmönster. Manuella eller automatiska utlösare startar pipelinen.

Omvandla data

Exempeldatabasen i den här referensarkitekturen är liten, så replikerade tabeller som inte har några partitioner skapas. För produktionsarbetsbelastningar kan distribuerade tabeller förbättra frågeprestanda. Mer information finns i Vägledning för att utforma distribuerade tabeller i Azure Synapse Analytics. Exempelskripten kör frågorna via en statisk resursklass.

I en produktionsmiljö bör du överväga att skapa mellanlagringstabeller som har resursallokeringsdistribution. Transformera och flytta sedan data till produktionstabeller som har grupperade kolumnlagringsindex, vilket ger bästa övergripande frågeprestanda. Kolumnlagringsindex är optimerade för frågor som söker igenom många poster.

Kolumnlagringsindex fungerar inte optimalt för singleton-sökningar eller letar upp en enda rad. Om du behöver utföra frekventa singleton-sökningar kan du lägga till ett icke-grupperat index i en tabell, vilket ökar hastigheten. Singleton-sökningar är dock vanligtvis mindre vanliga i informationslagerscenarier än arbetsbelastningar för transaktionsbearbetning online. Mer information finns i Index-tabeller i Azure Synapse Analytics.

Kommentar

Grupperade kolumnlagringstabeller stöder varchar(max)inte , nvarchar(max)eller varbinary(max) datatyper. Om du använder dessa datatyper bör du överväga ett heap- eller klustrat index. Du kan också överväga att placera dessa kolumner i en separat tabell.

Använda Power BI Premium för att komma åt, modellera och visualisera data

Power BI Premium har stöd för flera alternativ för att ansluta till datakällor i Azure. Du kan använda Azure Synapse Analytics-etablerade pooler för att utföra följande uppgifter:

  • Import: Data importeras till Power BI-modellen.
  • DirectQuery: Data hämtas direkt från relationslagring.
  • Sammansatt modell: Kombinera Import för vissa tabeller och DirectQuery för andra.

Det här scenariot använder DirectQuery-instrumentpanelen eftersom den har en liten mängd data och låg modellkomplexitet. DirectQuery delegerar frågan till den kraftfulla beräkningsmotorn under och använder omfattande säkerhetsfunktioner på källan. DirectQuery ser till att resultaten alltid överensstämmer med de senaste källdata.

Importläget ger den snabbaste svarstiden för frågor. Överväg importläge om:

  • Modellen passar helt i minnet av Power BI.
  • Datafördröjningen mellan uppdateringar är acceptabel.
  • Du behöver komplexa transformeringar mellan källsystemet och den slutliga modellen.

I det här fallet vill slutanvändarna ha fullständig åtkomst till de senaste data utan fördröjningar i Power BI-uppdatering, och de vill ha alla historiska data, vilket överskrider Power BI-datamängdskapaciteten. En Power BI-datauppsättning kan hantera 25–400 GB, beroende på kapacitetsstorleken. Datamodellen i den dedikerade SQL-poolen finns redan i ett star-schema och kräver inte transformering, så DirectQuery är ett lämpligt val.

Skärmbild som visar instrumentpanelen i Power BI.

Använd Power BI Premium- för att hantera stora modeller, sidnumrerade rapporter och distributionspipelines. Dra nytta av den inbyggda Azure Analysis Services-slutpunkten. Du kan också ha dedikerad kapacitet med unika värdeförslag.

När BI-modellen växer eller instrumentpanelens komplexitet ökar kan du växla till sammansatta modeller och importera delar av uppslagstabeller via hybridtabelleroch importera föraggregerade data. Du kan aktivera cachelagring av frågor i Power BI för importerade datauppsättningar och använda dubbla tabeller för egenskapen lagringsläge.

Inom den sammansatta modellen fungerar datauppsättningar som ett virtuellt direktlager. När användare interagerar med visualiseringar genererar Power BI SQL-frågor till Azure Synapse Analytics SQL-pooler. Power BI avgör om du vill använda minnesintern lagring eller DirectQuery-lagring baserat på effektivitet. Motorn bestämmer när du ska växla från minnesintern till DirectQuery och skickar logiken till Azure Synapse Analytics SQL-poolen. Beroende på kontexten för frågetabellerna kan de fungera som cachelagrade (importerade) eller icke-cachelagrade sammansatta modeller. Du kan välja vilken tabell som ska cachelagrats i minnet, kombinera data från en eller flera DirectQuery-källor eller kombinera DirectQuery-källdata och importerade data.

När du använder DirectQuery med en etablerad Azure Synapse Analytics-pool:

  • Använd Azure Synapse Analytics cachelagring av resultatuppsättningar för att cachelagra frågeresultat i användardatabasen för upprepad användning. Den här metoden förbättrar frågeprestandan till millisekunder och minskar användningen av beräkningsresurser. Frågor som använder cachelagrade resultatuppsättningar förbrukar inga samtidighetsfack i Azure Synapse Analytics, så de räknas inte mot befintliga samtidighetsgränser.

  • Använd Azure Synapse Analytics materialiserade vyer för att förberäkna, lagra och underhålla data som en tabell. Frågor som använder alla data eller en delmängd av data i materialiserade vyer kan uppnå snabbare prestanda utan att behöva referera direkt till den definierade materialiserade vyn för att använda den.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som du kan använda för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Well-Architected Framework.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i checklistan för Designgranskning för Security.

Molnmodernisering introducerar säkerhetsproblem, till exempel dataintrång, skadlig kodinfektion och skadlig kodinmatning. Du behöver en molnleverantör eller tjänstlösning som kan åtgärda dina problem eftersom otillräckliga säkerhetsåtgärder kan skapa stora problem.

Det här scenariot åtgärdar de mest krävande säkerhetsproblemen med hjälp av en kombination av säkerhetskontroller i flera lager: kontroller för nätverk, identitet, sekretess och auktorisering. En Azure Synapse Analytics-etablerad pool lagrar de flesta data. Power BI kommer åt data via DirectQuery via enkel inloggning. Du kan använda Microsoft Entra-ID för autentisering. Det finns också omfattande säkerhetskontroller för dataauktorisering i de etablerade poolerna.

Några vanliga säkerhetsfrågor är:

  • Definiera vem som kan se vilka data.

    • Se till att dina data följer federala, lokala riktlinjer och företagets riktlinjer för att minska risken för dataintrång. Azure Synapse Analytics tillhandahåller flera dataskyddsfunktioner för att uppnå efterlevnad.

  • Fastställa hur en användares identitet ska verifieras.

  • Välj en nätverkssäkerhetsteknik för att skydda integriteten, konfidentialiteten och åtkomsten för dina nätverk och data.

  • Välj verktyg för att identifiera och meddela dig om hot.

    • Använd Azure Synapse Analytics hotidentifiering funktioner, till exempel SQL-granskning, IDENTIFIERING av SQL-hot och sårbarhetsbedömning för att granska, skydda och övervaka databaser.

  • Fastställ hur du skyddar data i ditt lagringskonto.

    • Använd Azure Storage-konton för arbetsbelastningar som kräver snabba och konsekventa svarstider eller som har ett stort antal in- och utdataåtgärder per sekund. Lagringskonton kan lagra alla dina dataobjekt och har flera säkerhetsalternativ för lagringskonto.

Kostnadsoptimering

Kostnadsoptimering fokuserar på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i checklistan Designgranskning för kostnadsoptimering.

Det här avsnittet innehåller information om priser för olika tjänster som ingår i den här lösningen och nämner beslut som fattas för det här scenariot med en exempeldatauppsättning. Använd den här startkonfigurationen i priskalkylatorn för Azureoch justera den så att den passar ditt scenario.

Azure Synapse Analytics

Azure Synapse Analytics är en serverlös arkitektur som du kan använda för att skala dina beräknings- och lagringsnivåer oberoende av varandra. Beräkningsresurser medför kostnader baserat på användning. Du kan skala eller pausa dessa resurser på begäran. Lagringsresurser medför kostnader per terabyte, så dina kostnader ökar när du matar in data.

Azure Synapse Analytics-pipelines

Tre huvudkomponenter påverkar priset på en pipeline:

  • Datapipelineaktiviteter och integrationskörningstimmar
  • Storlek och implementering av dataflöden för kluster
  • Avgifter för åtgärder

Prisinformation finns på fliken dataintegrering på Prissättning för Azure Synapse Analytics.

Priset varierar beroende på komponenter eller aktiviteter, frekvens och antalet integrationskörningsenheter.

För exempeldatauppsättningen, som använder standardmiljön för Azure-värdbaserad integrering, kopieringsdataaktiviteten fungerar som kärnan i pipelinen. Den körs enligt ett dagligt schema för alla entiteter (tabeller) i källdatabasen. Scenariot innehåller inte dataflöden. Och det medför inte driftskostnader eftersom pipelines körs mindre än en miljon åtgärder per månad.

Dedikerad pool och lagring i Azure Synapse Analytics

För exempeldatauppsättningen kan du etablera 500 informationslagerenheter (DWU:er) för att ge en smidig upplevelse för analytiska belastningar. Du kan underhålla beräkning under kontorstid i rapporteringssyfte. Om lösningen flyttas till produktion använder du reserverad informationslagerkapacitet som en kostnadseffektiv strategi. Använd olika tekniker för att maximera kostnads- och prestandamått.

Prisinformation för en dedikerad Azure Synapse Analytics-pool finns på fliken Data Warehousing på Azure Synapse Analytics-prissättning. Under den dedikerade förbrukningsmodellen medför kunderna kostnader för varje etablerad DWU per timmes drifttid. Överväg även kostnader för datalagring, inklusive storleken på dina vilande data, ögonblicksbilder och geo-redundans.

Blobb-lagring

Överväg att använda reserverad Azure Storage-kapacitet för att minska lagringskostnaderna. Med den här modellen får du rabatt om du reserverar fast lagringskapacitet i ett eller tre år. Mer information finns i Optimera kostnader för bloblagring med reserverad kapacitet. Det här scenariot använder inte beständig lagring.

Power BI Premium

I det här scenariot används Power BI Premium-arbetsytor med inbyggda prestandaförbättringar för att tillgodose krävande analysbehov.

Mer information finns i Power BI-priser.

Operativ skicklighet

Operational Excellence omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i checklistan för Designgranskning för Operational Excellence.

  • Använd en Azure DevOps-versionspipeline och GitHub Actions för att automatisera distributionen av en Azure Synapse Analytics-arbetsyta i flera miljöer. Mer information finns i Kontinuerlig integrering och kontinuerlig leverans för en Azure Synapse Analytics-arbetsyta.

  • Placera varje arbetsbelastning i en separat distributionsmall och lagra resurserna i källkontrollsystem. Du kan distribuera mallarna tillsammans eller individuellt som en del av en process för kontinuerlig integrering och kontinuerlig leverans (CI/CD). Den här metoden förenklar automatiseringsprocessen. Den här arkitekturen har fyra huvudarbetsbelastningar:

    • Informationslagerservern och relaterade resurser
    • Azure Synapse Analytics-pipelines
    • Power BI-tillgångar, inklusive instrumentpaneler, appar och datauppsättningar
    • Ett simulerat scenario lokalt till molnet

  • Överväg att mellanlagring av dina arbetsbelastningar där det är praktiskt. Distribuera arbetsbelastningen till olika steg. Kör valideringskontroller i varje steg innan du går vidare till nästa steg. Den här metoden push-överför uppdateringar till dina produktionsmiljöer på ett kontrollerat sätt och minimerar oväntade distributionsproblem. Använd blågrön distribution och strategier för att uppdatera produktionsmiljöer i realtid.

  • Använd en återställningsstrategi för att hantera misslyckade distributioner. Du kan till exempel automatiskt distribuera om en tidigare lyckad distribution från distributionshistoriken. Använd flaggan --rollback-on-error i Azure CLI.

  • Använd Azure Monitor för att analysera prestanda för ditt informationslager och hela Azure Analytics-plattformen för en integrerad övervakningsupplevelse. Azure Synapse Analytics tillhandahåller en övervakningsupplevelse inom Azure Portal för att visa insikter om din arbetsbelastning i informationslagret. Använd Azure-portalen för att övervaka ditt informationslager. Det ger konfigurerbara kvarhållningsperioder, aviseringar, rekommendationer och anpassningsbara diagram och instrumentpaneler för mått och loggar.

Mer information finns i följande resurser:

Prestandaeffektivitet

Prestandaeffektivitet syftar på arbetsbelastningens förmåga att skala för att effektivt uppfylla användarnas krav. Mer information finns i checklistan för Designgranskning för prestandaeffektivitet.

Det här avsnittet innehåller information om storleksbeslut för att hantera den här datamängden.

Azure Synapse Analytics-etablerad pool

Du kan använda olika konfigurationer av informationslager.

DWU:er Antal beräkningsnoder Antal distributioner per nod
DW100c 1 60
-- TO --
DW30000c 60 1

Om du vill se prestandafördelarna med utskalning, särskilt för större DWU:er, använder du minst en datauppsättning på 1 TB. Om du vill hitta det bästa antalet DWU:er för din dedikerade SQL-pool kan du prova att skala upp och ned. Kör frågor som har olika antal DWU:er när du har läst in dina data. Skalning går snabbt, så du kan enkelt experimentera med olika prestandanivåer.

Hitta det bästa antalet DWU:er

För en dedikerad SQL-pool under utveckling väljer du ett litet antal DWU:er som utgångspunkt, till exempel DW400c eller DW200c. Övervaka programmets prestanda för varje antal DWU:er. Anta en linjär skala och bestäm hur mycket du behöver öka eller minska DWU:erna. Fortsätt att göra justeringar tills du når en optimal prestandanivå för dina affärsbehov.

Skala en Azure Synapse Analytics SQL-pool

För skalbarhets- och prestandaoptimeringsfunktioner i pipelines i Azure Synapse Analytics och för kopieringsaktiviteten som du använder, se guiden kopiera aktivitetsprestanda och skalbarhet.

Mer information finns i följande resurser:

Power BI Premium och Fabric

Den här artikeln använder Power BI Premium F64-kapacitet för att demonstrera BI-funktioner. Dedikerade Power BI-kapaciteter i Infrastrukturresurser sträcker sig från F64 (8 virtuella kärnor) till F1024 (128 virtuella kärnor).

Så här avgör du hur mycket kapacitet du behöver:

Deltagare

Microsoft ansvarar för denna artikel. Följande deltagare skrev den här artikeln.

Huvudsakliga författare:

Övriga medarbetare:

Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.

Nästa steg