Delen via

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

  • Artikel

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

Ga naar:

Limieten voor bestanden en opslagplaatsen

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

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

Databricks raadt dat aan in een opslagplaats:

  • Het totale aantal werkruimte-assets en -bestanden is niet groter dan 20.000.

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 2000 Git-mappen per werkruimte hebben. Neem contact op met databricks-ondersteuning als u meer nodig hebt.

Bestanden herstellen die zijn verwijderd uit Git-mappen in uw werkruimte

Werkruimteacties in Git-mappen variëren in de herstelbaarheid van bestanden. Sommige acties staan herstel toe via de map Prullenbak , terwijl andere niet. Bestanden die eerder zijn vastgelegd en naar een externe vertakking zijn gepusht, kunnen worden hersteld met behulp van de Git-doorvoergeschiedenis voor de externe Git-opslagplaats. In deze tabel wordt het gedrag en de herstelbaarheid van elke actie beschreven:

Actie Kan het bestand worden hersteld?
Bestand verwijderen met werkruimtebrowser Ja, uit de map Prullenbak
Een nieuw bestand verwijderen met het dialoogvenster Git-map Ja, uit de map Prullenbak
Een gewijzigd bestand verwijderen met het dialoogvenster Git-map Nee, het bestand is verdwenen
reset (moeilijk) voor niet-doorgevoerde bestandswijzigingen Nee, bestandswijzigingen zijn verdwenen
reset (moeilijk) voor niet-verzonden, nieuw gemaakte bestanden Nee, bestandswijzigingen zijn verdwenen
Schakelen tussen vertakkingen met het dialoogvenster Git-map Ja, vanuit externe Git-opslagplaats
Andere Git-bewerkingen (Doorvoeren en pushen, enzovoort) vanuit het dialoogvenster Git-map Ja, vanuit externe Git-opslagplaats
PATCH bewerkingen die worden bijgewerkt /repos/id vanuit opslagplaatsen-API Ja, vanuit externe Git-opslagplaats

