PowerBI: Tvoříme report v PowerBI

Norma není dogma. To, že to není podle normy neznamená, že je to špatně, alespoň do té doby, dokud to funguje.

Je potřeba nasadit PowerBI v “širokém” prostředí? V korporaci? Ve velké firmě? Pro mnoho reportů a mnoho uživatelů? Nebo-li chceme “Enterprise solution“? Ano?
Tak jdeme na to (a možná se nám to i povede).

Základem je prostředí = kontext

PowerBI nebude žít jen samo o sobě. Nevyženeme ho na opuštěný ostrov. PowerBI je vlastně taková třešnička na dortu celého datového prostředí/řešení/architektury. Takže musí synergicky fungovat se všemi komponenty, které kolem sebe má a ještě navíc vypadat skvěle.

Datovou architekturu si můžeme představit takto, to je ten náš kontext.

Když to vezmeme zjednodušeně, tak na obrázku jsou vidět tři základní body, které se k PWBI vztahují a které je potřeba řešit.
– umístění
– datový vstup
– výstup (přístup uživatelů k PWBI)
Kolem těchto tří bodů se bude všechno točit.

Základní termíny

Na začátek si sjednotíme slovník. Tzn. navštívíme jiný post :-).

http://scoutincloud.eu/2022/04/powerbi-zakladni-terminy/

Jmenné konvence

Než něco někam umístíme, tak si to musíme správně pojmenovat. Opět návštěva jiného postu.
http://scoutincloud.eu/2022/04/powerbi-jmenne-konvence/

---

Od teorie k praxi

Není nad to si teorii přetavit do praxe. Proto teorii rovnou vynecháme a vrhneme se na praxi.
Níže naleznete popis toho, co všechno je potřeba rozmyslet a udělat když se tvoří PWBI report.

Výchozí situace (kontext)

• Organizace s N zaměstnanci se zaměřením XY (dejme tomu, že N je tak veliké, aby již mělo smysl mluvit o nasazení PWBI do online tenantu).
• Organizace má klasickou BI architekturu
  • Datové zdroje
  • Integraci datových zdrojů
  • Landing/Stage vrstvu
  • DWH/Core vrstvu
  • Datamart vrstvu
  • Sémantickou/reportingovou/analytickou vrstvu (viz obrázek výše)
• Není uvažováno o realizaci analytické vrstvy například v Analysis Services.
• Datovým zdrojem pro reporting má být datamart/reportingová vrstva.
• Řízení přístupů probíhá přes Active directory, případně přes Office365 (Microsoft365).
• Je potřeba vytvořit interní reporting, do kterého budou mít přístup všichni zaměstnanci, jak pro přístup k provozním datům, tak k datům pro byznys potřebu. Ne všichni uživatelé smějí vidět všechno.
• Některým uživatelům bude umožněn přístup přímo k datům (relační reportingová vrstva) a některým uživatelům bude umožněn přístup pouze do PWBI tenantu.
  Uživatelé jsou různě zdatní. Některým bude dovoleno si nad PWBI datasety stavět vlastní reporty a zbytek bude jen koukat.
  • Z toho plynou byznys role (neplést s PWBI rolemi) 
    • viewer = pouze přístup k reportům
    • contributor = přístup k reportům + možnost stavět nad datasety vlastní reporty (které může sdílet ostatním) 
    • power user = vše jako předešlé role + přístup do pokladové reportingové vrstvy, je to takový analytik, který si dělá query nad daty
• Realizace nemusí být sériová, je možné provádět kroky realizace paralelně. Záleží na tom kolik rukou v realizačním týmu je. Některé kroky jsou obecné a mohou se aplikovat na jakýkoli report či na celé prostředí a jiné jsou zase specifické pro konkrétní použití (roli, uživatele, dataset, report, workspace).

Následuje seznam kroků realizace.

Kroky realizace

