Azure Databricks Git-Ordnerbeschränkungen und -referenz

Diese Seite behandelt Größenbeschränkungen, unterstützte Features, Sicherheitsaspekte und CI/CD-Verhalten für Git-Ordner von Databricks. Allgemeine Grenzwerte für Databricks-Ressourcen finden Sie unter "Ressourcengrenzwerte". Informationen zu unterstützten Objekttypen in Git-Ordnern finden Sie unter "Unterstützte Objekttypen" in Git-Ordnern.

Datei- und Repositorybeschränkungen

Azure Databricks erzwingt keine Beschränkung der Repositorygröße. Die folgenden Grenzwerte gelten jedoch:

  • Arbeitszweige sind auf 1 GB begrenzt.
  • Dateien, die größer als 10 MB sind, können in der Azure Databricks UI nicht angezeigt werden.
  • Jeder Git-Vorgang unterstützt bis zu 2 GB Arbeitsspeicher und 4 GB Datenträgerschreibvorgänge.
  • Einzelne Arbeitsbereichsdateien weisen separate Größenbeschränkungen auf. Informationen finden Sie unter Einschränkungen.

Databricks empfiehlt, die Gesamtanzahl der Arbeitsbereichsressourcen und Dateien unter 20.000 zu halten.

Da Grenzwerte pro Vorgang gelten, schlägt das Klonen eines 5 GB-Repositorys fehl, aber das Klonen eines 3 GB-Repositorys und das spätere Hinzufügen von 2 GB ist erfolgreich. Wenn Ihr Repository diese Grenzwerte überschreitet, erhalten Sie möglicherweise einen Fehler oder ein Timeout während des Klonens, obwohl der Vorgang möglicherweise noch im Hintergrund abgeschlossen ist.

Zur Arbeit mit größeren Repositories nutzen Sie Sparse-Checkout oder Git CLI-Befehle. Verwenden Sie $TEMPDIR, um temporäre Dateien zu schreiben, die nach dem Herunterfahren des Clusters nicht gespeichert werden. Dies vermeidet eine Überschreitung der Größenbeschränkungen für Zweigstellen und bietet eine bessere Leistung als das Schreiben in ein Arbeitsverzeichnis (CWD) im Arbeitsbereichsdateisystem. Siehe Wo sollte ich temporäre Dateien auf Azure Databricks? schreiben.

Lokale Verzweigungen können bis zu 30 Tage nach dem Löschen der Remote-Verzweigung im zugeordneten Git-Ordner verbleiben. Um eine lokale Verzweigung vollständig zu entfernen, löschen Sie das Repository.

Verringern der Repositorygröße

Wenn Ihr Repository aufgrund großer Dateien die Größenbeschränkungen überschreitet, wird das Hinzufügen dieser Dateien zu .gitignore die Größe des Repositorys nicht verringern. Dateien, die bereits in Git committet wurden, bleiben im Repository-Verlauf, selbst wenn sie zu .gitignore hinzugefügt werden.

So verringern Sie die Repositorygröße:

  • Verwenden Sie Git-Tools wie git filter-repo, oder BFG-Repo-Cleaner, um große Dateien aus dem Commit-Verlauf zu entfernen. Das überschreibt den Verlauf und erfordert einen Force-Push in Ihr Remote-Repository.
  • Klonen Sie nur bestimmte Verzeichnisse. Siehe den Sparse-Auscheckmodus konfigurieren.
  • Verschieben Sie nicht verknüpften Code in separate Repositorys.

Weitere Informationen finden Sie unter Removing vertraulicher Daten aus einem Repository in der GitHub Dokumentation.

Monorepo-Unterstützung

