Almindelige dbt-jobmønstre i Microsoft Fabric (forhåndsvisning)

dbt-job i Microsoft Fabric giver en styret måde at køre dbt-projekter på som en del af Fabric-dataplatformen. Brug dem, når teams ønsker modulære SQL-baserede transformationer, tests, afhængighedsstyring og kildekontrolleret analyseingeniørarbejde, mens Fabric leverer indtagelse, lagring, orkestrering, overvågning og forbrug.

Der findes ikke et eneste korrekt medaljondesign. Bronze, Silver og Gold kan bruges Fabric data warehouse, Lakehouse eller begge. Det rigtige valg afhænger af, hvor data lander, hvilken motor der skal udføre transformationer, hvordan kuraterede data leveres, og om DBT kører uafhængigt eller som en del af en større Fabric-pipeline.

Vælg mønsteret, før du implementerer

Bronze opbevarer kildetilpassede data, Silver standardiserer og validerer dem, og Gold organiserer dem til analyse. dbt kan eje sølvgrænsen, guldgrænsen eller begge dele. Hold implementeringen så enkel som kravene tillader, og gør hvert ansvar eksplicit. Fabric-pipelines kan orkestrere indtagelse, dbt-udførelse, validering, notifikationer og downstream-aktiviteter på tværs af alle mønstrene beskrevet i denne guide.

Hurtigt overblik

Mønster Bronze Sølv Guld Bedste pasform
1. Kun lagerplads Lagersted Lagersted Lagersted SQL-først lagerarbejdsbelastninger
2. Lakehouse-landing + Lager Lakehouse Lagersted Lagersted Open-format landing, SQL-servering
3. Lakehouse-forfining + lager Lakehouse Lakehouse Lagersted Lake engineering, BI service
4. Kun søhus Lakehouse Lakehouse Lakehouse Delta-først arbejdsbelastninger

Mønster 1: Medaljon kun til lageret

Hold Bronze, Sølv og Guld i Fabric data warehouse. Brug skemaer eller separate lagerelementer til at isolere lagene.

Arkitekturdiagram viser kilder, Fabric Ingestion, Bronze, dbt staging, Silver, dbt forretningsmodeller, Gold og Power BI i et Warehouse-only medallionmønster.

Figur 1. Kun lagermedaljon.

Brug dette mønster, når: Kilder er primært relationelle, teamet er SQL-først, og Warehouse er den naturlige transformations- og serveringsplatform.

Hvor DBT passer ind: DBT håndterer transformationer, tests, modelafhængigheder og kuraterede mart'er. Logiske dbt-lag som staging, intermediate og marts kan mappes til Warehouse-skemaer uden at blive behandlet som identiske koncepter.

Hvor Fabric passer: Lageropbevares og udfører modellerne. Fabric-pipelines kan koordinere indtagelse og eksekvering. Power BI bruger det kuraterede guldlag.

Hvorfor vælge det

  • Én SQL-centreret platform for alle lag.
  • Undgår at introducere Spark, når arbejdsbyrden ikke kræver det.
  • Passer til lagermigreringer og dimensionelle BI-arbejdsbelastninger.

Overvejelser

  • Warehouse Bronze er relationel snarere end en fil-native landingszone.
  • Semistrukturerede eller filbehandlingsarbejdsbyrder kan passe bedre til Lakehouse.
  • Adskil udviklings- og produktionsobjekter bevidst.

Mønster 2: Lakehouse-landing med Warehouse-transformation

Land rådata i Lakehouse, og byg derefter sølv- og guldmodeller i Warehouse med dbt.

Arkitekturdiagram, der viser rådata i et bronze søhus, bevægelse til lager, dbt-transformationer for sølv og guld samt forbrug af Power BI.

Figur 2. Lakehouse-landing med Warehouse-transformation.

Brug dette mønster, når: Brug dette mønster, når rådata lander i OneLake, men et SQL-først-team ønsker at bygge både Silver- og Gold-modeller i Fabric data warehouse med T-SQL. Denne tilgang holder transformationen og fungerer i én relationel motor.

