Verwenden von Git mit Lakeflow-Aufträgen

Aufgaben können Quellcode direkt aus einem Remote-Git-Repository auschecken.

Die folgenden Aufgabentypen unterstützen Remote-Git-Repositorys:

Notizbücher
Python Skripts
SQL-Dateien
Data Build Tool (dbt)-Projekte

Alle Aufgaben in einem Auftrag müssen auf dasselbe Commit im Remote-Repository verweisen. Wenn eine Auftragsausführung beginnt, erstellt Azure Databricks eine Momentaufnahme des angegebenen Branchs oder Commits, sodass alle Aufgaben in dieser Ausführung dieselbe Version des Codes verwenden.

Wenn Sie den Ausführungsverlauf einer Aufgabe anzeigen, die Code ausführt, der in einem Remote-Git-Repository gespeichert ist, enthält der Aufgabenausführungsdetailsbereich Git-Details, einschließlich des commit-SHA, das der Ausführung zugeordnet ist. Weitere Informationen finden Sie unter Anzeigen des Ausführungsverlaufs von Aufgaben.

Hinweis

Aufgaben, die für die Verwendung eines Git-Remoterepository konfiguriert sind, können nicht in Arbeitsbereichsdateien geschrieben werden. Diese Aufgaben müssen temporäre Daten in einen ephemeren Speicher schreiben, der an den Treiberknoten angehängt ist, und persistente Daten in ein Volume oder eine Tabelle schreiben.

Git-Repositoryquelle im Vergleich zu Git-Ordnern

Auf dieser Seite werden Aufgaben erläutert, die Quellcode direkt aus einem Git-Remote-Repository abrufen können. Arbeitsbereiche unterstützen auch ein Feature namens Git-Ordner, bei dem ein Ordner in Ihrem Arbeitsbereich mit einem Git-Repository synchronisiert wird. Eine Aufgabe kann einen Git-Ordner als Quelle verwenden. Sie müssen jedoch die Synchronisierung mit dem Repository verwalten. Wenn Sie ein Git-Remote-Repository verwenden, wie hier beschrieben, wird bei der Ausführung automatisch neuer Quellcode abgerufen, sofern verfügbar.

Azure Databricks empfiehlt das Verweisen auf Arbeitsbereichspfade in Git-Ordnern nur für schnelle Iterationen und Tests während der Entwicklung. Konfigurieren Sie für Staging- und Produktionsaufträge Aufgaben so, dass sie stattdessen auf ein Remote-Git-Repository verweisen.

Konfigurieren eines Git-Anbieters für einen Auftrag

Die Benutzeroberfläche für Jobs enthält einen Dialog zur Konfiguration eines Git-Remoterepository. Auf dieses Dialogfeld kann über den Bereich " Auftragsdetails " unter der Überschrift "Git " oder in einer aufgabe zugegriffen werden, die für die Verwendung eines Git-Anbieters konfiguriert ist. Um auf das Dialogfeld zuzugreifen, klicken Sie im Bereich "Auftragsdetails" auf "Git-Einstellungen hinzufügen".

Geben Sie im Git-Dialogfeld (bezeichnete Git-Informationen , wenn während der Aufgabenkonfiguration auf sie zugegriffen wird) die folgenden Details ein:

Die Git-Repository-URL.
Wählen Sie Ihren Git-Anbieter aus der Dropdownliste aus.
Geben Sie in das Feld Git-Referenz die Kennung einer Verzweigung, eines Tags oder einer Übertragung ein, die der Version des Quellcodes entspricht, die Sie ausführen möchten.
Wählen Sie Branch, Tag oder Commit aus der Dropdownliste aus.

Sie müssen nur eine der folgenden Optionen angeben:

Branch: der Name der Verzweigung, z. B. main.
tag: Der Name des Tags, release-1.0.0z. B. .
Committ: der Hash eines bestimmten Commits z. B. e0056d01.

Hinweis

Das Dialogfeld fordert Sie möglicherweise mit folgendem Hinweis auf: Git-Anmeldeinformationen für dieses Konto fehlen. Anmeldeinformationen hinzufügen. Sie müssen ein Git-Remoterepository konfigurieren, bevor Sie es als Referenz verwenden. Siehe Konfigurieren der Git-Integration für Git-Ordner.

Sparse Checkout für große Repositorys

Bei großen Repositorys können Sie nur wenige Auscheckvorgänge verwenden, um nur bestimmte Verzeichnisse anstelle des vollständigen Repositorys zu importieren. Das teilweise Auschecken reduziert die Auscheckzeit und die Ressourcenauslastung pro Auftrag.

