Del via

Forstå medaljong lakehouse arkitektur for Microsoft Fabric med OneLake

Denne artikkelen introduserer arkitektur for medaljongsjøen og beskriver hvordan du kan implementere utformingsmønsteret i Microsoft Fabric. Den er rettet mot flere målgrupper:

  • Dataingeniører: Teknisk personale som utformer, bygger og vedlikeholder infrastrukturer og systemer som gjør det mulig for organisasjonen å samle inn, lagre, behandle og analysere store mengder data.
  • Center of Excellence-, IT- og BI-team: Teamene som er ansvarlige for å overvåke analyser i hele organisasjonen.
  • Fabric-administratorer: Administratorene som er ansvarlige for å overvåke Fabric i organisasjonen.

Medaljong lakehouse arkitektur, kjent som medaljong arkitektur, er et designmønster som brukes av organisasjoner til logisk å organisere data i et innsjøhus. Det er den anbefalte designtilnærmingen for Fabric. Siden OneLake er datasjøen for Fabric, implementeres medaljongarkitektur ved å opprette innsjøer i OneLake.

Medaljongarkitektur består av tre forskjellige lag, også kalt soner. De tre medaljonglagene er: bronse (rådata), sølv (validerte data) og gull (berikede data). Hvert lag indikerer kvaliteten på dataene som er lagret i lakehouse, med høyere nivåer som representerer høyere kvalitet. Denne flerlags tilnærmingen hjelper deg med å bygge en enkelt kilde til sannhet for bedriftsdataprodukter.

Viktigere, medaljong arkitektur garanterer atomitet, konsistens, isolasjon og holdbarhet (ACID) som data utvikler seg gjennom lagene. Dataene starter i råform, og deretter klargjør en rekke valideringer og transformasjoner dataene for å optimalisere dem for effektiv analyse samtidig som de opprinnelige kopiene opprettholdes som en kilde til sannhet.

Hvis du vil ha mer informasjon, kan du se Hva er medaljongen lakehouse arkitektur?.

Medaljongarkitektur i Stoff

Målet med medaljongarkitekturen er å trinnvis og gradvis forbedre strukturen og kvaliteten på dataene etter hvert som den utvikler seg gjennom hvert trinn.

Medaljongarkitektur består av tre forskjellige lag (eller soner).

  • Bronse: Dette første laget kalles også råsonen, og lagrer kildedata i det opprinnelige formatet, inkludert ustrukturerte, halvstrukturerte eller strukturerte datatyper. Dataene i dette laget er vanligvis tilføybare og uforanderlige. Ved å bevare rådataene i bronselaget opprettholder du en kilde til sannhet og aktiverer reprosessering og revisjon i fremtiden.
  • Sølv: Dette laget kalles også den berikede sonen, og lagrer data hentet fra bronselaget. Dataene er renset og standardisert, og nå er de strukturert som tabeller (rader og kolonner). Det kan også være integrert med andre data for å gi en virksomhetsvisning av alle forretningsenheter, for eksempel kunder, produkter og mer.
  • Gull: Dette siste laget kalles også den kuraterte sonen, og lagrer data hentet fra sølvlaget. Dataene er presisert for å oppfylle spesifikke nedstrøms forretnings- og analysekrav. Tabeller samsvarer vanligvis med utforming av stjerneskjema, som støtter utvikling av datamodeller som er optimalisert for ytelse og brukervennlighet.

Hver sone bør deles inn i sitt eget lakehouse eller datalager i OneLake, med data som beveger seg mellom sonene etter hvert som den transformeres og raffineres.

Diagram over OneLake medaljongarkitektur som viser datakilder, klargjør og transformerer med tre lag og analyser med SQL og Power BI.

I en typisk implementering av medaljongarkitektur i Fabric lagrer bronsesonen dataene i samme format som datakilden. Når datakilden er en relasjonsdatabase, er Delta-tabeller et godt valg. Sølv- og gullsonene bør inneholde Delta-tabeller.

Tips