Hvor dbt passer ind: dbt læser Lakehouse-data gennem det skrivebeskyttede SQL-analyseendepunkt ved at bruge T-SQL krydsdatabaseforespørgsler og tre-delt navngivning, såsom LakehouseName.dbo.TableName. Denne adgangsvej er begrænset til genstande i samme Fabric-arbejdsområde. Til scenarier på tværs af arbejdsområder kan OneLake-genveje bruges til at eksponere nødvendige Delta-tabeller.

Hvor Fabric passer ind: Lakehouse gemmer rå data. Lagerbutikker tilpassede og kuraterede relationelle modeller. Pipelines koordinerer indtastning og dbt-udførelse.

Hvorfor vælge det

  • Kombinerer åbent format rå lagring med et SQL-first serveringslag.
  • Holder Silver- og Gold-transformationerne i samme Fabric data warehouse og reducerer behovet for at drive flere transformationsmotorer.
  • Skaber en klar overgang fra rådata til dimensionelle modeller.

Overvejelser

  • Adgang på tværs af arbejdsområder kræver OneLake-genveje for at gøre de nødvendige Delta-tabeller tilgængelige i det forbrugende arbejdsområde.
  • Kun Delta-tabeller i Lakehouse Tables-området er tilgængelige via SQL-analyse-endpointet.
  • Tag højde for metadatasynkroniseringsadfærd og forskelle mellem understøttede Delta- og T-SQL-datatyper.
  • Lakehouse SQL-analyse-endpointet er skrivebeskyttet. dbt materialiserer sølv- og guldmodeller i mållageret.
  • Brugen af både Lakehouse og Warehouse introducerer en ekstra driftsmæssig grænse.

Mønster 3: Lakehouse-forfinelse med lagerservice

Brug Lakehouse til bronze og sølv, og udgiv derefter kuraterede guldmodeller til Warehouse.

Arkitekturdiagram, der viser bronze og sølv i Lakehouse, overgang til lager, dbt-guldmodellering og forbrug af Power BI.

Figur 3. Lakehouse-forfinelse med lagerservice.

Brug dette mønster, når: Vælg dette mønster, når dataingeniørteams forfiner og bevarer bronze- og sølvdata i Lakehouse ved hjælp af Delta-orienterede værktøjer, mens analyse- eller BI-teams offentliggør kuraterede guldmodeller til Fabric data warehouse. Denne tilgang giver tydelige Lakehouse-forfinelser og lagerservicegrænser.

Hvor dbt passer ind: dbt kan eje Lakehouse-transformationer, Warehouse Gold-modeller eller begge dele gennem klart adskilte projekter eller jobs. Hold hvert projekt tilpasset dets adapter, mål og ejerskabsgrænse.

Hvor Fabric passer: Lakehouse tilbyder fil-native opbevaring og forfinelse. Warehouse leverer relationel service. Pipelines håndhæver afhængigheder mellem transformationsfaser.

Hvorfor vælge det

  • Lader dataingeniørteams bruge Lakehouse til Delta-orienteret forfining, mens analyse- og BI-teams bruger Fabric data warehouse til relationel service.
  • Leverer en kurateret lageroverflade til dimensionel BI.
  • Bevarer detaljerede sølvdata til bredere brug.

Overvejelser

  • Drift af transformationsfaser i Lakehouse og Warehouse kræver færdigheder på tværs af begge motorer og øger kompleksiteten af implementering, test og overvågning.
  • Undgå at implementere den samme regel både i Lakehouse og Warehouse.
  • Definér en klar kontrakt mellem sølv og guld.

Mønster 4: Medaljon kun til søhuset

Behold bronze, sølv og guld i Lakehouse. Brug Fabric Lakehouse-adapteren (dbt-fabricspark) til at udføre dbt-modeller som Spark SQL gennem Fabric Livy API og skriv resultaterne som Delta-tabeller i OneLake.

Arkitekturdiagram, der viser Bronze, Sølv og Guld i Lakehouse, med dbt-transformationer og forbrug af Power BI eller analyse.

Figur 4. Medaljon kun til søhuset.

Brug dette mønster, når: Platformen er Lakehouse-først, data bør forblive i Delta-format, og teamet ønsker dbt-projektstruktur og testning.

