Limieten en veelgestelde vragen over Git-integratie met Databricks Git-mappen

Databricks Git-mappen en Git-integratie hebben limieten die zijn opgegeven in de volgende secties. Zie Databricks-limieten voor algemene informatie.

Limieten voor grootte van bestanden en opslagplaatsen

Azure Databricks dwingt geen limiet af voor de grootte van een opslagplaats. Echter:

• Werkbranches zijn beperkt tot 200 MB.
• Afzonderlijke werkruimtebestanden zijn onderworpen aan een afzonderlijke groottelimiet. Lees beperkingen voor meer informatie.
• Bestanden die groter zijn dan 10 MB, kunnen niet worden weergegeven in de Gebruikersinterface van Azure Databricks.

Databricks raadt dat aan in een opslagplaats:

• Het totale aantal bestanden dat niet groter is dan 10.000.
• Het totale aantal notitieblokken is niet groter dan 5000.

Voor elke Git-bewerking is het geheugengebruik beperkt tot 2 GB en schijfschrijfbewerkingen zijn beperkt tot 4 GB. Omdat de limiet per bewerking is, krijgt u een fout als u probeert een Git-opslagplaats te klonen die 5 GB in huidige grootte heeft. Als u echter een Git-opslagplaats kloont die in één bewerking 3 GB groot is en er later 2 GB aan toevoegt, slaagt de volgende pull-bewerking.

Mogelijk ontvangt u een foutbericht als uw opslagplaats deze limieten overschrijdt. U ontvangt mogelijk ook een time-outfout wanneer u de opslagplaats kloont, maar de bewerking kan op de achtergrond worden voltooid.

Als u wilt werken met een opslagplaats die groter is dan de limieten, probeert u het uitchecken te parseren.

Als u tijdelijke bestanden moet schrijven die u niet wilt behouden nadat het cluster is afgesloten, schrijft u de tijdelijke bestanden om te $TEMPDIR voorkomen dat de limieten voor vertakkingen worden overschreden en betere prestaties opleveren dan schrijven naar de huidige werkmap (CWD) als de CWD zich in het bestandssysteem van de werkruimte bevindt. Zie Waar moet ik tijdelijke bestanden schrijven in Azure Databricks? voor meer informatie.

Maximum aantal Git-mappen per werkruimte

U kunt maximaal 10.000 Git-mappen per werkruimte hebben. Neem contact op met databricks-ondersteuning als u meer nodig hebt.

Ondersteuning voor Monorepo

Databricks raadt u aan om geen Git-mappen te maken die worden ondersteund door monorepos, waarbij een monorepo een grote Git-opslagplaats met één organisatie is met veel duizenden bestanden in veel projecten.

Configuratie van Git-map

Waar wordt azure Databricks-opslagplaatsinhoud opgeslagen?

De inhoud van een opslagplaats wordt tijdelijk gekloond op schijf in het besturingsvlak. Azure Databricks-notebookbestanden worden opgeslagen in de database van het besturingsvlak, net als notebooks in de hoofdwerkruimte. Niet-notebookbestanden worden maximaal 30 dagen op schijf opgeslagen.

Ondersteunen Git-mappen on-premises of zelf-hostende Git-servers?

Databricks Git-mappen ondersteunen GitHub Enterprise, Bitbucket Server, Azure DevOps Server en zelfbeheerde GitLab-integratie, als de server toegankelijk is via internet. Lees Git Proxy Server voor Git-mappen voor Git-mappen voor meer informatie over het integreren van Git-mappen met een on-premises Git-server.

Als u wilt integreren met een Bitbucket Server, GitHub Enterprise Server of een zelfbeheerd GitLab-abonnementexemplaren die niet toegankelijk zijn voor internet, neemt u contact op met uw Azure Databricks-accountteam.

Welke Databricks-assettypen worden ondersteund door Git-mappen?

Lees Bestandsassets beheren in Databricks Git-mappen voor meer informatie over ondersteunde assettypen.

Ondersteunen .gitignore Git-mappen bestanden?

Ja. Als u een bestand aan uw opslagplaats toevoegt en deze niet wilt bijhouden door Git, maakt u een bestand of gebruikt u een .gitignore bestand dat is gekloond vanuit uw externe opslagplaats en voegt u de bestandsnaam toe, inclusief de extensie.

.gitignore werkt alleen voor bestanden die nog niet zijn bijgehouden door Git. Als u een bestand toevoegt dat al door Git is bijgehouden aan een .gitignore bestand, wordt het bestand nog steeds bijgehouden door Git.

Kan ik mappen op het hoogste niveau maken die geen gebruikersmappen zijn?

Ja, beheerders kunnen mappen op het hoogste niveau tot één diepte maken. Git-mappen bieden geen ondersteuning voor extra mapniveaus.

Ondersteunen Git-mappen Git-submodules?