• Příprava dat
  • Příprava sémantické/reportingové vrstvy v podobě pohledů (views) nad relační datamartovou databázi. Nemusí jít o samostatnou databázi, ale třeba jen skupinu tabulek v určitém schématu.
  • Kromě základních datamartových dat jsou v reportingové vrstvě připravené i míry a ukazatelé, které je možné v relační vrstvě připravit. Omezíme tím náročnost generování PWBI reportu a přesuneme výpočetní zátěž na nižší vrstvu, která si s ní lépe poradí.
  • Názvy atributů v pohledech už jsou uživatelské/byznysové. Vyhneme se tím přejmenovávání v PWBI reportu a všechny reporty nad reportingovou vrstvou budou konzistentní (nejhorší je, když si stejná data, každý pojmenuje jinak, to se pak v tom nikdo nevyzná).
  • V této vrstvě by již nemělo být moc transformací ani výpočtů, ty už by měla obsahovat vrstva datamartu. Pokud by se v každém reportu, nad stejnými daty, počítalo něco znova, tak se může stát, že každý report bude ukazovat stejné ukazatele jinak.
  • Tato vrstva by měla obsahovat jen data potřebná k reportingu a nic navíc (co se dále nepoužije).
  • Tato vrstva nás případně i ochrání před změnou datamartu. Pokud se datamart bude měnit, tak je možné upravit views, tak aby reporting mohl fungovat zatímco se nižší vrstvy budou měnit a upravovat. Až se vše usadí, změní se reportingová vrstva (pokud to bude potřeba) a upraví se samotné reporty. Ano, z toho plyne riziko, že se rozjede podoba datamartu a reportingové vrstvy.
  • Pokud potřebujete do reportingu dostat přirozené klíče ze zdrojových systému, tak se k nim chovejte jako k jakýmkoli jiným popisným atributům. Pro realizaci vazeb mezi reportingovými entitami použijte umělé klíče z DWH/datamartu.
• PWBI přístup k datům
  • Máme připravená podkladová data, teď se k nim potřebujeme dostat. Nejjednodušší způsob je pomocí databázového uživatele. Ten nám stačí jen s read právy do db schématu kde je vytvořena reportingová vrstva. Pak už jen stačí znát adresu sql serveru a název databáze. Protože máme připravená pokladová views, tak nám stačí nalinkovat potřebné objekty.
  • Datové zdroje si parametrizujte. V ideálním světě vyvíjíme na DEV prostředí a finále prezentujeme na PROD prostředí = máme DEV a PROD data. Není potřeba mít pro každé prostředí samostatný report. Je možné si vytvořit parametry, které obsahují název serveru a databáze pro jednotlivá prostředí a parametry pak podle potřeby měnit.
• PWBI Import/Direct/Hybrid
  • Jak často se budou data reportu měnit? Každý měsíc/týden/den? Pokud takto, tak si data do reportu naimportujeme.
  • Pokud data potřebujeme častěji (třeba jde o monitoring datových zpracování, kde potřebujeme znát aktuální stav co čtvrt hodiny), tak si vybereme DirectQuery. Pak se nám data aktualizují přímo z db při každém otevření reportu, refreshi či přechodu mezi stránkami reportu. Pozor, ale na množství stahovaných dat.
  • Samozřejmě, že záleží i na množství dat. Dat bychom v reportu neměli potřebovat hodně. Agregace si uděláme v nižší vrstvě a tím si množství dat snížíme. Případně můžeme použít i where s parametrem pro stahování konkrétnějších dat z reportingové vrstvy. A import s DirectQuery můžeme i kombinovat. Velké tabulky, které se často nemění (třeba číselníky a dimenze) můžeme importovat a pro rychle se měnící fakta můžeme použít DirectQuery = hybrid.
• PWBI model
  • Vazební atributy pro tvorbu modelu máme připravené již v reportingové vrstvě, takže relace nám může vytvořit PWBI samo (i když automatickou tvorbu relací nedoporučuji, člověk je pak stejně musí ručně kontrolovat).
  • Doporučuji si vymodelovat hvězdu, případně vločku a do nějakých velkých složitostí se nepouštět. Není moc případů kdy je reálně využitelný košatý siamský strom.
  • O modelování tu moc řeč nebude. Omezíme se na realizaci relací mezi entitami pomocí vazebních atributů. Model jako takový, by již měl být vytvořen/připraven v datamartu či v reportingové vrstvě – v PWBI vlastně jen realizujeme již připravené relace.
  • Pokud máte, tak si přidejte datumovou dimenzi. Ta se vždycky hodí. Zejména pokud nemáte kontinuální časovou řadu přímo v datech. Někdy se hodí datumových dimenzí více, ale to už stačí referencovat tu první přidanou.
