Výběr a konfigurace compute

Volba typu compute přímo určuje náklady, výkon i provozní složitost. Základní dělení je dvojí: serverless compute spravuje kompletně Databricks (běží v jejich předplatném, startuje řádově v jednotkách sekund, škáluje automaticky), zatímco classic compute si konfigurujete sami a běží ve vašem Azure předplatném (start typicky v jednotkách minut, plná kontrola nad VM, sítí i runtime verzí).

Druhá osa je účel: all-purpose compute slouží interaktivnímu vývoji v notebooích a sdílí ho tým; job compute se vytváří pro automatizovaný běh jobu a po dokončení se sám ukončí — žádné idle náklady; SQL warehouse je compute optimalizovaný čistě pro SQL dotazy a BI.

Srovnání hlavních variant v kostce:

Výkon classic clusteru určují tři složky: celkový počet jader (maximální paralelismus — 8 workerů × 4 jádra = 32 souběžných tasků), celková paměť (kolik dat zvládnou joins a agregace v RAM, než začne spilling na disk) a lokální storage (mezisklad pro shuffle operace a cache).

Podle charakteru workloadu volíte rodinu VM:

Při stejném celkovém výkonu lze volit méně větších workerů (méně síťového provozu při shuffle — lepší pro analytické workloady s joins), nebo více menších (vyšší paralelismus — levnější pro jednoduché dávkové zpracování). Autoscaling zapnete zadáním min/max počtu workerů; Databricks používá optimized autoscaling, který škáluje nahoru ve dvou krocích a dolů umí jít i na ne-idle clusteru podle stavu shuffle souborů.

Photon je nativní vykonávací engine, který nahrazuje části Sparku optimalizovaným C++ kódem. Nejvíc zrychluje joins, agregace a scany širokých tabulek; na Runtime 9.1 LTS+ je zapnutý ve výchozím stavu. U malých jobů dokončených pod dvě sekundy se ale nemusí vyplatit (Photon má vyšší DBU sazbu) a na GPU clusterech není podporovaný vůbec — pro ML na GPU ho vypněte.

Výběr Databricks Runtime řiďte účelem: pro interaktivní vývoj klidně nejnovější verzi, pro produkční joby LTS verze (delší podpora, otestovaná stabilita). Verze Sparku je s runtime svázaná — upgrade runtime = upgrade Sparku, proto ho v produkci testujte nejdřív v dev prostředí. Pro ML volte Databricks Runtime ML s předinstalovanými knihovnami a GPU ovladači (CUDA).

Auto-termination ukončí cluster po zadané době nečinnosti — konfigurace zůstává a cluster lze kdykoli nastartovat znovu. Pro interaktivní práci je rozumný timeout kolem 15–45 minut podle pracovních návyků týmu; job clustery se terminují automaticky po doběhnutí jobu.

Instance pools drží sadu předalokovaných idle VM: cluster z poolu startuje pod minutu, protože VM už běží. Konfigurujete minimum idle instancí (kolik clusterů typicky běží souběžně), maximální kapacitu (férové dělení kvóty mezi týmy) a idle auto-termination poolu; předehřátí konkrétní runtime verze na instancích start ještě zrychlí. Platíte VM v idle stavu (ne DBU), takže pool se vyplatí jen při častých startech — v éře serverless je to spíš nástroj pro classic-only scénáře.

Compute policies omezují, co si uživatelé smí naklikat: admin jimi vynutí povolené typy VM, maximální velikost clusteru, LTS runtime či povinný auto-termination. Databricks dodává předdefinované policies (např. Personal Compute, Shared Compute, Job Compute — ta vynucuje LTS runtime a produkční defaults); vlastní policy je JSON s pravidly:

{
  "spark_version": { "type": "regex", "pattern": ".*-lts.*" },
  "node_type_id": { "type": "allowlist",
                     "values": ["Standard_E4ds_v5", "Standard_E8ds_v5"] },
  "autotermination_minutes": { "type": "range",
                                "maxValue": 60, "defaultValue": 30 },
  "autoscale.max_workers": { "type": "range", "maxValue": 8 }
}

