Implementatiepijplijnen en Git-integratie van Lakehouse

Het Lakehouse kan worden geïntegreerd met de mogelijkheden voor levenscyclusbeheer in Microsoft Fabric en biedt een gestandaardiseerde samenwerking tussen alle leden van het ontwikkelteam gedurende het hele leven van het product. Levenscyclusbeheer vereenvoudigt een effectief productversie- en releaseproces door voortdurend functies en bugfixes in meerdere omgevingen te leveren. Zie Wat is levenscyclusbeheer in Microsoft Fabric? voor meer informatie.

Wat wordt bijgehouden in git- en implementatiepijplijnen?

De volgende tabel bevat een overzicht van het Lakehouse-item en de subitems en de bijbehorende ondersteuning in met Git verbonden werkruimten en implementatiepijplijnen.

Opt-In ervaring voor objecttypen

Lakehouse biedt een opt-in-ervaring waarmee de traceringsobjecttypen in git- en implementatiepijplijnen worden ingeschakeld of uitgeschakeld. Als u de ervaring wilt inschakelen, gaat u naar Lakehouse-instellingen en schakelt u de gewenste objecttypen in die moeten worden bijgehouden.

Deze functie biedt om twee redenen de volgende voordelen:

• Bied flexibiliteit voor ontwikkelteams om te kiezen welke objecttypen worden bijgehouden in git- en implementatiepijplijnen op basis van hun specifieke behoeften en werkstromen. Teams kan objecttypen organiseren via externe hulpprogramma's of scripts. Sommige objecttypen zijn mogelijk niet relevant voor alle fasen in een implementatiepijplijn.
• Introduceer geleidelijk nieuwe objecttypen voor het bijhouden, zodat teams bestaande werkstromen en automatiseringen kunnen aanpassen voordat ze zich aanmelden voor meer objecttypen. Dit beschermt tegen mogelijke onderbrekingen van bestaande werkstromen en automatiseringen.

Het volgende gedrag wordt toegepast bij het kiezen voor of tegen het bijhouden van objecttypen:

• Nadat u zich hebt aangemeld om een objecttype bij te houden dat niet eerder is bijgehouden en wijzigingen in Git synchroniseert, wordt de huidige metagegevensstatus van dat objecttype geserialiseerd en opgeslagen in Git. Toekomstige wijzigingen in dat objecttype worden bijgehouden en gesynchroniseerd in workspaces binnen deployment pipelines.
• Nadat u hebt besloten om het bijhouden van een objecttype dat eerder werd bijgehouden te stoppen, worden de metadata van het objecttype niet langer geserialiseerd of in git opgeslagen. Toekomstige wijzigingen in dat objecttype worden niet bijgehouden of gesynchroniseerd in werkruimten binnen de implementatiepijplijnen. De bestaande metagegevens in Git worden verwijderd.
• Nieuwe lakehouses worden gemaakt met alle objecttypen die standaard zijn gekozen, met uitzondering van de objecten in de preview-status.
• Bestaande lakehouses behouden hun huidige status van objecttypen, tenzij de gebruiker deze wijzigt.

De ALM-traceringsdefinities worden opgeslagen in een bestand met de naam alm.settings.json onder de map Lakehouse in Git. Deze configuraties kunnen rechtstreeks in de Git-opslagplaats worden gewijzigd en geversied door het alm.settings.json bestand te wijzigen en deze wijzigingen vervolgens weer toe te passen op de werkruimte.

Git-integratie van Lakehouse

Lakehouse is een item dat zowel metagegevens als gegevens bevat waarnaar wordt verwezen in meerdere objecten in de werkruimte. Lakehouse bevat verwijzingen naar tabellen, mappen en snelkoppelingen als primaire beheerbare gegevenscontaineritems. Vanuit het perspectief van een ontwikkelingswerkstroom kunnen de volgende afhankelijke objecten verwijzen naar een Lakehouse:

• Gegevensstromen en pijplijnen
• Spark-taakdefinities
• Notebooks
• Semantische modellen en Power BI

De metagegevens van het SQL Analytics-eindpunt zijn gerelateerd aan een Lakehouse en worden standaard beheerd door het Git-updateproces. Omdat principegegevens niet worden bijgehouden in Git, worden alleen metagegevens bijgehouden.

Git-weergave

De volgende lakehouse-informatie wordt geserialiseerd en bijgehouden in een met Git verbonden werkruimte:

• Weergavenaam
• Beschrijving
• Logische guid

Integratiemogelijkheden voor Lakehouse-artefacten met Git en implementatiepijplijnen

De volgende mogelijkheden zijn beschikbaar:

• Serialisatie van de metagegevens van het Lakehouse-artefactobject naar een Git JSON-weergave.
• Pas wijzigingen rechtstreeks toe of gebruik pull-aanvraag om wijzigingen in upstream- of downstreamwerkruimten en vertakkingen te beheren.
• De naam van lakehouses wordt bijgehouden in Git. Als u een hernoemd Lakehouse bijwerkt, wordt ook de naam van het SQL Analytics-eindpunt gewijzigd.
• Er wordt geen actie toegepast op metagegevens van tabellen en mappenen gegevens van deze items blijven altijd behouden.
• metagegevens van OneLake Shortcuts blijven behouden in Git.

Het Lakehouse wordt ondersteund in implementatiepijplijnen voor levenscyclusbeheer van Microsoft Fabric. Hiermee worden best practices voor omgevingssegmentatie mogelijk.

Integratiemogelijkheden van Lakehouse-implementatiepijplijnen:

• Implementatie in ontwikkel-, test- en productiewerkruimten.
• Lakehouse kan worden verwijderd als een afhankelijk object bij de implementatie. Het toewijzen van verschillende Lakehouses binnen de context van de implementatiepijplijn wordt ook ondersteund.

  • Als er niets wordt opgegeven tijdens de configuratie van de implementatiepijplijn, wordt er een nieuw leeg Lakehouse-object met dezelfde naam gemaakt in de doelwerkruimte. Notebook- en Spark-taakdefinities worden opnieuw toegewezen om te verwijzen naar het nieuwe Lakehouse-object in de nieuwe werkruimte.

  • Als de Lakehouse-afhankelijkheid is geconfigureerd om te verwijzen naar een ander Lakehouse tijdens de configuratietijd van de implementatiepijplijn, zoals de upstream Lakehouse, wordt er nog steeds een nieuw Lakehouse-object met dezelfde naam gemaakt in de doelwerkruimte, maar blijven verwijzingen naar notebooks en Spark-taakdefinities behouden tot een ander Lakehouse zoals aangevraagd.

  • SQL Analytics-eindpunten en semantische modellen worden ingericht als onderdeel van de Lakehouse-implementatie.

• Updates voor De naam van Lakehouse kunnen worden gesynchroniseerd tussen werkruimten in een context van een implementatiepijplijn.

Integratiemogelijkheden voor Git- en implementatiepijplijnen in OneLake Shortcuts

Wanneer u Git-integratie met Lakehouse gebruikt, worden metagegevens van OneLake Shortcuts bijgehouden in Git. De volgende mogelijkheden zijn beschikbaar voor Git-integratie:

• Snelkoppelingsdefinities in zowel de sectie Tabellen als Bestanden worden opgeslagen in een bestand met de naam shortcuts.metadata.json onder de map Lakehouse in Git.
• De volgende bewerkingen worden ondersteund en automatisch bijgehouden: toevoegen, verwijderen en bijwerken van snelkoppelingen.
• De bewerkingen kunnen rechtstreeks worden uitgevoerd in de gebruikersinterface van Fabric of in de Git-opslagplaats door het shortcuts.metadata.json-bestand te wijzigen.
• Snelkoppelingen met interne doelen (OneLake Shortcuts) worden automatisch bijgewerkt tijdens git-synchronisatie. Opdat de snelkoppeling geldig is, moeten deze verwijzingen geldige doelstellingen zijn binnen de werkruimte. Als de doelobjecten ongeldig zijn voor snelkoppelingen zoals gedefinieerd in de sectie Lakehouse-tabellen, worden deze snelkoppelingen verplaatst naar de sectie Unidentified totdat de verwijzingen zijn opgelost.

Wanneer u implementatiepijplijnen met Lakehouse gebruikt, worden metagegevens van OneLake Shortcuts geïmplementeerd in fasen in de pijplijn. De volgende mogelijkheden zijn beschikbaar voor implementatiepijplijnen:

• Snelkoppelingsdefinities worden gesynchroniseerd tussen fasen in de implementatiepijplijnen.
• Snelkoppelingen met externe doelstellingen (ADLS Gen2, S3, enzovoort) zijn in alle stadia na de implementatie hetzelfde.
• Snelkoppelingen met interne doelen (OneLake-snelkoppelingen) in dezelfde werkruimte worden automatisch opnieuw toegewezen tussen fasen. Snelkoppelingen die zijn gericht op datawarehouse en Semantische modellen, worden niet opnieuw toegepast tijdens de implementatie. Tabellen, mappen en bestanden worden niet gemaakt in de doelwerkruimte. Om de snelkoppeling geldig te maken, moeten deze referenties na de implementatie in de doel-werkruimte worden gemaakt.
• In het scenario dat dezelfde snelkoppeling gericht moet worden op verschillende locaties in verschillende fasen. In Ontwikkeling verwijst men bijvoorbeeld naar een specifieke map in Amazon S3 en in Productie naar een andere map in ADLS Gen2. De aanbevolen methode is om variabelen te gebruiken in de snelkoppelingsdefinitie. Lees het artikel Wat is een variabelebibliotheek? (preview) voor meer informatie over de variabelebibliotheek en hoe u deze effectief kunt gebruiken in Microsoft Fabric. Een andere optie is; na de implementatie moet u de Definitie van OneLake Shortcut handmatig bijwerken in Lakehouse of rechtstreeks gebruikmaken van OneLake-API's.

Functionaliteiten voor OneLake-gegevensbeveiligingsroltoegang

• Rollendefinities voor OneLake Security Data Access worden opgeslagen in een bestand met de naam data-access-roles.json onder de map Lakehouse in Git. Wijzigingen kunnen rechtstreeks in de Git-opslagplaats worden aangebracht door het data-access-roles.json bestand te wijzigen en deze wijzigingen vervolgens weer toe te passen op de werkruimte.
• De volgende bewerkingen worden automatisch ondersteund en bijgehouden: toevoeging, verwijdering en updates van Data Access-rollen.
• Alleen gebruikers met beheerders- of lidrollen kunnen definities van beveiligingsrollen synchroniseren met Git.

De volgende tabel beschrijft het gedrag van OneLake Security Data Access-rollen tijdens git-synchronisatie- en implementatiepijplijnbewerkingen op basis van de configuraties van de bron- en doelwerkruimte:

Gerelateerde inhoud

• Wat is levenscyclusbeheer in Microsoft Fabric?
• Zelfstudie: Levenscyclusbeheer in Fabric
• Inleiding tot Git-integratie
• Inleiding tot implementatiepijplijnen