Monitoring, troubleshooting a optimalizace

Provoz lakehouse v produkci není jen o tom, že pipeline doběhne. Je o tom, že doběhne za rozumné peníze a že se o problému dozvíte dřív než finanční oddělení. Jediný zapomenutý interaktivní cluster běžící přes víkend umí vygenerovat překvapivě vysoký účet — a naopak poddimenzovaný cluster znamená pomalé joby a nedodržená SLA. Cílem monitoringu není minimalizovat náklady za každou cenu, ale napasovat zdroje přesně na workload.

Azure Databricks nabízí tři vrstvy pozorovatelnosti, které se doplňují: okamžité metriky ve workspace, historická data v system tables a centralizované logy v Azure Log Analytics.

Metriky clusterů a SQL warehousů

Nativní rozhraní metrik najdete u každého all-purpose i job clusteru: Compute → vybraný cluster → záložka Metrics. Zobrazuje tři kategorie: hardware metrics (CPU, paměť, síťová propustnost), Spark metrics (aktivní/selhané/dokončené tasky, shuffle read a write) a GPU metrics u ML runtime. Data lze filtrovat až 30 dní zpětně a přepínat mezi agregovaným pohledem a jednotlivými uzly — to se hodí, když podezříváte jeden konkrétní worker.

SQL warehousy mají vlastní záložku Monitoring: živé statistiky (běžící a čekající dotazy, počet clusterů), graf peak query count a historii dotazů s filtrem na dlouho běžící dotazy. Pokud graf běžících clusterů dlouhodobě sedí na maximu autoscalingu, warehouse nestíhá.

Auto-termination a autoscaling

Monitoring odhaluje vzory, konfigurace na ně reaguje. Auto-termination vypne cluster po zadané době nečinnosti — pro vývojová prostředí je obvyklých 30–60 minut. Cluster je „nečinný", až když doběhly všechny příkazy včetně Spark jobů, Structured Streamingu a JDBC volání. Autoscaling dynamicky přidává a ubírá workery mezi nastaveným minimem a maximem; podle Learn modulu tím lze proti fixní velikosti ušetřit řádově 20–40 % nákladů (skutečná úspora závisí na profilu workloadu).

Budgets a system tables pro náklady

Reálnou útratu sledujte přes budgets v account console (finanční cíle + e-mailové notifikace při překročení, filtrovatelné per tým/projekt/workspace) a hlavně přes system table system.billing.usage, kterou lze dotazovat přímo SQL. Kdo čeká, že náklady „nějak dopočítá z faktury", bude překvapen — bez tagů a system tables se zpětná atribuce nákladů dělá velmi špatně.

-- denni trend spotreby DBU
SELECT usage_date, sum(usage_quantity) AS dbus_consumed
FROM system.billing.usage
WHERE sku_name = "STANDARD_ALL_PURPOSE_COMPUTE"
GROUP BY usage_date
ORDER BY usage_date ASC

-- ktere joby spotrebovaly nejvic DBU (kandidati na optimalizaci)
SELECT usage_metadata.job_id AS job_id,
       sum(usage_quantity) AS total_dbus
FROM system.billing.usage
WHERE usage_metadata.job_id IS NOT NULL
GROUP BY job_id
ORDER BY total_dbus DESC

Joinem na system.compute.clusters zjistíte, čí clustery pálí nejvíc DBU (owned_by), a přes custom_tags rozpočítáte náklady na projekty. Tagy se propagují z clusterů a workspace do billing záznamů — ale jen od okamžiku, kdy je nastavíte. Zpětně historii neotagujete.

Když selže orchestrovaný job, první otázka nezní „proč", ale „kde". Stav celého běhu přitom Azure Databricks odvozuje od leaf tasků — tasků bez navazujících závislostí. Z toho plyne i na první pohled zvláštní stav „Succeeded with failures": nějaký task uprostřed DAGu selhal, ale všechny leaf tasky doběhly.

