Arkitektur för moderna informationslagermedaljonger i Microsoft Fabric

Den här exempelarbetesbelastningen beskriver en medaljongarkitektur för ett modernt datalager med SQL i första hand (MDW). Ett modernt informationslager använder SQL-baserade datalager för att organisera strukturerade data för analys och rapportering. Den här arkitekturen implementerar brons-, silver- och guldskikten i Fabric Data Warehouse och använder Fabric Data Factory för att samordna datainmatning och transformering.

Fabric Data Warehouse lagrar relationsdata i Delta-format i OneLake och stöder T-SQL-utveckling via tabeller, vyer, transaktioner och lagrade procedurer. Power BI, SQL-klienter och andra applikationer använder kurerade data från guldlagret.

Architecture

Ladda ned en PowerPoint-fil av den här arkitekturen.

I diagrammet hanterar spegling replikering av driftdata-baser, och Fabric Data Factory-pipelines läser in icke-speglade källor till bronssökvägen.

Dataflöde

Följande dataflöde motsvarar föregående diagram:

1. Driftdatabaser, SaaS-program, filer och andra källsystem producerar data.

2. Datainmatning för in källdata i Fabric via två vägar. För operativa databaser som stöds replikerar Spegling i Fabric kontinuerligt data till ett speglat databasobjekt i OneLake. Ett CTAS- eller INSERT ... SELECT-steg i lagret sparar sedan datan i bronze-lagret. För filer, SaaS-program och andra icke-speglade källor använder du Fabric Data Factory-pipelines eller T-SQL-lager, till exempel COPY INTO, för att läsa in bronstabeller.

3. brons-lagret lagrar råa, minimalt bearbetade data i tabeller i datalagret. Inmatningsmetadata, till exempel tidsstämplar för inläsning och källidentifierare, stöder granskning och ombearbetning.

4. Det första omvandlingssteget (Bronze to silver) validerar och omvandlar bronsdata till silverskiktet.

5. Silverskiktet innehåller rensade, deduplicerade och överensstämmande data. Om historisk analys krävs behåller silvertabeller källändringar med gällande datum och indikatorer för aktuell rad.

6. Lagrade procedurer eller dbt-jobb implementerar vanligtvis steget Bronze to silver med hjälp av SQL-mönster som CREATE TABLE AS SELECT (CTAS), INSERT ... SELECT och MERGE.

7. Det guldfärgade lagret innehåller förbrukningsklara stjärnscheman, data marts och föraggregerade tabeller.

8. Det andra omvandlingssteget (Silver to gold) omvandlar silverdata till affärsentiteter, dimensioner, fakta och aggregeringar i guldskiktet.

9. Power BI använder gulddata via semantiska modeller. Andra konsumenter, till exempel SQL-klienter, anteckningsböcker och applikationer, kan ställa frågor till informationslagrets SQL-slutpunkt.

Components

• Fabric Data Warehouse innehåller T-SQL-beräknings- och relationstabellerna för skikten brons, silver och guld.
• OneLake lagrar lagerdata i Delta-format och lagrar data som replikeras av Fabric spegling.
• Spegling i Fabric replikerar kontinuerligt operativa databaser som stöds till OneLake.
• Fabric Data Factory matar in data och samordnar lagrade procedurer, pipelines och andra transformeringsaktiviteter.
• Power BI tillhandahåller semantiska modeller, rapporter och instrumentpaneler över utvalda gulddata.

Riktlinjer för design

Följande vägledning beskriver hur du implementerar brons-, silver- och guldskikten och organiserar de stödjande arbetsytorna. Anpassa de här rekommendationerna till arbetsbelastningens datakällor och styrningskrav och teamets kunskaper.

Bronsskikt: Inläsning av rådata

Bronsskiktet matar in rådata och samlar in alla källdata i sin ursprungliga form utan att tillämpa någon affärslogik. Det fungerar som det primära systemet för registrering och möjliggör full spårbarhet och ombehandling. Tabeller i det här lagret speglar noggrant källscheman och undviker avsiktligt filtrering, deduplicering eller berikning. Valfria metadatakolumner, till exempel tidsstämplar för inmatning eller källfilnamn, stöder ofta granskning.

För driftdatabaser som stöds använder du Spegling i Fabric för att kontinuerligt replikera källtabeller till OneLake. För filbaserade källor, SaaS-källor eller källor som inte stöds använder du Fabric Data Factory-pipelines, COPY INTO för massinläsning eller OPENROWSET med CTAS eller INSERT ... SELECT för att lagra externa fildata i bronslagret.