Databricks empfiehlt, keine Git-Ordner zu erstellen, die von Monorepos unterstützt werden – große Git-Repositorys einer einzigen Organisation mit Tausenden von Dateien über viele Projekte hinweg. Das Klonen eines Monorepository kann die Speicher- und Datenträgerlimits von Git-Ordnern überschreiten und die Git-Vorgänge verlangsamen. Wenn Ihr Repository mehrere Projekte enthält, sollten Sie es aufteilen oder einen "sparse checkout" verwenden, um die zu klonenden Verzeichnisse zu begrenzen. Siehe den Sparse-Auscheckmodus konfigurieren.

Konfiguration

Nicht alle Standardmäßigen Git-Features funktionieren in Git-Ordnern, und Inhalte werden anders gespeichert als in einem lokalen Klon. In den folgenden Themen wird erläutert, wie Speicher funktioniert, welche Server unterstützt werden und wie sich Features wie .gitignore und Untermodule verhalten.

Repository-Content-Speicher

Azure Databricks klont die Repository-Inhalte vorübergehend auf die Festplatte in der Steuerungsebene. In der Steuerelementebenendatenbank werden Notizbuchdateien wie die im Hauptarbeitsbereich gespeichert. Nicht-Notebook-Dateien können bis zu 30 Tage lang auf dem Datenträger gespeichert werden.

Lokale und selbst gehostete Git-Server

Git-Ordner von Databricks unterstützen GitHub Enterprise, Bitbucket Server, Azure DevOps Server und GitLab Self-Managed, wenn der Server über das Internet zugänglich ist. Informationen zur lokalen Integration finden Sie unter Git-Proxyserver für Git-Ordner .

Wenden Sie sich an Ihr Azure Databricks-Kontoteam, um in eine Bitbucket-Server-, GitHub Enterprise Server- oder GitLab-selbstverwaltete Instanz zu integrieren, die nicht über das Internet zugänglich ist.

Unterstützte Objekttypen

Ausführliche Informationen zu unterstützten Objekttypen finden Sie unter "Unterstützte Objekttypen" in Git-Ordnern.

Gitignore-Dateiunterstützung

Git-Ordner unterstützen .gitignore Dateien. Um zu verhindern, dass Git eine Datei nachverfolgt, fügen Sie den Dateinamen (einschließlich Erweiterung) zu einer .gitignore Datei hinzu. Erstellen Sie entweder eine datei, oder verwenden Sie eine vorhandene Datei, die aus Ihrem Remote-Repository geklont wurde.

.gitignore funktioniert nur für nicht nachverfolgte Dateien. Das Hinzufügen einer bereits ins Repository übertragenen Datei zu .gitignore entfernt sie nicht aus dem Git-Verlauf und verringert nicht die Größe des Repositorys. Informationen zum Entfernen von zugesicherten Dateien finden Sie unter Reduzieren der Repositorygröße.

Unterstützung für Git-Untermodule

Standardmäßige Git-Ordner unterstützen keine Git-Untermodule, aber Git-Ordner mit Git CLI-Zugriff können sie verwenden. Siehe Verwenden von Git CLI-Befehlen (Beta)

Support für Azure Data Factory

Azure Data Factory (ADF) unterstützt Git-Ordner.

Quellverwaltung

Einige Vorgänge funktionieren in Git-Ordnern anders als bei einem Standardmäßigen Git-Workflow, insbesondere bei Notizbüchern und Verzweigungslöschvorgängen.

Notebook-Dashboards und Branch-Änderungen

Azure Databricks Quellformat-Notizbücher speichern keine Dashboardinformationen.

Um Dashboards beizubehalten, ändern Sie das Notizbuchformat .ipynb (Jupyter-Format), das standardmäßig Dashboard- und Visualisierungsdefinitionen unterstützt. Um Visualisierungsdaten beizubehalten, speichern Sie das Notizbuch mit Ergebnissen.

Siehe Verwalten von IPYNB-Notizbuchausgabe-Commits.

Unterstützung für das Zusammenführen von Zweigen

Git-Repositories unterstützen das Zusammenführen von Branches. Sie können auch einen Pull Request erstellen und das Zusammenführen über Ihren Git-Anbieter durchführen.

Löschen von Branches

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

Python Abhängigkeitsrangfolge

Python Bibliotheken in einem Git-Ordner Vorrang vor bibliotheken haben, die an anderer Stelle gespeichert sind. Wenn beispielsweise eine Bibliothek auf Ihren Databricks installiert ist und eine Bibliothek mit demselben Namen in einem Git-Ordner vorhanden ist, wird die Git-Ordnerbibliothek importiert. Siehe Python Bibliotheksrangfolge.

Sicherheit, Authentifizierung und Token

Azure Databricks speichert Git-Anmeldeinformationen in der Steuerebene, nicht in Ihrer lokalen Umgebung. In den folgenden Themen wird beschrieben, wie Git-Ordnerinhalte verschlüsselt werden, wie Token gespeichert und überwacht werden und was sie tun müssen, wenn Authentifizierungsprobleme auftreten.

Problem bei einer bedingten Zugriffsrichtlinie (Conditional Access Policy, CAP) für Microsoft Entra ID

Möglicherweise wird beim Klonen eines Repositorys ein Fehler "Zugriff verweigert" angezeigt, wenn:

  • Ihr Azure Databricks Arbeitsbereich verwendet Azure DevOps mit Microsoft Entra ID Authentifizierung.
  • 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 CAP-Richtlinie (Conditional Access Policy) einen Ausschluss für Azure Databricks IP-Adressen oder Benutzer 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 Standard-Zulassungsliste Git-URLs auf Folgendes ein:

  • dev.azure.com
  • visualstudio.com

Weitere Informationen finden Sie unter Git-URL-Zulassungslisten.

Git-Ordnerverschlüsselung

Azure Databricks verschlüsselt Git-Ordnerinhalte mit einem Standardschlüssel. Vom Kunden verwaltete Schlüssel werden nur zum Verschlüsseln von Git-Anmeldeinformationen unterstützt.

GitHub Tokenspeicher und -zugriff

  • Die Azure Databricks Steuerebene speichert Authentifizierungstoken. Mitarbeiter können nur über überwachte temporäre Anmeldeinformationen darauf zugreifen.
  • Azure Databricks protokolliert die Tokenerstellung und -löschung, aber nicht die Verwendung. Mit der Git-Vorgangsprotokollierung können Sie die Tokenverwendung von der Azure Databricks Anwendung überwachen.
  • GitHub Enterprise prüft die Nutzung von Tokens. Andere Git-Dienste bieten möglicherweise auch die Serverüberwachung an.

GPG Commit-Signierung

Git-Ordner unterstützen keine GPG-Signierung von Commits.

SSH-Unterstützung

Git-Ordner unterstützen nur HTTPS, nicht SSH.

Azure DevOps Mandantenübergreifende Fehler

Wenn Sie eine Verbindung mit DevOps in einem separaten Mandanten herstellen, wird möglicherweise Unable to parse credentials from Azure Active Directory account angezeigt. Wenn sich das Azure-DevOps-Projekt in einem anderen Mandanten der Microsoft Entra ID befindet als Azure Databricks, verwenden Sie ein Azure DevOps-Zugriffstoken. Siehe Persönliches Zugriffstoken.

CI/CD und MLOps

Wenn Sie Aufträge für Dateien in einem Git-Ordner ausführen, beachten Sie, wie Git-Vorgänge den Notizbuchzustand und MLflow-Experimente beeinflussen können, die möglicherweise nicht offensichtlich sind.

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

Git-Vorgänge, die den Quellcode des Notizbuchs ändern, führen zu Einem Verlust des Notizbuchzustands, einschließlich Zellenausgaben, Kommentaren, Versionsverlauf und Widgets. git pull Beispielsweise kann der Quellcode des Notizbuchs geändert werden, sodass Git-Ordner das vorhandene Notizbuch überschreiben müssen. Vorgänge wie git commit, oder pushdas Erstellen einer neuen Verzweigung wirken sich nicht auf Quellcode aus und bewahren den Notizbuchstatus auf.