Jednotlivé tasky mohou být navíc Disabled — buď je vypnete ručně, nebo je Lakeflow Jobs vypne automaticky, protože je vypnutý upstream task. V DAG view je poznáte podle ikony přeškrtnutého kolečka.

Kde to spadlo: matrix view

Diagnostika začíná v Jobs & Pipelines → detail jobu → záložka Runs. Matrix view zobrazuje historii běhů jako mřížku, kde každá buňka je stav jednoho tasku v jednom běhu:

1. Najeďte myší na červený (selhaný) task — uvidíte metadata včetně chybové zprávy.
2. Klikněte na task a otevřete Task run details s kompletním výstupem a logy.
3. Hledejte vzor: stejný task selhává opakovaně → problém v kódu či konfiguraci tasku. Selhání „skáčou" náhodně po různých tascích → spíš problém clusteru nebo zdrojů.

Repair run: oprava bez opakování celého jobu

Nejcennější nástroj této sekce: repair run znovu spustí jen selhané tasky a jejich potomky, ne celý job. U pipeline, kde tři hodiny běžící transformace uspěla a selhal až finální export, je to rozdíl mezi třemi hodinami a třemi minutami compute času.

1. Otevřete selhaný běh (sloupec Start time nebo matrix view).
2. Zvolte Repair run — dialog ukáže seznam tasků, které se znovu spustí.
3. Volitelně upravte parametry tasků — přepis platí jen pro tento repair běh.
4. Potvrďte; matrix view po dokončení přidá nový sloupec s výsledky opravy.

Zastavení, restart a proaktivní monitoring

Aktivní běh zastavíte tlačítkem stop v záložce Runs (hromadně přes Cancel runs / Cancel all queued runs). Kontinuální joby, které opakovaně selhávají, přecházejí do exponential backoff — Databricks čeká mezi pokusy stále déle. Po opravě příčiny použijte Restart run: zruší aktivní běh, vynuluje čekací interval a spustí nový běh hned.

Reaktivní hašení doplňte prevencí: notifikace (e-mail, Slack, webhook) na selhání jobu, pravidelná revize matrix view a dotazy nad schématem system.lakeflow, kde najdete historii jobů a běhů napříč účtem — trendy v době běhu odhalí degradaci dřív, než z ní bude incident.

Jobs UI vám řekne, který task selhal. Když ale potřebujete zjistit proč je pomalý, musíte o vrstvu níž — do Spark UI. K tomu je potřeba rozumět tomu, jak Spark práci strukturuje.

Tři kategorie selhání

Příčiny selhání Spark jobů spadají do tří rodin: chyby v kódu (syntaxe, špatné transformace, schema mismatch — chybová zpráva obvykle míří přímo na problém), nedostatek zdrojů (out-of-memory, pomalý shuffle, opakovaně selhávající tasky) a problémy prostředí (cluster nenastartoval kvůli limitům subscription, reclaim spot instancí, nedostupný externí zdroj). První kategorie se řeší v kódu, druhá kombinací konfigurace clusteru a optimalizace, třetí často mimo Databricks.

Postup ve Spark UI

Spark UI otevřete ze stránky clusteru (záložka Spark UI). Vyšetřování začněte na Jobs Timeline a hledejte tři vzory:

• Selhané joby (červený indikátor) — klik zobrazí selhanou stage a konkrétní důvod, včetně odkazů na chyby na úrovni tasků.
• Dlouho běžící joby — job výrazně delší než ostatní je první kandidát na drill-down do stages.
• Mezery v timeline — krátké pauzy jsou normální (driver koordinuje), ale mezera delší než minutu uprostřed pipeline naznačuje přetížený driver nebo poruchu clusteru.

V problematickém jobu otevřete nejdelší stage a čtěte metriky tasků: sloupce Input, Output, Shuffle Read a Shuffle Write ukazují, kolik dat se kde hýbe.

Metriky clusteru a driver vs. workery

