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.

Einschränkungen für die Datei- und Repositorygröße

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

  • Arbeitsbranches sind auf 200 MB beschränkt.
  • Einzelne Arbeitsbereichsdateien unterliegen einem separaten Größenlimit. Weitere Informationen finden Sie unter Einschränkungen.
  • Dateien, die größer als 10 MB sind, können nicht in der Azure Databricks-Benutzeroberfläche angezeigt werden.

Databricks empfiehlt in einem Repository Folgendes:

  • Die Gesamtanzahl aller Dateien sollte 10.000 nicht überschreiten.
  • Die Gesamtanzahl aller Notebooks sollte 5.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 Repositorys pro Arbeitsbereich

Sie können maximal 2.000 Repositorys pro Arbeitsbereich verwenden.

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 Verwalten von Dateiressourcen in Databricks Git-Ordnern.

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, und wenn Sie ein vollständiges Repository exportieren, sind Nicht-Notebook-Dateien nicht enthalten. Verwenden Sie zum Exportieren die Databricks CLI – Arbeitsbereichsexport oder die Arbeitsbereichs-API.

Sicherheit, Authentifizierung und Token

Problem mit einer Richtlinie für bedingten Zugriff (CAP) für Microsoft Entra ID (früher Azure Active Directory)

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.

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

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). Ausführlichere Informationen finden Sie unter Verwenden von versionskontrolliertem Quellcode in einem Azure Databricks-Auftrag.

Ressourcen

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