Dela via

Lakehouse-distributionspipelines och git-integrering

Lakehouse integreras med livscykelhanteringsfunktionerna i Microsoft Fabric, vilket ger ett standardiserat samarbete mellan alla medlemmar i utvecklingsteamet under hela produktens livslängd. Livscykelhantering underlättar en effektiv produktversions- och lanseringsprocess genom att kontinuerligt leverera funktioner och felkorrigeringar till flera miljöer. Mer information finns i Vad är livscykelhantering i Microsoft Fabric?.

Vad spåras i git- och distributionspipelines?

I följande tabell sammanfattas Lakehouse-objekt och därtill hörande underobjekt samt deras stöd i git-integrerade arbetsytor och distributionspipelines.

Objekt/underobjekt Git Distributionsflöden Versionsstatus Noteringar
Lakehouse-metadata (visningsnamn, beskrivning, logiskt GUID) ✅ Spårat ✅ Spårat GA Identifierare för flera arbetsytor för källkontroll
Metadata för OneLake-genvägar ✅ Spårat ✅ Spårat GA Lagras i shortcuts.metadata.json fil
Externa genvägar: ADLS Gen2, S3, Dataverse och Google Cloud Storage ✅ Spårat ✅ Synkroniseras mellan faser GA Samma mål i alla faser, om de inte mappas om med variabelbiblioteket
Externa genvägar: SharePoint, Azure Blob Storage, OneDrive ❌ Spåras inte ❌ Skrivs inte över Stöds inte Data bevaras alltid under åtgärder
Interna OneLake-genvägar ✅ Spårat ✅ Mappas om automatiskt mellan olika faser GA Kräver giltiga mål i arbetsytan för att bli användbara
Metadata för OneLake Security Data Access Roles ✅ Spårat ✅ Spårat Preview Lagras i data-access-roles.json-filen
Tabeller (Delta och icke-Delta) ❌ Spåras inte ❌ Skrivs inte över Stöds inte Data bevaras alltid under åtgärder
Spark-vyer ❌ Spåras inte ❌ Skrivs inte över Stöds inte Data bevaras alltid under åtgärder
Mappar i filavsnittet ❌ Spåras inte ❌ Skrivs inte över Stöds inte Data bevaras alltid under åtgärder

Opt-In funktion för objekttyper

Lakehouse erbjuder en opt-in-upplevelse som möjliggör eller förhindrar spårning av objekttyper i git- och distributionspipelines. Om du vill aktivera upplevelsen går du till Lakehouse-inställningar och aktiverar önskade objekttyper som ska spåras.

Den här funktionen ger följande fördelar av två skäl:

  • Ge utvecklingsteamen flexibilitet att välja vilka objekttyper som spåras i git- och distributionspipelines baserat på deras specifika behov och arbetsflöden. Teams kanske vill samordna objekttyper via externa verktyg eller skript. Vissa objekttyper kanske inte heller är relevanta för alla steg i en distributionspipeline.
  • Introducera gradvis nya objekttyper för spårning, så att team kan anpassa befintliga arbetsflöden och automatiseringar innan de väljer fler objekttyper. Detta skyddar mot potentiella störningar i befintliga arbetsflöden och automatiseringar.

Skärmbild av användarupplevelse vid opt-in för lakehouse-inställningar.

Följande beteenden tillämpas när du väljer att använda eller inte använda spårning av objekttyper:

  • När du har valt att spåra en objekttyp som inte har spårats tidigare och synkroniserat ändringar i git serialiseras och lagras det aktuella metadatatillståndet för den objekttypen i git. Framtida ändringar av den objekttypen spåras och synkroniseras mellan arbetsytor i distributionspipelines.
  • När du har valt att inte spåra en objekttyp som spårades tidigare, serialiseras eller lagras inte längre objekttypsmetadata i git. Framtida ändringar av objekttypen spåras inte eller synkroniseras inte mellan arbetsytor i distributionspipelines. Befintliga metadata i git tas bort.
  • Nya lakehouses skapas med alla objekttyper som valts som standard, förutom de som är i förhandsversionstillstånd.
  • Befintliga lakehouses behåller sina aktuella objekttypers spårningstillstånd om de inte ändras av användaren.

ALM-spårningsdefinitionerna lagras i en fil med namnet alm.settings.json under mappen lakehouse i git. Dessa konfigurationer kan ändras och versionshanteras direkt i git-lagringsplatsen genom att ändra alm.settings.json filen och sedan tillämpa ändringarna på arbetsytan igen.

Git-integrering i Lakehouse