Nee U kunt een opslagplaats met Git-submodules klonen, maar de submodule wordt niet gekloond.

Biedt Azure Data Factory (ADF) ondersteuning voor Git-mappen?

Ja.

Bronbeheer

Waarom verdwijnen notitieblokdashboards wanneer ik een andere vertakking trek of uitcheck?

Dit is momenteel een beperking omdat bronbestanden van Azure Databricks-notebook geen dashboardgegevens voor notebooks opslaan.

Als u dashboards in de Git-opslagplaats wilt behouden, wijzigt u de indeling van het notitieblok in .ipynb (de Jupyter-notebookindeling). .ipynb Standaard worden dashboard- en visualisatiedefinities ondersteund. Als u grafiekgegevens (gegevenspunten) wilt behouden, moet u het notebook doorvoeren met uitvoer.

Zie Uitvoer van het doorvoeren van notebooks toestaan voor meer informatie over het doorvoeren .ipynb van .ipynb notebookuitvoer.

Ondersteunen Git-mappen het samenvoegen van vertakkingen?

Ja. U kunt ook een pull-aanvraag maken en samenvoegen via uw Git-provider.

Kan ik een vertakking verwijderen uit een Azure Databricks-opslagplaats?

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

Als een bibliotheek op een cluster is geïnstalleerd en een bibliotheek met dezelfde naam is opgenomen in een map in een opslagplaats, welke bibliotheek wordt geïmporteerd?

De bibliotheek in de opslagplaats wordt geïmporteerd. Zie De prioriteit van de Python-bibliotheek voor meer informatie over bibliotheekprioriteit in Python.

Kan ik de nieuwste versie van een opslagplaats uit Git ophalen voordat ik een taak uitvoert zonder dat ik afhankelijk ben van een extern indelingsprogramma?

Nee Normaal gesproken kunt u dit integreren als een voordoorvoering op de Git-server, zodat elke push naar een vertakking (main/prod) de productieopslagplaats bijwerkt.

Kan ik een opslagplaats exporteren?

U kunt notitieblokken, mappen of een hele opslagplaats exporteren. U kunt geen niet-notebookbestanden exporteren. Als u een hele opslagplaats exporteert, worden niet-notebookbestanden niet opgenomen. Als u wilt exporteren, gebruikt u de workspace export opdracht in de Databricks CLI of gebruikt u de Werkruimte-API.

Beveiliging, verificatie en tokens

Probleem met beleid voor voorwaardelijke toegang (CAP) voor Microsoft Entra ID (voorheen Azure Active Directory)

Wanneer u probeert een opslagplaats te klonen, krijgt u mogelijk het foutbericht 'Geweigerde toegang' wanneer:

• Azure Databricks is geconfigureerd voor het gebruik van Azure DevOps met Microsoft Entra ID-verificatie.
• U hebt beleid voor voorwaardelijke toegang ingeschakeld in Azure DevOps en een beleid voor voorwaardelijke toegang van Microsoft Entra ID.

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

Zie Beleid voor voorwaardelijke toegang voor meer informatie.

Lijst toestaan met Azure AD-tokens

Als u Azure Active Directory (AAD) gebruikt voor verificatie met Azure DevOps, beperkt de standaard acceptatielijst Git-URL's tot:

• dev.azure.com
• visualstudio.com

Zie Acceptatielijsten beperken het gebruik van externe opslagplaatsen voor meer informatie.

Worden de inhoud van Azure Databricks Git-mappen versleuteld?

De inhoud van Azure Databricks Git-mappen wordt versleuteld door Azure Databricks met behulp van een standaardsleutel. Versleuteling met door de klant beheerde sleutels wordt niet ondersteund, behalve wanneer u uw Git-referenties versleutelt.

Hoe en waar worden de GitHub-tokens opgeslagen in Azure Databricks? Wie zou toegang hebben vanuit Azure Databricks?

• De verificatietokens worden opgeslagen in het azure Databricks-besturingsvlak en een Azure Databricks-werknemer kan alleen toegang krijgen via een tijdelijke referentie die wordt gecontroleerd.
• Azure Databricks registreert het maken en verwijderen van deze tokens, maar niet het gebruik ervan. Azure Databricks heeft logboekregistratie waarmee Git-bewerkingen worden bijgehouden die kunnen worden gebruikt om het gebruik van de tokens door de Azure Databricks-toepassing te controleren.
• GitHub Enterprise controleert het gebruik van tokens. Andere Git-services hebben mogelijk ook controle van Git-servers.

Ondersteunen Git-mappen GPG-ondertekening van doorvoeringen?

Nee

Ondersteunen Git-mappen SSH?

Nee, alleen HTTPS.

Fout bij het verbinden van Azure Databricks met een Azure DevOps-opslagplaats in een andere tenancy