I det här skedet sker datainhämtningen med minimal omformning så att bronslagret förblir det primära källsystemet som kan spelas upp på nytt. Vid behov för icke-speglade källor kan en lagrad procedur med bronsbelastning (eller motsvarande dbt-modell) standardisera inkommande poster och lägga till inläsningsmetadata.

Bästa praxis för bronsskiktet betonar vikten av att bevara alla rådata, inklusive ogiltiga poster, att använda batchinläsning för att undvika problem med små filer, att anpassa scheman så att de ligger nära källsystemens och att automatisera inläsningsarbetsflöden med hjälp av pipelines i Fabric för att säkerställa konsekvens och tillförlitlighet i stor skala.

Silverskikt: Datarensning och överensstämmelse

Silverskiktet fokuserar på datarensning och överensstämmelse genom att förfina bronsdata genom tillämpning av datakvalitetsregler, standardisering, deduplicering och integrering mellan flera källor. Det ger slutligen en enda sanningskälla för rengjorda och tillförlitliga data.

Du implementerar vanligtvis transformeringar i det här skedet med hjälp av T-SQL, med hjälp av mönster som CREATE TABLE AS SELECT (CTAS), INSERT … SELECToch MERGE -instruktioner för både batchbearbetning och inkrementell bearbetning. Även om Fabric Data Warehouse inte stöder materialiserade vyer kan du använda materialiserade sjövyer som implementeras med Hjälp av Spark för att generera Delta-tabeller. SQL-analysslutpunkten exponerar dessa Delta-tabeller som tabeller som lagret kan läsa.

Bästa praxis för silverskiktet omfattar att utforma transformationer så att de är idempotenta, att konsekvent tillämpa regler för datakvalitet och att använda MERGE för inkrementella uppdateringar. När arbetsbelastningen kräver historisering behåller du radversioner med effektiva start- och slutdatum och en indikator för aktuell rad. Gold-dimensioner kan använda den här historiken för att implementera beteende för långsamt föränderliga dimensioner (SCD) av typ 1 eller typ 2.

Guldskikt: Kuraterade data för analys

Guldlagret levererar utvalda, affärsklara data som är optimerade för analys, rapportering och förbrukning av BI-verktyg som Power BI. Det här lagret är utformat för analysmodelleringsmönster, som ofta använder star-scheman med fakta- och dimensionstabeller, domänspecifika data marts och föraggregerade sammanfattningstabeller för att stödja högpresterande frågor och intuitiv analys.

Du härleder vanligtvis guldtabeller uteslutande från silverdata och exponerar dem för slutanvändare och rapporteringsverktyg.

Använd stabila surrogatnycklar för dimensioner så att fakta inte är beroende av föränderliga källsystemnycklar. Fabric Data Warehouse stöder BIGINT IDENTITY kolumner för generering av surrogatnycklar. Identitetsvärden är unika men garanteras inte vara sekventiella eller ordnade, och det kan uppstå luckor. Om dessa begränsningar inte är lämpliga för arbetsbelastningen genererar och bevarar du surrogatnycklar i transformeringslogik och underhåller en varaktig mappning till varje naturlig nyckel. Återskapa inte surrogatnycklar under en fullständig uppdatering.

Bästa praxis för det guldfärgade lagret är modelleringsdata som är nära anpassade till analys- och affärsanvändningsfall, föraggregering av data där det är möjligt för att förbättra prestanda, tillämpa säkerhetskontroller som säkerhet på radnivå (RLS), säkerhet på kolumnnivå (CLS) och datamaskering och noggrant dokumentera data härkomst och transformeringar.

Strategi för arbetsyta

En strategi för arbetsytor definierar hur brons-, silver- och guldskikt är logiskt och fysiskt åtskilda för att balansera styrning, säkerhet och driftsmässig enkelhet. Du kan implementera lager med hjälp av separata arbetsytor per lager, vilket vi rekommenderar när starka säkerhetsgränser, tydligt ägarskap eller strikt ansvarsfördelning krävs. Du bör till exempel isolera rådatainmatning från kurerade affärsdata.

Du kan också implementera lager på en enda arbetsyta med hjälp av separata lager för brons-, silver- och gulddata. Den här metoden kan minska hanteringskostnaderna och förenkla utveckling och testning mellan lager samtidigt som lagernivåseparation mellan medaljongskikt bevaras.

Valet mellan dessa metoder beror vanligtvis på faktorer som organisationsskala, säkerhetskrav, teamstruktur och styrningsmognad. Många företag antar en hybridmodell när deras Fabric implementering utvecklas. Vi rekommenderar att du använder separata arbetsytor när isolering, styrning och ägarskapsgränser krävs.

