Freigeben über

Grenzwerte und häufig gestellte Fragen für die Git-Integration mit Databricks Git-Ordnern

  • Artikel

Databricks Git-Ordner und die Git-Integration weisen Einschränkungen auf, die in den folgenden Abschnitten beschrieben werden. Allgemeine Informationen finden Sie unter Databricks-Limits.

Wechseln Sie zu:

Datei- und Repositorybeschränkungen

Azure Databricks erzwingt keine Begrenzung der Größe eines Repositorys. Allerdings:

  • Arbeitszweige sind auf 1 Gigabyte (GB) begrenzt.
  • Dateien, die größer als 10 MB sind, können nicht in der Azure Databricks-Benutzeroberfläche angezeigt werden.
  • Einzelne Arbeitsbereichsdateien unterliegen einem separaten Größenlimit. Weitere Informationen finden Sie unter Einschränkungen.

Databricks empfiehlt in einem Repository Folgendes:

  • Die Gesamtanzahl aller Arbeitsbereich-Ressourcen und Dateien sollte 20.000 nicht überschreiten.

Bei jedem Git-Vorgang ist die Speicherauslastung auf 2 GB beschränkt, und Datenträgerschreibvorgänge sind auf 4 GB begrenzt. Da der Grenzwert pro Vorgang gilt, wird ein Fehler angezeigt, wenn Sie versuchen, ein Git-Repository zu klonen, das aktuell eine Größe von 5 GB hat. Wenn Sie jedoch ein Git-Repository mit einer Größe von 3 GB in einem Vorgang klonen und später 2 GB hinzufügen, wird der nächste Pullvorgang erfolgreich ausgeführt.

Sie erhalten möglicherweise eine Fehlermeldung, wenn Ihr Repository diese Grenzwerte überschreitet. Sie erhalten möglicherweise auch einen Zeitüberschreitungsfehler, wenn Sie das Repository klonen, aber der Vorgang wird möglicherweise im Hintergrund abgeschlossen.

Wenn Sie mit einem Repository arbeiten möchten, das die Größenbeschränkungen überschreitet, probieren Sie den Befehl sparse-checkout aus.

Wenn Sie temporäre Dateien schreiben müssen, die Sie nach dem Herunterfahren des Clusters nicht beibehalten möchten, können Sie durch das Schreiben der temporären Dateien in $TEMPDIR eine Überschreitung der Grenzwerte für die Branchgröße vermeiden und eine bessere Leistung als beim Schreiben in das aktuelle Arbeitsverzeichnis (Current Working Directory, CWD) erzielen, wenn sich das aktuelle Arbeitsverzeichnis im Dateisystem des Arbeitsbereichs befindet. Weitere Informationen finden Sie unter Wohin schreibe ich auf Azure Databricks am besten temporäre Dateien?.

Maximale Anzahl von Git-Ordnern pro Arbeitsbereich

Sie können maximal 2.000 Git-Ordner pro Arbeitsbereich haben. Wenn Sie mehr benötigen, wenden Sie sich an den Databricks-Support.

Wiederherstellen von Dateien, die aus Git-Ordnern in Ihrem Arbeitsbereich gelöscht wurden

Arbeitsbereichsaktionen auf Git-Ordnern variieren bei der Wiederherstellbarkeit von Dateien. Einige Aktionen ermöglichen die Wiederherstellung über den Papierkorbordner , während andere nicht. Dateien, die zuvor zugesichert und an eine Remote-Verzweigung übertragen wurden, können mithilfe des Git-Commit-Verlaufs für das Remote-Git-Repository wiederhergestellt werden. In dieser Tabelle werden das Verhalten und die Wiederherstellbarkeit der einzelnen Aktionen beschrieben:

Aktion Ist die Datei wiederherstellbar?
Datei mit Arbeitsbereichsbrowser löschen Ja, aus dem Ordner "Papierkorb "
Verwerfen einer neuen Datei mit dem Dialogfeld "Git"-Ordner Ja, aus dem Ordner "Papierkorb "
Verwerfen einer geänderten Datei mit dem Dialogfeld "Git"-Ordner Nein, Die Datei ist nicht mehr vorhanden.
reset (schwierig) für nicht ausgelassene Dateiänderungen Nein, Dateiänderungen sind nicht mehr vorhanden.
reset (schwierig) für nicht ausgelassene, neu erstellte Dateien Nein, Dateiänderungen sind nicht mehr vorhanden.
Wechseln von Verzweigungen mit dem Dialogfeld "Git-Ordner" Ja, von Remote-Git-Repository
Andere Git-Vorgänge (Commit & Push usw.) aus dem Dialogfeld "Git-Ordner" Ja, von Remote-Git-Repository
PATCHVorgänge, die von der Repos-API aktualisiert werden /repos/id Ja, von Remote-Git-Repository

Dateien, die aus einem Git-Ordner über Git-Vorgänge aus der Arbeitsbereich-UI gelöscht wurden, können mithilfe der Git-Befehlszeile (oder anderer Git-Tools) aus dem Remote branch-Verlauf wiederhergestellt werden, wenn diese Dateien zuvor zugesichert und an die Remoterepository übertragen wurden. Arbeitsbereichsaktionen variieren bei der Wiederherstellbarkeit von Dateien. Einige Aktionen ermöglichen die Wiederherstellung durch den Papierkorb, während andere nicht. Dateien, die zuvor zugesichert und an eine Remote-Verzweigung übertragen wurden, können über den Git-Commit-Verlauf wiederhergestellt werden. In der folgenden Tabelle werden das Verhalten und die Wiederherstellbarkeit der einzelnen Aktionen beschrieben:

Unterstützung für Monorepos

Databricks empfiehlt, keine Git-Ordner zu erstellen, die von Monorepos unterstützt werden, wobei ein Monorepo ein großes Git-Repository mit einer Einzigen Organisation mit vielen Tausenden von Dateien in vielen Projekten ist.

In Git-Ordnern unterstützte Objekttypen

Nur bestimmte Azure Databricks-Ressourcentypen werden von Git-Ordnern unterstützt. Ein unterstützter Objekttyp kann serialisiert, versionsgesteuert und an das sicherungsbasierte Git-Repository übertragen werden.

Derzeit werden die folgenden Objekttypen unterstützt:

Ressourcentyp Details
Datei Dateien sind serialisierte Daten und können alles von Bibliotheken bis zu Binärdateien bis hin zu Code und Bildern enthalten. Weitere Informationen finden Sie unter Was sind Arbeitsbereichsdateien?
Notebook Notebooks sind insbesondere die Notebookdateiformate, die von Databricks unterstützt werden. Notebooks werden als separater Azure Databricks-Objekttyp von Dateien betrachtet, da sie nicht serialisiert werden. Git-Ordner bestimmen ein Notizbuch anhand der Dateierweiterung (z .ipynb. B. ) oder durch Dateierweiterungen in Kombination mit einer speziellen Markierung in Dateiinhalten (z. B. einen # Databricks notebook source Kommentar am Anfang der .py Quelldateien).
Ordner Ein Ordner ist eine Azure Databricks-spezifische Struktur, die serialisierte Informationen zu einer logischen Gruppierung von Dateien in Git darstellt. Wie erwartet, erlebt der Benutzer ihn als „Ordner“ beim Anzeigen eines Azure Databricks-Git-Ordners oder beim Zugriff darauf mit der Azure Databricks CLI.

Derzeit werden u. a. die folgenden Azure Databricks-Ressourcentypen in Git-Ordnern nicht unterstützt:

  • DBSQL-Abfragen
  • Alerts
  • Dashboards (einschließlich Legacydashboards)
  • Experimente
  • Genie Spaces

Beachten Sie beim Arbeiten mit Ihren Ressourcen in Git die folgenden Einschränkungen bei der Dateinamenbenennung:

  • Ein Ordner kann kein Notebook mit demselben Namen wie ein anderes Notebook, eine Datei oder einen Ordner im selben Git-Repository enthalten, auch wenn sich die Dateierweiterung unterscheidet. (Bei Notebooks im Quellformat ist die Erweiterung für Python .py, .scala für Scala, .sql für SQL und .r für R. Für IPYNB-Format-Notebooks ist die Erweiterung .ipynb.) Sie können beispielsweise kein Quellformat-Notebook mit dem Namen test1.py und ein IPYNB-Notebook namens test1 im selben Git-Ordner verwenden, da die Python-Notebookdatei im Quellformat (test1.py) als test1 serialisiert wird und ein Konflikt auftritt.
  • Das Zeichen / wird in Dateinamen nicht unterstützt. Sie können z. B. keine Datei mit dem Namen i/o.py in Ihrem Git-Ordner haben.

Wenn Sie versuchen, Git-Operationen für Dateien durchzuführen, deren Namen diese Muster aufweisen, erhalten Sie die Meldung „Fehler beim Abrufen des Git-Status“. Wenn dieser Fehler unerwartet angezeigt wird, überprüfen Sie die Dateinamen der Objekte in Ihrem Git-Repository. Wenn Sie Dateien mit Namen mit diesen widersprüchlichen Mustern finden, benennen Sie sie um, und versuchen Sie es erneut.

Hinweis

Sie können vorhandene nicht unterstützte Ressourcen in einen Git-Ordner verschieben, aber keine Änderungen an diesen Ressourcen wieder ins Repository committen. Sie können keine neuen nicht unterstützten Ressourcen in einem Git-Ordner erstellen.

Notebook-Formate

Databricks betrachtet zwei Arten von High-Level-, Databricks-spezifischen Notebook-Formaten: „Source“ und „ipynb“. Wenn ein Benutzer ein Notizbuch im Quellformat commits, wird von der Azure Databricks-Plattform eine Flache Datei mit einem Sprachsuffix wie .py, , .sql, .scalaoder .r. Ein „Source“-Format-Notebook enthält nur Quellcode und enthält keine Ausgaben wie Tabellenanzeigen und Visualisierungen, welche die Ergebnisse der Ausführung des Notebooks darstellen.

Das Format „ipynb“ hat jedoch Ausgaben zugeordnet, und diese Artefakte werden automatisch an das Git-Repository übertragen, wenn sie das .ipynb-Notebook übertragen, das sie generiert hat. Wenn Sie ausgaben zusammen mit dem Code commiten möchten, verwenden Sie das Notizbuchformat "ipynb", und richten Sie die Konfiguration ein, damit ein Benutzer alle generierten Ausgaben übernehmen kann. Daher unterstützt „ipynb“ auch eine bessere Anzeigeerfahrung in Databricks für Notebooks, die über Git-Remoterepositorys an Git-Ordner übertragen werden.

Notebookquellformat Details
Quelle Dies kann eine beliebige Codedatei mit einem Standarddateisuffix sein, welche die Codesprache signalisiert, z. B. .py, .scala, .r und .sql. „Quell“-Notebooks werden als Textdateien behandelt und enthalten keine zugehörigen Ausgaben, wenn ein Commit für ein Git-Repository erfolgt.
ipynb „ipynb“-Dateien enden mit .ipynb und können, falls konfiguriert, Pushausgaben (z. B. Visualisierungen) aus dem Git-Ordner „Databricks“ an das zugrunde liegende Git-Repository übertragen. Ein .ipnynb-Notebook kann Code in jeder Sprache enthalten, die von Databricks-Notebooks unterstützt wird (trotz des py-Teils von .ipynb).

Wenn Ausgaben nach dem Ausführen eines Notebooks zurück in Ihr Repository verschoben werden sollen, verwenden Sie ein .ipynb-(Jupyter)-Notebook. Wenn Sie nur das Notebook ausführen und es in Git verwalten möchten, verwenden Sie ein „Quell“-Format, z. B. .py.

Weitere Informationen zu unterstützten Notebookformaten finden Sie unter Exportieren und Importieren von Databricks-Notebooks.

Hinweis

Was sind „Ausgaben“?

Ausgaben sind die Ergebnisse der Ausführung eines Notebooks auf der Databricks-Plattform, einschließlich Tabellenanzeigen und Visualisierungen.

Wie kann ich feststellen, welches Format ein Notebook verwendet, außer der Dateierweiterung?

Oben in einem Notebook, das von Databricks verwaltet wird, gibt es in der Regel einen einzeiligen Kommentar, der das Format angibt. Zum Beispiel wird bei einem .py-„Quell“-Notebook eine Zeile wie folgende angezeigt:

# Databricks notebook source

Bei .ipynb-Dateien wird das Dateisuffix verwendet, um anzugeben, dass es sich um das Notebook-Format IPYNB handelt.

IPYNB-Notebooks in Databricks-Git-Ordnern

Unterstützung für Jupyter-Notebooks (.ipynb-Dateien) ist in Git-Ordnern verfügbar. Sie können Repositorys mit .ipynb Notizbüchern klonen, mit ihnen in Azure Databricks arbeiten und diese dann als .ipynb Notizbücher übernehmen und übertragen. Metadaten, z. B. das Notizbuchdashboard, bleiben erhalten. Administratoren können steuern, ob Ausgaben committet werden können.

Zulassen von Commits für die Ausgabe von .ipynb-Notebooks

Standardmäßig lässt die Administratoreinstellung für Git-Ordner nicht zu, dass die Ausgabe von .ipynb-Notebooks committet wird. Arbeitsbereichsadministratoren können diese Einstellung ändern:

  1. Gehen Sie zu Administratoreinstellungen > Arbeitsbereichseinstellungen.

  2. Wählen Sie unter Git-Ordner > Zulassen, dass Git-Ordner IPYNB-Ausgaben exportieren die Option Zulassen: IPYNB-Ausgaben können aktiviert werden aus.

    Verwaltungskonsole: Zulassen, dass Git-Ordner IPYNB-Ausgaben exportieren.

Wichtig

Wenn Ausgaben enthalten sind, werden die Visualisierungs- und Dashboardkonfigurationen im IPYNB-Dateiformat beibehalten.

Steuern von IPYNB-Notebook-Ausgabeartefakten

Wenn Sie einen Commit für eine .ipynb-Datei ausführen, erstellt Databricks eine Konfigurationsdatei, mit der Sie steuern können, wie Sie Ausgaben übernehmen: .databricks/commit_outputs.

  1. Wenn Sie eine .ipynb-Notebookdatei, aber keine Konfigurationsdatei in Ihrem Repository haben, öffnen Sie das Modal Git-Status.

  2. Klicken Sie im Benachrichtigungsdialog auf commit_outputs-Datei erstellen.

    Notebook Commit UI: Schaltfläche commit_outputs Datei erstellen.

Sie können auch Konfigurationsdateien aus dem Datei-Menü generieren. Das Datei-Menü verfügt über ein Steuerelement, mit dem Sie die Konfigurationsdatei automatisch aktualisieren können, um die Aufnahme oder den Ausschluss von Ausgaben für ein bestimmtes Notebook anzugeben.

  1. Wählen Sie im Datei-Menü die Option Notebookausgaben committen aus.

    Notizbuch-Editor: Commit für Notizbücher gibt den Status und das Steuerelement aus.

  2. Bestätigen Sie im Dialogfeld, dass Sie Notebookausgaben commiten möchten.

    Dialogfeld „Notebookausgaben committen“.

Konvertieren eines Quell-Notebooks in IPYNB

Sie können ein vorhandenes Quell-Notebook in einem Git-Ordner über die Azure Databricks-Benutzeroberfläche in ein IPYNB-Notebook konvertieren.

  1. Öffnen Sie ein Quellnotizbuch in Ihrem Arbeitsbereich.

  2. Wählen Sie Datei aus dem Arbeitsbereichsmenü aus und wählen Sie dann Notebook-Format ändern [Quelle] aus. Wenn sich das Notebook bereits im IPYNB-Format befindet, wird [source] im Menüelement [ipynb] sein.

    Das erweiterte Arbeitsbereichsdateimenü mit der Option „Notebook-Format ändern“

  3. Wählen Sie im modalen Dialogfeld „Jupyter-Notebook-Format (IPYNB)“ aus, und klicken Sie auf Ändern.

    Das modale Dialogfeld, in dem Sie das IPYNB-Notebook-Format auswählen können.

Weitere Funktionen:

  • Erstellen von .ipynb-Notebooks
  • Anzeigen von Diffs als Code diff (Codeänderungen in Zellen) oder Raw diff (Codeänderungen werden als JSON-Syntax dargestellt, die Notebookausgabe als Metadaten enthält).

Weitere Informationen zu den in Azure Databricks unterstützten Notebooks finden Sie unter Exportieren und Importieren von Databricks-Notebooks.

Häufig gestellte Fragen: Konfiguration von Git-Ordnern

Wo werden die Inhalte von Azure Databricks-Repository gespeichert?

Die Inhalte eines Repositorys werden vorübergehend auf der Steuerungsebene auf den Datenträger geklont. Azure Databricks-Notebookdateien werden ebenso wie Notebooks im Hauptarbeitsbereich in der Datenbank der Steuerungsebene gespeichert. Nicht-Notebook-Dateien können bis zu 30 Tage lang auf dem Datenträger gespeichert werden.

Unterstützen Git-Ordner lokale oder selbstgehostete Git-Server?

Databricks Git-Ordner unterstützen GitHub Enterprise, Bitbucket Server, Azure DevOps Server und selbst verwaltete GitLab-Integrationen, wenn über das Internet auf den Server zugegriffen werden kann. Ausführliche Informationen zur Integration von Git-Ordnern in einen lokalen Git-Server finden Sie unter Git Proxy Server für Git-Ordner.

Wenden Sie sich für die Integration mit einem Bitbucket- oder GitHub Enterprise-Server oder mit einer selbstverwaltete Abonnementinstanz von GitLab, die nicht über das Internet zugänglich ist, an Ihr Azure Databricks-Kundenberatungsteam.

Welche Arten von Databricks-Ressourcen werden von Git-Ordnern unterstützt?

Ausführliche Informationen zu unterstützten Objekttypen finden Sie unter " Ressourcentypen", die in Git-Ordnern unterstützt werden.

Unterstützen Git-Ordner Dateien vom Typ .gitignore?

Ja. Wenn Sie Ihrem Repository eine Datei hinzufügen und nicht möchten, dass sie von Git nachverfolgt wird, erstellen Sie eine .gitignore-Datei, oder verwenden Sie eine aus Ihrem Remoterepository geklonte Datei, und fügen Sie den Dateinamen einschließlich der Erweiterung hinzu.

.gitignore funktioniert nur für Dateien, die noch nicht von Git nachverfolgt werden. Wenn Sie einer .gitignore-Datei eine Datei hinzufügen, die bereits von Git nachverfolgt wird, wird die Datei weiterhin von Git nachverfolgt.

Kann ich Ordner der obersten Ebene erstellen, die keine Benutzerordner sind?

Ja, Administratoren können Ordner der obersten Ebene bis zu einer einzelnen Tiefe erstellen. Git-Ordner unterstützen keine zusätzlichen Ordnerebenen.

Unterstützen Git-Ordner Git-Untermodule?

Nein Sie können ein Repository klonen, das Git-Untermodule enthält, aber das Submodul wird nicht geklont.

Unterstützt Azure Data Factory (ADF) Git-Ordner?

Ja.

Quellverwaltung

Warum verschwinden Notebook-Dashboards, wenn ich einen anderen Branch pulle oder auschecke?

Dies ist derzeit eine Einschränkung, da Notebook-Quelldateien von Azure Databricks keine Notebook-Dashboard-Informationen speichern.

Wenn Sie Dashboards im Git-Repository beibehalten möchten, ändern Sie das Notebook-Format in .ipynb (das Jupyter-Notebook-Format). Das .ipynb-Format unterstützt standardmäßig Dashboard- und Visualisierungsdefinitionen. Wenn Sie Graphdaten (Datenpunkte) beibehalten möchten, müssen Sie das Notebook mit Ausgaben committen.

Weitere Informationen zum Committen der Ausgaben von .ipynb-Notebooks finden Sie unter Zulassen des Commits für die Ausgabe von .ipynb-Notebooks.

Unterstützen Git-Ordner das Zusammenführen von Branches?

Ja. Sie können auch einen Pull Request erstellen und das Zusammenführen über Ihren Git-Anbieter durchführen.

Kann ich einen Branch aus einem Azure Databricks-Repository löschen?

Nein. Um einen Branch zu löschen, müssen Sie in Ihrem Git-Anbieter arbeiten.

Welche Bibliothek wird importiert, wenn eine Bibliothek auf einem Cluster installiert ist und eine Bibliothek mit dem gleichen Namen in einem Ordner innerhalb eines Repositorys enthalten ist?

Die Bibliothek im Repository wird importiert. Weitere Informationen zur Rangfolge von Bibliotheken in Python finden Sie unter Rangfolge von Python-Bibliotheken.

Kann ich die neueste Version eines Repositorys von Git pullen, bevor ich einen Auftrag ausführe, ohne ein externes Orchestrierungstool zu verwenden?

Nein. In der Regel können Sie dies als Pre-Commit auf dem Git-Server integrieren, sodass das Produktionsrepository bei jedem Push auf einen Branch (Main/Prod) aktualisiert wird.

Lassen sich Repositorys exportieren?

Sie können Notebooks, Ordner oder ein ganzes Repository exportieren. Sie können keine Nicht-Notebook-Dateien exportieren. Wenn Sie ein vollständiges Repository exportieren, sind Nicht-Notebook-Dateien nicht enthalten. Verwenden Sie zum Exportieren den workspace export-Befehl in der Databricks-CLI, oder verwenden Sie die Arbeitsbereichs-API.

Sicherheit, Authentifizierung und Token

Problem mit einer Richtlinie für bedingten Zugriff (CAP) für Microsoft Entra ID

Wenn Sie versuchen, ein Repository zu klonen, wird möglicherweise die Fehlermeldung „Zugriff verweigert“ angezeigt, wenn Folgendes zutrifft:

  • Azure Databricks ist für die Verwendung von Azure DevOps mit der Microsoft Entra ID-Authentifizierung konfiguriert.
  • Sie haben eine Richtlinie für bedingten Zugriff in Azure DevOps und eine Microsoft Entra ID-Richtlinie für bedingten Zugriff aktiviert.

Um dies zu beheben, fügen Sie der Richtlinie für bedingten Zugriff (CAP) für die IP-Adresse oder die Benutzer*innen von Azure Databricks einen Ausschluss hinzu.

Weitere Informationen finden Sie unter Richtlinien für bedingten Zugriff.

Liste mit Azure AD-Token zulassen

Wenn Sie Azure Active Directory (AAD) für die Authentifizierung bei Azure DevOps verwenden, beschränkt die standardmäßige Zulassungsliste Git-URLs auf:

  • dev.azure.com
  • visualstudio.com

Weitere Informationen finden Sie unter Listen zulassen, die die Verwendung von Remote-Repositorys einschränken.

Werden die Inhalte von Azure Databricks Git-Ordnern verschlüsselt?

Der Inhalt von Azure Databricks Git-Ordnern wird von Azure Databricks mithilfe eines Standardschlüssels verschlüsselt. Die Verschlüsselung mithilfe von kundenseitig verwalteten Schlüsseln wird nicht unterstützt, außer beim Verschlüsseln Ihrer Git-Anmeldeinformationen.

Wie und wo werden die GitHub-Token in Azure Databricks gespeichert? Wer hätte aus Azure Databricks Zugriff?

  • Die Authentifizierungstoken werden auf der Azure Databricks-Steuerungsebene gespeichert, und ein Azure Databricks-Mitarbeiter kann nur über temporäre Anmeldeinformationen Zugriff erhalten, die überwacht werden.
  • Azure Databricks protokolliert die Erstellung und Löschung dieser Token, nicht jedoch deren Verwendung. Azure Databricks verfügt über eine Protokollierung, die Git-Operationen nachverfolgt, die zum Überwachen der Verwendung der Token durch die Azure Databricks-Anwendung verwendet werden können.
  • GitHub Enterprise überwacht die Tokenverwendung. Andere Git-Dienste verfügen möglicherweise auch über Git-Server-Auditing.

Unterstützen Git-Ordner die GPG-Signierung von Commits?

Nein

Unterstützen Git-Ordner SSH?

Nein, nur HTTPS.

Fehler beim Verbinden von Azure Databricks mit einem Azure DevOps-Repository in einem anderen Mandanten

Wenn Sie versuchen, eine Verbindung mit DevOps in einem separaten Mandanten herzustellen, erhalten Sie möglicherweise die Meldung Unable to parse credentials from Azure Active Directory account. Wenn sich das Azure DevOps-Projekt in einem anderen Microsoft Entra ID-Mandanten als Azure Databricks befindet, müssen Sie ein Zugriffstoken aus Azure DevOps verwenden. Weitere Informationen finden Sie unter Herstellen einer Verbindung mit Azure DevOps mithilfe eines DevOps-Tokens.

CI/CD und MLOps

Bei eingehenden Änderungen wird der Notebook-Status gelöscht.

Git-Vorgänge, die den Notebook-Quellcode ändern, führen zum Verlust des Notebook-Status. Dies schließt Zellergebnisse, Kommentare, den Versionsverlauf und Widgets ein. Beispielsweise kann git pull den Quellcode eines Notebooks ändern. In diesem Fall müssen Databricks Git-Ordner das vorhandene Notebook überschreiben, um die Änderungen zu importieren. git commit und push oder das Erstellen eines neuen Branches wirken sich nicht auf den Notebookquellcode aus, sodass der Notebookzustand bei diesen Vorgängen beibehalten wird.

Wichtig

MLflow-Experimente funktionieren nicht in Git-Ordnern mit DBR 14.x oder niedrigeren Versionen.

Kann ich ein MLflow-Experiment in einem Repository erstellen?

Es gibt zwei Typen von MLflow-Experimenten: Arbeitsbereich und Notebook. Ausführliche Informationen zu den beiden Typen von MLflow-Experimenten finden Sie unter Organisieren von Trainingsausführungen mit MLflow-Experimenten.

In Git-Ordnern können Sie mlflow.set_experiment("/path/to/experiment") für ein MLflow-Experiment eines der beiden Typen aufrufen und Ausführungen darin protokollieren. Dieses Experiment und die zugehörigen Ausführungen werden jedoch nicht in die Quellcodeverwaltung eingecheckt.

MLflow-Arbeitsbereichsexperimente

Das Erstellen von MLflow-Arbeitsbereichsexperimenten ist in einem Databricks Git-Ordner (Git-Ordner) nicht möglich. Wenn mehrere Benutzer*innen separate Git-Ordner verwenden, um gemeinsam am selben ML-Code zu arbeiten, protokollieren Sie MLflow-Ausführungen für ein MLflow-Experiment, das in einem regulären Arbeitsbereichsordner erstellt wurde.

MLflow-Notebook-Experimente

Sie können Notebook-Experimente in einem Databricks Git-Ordner erstellen. Wenn Sie Ihr Notebook als Datei vom Typ .ipynb in die Quellcodeverwaltung einchecken, können Sie MLflow-Ausführungen in einem automatisch erstellten und zugeordneten MLflow-Experiment protokollieren. Hier finden Sie ausführlichere Informationen zum Erstellen von Notebook-Experimenten.

Verhindern von Datenverlusten in MLflow-Experimenten

Notebook-MLflow-Experimente, die mithilfe von Databricks-Aufträgen mit Quellcode in einem Remote-Repository erstellt wurden, werden an einem temporären Speicherort gespeichert. Diese Experimente bleiben zunächst nach der Workflowausführung bestehen, sind aber später beim geplanten Entfernen von Dateien im temporären Speicher gefahrlos. Databricks empfiehlt die Verwendung von MLflow-Arbeitsbereichsexperimenten mit Aufträgen und Remote-Git-Quellen.

Warnung

Jedes Mal, wenn Sie zu einem Branch wechseln, der das Notebook nicht enthält, riskieren Sie, dass die zugehörigen MLFlow-Experimentdaten verloren gehen. Die Daten gehen dauerhaft verloren, wenn nicht innerhalb von 30 Tagen auf den vorherigen Branch zugegriffen wird.

Um fehlende Experimentdaten vor dem Ablauf von 30 Tagen wiederherzustellen, benennen Sie das Notebook wieder mit seinem ursprünglichen Namen, öffnen Sie das Notebook, und klicken Sie auf das Symbol „Experiment“ im rechten Bereich (dadurch wird auch die mlflow.get_experiment_by_name()-API aufgerufen). Nun werden das wiederhergestellte Experiment und die Ausführungen angezeigt. Nach 30 Tagen werden alle verwaisten MLflow-Experimente endgültig gelöscht, um die Richtlinien zur Einhaltung der DSGVO zu erfüllen.

Um diese Situation zu verhindern, empfiehlt Databricks, entweder das Umbenennen von Notebooks in Repos ganz zu vermeiden oder direkt nach dem Umbenennen eines Notebooks im rechten Bereich auf das Symbol „Experiment“ zu klicken.

Was geschieht, wenn ein Notebook-Auftrag in einem Arbeitsbereich ausgeführt wird, während zugleich ein Git-Vorgang ausgeführt wird?

Zu jedem Zeitpunkt, während ein Git-Vorgang ausgeführt wird, wurden möglicherweise einige Notebooks im Repository aktualisiert, während andere dies nicht getan haben. Dies kann zu unvorhersehbarem Verhalten führen.

Nehmen wir zum Beispiel an, notebook A ruft notebook Z mit einem %run-Befehl auf. Wenn ein Auftrag, der während eines Git-Vorgangs ausgeführt wird, die neueste Version von notebook A startet, notebook Z aber noch nicht aktualisiert wurde, startet der Befehl %run in Notebook A möglicherweise die ältere Version von notebook Z. Während des Git-Vorgangs sind die Notebook-Zustände nicht vorhersagbar und der Auftrag kann fehlschlagen oder notebook A und notebook Z aus verschiedenen Commits ausführen.

Um diese Situation zu vermeiden, verwenden Sie Git-basierte Aufträge (bei denen es sich bei der Quelle um einen Git-Anbieter und nicht um einen Arbeitsbereichspfad handelt). Weitere Details finden Sie unter Verwenden von Git mit Aufträgen.

Ressourcen

Ausführliche Informationen zu Databricks-Arbeitsbereichsdateien finden Sie unter Was sind Arbeitsbereichsdateien?.