Azure Databricks Git-maplimieten en -verwijzing

Op deze pagina worden de groottelimieten, ondersteunde functies, beveiligingsoverwegingen en CI/CD-gedrag voor Databricks Git-mappen beschreven. Zie Resourcelimieten voor algemene Databricks-resourcelimieten. Zie Ondersteunde assettypen in Git-mappen voor meer informatie over ondersteunde assettypen in Git-mappen.

Limieten voor bestanden en opslagplaatsen

Azure Databricks dwingt geen limiet af voor de grootte van de opslagplaats. De volgende limieten zijn echter van toepassing:

• Werkbranches zijn beperkt tot 1 GB.
• U kunt geen bestanden weergeven die groter zijn dan 10 MB in de gebruikersinterface van Azure Databricks.
• Elke Git-bewerking ondersteunt maximaal 2 GB geheugen en 4 GB aan schijfschrijfbewerkingen.
• Afzonderlijke werkruimtebestanden hebben afzonderlijke groottelimieten. Zie Beperkingen.

Databricks raadt aan het totale aantal werkruimte-assets en -bestanden onder 20.000 te houden.

Omdat limieten per bewerking van toepassing zijn, mislukt het klonen van een opslagplaats van 5 GB, maar het klonen van een opslagplaats van 3 GB en het toevoegen van 2 GB slaagt later. Als uw opslagplaats deze limieten overschrijdt, ontvangt u mogelijk een foutmelding of een time-out tijdens het klonen, hoewel de bewerking mogelijk nog steeds op de achtergrond wordt voltooid.

Als u met grotere opslagplaatsen wilt werken, probeer dan sparse checkout of Git CLI-opdrachten. Als u tijdelijke bestanden wilt schrijven die niet behouden blijven nadat het cluster is afgesloten, gebruikt u $TEMPDIR. Dit voorkomt dat de limieten voor vertakkingen worden overschreden en biedt betere prestaties dan schrijven naar een werkmap (CWD) in het bestandssysteem van de werkruimte. Zie Waar moet ik tijdelijke bestanden schrijven op Azure Databricks?.

Lokale vertakkingen kunnen maximaal 30 dagen nadat de externe vertakking is verwijderd, in de bijbehorende Git-map blijven staan. Als u een lokale vertakking volledig wilt verwijderen, verwijdert u de opslagplaats.

Grootte van opslagplaats verkleinen

Als uw opslagplaats de maximale grootte overschrijdt vanwege grote bestanden, zal het toevoegen ervan aan .gitignore de grootte van de opslagplaats niet verminderen. Bestanden die al zijn doorgevoerd in Git, blijven in de geschiedenis van de opslagplaats, zelfs wanneer ze worden toegevoegd aan .gitignore.

Ga als volgende te werk om de grootte van de opslagplaats te verkleinen:

• Gebruik Git-hulpprogramma's zoals git filter-repo of BFG-Repo-Cleaner om grote bestanden uit de doorvoeringsgeschiedenis te verwijderen. Hiermee wordt de geschiedenis herschreven en is geforceerd pushen naar uw externe opslagplaats vereist.
• Kloon alleen specifieke directories. Zie De spaarzame checkout-modus configureren.
• Verplaats niet-gerelateerde code naar afzonderlijke opslagplaatsen.

Zie Gevoelige gegevens verwijderen uit een opslagplaats in de documentatie van GitHub voor meer informatie.

Ondersteuning voor Monorepo

Databricks raadt af om Git-mappen te maken die gebaseerd zijn op monorepos—grote Git-opslagplaatsen van een enkele organisatie met duizenden bestanden over veel projecten. Het klonen van een monorepo kan groter zijn dan geheugen- en schijflimieten voor Git-mappen en trage Git-bewerkingen. Als uw opslagplaats meerdere projecten bevat, kunt u overwegen deze te splitsen of een sparse checkout te gebruiken om te beperken welke mappen worden gekloond. Zie De spaarzame checkout-modus configureren.

Configuratie

Niet alle standaard Git-functies werken in Git-mappen en inhoud wordt anders opgeslagen dan in een lokale kloon. In de volgende onderwerpen wordt uitgelegd hoe opslag werkt, welke servers worden ondersteund en hoe functies zoals .gitignore en submodules zich gedragen.

Repository-inhoudopslag

Azure Databricks kloont de inhoud van de repository tijdelijk naar schijf in het besturingsvlak. In de database van het besturingsvlak worden notebookbestanden opgeslagen zoals die in de hoofdwerkruimte. Niet-notebookbestanden worden maximaal 30 dagen op schijf opgeslagen.