Riktlinjer för implementering

Fabric Data Warehouse ger transaktionskonsekvens och tillförlitlig databearbetning över brons-, silver- och guldskikten. Använd batchorienterade skrivningar för att minimera små filproblem och förbättra lagrings- och frågeeffektiviteten. Använd MERGE satser för att hantera sent inkomna eller ändrade data vid inkrementell bearbetning.

Håll transaktionerna kortvariga för att minska konkurrensen och optimera samtidigheten, särskilt i miljöer med hög inmatning. Övervaka prestanda och drifthälsa aktivt med hjälp av Fabric frågeinsikter och dynamiska hanteringsvyer (DMV:er). Arkitekturavgränsningen av läs- och skrivarbetsbelastningar i Fabric ytterligare gör det möjligt för inmatnings- och transformeringsjobb att köras samtidigt utan att blockera analytiska frågor, vilket säkerställer förutsägbara prestanda för nedströmsanalys och rapportering.

Använd T-SQL-lagrade procedurer och Fabric Data Factory-pipelines för inbyggd SQL-transformering och orkestrering. De team som föredrar modulära SQL-modeller och tester kan använda dbt-adaptern för Fabric Data Warehouse, som underhålls av Microsoft. Kör tester för unikhet, referensintegritet och godkända värden som distributions- eller pipelinekontroller innan du publicerar data till efterföljande lager.

Alternatives

Den här arkitekturen innehåller flera komponenter som du kan ersätta med andra Azure-tjänster eller -metoder, beroende på arbetsbelastningens funktionella och icke-funktionella krav. Överväg följande alternativ och deras kompromisser.

För scenarier som betonar datateknik i stor skala, avancerad analys, maskininlärning eller ostrukturerade data kan en arkitektur med lakehouse som förstahandsval i Microsoft Fabric passa bättre. I den här metoden fungerar ett Fabric lakehouse som det primära datalagret i OneLake, och transformeringar implementeras främst med hjälp av Spark-baserade verktyg som notebook-filer eller Dataflow Gen2. Det här mönstret innehåller distribuerad beräkning, notebook-filer och maskininlärningsverktyg som inte är i fokus för den här SQL-första lagerarkitekturen.

För organisationer med starkt fokus på datavetenskap, AI eller komplex distribuerad bearbetning är Azure Databricks ett annat alternativ. Azure Databricks väljs vanligtvis när arbetsbelastningar kräver djup integrering med maskininlärningsramverk med öppen källkod, detaljerad kontroll över Spark-körning eller portabilitet för flera moln.

För analys i nära realtid eller händelsedriven kan Fabric Real-Time Intelligence, Azure Event Hubs eller Azure Stream Analytics vara lämpligare än en batchorienterad medaljongdesign centrerad på Fabric Data Warehouse.

Scenarioinformation

Fabric Data Warehouse passar bra för den här medaljongarkitekturen när det primära målet är att leverera styrda, analysklara data i stor skala med hjälp av välbekanta SQL-mönster.

Scenario 1: Relationssemantik och SQL-prestanda för kurerade, analysklara datamängder

Fabric Data Warehouse passar bra eftersom den innehåller relationstabeller och vyer, ACID-transaktioner och T-SQL-åtgärder ovanpå Delta-data. Den här funktionsuppsättningen stöder arbetsbelastningar där data redan rensas och överensstämmer och måste efterfrågas konsekvent via SQL.

Exempel: Ett flygbolag bygger utvalda gulddatauppsättningar för flygverksamhet och intäktsanalys. Analytiker förlitar sig på stabil prestanda för SQL-frågor för att utvärdera trender för punktlighet, linjelönsamhet och besättningsutnyttjande. Med hjälp av lagertabeller och vyer säkerställs transaktionskonsekvens och tillförlitligt frågebeteende, vilket är svårare att garantera med ad hoc-filbaserad åtkomst.

Scenario 2: Centraliserad styrning med en SQL-första upplevelse

Fabric Data Warehouse möjliggör centraliserad styrning via arbetsytebehörigheter, säkerhet på objektnivå och inbyggd härkomst, samtidigt som data exponeras via ett SQL-gränssnitt som är bekant för analystekniker. Den här metoden minskar driftsfriktionen, förenklar åtkomstkontrollen och påskyndar implementeringen mellan team utan att införa nya åtkomstparadigm.

