Använda Git med Lakeflow-jobb

Processer kan hämta källkoden direkt från ett fjärr-Git-arkiv.

Följande aktivitetstyper stöder fjärranslutna Git-lagringsplatser:

• Notebooks
• Python skript
• SQL-filer
• data build tool -projekt (dbt)

Alla uppgifter i ett jobb måste referera till samma åtagande i fjärrarkivet. När en jobbkörning börjar tar Azure Databricks en ögonblicksbild av den angivna grenen eller incheckningen, så att alla aktiviteter i den körningen använder samma version av koden.

När du visar körningshistoriken för en aktivitet som kör kod som lagras på en fjärransluten Git-lagringsplats innehåller fönstret Aktivitetskörningsinformation Git-information, inklusive inchecknings-SHA som är associerad med körningen. Se Visa uppgiftshistorik.

Använda en Git-lagringsplatskälla jämfört med Git-mappar.

På den här sidan beskrivs uppgifter som kan hämta källkod direkt från en fjärransluten Git-lagringsplats. Arbetsytor stöder också en funktion som kallas Git-mappar, där en mapp i din arbetsyta synkroniseras med en Git-lagringsplats. En uppgift kan använda en Git-mapp som källa. Du måste dock hantera synkronisering med lagringsplatsen. Med hjälp av ett fjärr-Git-förråd enligt beskrivningen här hämtas automatiskt ny källkod om det är tillgängligt under jobbkörning.

Azure Databricks rekommenderar att du refererar till arbetsytesökvägar i Git-mappar endast för snabb iteration och testning under utveckling. För mellanlagrings- och produktionsjobb konfigurerar du uppgifter för att referera till en fjärransluten Git-lagringsplats i stället.

Konfigurera en Git-provider för ett jobb

Jobbgränssnittet har en dialogruta för att konfigurera en fjärransluten Git-lagringsplats. Den här dialogrutan är tillgänglig från fönstret Jobbinformation under Git-rubriken eller i alla aktiviteter som har konfigurerats för att använda en Git-provider. Om du vill komma åt dialogrutan klickar du på Lägg till Git-inställningar i fönstret Jobbinformation .

I Git-dialogrutan (märkt Git-information om den används under aktivitetskonfigurationen) anger du följande information:

• Url:en för Git-lagringsplatsen.
• Välj din Git-provider i listrutan.
• I fältet Git-referens anger du identifieraren för en gren, tagg eller incheckning som motsvarar den version av källkoden som du vill köra.
• Välj gren, tagg eller commit från listrutan.

Du måste bara ange något av följande:

• branch: Namnet på grenen, till exempel main.
• tag: Taggens namn, till exempel release-1.0.0.
• commit: Hashen för en specifik commit, till exempel e0056d01.

När du visar körningshistoriken för en aktivitet som kör kod som lagras på en fjärransluten Git-lagringsplats innehåller panelen Aktivitetskörningsinformation Git-information, inklusive inchecknings-SHA som är associerad med körningen. Se Visa uppgiftshistorik.

Gles utcheckning för stora lagringsplatser

För stora lagringsplatser kan du använda gles utcheckning för att endast importera specifika kataloger i stället för den fullständiga lagringsplatsen. Sparse checkout minskar utcheckningstiden samt resursanvändningen per jobbkörning.

Felaktig konfiguration kan dock orsaka cachefragmentering, vilket försämrar exekveringstiderna i hela arbetsytan. I det här avsnittet beskrivs kompromisser och problem som kan uppstå när du använder en glesare utcheckning.

Hur Azure Databricks cachelagrar lagringsplatsens utcheckningar

Azure Databricks cachelagrar varje Git-utcheckning baserat på fyra värden:

• Arbetsyta
• URL för lagringsplats
• Exakt incheckningshash
• Fingeravtryck av det glesa utcheckningsmönstret (den exakta uppsättningen av mappsökvägar)

Alla jobbexekveringar som matchar alla fyra kriterier återanvänder en cache-inlägg, som förblir giltigt i upp till en vecka. Om du till exempel har tre olika jobb och alla har samma villkor använder de samma cacheminne till lagringsplatsen tills det finns en ny incheckning (efter 1 vecka).

Varje unikt glesa utcheckningsmönster skapar ett separat fingeravtryck och därför en separat cachepost. Om 20 användare lägger till en anpassad mapp i sitt mönster skapar systemet 20 distinkta cachenycklar och importerar det delade mappträdet 20 gånger – vilket multiplicerar belastningen på din arbetsyta. Genom att skapa ett enda sparsamt utcheckningsmönster som inkluderar alla 20 mappar (där en av dessa fungerar som huvudmapp), kan en enda cache användas oftare och förbättra prestandan i dina jobb. Kompromissen är ett större antal filer i din utcheckning.

