Použití Git s úlohami Lakeflow

Úlohy mohou přímo kontrolovat zdrojový kód ze vzdáleného Git repozitáře.

Následující typy úloh podporují vzdálená úložiště Git:

  • Notebooks
  • skripty Python
  • Soubory SQL
  • projekty nástroje dbt (data build tool)

Všechny úkoly v úloze musí odkazovat na stejné potvrzení ve vzdáleném úložišti. Když se spustí úloha, Azure Databricks pořídí snímek zadané větve nebo potvrzení, aby všechny úlohy v tomto spuštění používaly stejnou verzi kódu.

Když zobrazíte historii spuštění úlohy, která spouští kód uložený ve vzdáleném úložišti Git, obsahuje podokno podrobností o spuštění úlohy podrobnosti o Gitu, včetně algoritmu SHA potvrzení přidruženého ke spuštění. Viz Historii spuštěných úloh.

Poznámka:

Úlohy nakonfigurované pro použití vzdáleného úložiště Git nemůžou zapisovat do souborů pracovního prostoru. Tyto úlohy musí zapisovat dočasná data do dočasného úložiště připojeného k uzlu ovladače a trvalá data do svazku nebo tabulky.

Zdroj úložiště Git vs. složky Git

Tato stránka popisuje úlohy, které můžou načíst zdrojový kód přímo ze vzdáleného úložiště Git. Pracovní prostory také podporují funkci s názvem Složky Gitu, kde se složka ve vašem pracovním prostoru synchronizuje s úložištěm Git. Úkol může jako zdroj použít složku Git. Synchronizaci s úložištěm ale musíte spravovat. Použití vzdáleného úložiště Git, jak je zde popsáno, automaticky načte nový zdroj( pokud je k dispozici) za běhu úlohy.

Azure Databricks doporučuje odkazovat na cesty k pracovním prostorům ve složkách Git pouze pro rychlou iteraci a testování během vývoje. Pro staging a produkční úkoly nakonfigurujte úkoly tak, aby odkazovaly na vzdálené úložiště Git.

Konfigurace poskytovatele Gitu pro úlohu

Uživatelské rozhraní úloh má dialogové okno pro konfiguraci vzdáleného úložiště Git. Toto dialogové okno je přístupné z podokna podrobností úlohy pod nadpisem Git nebo v libovolné úloze nakonfigurované pro použití poskytovatele Gitu. Chcete-li získat přístup k dialogovému okně, klikněte v podokně podrobností úlohy na tlačítko Přidat nastavení Gitu.

V dialogovém okně Git (označené jako Git informace pokud jsou při konfiguraci úkolu přístupné) zadejte následující podrobnosti:

  • Adresa úložiště Git URL.
  • V rozevíracím seznamu vyberte svého poskytovatele Gitu .
  • Do referenčního pole Gitu zadejte identifikátor větve, značky nebo potvrzení, který odpovídá verzi zdrojového kódu, kterou chcete spustit.
  • V rozevíracím seznamu vyberte větev, značku nebo potvrzení .

Musíte zadat pouze jednu z těchto možností:

  • branch: Název větve, například main.
  • tag: Název značky, například release-1.0.0.
  • commit: Hodnota hash konkrétního potvrzení, například e0056d01.

Poznámka:

V dialogovém okně se může zobrazit výzva s následujícími údaji: Chybí přihlašovací údaje Gitu pro tento účet. Přidejte přihlašovací údaje. Než ho použijete jako referenci, musíte nakonfigurovat vzdálené úložiště Git. Viz Konfigurace integrace Gitu pro složky Gitu.

Když zobrazíte historii spuštění úlohy, která spouští kód uložený ve vzdáleném úložišti Git, obsahuje podokno podrobností o spuštění úlohy podrobnosti o Gitu, včetně algoritmu SHA potvrzení přidruženého ke spuštění. Viz Historii spuštěných úloh.