Eine unsachgemäße Konfiguration kann jedoch zu einer Fragmentierung des Caches führen, wodurch die Ausführungszeiten im gesamten Arbeitsbereich beeinträchtigt werden. In diesem Abschnitt werden Trade-Offs und Probleme beschrieben, die beim Verwenden von sparse Checkout auftreten können.

Wie Azure Databricks Repository-Auscheckvorgänge zwischenspeichert

Azure Databricks speichert jeden Git-Checkout basierend auf vier Werten.

Workspace
Repository-URL
Der exakte Commit-Hash
Fingerabdruck des Sparse Checkout-Musters (die genaue Gruppe von Ordnerpfaden)

Jeder Auftrag, der allen vier Kriterien entspricht, verwendet einen Cacheeintrag, der bis zu einer Woche gültig bleibt. Wenn Sie beispielsweise drei verschiedene Aufträge haben und alle über dieselben Kriterien verfügen, verwenden sie denselben Cache für das Repository, bis ein neuer Commit vorhanden ist (oder nach 1 Woche).

Jedes eindeutige Sparse Checkout-Muster erstellt einen separaten Fingerabdruck und somit einen separaten Cacheeintrag. Wenn jeweils 20 Benutzer ihrem Muster einen benutzerdefinierten Ordner hinzufügen, erstellt das System 20 unterschiedliche Cacheschlüssel und importiert die Struktur des freigegebenen Ordners 20 Mal und multipliziert die Last in Ihrem Arbeitsbereich. Das Erstellen eines einzelnen Sparse Checkout-Musters, das alle 20 Ordner umfasst (z. B. ein übergeordneter Ordner ist), ermöglicht es, dass ein einzelner Cache häufiger funktioniert und eine bessere Leistung in Ihren Aufträgen aufweist. Der Kompromiss ist eine größere Anzahl von Dateien in Ihrem Checkout.

Entscheiden Sie, ob Sie das Sparse-Checkout verwenden möchten.

Aktivieren Sie nur den Sparse Checkout, wenn Ihr Anwendungsfall beide der folgenden Kriterien erfüllt:

Größe: Ihr Repository ist groß (z. B. überschreitet es 2.500 Dateien).
Stabiles Targeting: Der Zielbranch wird selten aktualisiert (z. B. etwa ein Commit pro Stunde oder weniger). Vermeiden Sie Verzweigungen, die sich aufgrund automatisierter CI/CD-Workflows schnell ändern.

Wenn Sie Sparse Checkout verwenden, sollte Ihre Organisation auch eine oder beide der folgenden Musterstrategien anwenden:

Standardisierung: Verwenden Sie drei oder weniger gemeinsame Checkout-Muster in der gesamten Organisation, um Cachetreffer zu maximieren.
Mikroadressierung: Strukturieren Sie Muster so, dass jedes auf eine kleine Anzahl von Dateien abzielt. Um eine optimale Leistung zu erzielen, richten Sie sich auf weniger als 200 Dateien.

Dies kann dazu beitragen, die Importrate zu minimieren.

Berechnen der Importrate

Bevor Sie das Auschecken mit geringem Aufwand aktivieren, schätzen Sie die projizierte Importrate für Dateien pro Stunde . Grenzwerte gelten auf Arbeitsbereichsebene für alle Aufträge und Benutzer.

Dateien pro Stunde = Auftragsausführungen pro Stunde × Cachefehlerrate × Importierte Dateien pro Fehler

Faktor	Was dies steuert
Auftragsausführungen pro Stunde	Triggerhäufigkeit für alle Benutzer
Cachefehlerrate	Commithäufigkeit im Zielbranch und Anzahl eindeutiger Sparse-Muster
Importierte Dateien pro Fehler	Gesamte Repositorygröße oder Größe der Sparse Checkout-Teilmenge

Beispiel: 180 Vorgänge/Stunde × 10% Fehlerquote × 6.000 Dateien/Fehler = 108.000 Dateien/Stunde

Vergleichen Sie Ihr Ergebnis mit diesen Schwellenwerten:

Pro Stunde importierte Dateien	Erwartete Arbeitsbereichswirkung
Unter 150.000	Normaler Vorgang
150,000 – 300,000	Beeinträchtigte Leistung. Bei einigen Aufträgen treten möglicherweise Verzögerungen oder Fehler auf.
Über 300.000	Aufträge werden nicht zuverlässig abgeschlossen.

Bewährte Methoden

Standardisieren von Mustern

Do: Veröffentlichen Sie höchstens drei genehmigte Sparse-Muster pro Repository. Gemeinsame Muster konsolidieren die Ladung und maximieren Cachetreffer.
Nicht: Benutzerdefinierte Muster pro Team zulassen. Selbst ein zusätzlicher Ordner erstellt einen neuen Cacheeintrag und löst einen vollständigen erneuten Import aus.