Hvis du vil lære hvordan du oppretter et lakehouse, kan du arbeide gjennom opplæringen i ende-til-ende-scenarioet i Lakehouse.

OneLake og lakehouse i Fabric

Grunnlaget for et moderne datalager er en datainnsjø. Microsoft OneLake er en enkel, enhetlig, logisk datainnsjø for hele organisasjonen. Den leveres automatisk med hver Fabric-leier, og det er den eneste plasseringen for alle analysedataene dine.

Du kan bruke OneLake til å:

  • Fjern siloer og reduser administrasjonsarbeidet. Alle organisasjonsdata lagres, administreres og sikres i én datainnsjøressurs.
  • Reduser dataflytting og duplisering. Målet med OneLake er å lagre bare én kopi av data. Færre kopier av data resulterer i færre databevegelsesprosesser, og det fører til effektivitetsgevinster og reduksjon i kompleksiteten. Bruk snarveier til å referere til data som er lagret andre steder, i stedet for å kopiere dem til OneLake.
  • Bruk med flere analytiske motorer. Dataene i OneLake lagres i et åpent format. På denne måten kan dataene spørres av ulike analytiske motorer, inkludert Analysis Services (brukes av Power BI), T-SQL og Apache Spark. Andre programmer som ikke er stoff, kan også bruke API-er og SDK-er for å få tilgang til OneLake .

Hvis du vil lagre data i OneLake, oppretter du et lakehouse i Fabric. Et lakehouse er en dataarkitekturplattform for lagring, administrasjon og analyse av strukturerte og ustrukturerte data på ett sted. Den kan skaleres til store datavolumer av alle filtyper og størrelser, og fordi dataene lagres på én enkelt plassering, kan de deles og brukes på nytt på tvers av organisasjonen.

Hvert lakehouse har et innebygd SQL Analytics-endepunkt som låser opp datalagerfunksjoner uten å måtte flytte data. Det betyr at du kan spørre dataene i lakehouse ved hjelp av SQL-spørringer og uten noen spesiell konfigurasjon.

Hvis du vil ha mer informasjon, kan du se Hva er et lakehouse i Microsoft Fabric?.

Tabeller og filer

Når du oppretter et lakehouse i OneLake, klargjøres to fysiske lagringssteder automatisk:

  • Tabeller er et administrert område for lagring av tabeller i alle formater i Apache Spark (CSV, Parquet eller Delta). Alle tabeller, enten de opprettes automatisk eller eksplisitt, gjenkjennes som tabeller i lakehouse. Alle Delta-tabeller, som er Parquet-datafiler med en filbasert transaksjonslogg, gjenkjennes også som tabeller.
  • Filer er et uadministrert område for lagring av data i alle filformater. Delta-filer som er lagret i dette området, gjenkjennes ikke automatisk som tabeller. Hvis du vil opprette en tabell over en Delta Lake-mappe i det uadministrerte området, oppretter du en snarvei eller en ekstern tabell med en plassering som peker til den uadministrerte mappen som inneholder Delta Lake-filene i Apache Spark.

Hovedforskjellen mellom det administrerte området (tabeller) og det uadministrerte området (filer) er den automatiske tabelloppdagelses- og registreringsprosessen. Denne prosessen kjører bare over alle mapper som er opprettet i det administrerte området, men ikke i det uadministrerte området.

I bronsesonen lagrer du data i det opprinnelige formatet, som kan være enten tabeller eller filer. Hvis kildedataene er fra OneLake, oppretter Azure Data Lake Store Gen2 (ADLS Gen2), Amazon S3 eller Google en snarvei i bronsesonen i stedet for å kopiere dataene på tvers.

I sølv- og gullsonene lagrer du vanligvis data i Delta-tabeller. Du kan imidlertid også lagre data i Parquet- eller CSV-filer. Hvis du gjør dette, må du eksplisitt opprette en snarvei eller en ekstern tabell med en plassering som peker til den uadministrerte mappen som inneholder Delta Lake-filene i Apache Spark.

I Microsoft Fabric gir Lakehouse Explorer en enhetlig grafisk representasjon av hele Lakehouse for brukere å navigere, få tilgang til og oppdatere dataene sine.