Bestäm om du vill använda en gles utcheckning

Aktivera endast gles utcheckning om ditt användningsfall uppfyller båda följande kriterier:

• Storlek: Lagringsplatsen är stor (till exempel överskrider den 2 500 filer).
• Stabil målinriktning: Målgrenen uppdateras sällan (till exempel ungefär en commit per timme eller mindre). Undvik grenar som ändras snabbt på grund av automatiserade CI/CD-arbetsflöden.

Om du använder en gles utcheckning bör din organisation också använda en eller båda av följande mönsterstrategier:

• Standardisering: Använd tre eller färre delade utcheckningsmönster i organisationen för att maximera cacheträffar.
• Mikroinriktning: Strukturera mönster så att var och en riktar sig mot ett litet antal filer. För bästa prestanda bör du rikta in dig på färre än 200 filer.

Dessa kan bidra till att minimera importfrekvensen.

Beräkna din importtakt

Innan du aktiverar gles utcheckning bör du uppskatta din planerade importfrekvens för filer per timme. Gränser gäller på arbetsytans nivå för alla jobb och användare.

Filer per timme = Jobbkörningar per timme × cachemissfrekvens × filer importerade per miss

Exempel: 180 körningar/timme × 10% missfrekvens × 6 000 filer/miss = 108 000 filer/timme

Jämför resultatet med dessa tröskelvärden:

Metodtips

Standardisera mönster

• Gör: Publicera tre eller färre godkända glesa mönster per lagringsplats. Delade mönster konsoliderar belastningen och maximerar cacheträffar.
• Tillåt inte: Anpassade mönster för varje lag. Även en extra mapp skapar en ny cachepost och utlöser en fullständig återimport.

Hantera commit-frekvens

• Gör: Peka jobb på en stabil versionsgren. Batch sammanfogas med schemalagda utgivningsfönster så att flera körningar delar samma cachelagrade commit.
• Gör inte: Använd glesa utcheckningar med ofta uppdaterade grenar som master eller main. Eftersom cachen baseras på den exakta commithashen ogiltigförklarar varje ny commit cacheminnet och orsakar en fullständig återimport för varje jobbutförande.

Hantera belastning

• Gör: Ta bort stora binärfiler, genererade artefakter och datafiler från källkontrollen för att minska lagringsplatsens storlek villkorslöst.
• Gör inte: Låt redundanta jobb köras med hög frekvens. Lägre triggerfrekvens för jobb som inte kräver kontinuerlig körning, fördröj scheman eller konsolidera jobb som delar samma utcheckning.

Hantera commit-aktivitet med en versionsgren

När arbeten riktar sig mot en snabb gren som master eller main, ändras commithash ofta, vilket orsakar cachemissar vid nästan varje körning. Om du använder en dedikerad versionsgren som uppdateras enligt ett fast schema förbättras cacheträffarna.

Genom att peka alla jobb på en utgivningsgren för varje timme, matchar alla körningar inom den timmen samma incheckningshash och delar samma cacheinmatning.

Så här konfigurerar du en versionsgren:

1. Skapa en långlivad gren (till exempel release-candidate) på din Git-lagringsplats.
2. Automatisera uppdatering av den här grenen så att den matchar master enligt ett fast schema, till exempel överst i varje timme.
3. Konfigurera dina Git-baserade jobb att använda release-candidate som deras mål-Git-referens.

Granska dessa kompromisser innan du implementerar:

Exempel: automatisera med GitHub Actions

Följande GitHub Actions-arbetsflöde automatiserar skapandet av en ny versionsgren varje timme.

Steg 1: Commita en .github/workflows/cut-release-branch.yml fil till ditt arkiv:

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

Steg 2: Utlös GitHub-åtgärden manuellt för att kontrollera att grenen release-candidate har skapats.

Steg 3: Uppdatera dina befintliga jobb så att de används release-candidate som Git-målreferens.

Aktivera gles utcheckning med hjälp av jobb-API:et

För att aktivera gles utcheckning, inkludera ett sparse_checkout block inuti git_source när du skapar eller uppdaterar ett jobb.

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

Varje sträng i patterns är en katalogsökväg i förhållande till lagringsplatsens rot. Alla filer i varje angiven katalog ingår i utcheckningen.