Spark UI doplňte pohledem do záložky Metrics clusteru. Vizualizace Server load distribution barví uzly podle zátěže: červená = přetížený, modrá = nevytížený. Klasický vzor: červený driver, modří workeři — driver je přetížený (typicky sběr velkých výsledků do notebooku, tisíce malých tasků, nebo single-threaded Python kód) a potřebuje větší instanci, nebo úpravu kódu. Vysoké shuffle objemy s pomalým během zase značí síťové úzké hrdlo — řešením je dřívější filtrování, broadcast join nebo repartitioning.

Restart clusteru

Vyčerpané zdroje, zaseknuté executory nebo zastaralý image někdy vyřeší jen restart. Před ním zkontrolujte Event log clusteru (selhání akvizice instancí, reclaim spotů, terminace executorů) a restartujte přes UI, nebo CLI:

# restart clusteru pres Databricks CLI
databricks clusters restart CLUSTER_ID

# CLUSTER_ID zjistite napr. z
databricks clusters list

Dotaz, který včera běžel deset minut, dnes běží hodinu. Většina takových záhad se dá vystopovat ke čtyřem vzorům: caching problémy, data skew, memory spill a nadměrný shuffle. Nejsou nezávislé — skew typicky způsobuje spill a obojí zhoršuje shuffle. Proto se vyšetřují společně.

Caching: disk cache vs. Spark cache

Azure Databricks automaticky cachuje Parquet soubory na lokálních discích workerů — tzv. disk cache (dříve Delta cache). Funguje transparentně; jestli je zapnutá, ověříte konfigurací spark.databricks.io.cache.enabled. Vedle toho existuje klasická Spark cache (.cache() / .persist()), která vyžaduje ruční správu. Dva protipóly problémů: under-caching (opakované čtení stejných dat z remote storage — ve Spark UI vysoké Input u stále stejných stages) a over-caching (cache ukusuje paměť potřebnou pro zpracování a přispívá k OOM). Kdo čeká, že .cache() je vždy zrychlení, bude překvapen — necachovaná data, která se nikdy znovu nepřečtou, jsou jen zaplacená paměť; a nezapomínejte na .unpersist().

Data skew: pár tasků dře, zbytek čeká

Data skew = některé partitions jsou výrazně větší než ostatní. Pár tasků pak běží mnohonásobně déle a celý cluster čeká na opozdilce. Typické příčiny: nerovnoměrná distribuce klíčů v joinech a agregacích (jeden zákazník v 90 % záznamů), NULL hodnoty směřující do jedné partition, časové partitionování s „těžkými" posledními dny.

Diagnóza: ve Spark UI otevřete detail stage a sekci Summary Metrics. Dokumentace: „If the Max is more than 50% higher than the 75th percentile, you likely have skew." Řešení v pořadí, v jakém je zkoušet:

• Adaptive Query Execution (AQE) — za běhu rozbíjí skewed partitions při joinech. Na moderních Databricks Runtime je zapnutá; ověřte konfiguraci.
• Broadcast join — malou tabulku rozešlete na všechny executory a skew v shuffle joinu úplně obejdete.
• Salting — ruční přidání náhodné složky ke klíči, když automatika nestačí (viz odbočka níže).

# overeni klicovych konfiguraci
spark.conf.get("spark.databricks.io.cache.enabled")          # disk cache
spark.conf.get("spark.databricks.optimizer.adaptive.enabled") # AQE

# shuffle partitions nechat ridit dynamicky
spark.conf.set("spark.sql.shuffle.partitions", "auto")

Memory spill: paměť došla, jede se přes disk

Spill nastává, když se mezivýsledky nevejdou do paměti a Spark je odkládá na disk — každý bajt se zapíše a znovu přečte. V detailu stage hledejte metriky Shuffle Spill (Memory) a Shuffle Spill (Disk): jakákoli nenulová hodnota znamená tlak na paměť. Nápravy: zvýšit počet partitions (menší data na task — proto "auto" výše), workery s vyšším poměrem paměti na jádro, a hlavně zmenšit zpracovávaná data (výběr sloupců, časné filtrování).

Shuffle: nejdražší operace ve Sparku

