Git gebruiken met Lakeflow-taken

Taaktaken kunnen broncode rechtstreeks vanuit een externe Git-opslagplaats uitchecken.

De volgende taaktypen ondersteunen externe Git-opslagplaatsen:

• Notitieboekjes
• Python-scripts
• SQL-bestanden
• dbt-projecten (data build tool)

Alle taken binnen een opdracht moeten naar dezelfde commit in de externe opslagplaats verwijzen. Wanneer een taakuitvoering begint, maakt Azure Databricks een momentopname van de opgegeven vertakking of doorvoering, zodat alle taken in die uitvoering dezelfde versie van de code gebruiken.

Wanneer u de uitvoeringsgeschiedenis van een taak bekijkt die code uitvoert die is opgeslagen in een externe Git-opslagplaats, bevat het detailvenster Taakuitvoering Git-details, inclusief de doorvoer-SHA die is gekoppeld aan de uitvoering. Zie De uitvoeringsgeschiedenis van de taak weergeven.

Een Git-opslagplaats gebruiken versus Git-mappen.

Op deze pagina worden taken besproken die broncode rechtstreeks vanuit een externe Git-opslagplaats kunnen ophalen. Werkruimten ondersteunen ook een functie met de naam Git-mappen, waarbij een map in uw werkruimte wordt gesynchroniseerd met een Git-opslagplaats. Een taak kan een Git-map als bron gebruiken. U moet echter de synchronisatie met de opslagplaats beheren. Als u een externe Git-opslagplaats gebruikt, zoals hier wordt beschreven, wordt er automatisch een nieuwe bron opgehaald, indien beschikbaar, tijdens de uitvoering van de taak.

Azure Databricks raadt u aan om tijdens de ontwikkeling alleen te verwijzen naar werkruimtepaden in Git-mappen voor snelle iteratie en testen. Voor faserings- en productietaken configureert u in plaats daarvan taken om te verwijzen naar een externe Git-opslagplaats.

Een Git-provider configureren voor een taak

De gebruikersinterface voor taken heeft een dialoogvenster voor het configureren van een externe Git-opslagplaats. Dit dialoogvenster is toegankelijk vanuit het deelvenster Taakdetails onder de Git-kop of in een taak die is geconfigureerd voor het gebruik van een Git-provider. Klik op Git-instellingen toevoegen in het deelvenster Taakdetails om het dialoogvenster te openen.

Voer in het Git-dialoogvenster (gelabelde Git-gegevens indien geopend tijdens de taakconfiguratie) de volgende gegevens in:

• De URL van de Git-opslagplaats.
• Selecteer uw Git-provider in de vervolgkeuzelijst.
• Voer in het veld Git-verwijzing de id in voor een vertakking, tag of doorvoer die overeenkomt met de versie van de broncode die u wilt uitvoeren.
• Selecteer vertakking, tag of doorvoer in de vervolgkeuzelijst.

U moet slechts een van de volgende opgeven:

• branch: De naam van de vertakking, bijvoorbeeld main.
• tag: de naam van de tag, bijvoorbeeld release-1.0.0.
• commit: De hash van een specifieke doorvoer, bijvoorbeeld e0056d01.

Wanneer u de uitvoeringsgeschiedenis van een taak bekijkt die code uitvoert die is opgeslagen in een externe Git-opslagplaats, bevat het deelvenster Taakuitvoeringsgegevens Git-details, inclusief de doorvoer-SHA die is gekoppeld aan de uitvoering. Zie De uitvoeringsgeschiedenis van de taak weergeven.

Sparse uitchecken voor grote opslagplaatsen

Voor grote repositories kunt u sparse checkout gebruiken om alleen specifieke mappen te importeren in plaats van de volledige repository. Het verminderen van uitchecktijd en middelengebruik per taakuitvoering wordt gerealiseerd door een sparse checkout.

Een onjuiste configuratie kan echter leiden tot fragmentatie van de cache, waardoor de uitvoeringstijden in uw hele werkruimte afnemen. In deze sectie worden trade-offs en problemen besproken die zich kunnen voordoen bij het gebruik van sparse checkout.

Hoe Azure Databricks repository-uitcheckingen cachet

Azure Databricks slaat elke Git-betaling in de cache op op basis van vier waarden:

• Workspace
• URL van opslagplaats
• Exacte doorvoerhash
• Vingerafdruk van het sparse checkout-patroon (de precieze set mappaden)

Elke taakuitvoering die voldoet aan alle vier de criteria, hergebruikt een cachevermelding, die maximaal één week geldig blijft. Als u bijvoorbeeld drie verschillende taken hebt en ze allemaal dezelfde criteria hebben, gebruiken ze dezelfde cache voor de opslagplaats totdat er een nieuwe doorvoering is (van na 1 week).

Elke unieke sparse checkout-patroon creëert een aparte vingerafdruk en daarmee een aparte cache-entry. Als 20 gebruikers elk een aangepaste map aan hun patroon toevoegen, maakt het systeem 20 afzonderlijke cachesleutels en importeert de structuur van de gedeelde map 20 keer, waardoor de belasting van uw werkruimte wordt vermenigvuldigd. Door één sparse-uitcheckpatroon te maken dat alle 20 mappen bevat (bijvoorbeeld een bovenliggende map), kan één cache vaker werken en betere prestaties hebben in uw taken. De afweging is een groter aantal bestanden in uw kassa.

