Freigeben über

Grenzwerte und HÄUFIG gestellte Fragen zur Git-Integration mit Git-Ordnern von Databricks

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:

Informationen zu den in Git-Ordnern unterstützten Datentypen von Databricks finden Sie unter Welche Objekttypen werden von Git-Ordnern unterstützt?.

Datei- und Repositorybeschränkungen

Azure Databricks erzwingt keinen Grenzwert für die Größe eines Repositorys. Allerdings:

  • Arbeitszweige sind auf 1 Gigabyte (GB) begrenzt.
  • Dateien, die größer als 10 MB sind, können in der Azure Databricks-Benutzeroberfläche nicht angezeigt werden.
  • Einzelne Arbeitsbereichsdateien unterliegen einem separaten Größenlimit. Weitere Informationen finden Sie unter Einschränkungen.
  • Die lokale Version einer Verzweigung kann bis zu 30 Tage nach dem Löschen der Remote-Verzweigung im zugeordneten Git-Ordner vorhanden bleiben. Um eine lokale Verzweigung in einem Git-Ordner vollständig zu entfernen, löschen Sie das Repository.

Databricks empfiehlt in einem Repository Folgendes:

  • Die Gesamtanzahl der Arbeitsbereichsressourcen und Dateien überschreitet nicht 20.000.

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 liegt, tritt ein Fehler auf, wenn Sie versuchen, ein Git-Repository mit einer Größe von 5 GB zu klonen. 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.

Wenn Ihr Repository diese Grenzwerte überschreitet, wird möglicherweise eine Fehlermeldung angezeigt. Möglicherweise wird auch beim Klonen des Repositorys ein Timeoutfehler angezeigt, obwohl der Vorgang möglicherweise noch im Hintergrund abgeschlossen ist.

Wenn Sie mit einem Repository arbeiten möchten, das größer als die Größenbeschränkungen ist, versuchen Sie das auschecken.

Wenn Sie temporäre Dateien schreiben müssen, die Sie nach dem Herunterfahren des Clusters nicht beibehalten möchten, sollten Sie diese Dateien in $TEMPDIR ablegen. Dadurch werden die Größenbeschränkungen für Verzweigungen nicht überschritten und es wird eine bessere Leistung erzielt als beim Schreiben in ein Arbeitsverzeichnis (CWD) im Dateisystem des Arbeitsbereichs. Weitere Informationen finden Sie unter Wohin schreibe ich auf Azure Databricks am besten temporäre Dateien?.

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 committet und an einen Remote-Branch übertragen wurden, können mithilfe des Git-Commit-Verlaufs für das Remote-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 "
Eine neue Datei über das Git-Ordner-Dialogfeld verwerfen 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, aus dem Remote-Git-Repository
Andere Git-Vorgänge, z. B. Commit oder Push, aus dem Dialogfeld "Git-Ordner" Ja, aus dem Remote-Git-Repository
PATCH Vorgänge, die von der Repos-API aktualisiert werden /repos/id Ja, aus dem Remote-Git-Repository

Unterstützung für Monorepos

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

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 zum Integrieren von Git-Ordnern mit einem lokalen Git-Server finden Sie unter Git Proxy Server für Git-Ordner.

Wenden Sie sich an Ihr Azure Databricks-Kontoteam, um eine Integration mit einem Bitbucket-Server, GitHub Enterprise Server oder einer selbstverwalteten GitLab-Abonnementinstanz zu ermöglichen, auf die nicht über das Internet zugegriffen werden kann.

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

Ausführliche Informationen zu unterstützten Artefakttypen finden Sie unter Welche Objekttypen werden von Git-Ordnern unterstützt?.

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 wurden. Wenn Sie einer Datei, die bereits von Git nachverfolgt wurde, eine .gitignore Datei hinzufügen, wird die Datei weiterhin von Git nachverfolgt.

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 eine Einschränkung, da Notizbücher im Quellformat von Azure Databricks keine Notizbuch-Dashboardinformationen speichern.

