Dela via

Implementera medallion lakehouse-arkitektur i Microsoft Fabric

  • Artikel

Den här artikeln beskriver arkitekturen för medallion lake och beskriver hur du kan implementera ett sjöhus i Microsoft Fabric. Den riktar sig till flera målgrupper:

  • Datatekniker: Teknisk personal som utformar, skapar och underhåller infrastrukturer och system som gör det möjligt för organisationen att samla in, lagra, bearbeta och analysera stora mängder data.
  • Center of Excellence-, IT- och BI-teamet: De team som ansvarar för att övervaka analyser i hela organisationen.
  • Infrastrukturadministratörer: De administratörer som ansvarar för att övervaka infrastrukturresurser i organisationen.

Medallion Lakehouse-arkitekturen, som ofta kallas medallionarkitektur, är ett designmönster som används av organisationer för att logiskt organisera data i ett sjöhus. Det är den rekommenderade designmetoden för Fabric.

Medallion-arkitekturen består av tre distinkta skikt – eller zoner. Varje lager anger kvaliteten på data som lagras i lakehouse, med högre nivåer som representerar högre kvalitet. Den här metoden med flera lager hjälper dig att skapa en enda sanningskälla för företagets dataprodukter.

Det är viktigt att medaljongarkitekturen garanterar ACID-uppsättningen egenskaper (atomicitet, konsekvens, isolering och hållbarhet) när data utvecklas genom lagren. Från och med rådata förbereder en serie valideringar och transformeringar data som är optimerade för effektiv analys. Det finns tre medaljongsteg: brons (rå), silver (validerat) och guld (berikat).

Mer information finns i Vad är arkitekturen i medallion lakehouse?.

OneLake och lakehouse i Fabric

Grunden för ett modernt informationslager är en datasjö. Microsoft OneLake, som är en enda, enhetlig, logisk datasjö för hela organisationen. Den etableras automatiskt med varje Fabric-klientorganisation och är utformad för att vara den enda platsen för alla dina analysdata.

Du kan använda OneLake för att:

  • Ta bort silor och minska hanteringsarbetet. Alla organisationsdata lagras, hanteras och skyddas i en datasjöresurs. Eftersom OneLake etableras med fabric-klientorganisationen finns det inga fler resurser att etablera eller hantera.
  • Minska dataförflyttning och duplicering. Målet med OneLake är att endast lagra en kopia av data. Färre kopior av data resulterar i färre dataförflyttningsprocesser, vilket leder till effektivitetsvinster och minskad komplexitet. Om det behövs kan du skapa en genväg för att referera till data som lagras på andra platser i stället för att kopiera dem till OneLake.
  • Använd med flera analysmotorer. Data i OneLake lagras i ett öppet format. På så sätt kan data efterfrågas av olika analysmotorer, inklusive Analysis Services (används av Power BI), T-SQL och Apache Spark. Andra icke-Fabric-program kan också använda API:er och SDK:er för att komma åt OneLake .

Mer information finns i OneLake, OneDrive för data.

Om du vill lagra data i OneLake skapar du ett lakehouse i Fabric. En lakehouse är en plattform för dataarkitektur för lagring, hantering och analys av strukturerade och ostrukturerade data på en enda plats. Den kan enkelt skalas till stora datavolymer av alla filtyper och storlekar, och eftersom den lagras på en enda plats delas och återanvänds den enkelt i organisationen.

Varje lakehouse har en inbyggd SQL-analysslutpunkt som låser upp informationslagerfunktioner utan att behöva flytta data. Det innebär att du kan köra frågor mot dina data i lakehouse med hjälp av SQL-frågor och utan någon särskild konfiguration.

Mer information finns i Vad är ett sjöhus i Microsoft Fabric?.

Tabeller och filer

När du skapar ett lakehouse i Fabric etableras två fysiska lagringsplatser automatiskt för tabeller och filer.

  • Tabeller är ett hanterat område för värdtabeller i alla format i Apache Spark (CSV, Parquet eller Delta). Alla tabeller, oavsett om de skapas automatiskt eller uttryckligen, identifieras som tabeller i lakehouse. Dessutom identifieras alla Delta-tabeller, som är Parquet-datafiler med en filbaserad transaktionslogg, även som tabeller.
  • Filer är ett ohanterat område för lagring av data i valfritt filformat. Alla Delta-filer som lagras i det här området identifieras inte automatiskt som tabeller. Om du vill skapa en tabell över en Delta Lake-mapp i det ohanterade området måste du uttryckligen skapa en genväg eller en extern tabell med en plats som pekar på den ohanterade mappen som innehåller Delta Lake-filerna i Apache Spark.

Den största skillnaden mellan det hanterade området (tabeller) och det ohanterade området (filer) är den automatiska processen för identifiering och registrering av tabeller. Den här processen körs endast över alla mappar som skapats i det hanterade området, men inte i det ohanterade området.