Shuffle přesouvá data mezi uzly při joinech, agregacích a repartitioningu. Zahrnuje serializaci, zápis na disk, síťový přenos a deserializaci — proto je to typicky nejdražší část dotazu. Ve Spark UI ho čtete ze sloupců Shuffle Read / Shuffle Write; v DAGu a query profilu se zobrazuje jako Exchange uzly. Když shuffle read výrazně převyšuje velikost vstupních dat, hýbete daty zbytečně.

• Filtrujte co nejdřív — do shuffle pošlete jen data, která opravdu potřebujete.
• Broadcast join pro malé tabulky — Learn modul uvádí výchozí limit pro automatický broadcast cca 30 MB (AQE navíc umí sort-merge join překlopit na broadcast za běhu, když malou tabulku odhalí až runtime statistika); přesné prahy pro váš runtime ověřte v dokumentaci.
• Nerepartitionujte zbytečně — každé repartition() je plný shuffle.
• Kolokujte data — tabulky často joinované přes stejný klíč partitionujte/bucketujte stejně.

from pyspark.sql import functions as F

# explicitni broadcast male dimenzni tabulky
result = (fact_df
    .join(F.broadcast(dim_df), "customer_id")
    .groupBy("region")
    .agg(F.sum("amount").alias("total_amount")))

# faze 1: agregace pres klic + sul (rozlozi skewed klic na 8 tasku)
salted = (df
    .withColumn("salt", (F.rand() * 8).cast("int"))
    .groupBy("customer_id", "salt")
    .agg(F.sum("amount").alias("partial")))

# faze 2: finalni agregace uz nad malymi mezisoucty
final = salted.groupBy("customer_id").agg(F.sum("partial"))

Jakmile firma provozuje víc než jeden workspace, prohledávání logů „workspace po workspace" přestane škálovat. Log streaming do Azure Log Analytics centralizuje audit a diagnostické logy z celého prostředí do jednoho místa, kde je dotazujete přes KQL (Kusto Query Language), stavíte nad nimi alerty a dashboardy.

Tok dat: workspace generuje audit/diagnostické eventy (vytvoření clusteru, běh jobu, spuštění notebooku, změna oprávnění) → Azure diagnostic settings je zachytí a routují → Log Analytics je uloží do tabulek per služba → vy dotazujete KQL. Diagnostic settings typicky konfiguruje platformní administrátor v Azure portálu; datový inženýr logy hlavně konzumuje.

Každá tabulka sdílí standardní sloupce: TimeGenerated, OperationName, Identity, SourceIPAddress, RequestParams a Response. Vyšetřování selhání jobů tedy začíná v DatabricksJobs, bezpečnostní incident v DatabricksSecrets a DatabricksTables.

// ktere operace jobu selhaly za poslednich 7 dni a kdy se selhani kumuluji
DatabricksJobs
| where TimeGenerated > ago(7d)
| where Response contains "error" or Response contains "failed"
| summarize FailureCount = count() by OperationName, bin(TimeGenerated, 1h)
| order by FailureCount desc

Z dotazu je jeden krok k alertu: v Log Analytics zvolíte New alert rule, nastavíte podmínku a action group (e-mail, SMS, mobilní aplikace, ITSM integrace). Typické scénáře: víc než pět selhání jobů za hodinu, operace nad tabulkami mimo pracovní dobu, nezvyklá vlna vytváření clusterů (utržená automatizace).

// alert: vice nez 5 selhani jobu za poslednich 60 minut
DatabricksJobs
| where TimeGenerated > ago(1h)
| where Response contains "error" or Response contains "failed"
| summarize FailureCount = count()
| where FailureCount > 5

Scénář: reportovací dotaz, který dřív končil za pár minut, náhle běží násobně déle — cluster vypadá vytížený, ale většina tasků končí rychle a pár se vleče. V labu si syntetické skew a shuffle workloady nejdřív sami vyrobíte (skewed groupBy, sort-merge join), problémy diagnostikujete ve Spark UI (Summary Metrics, DAG, Exchange uzly) a pak je opravíte pomocí broadcast joinů, AQE a redukce shuffle.

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