Lakehouse är ett objekt som innehåller både metadata och data som refereras till i flera objekt på arbetsytan. Lakehouse innehåller referenser till tabeller, mappar och genvägar som primära hanterbara datacontainerobjekt. Ur ett utvecklingsarbetsflödesperspektiv kan följande beroende objekt referera till ett Lakehouse:

SQL-analysslutpunktsmetadata är relaterade till en Lakehouse och hanteras av git-uppdateringsprocessen som standard. Eftersom principdata inte spåras i git spåras endast metadata.

Git-representation

Följande lakehouse-information serialiseras och spåras på en git-ansluten arbetsyta:

  • Visningsnamn
  • beskrivning
  • Logiskt guid

Kommentar

Det spårade logiska guid-objektet är en automatiskt genererad identifierare för flera arbetsytor som representerar ett objekt och dess källkontrollrepresentation.

Viktigt!

Endast Lakehouse-containerartefakten och objekten som refereras till i det första avsnittet i den här artikeln spåras i git i den nuvarande upplevelsen. -tabeller (Delta och icke-Delta) och filer i avsnittet Mappar spåras och versionhanteras inte i git-.

Integreringsfunktioner för Lakehouse-artefakt i git och distributionspipelines

Följande funktioner är tillgängliga:

  • Serialisering av Metadata för Lakehouse-artefaktobjekt till en git JSON-representation.
  • Tillämpa ändringar direkt eller använd pull-begäran för att styra ändringar på uppströms- eller nedströmsarbetsytor och grenar.
  • Byt namn på lakehouses spåras i git. En uppdatering av ett redan omdöpt lakehouse ändrar också namnet på SQL Analytics-slutpunkten.
  • Ingen åtgärd tillämpas på tabeller och mappar metadata, och data för dessa objekt bevaras alltid.
  • Metadata för OneLake-genvägar bevaras i git.

Lakehouse stöds i distributionspipelines för livscykelhantering i Microsoft Fabric. Det möjliggör metodtips för miljösegmentering.

Integreringsfunktioner för Lakehouse-distributionspipelines:

  • Distribution över arbetsytor för utveckling, testning och produktion.
  • Lakehouse kan tas bort som ett beroende objekt vid distributionen. Det finns också stöd för att mappa olika Lakehouses i distributionspipelinekontexten.

    • Om inget anges under konfigurationen av distributionspipelinen skapas ett nytt tomt Lakehouse-objekt med samma namn på målarbetsytan. Notebook- och Spark-jobbdefinitioner mappas om för att referera till det nya Lakehouse-objektet på den nya arbetsytan.

    • Om Lakehouse-beroendet har konfigurerats för att referera till en annan Lakehouse under konfigurationstiden för distributionspipelinen, till exempel det överordnade Lakehouse, skapas fortfarande ett nytt tomt Lakehouse-objekt med samma namn på målarbetsytan, men referenser för Notebooks och Spark-jobbdefinitioner bevaras till ett annat Lakehouse på begäran.

    • SQL Analytics-slutpunkter och semantiska modeller etableras som en del av Lakehouse-distributionen.

  • Uppdateringar av Lakehouse-namnet kan synkroniseras mellan arbetsytor i en distributionspipelinekontext.

Integreringsfunktioner för OneLake-genvägar för git- och distributionspipelines

När du använder git-integrering med Lakehouse spåras OneLake Shortcuts-metadata i git. Följande funktioner är tillgängliga för git-integrering:

  • Genvägsdefinitioner i både avsnittet Tabeller och Filer lagras i en fil med namnet shortcuts.metadata.json under mappen lakehouse i git.
  • Följande åtgärder stöds och spåras automatiskt: tillägg, borttagning och uppdateringar av genvägar.
  • Åtgärderna kan utföras direkt i användargränssnittet för infrastrukturresurser eller i git-lagringsplatsen genom att ändra shortcuts.metadata.json-filen.
  • Genvägar med interna mål (OneLake-genvägar) uppdateras automatiskt under git-synkroniseringen. För att genvägen ska vara giltig måste dessa referenser vara giltiga mål på arbetsytan. Om målobjekten är ogiltiga för genvägar som definierats i avsnittet lakehouse-tabeller flyttas dessa genvägar till avsnittet Unidentified tills referenserna har lösts.

Viktigt!

Var försiktig när du ändrar onelake-genvägsegenskaper direkt i shortcuts.metadata.json-filen. Felaktiga ändringar av egenskaperna, särskilt GUID: er, kan göra OneLake-genvägen ogiltig när uppdateringar tillämpas tillbaka på arbetsytan.

Viktigt!

En uppdatering från git åsidosätter tillståndet för genvägar på arbetsytan. Alla genvägar i arbetsytan skapas, uppdateras eller tas bort baserat på inkommande tillstånd från git.

När du använder distributionspipelines med Lakehouse distribueras OneLake Shortcuts-metadata mellan steg i pipelinen. Följande möjligheter är tillgängliga för distributionspipelines:

  • Genvägsdefinitioner synkroniseras mellan faser i distributionspipelinesarna.
  • Genvägar med externa mål (ADLS Gen2, S3 osv.) är desamma i alla steg efter att de har distribuerats.
  • Genvägar med interna mål (OneLake-genvägar) på samma arbetsyta mappas automatiskt om mellan olika steg. Genvägar som är avsedda för informationslagret och semantiska modeller mappas inte om under distributionen. Tabeller, mappar och filer skapas inte på målarbetsytan. För att genvägen ska vara giltig måste dessa referenser skapas på målarbetsytan efter distributionen.
  • Vid scenarion där samma genväg måste riktas mot olika platser på olika faser. I Utveckling pekar du till exempel på en specifik mapp i Amazon S3 och i Produktion en annan mapp i ADLS Gen2. Den rekommenderade metoden är att använda variabler i genvägsdefinitionen. Mer information om variabelbibliotek och hur du effektivt använder det i Microsoft Fabric finns i biblioteket Vad är en variabel? (förhandsversion) Artikel. Ett annat alternativ är; efter distributionen uppdaterar du onelake-genvägsdefinitionen manuellt i Lakehouse eller direkt med onelake-API:er.

Viktigt!

En driftsättning åsidosätter tillståndet för genvägar i målmiljön. Alla genvägar i måldataplattformen uppdateras eller tas bort baserat på statusen i källdataplattformen. Nya genvägar skapas i mål-lakehouse. Välj alltid "granska ändringar" för att förstå de ändringar som distribueras mellan käll- och målarbetsytor.

Funktioner för åtkomstroller för OneLake Security-data

  • OneLake Security Data Access Roles-definitioner lagras i en fil med namnet data-access-roles.json under mappen lakehouse i git. Ändringar kan göras direkt i git-lagringsplatsen genom att ändra data-access-roles.json filen och sedan tillämpa ändringarna på arbetsytan igen.
  • Följande åtgärder stöds och spåras automatiskt: tillägg, borttagning och uppdateringar av dataåtkomstroller.
  • Endast användare med administratörs- eller medlemsroller kan synkronisera definitioner av säkerhetsroller till git.

I följande tabell beskrivs beteendet för OneLake Security Data Access-roller under git-synkronisering och distributionspipelineåtgärder baserat på konfigurationerna för käll- och målarbetsytan:

Källarbetsyta Målarbetsyta Git-integrering Distributionspipeline beskrivning
DAR + Opt-In aktiverat Nytt mål (inget sjöhus) ✅ Aktivera DAR-spårning på målet ✅ Aktivera DAR-spårning på målet Målarbetsytan aktiveras automatiskt för DAR-spårning
DAR + Opt-In aktiverat DAR-spårning har inaktiverats ✅ Aktivera både DAR-spårning och Opt-In på målet ✅ Aktivera både DAR-spårning och Opt-In på målet Målarbetsytan får båda funktionerna aktiverade automatiskt.
DAR + Opt-In aktiverat DAR aktiverat, Opt-In inaktiverat ⚠️ Uppmana användaren att aktivera Opt-In och DAR (åsidosätta eller avbryta) ❌ Visa fel Git-integrering tillåter användarval; Distributionspipelinen kräver manuell målkonfiguration
DAR + Opt-In aktiverat DAR + Opt-In aktiverat ✅ Normal synkronisering (skapa/uppdatera/ta bort efter behov) ✅ Normal synkronisering (skapa/uppdatera/ta bort efter behov) Standardåtgärd med fullständig synkronisering

Kommentar

När distributionspipelinen visar ett fel måste kunderna manuellt aktivera DAR-spårning på målarbetsytan och stämma av rollerna för att säkerställa att det inte finns några konflikter i dataåtkomstroller innan de fortsätter med distributionen.

Viktigt!

Var försiktig när du ändrar OneLake Security. Endast användare med administratörs- eller medlemsroller kan synkronisera säkerhetsrolldefinitioner till git- eller distributionspipelines.

Viktigt!

Microsoft Entra-medlems-ID:er spåras inte i git på grund av säkerhetsskäl. Under git-uppdateringar och distributionskedjor bevaras medlemmar mellan arbetsytor endast om rollnamnen matchar exakt. Det rekommenderas att vara försiktig när man byter namn på roller, som har medlemmar tilldelade till dem.

Relaterat innehåll

  • Last updated on