I Microsoft Fabric ger Lakehouse Explorer en enhetlig grafisk representation av hela Lakehouse så att användarna kan navigera, komma åt och uppdatera sina data.

Mer information om automatisk tabellidentifiering finns i Automatisk tabellidentifiering och registrering.

Delta Lake-lagring

Delta Lake är ett optimerat lagringslager som utgör grunden för lagring av data och tabeller. Det stöder ACID-transaktioner för stordataarbetsbelastningar, och därför är det standardlagringsformatet i en Infrastruktursjöhus.

Viktigt är att Delta Lake levererar tillförlitlighet, säkerhet och prestanda i lakehouse för både strömning och batchdrift. Internt lagrar den data i Parquet-filformat, men den har även transaktionsloggar och statistik som ger funktioner och prestandaförbättringar jämfört med standardformatet Parquet.

Delta Lake-format över generiska filformat ger följande huvudsakliga fördelar.

  • Stöd för ACID-egenskaper och särskilt hållbarhet för att förhindra att data skadas.
  • Snabbare läsfrågor.
  • Ökad data freshness.
  • Stöd för både batch- och strömningsarbetsbelastningar.
  • Stöd för återställning av data med hjälp av Delta Lake-tidsresor.
  • Förbättrad regelefterlevnad och granskning med hjälp av Delta Lake-tabellhistoriken.

Fabric standardiserar lagringsfilformatet med Delta Lake, och som standard skapar varje arbetsbelastningsmotor i Fabric Delta-tabeller när du skriver data till en ny tabell. Mer information finns i Tabellerna Lakehouse och Delta Lake.

Medallion-arkitektur i Infrastruktur

Målet med medaljongarkitekturen är att stegvis och progressivt förbättra strukturen och kvaliteten på data under varje fas.

Medallion-arkitekturen består av tre distinkta skikt (eller zoner).

  • Brons: Det här första lagret är även känt som råzonen och lagrar källdata i sitt ursprungliga format. Data i det här lagret är vanligtvis endast tillägg och oföränderliga.
  • Silver: Det här lagret kallas även för den berikade zonen och lagrar data från bronsskiktet. Rådata har rensats och standardiserats och är nu strukturerade som tabeller (rader och kolumner). Det kan också vara integrerat med andra data för att ge en företagsvy över alla affärsentiteter, till exempel kund, produkt och andra.
  • Guld: Det här sista lagret kallas även för den kurerade zonen och lagrar data från silverskiktet. Data förfinas för att uppfylla specifika verksamhets- och analyskrav för nedströms. Tabeller överensstämmer vanligtvis med star-schemadesign, som stöder utveckling av datamodeller som är optimerade för prestanda och användbarhet.

Viktigt!

Eftersom en Infrastruktursjöhus representerar en enda zon skapar du ett sjöhus för var och en av de tre zonerna.

Diagram över ett exempel på OneLake-medaljongarkitektur som visar datakällor, förbereder och transformerar med brons-, silver- och guldskikt och analyserar med SQL-analysslutpunkten och Power BI.

I en typisk implementering av medaljongarkitektur i Infrastruktur lagrar bronszonen data i samma format som datakällan. När datakällan är en relationsdatabas är Delta-tabeller ett bra val. Silver- och guldzonerna innehåller Delta-tabeller.

Dricks

Om du vill lära dig hur du skapar ett sjöhus kan du gå igenom självstudiekursen för lakehouse-scenariot från slutpunkt till slutpunkt .

Vägledning för infrastruktursjöhus

I det här avsnittet får du vägledning om hur du implementerar fabric lakehouse med hjälp av medaljongarkitektur.

Distributionsmodell

Om du vill implementera medaljongarkitektur i Infrastruktur kan du antingen använda lakehouses (ett för varje zon), ett informationslager eller en kombination av båda. Ditt beslut bör baseras på dina önskemål och expertkunskaper i ditt team. Tänk på att Fabric ger dig flexibilitet: Du kan använda olika analysmotorer som fungerar på en kopia av dina data i OneLake.

Här är två mönster att tänka på.

  • Mönster 1: Skapa varje zon som ett sjöhus. I det här fallet får företagsanvändare åtkomst till data med hjälp av SQL-analysslutpunkten.
  • Mönster 2: Skapa brons- och silverzonerna som sjöhus och guldzonen som informationslager. I det här fallet får företagsanvändare åtkomst till data med hjälp av datalagerslutpunkten.

Även om du kan skapa alla lakehouses på en enda infrastrukturarbetsyta rekommenderar vi att du skapar varje lakehouse i en egen, separat infrastrukturarbetsyta. Den här metoden ger dig mer kontroll och bättre styrning på zonnivå.

För bronszonen rekommenderar vi att du lagrar data i dess ursprungliga format eller använder Parquet eller Delta Lake. När det är möjligt behåller du data i sitt ursprungliga format. Om källdata kommer från OneLake, Azure Data Lake Store Gen2 (ADLS Gen2), Amazon S3 eller Google skapar du en genväg i bronszonen i stället för att kopiera data över.

