Microsoft Fabric vs. dbt | Mňamka #556
Když firmy modernizují svou datovou platformu, narazí dřív nebo později na otázku, jaký datový stack zvolit a co je pro jejich byznys nejvhodnější. Migrovat na Microsoft Fabric? Nasadit dbt? Otázka je ale položená trochu zavádějícím způsobem, jde totiž o srovnání dvou věcí, které stojí na jiné úrovni datového stacku: Fabric je platforma, dbt je transformační nástroj, který na takové platformě běží. Přesto má smysl se ptát, jak se tyto dva světy doplňují, kde si uvnitř Fabricu konkurují nativní nástroje a dbt, a kdy se vyplatí sáhnout po dbt jako standardní transformační vrstvě.
Co řeší Microsoft Fabric
Fabric je konsolidovaná datová platforma postavená kolem OneLake jako jednotného úložiště. Přináší několik věcí, které řeší typické bolesti firem se stávající Microsoft infrastrukturou:
OneLake jako sjednocený storage layer pro celou organizaci, bez nutnosti kopírovat data mezi systémy.
Direct Lake mód v Power BI, který umožňuje reporting v řádu sekund bez klasického importu dat.
Entra ID a Purview pro autentizaci a governance, které firmy s Microsoft ekosystémem už typicky mají zavedené.
Database Mirroring zdarma pro Azure SQL, MySQL nebo Cosmos DB - replikace produkčních databází do OneLake bez nákladů na compute a v řádu sekund, což řeší častý problém reportů čerpajících přímo z produkčních systémů.
Bundled licencování, kde kapacita F64 a vyšší zahrnuje Power BI Pro pro čtenáře reportů zdarma.
Fabric ale ve výchozím stavu nabízí pro transformace nízkokódové nástroje - Dataflows Gen2, Fabric pipelines, případně notebooky. To pro řadu týmů stačí, ale s rostoucí komplexitou datového modelu narážejí na limity verzování, testování a udržitelnosti takového řešení.
Co řeší dbt
dbt (data build tool) není platforma, ale transformační framework. Jeho hodnota spočívá jinde:
SQL transformace verzované v Gitu namísto vizuálních toků nebo DAX měr, které se špatně sledují a reviewují.
Testy, contracts, lineage a dokumentace jako nedílná součást kódu, ne jako dodatečná vrstva.
Slim CI přes CI/CD pipeline (typicky GitLab nebo Azure DevOps), který dokáže ušetřit přes 90 % nákladů na testovací běhy tím, že testuje jen změněné modely.
Vendor neutralita - stejný SQL-first přístup funguje nad Snowflake, BigQuery i Fabricem, což usnadňuje případnou budoucí migraci.
AI workflow - nástroje jako Claude ve VS Code fungují nad dbt projektem identicky bez ohledu na to, nad jakým warehousem běží, protože AI tooling se řídí strukturou kódu, ne platformou.
Klíčový technický detail: dbt-fabric adaptér je Microsoft-maintained a v produkčním stavu (aktuálně primárně pro Fabric Data Warehouse/T-SQL; adaptér pro Lakehouse Microsoft chystá jako další krok). Spouštění dbt jobů přímo ve Fabric pipelines je zatím ve stavu Preview - funguje a je oficiálně podporované, ale ještě ne plně GA. Integrace tedy není provizorní nadstavba, ale aktivně rozvíjená a podporovaná součást ekosystému, u které je do poloviny roku 2026 avizovaná i podpora dbt Fusion.
Nativní Fabric nástroje vs. dbt - kdy se co hodí
Nativní Fabric (Dataflows, Pipelines) | dbt nad Fabricem | |
|---|---|---|
Vhodné pro | jednodušší, málo se měnící transformace, business uživatele bez SQL/Git zkušeností | komplexní datové modely, týmy senior data inženýrů, potřebu verzování a testů |
Governance | vizuální, méně auditovatelná historie změn | plné verzování v Gitu, code review před nasazením |
Testování | omezené, ruční | automatizované dbt tests a contracts |
Dokumentace a lineage | částečně automatická v rámci Fabricu | generovaná přímo z kódu, propojitelná s Purview |
Škálování týmu | složitější u více vývojářů současně | standard, který zná každý senior data engineer bez ohledu na firmu |
Praxe většiny migračních projektů ukazuje, že nativní nástroje jsou dobrým startem, ale jakmile datový model naroste na desítky až stovky transformací a do projektu vstoupí víc lidí, dbt vrstva se vyplatí — nejde o nahrazení Fabricu, ale o standardizaci té části stacku, kde vzniká nejvíc technického dluhu.
Závěr
Otázka „Fabric, nebo dbt" je z technického hlediska položená nesprávně — nejde o alternativy, ale o dvě vrstvy, které se navzájem doplňují. Fabric řeší, kde data leží a jak se dostanou k uživateli; dbt řeší, jak se cestou k tomu uživateli transformují a jestli té transformaci firma za rok ještě bude rozumět.
Prakticky to znamená jedno doporučení: začít s nativními nástroji tam, kde je transformační logika jednoduchá, a přechod na dbt naplánovat v okamžiku, kdy roste počet modelů, lidí v týmu nebo požadavky na auditovatelnost — ne až ve chvíli, kdy technický dluh začne brzdit dodávky. Díky tomu, že je dbt-fabric adaptér oficiálně podporovaný Microsoftem, nejde o rizikovou odbočku mimo standardní stack, ale o krok, který lze udělat postupně a bez nutnosti měnit platformu.
Verča
