Airflow vs Dagster: Který orchestrátor zvolit v roce 2026?

Co je Apache Airflow

Apache Airflow je open-source orchestrátor workflow, který v Airbnb vznikl už v roce 2014 a dnes je de facto standardem pro data orchestraci. Pipelinu popisujete v Pythonu jako DAG (directed acyclic graph) — uzly jsou tasky, hrany závislosti.

Airflow vyniká obrovským ekosystémem operátorů (Postgres, Snowflake, GCS, Slack, Kubernetes…), zralou plánovací logikou a propracovaným UI. Provoz ale není triviální — typicky potřebujete scheduler, webserver, workers a metadata DB v PostgreSQL nebo MySQL.

Pro produkční nasazení dnes většina firem volí managed verzi: Astronomer, AWS MWAA nebo Google Cloud Composer. Tím odpadá nutnost spravovat infrastrukturu, zůstává ale task-centric mentalita — Airflow stále neví, jaká data tasky produkují, závislosti řešíte přes XCom nebo externí metastore a kvalitu dat řeší typicky vedlejší nástroj. Pro CI/CD pipeline musíte navíc vyřešit packaging DAGů, izolaci pluginů a kompatibilitu providerů, což u větších týmů často znamená vlastní platform tým.

Co je Dagster

Dagster je novější orchestrátor (první stabilní verze 2019) postavený kolem konceptu software-defined assets. Místo „spusť task X před taskem Y" deklarujete „tabulka orders závisí na tabulce raw_orders" a Dagster zbytek odvodí.

Tento přístup přirozeně přináší vestavěný lineage, typový systém na vstupech a výstupech a první-class integraci s dbt. V UI vidíte asset graf, historii materializací a kvalitu dat, ne jen běh tasků. Senzory mohou pipeline spouštět reaktivně (nový soubor v S3, zpráva v Kafka, změna v upstream tabulce) bez nutnosti polling cronu, což u event-driven workflow šetří latenci i compute.

Lokální development je výrazně lehčí — stačí dagster dev a běží vám kompletní prostředí. Pro produkci nabízí firma Dagster Labs hostovanou platformu Dagster+ (dříve Dagster Cloud) s hybridním deploymentem, kde control plane běží u Dagster Labs a vaše pipeline data nikdy neopouští vaši síť. Branch deployments navíc umožňují každému pull requestu izolované prostředí pro review datových změn, podobně jako Vercel preview pro frontend.

Architektura a komponenty

Airflow je distribuovaný systém čtyř hlavních komponent: scheduler (rozhoduje, co a kdy spustit), executor (kde tasky běží — LocalExecutor, CeleryExecutor nebo KubernetesExecutor), webserver (UI a REST API) a metadata database (typicky PostgreSQL, drží stav DAGů, taskinstancí a XCom). V produkci přibývá ještě triggerer pro deferrable operátory a flower nebo Prometheus pro monitoring workerů.

Dagster má vědomě jednodušší topologii: dagster-webserver (UI + GraphQL API), daemon (scheduler, sensor a run queue), code locations (oddělené Python prostředí pro každý projekt) a run launcher (Kubernetes, Docker, ECS nebo lokální subprocess). Code locations jsou klíčová izolace — různé týmy mohou mít vlastní závislosti a deploy cyklus, aniž by se vzájemně blokovaly.

Praktický důsledek: Airflow cluster s 50+ DAGy a desítkami workerů typicky vyžaduje dedikovaného DevOps engineera. Dagster díky code locations umí stejnou zátěž obsloužit s lehčí infrastrukturou — týmy nasazují nezávisle a daemon zvládne stovky senzorů na jednom procesu. Pro DataOps zralé organizace je to nezanedbatelný rozdíl v provozních nákladech.

Srovnávací tabulka

Klíčové rozdíly v jednom přehledu — od abstrakce přes výkon až po typický fit.

Developer experience

Airflow má strmější on-ramping. Lokální vývoj typicky znamená spustit docker-compose s Postgres, scheduler a webserverem. Testování tasků vyžaduje vlastní harness — neexistuje first-class podpora unit testů.

Dagster jde opačnou cestou: pip install dagster && dagster dev rozjede UI i scheduler během vteřin. Ops (ekvivalent tasků) jsou čisté Python funkce s typovanými vstupy a výstupy — testujete je jako běžný kód. Pro týmy, které berou data engineering jako software engineering, je to dramatický rozdíl.

Observabilita a alerting

Airflow nabízí granulární logy na úrovni tasku, Gantt chart pro identifikaci úzkých míst a integraci s StatsD/Prometheus pro export metrik. Alerting řešíte přes on_failure_callback, SLA misses nebo email — pro Slack a PagerDuty existují operátory. Nevýhodou je task-level pohled: když selže pipeline, vidíte „task X failed", ale nikoli „tabulka orders se nematerializovala a downstream report je zastaralý".

Dagster posouvá observabilitu na úroveň datových assetů. V UI vidíte freshness policies (kdy byl asset naposled aktualizován oproti SLA), asset checks (data quality kontroly přímo v orchestrátoru), materialization history s metadaty (počet řádků, velikost, kontrolní součty) a auto-materialize policy pro reaktivní spouštění. Alerting umí cílit na konkrétní assety, ne jen tasky.

Pro data observabilitu napříč celým stackem oba nástroje doplňujeme o specializovaná řešení (Monte Carlo, Soda, Elementary pro dbt). Dagster však pokryje 70–80 % typických potřeb out-of-the-box, zatímco Airflow vyžaduje od začátku vlastní instrumentaci nebo bolt-on nástroje.

Náklady a TCO

Self-hosted Airflow má nulové licenční náklady, ale realistický TCO pro produkční cluster (3 workery, HA scheduler, PostgreSQL RDS, monitoring) startuje na 800–1 500 USD/měsíc v AWS plus 0,3–0,5 FTE platformního inženýra. Managed varianty: MWAA od 360 USD/měsíc (small), Cloud Composer od 380 USD/měsíc, Astronomer od 0,35 USD/task-minute s minimem ~500 USD/měsíc.

Dagster self-hosted vyjde levněji díky jednodušší topologii — typický setup (1 webserver, 1 daemon, Postgres, K8s run launcher) běží od 400–800 USD/měsíc s 0,1–0,2 FTE údržby. Dagster+ Pro stojí od cca 1 000 USD/měsíc (zahrnuje hosting, branch deployments, observabilitu) a Enterprise dle dohody s SAML, audit logy a privátním deploymentem.

Skrytý náklad obou nástrojů je výpočet v podkladovém warehouse — orchestrátor sám neúčtuje, ale špatně navržené DAGy mohou snadno spálit desítky tisíc Kč měsíčně v Snowflake nebo BigQuery. Dagster s asset-aware schedulingem (spustit jen to, co se opravdu změnilo) typicky šetří 20–40 % compute oproti time-based DAGům v Airflow.

Kdy zvolit Airflow

Airflow zůstává správnou volbou v těchto situacích:

• Máte heterogenní workflows (ML, ops jobs, ETL, alerty) — ne čistě datovou platformu.
• Potřebujete obscurní operátor, který v Dagsteru chybí (např. specifický SaaS).
• Tým má roky zkušeností s Airflow a migrace by nepřinesla úměrnou hodnotu.
• Chcete managed offering od velkého cloud providera (MWAA, Cloud Composer).

Kdy zvolit Dagster

Dagster je výhodnější, pokud:

• Stavíte moderní data platformu s dbt a lakehouse architekturou.
• Potřebujete vestavěný lineage a data quality bez bolt-on nástrojů.
• Týmu záleží na DX — typování, testování, rychlá lokální iterace.
• Začínáte zelený projekt a nemáte legacy Airflow investici.

Migrace z Airflow na Dagster

Dagster nabízí oficiální dagster-airflow knihovnu, která umí importovat existující Airflow DAGy a spouštět je jako Dagster joby. To znamená, že nemusíte přepsat vše naráz — můžete postupně přepisovat DAG po DAGu na asset-based přístup. Doporučený postup: nejdřív obalit stávající DAGy, paralelně rozjet asset graf nad novými pipeline a po validaci shadow runů přepnout produkci.

V praxi doporučujeme migrovat nejprve nové pipelines, pak nejdůležitější existující flows (typicky core data warehouse pipeline) a legacy jobs nechat běžet v Airflow do přirozeného konce života. Klíčové kontroly před přepnutím: shoda materializovaných dat (row counts, checksum), srovnatelná latence, fungující alerting v Slack/PagerDuty a runbook pro rollback. Plnou migraci typicky zvládneme za 6–12 týdnů podle počtu DAGů — napište nám pro nezávazný odhad.

Reálný příklad z našeho portfolia: středně velký e-commerce hráč s 80 Airflow DAGy (denně 2 500 task runů, 4 datoví inženýři) přešel na Dagster za 9 týdnů. Výsledek: −38 % compute v Snowflake díky asset-aware schedulingu, čas od commitu po produkční materializaci klesl z 25 na 6 minut a počet on-call incidentů spojených s neaktuálními daty se snížil o 60 % díky freshness policies a asset checkům přímo v orchestrátoru.

Časté dotazy