Runtime obsahuje stovky předinstalovaných balíčků, ale dřív či později potřebujete něco navíc. Zásadní je rozdíl mezi dvěma rozsahy instalace:

Compute-scoped (cluster-scoped) knihovny instalujete na záložce Libraries daného clusteru (vyžaduje oprávnění CAN MANAGE). Podporují Python wheels, Java JAR a R balíčky a přeinstalují se automaticky při každém startu clusteru — konzistentní prostředí pro celý tým. Nevýhoda: kolize verzí řešíte za všechny; když dva týmy potřebují různé verze téže knihovny, musí na oddělené clustery nebo k notebook-scoped instalaci.

Notebook-scoped knihovny instalujete přímo v notebooku a platí jen pro aktuální session:

# notebook-scoped instalace — plati jen pro tuto session
%pip install faker==40.8.0

# po instalaci se restartuje Python interpret
dbutils.library.restartPython()

Zdroje balíčků: veřejné repozitáře (PyPI pro Python, Maven pro Javu/Scalu se souřadnicemi groupId:artifactId:version, CRAN pro R), nebo soubory — workspace files (limit 500 MB) a Unity Catalog volumes (plná governance: přístup přes UC oprávnění, audit log). Od Runtime 15.0 lze instalovat i requirements.txt. Cesta pak vypadá např. /Volumes/main/engineering/libraries/mypackage-1.0.0-py3-none-any.whl — instalující identita potřebuje READ VOLUME.

Přístup ke compute se řídí ve workspace UI (ne v Azure portálu) a má dvě roviny: access mode clusteru (kdo a jak izolovaně na něm smí pracovat) a permission levels (co smí konkrétní uživatel s daným clusterem dělat).

Access mode se v UI defaultně nastavuje jako Auto: zvolí Standard, pokud nevyberete ML runtime nebo runtime pod 14.3 — pak automaticky padne volba na Dedicated. Standard access mode (dříve shared) umožňuje bezpečné sdílení clusteru více uživateli — izolaci kódu mezi uživateli zajišťuje Lakeguard. Dedicated access mode (dříve single-user) přiřazuje cluster jedinému uživateli nebo skupině a dává plná strojová oprávnění — nutné pro RDD API, R, GPU workloady a custom containers.

Oprávnění nastavíte přes Compute → menu clusteru → Permissions; změny platí okamžitě bez restartu. Tvůrce clusteru je jeho vlastníkem s CAN MANAGE, workspace admini mají CAN MANAGE všude automaticky. Vedle toho existují workspace-level entitlements — např. unrestricted cluster creation dovolí ne-adminovi zakládat clustery bez omezení velikosti (bez povyšování na admina); běžným uživatelům místo toho přidělte compute policy.

Dedicated group access (Unity Catalog + Runtime 15.4+) umožňuje přiřadit cluster celé skupině: oprávnění každého člena se při připojení automaticky zúží na oprávnění skupiny (žádná eskalace privilegií) a objekty vytvořené na clusteru vlastní skupina, ne jednotlivec. Skupině vytvořte workspace složku (např. /Workspace/Groups/<groupName>) s CAN MANAGE pro notebooky a experimenty.

Pro zdravotnickou organizaci HealthBridge Analytics vytvoříte all-purpose cluster healthbridge-dev (LTS runtime, memory-optimized workery, autoscaling 1–3, auto-termination 15 minut, Photon), nainstalujete cluster-scoped knihovnu faker==40.8.0, srovnáte ji s notebook-scoped instalací přes %pip a vygenerujete syntetická pacientská data kombinací faker + PySpark.

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

Ochutnávka z notebooku — syntetičtí pacienti bez rizika úniku skutečných dat:

from faker import Faker

fake = Faker()
# generovani syntetickych pacientu
pacienti = [(fake.name(), fake.date_of_birth(minimum_age=18, maximum_age=90),
             fake.city()) for _ in range(1000)]

df = spark.createDataFrame(pacienti, ["jmeno", "datum_narozeni", "mesto"])
display(df)