On-premises en zelf-hostende Git-servers

Databricks Git-mappen ondersteunen GitHub Enterprise, Bitbucket Server, Azure DevOps Server en GitLab Zelfbeheerd als de server toegankelijk is via internet. Zie voor on-premises integratie Git Proxy Server voor Git-mappen.

Neem contact op met uw Azure Databricks accountteam om te integreren met een Bitbucket-server, GitHub Enterprise Server of een zelfbeheerd GitLab-exemplaar dat niet toegankelijk is voor internet.

Ondersteunde assettypen

Zie Ondersteunde assettypen in Git-mappen voor meer informatie over ondersteunde assettypen.

Ondersteuning voor .gitignore-bestanden

Git-mappen ondersteunen .gitignore bestanden. Als u wilt voorkomen dat Git een bestand bijhoudt, voegt u de bestandsnaam (inclusief extensie) toe aan een .gitignore bestand. Maak een bestand of gebruik een bestaand bestand dat is gekloond vanuit uw externe opslagplaats.

.gitignore werkt alleen voor niet-bijgehouden bestanden. Als u een al doorgevoerd bestand toevoegt aan .gitignore, wordt het niet uit de Git-geschiedenis verwijderd en verkleint de opslagplaats niet. Als u vastgelegde bestanden wilt verwijderen, zie De grootte van de opslagplaats verkleinen.

Ondersteuning voor Git-submodules

Standaard Git-mappen bieden geen ondersteuning voor Git-submodules, maar Git-mappen met Git CLI-toegang kunnen deze gebruiken. Zie Git CLI-opdrachten gebruiken (bèta).

ondersteuning voor Azure Data Factory

Azure Data Factory (ADF) ondersteunt Git-mappen.

Bronbeheer

Een paar bewerkingen werken anders in Git-mappen dan in een standaard werkstroom voor Git, met name rond notebooks en het verwijderen van vertakkingen.

Wijzigingen in notebookdashboards en vertakkingen

Azure Databricks notitieblokken met bronindelingen bevatten geen dashboardgegevens.

Als u dashboards wilt behouden, wijzigt u de indeling van het notitieblok in .ipynb (Jupyter-indeling), die standaard dashboard- en visualisatiedefinities ondersteunt. Om visualisatiegegevens te behouden, slaat u het notebook op met de uitvoer.

Zie Uitvoerdoorvoeringen voor IPYNB-notebooks beheren.

Ondersteuning voor het samenvoegen van takken

Git-mappen ondersteunen het samenvoegen van vertakkingen. U kunt ook een pull-aanvraag maken en samenvoegen via uw Git-provider.

Vertakkingen verwijderen

Als u een vertakking wilt verwijderen, moet u in uw Git-provider werken.

Python afhankelijkheidsvolgorde

Python bibliotheken in een Git-map voorrang hebben op bibliotheken die elders zijn opgeslagen. Als er bijvoorbeeld een bibliotheek is geïnstalleerd op uw Databricks-rekenproces en er een bibliotheek met dezelfde naam in een Git-map bestaat, wordt de Git-mapbibliotheek geïmporteerd. Zie Python bibliotheekvoorrang.

Beveiliging, verificatie en tokens

Azure Databricks slaat Git-referenties op in het besturingsvlak, niet in uw lokale omgeving. In de volgende onderwerpen wordt beschreven hoe de inhoud van Git-mappen wordt versleuteld, hoe tokens worden opgeslagen en gecontroleerd, en wat u moet doen als u verificatieproblemen ondervindt.

Probleem met een voorwaardelijk toegangsbeleid (CAP) voor Microsoft Entra ID

Mogelijk krijgt u de foutmelding 'Toegang geweigerd' bij het klonen van een opslagplaats als:

• Uw Azure Databricks werkruimte maakt gebruik van Azure DevOps met Microsoft Entra ID-verificatie.
• U hebt beleid voor voorwaardelijke toegang ingeschakeld in Azure DevOps en een Microsoft Entra ID beleid voor voorwaardelijke toegang.

U kunt dit oplossen door een uitsluiting toe te voegen aan het beleid voor voorwaardelijke toegang (CAP) voor Azure Databricks IP-adressen of gebruikers.

Zie Beleid voor voorwaardelijke toegang voor meer informatie.

Toegangslijst met Microsoft Entra ID-tokens

Als u Microsoft Entra ID gebruikt voor verificatie met Azure DevOps, beperkt de standaard acceptatielijst Git-URL's tot:

• dev.azure.com
• visualstudio.com