Hvor dbt passer: dbt ejer udvalgte Lakehouse-transformationer, tests, afhængigheder og materialiseringer. Beslut om fysisk adskillelse bruger skemaer, separate Lakehouses eller en anden styringsgrænse.

Hvor Fabric passer: OneLake og Lakehouse gemmer dataene. Pipelines orkestrerer indtagelse og transformation. Power BI kan forbruge kuraterede Lakehouse-data via Direct Lake, DirectQuery eller Import, afhængigt af rapporterings- og styringskrav.

Hvorfor vælge det

  • Holder data i Delta-format på tværs af arkitekturen.
  • Reducerer bevægelsen mellem Lakehouse og Warehouse.
  • Passer til søcentrerede og Spark-orienterede driftsmodeller.

Overvejelser

  • Lakehouse SQL analytics-endpointet er skrivebeskyttet og bruges ikke til at skrive dbt-modelresultater. Hvis dine transformationer kræver T-SQL-eksekvering, så brug i stedet Fabric data warehouse-adapteren.
  • Fabric Lakehouse- og Fabric data warehouse-adapterne bruger forskellige eksekveringsmotorer og understøtter forskellige funktioner.
  • Bekræft, at den valgte adapter understøtter SQL-dialekten, materialiseringerne, pakkerne og kommandoerne, som dit projekt kræver.
  • Overvej et relationelt guldlag i Fabric data warehouse til lagercentrerede BI-arbejdsbelastninger.

Vælg en orkestreringsmodel

Når du har valgt et opbevarings- og transformationsmønster, beslutter du, hvordan du skal orkestrere dbt-opgaven. Du kan planlægge opgaven selvstændigt eller køre den som en aktivitet i en Fabric-pipeline.

Arkitekturdiagram over pipeline-workflow, der viser indtagelse, dbt-jobaktivitet, validering, downstream-behandling og opdatering af semantisk model eller rapport.

Figur 5. En Fabric-pipeline, der orkestrerer dbt med indtagelse, validering og downstream-aktiviteter.

Brug native planlægning når:

  • DBT-jobbet kører uafhængigt på en tilbagevendende tidsplan.
  • Jobbet afhænger ikke af opstrøms eller nedstrøms Fabric-aktiviteter.
  • Jobovervågning opfylder de operationelle krav.

Brug en Fabric-pipeline, når:

  • Indtagelse, DBT-udførelse, validering, notifikationer eller nedstrøms behandling skal køre som én arbejdsgang.
  • Arbejdsgangen kræver afhængigheder af succes, fiasko eller fuldførelse.
  • Runtime-indstillinger skal parameteriseres med dynamisk indhold.
  • Teamet ønsker at overvåge den komplette arbejdsgang gennem pipeline-kørselshistorikken.

Fabric-pipelines styrer arbejdsgangsafhængigheder, parametre, fejlstier, notifikationer og konsolideret overvågning. DBT er fortsat ansvarlig for transformationslogik, modeludvælgelse, tests, afhængigheder og materialisering. Pipeline-orkestrering erstatter ikke dbt-projektniveau test eller afhængighedsstyring.

Implementeringsprincipper

  • Definér klart ejerskab for indtagelse, sølvforfining, guldmodellering, orkestrering og semantisk modellering.
  • Behandle dbt-staging, mellemniveau og marts som logiske modelgrupper; de svarer ikke automatisk til Bronze-, Sølv- og Guld-fysiske lag.
  • Undgå at duplikere transformationslogik på tværs af dbt, notesbøger, pipelines og lagrede procedurer.
  • Brug native planlægning til et selvstændigt job og Fabric-pipelines til en multi-aktivitets-arbejdsgang.
  • Tag højde for runtime-adfærd. dbt-job runtime V1.0 understøtter ikke build-caching eller genbrug af artefakter. Hver kørsel kompilerer og eksekverer projektet fra kildekoden. For store projekter skal du inkludere den fulde kompilerings- og eksekveringstid, når du estimerer planlægningsvinduer og SLA'er.

Relateret indhold

  • Last updated on