Um Dashboards im Git-Repository beizubehalten, ändern Sie das Notizbuchformat .ipynb in (das Jupyter-Notizbuchformat). Das .ipynb-Format unterstützt standardmäßig Dashboard- und Visualisierungsdefinitionen. Um Visualisierungsdaten beizubehalten, müssen Sie das Notizbuch mit Ausgaben speichern.

Weitere Informationen zum Committen der Ausgaben von .ipynb-Notebooks finden Sie unter Verwalten 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.

Was ist die Rangfolge, wenn Python-Abhängigkeiten in Git-Ordnern enthalten sind?

Python-Bibliotheken, die in einem Git-Ordner gespeichert sind, haben Vorrang vor Bibliotheken, die an anderer Stelle gespeichert sind. Wenn beispielsweise eine Bibliothek auf Ihren Databricks-Berechnungen installiert ist und eine Bibliothek mit demselben Namen in einem Git-Ordner enthalten ist, wird die Bibliothek im Git-Ordner importiert. Weitere Informationen zur Rangfolge von Bibliotheken in Python finden Sie unter Rangfolge von Python-Bibliotheken.

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.

Zulassungsliste mit Microsoft Entra-ID-Token

Wenn Sie Microsoft Entra-ID für die Authentifizierung mit Azure DevOps verwenden, schränkt die Standardmäßige Zulassungsliste Git-URLs auf Folgendes ein:

  • 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, aber nicht 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-Verzeichnisse das GPG-Signieren von Commits?

Nein

Unterstützt Git-Ordner Git-Vorgänge mithilfe von SSH?

Nein, nur das HTTPS Protokoll wird unterstützt.

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 von 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 wirkt 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 Git-Ordner 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.

  • Arbeitsbereichsexperimente: Sie können keine MLflow-Arbeitsbereichsexperimente in Git-Ordnern erstellen. Stattdessen wird der MLflow-Protokoll in einem MLflow-Experiment ausgeführt, das in einem regulären Arbeitsbereichsordner erstellt wurde. Wenn mehrere Benutzer separate Git-Ordner verwenden, um an demselben Code zusammenzuarbeiten, sollten MLflow-Ausführungen in einem MLflow-Experiment protokolliert werden, das in einem freigegebenen Arbeitsbereichsordner erstellt wurde.

  • Notizbuchexperimente: Sie können Notizbuchexperimente in einem Git-Ordner "Databricks" 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. Das Experiment und die zugehörigen Ausführungen werden jedoch nicht in die Quellcodeverwaltung eingecheckt. Weitere Informationen finden Sie unter Erstellen von Notizbuchexperimenten.

Verhindern von Datenverlusten in MLflow-Experimenten

Notizbuch-MLflow-Experimente, die mithilfe von Lakeflow-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 jedoch später beim geplanten Entfernen von Dateien im temporären Speicher von Löschung bedroht. 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 Ablauf des 30-Tage-Ablaufs wiederherzustellen, ändern Sie den Notizbuchnamen in den ursprünglichen Namen, öffnen Sie das Notizbuch, und klicken Sie im rechten Bereich auf " Experiment ", wodurch ein Aufruf der mlflow.get_experiment_by_name() Funktion ausgelöst wird. Wenn die Funktion zurückgegeben wird, können Sie das wiederhergestellte Experiment sehen und ausgeführt werden. 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, Notizbücher in einem Repository nicht umzubenennen. Wenn Sie ein Notizbuch umbenennen, klicken Sie unmittelbar nach dem Umbenennen des Notizbuchs auf das Symbol "Experiment".

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

An jedem Punkt, an dem ein Git-Vorgang ausgeführt wird, wurden einige Notizbücher im Repository möglicherweise aktualisiert, während andere nicht. 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, aber notebook Z noch nicht aktualisiert ist, könnte der %run-Befehl in notebook A möglicherweise die ältere Version von notebook Z starten. 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, konfigurieren Sie Ihre Auftragsaufgaben so, dass Ihr Git-Anbieter als Quelle und nicht als Arbeitsbereichspfad verwendet wird. Weitere Informationen finden Sie unter Verwenden von Git mit Aufträgen.

Ressourcen

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