Sémantický model v Power BI umí popisy (descriptions) u tabulek, sloupců i measures. Datový sklad pod ním obvykle ne. Nebo aspoň ne tak, aby je někdo skutečně udržoval. Jestli jste někdy otevřeli tabulku s názvem col_17_flg a hledali, co znamená, víte, o čem je řeč.
Tenhle článek je pro vývojáře z Power BI světa, kteří uvažují o Fabricu a slyšeli o dbt. Nebude to kompletní průvodce dbt. Vysvětlím, co to je, proč mě to zaujalo a jak se z popisů napsaných jednou dostanete až do sémantického modelu.
Co je dbt (a co není)
dbt (data build tool) je nástroj na transformace dat uvnitř databáze. Nenačítá data, neorchestruje celý svět a nemá vlastní úložiště. Dělá jednu věc: ze SQL dotazů (modelů) postaví tabulky a views ve správném pořadí a ohlídá, že výsledek sedí.
Pro člověka z Power BI se to dá přirovnat takto:
- model je jeden
SELECTuložený v souboru. dbt z něj udělá view nebo tabulku. Něco jako dotaz v Power Query, jen v SQL a ve skladu. - ref() je odkaz na jiný model. Podle něj dbt pozná závislosti a sestaví lineage (graf, co z čeho vzniká). V Power BI znáte podobné zobrazení závislostí.
- test je pravidlo nad daty (
unique,not_null, vztah mezi tabulkami). Spustí se spolu s buildem. - YAML soubor vedle modelu popisuje model a sloupce: tady se píší descriptions. A právě to je důvod, proč jsem u dbt skončil.
Všechno jsou to textové soubory v Gitu. Pro vývojáře z Power BI, který si zvykl na PBIP a TMDL, to není nic cizího.
dbt ve Fabricu
Fabric má vlastní položku dbt job (Data Factory). Spouští dbt Core ve spravovaném runtime, takže nic neinstalujete lokálně. Projekt vezmete z ukázky (Jaffle Shop) nebo z GitHub repozitáře, vyberete cíl (Warehouse, Lakehouse a další podporované adaptéry) a job můžete naplánovat. Po běhu uvidíte lineage, zkompilované SQL a výsledky. Podle oznámení z FabCon Europe (29. 9. 2026) je dbt job ve stavu GA. Oznámení: FabCon/SQLCon Barcelona 2026: What’s new in Fabric Data Factory. Zapíná se v tenant settings.
Založení dbt jobu: vzorový projekt Jaffle Shop
Připojení projektu k cíli: výběr profilu adaptéru
Adaptéry jsou dva důležité:
- dbt-fabric pro Fabric Data Warehouse (T-SQL),
- dbt-fabricspark pro Lakehouse (Spark SQL přes Livy API, zapisuje Delta tabulky do OneLake).
Rozdíl je podstatný: SQL analytics endpoint u Lakehouse je pro dbt jen pro čtení, takže transformace ve stylu T-SQL patří do Warehouse. Pokud je váš tým spíš Spark, sáhnete po Lakehouse.
Nový Warehouse jako cíl dbt jobu
Profil adaptéru: Warehouse, schéma jaffle_shop, nahrání seed dat
Dva praktické limity z dokumentace: dbt job nemá build cache (každý běh kompiluje projekt od nuly) a ne všechny partnerské adaptéry jsou ve Fabricu podporované.
Proč mě to zajímalo: kde žijí popisy
V sémantickém modelu Power BI je popis jednoduchý. Zapíšete ho do vlastností sloupce nebo do TMDL a uvidí ho každý, kdo model použije, včetně Copilota a dalších nástrojů, které se na model dotazují.
Pod tím je ale datový sklad. A tam popisy sloupců uložit nejde. Standardní cesta ze SQL Serveru (extended properties) ve Fabric Warehouse nefunguje: sp_addextendedproperty Warehouse odmítne s hláškou, že procedura není podporovaná. Praktický důsledek: popisy se nejčastěji řeší vedle databáze. Excelem, wiki nebo vlastní konfigurační databází, kam se píše, co který sloupec znamená. Funguje to, dokud to někdo udržuje. Obvykle to trvá do prvního release.
dbt tenhle problém řeší jinak. Popis sloupce leží ve stejném YAML souboru jako model, ve stejném commitu a prochází stejným code review. Změníte sloupec a popis vidíte hned vedle.
Ukázka z demo projektu Jaffle Shop (fiktivní e-shop, který dbt i Fabric nabízejí jako vzorový projekt):
version: 2
models:
- name: customers
description: This table has basic information about a customer, as well as some derived facts based on a customer's orders
columns:
- name: customer_id
description: This is a unique identifier for a customer
tests:
- unique
- not_null
- name: first_order
description: Date (UTC) of a customer's first order
- name: number_of_orders
description: Count of the number of orders a customer has placed
- name: total_order_amount
description: Total value (AUD) of a customer's orders
schema.yml s popisy v editoru dbt jobu ve Fabricu
Delší popis nemusíte cpát do YAML. Dá se napsat jako doc blok v Markdownu (docs.md) a z YAML na něj odkázat přes {{ doc("orders_status") }}. V demu takhle vypadá popis stavů objednávky:
Doc blok orders_status v souboru docs.md
Popisy a závislosti skončí v artefaktu manifest.json, který dbt job ve Fabricu ukládá při každém běhu do složky target v OneLake. Příkaz dbt docs generate k tomu přidá catalog.json se skutečnými sloupci a typy z databáze. Pozor: ve Fabricu se vygenerovaná dokumentace zatím nerenderuje jako web, máte jen soubory.
Příkazy dbt jobu, mezi nimi i docs generate
Popisy až do databáze
dbt umí popisy zapsat i do samotné databáze, jako komentáře k tabulkám a sloupcům. Slouží k tomu konfigurace persist_docs:
models:
my_project:
+persist_docs:
relation: true
columns: true
Na řadě platforem to funguje (Snowflake, Databricks, BigQuery a další). Pro Fabric je situace rozdělená a vyzkoušel jsem si obě varianty:
- Warehouse (dbt-fabric): dokumentace dbt
persist_docspro tento adaptér neuvádí a test to potvrdil.dbt runspersist_docskončí chybou „alter_relation_comment macro not implemented for adapter fabric“, u sloupců totéž salter_column_comment. Model spersist_docstedy spadne, pro Warehouse ho nechte vypnutý. - Lakehouse (dbt-fabricspark):
persist_docsfunguje. Popis tabulky i sloupců skončí v metadatech Delta tabulky (ověřil jsem v Delta logu). SQL analytics endpoint je ale do T-SQL metadat nepromítne (sys.extended_propertieszůstane prázdné), takže přes T-SQL je neuvidíte.
Proč to ale není slepá ulička: popisy nemusí být v databázi, aby je někdo přečetl. Jsou v dbt projektu a v artefaktech. Kdo potřebuje metadata, přečte je odtud. A tím se dostávám k tomu, co mě na tom baví nejvíc.
Agent staví sémantický model a popisy si přečte sám
Sémantický model Power BI dnes umíme stavět i s agentem. Microsoft k tomu má Power BI Authoring MCP server (lokální verze se instaluje jako powerbi-modeling-mcp), který umí s modelem pracovat (tabulky, sloupce, measures, vztahy, popisy). Agent pak může model sestavit nad vaším skladem.
Obvyklý problém: agent vidí názvy sloupců a typy, ale neví, co znamenají. Model pak vznikne bez popisů, nebo se popisy domýšlejí. A domýšlené popisy jsou horší než žádné.
Pokud ale agent dostane k dispozici dbt projekt (nebo manifest.json), může popisy převzít. Zadání je jednoduché: „Postav sémantický model nad schématem jaffle_shop, popisy a vztahy převezmi z dbt projektu.“ Agent přečte popis customer_id z YAML a zapíše ho jako description sloupce v modelu. Vztah orders → customers odvodí z testu relationships, který je v YAML u sloupce orders.customer_id. Co jednou popíšete v dbt projektu, agent přenese do sémantického modelu bez ručního přepisování. Copilot a Fabric data agent pak nad modelem mají k dispozici popisy, které byste jinak psali ručně.
Zadání agentovi a shrnutí jeho běhu (výstup přepsaný do přehledné podoby), včetně nahlášeného nesouladu
Výsledný model v TMDL view: popisy z dbt jako /// komentáře
Jedna pojistka: popis z dbt je vstup, ne pravda. Hezky se to ukázalo hned v demu. YAML popisuje u zákazníka sloupec total_order_amount (viz ukázka výše), jenže tabulka ve Warehouse ho nemá, místo něj obsahuje customer_lifetime_value bez popisu. Nesoulad je přímo ve vzorovém projektu. Agent to porovnal se skutečnou tabulkou, nesouhlasící popis nepoužil a nesoulad nahlásil. Kdyby popisy jen slepě kopíroval, měli byste v modelu popis ke sloupci, který neexistuje. Agentovi proto dejte za úkol model postavit a nesoulady hlásit, ale zkontrolovat ho musíte vy.
Demo
Demo stojí na vzorovém projektu Jaffle Shop (fiktivní e-shop: zákazníci, objednávky, platby) ve Fabric Warehouse. Postup:
- dbt job ve Fabricu nad Warehouse, modely ve dvou vrstvách (staging a výsledné tabulky
customersaorders). - Popisy sloupců výsledných tabulek v YAML, testy
unique,not_null,relationshipsaaccepted_values. - Spuštění jobu s příkazem
build, kontrola lineage a výsledků testů. - Agent načte popisy z dbt projektu a postaví nad Warehouse sémantický model (Direct Lake).
- Výsledek v Power BI: popisy tabulek a sloupců ve vlastnostech modelu.
Lineage view v dbt jobu: seedy, staging a výsledné tabulky
Výsledek dbt build: modely i testy prošly
Sémantický model (Direct Lake) ve Fabricu: popis sloupce first_order převzatý z dbt
Chování persist_docs ve Warehouse a v Lakehouse jsem zkoušel zvlášť na malém testovacím modelu (výsledky viz výše).
Kdy to dává smysl a kdy ne
Dává to smysl, pokud:
- máte transformace ve skladu v SQL a chcete je verzovat, testovat a mít lineage,
- chcete jedno místo pro popisy, které se dostane i do sémantického modelu,
- už dbt znáte, nebo máte tým, který zvládne Git.
Nedává to smysl, pokud:
- máte pár tabulek a transformace řešíte jednou za čas,
- nikdo nechce psát popisy: dbt je nevymyslí, jen je udrží u kódu,
- potřebujete něco, co dbt Core nemá. dbt job ve Fabricu dnes spouští dbt Core, novější engine Fusion v něm zatím není.
Závěr
Dnešní článek měl ukázat, co je dbt a proč ho zvážit ve Fabricu, i když jste vývojář Power BI. Pro mě je hlavní důvod popisy: napsat je jednou u kódu a nechat je přečíst agenta, který staví sémantický model. Warehouse a Lakehouse se v tom chovají odlišně, proto si to vyzkoušejte na malém projektu dřív, než to nasadíte na něco důležitého.
Zdroje:
