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 ein Arbeitsablauf gestartet wird, erstellt Azure Databricks eine Momentaufnahme der angegebenen Verzweigung oder eines Commits, sodass alle Aufgaben dieses Ausführungsprozesses 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.

Verwenden einer 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 aufgaben für Staging- und Produktionsaufträge, um stattdessen auf ein Git-Remote-Repository zu 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.

Wenn Sie den Ausführungsverlauf einer Aufgabe anzeigen, die in einem Git-Remoterepository gespeicherten Code ausführt, enthält der Bereich Taskausführungsdetails Git-Details – einschließlich der Commit-SHA, die der Ausführung zugeordnet ist. Weitere Informationen finden Sie unter Anzeigen des Ausführungsverlaufs von Aufgaben.

Geringes Auschecken 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 Menge der Ordnerpfade)

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

Jedes eindeutige Spars-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 – multipliziert die Last in Ihrem Arbeitsbereich. Das Erstellen eines einzelnen sparse Checkout-Musters, das alle 20 ihrer Ordner enthält (z. B. ein übergeordneter Ordner), ermöglicht es einem einzelnen Cache, häufiger zu arbeiten und eine bessere Leistung in Ihren Aufträgen zu erzielen. 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).
• Stabile Zielausrichtung: Der Zielzweig 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 einen „sparse Checkout“ verwenden, sollte Ihre Organisation auch eine oder beide der folgenden strategischen Muster einführen:

• 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 = Aufträge pro Stunde × Cachefehlerrate × Pro Fehler importierte Dateien

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

Vergleichen Sie Ihr Ergebnis mit diesen Schwellenwerten:

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. Batch-Operationen werden in geplanten Releasefenstern zusammengeführt, sodass mehrere Ausführungen denselben zwischengespeicherten Commit gemeinsam nutzen.
• Nicht: Verwenden Sie sparsame Auscheckvorgänge mit häufig aktualisierten Verzweigungen 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. Niedrigere Triggerhäufigkeit für Aufträge, für die keine kontinuierliche Ausführung erforderlich ist, gestaffelte Zeitpläne oder Konsolidieren von Aufträgen, die das gleiche Auschecken aufweisen.

Verwalten von Commit-Abwanderungen mit einer Release-Verzweigung

Wenn Aufträge auf einen schnell aktualisierenden Branch wie master oder main abzielen, ändert sich der Commit-Hash häufig, was zu Cache-Misses bei fast jeder Ausführung führt. Die Verwendung eines dedizierten Release branch, der nach einem festen Zeitplan aktualisiert wird, verbessert die Trefferraten des Caches.

Wenn Sie alle Aufträge auf eine stündliche Release-Branch verweisen, werden alle Läufe innerhalb dieser Stunde in den gleichen Commit-Hash aufgelöst und verwenden denselben Cache-Eintrag.

So konfigurieren Sie einen Release-Branch:

1. Erstellen Sie eine langlebige Verzweigung (z. B. release-candidate) in Ihrem Git-Repository.
2. Automatisieren Sie das Aktualisieren dieser Verzweigung, um diese mit master nach einem festen Zeitplan abzugleichen, z. B. zu jeder vollen Stunde.
3. Konfigurieren Sie Ihre Git-basierte Aufträge, damit sie release-candidate als Ziel-Git-Referenz verwenden.

Überprüfen Sie diese Kompromisse vor der Implementierung:

Beispiel: Automatisieren mit GitHub Actions

** Der folgende GitHub Actions-Workflow automatisiert jede Stunde das Erstellen eines Release-Branches.

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 das spärliche Auschecken zu aktivieren, schließen Sie beim Erstellen oder Aktualisieren eines Jobs 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.