Lakehouse-udrulningspipelines og git-integration (prøveversion)
Lakehouse kan integreres med livscyklusstyringsfunktionerne i Microsoft Fabric, hvilket giver et standardiseret samarbejde mellem alle medlemmer af udviklingsteamet gennem hele produktets levetid. Livscyklusstyring faciliterer en effektiv produktversions- og udgivelsesproces ved løbende at levere funktioner og fejlrettelser i flere miljøer. Du kan få mere at vide under Hvad er livscyklusstyring i Microsoft Fabric?.
Vigtigt
Denne funktion er en prøveversion.
Git-integration i Lakehouse
Lakehouse er et element, der indeholder både metadata og data, der refereres til i flere objekter i arbejdsområdet. Lakehouse indeholder tabeller, mapper og genveje som primære elementer i databeholderen, der kan administreres. Fra et udviklingsarbejdsprocesperspektiv kan følgende afhængige objekter referere til et Lakehouse:
- Dataflow ogdatapipelines
- Definitioner af Spark-job
- Notebooks
- Semantiske modeller og Power BI
Standardmetadata for semantiske modeller og SQL-analyseslutpunkter er relateret til et Lakehouse og administreres som standard af git-opdateringsprocessen. Som et princip spores data ikke i git, kun metadata spores.
Git-repræsentation
Følgende lakehouse-oplysninger serialiseres og spores i et arbejdsområde, der er forbundet med Git:
- Display name
- Description
- Logisk GUID
Bemærk
Det sporede logiske GUID er et automatisk genereret id på tværs af arbejdsområder, der repræsenterer et element og dets versionsstyringsrepræsentation.
Vigtigt
Det er kun Lakehouse-objektbeholderartefaktet, der spores i Git i den aktuelle oplevelse. tabeller (Delta og ikke-Delta) og mapper i afsnittet Filer spores og versioneres ikke i git.
Funktioner til git-integration i Lakehouse
Følgende funktioner er tilgængelige:
- Serialisering af Metadata for Lakehouse-objektet til en git JSON-repræsentation.
- Anvend ændringerne direkte, eller brug pullanmodning til at styre ændringer i upstream- eller downstreamarbejdsområder og -forgreninger.
- Omdøbning lakehouses spores i Git. Hvis du opdaterer et omdøbt lakehouse, omdøbes standard-semantisk datamodellen og SQL Analytics-slutpunktet også.
- Der anvendes ingen handling på tabeller og mappers metadata, og dataene for disse elementer bevares altid.
- OneLake-genvejsmetadata bevares i git.
Git-integrationsfunktioner til OneLake-genveje
- Genvejsdefinitioner i både afsnittet Tabeller og Filer gemmes i en fil med navnet
shortcuts.metadata.json
under mappen lakehouse i git. - Følgende handlinger understøttes og spores automatisk: tilføjelse, sletning og opdateringer af genveje.
- Handlingerne kan udføres direkte i Fabric-brugergrænsefladen eller i Git-lageret ved at ændre filen
shortcuts.metadata.json
. - Genveje med interne mål (OneLake-genveje) opdateres automatisk under git-synkronisering. Hvis genvejen skal være gyldig, skal disse referencer være gyldige mål i arbejdsområdet. Hvis målene er ugyldige for genveje, der er defineret i afsnittet lakehouse-tabeller, flyttes disse genveje til sektionen
Unidentified
, indtil referencer er løst.
Vigtigt
Vær forsigtig, når du ændrer egenskaberne for OneLake Genvej direkte i filen shortcuts.metadata.json
. Forkerte ændringer af egenskaberne, specielt GUID'er, kan gøre OneLake-genvejen ugyldig, når der anvendes opdateringer på arbejdsområdet igen.
Vigtigt
En opdatering fra git tilsidesætter tilstanden af genveje i arbejdsområdet. Alle genveje i arbejdsområdet oprettes, opdateres eller slettes på baggrund af den indgående tilstand fra git.
Lakehouse i udrulningspipelines
Lakehouse understøttes i udrulningspipelines til Microsoft Fabric-livscyklusstyring. Det muliggør bedste praksis for segmentering af miljøet.
Integrationsfunktioner til lakehouse-udrulningspipelines:
Udrulning på tværs af udviklings-, test- og produktionsarbejdsområder.
Lakehouse kan fjernes som et afhængigt objekt ved udrulning. Tilknytning af forskellige Lakehouses i konteksten for udrulningspipelinen understøttes også.
Hvis der ikke angives noget under konfigurationen af udrulningspipelinen, oprettes der et nyt tomt Lakehouse-objekt med samme navn i destinationsarbejdsområdet. Definitioner af notesbøger og Spark-job tilknyttes igen for at referere til det nye Lakehouse-objekt i det nye arbejdsområde.
Hvis Lakehouse-afhængigheden er konfigureret til at referere til et andet Lakehouse under konfigurationstiden for udrulningspipelinen, f.eks. upstream Lakehouse, oprettes der stadig et nyt tomt Lakehouse-objekt med samme navn i målarbejdsområdet, men referencer til notesbøger og Spark-jobdefinitioner bevares til et andet Lakehouse efter behov.
SQL Analytics-slutpunkter og semantiske modeller klargøres som en del af Lakehouse-udrulningen.
Intet objekt i Lakehouse overskrives.
Opdateringer af Lakehouse-navnet kan synkroniseres på tværs af arbejdsområder i en kontekst for udrulningspipelinen.
OneLake-genveje i udrulningspipelines
- Genvejsdefinitioner synkroniseres på tværs af faser i udrulningspipelines.
- Genveje med eksterne mål (ADLS Gen2, S3 osv.) er de samme på tværs af alle faser efter udrulningen.
- Genveje med interne mål (OneLake-genveje) i det samme arbejdsområde tilknyttes automatisk på tværs af faser. Genveje, der er målrettet til Data Warehouse og semantiske modeller, tilknyttes ikke igen under udrulningen. Tabeller, mapper og filer oprettes ikke i destinationsarbejdsområdet. Hvis genvejen skal være gyldig, skal disse referencer oprettes i målarbejdsområdet efter udrulningen.
- I scenariet skal den samme genvej målrette forskellige placeringer på forskellige faser. I Udvikling skal du f.eks. pege på en bestemt mappe i Amazon S3 og i Produktion en anden mappe i ADLS Gen2. Efter udrulningen skal du opdatere definitionen af OneLake-genvejen i Lakehouse eller direkte ved hjælp af OneLake-API'er.
Vigtigt
En udrulnings-tilsidesætter tilstanden af genveje i målarbejdsområdet. Alle genvejene i målsøhuset opdateres eller slettes baseret på tilstanden i kildesøhuset. Der oprettes nye genveje i målsøhuset. Klik altid på "gennemse ændringer" for at forstå de ændringer, der installeres mellem kilde- og destinationsarbejdsområder.