Řídký výběr pro velká úložiště

U velkých úložišť můžete použít řídkou kontrolu k importu pouze konkrétních adresářů namísto celého úložiště. Řídké převzetí zkracuje čas převzetí a využití prostředků na spuštění úlohy.

Nesprávná konfigurace však může způsobit fragmentaci mezipaměti, což snižuje dobu provádění v celém pracovním prostoru. Tato část popisuje úskalí a problémy, které se mohou objevit při použití řídkého checkoutu.

Jak Azure Databricks ukládá do mezipaměti kontrolní body úložiště

Azure Databricks ukládá každou rezervaci Gitu do mezipaměti na základě čtyř hodnot:

  • Workspace
  • Adresa URL úložiště
  • Přesná hodnota hash potvrzení
  • Odtisk řídkého vzoru výběru (přesná sada cest ke složkám)

Každé spuštění úlohy, které odpovídá všem čtyř kritériím, znovu použije položku mezipaměti, která zůstane platná až po jeden týden. Pokud máte například 3 různé úlohy a všechny mají stejná kritéria, budou používat stejnou mezipaměť pro úložiště, dokud neproběhne nový commit (nebo po uplynutí 1 týdne).

Každý jedinečný vzor řídkého procházení vytvoří samostatný otisk, a proto samostatnou položku mezipaměti. Pokud každý z 20 uživatelů přidá do svého vzoru vlastní složku, systém vytvoří 20 jedinečných klíčů mezipaměti a naimportuje strom sdílených složek 20krát a vynásobí zatížení vašeho pracovního prostoru. Vytvoření jednoho řídkého způsobu rezervace, který zahrnuje všech 20 složek (například nadřazenou složku), umožňuje, aby jedna mezipaměť fungovala častěji a měla lepší výkon ve vašich úlohách. Kompromis je větší počet souborů v pokladně.

Rozhodněte se, jestli chcete použít řídký checkout.

Zapněte pouze řídký checkout, pokud váš případ použití splňuje obě následující kritéria:

  • Velikost: Úložiště je velké (například překračuje 2 500 souborů).
  • Stabilní cílení: Cílová větev se aktualizuje zřídka (například přibližně jedno potvrzení za hodinu nebo méně). Vyhněte se větvím, jež se rychle mění kvůli automatizovaným CI/CD pracovním postupům.

Pokud používáte řídký checkout, měla by vaše organizace také přijmout jednu nebo obě z následujících strategií návrhových vzorů:

  • Standardizace: K maximalizaci přístupů do mezipaměti použijte tři nebo méně vzorů sdílených kontrol v celé organizaci.
  • Mikrocílování: Strukturovat vzory tak, aby každý z nich cílil na malý počet souborů. Pokud chcete dosáhnout nejlepšího výkonu, zaměřte se na méně než 200 souborů.

To vám může pomoct minimalizovat míru importu.

Výpočet míry importu

Před povolením řídkého výběru odhadněte míru importu u předpokládaných souborů za hodinu. Omezení se vztahují na úrovni pracovního prostoru pro všechny úlohy a uživatele.

Soubory za hodinu = spuštění úlohy za hodinu × neúspěšná rychlost mezipaměti × importovaných souborů za miss

Faktor Co ho řídí
Spustení úloh za hodinu Četnost aktivačních událostí u všech uživatelů
Rychlost neúspěšné ukládání do mezipaměti Frekvence commitů v cílové větvi a počet jedinečných řídkých vzorů
Importované soubory podle miss Celková velikost úložiště nebo velikost podmnožiny při řídkém výběru

Příklad: 180 spuštění za hodinu × 10% míra chybovosti × 6 000 souborů na omyl = 108 000 souborů za hodinu

Porovnejte výsledek s těmito prahovými hodnotami:

Importované soubory za hodinu Očekávaný dopad pracovního prostředí
Pod 150.000 Normální provoz
150,000 – 300,000 Snížený výkon. U některých úloh může docházet ke zpožděním nebo selháním.
Více než 300 000 Úlohy nejsou spolehlivě dokončeny.

Osvědčené postupy

Standardizace vzorů

  • Do: Publikujte tři nebo méně schválených řídkých vzorů pro každé úložiště. Sdílené vzory konsolidují zatížení a maximalizují přístupy do mezipaměti.
  • Nepovolujte: Nepovolujte vlastní vzory pro jednotlivé týmy. Dokonce i jedna další složka vytvoří novou položku mezipaměti a aktivuje úplný opětovný import.

Správa frekvence změn potvrzení

  • Udělejte: Nasměrujte úlohy na stabilní větev vydané verze. Batch procesy se slučují do naplánovaných oken vydání, aby několik spuštění sdílelo stejný commit uložený v mezipaměti.
  • Vzhledem k tomu, že mezipaměť je založená na přesné hodnotě hash potvrzení, každé nové potvrzení mezipaměť zneplatní a způsobí úplný opětovný import pro každé spuštění úlohy.

Správa zatížení

  • Udělejte: Odeberte velké binární soubory, vygenerované artefakty a datové soubory ze správy zdrojového kódu, aby se velikost úložiště bezpodmínečně snížila.
  • Nenechávejte redundantní úlohy spuštěné ve vysoké frekvenci. Nižší frekvence spouštění pro úlohy, které nevyžadují průběžné spouštění, rozložit plány, nebo konsolidovat úlohy, které sdílejí stejné odbavení.

Řízení churnu commitů pomocí release větve

Když úlohy cílí na rychle se měnící větev, jako master nebo main, hash potvrzení se často mění, což způsobuje chybné ukládání do mezipaměti téměř při každém spuštění. Použití vyhrazené vývojové větve, která se aktualizuje podle pevného plánu, zvyšuje míru zásahů do mezipaměti.

Nasmerováním všech úloh na hodinovou vydávací větev, všechny běhy v rámci té hodiny odkážou na stejný hash commit a sdílejí stejnou mezipaměťovou položku.

Pro konfiguraci větve připravovaného vydání:

  1. Vytvořte v úložišti Git dlouhodobou větev (například release-candidate).
  2. Automatizujte aktualizaci této větve podle pevného plánu, aby odpovídala master, například na začátku každé hodiny.
  3. Nakonfigurujte úlohy založené na Gitu tak, aby se používaly release-candidate jako cílové referenční informace k Gitu.

Před implementací si projděte tyto kompromisy:

Zvážení Description
Prodleva při potvrzení Úlohy běží s kódem se zpožděním až do jedné hodiny za master. Přijatelné pro většinu dávkových úloh, ale nemusí vyhovovat úlohám vyžadujícím nejnovější commit.
Okno selhání Pokud úloha sestavení verze selže, větev se po tuto hodinu neaktualizuje a úlohy pokračují ve spuštění proti předchozímu potvrzení. Databricks doporučuje vytváření alertů na zastavenou úlohu.

Příklad: automatizace pomocí GitHub Actions

Následující pracovní postup GitHub Actions automatizovaně vytváří větev pro vydání každou hodinu.

Krok 1: Potvrzení .github/workflows/cut-release-branch.yml souboru do úložiště:

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: Ručně aktivujte akci GitHub a ověřte, že je vytvořena větev release-candidate.

Krok 3: Aktualizujte existující úlohy tak, aby se používaly release-candidate jako cílový odkaz na Git.

Povolení řídkého výběru pomocí rozhraní API úloh

Pokud chcete povolit řídké odhlášení, při vytváření nebo aktualizaci úlohy zahrňte sparse_checkout uvnitř bloku git_source.

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

Každý řetězec v patterns je cesta k adresáři vzhledem ke kořenovému adresáři úložiště. Všechny soubory v každém zadaném adresáři jsou součástí rezervace.

  • Last updated on