Del via


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:

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.