Commit-Fluktuation verwalten

Do: Weisen Sie Jobs einem stabilen Release-Branch zu. Fassen Sie Merges in geplanten Releasefenstern zusammen, sodass mehrere Ausführungen denselben zwischengespeicherten Commit gemeinsam nutzen.
Nicht empfohlen: Verwenden Sie Sparse Checkouts mit häufig aktualisierten Branches wie master oder main. Da der Cache auf dem genauen Commit-Hash basiert, wird der Cache durch jeden neuen Commit ungültig und für jeden Auftrag wird ein vollständiger erneuter Import ausgeführt.

Last verwalten

Do: Entfernen Sie große Binärdateien, generierte Artefakte und Datendateien aus der Quellcodeverwaltung, um die Repositorygröße bedingungslos zu reduzieren.
Nicht: Lassen Sie redundante Aufträge mit hoher Frequenz laufen. Verringern Sie die Triggerhäufigkeit für Aufträge, die keine kontinuierliche Ausführung erfordern, staffeln Sie Zeitpläne, oder konsolidieren Sie Aufträge, die denselben Checkout gemeinsam nutzen.

Verwalten von Commit-Churn mit einem Releasebranch

Wenn Aufträge auf einen sich schnell ändernden Branch wie master oder main abzielen, ändert sich der Commithash häufig, was bei fast jeder Ausführung zu Cachefehlern führt. Die Verwendung eines dedizierten Releasebranchs, der nach einem festen Zeitplan aktualisiert wird, verbessert die Cachetrefferraten.

Indem alle Aufträge auf einen stündlichen Releasebranch verweisen, werden alle Ausführungen innerhalb dieser Stunde in denselben Commithash aufgelöst und nutzen denselben Cacheeintrag gemeinsam.

So konfigurieren Sie einen Release-Branch:

Erstellen Sie eine langlebige Verzweigung (z. B. release-candidate) in Ihrem Git-Repository.
Automatisieren Sie die Aktualisierung dieses Branchs, damit er nach einem festen Zeitplan, z. B. zu jeder vollen Stunde, mit master übereinstimmt.
Konfigurieren Sie Ihre Git-basierte Aufträge, damit sie release-candidate als Ziel-Git-Referenz verwenden.

Überprüfen Sie diese Kompromisse vor der Implementierung:

Überlegung	Beschreibung
Commit-Verzögerung	Aufträge werden für Code ausgeführt, der bis zu einer Stunde hinter `master` liegt. Akzeptabel für die meisten Batch-Prozesse, aber möglicherweise nicht geeignet für Prozesse, die den neuesten Commit benötigen.
Fehlerfenster	Wenn der Release-Cut-Auftrag fehlschlägt, wird der Branch für diese Stunde nicht aktualisiert, und Aufträge werden weiterhin für den vorherigen Commit ausgeführt. Databricks empfiehlt, Warnungen für den Cut-Auftrag einzurichten.

Beispiel: Automatisieren mit GitHub Actions

Der folgende GitHub Actions-Workflow automatisiert einen stündlichen Releasebranch-Cut.

Schritt 1: Committen Sie eine .github/workflows/cut-release-branch.yml Datei in Ihr Repository:

name: Cut Hourly Release Candidate

on:
  schedule:
    - cron: '0 * * * *'
  workflow_dispatch:

jobs:
  update-branch:
    runs-on: ubuntu-latest
    permissions:
      contents: write

    steps:
      - name: Checkout main branch
        uses: actions/checkout@v4
        with:
          ref: main
          fetch-depth: 0

      - name: Update release-candidate branch
        run: |
          git push origin HEAD:release-candidate --force

Step 2: Lösen Sie die GitHub Aktion manuell aus, um zu überprüfen, ob die release-candidate Branch erstellt wird.

Schritt 3: Aktualisieren Sie Ihre vorhandenen Aufträge so, dass sie als Git-Zielreferenz verwendet werden release-candidate .

Sparse Checkout mithilfe der Jobs API aktivieren

Um Sparse Checkout zu aktivieren, fügen Sie beim Erstellen oder Aktualisieren eines Auftrags einen sparse_checkout-Block in git_source ein:

{
  "git_source": {
    "git_url": "https://github.com/example/my-repo",
    "git_provider": "gitHub",
    "git_branch": "release-candidate",
    "sparse_checkout": {
      "patterns": ["src/models", "src/utils"]
    }
  }
}

Jede Zeichenfolge in patterns ist ein Verzeichnispfad relativ zum Repositorystamm. Alle Dateien in jedem angegebenen Verzeichnis sind im Auschecken enthalten.

Feedback

War diese Seite hilfreich?

Last updated on 2026-07-06