Power BI: Dataflows versus datasety a sdílená architektura

Uvažujete o implementaci Power BI, anebo ho už používáte pro firemní reporting? Máte hodně reportů, které čerpají data ze stejných zdrojů? Pracuje na jednom projektu více vývojářů? Chtěli byste, aby si vaši zaměstnanci mohli sami vytvářet nové reporty na očištěných, ověřených a otestovaných datech?

Nejen pro tyto případy je nejvhodnější využít v Power BI Service architekturu sdílení dat napříč reporty. Připravili jsme pro vás přehled výhod (a nevýhod) využívání dataflows a datasetů a rozdíly mezi nimi. Dozvíte se také, jak sdílená architektura funguje a proč by měla mít místo ve vašem reportingu.

Dataset

Pokud vytváříte reporty v Power BI Desktop a poté je publikujete do Power BI Service, asi jste si všimli, že jeden soubor .pbix se po nahrání zobrazí jako dvě entity – report a dataset. Oddělí se vrstva vizualizací a datová vrstva. Vrstva vizualizací obsahuje nastavení stránky, jednotlivé grafické prvky a vizuály. Ta druhá (dataset) si ponechává všechny tabulky, transformace, datový model a míry.

Na dataset je možné se napojit v jiném reportu a pře-použít ho jako zdroj dat. Můžeme jej také sdílet s dalšími uživateli. Úpravy dat už není nutné (a do velké míry ani možné) v napojeném reportu opakovat a dotyční se mohou soustředit jen na design a tvorbu vizuálů.

Dataflow

Dataflows jsou online nástroj pro sběr a uložení dat. Můžeme se na ně dívat i jako na ETL vrstvu – v Power BI Desktopu se dataflow chová jako další datový zdroj, na který se můžeme napojit. Tento mezikrok nám umožňuje si data v Service předpřipravit (filtrovat, očistit…) a získat je tak do reportu ve vyšší kvalitě. Transformace a úpravu v případě dataflow provádíme v cloudové verzi Power Query, a tak můžeme i například překopírovat Advanced Query kód z Power BI Desktop.

Dataflow versus dataset

Výsledkem dataflows i datasetu je v obou případech tabulka nebo skupina tabulek.  Oba sídlí v Power BI Service a najdeme je ve zvoleném pracovním prostoru (workspace). Ale zatímco dataset většinou upravujeme v Power BI Desktop (jako součást reportu) a musíme jej při každé změně znovu publikovat, dataflow vytváříme a spravujeme po celou dobu jeho životnosti v cloudu.

V datasetu se lze na zdrojová data napojit pomocí import, direct query, dual či live, dataflow umožňuje pouze import.

Zatímco primární dataset má pro tvorbu transformací k dispozici jak Power Query, tak i DAX a další nástroje (tvorbu measures, konečné formátování sloupců, relační vztahy), v případě dataflow si musíme vystačit pouze s cloudovou verzí Power Query.

Pokud se napojíme na publikovaný dataset v jiném reportu, nemůžeme provádět většinu transformací – např. upravovat datový model, měnit a přidávat sloupce či upravovat převzaté míry. Můžeme pouze vytvářet nové míry na existujících datech. Takto lze rozdělit míry na globální (v hlavním datasetu) a lokální (v podřízeném reportu).

Dataflow oproti tomu můžeme snadno kombinovat s jinými zdroji a v Desktopu na něm lze provádět všechny dostupné transformace, a to jak v Power Query, tak i po načtení v DAXu. Zároveň je dataflow v cloudu snadno editovatelné.

Kdy zvážit využití sdílených datasetů a dataflow?

Především tam, kde více reportů čerpá ze stejných dat, nebo by tomu tak mělo být. Můžeme vytvořit jeden zdroj pravdy napříč organizací – sdílet formátování sloupců, vypočítané sloupce, míry, hierarchie, datový model, vazby a jejich kardinality a další nastavení. V takové situaci si bude moci i méně zkušený uživatel sám vytvářet jednoduché ad hoc reporty při zachování kvality zdrojových dat.

Dobré je tento přístup zvážit i v případě, že chceme centrálně spravovat, jaká data budou dostupná různým osobám, aby s nimi mohly dále pracovat – pomocí  row level security například vedoucí pobočky uvidí data pouze pro svou pobočku, skryjeme určité sloupce a míry, které měly být dostupné pouze vývojářům, zpřístupníme jen agregovaná výsledná data atp.

Bez využívání Service se také neobejdeme, pokud má více lidí najednou vyvíjet jeden report nebo mít možnost ho upravovat. Struktura dataflow – dataset – reporty tento proces podstatně zjednodušuje, i když i tak jsou zde některá omezení (viz nevýhody využití).

Čištění a transformace dat tvoří i 70 % práce při vývoji reportu. Při využití sdílených datasetů a dataflows probíhá úprava dat ze stejného zdroje pouze jednou, takže jsou výpočetní zdroje využity efektivněji. Můžeme provést úpravy jen jednou a vždy se napojit pouze na výsledek. Například pokud opakovaně využíváme stejnou kalendářní tabulku.

Své využití sdílená architektura najde také při optimalizaci reportů. Microsoft Cloud načítá data rychleji než většina PC, a mezi ním a Desktopem vede „přímá cesta“ – rychlejší než z datových zdrojů třetích stran. Pokud část transformací proběhne ještě před načtením do reportu, zmenší se jeho velikost a zrychlí aktualizace.

Další výhodou jsou orchestrované aktualizace dat – automatizované ve stanovený čas, navázané na sebe v různých vrstvách architektury (nejdřív zdroj, poté dataset). Můžeme také nastavit různou frekvenci aktualizací různých zdrojů (např. HR systém 1x měsíčně, IoT co deset minut, zbytek 1x denně).

Nevýhody využití

Nevýhodou Power BI obecně je verzování – chybí nativní verzování, které by bylo efektivně využitelné při spolupráci více lidí. Nevidíme historii změn a nejsou snadno dostupné starší verze reportu, pokud je manuálně neukládáme například na SharePoint. Navíc každé dataflow a každý dataset může souběžně vlastnit a spravovat pouze jeden vývojář nebo servisní účet. Je ale možné si je mezi sebou „přehazovat.“

Ve sdílené architektuře jsou související položky propojené online, neuvážené změny tak mohou mít své následky. Pokud například změníme dataflows, změna se ihned po aktualizaci projeví všude v cloudu, kde jsou dataflows použité. Tomu se dá částečně předejít, pokud stejné dataflows nepoužívá současně development i produkce, ale většinou to znamená potřebné změny provádět manuálně dvakrát, nebo nasazovat do produkce (a případně i testovacího prostředí) pomocí “Kanálů nasazení” (Deployment Pipelines) vyžadujících prémiovou licenci.

Obecně, máme-li hlavní dataset a podřízené reporty, je složitější jejich správa při častých změnách. Report může například nezobrazit vizuál, pokud přejmenujeme sloupec v datasetu (hlavním reportu), ale nikoli v navázaném reportu. Také musíme vždy publikovat hlavní report, aby se změna projevila v reportech podřízených (například přidaní vypočteného sloupce).

Příklady použití

Pojďme se se nyní na několika příkladech podívat, jak může sdílená architektura vypadat v praxi.

První diagram ukazuje základní model sdílené architektury – více rozdílných dataflow a další zdroje jsou napojené na hlavní dataset a ten je poté využit ve více reportech.

Ve druhém případě je konstrukce trochu složitější – máme dva datasety, které sdílí společné dataflow, ale jsou každý napojen na další zdroje dat.