Lakeflow Jobs

Lakeflow Jobs je orchestrátor zabudovaný přímo v Azure Databricks. Job se skládá z jednoho nebo více tasků uspořádaných do DAG (Directed Acyclic Graph) — graf určuje pořadí a paralelismus. Minimální job potřebuje tři věci: task s logikou, compute, na kterém task poběží, a unikátní název.

Job vytvoříte v UI přes Jobs & Pipelines → Create → Job. Každý task má typ, který určuje, co se konfiguruje a kde to běží:

Vedle toho existují řídicí tasky If/else a For each pro větvení a iteraci uvnitř jobu. Kód tasku může žít na třech místech: ve workspace (rychlý start, vývoj), v Git repozitáři (job si při spuštění vezme snapshot konkrétního commitu — všechny tasky jobu sdílejí stejnou Git referenci) nebo v volume/cloud storage (pro Python skripty přes abfss:// URI).

U compute je dnes výchozí volbou serverless compute — Databricks spravuje infrastrukturu, nic nekonfigurujete a škáluje se automaticky. Classic jobs compute si vyberete, když potřebujete kontrolu nad verzí Sparku, typem instancí nebo knihovnami, které serverless nepodporuje. Když více tasků sdílí stejný cluster, cluster žije, dokud neskončí všechny — ušetříte start-up čas mezi tasky, ale platíte i za případné prostoje.

-- opravneni pro service principal, pod kterym job pobezi
GRANT SELECT, MODIFY ON TABLE telconnect.silver.cdr_clean TO `sp-cdr-pipeline`;
GRANT USE SCHEMA ON SCHEMA telconnect.silver TO `sp-cdr-pipeline`;

Závislosti definujete u tasku polem Depends on — tím vzniká DAG. Ke každé hraně navíc patří podmínka Run if, která říká, kdy se downstream task vůbec spustí:

Kdo čeká, že podmínky slouží jen na „happy path", přichází o nejužitečnější vzory: All done pro úklidové tasky, které musí běžet vždy, a At least one failed pro error-handling větev (zápis do incident tabulky, kompenzační logika).

Job parametry definujete na úrovni jobu jako key-value páry a jsou automaticky dostupné všem taskům. Notebooky je čtou přes widgety, Python skripty je dostanou jako argumenty příkazové řádky. V hodnotách parametrů můžete používat dynamic value references — hodnoty doplněné až při spuštění:

# notebook cte job parametr pres widget
processing_date = dbutils.widgets.get("processing_date")

# hodnota parametru v konfiguraci jobu muze byt dynamicka:
#   {{job.trigger.time.iso_date}}                          -> datum spusteni
#   {{job.trigger.table_update.updated_tables}}            -> ktere tabulky se zmenily
#   {{job.trigger.table_update.<cat.sch.tbl>.version}}     -> verze Delta tabulky

Trigger určuje, kdy job poběží. Vedle časového plánu (viz sekce 11.4) nabízí Lakeflow Jobs event-based triggery, které reagují na data, ne na hodiny. Trigger přidáte v Job details → Schedules & Triggers → Add trigger.

File arrival trigger hlídá cestu v Unity Catalog external location nebo volume (včetně podadresářů, rekurzivně) a spustí job, když se objeví nový soubor. Kontrola probíhá best-effort zhruba každou minutu. Přepsání existujícího souboru stejným jménem běh nevyvolá — dodávky souborů proto navrhujte s unikátními názvy.

Table update trigger sleduje jednu nebo více Unity Catalog tabulek (managed Delta/Iceberg, external Delta, streaming tables, materialized views i views nad nimi) a reaguje na inserty, updaty, merge i delete. U více tabulek volíte mezi Any table is updated (rychlá reakce) a All tables are updated (počká, až budou aktuální všechny zdroje).

Oba typy sdílejí dvě šikovné volby proti „trigger stormu": Minimum time between triggers (ochranná pauza po doběhnutí) a Wait after last change (odklad, který se resetuje s každou další změnou — dávkuje rychlé série updatů do jednoho běhu).

Continuous trigger drží job v nekonečné smyčce: jakmile běh skončí (i selháním), okamžitě startuje další. Hodí se pro near real-time zpracování; počítejte ale s průběžnou spotřebou compute.

Scheduled trigger má dvě podoby. Simple schedule zadáte jako interval („každých 12 hodin") — první běh si scheduler zvolí sám při uložení. Advanced schedule používá cron výraz se šesti až sedmi poli: sekundy, minuty, hodiny, den v měsíci, měsíc, den v týdnu, volitelně rok. Minimální interval mezi běhy je 10 sekund.

Časová zóna není detail. Zóny s letním časem (DST) způsobí, že hodinový job při přechodu jednou za rok přeskočí běh nebo se o hodinu posune. Pravidlo z praxe: reporty pro lidi plánujte v jejich lokální zóně (a přijměte DST posuny), technické pipeline vázané na UTC timestampy nebo přesné intervaly plánujte v UTC.

Co když běh trvá déle než interval? To řídí Maximum concurrent runs — pro joby zapisující do stejných tabulek jej nastavte na 1 — a chování při překročení limitu:

Dokumentace k frontě: „Queued runs consume no compute resources while waiting." Fronta je tedy zadarmo — platí se až samotný běh.

Notifikace konfigurujete na úrovni jobu (Job notifications) i jednotlivých tasků. K dispozici je pět typů událostí:

Cílem může být e-mail nebo system destination: Slack, Microsoft Teams, PagerDuty a generický HTTP webhook. System destinations musí nejdřív založit workspace admin v Admin Settings → Notifications; na job/task lze navěsit max. tři destinace na typ události.

{
  "event_type": "jobs.on_failure",
  "workspace_id": "your_workspace_id",
  "run": { "run_id": "run_id" },
  "job": { "job_id": "job_id", "name": "job_name" }
}

Největší nepřítel alertingu je alert fatigue — tým zavalený notifikacemi je přestane číst, včetně těch kritických. Osvědčené zásady: ztlumte notifikace pro skipnuté a zrušené běhy (Mute notifications for skipped/canceled runs — platí jen pro job-level, na taskách je nutné nastavit zvlášť), duration warning nastavujte podle historie běhů (job běžící typicky 30 minut varujte ve 45, ne v 35), a u tasků s retry zapněte Mute notifications until the last retry. A zdokumentujte, proč každý alert existuje a co má příjemce udělat.

Síťové výpadky a přechodné chyby cloudových služeb jsou v distribuovaných systémech normální provozní stav. Retry policy zajistí, že se job z takového selhání zotaví sám. Výchozí chování ale překvapí: většina jobů se bez explicitní konfigurace neretryuje. Výjimky jsou dvě — serverless joby mají ve výchozím stavu auto-optimalizované retry a continuous joby se restartují vždy, s exponential backoff algoritmem.

Retry nastavujete na úrovni tasku: počet pokusů a interval mezi nimi. Interval se počítá od startu selhaného běhu — při intervalu 60 s a tasku, který padl po 30 s, startuje retry 30 s po selhání. Timeout se přitom vztahuje na každý pokus zvlášť; vypršení timeoutu se počítá jako selhání a spotřebuje pokus.

U continuous jobů funguje exponential backoff takto: po překročení prahu po sobě jdoucích selhání job čeká, každé další selhání čekání prodlouží až do systémového maxima, a úspěšný běh (nebo běh bez selhání po prahovou dobu) sekvenci resetuje. Volbou Task retry mode (On failure / Never) řídíte, zda se selhané tasky zkusí znovu ještě uvnitř běhu. Klasické task-level retry politiky ani závislosti tasků continuous joby nepodporují.

Proti „zombie" taskům nasaďte Metric thresholds → Run duration: hodnota Warning pošle notifikaci, hodnota Timeout task ukončí se stavem Timed Out a předá ho retry logice.

V roli data engineera telekomunikační firmy TelConnect zautomatizujete pipeline zpracovávající Call Detail Records (CDR) přes bronze → silver → gold vrstvy: postavíte job se dvěma závislými tasky (notebook process_cdrs + SQL summarize_gold), dynamickým parametrem processing_date, file arrival triggerem nad volume, nočním cron schedulem, failure notifikacemi a retry politikou s timeoutem.

▶ Otevřít lab na GitHubu (EN) · Learn modul k tématu — s krátkými výukovými videy