Exempel: Ett globalt företag tillämpar strikt ansvarsfördelning: plattformsteam hanterar inmatning och omvandlingar, och analysteam använder endast kurerade data. Genom att endast exponera tabeller i guldskikt via ett lager och styra åtkomsten centralt undviker organisationen okontrollerad åtkomst till rådata eller mellanliggande data samtidigt som ett välbekant SQL-baserat arbetsflöde upprätthålls.

Scenario 3: BI-optimerad förbrukning för rapportering och instrumentpaneler

Datalagret är optimerat för hög grad av samtidighet och läsintensiva arbetsbelastningar, vilket gör det till ett bra val när ett stort antal verksamhetsanvändare tar del av instrumentpaneler och rapporter som bygger på konsekventa semantiska modeller. Den här optimeringen är särskilt viktig där prestanda, stabilitet och förutsägbart frågebeteende krävs under hög användning.

Exempel: Ekonomi- och driftteam får åtkomst till Power BI instrumentpaneler under kontorstid för att övervaka KPI:er, till exempel intäkter, driftseffektivitet och SLA-efterlevnad. Fabric Data Warehouse isolerar SELECT- och icke-SELECT-arbetsbelastningar i separata beräkningspooler, vilket minskar den direkta resurskonkurrensen mellan frågor från instrumentpaneler och inläsning till informationslagret.

Scenario 4: Stöd för dimensionsmodellering för ett återanvändbart guldskikt

Fabric Data Warehouse överensstämmer naturligt med dimensionsmodelleringsmönster, inklusive fakta- och dimensionstabeller, som du ofta använder i guldskiktet för att exponera affärsvänliga, återanvändbara datamängder. Dessa modeller förenklar analys, minskar logikduplicering och främjar konsekventa måttdefinitioner mellan team.

Exempel: En detaljhandelsorganisation skapar delade dimensionstabeller för kunder, produkter och butiker, tillsammans med faktatabeller för försäljning och inventering. Dessa gulddatauppsättningar återanvänds i flera Power BI rapporter och affärsenheter, vilket säkerställer att KPI:er som nettoförsäljning eller lageromsättning definieras en gång och tillämpas konsekvent.

Considerations

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.

Tillförlitlighet

Tillförlitlighet hjälper till att säkerställa att ditt program kan uppfylla de åtaganden som du gör gentemot dina kunder. Mer information finns i checklistan för designgranskning för tillförlitlighet.

Granska Tillförlitlighet i Microsoft Fabric för den dokumenterade resiliensmodellen, inklusive beteende vid zonbortfall och regionala överväganden. Verifiera återställningsförväntningarna mot den här vägledningen för dina region- och arbetsbelastningskrav.

För scenarier för haveriberedskap mellan regioner utformar och dokumenterar du en återställningsstrategi som överensstämmer med organisationens krav och modellen för delat ansvar.

• Fabric Data Warehouse stöder PRIMARY KEY, FOREIGN KEYoch UNIQUEtabellbegränsningar endast som NOT ENFORCED. Lagret validerar inte unikhet eller referensintegritet. Inmatnings- och transformeringslogik måste identifiera duplicerade eller överblivna poster och förhindra att de når underordnade lager.

Security

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 Säkerhet.

Microsoft Fabric tillhandahåller funktioner för att hantera, kontrollera och granska säkerhetsinställningar baserat på organisationens krav. Överväg följande säkerhetsmetoder:

• Använd Microsoft Entra ID enkel inloggning (SSO) för att autentisera användare och tillhandahålla konsekvent identitetshantering mellan enheter och platser.

• Använd arbetsytebaserade behörigheter för att styra vem som kan skapa, ändra eller använda Fabric artefakter.

• Använd Fabric inkommande och utgående nätverkssäkerhetskontroller vid åtkomst till data eller tjänster i eller utanför nätverket. Dessa kontroller omfattar villkorlig åtkomst, privata länkar, åtkomst till betrodda arbetsytor och hanterade privata slutpunkter.

• Använd Fabric granskningsloggar för att spåra användaraktivitet, konfigurationsändringar och dataåtkomst över hela plattformen.

Mer information finns i Säkerhet i Fabric.

Kostnadsoptimering

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

Microsoft Fabric tillhandahåller kapacitetsreservationer för ett definierat antal kapacitetsenheter (CUS). Reservationer för ett år kan bidra till att minska kostnader för förutsägbara, stabila arbetsbelastningar.

Tänk på följande metoder för att maximera Fabric kapacitetsutnyttjande:

• Börja med testkapaciteter eller F-SKU:er med betalning efter användning för att förstå hur arbetsbelastningen beter sig. Genomför ett avgränsat proof of concept med representativa arbetsbelastningar för datainhämtning, transformering och rapportering. Övervaka CU-förbrukning och extrapolera resultat för att uppskatta produktionsbehov. Du kan skala Fabric kapaciteter när efterfrågan ökar.

• Analysera historisk användning för att identifiera perioder med hög och låg belastning. Schemalägg icke-kritiska arbetsbelastningar eller bakgrundsarbetsbelastningar under perioder med lägre belastning för att minska ett ihållande tryck på CU.

• Minska onödig beräkningsförbrukning genom att optimera SQL-frågor, dataanalysuttryck (DAX) och bakgrundsjobb.

• Fabric stöder hantering av belastningstoppar och utjämning för att hantera kortvariga toppar i behovet av beräkningskapacitet och fördela resursförbrukningen för arbetsbelastningar i bakgrunden över tid. De här funktionerna hjälper till att storleksanpassa kapaciteter för genomsnittlig användning i stället för hög efterfrågan. Mer information finns i Utvärdera och optimera din Fabric-kapacitet.

• Samordna långvariga transformeringar och uppdateringsåtgärder för att undvika överlappande arbetsbelastningar med hög beräkning på samma kapacitet. Mer information finns i Arbetsbelastningshantering i Fabric Data Warehouse.

Tänk på följande prisöverväganden:

• OneLake-lagringsvolym, kvarhållningsperiod och dataåtkomstmönster påverkar direkt den totala kostnaden. Beräkna den förväntade datatillväxten för varje lager i medaljongarkitekturen och anpassa lagringstiden efter affärskrav och krav på regelefterlevnad.

• Microsoft Fabric prissättningen baseras på en tilldelad F-kapacitet, mätt i CU:er. Power BI-användarlicenser är separata och tillhandahåller inte Fabric-kapacitet.

Använd den förkonfigurerade uppskattningen i priskalkylatorn för Azure för att få en startkostnad för den här arkitekturen. Justera värdena så att de matchar din förväntade arbetsbelastning.

Operativ skicklighet

Operational Excellence omfattar de operativa processer som distribuerar, övervakar och underhåller en arbetsbelastning i produktion. Mer information finns i checklistan för designgranskning för Operational Excellence.

Microsoft Fabric ger inbyggd driftssynlighet för datateknik, lagerhantering och analysarbetsbelastningar. Använd appen Fabric Kapacitetsmått för att övervaka kapacitetsförbrukningen, identifiera resursintensiva artefakter och förstå hur interaktiva arbetsbelastningar och bakgrundsarbetsbelastningar bidrar till den totala användningen. Dessa insikter hjälper teamen att fatta välgrundade operativa beslut om skalning, schemaläggning och optimering.

Konfigurera proaktiva aviseringar så att kapacitetsadministratörer kan identifiera höga användnings- eller begränsningsvillkor tidigt och svara innan användarpåverkan inträffar.

Prestandaeffektivitet

Prestandaeffektivitet syftar på en arbetsbelastnings förmåga att skala och möta användarnas efterfrågan effektivt. Mer information finns i checklistan för designgranskning för prestandaeffektivitet.

Microsoft Fabric innehåller flera mekanismer för att hantera prestanda och kapacitetsanvändning:

• Bristning och utjämning gör att kortsiktiga toppar i beräkningsefterfrågan kan slutföras snabbare samtidigt som användningen sprids över tid. Interaktiva åtgärder jämnas vanligtvis ut över minuter och bakgrundsåtgärderna jämnas ut över längre fönster.

• Strypning sker när en kapacitet har ihållande användning av beräkningsresurser som överskrider gränserna för dess tilldelade SKU. Strypning fördröjer eller avvisar nya operationer för att skydda plattformens stabilitet.

• Appen Fabric Capacity Metrics ger detaljerad insyn i kapacitetsförbrukningen och skiljer mellan interaktiva åtgärder (till exempel rapportfrågor) och bakgrundsåtgärder (till exempel inmatning eller modelluppdatering). Den här skillnaden möjliggör riktade prestandaoptimeringar för olika arbetsbelastningstyper.

Contributors

Microsoft underhåller den här artikeln. Följande bidragsgivare skrev den här artikeln.

• Prabhjot Kaur | Senior Cloud Solution Architect

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

Nästa steg

• Vad är Fabric Data Warehouse?
• Lageranslutning
• Vad är Copilot i Data Warehouse?
• CI/CD i Fabric Data Warehouse
• Datalagerarkitektur

Relaterade resurser

• Välj ett analysdatalager i Microsoft Fabric
• Vad är en datasjö?
• Informationslager och analys