Databricks 2026: Znížte DBU o 40-60% (N…

Aktualizované: 10. septembra 2026

Náklady na Databricks sa v roku 2026 dajú znížiť o 40–60 % kombináciou piatich pák: prechod z all-purpose na jobs clustery, zapnutie Photon enginu tam, kde má zmysel, agresívne auto-termination, cluster policies vynucujúce spot inštancie a serverless SQL warehouses s auto-stop na 1 minútu. Faktúra za Databricks nie je fixná. Je to súčet DBU spotreby, cloudového compute a storage, a každú z týchto troch zložiek viete škrtiť samostatne. Nižšie ukazujem, ako som na jednom klientskom účte znížil mesačný Databricks bill zo 187 000 USD na 74 000 USD za osem týždňov.

Databricks účtuje DBU (Databricks Units) za sekundu. Jedna DBU stojí od 0,07 do 0,95 USD podľa SKU (all-purpose, jobs, serverless SQL, DLT). Photon engine zdvojnásobuje DBU sadzbu, ale často znižuje wall-clock čas o 3–5×.
Presunutie ETL úloh z all-purpose clustera (0,55 USD/DBU) na jobs cluster (0,15 USD/DBU) zníži DBU cenu o 73 % bez zmeny kódu.
Cluster policies s vynúteným spot_bid_price_percent = 100 a min_workers = 1 dokážu redukovať cloud compute časť účtu o 50–70 % (na AWS m6i.xlarge spot vs on-demand).
Serverless SQL Warehouses s auto-stop 1 minúta stoja o 25–40 % menej ako classic warehouses pre BI workloady s prerušovanou aktivitou.
OPTIMIZE, VACUUM a Z-ORDER v Delta Lake redukujú počet čítaných súborov o 60–90 %, čo priamo znižuje čas dopytu a tým DBU spotrebu.
System tables (system.billing.usage) sú v roku 2026 GA a poskytujú per-user, per-cluster attribúciu bez potreby CUR joinov.

Ako sa účtuje Databricks: DBU, compute a storage

Databricks bill má tri komponenty a každý z nich má vlastnú páku. Prvý je DBU spotreba. DBU (Databricks Unit) je normalizovaná jednotka výpočtového výkonu, ktorá sa počíta za sekundu behu clustera. Cena za DBU závisí od SKU: pre AWS na tier Premium je all-purpose compute 0,55 USD/DBU, jobs compute 0,15 USD/DBU, DLT Advanced 0,36 USD/DBU a serverless SQL Warehouses 0,70 USD/DBU. Druhý komponent je cloudový compute (EC2, Azure VMs alebo GCE inštancie), ktorý fakturuje priamo poskytovateľ mimo Databricks účtu. Tretí je storage a networking, teda S3/ADLS/GCS požiadavky, cross-region prenos a Unity Catalog metastore.

Honestly, v praxi vidím, že klienti vôbec nechápu, ako veľmi sa DBU sadzby líšia medzi SKU. Ten istý ETL job bežiaci na all-purpose clustri s Photonom (0,55 × 2 = 1,10 USD/DBU) vs. na jobs clustri bez Photonu (0,15 USD/DBU) je rozdiel 7,3× v cene DBU pri rovnakom výkone. Keď audit dostane firma s 200 000 USD/mesiac Databricks účtom, prvá otázka nie je "aké optimalizácie kódu?", ale "koľko z toho beží na správnom SKU?". Oficiálna pricing stránka Databricks zverejňuje DBU sadzby pre všetky SKU a cloudy. Používajte ju ako referenciu, nie čísla z blogov.

All-purpose vs jobs clustery: kedy použiť ktorý

Toto je najlacnejšia optimalizácia s najväčším dopadom a väčšina tímov ju nemá zavedenú. All-purpose cluster (interaktívny) je určený pre notebooky, ad-hoc analýzy a spoločné vývojárske sedenia. Jobs cluster je jednorazový cluster, ktorý sa vytvorí pre spustenie úlohy a po jej skončení sa okamžite ukončí. Rozdiel v cene je 3,6× (0,55 vs 0,15 USD/DBU na AWS Premium).

Pravidlo: ak niečo beží zo scheduleru, MUSÍ to byť jobs cluster, nie all-purpose. Vidím to opakovane. Data engineer si vytvorí notebook, otestuje ho na all-purpose clustri, potom vytvorí Job, ktorý ukazuje na ten istý all-purpose cluster ("aby sa nemusel čakať na štart"), a nechá to tak. O 6 mesiacov neskôr má firma 40 % Databricks účtu na all-purpose clustroch, ktoré bežia 24/7. Na klientovi, kde som robil audit v Q1 2026, sme len týmto jedným presunom (60 job definícií z all-purpose na jobs cluster) ušetrili 43 000 USD/mesiac. To nie je optimalizácia kódu. To je len re-tag toho, kam job ukazuje.

Kedy má all-purpose zmysel? Interaktívny vývoj v notebookoch, ad-hoc SQL queries, ktoré nechcete pushovať cez serverless SQL warehouse, spoločné exploration clustery pre data science tímy. Vždy s cluster policy, ktorá vynúti auto-termination na 10–20 minút idle. Pre všetko schedulované ide o jobs cluster alebo (novšia možnosť od 2025) serverless jobs compute, ktorý ešte znižuje overhead startupu a účtuje sa granulárnejšie.

Je Photon engine hodný dvojnásobnej DBU ceny?

Photon je natívny C++ vektorizovaný engine, ktorý Databricks vypustil v 2021 a v 2026 je štandardnou súčasťou Runtime 15+ pre SQL a DataFrame API. Zapnutie Photonu zdvojnásobí DBU sadzbu, takže väčšina finančne konzervatívnych tímov ho automaticky vypína. To je chyba pre určité workloady.

Kedy sa Photon oplatí zapnúť: ETL pipelines s veľkými scan/aggregate/join operáciami nad Delta tabuľkami, SQL analytics dotazy nad partícionovanými faktmi a machine-learning feature engineering. V mojej praxi vidím speedup 3–5× pre typické Spark SQL dotazy. To znamená, že zdvojnásobenie DBU sadzby stále znižuje absolútnu cenu za spustenie o 30–60 %. Oficiálna Photon dokumentácia obsahuje benchmarky a zoznam podporovaných operácií.

Kedy Photon nedáva zmysel: úlohy zdomínované Python UDF (Photon ich fallbackuje na klasický engine), MLlib training joby (Photon neakceleruje ML tréning), malé úlohy s runtime pod 30 sekúnd (startup overhead je väčší ako úspora) a všetko so streaming Spark API pod verziu Runtime 14. Vždy odmerajte pred a po. Nasadenie Photonu naslepo pre všetko je rovnaká chyba ako mať ho nikde.

Serverless SQL Warehouses a auto-stop stratégia

Serverless SQL Warehouses (rebrand pôvodných SQL endpoints) sú optimalizované pre BI workloady, teda Tableau, Power BI, Looker a ad-hoc SQL. V 2026 je serverless variant o 25–40 % lacnejší ako classic warehouses pre typický BI traffic pattern (prerušované dotazy s idle časom 60–90 % dňa), pretože sa aktivuje za 2–5 sekúnd a účtuje len počas skutočného behu dotazu.

Kritické nastavenie je auto-stop. Defaultná hodnota 10 minút je príliš liberálna pre väčšinu BI use casov. Znížte ju na 1 minútu pre serverless a 5 minút pre classic. Rozdiel v spotrebe: pri warehouse, ktorý vybaví 40 dotazov denne v pracovných hodinách, 10-minútový auto-stop znamená ~7 hodín skutočného behu, 1-minútový len ~1,5 hodiny. To je 4,7× menej.

Ďalšia optimalizácia je right-sizing warehouse t-shirt size. Small warehouse má 1 cluster, Medium 2, Large 4, a cena rastie exponenciálne. Väčšina BI dashboardov, ktoré vidím u klientov, beží na Large alebo X-Large, keď Medium alebo dokonca Small stačí. Overte to cez system.query.history. Ak je 95. percentil query duration pod 30 sekúnd, ste over-provisioned. Podobný princíp platí aj v optimalizácii Snowflake nákladov cez warehouse credits, kde t-shirt sizing je najväčšia jedna páka.

Spot inštancie a cluster policies pre governance

Cloud compute časť (EC2, Azure VMs, GCE) tvorí typicky 30–50 % Databricks účtu, a je to práve časť, kde môžete použiť spot inštancie s 60–80 % zľavou. Databricks podporuje mixed clusters, kde driver beží na on-demand inštancii a workers na spot inštanciách. Zlyhanie spot instance sa detekuje a Spark automaticky replayne stratené tasky na inom worker.

Nastavenie cez cluster policy:

{
  "spark_version": {
    "type": "regex",
    "pattern": "^(15\\.[0-9]+\\.x-scala2\\.12|15\\.[0-9]+\\.x-photon-scala2\\.12)$"
  },
  "aws_attributes.availability": {
    "type": "fixed",
    "value": "SPOT_WITH_FALLBACK"
  },
  "aws_attributes.spot_bid_price_percent": {
    "type": "fixed",
    "value": 100
  },
  "aws_attributes.first_on_demand": {
    "type": "fixed",
    "value": 1
  },
  "autotermination_minutes": {
    "type": "range",
    "minValue": 10,
    "maxValue": 30
  },
  "node_type_id": {
    "type": "allowlist",
    "values": ["m6i.xlarge", "m6i.2xlarge", "r6i.xlarge"]
  }
}

Táto policy vynúti spot workers s max bid 100 % on-demand ceny (žiadny cenový overshoot), 1 on-demand inštanciu ako driver, auto-termination v rozmedzí 10–30 minút a obmedzí instance types na Graviton-kompatibilné SKUs. Ak beží Databricks na AWS, kombinácia so Gravitonom prináša ďalších 15–25 % úspor na cloudovom compute; detaily nájdete v playbooku migrácie na AWS Graviton.

Delta Lake optimalizácia: OPTIMIZE, VACUUM, Z-ORDER

DBU spotreba priamo koreluje s množstvom prečítaných dát z Delta Lake. Ak pipeline číta 10 TB namiesto 2 TB kvôli fragmentácii súborov a chýbajúcemu partition pruningu, platíte 5× viac za DBU aj cloud compute. Tri kľúčové nástroje na zmenu:

OPTIMIZE a small file problem

Delta Lake zapisuje nové súbory pri každom write. Streaming pipelines alebo časté batch appendy vytvárajú tisíce malých súborov (10–50 MB), ktoré Spark neefektívne číta. Príkaz OPTIMIZE table_name ich zlúči do väčších súborov (~256 MB), čo znižuje počet task-ov a I/O overhead. V roku 2026 je auto-compaction default v Runtime 15+, ale stojí za to overiť si cez DESCRIBE DETAIL, či je naozaj zapnuté.

Z-ORDER pre dopyty s vysoko selektívnym filtrom

OPTIMIZE table_name ZORDER BY (user_id, event_date) preorganizuje dáta tak, aby dopyty filtrujúce na tieto stĺpce čítali len relevantné súbory. Pre analytické dopyty typu "nájdi eventy pre user_id X za posledných 7 dní" to redukuje I/O o 80–95 %. Nekombinujte s viac ako 3–4 stĺpcami, inak Z-order stráca účinnosť.

VACUUM a storage retention

Delta Lake si udržiava time-travel history po default 7 dní. Pre veľké tabuľky (10 TB+) to znamená, že fyzicky ukladáte 2–3× viac dát ako aktuálny stav. VACUUM table_name RETAIN 168 HOURS vymaže staré verzie a znižuje storage bill. Nechajte 168 hodín (7 dní) len ak reálne používate time travel; inak znížte na 24 hodín. Na jednom projekte som takto ušetril klientovi 12 000 USD/mesiac len na S3, pretože nikto z tímu si o time travel v produkcii ani nespomenul.

Monitorovanie nákladov cez system tables

V roku 2026 sú Databricks system tables (system.billing.usage, system.query.history, system.access.audit) GA a poskytujú granulárnu attribúciu bez toho, aby ste museli joinovať CUR/billing exporty. Toto je základ FinOps observability pre Databricks. Bez toho iba hádate, kto míňa. Podobne ako pri rightsizingu EC2 cez AWS Compute Optimizer, kľúč je dostať sa k per-workload attribution dátam skôr, ako začnete čokoľvek optimalizovať.

Základný dotaz pre attribúciu DBU spotreby po užívateľoch a job type:

SELECT
  usage_metadata.job_id,
  usage_metadata.cluster_id,
  identity_metadata.run_as,
  sku_name,
  SUM(usage_quantity) AS total_dbus,
  SUM(usage_quantity * list_prices.pricing.default) AS estimated_cost_usd
FROM system.billing.usage
LEFT JOIN system.billing.list_prices list_prices
  ON usage.sku_name = list_prices.sku_name
  AND usage.usage_start_time BETWEEN list_prices.price_start_time AND COALESCE(list_prices.price_end_time, CURRENT_TIMESTAMP())
WHERE usage_date >= CURRENT_DATE - INTERVAL 30 DAYS
GROUP BY 1, 2, 3, 4
ORDER BY estimated_cost_usd DESC
LIMIT 100;

Tento dotaz vám dá top 100 najdrahších job/cluster/user kombinácií za posledných 30 dní s odhadovanou USD cenou. Nasaďte ho ako Databricks alert s prahom (napríklad denný náklad > 500 USD za jedného usera) a máte zabudované cost anomaly detection. Oficiálna dokumentácia system tables obsahuje kompletný dátový model a príklady.

30/60/90-dňový FinOps roadmap pre Databricks

Ak máte Databricks účet nad 50 000 USD/mesiac a chcete začať, toto je fázovaný plán, ktorý som overil na piatich klientoch v 2025–2026 s priemernou úsporou 48 % za 90 dní. Nie je nutné robiť to v tomto poradí, ale odporúčam nezačínať štrukturálnymi zmenami skôr, ako máte v ruke observability dáta.

Prvých 30 dní: audit a quick wins

Zapnite system tables, ak ešte nie sú (vyžaduje account admin).
Identifikujte všetky joby bežiace na all-purpose clustri a presuňte ich na jobs cluster. Priemerná úspora 20–35 % okamžite.
Nastavte auto-termination na 10 minút pre všetky all-purpose clustery cez cluster policies.
Znížte auto-stop pre SQL warehouses z 10 min na 1 min (serverless) alebo 5 min (classic).
Vytvorte cost dashboard s dennými výdavkami rozdelenými po workspace / SKU / user.

Dni 30–60: kapitalizácia úspor

Zapnite spot inštancie pre všetky non-critical joby cez cluster policy (SPOT_WITH_FALLBACK).
Zvážte AWS Graviton alebo Azure Ampere Altra inštancie tam, kde Runtime podporuje.
A/B testujte Photon na top 20 najdrahších úloh.
Rightsize SQL warehouses podľa p95 query duration z system.query.history.
Vypnite streaming úlohy, ktoré zapisujú do prázdnej alebo len jednou konzumovanej tabuľky (zombie streams sú prekvapivo časté).

Dni 60–90: štrukturálne zmeny

Zaveďte OPTIMIZE + Z-ORDER na top 10 najčastejšie dopytovaných Delta tabuliek.
Nastavte VACUUM policy s retenciou 24–72 hodín pre tabuľky bez time-travel use case.
Kúpte Databricks Committed Use Discount (DBU commitment) na základe stabilizovanej spotreby, čo prinesie zľavu 10–30 % za 1–3 ročný záväzok.
Zaveďte FinOps chargeback cez tagovanie clustrov (business_unit, project, cost_center) a týždenný report do každého tímu.

Často kladené otázky

Čo je DBU a ako sa účtuje?

DBU (Databricks Unit) je normalizovaná jednotka výpočtového výkonu, ktorá sa počíta za sekundu behu clustera. Cena za DBU sa líši podľa SKU: all-purpose 0,55 USD, jobs 0,15 USD, serverless SQL 0,70 USD, DLT Advanced 0,36 USD (AWS Premium tier, 2026 sadzby). K DBU cene sa pripočítava cena cloudového compute (EC2/Azure VMs/GCE), ktorú fakturuje priamo cloud provider.

Ako môžem znížiť náklady na Databricks?

Päť najúčinnejších pák: (1) presunúť schedulované joby z all-purpose na jobs clustery (úspora ~73 % DBU ceny), (2) zapnúť spot inštancie cez cluster policy (~60 % úspora cloud compute), (3) nastaviť auto-stop SQL warehouses na 1 minútu, (4) rightsize warehouse t-shirt size podľa p95 query duration, (5) zaviesť OPTIMIZE a Z-ORDER na horúce Delta tabuľky.

Oplatí sa zapnúť Photon engine?

Áno pre ETL pipelines s veľkými scan/aggregate/join operáciami nad Delta tabuľkami a pre SQL analytics. Photon zdvojnásobuje DBU sadzbu, ale znižuje wall-clock čas o 3–5×, čo v čistom výsledku šetrí 30–60 %. Neoplatí sa pre Python UDF-dominované úlohy, MLlib tréning a krátke joby pod 30 sekúnd.

Aký je rozdiel medzi serverless a classic SQL warehouse?

Serverless SQL Warehouse spúšťa infraštruktúru priamo v Databricks účte, aktivuje sa za 2–5 sekúnd a účtuje sa len počas behu dotazu. Classic warehouse beží vo vašom cloud účte, štart trvá 3–5 minút a účtuje sa aj počas idle. Pre BI workloady s prerušovanou aktivitou je serverless typicky 25–40 % lacnejší; pre 24/7 dashboardy s konštantnou záťažou môže byť classic výhodnejší.

Ako monitorovať Databricks náklady per team alebo project?

Použite Databricks system tables (system.billing.usage) v kombinácii s custom tagmi na clustroch a jobs (business_unit, project, cost_center). Vytvorte cost dashboard v Databricks SQL, ktorý joinuje usage data s list_prices tabuľkou pre USD attribúciu. Pre multi-cloud FinOps zvážte export do FOCUS-kompatibilného datasetu, ktorý zjednotí Databricks fakturáciu s AWS/Azure/GCP nákladmi.