Bestanden die zijn verwijderd uit een Git-map via Git-bewerkingen vanuit de gebruikersinterface van de werkruimte, kunnen worden hersteld vanuit de geschiedenis van de externe vertakking met behulp van de Git-opdrachtregel (of andere Git-hulpprogramma's) als deze bestanden eerder zijn doorgevoerd en naar de externe opslagplaats zijn gepusht. Werkruimteacties variëren in de herstelbaarheid van bestanden. Sommige acties maken herstel mogelijk via de prullenbak, terwijl andere niet. Bestanden die eerder zijn doorgevoerd en naar een externe vertakking zijn gepusht, kunnen worden hersteld via de Git-doorvoergeschiedenis. De onderstaande tabel bevat een overzicht van het gedrag en de herstelbaarheid van elke actie:

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.

Assettypen die worden ondersteund in Git-mappen

Alleen bepaalde Azure Databricks-assettypen worden ondersteund door Git-mappen. Een ondersteund assettype kan worden geserialiseerd, versiebeheerd en naar de back-up van de Git-opslagplaats worden gepusht.

Momenteel zijn de ondersteunde assettypen:

Assettype DETAILS
Bestand Bestanden zijn geserialiseerde gegevens en kunnen alles bevatten, van bibliotheken tot binaire bestanden tot afbeeldingen. Lees wat zijn werkruimtebestanden voor meer informatie ?
Notebook Notebooks zijn specifiek de notebookbestandsindelingen die worden ondersteund door Databricks. Notebooks worden beschouwd als een afzonderlijk Azure Databricks-assettype van bestanden omdat ze niet worden geserialiseerd. Git-mappen bepalen een notebook op basis van de bestandsextensie (zoals .ipynb) of door bestandsextensies in combinatie met een speciale markering in bestandsinhoud (bijvoorbeeld een # Databricks notebook source opmerking aan het begin van .py bronbestanden).
Map Een map is een Azure Databricks-specifieke structuur die geserialiseerde informatie vertegenwoordigt over een logische groepering van bestanden in Git. Zoals verwacht, ervaart de gebruiker dit als een map bij het weergeven van een Azure Databricks Git-map of het openen ervan met de Azure Databricks CLI.
DBSQL-query Databricks SQL (DBSQL)-query's kunnen als IPYNB-notebooks (extensie: .dbquery.ipynb) worden opgeslagen. Git-ondersteuning voor DBSQL-query's vereist dat u de nieuwe SQL Editor-inschakelt. Query's die zijn gemaakt wanneer de nieuwe SQL-editorfunctie is uitgeschakeld, kunnen worden geplaatst in een Git-map, maar kunnen niet worden aangemeld in de achterliggende opslagplaats.

Azure Databricks-assettypen die momenteel niet worden ondersteund in Git-mappen, omvatten het volgende:

  • Waarschuwingen
  • Dashboards (inclusief verouderde dashboards)
  • Experimenten
  • Genie-ruimten

Wanneer u met uw assets in Git werkt, moet u rekening houden met de volgende beperkingen bij het benoemen van bestanden:

  • Een map kan geen notitieblok met dezelfde naam bevatten als een ander notitieblok, bestand of map in dezelfde Git-opslagplaats, zelfs als de bestandsextensie verschilt. (Voor notebooks met bronindeling is .py de extensie voor Python, .scala scala, .sql sql en .r R. Voor NOTEBOOKs met IPYNB-indeling is .ipynbde extensie .) U kunt bijvoorbeeld geen notebook met bronindeling gebruiken met de naam test1.py en een IPYNB-notebook met de naam test1 in dezelfde Git-map, omdat het Python-notebookbestand met de bronindeling (test1.py) wordt geserialiseerd als test1 een conflict.
  • Het teken / wordt niet ondersteund in bestandsnamen. U kunt bijvoorbeeld geen bestand hebben met de naam i/o.py in uw Git-map.

Als u Git-bewerkingen probeert uit te voeren op bestanden met namen met deze patronen, krijgt u het bericht 'Fout bij het ophalen van Git-status'. Als u deze fout onverwacht ontvangt, controleert u de bestandsnamen van de assets in uw Git-opslagplaats. Als u bestanden met namen met deze conflicterende patronen vindt, wijzigt u de naam ervan en probeert u de bewerking opnieuw.

Notitie

U kunt bestaande niet-ondersteunde assets verplaatsen naar een Git-map, maar u kunt geen wijzigingen doorvoeren in deze assets naar de opslagplaats. U kunt geen nieuwe niet-ondersteunde assets maken in een Git-map.

Notitieblokindelingen

Bronindeling notitieblok DETAILS
source Kan elk codebestand zijn met een standaardbestandsachtervoegsel dat de codetaal aangeeft, zoals .py, .scala.ren .sql. 'bron'-notebooks worden behandeld als tekstbestanden en bevatten geen bijbehorende uitvoer wanneer ze worden teruggezet naar een Git-opslagplaats.
IPYNB (Jupyter) IPYNB-bestanden eindigen op .ipynb en kunnen, indien geconfigureerd, uitvoer (zoals visualisaties) van de Databricks Git-map naar de Backing Git-opslagplaats pushen. Een IPYNB-notebook kan code bevatten in elke taal die wordt ondersteund door Databricks-notebooks (ondanks het py deel van .ipynb).

Databricks werkt met twee soorten hoogwaardige Databricks-specifieke notebookindelingen: source en IPYNB (Jupyter). Wanneer een gebruiker een notebook in de source-indeling doorvoert, voert het Azure Databricks-platform een plat bestand door met een taalachtervoegsel, zoals .py, .sql, .scalaof .r. Een source-indeling notebook bevat alleen broncode en bevat geen uitvoer zoals tabelweergaven en visualisaties die de resultaten zijn van het uitvoeren van het notebook.

Het IPYNB (Jupyter)-formaat heeft echter wel uitvoer die eraan is gekoppeld, en deze artefacten worden automatisch naar de Git-opslagplaats verplaatst die de Git-map ondersteunt wanneer het .ipynb-notebook dat ze heeft gegenereerd, wordt gepusht. Als u uitvoer wilt doorvoeren samen met de code, gebruikt u de indeling van het IPYNB-notebook en stelt u de configuratie in zodat een gebruiker het gegenereerde resultaat kan doorvoeren. Als gevolg hiervan biedt IPYNB ook ondersteuning voor een betere weergave-ervaring in Databricks voor notebooks die zijn gepusht naar externe Git-opslagplaatsen via Git-mappen.

IPYNB-notebooks zijn de standaardindeling bij het maken van een nieuw notebook in Databricks. Als u de standaardinstelling wilt wijzigen naar het Databricks-bronformaat, meldt u zich aan bij uw Azure Databricks-werkruimte, klikt u op uw profiel in de rechterbovenhoek van de pagina, klikt u op Instellingen en gaat u naar Ontwikkelaar. Wijzig de standaardindeling van het notitieblok onder de Editor-instellingen rubriek.

de standaardnotitieblokindeling wijzigen in de instellingen voor ontwikkelaars van uw profiel

Als u uitvoer wilt terugsturen naar uw opslagplaats nadat u een notebook hebt uitgevoerd, gebruikt u een IPYNB-notebook (Jupyter). Als u het notebook alleen wilt uitvoeren en beheren in Git, gebruik dan een source-indeling zoals .py.

Lees Databricks-notebooks exporteren en importeren voor meer informatie over ondersteunde notitieblokken.

Notitie

Wat zijn 'uitvoer'?

Uitvoer zijn de resultaten van het uitvoeren van een notebook op het Databricks-platform, inclusief tabelweergaven en visualisaties.

Hoe kan ik vertellen welke indeling een notitieblok gebruikt, met uitzondering van de bestandsextensie?

Boven aan een notebook dat wordt beheerd door Databricks, is er meestal een opmerking met één regel die de indeling aangeeft. Voor een .py bronnotitieblok ziet u bijvoorbeeld een regel die er als volgt uitziet:

# Databricks notebook source

Voor .ipynb bestanden wordt het bestandsachtervoegsel gebruikt om aan te geven dat het de indeling 'ipynb'-notebook is.

IPYNB-notebooks in Git-mappen in Databricks

Ondersteuning voor Jupyter-notebooks (.ipynb bestanden) is beschikbaar in Git-mappen. U kunt opslagplaatsen klonen met .ipynb notebooks, ermee werken in Azure Databricks en deze vervolgens doorvoeren en pushen als .ipynb notebooks. Metagegevens, zoals het notebookdashboard, blijven behouden. Beheerders kunnen bepalen of uitvoer kan worden doorgevoerd of niet.

Doorvoeren .ipynb van notebookuitvoer toestaan

De beheerdersinstelling voor Git-mappen staat standaard niet toe dat .ipynb notebookuitvoer wordt doorgevoerd. Werkruimtebeheerders kunnen deze instelling wijzigen:

  1. Ga naar Werkruimte-instellingen >voor beheerders.

  2. Selecteer Onder Git-mappen > Toestaan dat Git-mappen IPYNB-uitvoer exporteren de optie Toestaan: IPYNB-uitvoer kan worden ingeschakeld.

    Beheerconsole: Git-mappen toestaan OM IPYNB-uitvoer te exporteren.

Belangrijk

Wanneer uitvoer wordt opgenomen, blijven de visualisatie- en dashboardconfiguraties behouden met de .ipynb-bestandsindeling.

Doorvoeringen voor IPYNB-notebookuitvoerartefacten beheren

Wanneer u een .ipynb bestand doorvoert, maakt Databricks een configuratiebestand waarmee u kunt bepalen hoe u uitvoer doorvoert: .databricks/commit_outputs.

  1. Als u een .ipynb notebookbestand hebt maar geen configuratiebestand in uw opslagplaats, opent u de modale Git-status.

  2. Klik in het meldingsdialoogvenster op Commit_outputs bestand maken.

    Gebruikersinterface voor doorvoer van notitieblok: knop Commit_outputs bestand maken.

U kunt ook configuratiebestanden genereren vanuit het menu Bestand . Het menu Bestand bevat een besturingselement waarmee u het configuratiebestand automatisch kunt bijwerken om de opname of uitsluiting van uitvoer voor een specifiek notitieblok op te geven.

  1. Selecteer Uitvoer van doorvoernotitieblokken in het menu Bestand.

    Notebook-editor: Notebooks doorvoeren voert de status en het besturingselement uit.

  2. Bevestig uw keuze in het dialoogvenster om notebookuitvoer door te voeren.

    Dialoogvenster Notebooks doorvoeren.

Een bronnotitieblok converteren naar IPYNB

U kunt een bestaand bronnotitieblok in een Git-map converteren naar een IPYNB-notebook via de Gebruikersinterface van Azure Databricks.

  1. Open een bronnotitieblok in uw werkruimte.

  2. Selecteer Bestand in het werkruimtemenu en selecteer vervolgens Notitieblokindeling wijzigen [bron]. Als het notebook al de IPYNB-indeling heeft, is [bron] [ipynb] in het menu-element.

    Het menu Werkruimtebestand, uitgevouwen, met de optie Notitieblokindeling wijzigen.

  3. Selecteer 'Jupyter notebook format (.ipynb)' in het modale dialoogvenster en klik op Wijzigen.

    Het modale dialoogvenster waarin u de INDELING van het IPYNB-notebook kunt selecteren.

U kunt ook het volgende doen:

  • .ipynb Nieuwe notitieblokken maken.
  • Diffs weergeven als codeverschil (codewijzigingen in cellen) of onbewerkte diff (codewijzigingen worden weergegeven als JSON-syntaxis, waaronder notebookuitvoer als metagegevens).

Lees Databricks-notebooks exporteren en importeren voor meer informatie over de soorten notebooks die worden ondersteund in Azure Databricks.

Veelgestelde vragen: Configuratie van Git-mappen

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 assettypen die worden ondersteund in 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

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 heeft er toegang 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 met 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

Notebook MLflow-experimenten die zijn gemaakt met databricks-taken met broncode in een externe opslagplaats , worden opgeslagen in een tijdelijke opslaglocatie. Deze experimenten blijven in eerste instantie behouden na de uitvoering van de werkstroom, maar lopen het risico dat ze later worden verwijderd tijdens het gepland verwijderen van bestanden in tijdelijke opslag. Databricks raadt aan om MLflow-experimenten van werkruimten te gebruiken met Jobs en externe Git-bronnen.

Waarschuwing

Telkens wanneer u overschakelt naar een vertakking die het notebook niet bevat, loopt u het risico dat de bijbehorende MLflow-experimentgegevens verloren gaan. 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 Git gebruiken met taken voor meer informatie.

Resources

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