Hvis du vil ha mer informasjon om automatisk tabelloppdagelse, kan du se Automatisk tabelloppdagelse og -registrering.

Delta Lake-lagring

Delta Lake er et optimalisert lagringslag som gir grunnlaget for lagring av data og tabeller. Den støtter ACID-transaksjoner for store dataarbeidsbelastninger, og derfor er det standard lagringsformat i et Fabric Lakehouse.

Delta Lake leverer pålitelighet, sikkerhet og ytelse i lakehouse for både streaming og batch operasjoner. Internt lagrer den data i Parquet-filformat, men det opprettholder også transaksjonslogger og statistikk som gir funksjoner og ytelsesforbedringer i forhold til standard parkettformat.

Delta Lake-format gir følgende fordeler sammenlignet med generiske filformater:

  • Støtte for ACID-egenskaper, spesielt holdbarhet for å forhindre datakorrupsjon.
  • Raskere lesespørringer.
  • Økt datafriskhet.
  • Støtte for både gruppe- og strømming av arbeidsbelastninger.
  • Støtte for tilbakerulling av data ved hjelp av Tidsreiser i Delta Lake.
  • Forbedret forskriftssamsvar og revisjon ved hjelp av Tabelllogg for Delta Lake.

Fabric standardiserer lagringsfilformatet med Delta Lake. Som standard oppretter alle arbeidsbelastningsmotorer i Fabric Delta-tabeller når du skriver data til en ny tabell. Hvis du vil ha mer informasjon, kan du se Lakehouse- og Delta Lake-bord.

Distribusjonsmodell

Hvis du vil implementere medaljongarkitektur i Fabric, kan du enten bruke lakehouses (én for hver sone), et datalager eller en kombinasjon av begge. Din beslutning bør være basert på dine preferanser og ekspertisen til teamet ditt. Med Fabric kan du bruke forskjellige analytiske motorer som fungerer på den ene kopien av dataene dine i OneLake.

Her er to mønstre å vurdere:

  • Mønster 1: Opprett hver sone som et innsjøhus. I dette tilfellet får forretningsbrukere tilgang til data ved hjelp av SQL Analytics-endepunktet.
  • Mønster 2: Opprett bronse- og sølvsonene som innsjøer, og gullsonen som et datalager. I dette tilfellet får forretningsbrukere tilgang til data ved hjelp av datalagerendepunktet.

Selv om du kan opprette alle lakehouses i et enkelt Fabric arbeidsområde, anbefaler vi at du oppretter hvert lakehouse i sitt eget, separate arbeidsområde. Denne tilnærmingen gir deg mer kontroll og bedre styring på sonenivå.

For bronsesonen anbefaler vi at du lagrer dataene i det opprinnelige formatet, eller bruker Parquet eller Delta Lake. Når det er mulig, beholder du dataene i det opprinnelige formatet. Hvis kildedataene er fra OneLake, oppretter Azure Data Lake Store Gen2 (ADLS Gen2), Amazon S3 eller Google en snarvei i bronsesonen i stedet for å kopiere dataene på tvers.

For sølv- og gullsonene anbefaler vi at du bruker Delta-tabeller på grunn av de ekstra funksjonene og ytelsesforbedringene de tilbyr. Stoff standardiseres på Delta Lake-format, og som standard skriver hver motor i Fabric data i dette formatet. Videre bruker disse motorene V-Order-skrivetidsoptimalisering til Parquet-filformatet. Denne optimaliseringen muliggjør rask lesing av stoffdatabehandlingsmotorer, for eksempel Power BI, SQL, Apache Spark og andre. Hvis du vil ha mer informasjon, kan du se Tabelloptimalisering for Delta Lake og V-order.

Til slutt står mange organisasjoner i dag overfor massiv vekst i datavolumer, sammen med et økende behov for å organisere og administrere disse dataene på en logisk måte, samtidig som de legger til rette for mer målrettet og effektiv bruk og styring. Dette kan føre til at du etablerer og administrerer en desentralisert eller forbundsbasert dataorganisasjon med styring. For å nå dette målet bør du vurdere å implementere en datanettarkitektur. Datanett er et arkitektonisk mønster som fokuserer på å opprette datadomener som tilbyr data som et produkt.