För silver- och guldzonerna rekommenderar vi att du använder Delta-tabeller på grund av de extra funktioner och prestandaförbättringar som de ger. Infrastrukturresurserna standardiseras i Delta Lake-format och som standard skriver varje motor i Fabric data i det här formatet. Dessutom använder dessa motorer optimering av V-Order-skrivtid till Parquet-filformatet. Den optimeringen möjliggör extremt snabba läsningar av Fabric-beräkningsmotorer, till exempel Power BI, SQL, Apache Spark och andra. Mer information finns i Delta Lake-tabelloptimering och V-order.

Slutligen står många organisationer idag inför en massiv ökning av datavolymer, tillsammans med ett ökande behov av att organisera och hantera dessa data på ett logiskt sätt samtidigt som mer målinriktad och effektiv användning och styrning underlättas. Det kan leda till att du upprättar och hanterar en decentraliserad eller federerad dataorganisation med styrning.

För att uppfylla det här målet bör du överväga att implementera en datanätsarkitektur. Data mesh är ett arkitekturmönster som fokuserar på att skapa datadomäner som erbjuder data som en produkt.

Du kan skapa en datanätsarkitektur för din dataegendom i Fabric genom att skapa datadomäner. Du kan skapa domäner som mappar till dina affärsdomäner, till exempel marknadsföring, försäljning, inventering, personal och andra. Du kan sedan implementera medallion-arkitektur genom att konfigurera datazoner inom var och en av dina domäner.

Mer information om domäner finns i Domäner.

Förstå Datalagring i Delta-tabeller

Det här avsnittet beskriver andra vägledningsämnen som rör implementering av en medallion lakehouse-arkitektur i Fabric.

Filstorlek

I allmänhet presterar en stordataplattform bättre när den har ett litet antal stora filer i stället för ett stort antal små filer. Det beror på att prestandaförsämring inträffar när beräkningsmotorn måste hantera många metadata och filåtgärder. För bättre frågeprestanda rekommenderar vi att du siktar på datafiler som är ungefär 1 GB stora.

Delta Lake har en funktion som kallas förutsägelseoptimering. Förutsägande optimering tar bort behovet av att manuellt hantera underhållsåtgärder för Delta-tabeller. När den här funktionen är aktiverad identifierar Delta Lake automatiskt tabeller som skulle dra nytta av underhållsåtgärder och optimerar sedan deras lagring. Det kan transparent slå samman många mindre filer i stora filer, och utan någon inverkan på andra läsare och författare av data. Även om den här funktionen bör utgöra en del av din driftskvalitet och ditt arbete med dataförberedelse har Fabric även möjlighet att optimera dessa datafiler under dataskrivning. Mer information finns i Förutsägande optimering för Delta Lake.

Historisk kvarhållning

Som standard har Delta Lake en historik över alla ändringar som gjorts. Det innebär att storleken på historiska metadata växer över tid. Baserat på dina affärskrav bör du sträva efter att endast behålla historiska data under en viss tidsperiod för att minska dina lagringskostnader. Överväg att behålla historiska data endast under den senaste månaden eller någon annan lämplig tidsperiod.

Du kan ta bort äldre historiska data från en Delta-tabell med hjälp av kommandot VACUUM. Tänk dock på att du som standard inte kan ta bort historiska data under de senaste sju dagarna – det är för att upprätthålla konsekvensen i data. Standardantalet dagar styrs av tabellegenskapen delta.deletedFileRetentionDuration = "interval <interval>". Den avgör hur lång tid en fil måste tas bort innan den kan betraktas som en kandidat för en vakuumåtgärd.

Tabellpartitioner

När du lagrar data i varje zon rekommenderar vi att du använder en partitionerad mappstruktur i tillämpliga fall. Den här tekniken hjälper till att förbättra data hanterbarhet och frågeprestanda. I allmänhet resulterar partitionerade data i en mappstruktur i snabbare sökning efter specifika dataposter tack vare partitionsrensning/eliminering.

Vanligtvis lägger du till data i måltabellen när nya data tas emot. I vissa fall kan du dock sammanfoga data eftersom du behöver uppdatera befintliga data samtidigt. I så fall kan du utföra en upsert-åtgärd med hjälp av KOMMANDOT MERGE. När måltabellen är partitionerad måste du använda ett partitionsfilter för att påskynda åtgärden. På så sätt kan motorn eliminera partitioner som inte kräver uppdatering.

Dataåtkomst

Slutligen bör du planera och kontrollera vem som behöver åtkomst till specifika data i lakehouse. Du bör också förstå de olika transaktionsmönster som de kommer att använda vid åtkomst till dessa data. Du kan sedan definiera rätt tabellpartitioneringsschema och datasamordning med Delta Lake Z-orderindex.

Relaterat innehåll

Mer information om hur du implementerar en Infrastruktursjöhus finns i följande resurser.