dbt Fusion přepisuje dbt engine z Pythonu do Rustu a v červnu 2026 se stal základem dbt Core v2.0. Průvodce migrací, unit testy, srovnávací tabulka Core vs Fusion a jak Fusion zapadá do Python-first data stacku v roce 2026.
Aktualizováno: 6. září 2026
dbt Fusion je nový engine pro dbt, přepsaný od nuly v Rustu. Parsuje projekt s deseti tisíci modely až 30× rychleji než klasický dbt Core v Pythonu a od června 2026 se stal základem pro dbt Core v2.0. Pokud stavíte datové pipeline v Pythonu, tenhle rok je zlomový: dvouenginová éra končí, unit testy jsou konečně použitelné v CI, a real-time zpětná vazba v editoru mění způsob, jakým píšete SQL modely. Tenhle článek shrnuje všechno, co v roce 2026 potřebujete vědět.
--sample flag (1.10) dělají z dbt konečně nástroj, který umí opravdové testování před buildem.dbt Fusion je engine přepsaný v Rustu, který nahrazuje původní Python runtime dbt Core. Nejde jenom o výkon. Fusion je opravdový SQL kompilátor: chápe syntaxi i sémantiku SQL napříč datovými platformami (Snowflake, BigQuery, Databricks, Redshift, Postgres, Salesforce Data 360), takže dokáže dělat věci, na které jsem v Pythonovém dbt roky čekala. Statická analýza modelů, real-time podtržení chybného sloupce v editoru ještě než pipeline spustíte, náhled expanze CTE bez query do warehousu.
V mých pipeline byla hlavním úzkým hrdlem parse fáze na monorepo projektu se stovkami modelů. CI job se rozjížděl minutami manifestu, i když jsme měnili jeden model. Honestly, tenhle jediný fakt byl důvod, proč tým začal Fusion vůbec testovat. Fusion tenhle problém řeší architekturou: parser běží paralelně, kompilovaný binárník má nulové Python závislosti a projekt se deploynuje jako jeden soubor. Podle oznámení dbt Labs zvládá Fusion projekt s deseti tisíci modely parsovat až 30× rychleji než Core a plná kompilace je zhruba dvojnásobná. Pro velké data-mesh projekty je to rozdíl mezi „build za osm minut“ a „build za dvacet vteřin“.
Důležitý kontext: Fusion je proprietární distribuce postavená nad open-source jádrem. Precompilovanou binárku si stáhne kdokoliv zdarma, včetně integrovaného SQL linteru, ale některé pokročilé funkce (dbt State pro incremental reuse) běží pod ELv2 licencí a stojí $0,094 za unikátní denní reuse. Jádro samotné je stále Apache 2.0 v repozitáři dbt-core.
Rok 2026 přinesl důležitý zlom: 1. června vyšel dbt Core v2.0 alpha a s ním se otevřel Rust kód, který dřív byl uzavřený ve Fusion repozitáři. Otevřený i placený svět teď stojí na stejném základu, ale liší se distribucí a placenými funkcemi. Než začnete v Q3 2026 řešit migrační strategii, srovnejte oba světy ve stejné rovině:
| Vlastnost | dbt Core v1.x (Python) | dbt Fusion / Core v2.0 (Rust) |
|---|---|---|
| Runtime jazyk | Python 3.9+ | Rust (Fusion), Rust jádro s Python wrapperem (Core v2) |
| Rychlost parsování 10k modelů | Referenční základ | Až 30× rychlejší |
| Verze manifestu | v12 | v20 (Fusion i Core v2) |
| Licence | Apache 2.0 | Apache 2.0 (Core v2), ELv2 (Fusion binárka) |
| Real-time IDE feedback (LSP) | Ne | Ano (VS Code, Cursor) |
| RBAC / governance | Ne | Ano (Fusion v dbt platformě) |
| Instalace | pip install dbt-core dbt-snowflake | Single binary (dbtf) nebo pip install dbt-core pro v2 |
| Cena | Zdarma | Zdarma plus volitelné placené featury (State reuse $0,094/den) |
Pro čistě open-source projekty je od podzimu 2026 přirozená cesta dbt Core v2.0. Pro týmy, které chtějí LSP integraci, dbt Wizard nebo dbt Mesh, dává smysl přejít na Fusion. Mým doporučením: nejdřív si projekt nechte proběhnout přes --use-v2-parser flag v Core 1.12, ať zjistíte kompatibilitu, a teprve pak řešte licenční model. Oficiální upgrade průvodce k dbt Core v2 obsahuje kompletní checklist.
Fusion se instaluje jako single binary, nezávislý na Pythonu, což se hodí pro Docker image a CI, kde jsem dřív musela řešit konfliktní verze dbt-core a dbt-snowflake pluginů. Instalační skript stáhne binárku pro váš OS a přidá ji do PATH:
# macOS / Linux, oficiální instalátor
curl -fsSL https://public.cdn.getdbt.com/fusion/install/fusion-installer.sh | sh
# Ověření instalace
dbtf --version
# dbt Fusion Engine 2.10.3 (rev abc123f, 2026-08-15)
# Alternativa: Homebrew
brew install dbt-labs/dbt/dbtf
# Alternativa: Docker image (pro CI)
docker pull ghcr.io/dbt-labs/dbt-fusion:2.10
Pokud máte existující Python virtualenv s dbt-core, můžete Fusion provozovat paralelně. Binárka se jmenuje dbtf, takže se nesrazí s klasickým dbt příkazem. To je zásadní pro postupnou migraci: v CI necháte oba běžet vedle sebe, porovnáte manifest a teprve pak přepnete produkci. V mém týmu jsme tři týdny točili oba enginy proti stejnému branchi, než jsme si byli jistí, že se manifest v20 chová konzistentně s naším downstream monitoringem.
Konfigurace profiles.yml zůstává stejná (Fusion používá stejný formát profilů, jaký znáte z dbt Core). Nový je ADBC driver stack místo starých Python konektorů, který snižuje čas připojení k Snowflake o desítky milisekund na model. Pro produkci tohle není magie, ale pro dev loop, kde spouštíte dbt run --select my_model stovkykrát denně, se to sčítá.
Než Fusion nahradil vývoj v Pythonovém dbt-core, stihly ještě verze 1.9 a 1.10 přidat několik věcí, které jsou teď v Rust enginu dostupné rovnou. Krátký přehled toho, co v roce 2026 opravdu používám:
Microbatch rozděluje incremental model do dávek po dnech (nebo jiné časové jednotce) a zpracovává je jako samostatné SQL příkazy. Konec bolesti s backfilly. Když se rozbije zdroj z března a potřebuji přeprocesovat tři týdny, nemusím řešit ruční partition management. Stačí dbt run --event-time-start 2026-03-01 --event-time-end 2026-03-21 --select orders a dbt vygeneruje jednu dávku na den.
Do 1.9 se unit testy spouštěly pouze v rámci celého dbt build. Od 1.9 můžu izolovat dbt test --select "test_type:unit,tag:orders" a ověřit jenom logiku, kterou aktuálně měním. V CI to zkrátilo naši pre-merge kontrolu z 12 na 90 vteřin. Solidní ROI za pětiminutovou úpravu workflow.
dbt build --sample=1d spouští celou pipeline nad časově omezeným výřezem dat, což je perfektní pro validaci PR bez toho, aby vývojářský branch žral kredit ve warehouse. Doporučuji párovat s CI environmentem, který má oddělený schéma prefix.
Verze 1.10 zavedla top-level anchors: klíč pro sdílené YAML fragmenty a zároveň začala varovat před neočekávanými top-level klíči. Ve Fusion jsou tato varování už tvrdé chyby, o tom podrobněji v sekci o migraci. Kompletní seznam změn najdete v oficiálním upgrade průvodci na v1.10.
Do dbt 1.8 byly „testy“ v dbt jenom data testy: SQL query nad hotovým modelem, které padlo, když vrátilo víc než 0 řádků. Bylo to lepší než nic, ale nedokázalo to najít regresi v SQL logice před buildem. Unit testy tenhle rozdíl konečně smazaly: dostanou statické vstupy a porovnají výstup vaší SELECT transformace s očekávanými řádky.
V mých pipeline jsou unit testy povinné pro každý model, který dělá netriviální transformaci: join s podmínkou, window funkce, případová konstrukce. Backfill, který spadne ve tři ráno, protože někdo přeformuloval CASE WHEN, je noční můra, které se dá s unit testy vyhnout. Následující YAML testuje model orders_enriched, který spočítá lifetime value ze dvou vstupů:
# models/marts/_unit_tests.yml
unit_tests:
- name: test_orders_enriched_ltv_calculation
model: orders_enriched
given:
- input: ref('stg_orders')
rows:
- {order_id: 1, customer_id: 42, amount: 100.00, status: 'completed'}
- {order_id: 2, customer_id: 42, amount: 50.00, status: 'completed'}
- {order_id: 3, customer_id: 42, amount: 30.00, status: 'refunded'}
- input: ref('stg_customers')
rows:
- {customer_id: 42, country: 'CZ', signup_date: '2026-01-15'}
expect:
rows:
- {customer_id: 42, ltv: 150.00, orders_count: 2, country: 'CZ'}
- name: test_orders_enriched_handles_empty_input
model: orders_enriched
given:
- input: ref('stg_orders')
rows: []
- input: ref('stg_customers')
rows: []
expect:
rows: []
Klíčové je tohle: refundované objednávky se do LTV nezapočítávají a prázdný vstup nesmí spadnout dělením nulou. Když se tyhle dva testy dostanou do CI, nikdo v týmu nemůže bezpečně zkazit produkci nechtěnou úpravou WHERE status = 'completed'. Spuštění: dbt build --select orders_enriched zvalidují unit testy dřív, než se model materializuje, což šetří peníze ve warehousu.
V praxi kombinujeme unit testy s pytestem a Great Expectations pro širší validaci datových kontraktů. dbt unit testy pokrývají logiku transformace, pytest pokrývá Python glue kód (custom macros, hooks, orchestrátor). Detaily YAML syntaxe a podporu různých formátů vstupů (dict, CSV, SQL) jsou v oficiální dokumentaci unit testů.
Migrace na Fusion je bezpečnější, než se z release notes zdá. Projektová struktura zůstává stejná, modely nemusíte přepisovat, DAG se sám nerozbije. Co se ale mění: validace YAML je striktnější, deprecation warnings z Core se ve Fusion mění na chyby, a projekt nesmí míchat manifesty v12 (Core) a v20 (Fusion) napříč prostředími. Doporučená sekvence:
--use-v2-parser flag, který dovolí zkusit Fusion parser bez plné migrace.dbt-autofix. Balíček, který dbt Labs uvolnili speciálně pro tento přechod, opraví většinu deprecation warnings automaticky. Doporučuji zapnout v samostatném PR.dbt parse --use-v2-parser proti hlavní větvi. Chyby, které vypadne, jsou zpravidla YAML se skrytými top-level klíči nebo modely s nejednoznačným ref().dbtf compile a dbt compile. Očekávejte, že kompilovaný SQL je identický, ale manifest se liší (v20 vs v12).Fusion umí přečíst Core manifest, ale Core neumí přečíst Fusion. To znamená: jakmile jedno prostředí přejde na Fusion, ostatní musí následovat, jinak přestanou fungovat state:modified, --defer a cross-environment dbt docs generate. Plánujte migraci jako všechno-nebo-nic pro každou logickou skupinu prostředí.
dbt Fusion sám v Pythonu neběží, ale pořád zapadá do Python-first data platformy. V našem stacku vypadá typický data flow takhle: dlt nebo Airbyte natáhne raw data do Snowflake nebo BigQuery, dbt Fusion transformuje raw do marts, Airflow orchestruje spuštění dbt jobů a downstream Python konzumuje výsledky přes ADBC nebo Polars pro rychlou analýzu tabulek.
Pro orchestraci Fusion i Core doporučuji Astronomer Cosmos, který dbt DAG přeloží 1:1 na Airflow tasks. Každý model je vlastní task, což umožňuje re-run jednoho selhaného modelu bez re-runu celé pipeline. To je klíčové pro backfilly nad velkými fact tabulkami. Jak zorganizovat Airflow DAG do logických skupin popisuje článek o Airflow Task Groups pro produkční pipeline.
Datové kontrakty mezi vrstvami sesynchronizuji přes Pydantic v2 pro validaci dat na hranici Python aplikací. Fusion produkuje strukturovaný manifest v20, ze kterého generuji Pydantic modely. Pak validace v FastAPI endpoints padne dřív, než se špatná data dostanou k modelu. Kombinace „dbt kontrakty ve warehouse plus Pydantic na hranici API“ je pro mě zlatý standard roku 2026.
Pár věcí, o které jsem se v produkci spálila a které dbt Labs v prvních migračních guidech nezdůrazňují dost:
Poslední věc, kterou opakuju juniorům: Fusion vám neušetří práci s testováním. Rychlejší parsování znamená, že chyby se v CI objeví dřív, ale unit testy si musíte pořád psát ručně. dbt neuhodne, které řádky mají projít refundovaným filtrem, to je pořád na vás.
Precompilovaný Fusion binárek je zdarma ke stažení a instalaci, včetně integrovaného SQL linteru a LSP pro VS Code. Placené jsou pokročilé funkce dbt platformy (dbt Wizard, dbt Mesh, RBAC) a State reuse, které stojí $0,094 za unikátní denní reuse. Zdrojový kód runtime je otevřený pod Apache 2.0 v repozitáři dbt-core v2.0, samotná Fusion distribuce běží pod ELv2.
Ano, dbt Fusion podporuje Python modely stejně jako dbt Core, ale native unit testy jsou stále dostupné jen pro SQL modely. Pro Python modely se doporučuje testovat kód přes pytest s vlastními fixtures. dbt Labs to explicitně uvádí jako komunitní workaround, nikoliv oficiální feature.
Sdílejí stejný Rust runtime, ale dbt Core v2.0 je čistě open-source Apache 2.0 distribuce zaměřená na CLI vývojáře, kdežto dbt Fusion je proprietární produkt dbt Labs s doplňkovými funkcemi (LSP, dbt Wizard, RBAC, State reuse) a licencí ELv2. Pro většinu jednoduchých projektů stačí Core v2, pro enterprise týmy dává smysl Fusion.
Podle mé zkušenosti s projektem 400+ modelů a integracemi na Snowflake, Airflow a Cosmos jde o zhruba dva sprinty: první týden běží dbt-autofix a testy parseru, druhý týden ladíte striktnější YAML validaci, třetí až čtvrtý týden běží Fusion vedle Core ve stagingu a teprve pak přepnete produkci. Malé projekty (do 50 modelů) zvládnete za den.
Pokud máte projekt do 30 modelů, nekritické backfilly a jste zvyklí na Python plugin ekosystém, Core v1.x nebo v2.0 vám bude sloužit dobře. Fusion se vyplatí, jakmile parse time začne blokovat CI (typicky nad 200 modelů) nebo když potřebujete real-time IDE feedback pro velký tým analytiků.
Praktický průvodce XGBoost 3.2 v Pythonu s CUDA 13, produkčně stabilními kategoriálními features, laděním hyperparametrů přes Optuna a SHAP interpretací. Sedm let zkušeností s gradient boostingem v produkci.
Praktický průvodce MLflow 3.0 v Pythonu: instalace, sledování experimentů, Model Registry s aliasy, mlflow.genai pro LLM tracing a nasazení do produkce s FastAPI.
Optuna 4.9 automatizuje ladění hyperparametrů v Pythonu. Naučte se Bayesovskou optimalizaci s TPE a GP samplery, prunery, paralelní běh a integrace s XGBoost, LightGBM i MLflow 3.0 na hotových příkladech pro rok 2026.