Git-Ordnerbeschränkungen und -referenz für Databricks

In den folgenden Abschnitten werden Grenzwerte für die Git-Ordner und die Git-Integration von Databricks angegeben. Allgemeine Informationen finden Sie unter Ressourcengrenzwerte.

Wechseln Sie zu:

• Datei- und Repositorybeschränkungen
• Configuration

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 keine Beschränkung der Repositorygröße. Allerdings:

• Arbeitszweige sind auf 1 GB begrenzt.
• Dateien, die größer als 10 MB sind, können in der Azure Databricks-Benutzeroberfläche nicht angezeigt werden.
• Einzelne Arbeitsbereichsdateien weisen separate Größenbeschränkungen auf. Informationen finden Sie unter Einschränkungen.
• 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.

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

Jeder Git-Vorgang ist auf 2 GB Arbeitsspeicher und 4 GB Datenträgerschreibvorgänge beschränkt. 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. Lesen Sie , wo sollte ich temporäre Dateien auf Azure Databricks schreiben?.

Wiederherstellen gelöschter Dateien

Die Wiederherstellbarkeit von Dateien variiert je nach Aktion. Einige Aktionen ermöglichen die Wiederherstellung über den Papierkorb, während andere nicht. Dateien, die zuvor committed und in einen Remote-Branch gepusht wurden, können mithilfe des Git-Commit-Verlaufs des Remote Repositories wiederhergestellt werden.

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 – große Git-Repositorys einer einzigen Organisation mit Tausenden von Dateien über viele Projekte hinweg.

Konfiguration

In diesem Abschnitt werden Git-Ordnerspeicher, Serverunterstützung und allgemeine Einrichtungsfragen behandelt.

Speicher für Repositoryinhalte

Azure Databricks klont temporär Repositoryinhalte auf den Datenträger in der Steuerebene. 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 die Integration mit einem Bitbucket-Server, GitHub Enterprise Server oder gitLab selbstverwalteter Instanz zu ermöglichen, auf die nicht über das Internet zugegriffen werden kann.

Unterstützte Ressourcentypen

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. 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 nachverfolgten Datei zu .gitignore hindert Git nicht daran, sie weiterhin nachzuverfolgen.

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)

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

Ja.

Quellverwaltung

In diesem Abschnitt werden Verzweigungen, Merge-Vorgänge und die Behandlung von Notizbüchern und Abhängigkeiten in Git-Ordnern behandelt.

Notebook-Dashboards und Verzweigungs-Änderungen

Notizbücher im Quellformat von Azure Databricks 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ü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.

Löschen von Branches

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

Rangfolge der Python-Abhängigkeit

Python-Bibliotheken in einem Git-Ordner haben Vorrang vor Bibliotheken, 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. Weitere Informationen finden Sie unter Rangfolge der Python-Bibliothek.

Sicherheit, Authentifizierung und Token

In diesem Abschnitt werden Verschlüsselungs-, Tokenspeicher- und Authentifizierungsprobleme mit Git-Anbietern behandelt.

Problem mit einer Richtlinie für bedingten Zugriff (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 Richtlinie für bedingten Zugriff in Microsoft Entra ID aktiviert.

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

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

Erlaubnisliste mit Microsoft Entra ID-Tokens

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 Listen zulassen, die die Verwendung von Remote-Repositorys einschränken.

Git-Ordnerverschlüsselung

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

GitHub-Tokenspeicher und -Zugriff

• Die Azure Databricks-Steuerungsebene 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 überwacht die Tokenverwendung. Andere Git-Dienste bieten möglicherweise auch die Serverüberwachung an.

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

Nein

Unterstützen Git-Ordner SSH?

Nein Git-Ordner unterstützen nur HTTPS.

Azure DevOps-Mandantenübergreifende Fehler

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

CI/CD und MLOps

In diesem Abschnitt wird erläutert, wie Sich Git-Vorgänge auf den Notizbuchzustand, MLflow-Experimente und die Auftragsausführung auswirken.

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, wodurch Git-Ordner von Databricks verwendet werden, um das vorhandene Notizbuch zu überschreiben. 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 niedrigeren 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 Datenverlust wird dauerhaft, wenn Sie innerhalb von 30 Tagen nicht auf den vorherigen Branch zugreifen.

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 Aufträgen während Git-Vorgängen

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 Aufträgen.

Ressourcen

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