Du kan opprette en datanettarkitektur for dataområdet i Fabric ved å opprette datadomener. Du kan opprette domener som tilordnes forretningsdomenene, for eksempel markedsføring, salg, beholdning, personaladministrasjon og andre. Deretter kan du implementere medaljongarkitektur ved å konfigurere datasoner innenfor hvert av domenene dine. Hvis du vil ha mer informasjon om domener, kan du se Domener.

Forstå datalagring for Delta-tabell

Denne delen beskriver andre veiledninger knyttet til implementering av en medaljong lakehouse arkitektur i Fabric.

Filstørrelse

Vanligvis fungerer en stor dataplattform bedre når den har noen store filer i stedet for mange små filer. Ytelsesreduksjon oppstår når databehandlingsmotoren har mange metadata- og filoperasjoner å administrere. For bedre spørringsytelse anbefaler vi at du sikter mot datafiler som er omtrent 1 GB i størrelse.

Delta Lake har en funksjon som kalles prediktiv optimalisering. Prediktiv optimalisering automatiserer vedlikeholdsoperasjoner for Delta-tabeller. Når denne funksjonen er aktivert, identifiserer Delta Lake tabeller som vil dra nytte av vedlikeholdsoperasjoner og deretter optimalisere lagringsplassen. Selv om denne funksjonen skal være en del av den operative fortreffeligheten og dataforberedelsesarbeidet, kan Fabric optimalisere datafiler under dataskriving også. Hvis du vil ha mer informasjon, kan du se Prediktiv optimalisering for Delta Lake.

Historisk oppbevaring

Som standard opprettholder Delta Lake en historie over alle endringer som er gjort, slik at størrelsen på historiske metadata vokser over tid. Behold historiske data i en viss tidsperiode basert på forretningskravene dine for å redusere lagringskostnadene. Vurder å beholde historiske data for bare den siste måneden eller en annen passende tidsperiode.

Du kan fjerne eldre historiske data fra en Delta-tabell ved hjelp av VACUUM-kommandoen. Som standard kan du imidlertid ikke slette historiske data i løpet av de siste sju dagene. Denne begrensningen opprettholder konsekvensen i data. Konfigurer standard antall dager med tabellegenskapen delta.deletedFileRetentionDuration = "interval <interval>". Denne egenskapen bestemmer tidsperioden som en fil må slettes før den kan betraktes som en kandidat for en vakuumoperasjon.

Tabell partisjoner

Når du lagrer data i hver sone, anbefaler vi at du bruker en partisjonert mappestruktur der det er aktuelt. Denne teknikken forbedrer databehandling og spørringsytelse. Partisjonerte data i en mappestruktur resulterer vanligvis i raskere søk etter bestemte dataoppføringer på grunn av partisjonsbeskjæring/eliminering.

Vanligvis tilføyer du data til måltabellen etter hvert som nye data kommer. I noen tilfeller kan du imidlertid flette data fordi du må oppdatere eksisterende data samtidig. I så fall kan du utføre en upsert-operasjon ved hjelp av KOMMANDOEN SLÅ SAMMEN. Når måltabellen er partisjonert, må du bruke et partisjonsfilter for å øke hastigheten på operasjonen. På den måten kan motoren eliminere partisjoner som ikke krever oppdatering.

Datatilgang

Du bør planlegge og kontrollere hvem som trenger tilgang til bestemte data i lakehouse. Du bør også forstå de ulike transaksjonsmønstrene de kommer til å bruke mens du får tilgang til disse dataene. Deretter kan du definere riktig tabellpartisjoneringsskjema og datakollegasjon med Delta Lake Z-ordreindekser.

Relatert innhold

Hvis du vil ha mer informasjon om hvordan du implementerer et Fabric Lakehouse, kan du se følgende ressurser.