Dela via

Lakehouse-distributionspipelines och git-integrering (förhandsversion)

  • Artikel

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?.

Viktigt!

Den här funktionen är i förhandsversion.

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 tabeller, mappar och genvägar som primära hanterbara datacontainerobjekt. Ur ett utvecklingsarbetsflödesperspektiv kan följande beroende objekt referera till ett Lakehouse:

Standard-semantisk modell och 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:

  • Display name
  • 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 spåras i git i den aktuella upplevelsen. -tabeller (Delta och icke-Delta) och filer i avsnittet Mappar spåras och versionhanteras inte i git-.

Lakehouse git-integreringsfunktioner

Följande funktioner är tillgängliga:

  • Serialisering av Lakehouse-objektmetadata 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. Om du uppdaterar ett omdöpt lakehouse byter du även namn på standard-semantisk datamodell och SQL Analytics-slutpunkt.
  • 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.

Git-integreringsfunktioner för Onelake-genvägar

  • 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-synkronisering. 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 i arbetsytan. Alla genvägar i arbetsytan skapas, uppdateras eller tas bort baserat på inkommande tillstånd från git.

Lakehouse i distributionspipelines

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.

  • Inget objekt i Lakehouse skrivs över.

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

OneLake-genvägar i distributionspipelines

  • Genvägsdefinitioner synkroniseras mellan faser i distributionspipelinesarna.
  • Genvägar med externa mål (ADLS Gen2, S3 osv.) är desamma i alla steg efter distributionen.
  • 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. Efter distributionen uppdaterar du OneLake Shortcut-definitionen i Lakehouse eller direkt med onelake-API:er.

Viktigt!

Utplacering åsidosätter tillståndet för genvägar i målarbetsytan. Alla genvägar i måldataplattformen uppdateras eller tas bort baserat på statusen i källdataplattformen. Nya genvägar skapas i mål-lakehouse. Klicka alltid på "granska ändringar" för att förstå de ändringar som ska distribueras mellan käll- och målarbetsytor.

Relaterat innehåll