Voor meer informatie, zie toegestane lijsten van git-URL's.

Git-mapversleuteling

Azure Databricks versleutelt inhoud van Git-mappen met behulp van een standaardsleutel. Door de klant beheerde sleutels worden alleen ondersteund voor het versleutelen van Git-referenties.

GitHub tokenopslag en toegang

• In het Azure Databricks besturingsvlak worden verificatietokens opgeslagen. Werknemers hebben alleen toegang tot hen via gecontroleerde tijdelijke referenties.
• Azure Databricks registreert het aanmaken en verwijderen van tokens, maar niet het gebruik ervan. Met logboekregistratie van Git-bewerkingen kunt u het gebruik van tokens controleren door de Azure Databricks toepassing.
• GitHub Enterprise controleert het tokengebruik. Andere Git-services bieden mogelijk ook servercontrole.

GPG-ondertekening doorvoeren

Git-directories bieden geen ondersteuning voor GPG-ondertekening van commits.

SSH-ondersteuning

Git-mappen ondersteunen alleen HTTPS, niet SSH.

Azure DevOps fouten in meerdere tenants

Wanneer u verbinding maakt met DevOps in een afzonderlijke tenancy, ziet u mogelijk Unable to parse credentials from Azure Active Directory account. Als het Azure DevOps project zich in een andere Microsoft Entra ID tenancy bevindt dan Azure Databricks, gebruikt u een Azure DevOps-toegangstoken. Zie persoonlijk toegangstoken.

CI/CD en MLOps

Als u taken uitvoert op bestanden in een Git-map, moet u rekening houden met hoe Git-bewerkingen invloed kunnen hebben op de notebookstatus en MLflow-experimenten op manieren die mogelijk niet duidelijk zijn.

Binnenkomende wijzigingen maken de staat van het notitieblok leeg

Git-bewerkingen die de broncode van notebooks wijzigen, leiden tot verlies van notebookstatus, inclusief celuitvoer, opmerkingen, versiegeschiedenis en widgets. Bijvoorbeeld, git pull kan worden gebruikt om de broncode van het notitieblok te wijzigen, waardoor het bestaande notitieblok moet worden overschreven door Git-mappen. Bewerkingen zoals git commit, pushof het maken van een nieuwe vertakking hebben geen invloed op de broncode en behouden de notebookstatus.

MLflow-experimenten in Git-mappen

Er zijn twee soorten MLflow-experimenten: werkruimte en notebook. Zie Trainingsuitvoeringen organiseren met MLflow-experimenten.

• Werkruimteexperimenten: U kunt geen MLflow-experimenten voor werkruimten maken in Git-mappen. Log MLflow wordt uitgevoerd naar een experiment dat is gemaakt in een gewone werkruimtemap. Gebruik een gedeelde werkruimtemap voor samenwerking met meerdere gebruikers.

• Notebookexperimenten: U kunt notebookexperimenten maken in een Databricks Git-map. Als u uw notebook als bestand .ipynb in broncodebeheer controleert, voert MLflow logboeken uit naar een automatisch gemaakt experiment. Broncodebeheer voert geen controle uit op het experiment of de uitvoeringen ervan. Zie Notitieblokexperiment maken.

Gegevensverlies voorkomen in MLflow-experimenten

Notebook MLflow-experimenten die met Lakeflow-jobs met broncode in een externe repository zijn gemaakt, worden in tijdelijke opslag opgeslagen. Deze experimenten blijven aanvankelijk behouden na de uitvoering van de werkstroom, maar lopen het risico om tijdens de geplande opschoning te worden verwijderd. Databricks raadt aan om MLflow-experimenten van werkruimten te gebruiken met Jobs en externe Git-bronnen.

Taken uitvoeren tijdens Git-bewerkingen

Tijdens een Git-bewerking kunnen sommige notebooks worden bijgewerkt terwijl andere nog niet zijn, wat onvoorspelbaar gedrag veroorzaakt.

Als notebook Anotebook Z oproept via %run en een taak wordt gestart tijdens een Git-bewerking, kan de taak de meest recente versie van notebook A uitvoeren met een oudere versie van notebook Z. De taak kan mislukken of notebooks uitvoeren van verschillende commits.

Om dit te voorkomen, configureert u taaktaken om uw Git-provider te gebruiken als de bron in plaats van een werkruimtepad. Zie Git gebruiken met Lakeflow-taken.

Volgende stappen 

• Fouten in Git-mappen oplossen
• Git-mappen maken en beheren
• Git-integratie instellen voor Git-mappen