Jobs en orkestratie

Van pipeline naar proces

Een declaratieve pipeline ververst tabellen. Een bedrijfsproces doet meer: het wacht op een levering, ververst de tabellen, controleert het resultaat, publiceert een dashboard en meldt het aan iemand als het faalt. Lakeflow Jobs is de Databricks-service die die reeks orkestreert.

In deze les modelleren we een workflow als een graaf van taken, kiezen we triggers en stellen we de regels op die een job veilig maken om onbemand te draaien. Externe orkestrators behandelen we niet. Draait je organisatie er al een, dan gelden dezelfde ontwerpregels ook daar.

Wat een job is

Een job bevat een of meer taken. Taken kunnen van elkaar afhangen en vormen een gerichte acyclische graaf (DAG), die de Jobs-interface als graaf toont. De documentatie noemt drie tasktypen die je als eerste gebruikt: een notebooktaak, een pipelinetaak (die een Lakeflow-pipeline draait) en een Python-scripttaak. Er wordt verwezen naar een langere lijst met tasktypen. De authoring-interface ondersteunt ook besturingsstromen zoals if/else-vertakkingen en for-each-lussen, en jobs kunnen runtime-parameters aan taken doorgeven.

Een typische dagelijkse workflow:

1. Een pipelinetaak ververst bronze, silver en gold.
2. Een notebook- of scripttaak draait een reconciliatiecontrole tegen de brontotalen.
3. Een volgende taak ververst een dashboard of publiceert een share, maar alleen als stap 2 slaagde.

Omdat stap 3 van stap 2 afhangt, stopt een mislukte controle de publicatie. Die afhankelijkheid is de goedkoopste beveiliging van het hele platform.

Triggers

Een trigger start een job. De documentatie beschrijft twee families.

Kies een gebeurtenisgebaseerde trigger als de bron onregelmatig levert. Een schema dat om 02:00 draait en geen bestand vindt, verspilt een run. Een schema dat draait voor het late bestand binnen is, levert het rapport van gisteren als dat van vandaag.

Kies bij een schema altijd expliciet de tijdzone en schrijf die in de jobbeschrijving. Zomer- en wintertijd heeft carrières beëindigd.

Ontwerpregels voor onbemande jobs

Pas deze regels toe op elke job. Ze sluiten aan op onze delivery standards.

Idempotente taken. Een taak die twee keer draait, moet hetzelfde resultaat achterlaten als één keer. Declaratieve pipelines en MERGE-statements geven je dit. Alleen-toevoegen-statements zonder sleutel niet. Idempotentie maakt een herpoging veilig.

Draai als service principal. Jobs draaien als service principal met de minste rechten voor het werk, nooit als persoon. Een persoon verlaat het bedrijf en de job stopt. Definieer de identiteit in de bundle (les 5).

Kleine, benoemde taken. Eén taak, één doel. Een taak die ingestie, opschoning en publicatie in één notebook doet, kan niet gedeeltelijk opnieuw draaien en zijn foutmelding is "er is iets misgegaan". Splits taken langs de lagen van les 1.

Timeouts en herpogingen. Geef elke taak een timeout, zodat een vastgelopen run de volgende niet blokkeert. Gebruik een beperkt aantal herpogingen voor taken die om tijdelijke redenen falen, zoals een netwerkfout, en geen voor taken die om logische redenen falen, want een herpoging faalt dan op dezelfde manier.

Meldingen. De documentatie noemt meldingen per e-mail of webhook wanneer een job faalt of te lang draait. Stuur fouten naar een kanaal waar iemand naar kijkt en noem de jobeigenaar in het bericht. Een melding naar een mailbox die niemand leest, is geen melding.

Parameters, geen kopieën. Geef de omgeving, het datumbereik of de bronnaam mee als parameters. Kopieer niet een job per omgeving. De bundle geeft elke omgeving dezelfde job met andere waarden.

Geen geheimen in parameters. Lees geheimen uit een secret scope op basis van Key Vault, of vermijd ze met managed identities.

Een voorbeeld van afhankelijkheden

De graaf hieronder is de vorm van de meeste van onze dagelijkse workflows.

wait_for_files (trigger bij aankomst van bestanden)
   -> run_pipeline (pipelinetaak: bronze, silver, gold)
        -> reconcile (scripttaak: vergelijk aantallen met het bronrapport)
             -> publish_share (alleen als reconcile slaagde)
             -> notify_owner (draait bij falen van een voorgaande taak)

De reconcile-taak vergelijkt totalen met een onafhankelijk getal: het controlebestand van de leverancier of een telling uit het bronsysteem. Een pipeline die technisch slaagt maar de helft van de rijen laadt, is de fout die expectations alleen niet vangen.

Ken de limieten

De documentatie noemt limieten voor Lakeflow Jobs: 2.000 gelijktijdige taskruns per workspace, 1.000 taken per job en 12.000 opgeslagen jobs per workspace. De meeste teams komen er nooit bij. Groeit één job richting 1.000 taken, dan is het ontwerp het probleem en splits je hem in jobs per domein.

Compute voor jobs

Jobs kunnen op serverless compute of op klassieke jobclusters draaien. De keuze behandelen we in les 7. Voor nu geldt: draai een geplande job nooit op een all-purpose cluster dat ook een persoon gebruikt. Een persoon die een notebook sluit, mag nooit een nachtelijke load kunnen beïnvloeden.

Een job bewaken

Volg drie getallen per job: slagingspercentage, duur ten opzichte van het gebruikelijke bereik en tijd sinds het laatste succes. Een job die stilletjes niet meer wordt getriggerd toont geen fouten, alleen een groeiende afstand tot het laatste succes. Alarmeer op die afstand. Dit werken we uit in les 6.

Veelgemaakte fouten

• Cron-denken. Een schema dat aanneemt dat de data er is.
• Eén reuzentaak. Je kunt hem niet zien, herproberen of erover redeneren.
• Een persoonlijke identiteit als run-as. De job sterft met het account.
• Geen poort stroomafwaarts. Het dashboard ververst bovenop een mislukte load.
• Logische fouten herproberen. Het verbrandt compute en vertraagt de alert.

Samenvatting

Modelleer de workflow als een graaf van kleine taken met afhankelijkheden, kies gebeurtenisgebaseerde triggers voor onregelmatige bronnen, maak taken idempotent, draai als service principal, stel timeouts, herpogingen en meldingen in en bewaak publicatie met een reconciliatietaak.

Volgende les: bundles, die dit alles omzetten in code die door dev, test, acceptatie en productie beweegt.