Bepalen of gebruik gemaakt moet worden van sparse checkout

Schakel sparse checkout alleen in als uw usecase voldoet aan beide van de volgende criteria:

• Grootte: Uw opslagplaats is groot (bijvoorbeeld groter dan 2500 bestanden).
• Stabiele doelen: De doelvertakking wordt zelden bijgewerkt (bijvoorbeeld ongeveer één doorvoer per uur of minder). Vermijd vertakkingen die snel veranderen door geautomatiseerde CI/CD-werkstromen.

Als u sparse checkout gebruikt, moet uw organisatie ook een of beide van de volgende patroonstrategieën gebruiken:

• Standaardisatie: gebruik drie of minder gedeelde betaalpatronen in de hele organisatie om cachetreffers te maximaliseren.
• Micro-targeting: Structureer patronen zodat elk zich op een klein aantal bestanden richt. Voor de beste prestaties richt u zich op minder dan 200 bestanden.

Dit kan helpen bij het minimaliseren van uw importsnelheid.

Uw importsnelheid berekenen

Voordat u sparse checkout inschakelt, schat u de verwachte importsnelheid van bestanden per uur. Limieten gelden op werkruimteniveau voor alle taken en gebruikers.

Bestanden per uur = Taakuitvoeringen per uur × aantal cachemissers × bestanden geïmporteerd per miss

Voorbeeld: 180 uitvoeringen per uur × 10% aantal gemiste bestanden × 6.000 bestanden/miss = 108.000 bestanden/uur

Vergelijk uw resultaat met deze drempelwaarden:

Best practices

Patronen standaardiseren

• Do: Publiceer drie of minder goedgekeurde schaarse patronen per opslagplaats. Gedeelde patronen consolideren werkbelasting en maximaliseren cachetreffers.
• Niet: Aangepaste patronen per team toestaan. Zelfs één extra map maakt een nieuwe cachevermelding en activeert een volledige herimport.

Doorvoerverloop beheren

• Do: Wijs taken aan bij een stabiele releasebranch. Batches worden samengevoegd in geplande releasevensters, zodat meerdere uitvoeringen dezelfde commit in de cache delen.
• Niet gebruik: geen sparse checkouts met regelmatig bijgewerkte vertakkingen zoals master of main. Omdat de cache is gebaseerd op de exacte doorvoerhash, maakt elke nieuwe doorvoer de cache ongeldig en wordt voor elke taakuitvoering een volledige herimport uitgevoerd.

Laadbeheer

• Do: Verwijder grote binaire bestanden, gegenereerde artefacten en gegevensbestanden uit broncodebeheer om de grootte van de opslagplaats onvoorwaardelijke te verminderen.
• Niet: Zorg ervoor dat redundante taken niet met hoge frequentie worden uitgevoerd. Verlaag de triggerfrequentie voor taken die geen voortdurende uitvoering vereisen, werk met gefaseerde schema's, of consolideer taken die dezelfde controle delen.

Doorvoerverloop beheren met een releasevertakking

Wanneer taken gericht zijn op een snel bewegende vertakking zoals master of main, verandert de commit-hash regelmatig, waardoor de cache daardoor bij bijna elke uitvoering mist. Het gebruik van een toegewezen releasebranch die op een vast schema wordt bijgewerkt, verbetert de cachetreffers.

Door alle opdrachten naar een uurlijkse releasevertakking aan te wijzen, worden alle uitvoeringen binnen dat uur omgezet naar dezelfde commit-hash en delen dezelfde cache-entry.

Een releasebranch configureren:

1. Maak een permanente vertakking (bijvoorbeeld release-candidate) in uw Git-opslagplaats.
2. Automatiseer het bijwerken van deze branch zodat deze overeenkomt met master volgens een vast schema, zoals het begin van elk uur.
3. Configureer uw door Git ondersteunde taken voor gebruik release-candidate als doelverwijzing voor Git.

Bekijk deze afwegingen voordat u implementeert:

Voorbeeld: automatiseren met GitHub Actions

De volgende GitHub Actions workflow automatiseert het aanmaken van een release-branch op uur basis.

Stap 1: Een bestand doorvoeren .github/workflows/cut-release-branch.yml in uw opslagplaats:

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: activeer de GitHub-actie handmatig om te controleren of de vertakking release-candidate is gemaakt.

Stap 3: Werk uw bestaande taken bij om release-candidate als doel-Git-verwijzing te gebruiken.

Sparse checkout inschakelen met behulp van de Jobs API

Als u spaarzaam uitchecken wilt inschakelen, plaatst u een sparse_checkout blok binnen git_source bij het maken of bijwerken van een taak.

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

Elke tekenreeks in patterns is een directorypad ten opzichte van de hoofdmap van de opslagplaats. Alle bestanden in elke opgegeven map zijn opgenomen in het uitchecken.