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

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.
Abfrage (Public Preview) Databricks SQL (DBSQL)-Abfragen können als IPYNB-Notizbücher (Dateiendung: .dbquery.ipynb) gespeichert werden. Die Git-Unterstützung für DBSQL-Abfragen erfordert, dass Sie den neuen SQL-Editoraktivieren. Abfragen, die mit deaktiviertem SQL-Editor-Feature erstellt wurden, können in einem Git-Ordner platziert, aber nicht für das Remote-Repository übernommen werden.

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

  • 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 Objekte in einen Git-Ordner verschieben, aber keine Änderungen übernehmen, die an dem Remote-Repository vorgenommen wurden.

Notebook-Formate

Weitere Informationen zu Notizbuchformaten für Git-Ordner finden Sie unter Notizbuchformate.

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?.