Wanneer u verbinding probeert te maken met DevOps in een afzonderlijke tenancy, ontvangt u mogelijk het bericht Unable to parse credentials from Azure Active Directory account. Als het Azure DevOps-project zich in een andere Microsoft Entra ID-tenancy bevindt van Azure Databricks, moet u een toegangstoken van Azure DevOps gebruiken. Zie Verbinding maken naar Azure DevOps met behulp van een DevOps-token.

CI/CD en MLOps

Binnenkomende wijzigingen wissen de status van het notitieblok

Git-bewerkingen die de broncode van het notebook wijzigen, leiden tot verlies van de notebookstatus, inclusief celuitvoer, opmerkingen, versiegeschiedenis en widgets. U kunt bijvoorbeeld git pull de broncode van een notebook wijzigen. In dit geval moeten Databricks Git-mappen het bestaande notebook overschrijven om de wijzigingen te importeren. git commit en push of het maken van een nieuwe vertakking heeft geen invloed op de broncode van het notebook, dus de notebookstatus blijft behouden in deze bewerkingen.

Belangrijk

MLflow-experimenten werken niet in Git-mappen met DBR 14.x of lagere versies.

Kan ik een MLflow-experiment maken in een opslagplaats?

Er zijn twee soorten MLflow-experimenten: werkruimte en notebook. Zie Trainingsuitvoeringen organiseren met MLflow-experimenten voor meer informatie over de twee typen MLflow-experimenten.

In Git-mappen kunt u een MLflow-experiment van beide typen en logboekuitvoeringen aanroepen mlflow.set_experiment("/path/to/experiment") , maar dat experiment en de bijbehorende uitvoeringen worden niet ingecheckt in broncodebeheer.

MLflow-experimenten voor werkruimten

U kunt geen MLflow-experimenten voor werkruimten maken in een Databricks Git-map (Git-map). Als meerdere gebruikers afzonderlijke Git-mappen gebruiken om samen te werken aan dezelfde ML-code, wordt MLflow uitgevoerd naar een MLflow-experiment dat is gemaakt in een gewone werkruimtemap.

Notebook MLflow-experimenten

U kunt notebookexperimenten maken in een Databricks Git-map. Als u uw notebook als een .ipynb bestand in broncodebeheer controleert, kunt u MLflow-uitvoeringen vastleggen in een automatisch gemaakt en gekoppeld MLflow-experiment. Lees voor meer informatie over het maken van notebookexperimenten.

Gegevensverlies voorkomen in MLflow-experimenten

Waarschuwing

Telkens wanneer u overschakelt naar een vertakking die het notebook niet bevat, loopt u het risico dat u de bijbehorende MLFlow-experimentgegevens kwijtraakt. Dit verlies wordt permnanent als de voorgaande vertakking niet binnen 30 dagen wordt geopend.

Als u ontbrekende experimentgegevens vóór het verlopen van 30 dagen wilt herstellen, wijzigt u de naam van het notitieblok terug naar de oorspronkelijke naam, opent u het notitieblok, klikt u op het pictogram 'experiment' in het rechterdeelvenster (hiermee wordt ook de mlflow.get_experiment_by_name() API aangeroepen) en ziet u het herstelde experiment en wordt uitgevoerd. Na 30 dagen worden zwevende MLflow-experimenten opgeschoond om te voldoen aan het AVG-nalevingsbeleid.

Om deze situatie te voorkomen, raadt Databricks u aan de naam van notitieblokken helemaal in opslagplaatsen te voorkomen of als u de naam van een notitieblok wijzigt, klikt u direct na het wijzigen van de naam van een notitieblok op het pictogram 'experiment' in het rechterdeelvenster.

Wat gebeurt er als een notebooktaak wordt uitgevoerd in een werkruimte terwijl een Git-bewerking wordt uitgevoerd?

Op elk moment dat een Git-bewerking wordt uitgevoerd, zijn sommige notebooks in de opslagplaats mogelijk bijgewerkt terwijl andere niet. Dit kan onvoorspelbaar gedrag veroorzaken.

Stel dat notebook A aanroepen worden aanroepen notebook Z met behulp van een %run opdracht. Als een taak die wordt uitgevoerd tijdens een Git-bewerking de meest recente versie van notebook Astart, maar notebook Z nog niet is bijgewerkt, kan de %run opdracht in notebook A de oudere versie van notebook Zstarten. Tijdens de Git-bewerking zijn de notebookstatussen niet voorspelbaar en kan de taak mislukken of uitvoeren notebook A en notebook Z vanuit verschillende doorvoeringen.

Gebruik in plaats daarvan Git-taken (waarbij de bron een Git-provider is en geen werkruimtepad) om deze situatie te voorkomen. Lees versiebeheerde broncode gebruiken in een Azure Databricks-taak voor meer informatie.

Resources

Zie Wat zijn werkruimtebestanden? voor meer informatie over Databricks-werkruimtebestanden.