Wichtig

MLflow-Experimente funktionieren nicht in Git-Ordnern mit Databricks Runtime 14.x oder früheren Versionen.

MLflow-Experimente in Git-Ordnern

Es gibt zwei Typen von MLflow-Experimenten: Arbeitsbereich und Notebook. Weitere Informationen finden Sie unter Organisieren von Trainingsausführungen mit MLflow-Experimenten.

  • Arbeitsbereichsexperimente: Sie können keine MLflow-Arbeitsbereichsexperimente in Git-Ordnern erstellen. MLflow-Läufe in ein in einem regulären Arbeitsbereichsordner erstelltes Experiment protokollieren. Verwenden Sie für die Zusammenarbeit mit mehreren Benutzern einen freigegebenen Ordner im Arbeitsbereich.

  • Notizbuchexperimente: Sie können Notizbuchexperimente in einem Git-Ordner "Databricks" erstellen. Wenn Sie Ihr Notizbuch als .ipynb Datei in die Quellcodeverwaltung einchecken, führt MLflow das Protokoll für ein automatisch erstelltes Experiment aus. Die Quellcodeverwaltung checkt das Experiment oder dessen Ausführung nicht ein. Weitere Informationen finden Sie unter Erstellen eines Notebookexperiments.

Verhindern von Datenverlusten in MLflow-Experimenten

Notizbuch-MLflow-Experimente, die mithilfe von Lakeflow-Aufträgen mit Quellcode in einem Remote-Repository erstellt wurden, werden im temporären Speicher gespeichert. Diese Experimente bleiben zunächst nach der Workflowausführung bestehen, aber besteht die Gefahr einer Löschung während der geplanten Bereinigung. Databricks empfiehlt die Verwendung von MLflow-Arbeitsbereichsexperimenten mit Aufträgen und Remote-Git-Quellen.

Warnung

Wenn Sie zu einer Verzweigung wechseln, die nicht das Notizbuch enthält, gehen die zugehörigen MLflow-Experimentdaten verloren. Dieser Verlust wird dauerhaft, wenn Sie den vorherigen Zweig innerhalb von 30 Tagen nicht besuchen.

Um fehlende Experimentdaten vor dem 30-tägigen Ablauf wiederherzustellen, stellen Sie den ursprünglichen Notizbuchnamen wieder her, öffnen Sie das Notizbuch, und klicken Sie im rechten Bereich auf das Experiment-Symbol. Dadurch wird mlflow.get_experiment_by_name() ausgelöst und das Experiment wiederhergestellt und durchgeführt. Nach 30 Tagen löscht Azure Databricks verwaiste MLflow-Experimente für die DSGVO-Compliance.

Um Datenverluste zu verhindern, vermeiden Sie das Umbenennen von Notizbüchern in einem Repository. Wenn Sie ein Notizbuch umbenennen, klicken Sie sofort im rechten Bereich auf das Experimentsymbol.

Ausführen von Jobs während Git-Operationen

Während eines Git-Vorgangs werden einige Notizbücher möglicherweise aktualisiert, während andere noch nicht vorhanden sind, was zu unvorhersehbarem Verhalten führt.

Wenn notebook Anotebook Z unter Verwendung von %run aufruft und ein Job während eines Git-Vorgangs gestartet wird, kann der Job die neueste notebook A mit einem älteren notebook Z ausführen. Der Job könnte fehlschlagen oder Notebooks aus unterschiedlichen Commits ausführen.

Um dies zu vermeiden, konfigurieren Sie Auftragsaufgaben so, dass Ihr Git-Anbieter anstelle eines Arbeitsbereichspfads als Quelle verwendet wird. Siehe Verwenden von Git mit Lakeflow-Aufträgen.

Nächste Schritte

  • Last updated on