• PWBI atributy
  • Názvy atributů jsou už vytuněné v reportingové vrstvě.
  • Atributy, které se nebudou v reportingu používat se mohou skrýt (ať je někdo nezneužije – třeba vazební ID atributy). Případně nemusí ani být v reportingové vrstvě.
  • Vyberte jeden způsob formátování pro data, čísla, peníze, atd. a ten používejte všude (ať vše vypadá konzistentně).
  • Atributy si zaškatulkujte do složek podle významu.
  • U důležitých (a to jsou vlastně všechny atributy) atributů vyplňte popisy, ať uživatelé vědí co co znamená a ať to následně umí použít. Případně i vzorečky pro výpočet ukazatelů.
  • Správně seřaďte datumové atributy, vytvořte si hierarchii. Ať jdou měsíce pěkně za sebou a ne podle abecedy.
• PWBI vizualizace
  • Už máme v reportu data, už máme model, tak můžeme začít s vizuály.
  • Vytvořte si jednotný layout. Kde budou meta informace (přihlášený uživatel, datum a čas načtení zdrojových dat, datum a čas refreshe dat, případně hodnoty důležitých vstupních parametrů, které ovlivňují způsob načítání dat), filtry, hlavní věcné vizuály (grafy, tabulky). Případně doplňte o vizuální oddělovače. Taková čára oddělující filtry od dat udělá divy.
  • Všechny tabulky napříč reportem formátujte stejně. Držte konzistenci v podmíněném formátování (třeba barvičky pro škálování ať škálují všude stejně).
  • Nesnažte se na jednu stránku reportu naházet co nejvíce dat. Méně je více, více než kdy jindy.
  • Vytvořte si separé stránku kam budete psát release notes – ať uživatelé vědí co je v reportu nového.
  • Vytvořte si separé stránku se slovníčkem. Pokud je potřeba vysvětlit nějaké termíny či reálie, tak se to hodí mít přímo v reportu.
• PWBI report máme hotový (křtiny)
  • Je potřeba si report správně pojmenovat. Chce to jednoduchý, věcný a tematický název.
  • Pokud máte reportů hodně, tak se hodí i jednoznačný identifikátor ve formě prefixu či postfixu. Pokud bude konzument report reklamovat, stačí zadat identifikátor a je jasné kam je potřeba se podívat.
  • Mějte někde, dobře strukturovaný, seznam reportů s jejich popisem. Takový katalog. Uživatelé ho mohou používat jako základní rozcestník a můžete tam přidat i informaci o tom kdo je vlastníkem reportu, kdo je kontaktní osobou v případě problémů, kdy se refreshuje, atd.
• PWBI verzování
  • Než začneme PWBI reporty publikovat do onlinu, tak je potřeba si říci jestli máme verzovací ambice.
  • Chceme mít historii jednotlivých verzi PWBI reportu?
  • Chceme mít kontrolu nad tím kdo a kdy v reportu provedl nějakou změnu?
  • Bude na jednom reportu pracovat více lidí, kteří by si mohli lézt do zelí? Jde o paralelní práci – v jeden moment více developerů na jednom reportu (zas tak často se to nestává, ale náhoda je blbec).
  • V praxi jsem narazil pouze na jeden efektivní způsob verzování. Nahrávání pbix souborů do Gitu mi moc rozumné nepřijde. Navíc v momentě kdy jsem toto řešil nebyl jednoduchý způsob jak zDevOpsovat nasazení reportu z Gitu do PWBI online služby jednoduchým způsobem. Já zvolil SharePoint.
  • V nastavení workspace je možné, k němu, přiřadit Workspace OneDrive. A když vytvoříte SharePoint stránku, tak co se stane? Založí se i OneDrive – pak už stačí spárovat tento OneDrive s PWBI workspace a můžete spravovat pbix soubory v SharePointu. To znamená, že můžete pbix soubory vesele verzovat, check outovat a check inovat a máte vyhráno. Když se potom z tohoto OneDrive nasadí report do online služby, tak stačí synchronizovat OneDrive a můžete s reporty pracovat přes průzkumníka ve Win. Jakákoli úprava v reportu se poté rovnou přenese do reportu, který je nasazen.

• PWBI workspace
  • Report je hotový. Je potřeba ho někam dát. Jako základní skříň, do které se strkají šanony (reporty), slouží workspace.
  • Je to taková základní jednotka pro řízení přístupů k reportům. Pustím tě do workspace, uvidíš reporty.
  • Opět věcné pojmenování, aby bylo poznat čeho se reporty uvnitř týkají.
• PWBI deploy
  • Je více možností jak report do workspace dostat a je to vlastně hlavní část toho jak je celý PWBI ekosystém koncipovaný.
    • Publish přímo z PWBI reportu – málo flexibilní
    • Deployment pipeline v PWBI service – moc robustní
    • Deploy z OneDrive připojené SharePoint stránky – pro mě ideál (viz bod výše)
    • Upload pbix souboru z PWBI service – krkolomné
• PWBI uživatelé
  • Konzumenti reportů jsou uživatelé, lidé = jednotlivci. Už od počátku věků se lidé rádi shlukují = tvoří skupiny. A to ctí i PowerBI. Přístup uživatelů k reportům jde řídit přes jednotlivce i přes skupiny (třeba O365 skupiny či security skupiny v AAD).
  • Je výhodné uživatele, kteří pracují s PWBI určitým, společným způsobem, dávat do skupin. Pak je můžete ovlivňovat hromadně = řídíte oprávnění pro skupinu a to se aplikuje na všechny členy skupiny. Ušetří vám to mnoho práce.
• PWBI práva
  • A už je tu finále. Teď už jen do reportu pustit davy.
  • Opět je tu několik možností jak přidělit práva na report.  Základem je pustit uživatele do celého workspace. Pokud v něm jsou, tak report vidí. Pak už jen záleží na tom jakou roli uživatel má.
    • Viewer – uživatel může pouze číst, nepotřebuje PRO licenci pokud je workspace v Premium verzi
    • Contributor – uživatel může vytvářet, editovat, kopírovat a mazat objekty ve workspace, publikovat reporty, nastavovat datasety a spravovat pwbi bránu.
    • Member – uživatel má navíc práva dávat práva, ne všechna, ale může rozhodovat o tom kdo bude viewer a kdo contribotur a dává práva ostatním uživatelům pro reshare
    • Admin – ten už může úplně všechno

• Jak práva řídit? Jednotlivě nebo skupinově? Rozhodně skupinově. Asi se nestane, že byste dělali report jen pro jednoho jediného uživatele. Většinou jich je víc, celá skupina.
  • Workspace – přidáte uživatele/skupinu a přidáte role uvedené výše
  • Dataset (Dataset – Manage permissions) – pokud přidáte práva skupině/uživateli bude mít práva na dataset, v detailu můžete vybrat dvě oprávnění
    • Build content – může nad datasetem vytvářet reporty (pokud toto právo nemá, tak je mu přístup k datasetu na prd)
    • Share dataset – může dataset sdílet jiným uživatelům
  • Report (Report – Manage permissions) – opět to jsou dvě možné oprávnění, bacha pokud dáte uživateli práva na report, ale seberete mu práva na dataset, tak sice uvidí report, ale žádná data v něm + pokud dáte takto práva na report tak uživatel automaticky dostane práva na dataset
    • Build content  – může vytvářet reporty nad datasetem tohoto reportu
    • Share report – může report sdílet s jinými uživateli

• A to je vše. Udělali jsme report a zpřístupnili ho publiku.

A ještě jedna tip/úvaha na závěr.
Pokud chcete, aby si PWBI uživatele dělali reporty sami, ale nechcete je pustit do podkladové reportingové vrstvy, tak je pusťte do datasetu.
Vytvořte dataset s daty a modelem a ten zpřístupněte uživatelům pro tvorbu vlastních reportů. Data mají předpřipravená, žádnou rotiku tam neudělají a mohou si vytvářet vlastní reporty. Vlk se nažere a data zůstanou celá. 🙂

V průběhu psaní mi téma ujelo trochu stranou. Takže pokud nějaká Vaše otázka zůstala nezodpovězená, tak se neváhejte zeptat.