Sdílený obsah: modely, Dataflows, OneLake
Cíle kapitoly
- Vysvětlit princip sdíleného sémantického modelu a roli Build permission
- Rozlišit thin report přes Live Connection od DirectQuery a composite modelu
- Použít lineage view a impact analysis před změnou sdíleného modelu
- Orientovat se v endorsementu — promoted, certified, master data
- Porovnat Dataflow Gen1 a Gen2 a zvolit vhodnou variantu pro sdílenou přípravu dat
Úvod — proč sdílet vrstvy, ne kopírovat data
Typický problém rostoucího Power BI prostředí: desítky reportů, každý se svou kopií dat a svou vlastní transformační logikou. Změna definice jedné metriky pak znamená opravu na mnoha místech současně, a riziko, že se na některém zapomene. Sdílená datová vrstva — jeden model, jedna transformace, jedno úložiště — tenhle problém řeší přesunem odpovědnosti z jednotlivých reportů na společné, centrálně spravované komponenty.
Tato kapitola probírá tři stavební kameny takové vrstvené architektury: sdílený sémantický model jako zdroj pro více reportů, Dataflow jako sdílenou přípravu dat a OneLake jako jedno úložiště pro celý tenant. Postupně je poskládáme do jedné architektury v poslední sekci.
Sdílený sémantický model a Build permission
Sémantický model publikovaný do jednoho workspace může sloužit jako zdroj pro reporty v úplně jiných workspace. Autor reportu se na takový model připojí přes Live Connection — nepotřebuje vlastní kopii dat, jen vizualizuje to, co model už obsahuje. Výsledek: jeden dobře postavený model může stát za desítkami reportů od různých autorů, a změna míry nebo transformace na jednom místě se projeví okamžitě všude, kde se model používá.
Aby na modelu mohl někdo stavět nový report, nestačí vidět workspace — potřebuje na konkrétním modelu Build permission. Bez ní model sice může být viditelný (třeba v OneLake catalogu), ale nejde na něm postavit report, použít ho v Excelu přes Analyze in Excel, ani se k němu připojit přes XMLA endpoint.
| Kdo má Build automaticky | Jak Build ještě získat |
|---|---|
| Uživatelé s rolí Contributor a vyšší přímo ve workspace modelu | Workspace → sémantický model → … → Manage permissions → přidat osobu nebo skupinu a zaškrtnout Build (přesné znění položky v UI ověřte, může se lišit verze od verze) |
| Nikdo jiný ve výchozím stavu | Publikací Power BI App s audience, která má na modelu Build přiřazený; nebo přes reshare, pokud má sdílející uživatel na modelu oprávnění Reshare + Build |
Viditelnost workspace a Build permission na konkrétním modelu jsou dvě nezávislé věci. Uživatel s rolí Viewer ve workspace model uvidí, ale bez explicitně přidaného Build na něm nepostaví nový report — dostane chybu při pokusu o Get data → Power BI semantic models. Naopak Build lze udělit i uživateli, který workspace se zbytkem obsahu vůbec nevidí, pokud se model sdílí i mimo workspace (přes Manage permissions, ne přes workspace role).
Thin report: Live Connection a její limity
Thin report je report bez vlastního sémantického modelu — veškerá data, míry a vztahy přicházejí ze sdíleného modelu přes Live Connection. V Power BI Desktopu ho založíte přes Get data → Power BI semantic models a výběrem modelu, na který máte Build permission.
Co thin report nemůže: přidávat vlastní tabulky ani psát vlastní Power Query dotazy — model je pro něj jen zdroj dat a struktury, ne surová data k transformaci. Co může: veškerou vizualizaci, vlastní bookmarks, vlastní stránky a filtrace, a navíc i vlastní report-level míry postavené nad existujícími sloupci a mírami modelu — reportovací vrstva zůstává plně v rukou autora.
Live Connection je jen jedna z cest, jak se na sdílený model napojit. Rozdíl proti composite modelu je zásadní pro pochopení, co má student volit kdy:
| Režim | Vlastní tabulky / Power Query | Co zůstává centrální |
|---|---|---|
| Live Connection (thin report) | Ne | Celý model — schéma, míry, RLS |
| DirectQuery na Power BI semantic model (composite) | Ano — lze přidat vlastní tabulky a kombinovat s DirectQuery zdroji | Zdrojový model zůstává živě dotazovaný, ne zkopírovaný |
| Import vlastního modelu | Ano — plná kontrola nad transformacemi | Nic — jde o vlastní, oddělenou kopii dat |
Allow DirectQuery connections to Power BI semantic models — bez něj composite mód nad sdíleným modelem nejde vůbec použít.Lineage view a impact analysis
Lineage view zobrazuje závislosti mezi položkami napříč workspace — odkud model čerpá data a které reporty na něm stojí. Report postavený přes Live Connection v lineage view ukazuje jasnou šipku na svůj zdrojový model; administrátor nebo správce modelu tak vidí dopad případné změny dřív, než ji provede.
Impact analysis jde o krok dál — před úpravou modelu (přejmenování míry, odstranění sloupce, změna typu dat) ukáže konkrétní seznam navazujících reportů a dashboardů, které by změnou mohly být zasažené. Je to standardní krok před jakoukoli breaking change na sdíleném modelu, ne až reakce na hlášení od uživatelů, že „report přestal fungovat".
Lineage view zobrazuje deklarované závislosti (report je postavený na modelu X), ne to, jak často se report skutečně otevírá nebo kým. Pro skutečné využití slouží Usage Metrics a Monitoring hub — viz kapitola 7. Kombinace obou pohledů — strukturálního (lineage) a provozního (usage) — dává úplný obraz před rozhodnutím model změnit nebo zrušit.
Endorsement: promoted, certified, master data
Ve velkém tenantu s desítkami modelů potřebuje uživatel rychle poznat, kterému modelu má věřit jako zdroji pravdy. K tomu slouží endorsement — badge viditelný přímo u položky v OneLake catalogu i při výběru zdroje dat.
| Úroveň | Kdo ji může nastavit | Význam |
|---|---|---|
| Promoted | Kdokoli s write permission na položce | „Doporučuji tento model ostatním" — bez centrální kontroly kvality |
| Certified | Jen autorizovaní recenzenti, nastavení Fabric administrátorem | Formální potvrzení kvality a spolehlivosti — typicky vyžaduje proces review |
| Master data | Jen autorizovaní recenzenti | Pro datové položky (Lakehouse, sémantický model) — označuje autoritativní zdroj referenčních dat |
Dokumentace: „Endorsed items are clearly labeled in the UI with a badge" (Learn, endorsement overview).
Dataflow Gen2 — sdílená příprava dat
Dataflow je Power Query transformace spuštěná v cloudu, bez nutnosti mít otevřený Power BI Desktop nebo přistupovat přímo ke zdroji přes SQL. Editor v prohlížeči je stejný Power Query zážitek jako v Desktopu — jen běží jako samostatná, plánovatelná položka ve workspace.
Volitelný staging je interní Lakehouse, který používá jen dataflow sám — mezikrok pro zrychlení zpracování dotazů (skládání do SQL analytics endpointu bývá rychlejší než in-memory zpracování v Power Query). Konzumenti mimo dataflow k tomuto internímu úložišti nemají přímý přístup; číst ho mohou jen přes dataflow connector v Power BI, Excelu nebo jiném dataflow. Pro skutečnou konzumaci výstupu (dalším modelem, Direct Lake, notebookem) slouží samostatné nastavení data destination — Dataflow Gen2 podporuje řadu cílů: Fabric Lakehouse (tabulky i soubory), Fabric Warehouse, Fabric SQL database, Fabric KQL database, Azure SQL database, Azure Data Explorer (Kusto), Azure Data Lake Storage Gen2, SharePoint Files, Snowflake nebo PostgreSQL. Při zápisu do Lakehouse je staging defaultně vypnutý — data jdou do destinace přímo.
Více sémantických modelů může čerpat ze stejné data destination — stejně jako u sdíleného modelu tím vzniká sdílená transformační logika: čištění dat, integrace více zdrojů, příprava dimenzí a faktů se dělá jednou, ne v každém modelu zvlášť. Plán refreshe Dataflow je nezávislý na plánu refreshe modelů, které z výstupu čerpají.
Dataflow Gen1 vs. Gen2
Dataflow Gen1 je podle dokumentace v legacy stavu — zůstává podporovaný, ale nedostává investice do nových funkcí. Pro zákazníky s Fabric nebo Premium kapacitou je doporučenou cestou Gen2, který nabízí lepší výkon, škálování a nativní integraci s Fabricem. Pro tenanty s Pro nebo PPU licencí bez Fabric kapacity zůstává Gen1 podporovanou volbou — vodítka pro Gen2 v těchto Pro/PPU scénářích Microsoft teprve připravuje.
| Dataflow Gen1 | Dataflow Gen2 | |
|---|---|---|
| Výstup | Vlastní interní úložiště, přístupné jen přes dataflow connector | Volitelná data destination (Lakehouse, Warehouse, SQL databáze a další), plus interní staging |
| Vyžaduje kapacitu | Ne — stačí Pro/PPU licence | Ano — Fabric, Premium nebo trial kapacita |
| Integrace s Fabricem | Omezená, chybí nativní Fabric integrace | Nativní — Git integrace, deployment pipelines (u Gen2 s CI/CD podporou) |
| Vývoj | Legacy — bez investic do nových funkcí | Aktivní vývoj |
OneLake a OneLake catalog
OneLake je automaticky vytvořené úložiště pro celý Fabric tenant, postavené na Azure Data Lake Storage Gen2. Každý Lakehouse a Warehouse má v něm svůj prostor, data se ukládají ve formátu Delta Parquet. Přístup je možný přes OneLake file explorer (aplikace pro Windows integrovaná do Průzkumníka souborů), ADLS API, Spark nebo SQL endpoint.
Centrální místo pro objevování a správu dat napříč tenantem je OneLake catalog — nástupce staršího „data hub". Skládá se ze tří oblastí: Explore (hledání a náhled položek), Govern (tenant-wide governance insights, nástupce staršího preview reportu „Feature usage and adoption") a Secure (správa přístupů).
OneLake běží na stejné technologii jako ADLS Gen2, ale je spravovaný Fabricem jako jeden logický namespace pro celý tenant — ne jako samostatný storage account, který by bylo nutné explicitně zakládat a konfigurovat. Výhoda: jednotné zabezpečení, jedno místo pro shortcuts napříč workspace, žádná duplicitní správa storage účtů per projekt.
Shortcuts a Direct Lake
Shortcut je odkaz na data uložená jinde — v jiném Lakehouse, v externím Azure Data Lake, případně v jiném cloudovém úložišti — aniž by se data fyzicky kopírovala. Z pohledu konzumenta vypadá shortcut jako běžná tabulka nebo složka; čtení probíhá přímo ze zdroje při dotazu.
Na shortcuts i přímo uložená data v OneLake se může napojit sémantický model v režimu Direct Lake — čte přímo z Delta tabulek v OneLake, bez importu a bez nutnosti DirectQuery. Podle dokumentace existují dva režimy Direct Lake (podrobněji v kapitole 1): Direct Lake on OneLake, doporučovaný pro nové modely, který běží výhradně v Direct Lake módu bez DirectQuery fallbacku a podporuje composite modely, a Direct Lake on SQL analytics endpoint, který může za určitých okolností (např. SQL RLS, OLS nebo view na zdrojových datech) přepadnout na DirectQuery.
Vrstvená architektura — vše dohromady
Tři stavební kameny z téhle kapitoly — sdílený model, Dataflow a OneLake — skládají dohromady vrstvenou architekturu, kde je každá vrstva nezávisle spravovatelná a verzovatelná.
Tohle je cíl managed self-service BI v Microsoft Fabricu — IT/BI tým spravuje spodní, sdílené vrstvy (Dataflow, OneLake, sémantický model), zatímco business uživatelé svobodně stavějí reportovací vrstvu nahoře, bez rizika, že si každý bude vytvářet vlastní, nekonzistentní kopii dat.
Reference
- Build permission for shared semantic models (EN)
- Use semantic models across workspaces (Live Connection, thin reports) (EN)
- Dataflow Gen1 vs. Gen2 — feature comparison (EN)
- Dataflow Gen2 CI/CD a Git integrace (EN)
- OneLake catalog overview (EN)
- Endorsement overview (promoted, certified, master data) (EN)
- Direct Lake overview (EN)