20. prosince 2018

Tabular a Power BI - velikost modelu

Úvod
Power BI uživatelé, vydržte, článek bude relevantní i pro Vás :) Možná :)
Poměrně častou otázkou, kterou dostávám na konferencích a školení týkající se analytických služeb je: Kdy použít Multidimensional, kdy použít Tabular (Power BI běží na Tabularu).
Rychlá odpověď úplně neexistuje (a možná si to zaslouží samostatný blog post). Jedním z faktorů vstupujících do rozhodování je architektura úložiště.
Multidimensional drží data na disku, Tabular v paměti. Sami si odpovězte na otázku, čeho mají vaše servery více :)
Je ale opravdu třeba se obávat nedostatku paměti? Tabular a Power BI do paměti data komprimuje.
O tom, jak komprese ve Vertipaq úložišti funguje jsem mimo jiné povídal na WUG Days a záznam můžete shlédnout zde
Konkrétně popis enginu na přednášce vychází z knihy od Alberta Ferrari a Marca Russa:
Deffinitive Guide To DAX
Bude vycházet druhá edice, chcete-li komplet přehled, počkejte si.

Priority vývojového týmu Analytických služeb jsou zřejmé. V Tabularu je budoucnost, Multidimensional se více nerozvíjí
(průlomových novinek v Multidimenzionalu jsme se nedočkali od verze 2008) a podpora ze strany klientských aplikací, zejména Power BI, pokulhává.
A to je to, co mě v poslední době vadí nejvíce a přehodnocuji, zda držet se multidimenzionalu je dobrý nápad (a to jsem velký fanda).
Multidimenzional byl pro stávající řešení ve firmě vybrán hlavně s ohledem na funkci. Tabular nesplňoval všechny funkční požadavky, po pár letech je ale situace již trochu jiná.
Na co však v Multidimenzionalu marně čekám a začíná se z toho stávat skutečná bolest jsou session level výpočty na úrovni reportu při živém připojení. Bolestí je víc.
Udělám z toho samostatný blog post v angličtině, protože jeden moudrý člověk mi řekl ohledně mých MVP aktivit. “Chceš-li něco změnit, musí se to dostat k produktovému týmu”.
Takže přemýšlím i nad tím, jestli budu psát česky, střídat jazyky, nebo přejít komplet do angličtiny (abych lépe ovlivnil vývoj produktu). To je ale jiný příběh.
Suma sumárům, začínám ve firmě silně uvažovat nad předělání stávajícího multidimenzionálního řešení na Tabular
(pokud nebudou mé prosby vyslyšeny, nic jiného mi asi nezbyde).
Předělat něco, co vznikalo cca 4 roky nebude ale na den. Takže se můžete těšit i na návazné blog posty.

Hlavní část
Mám multidimenzionální kostku cca 11 measure groups, 27 dimenzí. Na disku v MOLAP storage zabírá 86 GB.
První základní otázka zní
Pokud bych stávající řešení chtěl předělat do Tabularu, kolik paměti si vezme model, ve kterém budu mít dostupná stejná data?
Vytvořil jsem model obsahující všechny Measure Groups. A většinu dimenzí.
Některé malé jsem vynechal, protože by cvičení trvalo zbytečně mnoho času a vliv na velikost by byl beztak minimální.
K analýze velikosti jsem použil Vertipaq Analyzer od SQLBI (https://www.sqlbi.com/)
Nástroj je ke stažení zde včetně tutorialu. V podstatě se jedná o Power Pivot model postavený nad metadaty SSAS. Dá se použít jak pro analýzu Tabularu, tak Power BI.
Stačí změnit connection string na vaše SSAS a aktualizovat data.
Výsledky měření bez jakékoliv optimalizace
Celková velikost databáze 65,6GB bez jakékoliv optimalizace. Nejvíce místa si vzaly 2 největší faktové tabulky.
31 GB availability stock (539 milionu záznamů velká tabulka týkající se dostupnosti zboží) a 27,3 GB stock
(1,8 miliardy záznamů velká snapshotová tabulka týkající se skladových zásob).
Fakta jsou za poslední 3 fiskální roky, u nás tedy nyní cca 2,5 roku dat. Delší historii držíme v datovém skladu. Tyhle dvě faktové tabulky si vzaly 88,76% celkové velikosti.
Význam vybraných sloupců ze screenshotu:
Cardinality - u tabulky počet řádků, u sloupce počet unikátních hodnot
Table size - celková velikost tabulky (Columns size+User Hierarchies Size+Relationship Size)
Columns total size - velikost dat ve sloupcích (Data size, Dictionary size, Columns Hierarchies Size)
Data size - velikost detailních dat
Dictionary size - velikost slovníku souvisí s kompresí detaily o kompresi můžete dozvědět v článku od Alberta a Marca zde

Z předchozího screenshotu je tedy zřejmé, že Availability stock zabírá skoro 31GB a z toho 22,5 GB tvoří slovník.
Tabulka je menší do počtu řádků, ale větší do konzumované velikosti v paměti.
Jak jsou na tom asi jednotlivé sloupce?
Všimněte si žlutých buněk. Tabulka 30,9 GB. Sloupec forecasted_sales_units 26,5 GB. Tedy 85,89%. Data ve sloupci 2GB, slovník pro kompresi k datům 21 GB.
To je trochu nepoměr a prostor pro optimalizaci.
Pokud vím, jak v tabularu funguje komprese, vím že velikost slovníku je dána ovlivněna datovým typem. Datový typ totiž ovlivňuje kardinalitu.
Zkontroluji datový typ u sloupce a vidím float. Můžu zachovat funkčnost modelu a při citlivé změně datového typu nepřijít příliš o přesnost?
Decimal (19,4) by mohl stačit. Provedu reload a podívejte na číla.
Změna datového typu srazila velikost tabulky z 30,9 GB na 5,8 GB. Databázi to dostalo z 65,6 GB na 40,5 GB.
Konkrétní sloupec forecasted sales units jsem dostal z 26,5 GB na 1,3 GB. To je slušné změnou datového typu u jednoho sloupce :)
Závěr

Jak bude velký model v Power BI, nebo Tabularu se nedá dopředu odhadnout jen na základě velikosti vstupních dat.
Bude záležet na množství faktorů, zejména schopnosti vertipaq engine data komprimovat. Tento článek by vám měl dát drobný návod jak na analýzu využitého místa.
Co se týká potenciální konverze stávajícího multidimenzionálního řešení do Tabularu.
Odpověď na první otázku, bude místo problém zní. Místo problém nebude. I rychlost výpočtů pro základní metriky nad tabulkou s 1,8 miliardou záznamů byla velmi slušná.
Je to ale běh na dlouhou trať a je třeba zodpovědět další dotazy. Jako například:
Půjde pokrýt celá funkčnost? Nepůjde rychlost do kytek, jak se začnou věci komplikovat složitostí byznys logiky? O tom někdy potom :)

13. prosince 2018

Monitoring BI Solution using Power BI (presented on SQL Saturday Prague)

Intro:
Tento článek píši v angličtině. Téma jsem prezentoval na SQL Saturday Praha též v anglickém jazyce, kde byla značná část publika mluvící jiným jazykem (a nemám na mysli jen bratry a sestry ze Slovenska :) ) Dále již tedy v angličtině.

I will write this article in English and this is because I had a session on this topic on SQL Saturday Prague also covered in English. Significant part of audience was not speaking Czech (and I'm not talking about brothers and sisters from Slovakia only). Therefore rest of blog post in English

Blog post:
When doing anything it is good to have feedback if you are doing right. How to know if you are doing BI right? If your end users are using your outputs they are either happy with them (good for you) or they are using them because they have to (and if not happy with content and/or performance they will usually tell you).
If they have access to report and not using it? There is something wrong about it. Especially if you spent several weeks building output for particular user and now see zero usage. And that is it. Monitoring will tell you if your effort was successful or if you did all for nothing (paycheck will maybe ease your pain, but not completely).
So how do you get feedback about usage of your BI stuff?
By monitoring usage.
If your end user complains about slow SSRS report, what can you do about it? Improve it if you know the reason. How do you get to know reason?
By monitoring report executions. And analyzing performance related data.

In this blog post I will focus just on analyzing SSRS reports usage and OLAP usage (as on SQL Saturday)

SSRS
To analyze performance and usage you will need 3 tables in ReportServer database.
First of all
dbo.ConfigurationInfo - property ExecutionLogDyasKept needs to be changed from default 60 if you want to analyze data over longer period then 60 days
then you will need dbo.Catalog - list of reports, folders
ExecutionLogStorage - main table containing interesting stuff, can be joined to Catalog by connection Catalog.ItemId = ExecutionLogStorage.ReportId
At the end of this blog post will follow link to sample file created during presentation.
Tables described in data model:
Executions = ExecutionLogStorage
Reports = Catalog
OlapQueryLog = OlapQueryLog

DAX generated tables
Date = CALENDARAUTO()
Users = DISTINCT(UNION(DISTINCT('Executions'[UserName]),DISTINCT('OlapQueryLog'[MSOLAP_User])))
Measures of interest including DAX formulas to calculate it in blue
I'm interested in number of executions. Could be calculated in DAX as
Total Executions = COUNTROWS('Executions')
Also interested in Distinct Users of reports
Distinct Users = DISTINCTCOUNT('Executions'[UserName])

For performance troubleshooting we can break execution of SSRS report into
Time to return dataset (ExecutionLogStorage[TimeDataRetrieval])
Intermediate (format independent) report format creation contains data and layout, report level formulas ExecutionLogStorage[TimeProcessing]
Rendering (to specific format) - mhtml, Excel, Pdf, etc. ExecutionLogStorage[TimeRendering]

I would be also interested in BytesCount. If this number is high, execution on report server can be already finished on server, but it will take some time to render it on client (BytesCount then sent over network).

DAX Calculated column
Execution Time = (Executions[TimeRendering]+ 'Executions'[TimeDataRetrieval] + 'Executions'[TimeProcessing])/1000
Measures
Average Execution Time = AVERAGE('Executions'[Execution Time])
Average Data Retrieval = AVERAGE(Executions[TimeDataRetrieval])/1000
Average Data Rendering = AVERAGE(Executions[TimeRendering])/1000
Average Data Processing = AVERAGE(Executions[TimeProcessing])/1000


RequestTypeID 0 is adhoc execution, 1 is subscription.

OLAP usage analysis
For analysing OLAP usage you can enable loging on SSAS instance for both multidimensional and tabular. To avoid too many queries stored there is default sampling 10. Every tenth query will be stored. But to get general idea it is sufficient.
OLAP Executions = COUNTROWS('OlapQueryLog')

Then I can just create 2 common dimensions for calendar and distinct users (see DAX above). Create relationships between tables.


And create a report

Sample report is available here:


It can be downloaded here

Conclusion
This blog post was about providing resources to attendees of my session on SQL Saturday Prague. To other readers it should give idea how to monitor your BI landscape and get some information about usage and performance related metrics. File shared here is far from enterprise ready, but can be used straight ahead. Just change connections from localhost to your servers and remove last steps in Power Query transformations (I have to fake data, so I used first, last 4 for user names and report names).
If you want something finer tuned you can check out tool by my friends from Joyful Craftsmen (who participated heavily on SQL Saturday Prague). You can check out their tool here
Enjoy and if you have any feedback, let me know. 

12. listopadu 2018

SSRS reporty v Power BI službě

Do Vánoc měsíc a půl, ale Power BI tým přišel s nadílkou už nyní. No a udělali mi docela radost. Již nějakou dobu není tajemstvím, že se chystal SSRS typ reportů do Power BI služby. Nyní se očekávané stalo skutečností. Dostupnost zatím jen v Power BI Premium (těžko říct, zda to tak zůstane, ale nedivil bych se).

Pokud byste ale chtěli SSRS reporty v Power BI službě vyzkoušet, můžete požadavek na Premium obejít díky Power BI Embedded v Azure.
Není to dostupné ve všech SKU’s, ale od A4 nahoru, což je docela vysavač na kreditku, nebo MSDN kredit.
Chcete-li zkoušet, tak si to tedy rozmyslete dopředu, co konkrétně. No a hlavně následně nezapomeňte na tlačítko pauza ;-)
Po startu je potřeba v Power BI nastavit capacity settings a povolit typ zátěže “Paginated reports”.
Samotná publikace reportu probíhá přes get data- file- local file. Najdete rdl soubor s SSRS reportem. A vypublikujete.
Budete muset nastavit datový zdroj v Gateway.
Jakmile tohle provedete, vidíte povědomé “loading report”


A jede to i na mobilu :) Export do Excelu fungoval taky pěkně.
Závěr

Funguje to a nejen nad demo soubory od Microsoftu, vyzkoušeno nad vlastním reportem nad SSAS.
Milý Ježíšku, kup mi do firmy Power BI Premium. Prosím prosím.

30. srpna 2018

Záznam přednášky - Reportovací platforma společnosti Microsoft

Střihači videí se do toho pořádně obuli. Dnes s Vámi můžu nasdílet další záznam přednášky, tentokrát z WUG Praha. Téma Reportovací platforma společnosti Microsoft. Co se technologií týká, hlavní zaměření na Power BI a Reporting Services
https://www.wug.cz/zaznamy/495-Reportovaci-platforma-spolecnosti-Microsoft

Díky střihačům za odvedenou práci :)

23. srpna 2018

SQL Server Bootcamp 2017 a 2018 - záznamy přednášek

Díky Davidovi Gešvindrovi, který nejen SQL Bootcamp výraznou měrou umožnil uskutečnit, ale i v velmi rychle po akci sestříhal záznamy vybraných přednášek, se s Vámi mohu podělit o následující videa.

Power BI - Best Practices - https://www.wug.cz/zaznamy/483-SQL-Server-Bootcamp-2018-Power-BI-Best-Practices/
BI řešení pro ne BI lidi - https://www.wug.cz/zaznamy/480-SQL-Server-Bootcamp-2018-BI-reseni-pro-ne-BI-lidi/
Dynamický partitioning OLAP kostek s použitím SSIS - https://wug.cz/zaznamy/492-SQL-Server-Bootcamp-2018-Dynamicky-partitioning-OLAP-kostek-s-pouzitim-SSIS
Power BI Import Dat, Živé připojení a kompozitní modely - https://wug.cz/zaznamy/491-SQL-Server-Bootcamp-2018-Power-BI-Import-dat-zive-pripojeni-a-kompozitni-modely

Materiály k přednáškám jsem přikládal v rámci tohoto článku http://www.neoral.cz/2018/08/sql-server-bootcamp-2018.html


------------------------------------------------------------------------------------------------------
SQL Server 2017 se konal pravda již před rokem a jedno video se zaseklo ve střižně.
Můžete se též podívat na záznam přednášky
Úvod do MDX jazyka - https://www.wug.cz/zaznamy/473-SQL-Server-Bootcamp-2017-Uvod-do-MDX-jazyka/
Pokud byste chtěli i nějaké materiály nad rámec přednášky, můžete si přečíst MDX tutorial, který jsem napsal: http://www.neoral.cz/2016/01/mdx-tutorail-0-rozcestnik.html




17. srpna 2018

SQL Server Bootcamp 2018


15-16.8 v Brně proběhnul SQL Server Bootcamp. Konference pro lidi pracující s SQL Serverem, Power BI a dalšími datovými technologiemi z dílny Microsoftu. Děkuji všem účastníkům, sponzorům a dobrovolníkům z WUGu za skvělou akci. Bylo mi potěšením odpřednášet 4 témata.
Úvod do Business Intelligence světa a žargonu v přednášce BI pro ne BI lidi.
Dále moje posbírané „Best Practices“ pro Power BI v přednášce „Power BI Best Practices“.
Metody připojení použitelné v Power BI jsem rozebral v přednášce „Power BI Import dat, živé připojení a kompozitní modely“ Zde jsem chtěl hlavně představit nové kompozitní modely, o kterých jsem psal článek zde:
Uzavřel jsem technicky lehcé náročnější, ale snad přehlednou formou vysvětlený „Dynamický partitioning OLAP kostek s použitím SSIS“ Zde se jednalo o popis reálného problému z práce, který se ale může určitě hodit více lidem. Principy probrané v přednášce se věřím mohou hodit mnohým.
Slíbil jsem, že se podělím o prezentace a solution z poslední přednášky pro partitioning OLAPů. Slíbené materiály najdete zde
Jakmile budou k dispozici záznamy přednášek, dám vědět v samostatném článku.
Přeji pěkný víkend



30. července 2018

Publikace Power BI reportu do SharePointu Online


Nedávno jsem psal blog post, proč nepoužívat funkci Publish To Web v Power BI (http://www.neoral.cz/2018/07/power-bi-proc-nepouzivat-publish-to-web.html). Důvod byl bezpečnost dat. Zmiňoval jsem, že jako alternativa je použití funkce "Embed To SharePoint". Jak na to a jaká jsou úskalí? O tom bude dnešní článek.
Abyste mohli vkládat Power BI reporty do SharePointu online, potřebujete takzvané "Modern pages". Tyto je potřeba explicitně povolit. Dělá se to v Site settings-Manage Site Features-Site Pages-Activate
Dále vytvoříte novou Site Page


Kliknete na plusko pro přidání obsahu a najdete Power BI


Vyberete add report


Přepnete se do Power BI portálu do reportu, který chcete sdílet a zvolíte v menu file - Embed To SharePoint. Zkopírujete link, nastavíte velikost reportu. Zvolíte, zda chcete zobrazit navigaci mezi stránkami a lištu s filtry po pravé straně. 


Stránku vypublikujete a případně přidáte link na ni na nějaké viditelné místo. 
Na rozdíl od Publish To Web je možno vkládat touto formou vytvořené reporty i takové, které využívají live connection a sice proto, že dochází k ověření uživatele. To má ale také "nepříjemný" dopad. Spíše vlastnost. Pokud chcete, aby uživatel report viděl, musíte s ním report explicitně nasdílet. A abyste s ním mohli report mohli explitně nasdílet, uživatel potřebuje Pro licenci. Nebo musíte mít zakoupené Power BI Premium. Poté můžete sdílet i se všemi Free uživateli

Embedování do SharePointu je bezpečnou variantou, jak se o reporty podělit v rámci stránky SharePointu online. Nevýhodou může být složitější administrace a vyšší finanční náročnost. Bezpečnost citlivých dat v době GDPR ale určitě tyto drobné nevýhody vykoupí :)

24. července 2018

Kompozitní modely

Tento měsíc jsme si na nový Power BI Desktop počkali o něco déle. Určitě to souviselo s probíhajícím Microsoft Business Applications Summitem, kde bylo oznámeno další směřování produktu. K dnešnímu tématu. Co jsou kompozitní modely?
V Power BI Desktopu můžeme tradičně volit mezi 2mi typy připojení. Data Importem a živým připojením. O metodách připojení jsem mimo jiné psal v tomto článku anglicky zde http://www.neoral.cz/2016/10/power-bi-live-connection-vs-import.html a také přednášel zde https://www.youtube.com/watch?time_continue=2&v=NtQqTaI4w7E
Import může kombinovat libovolný počet zdrojů. Živé připojení bylo ale odsouzeno k tomu, že jste byli uvězněni do jednoho jediného zdroje.
To se nyní mění právě díky kompozitním modelům.
Kompozitní model umožňuje kombinovat více zdrojů s živým připojením (zatím jen tabulární typ, ne multidimenzionální kostky atd.). A také umožňuje kombinovat metodu import s živým připojením.
Tato preview funkce se povoluje v menu File-Options-Preview Features-Composite Models



V pravém dolním rohu obrázku vidíte, že jsem v režimu Storage Mode: Direct Query. Přesto však nemám zašedlý Get Data Dialog.
První zdroj jsem pro účel screenshotu zvolil ContosoRetailDW
Jako druhý si vezmu AdventureWorksDW z jiného serveru. Tam si vezmu tabulku FactInternetSales
Vyskočí potential security risk



V relationship window můžu udělat logickou vazbu (i když mezi těmito databázemi opravdu není) mezi tabulkou DimDate Na jedné straně ai FactInternetSales na druhé přes OrderDate. Vyskočí mi, že typ vazby bude Many to Many (další novinka, které se nejspíš v detailu pověnuji samostatně). Je to totiž trošičku jiné Many to Many, než znáte z databází. Kdo by si chtěl přečíst v originále, můžete zde: https://docs.microsoft.com/en-us/power-bi/desktop-many-to-many-relationships



Na úrovni jednotlivých objektů potom můžete v table properties definovat, jestli chcete, aby daná tabulka byla braná jako import, živé připojení, nebo dual.



Výhodou by mělo být omezení bombardování backendového zdroje opakovanými dotazy například pro hodnoty slicerů. Abyste ten zdroj netrápili více, než je nezbytně nutné.

Pokud byste se chtěli podívat na kompozitní modely na živo, v Brně proběhne konference SQL Server Bootcamp (3.ročník s bezplatnou registrací zde: https://wug.cz/brno/akce/1080-SQL-Server-Bootcamp-2018 )

Navrhnul jsem téma "Power BI – Import dat vs. živé připojení a dál" kde jsem chtěl o tomto tématu mluvit. Když se o kompozitních modelech ví už veřejně, můžu přednášku přejmenovat na "Power BI – Import dat, živé připojení a kompozitní modely"

Moje další témata na Bootcampu jsou:
BI řešení pro ne BI lidi
Dynamický partitioning OLAP kostek s použitím SSIS
Master Data Services a jejich využití pro BI vývojáře
Power BI – Best practices
Power BI – Co nového a dobrého přinesly poslední měsíce

Témat jsem nasázel tradičně hodně a věřím, že se všechny do programu nevlezou :) Ale na Bootcampu Vás rád uvidím.

Po krátké reklamní vložce zpátky ke kompozitním modelům. VELKÝ POZOR. Modely s touto funkcí zatím nejdou publikovat do Power BI Service. Tož si ty vaše produkční reporty prvně někam odzálohujte, než si s tím začnete hrát :)

Těším se, až bude možno dělat live connection i nad multidimenzionálními zdroji, což je určitě logický krok, kam by se mohla technologie vyvíjet dál. Přeji příjemnou zábavu s kompozitními modely.

9. července 2018

Power BI - Proč nepoužívat Publish to web

Na začátek lehce provokativní název. Blog by se mohl jmenovat spíš "Kdy nepoužívat Publish to web a jak se bránit" To by měl ale potom možná méně kliků :)
Proč bych Vás nyní zrazoval od sdílení na web v Power BI, když jsem sám v minulosti lákal článkem "Veřejné sdílení reportů". http://www.neoral.cz/2016/02/power-bi-verejne-sdileni-reportu.html
Ono veřejné sdílení reportů může být vhodné za určitých situací. S mnou sdíleným kurzovním lístkem ČNB by asi problém nebyl.
Problém nastává v situaci, kdy se firmy a jednotlivci snaží používat Power BI zadarmo a za účelem obcházení licenčního modelu. Nebo si jen nejsou vědomí dopadu svých akcí.
Neboť jak praví svaté písmo (dokumentace) https://docs.microsoft.com/en-us/power-bi/service-publish-to-web

Když chcete použít Publish to web, vězte, že vypínáte zabezpečení. Je to vhodné použít pouze pro obsah, kde nevadí, že REPORT I DATA jsou veřejně dostupná komukoliv z internetu. 
Člověk si může myslet, že kód pro sdílení je natolik strašidelný a neodhadnutelný, že se k tomu přece nikdo nedostane. Člověk si ten kód sice nevycucá, ale co stroje? Obsah reportů včetně detailních dat může být nelezen roboty a je indexován vyhledávači (Bingem počínaje, ale těžko říct, kde konče).
Takže je potřeba si položit otázku: 
Opravdu nasdílím v době GDPR data zákazníka touto formou? Vystavím takto data zaměstnanců? Vystavím takhle do internetu finanční data firmy?
Každý si odpovězte sám, já si za sebe řekl, že ne :)
Pokud chcete nasdílet na SharePointu něco ze zmiňovaných typů reportů, existuje zde bezpečná alternativa "Embed in SharePoint Online".
Více informací o této funkci v originále https://docs.microsoft.com/en-us/power-bi/service-embed-report-spo

Jak se tedy bránit z pohledu Admina?
V Admin portále můžete jednak zkontrolovat kdo co vypublikoval touhle formou, včetně možnosti embed kód smazat
Nebo můžete rovnou přistoupit k drastické metodě a zakázat tuhle funkci pro celou organizaci

Admin Portal - Tenant Settings
Závěr
Přeji příjemnou zábavu při prohlížení toho, co kolegové z organizace nasdíleli. Stejně tak pevné nervy při mazání obsahu a zakazování :)

20. června 2018

WUG Days 2018 - záznamy

Na začátku dubna proběhla v Brně konference WUG Days, na které jsem měl 3 přednášky na téma Power BI. Díky Davidovi Gešvindrovi jsou dostupné sestříhané záznamy na stránkách WUG
První byla o přípravě dat u importu do Power BI, záznam naleznete zde:
https://www.wug.cz/zaznamy/465-WUG-Days-2018-Power-BI-Priprava-dat
Druhá o tvorbě datového modelu, a jeho optimalizaci, záznam zde:
https://www.wug.cz/zaznamy/466-WUG-Days-2018-Power-BI-Datove-modelovani-a-optimalizace
Třetí o tvorbě reportů v Power BI, ke shlédnutí zde:¨
https://www.wug.cz/zaznamy/467-WUG-Days-2018-Power-BI-Tvorba-reportu

Přeji příjemnou zábavu na dlouhé večery doma, nebo dlouhá odpoledne v prázdné kanceláři o nadcházejících prázdninách :)

18. května 2018

Power BI – Inkrementální plnění

Po konferenčním maratonu další článek o Power BI. Rozcestník se seznamem najdete zde http://www.neoral.cz/2016/10/power-bi-rozcestnik.html
V poslední aktualizaci Power BI Desktopu přibyla možnost nastavit inkrementální plnění u importu dat. Kdo aktualizujete větší objemy dat, jistě byste tuhle možnost ocenili.
Místo pěti let aktualizovat jen poslední den/týden.
Jak to funguje? Konfigurace probíhá v Power BI Desktopu. Ten ale naplnit jen přírůstek neumí. Počítá se totiž s automatizací v Power BI Service (powerbi.com)
Má to jednu vadu na kráse a sice funguje to jen v Power BI Premium (nabídka pro Enterprise zákazníky, psal jsem zde http://www.neoral.cz/2017/05/power-bi-premium-zmeny-v-power-bi-free.html).
Power BI Premium je cenově hůře dostupné, než licence Pro (fungující ve sdílené infrastruktuře, které by zrovna inkrementální plnění pomohlo).
K demonstraci použiji své oblíbené demo s kurzovním lístkem ČNB http://www.cnb.cz/cs/financni_trhy/devizovy_trh/kurzy_devizoveho_trhu/rok.txt?rok=2018
V prvé řadě si nachystám dataset bez inkrementu
Důležité je, aby sloupec datum měl datový typ Date/Time pro jiné datové typy zatím nefungují a to ani pro Date.
Kód v „M“
let
   Source = Csv.Document(Web.Contents("http://www.cnb.cz/cs/financni_trhy/devizovy_trh/kurzy_devizoveho_trhu/rok.txt?rok=2018"),[Delimiter="|", Columns=34, Encoding=65001, QuoteStyle=QuoteStyle.None]),
   #"Promoted Headers" = Table.PromoteHeaders(Source, [PromoteAllScalars=true]),
   #"Unpivoted Other Columns" = Table.UnpivotOtherColumns(#"Promoted Headers", {"Datum"}, "Attribute", "Value"),
   #"Changed Type with Locale" = Table.TransformColumnTypes(#"Unpivoted Other Columns", {{"Datum", type datetime}}, "cs-CZ"),
   #"Changed Type with Locale1" = Table.TransformColumnTypes(#"Changed Type with Locale", {{"Value", type number}}, "cs-CZ"),
   #"Split Column by Delimiter" = Table.SplitColumn(#"Changed Type with Locale1", "Attribute", Splitter.SplitTextByEachDelimiter({" "}, QuoteStyle.Csv, false), {"Attribute.1", "Attribute.2"}),
   #"Changed Type" = Table.TransformColumnTypes(#"Split Column by Delimiter",{{"Attribute.1", Int64.Type}, {"Attribute.2", type text}}),
   #"Renamed Columns" = Table.RenameColumns(#"Changed Type",{{"Attribute.1", "Pocet"}, {"Attribute.2", "Mena"}, {"Value", "Kurz"}})
in
   #"Renamed Columns"
Dále je potřeba v Desktopu povolit inkrementy v Preview Features
Dále nad DateTime sloupcem vytvoříme between filtr a vybereme odkaz na parametr
Parametry nachystáme 2. Mají pevně předepsaná jména kvůli rozpoznání ze strany Power BI service a musí se jmenovat RangeStart a RangeEnd.
Datový typ opět Date/Time. Current value je hodnota pro iniciální load
Filter vypadá potom následovně
Následuje pravé tlačítko na dotaz a výběr Incremental Refresh
Vyplníme dialog pro inkrementální politiku. Kolik dat načítat celkem a jaký časový údaj se má brát jako přírůstek
Zbývá nasadit do Power BI Premium tenantu. Standartní workspace bez dedikované kapacity nejde vybrat.
Refresh na straně service se nastavuje standartně. Jen data source credentials (uživatelské jméno, heslo, nebo anonymní přístup jako v případě webu).
A čas, kdy to má běhat.
Závěr

Inkrementální refresh pomůže hlavně aktualizacím větších datových modelů, pokud historie je již neměnná. Jen škoda toho licencování.
Ale třeba se časem dočkáme i u Pro licencí.

26. března 2018

Power BI Roadmap – jaro 2018

Být na MVP summitu, slyšet všechny úžasné věci, které se chystají a nemoci o tom mluvit... Bylo těžké, ale zvládnul jsem to.
Nyní ale díky Dynamics 365 Release Notes, které vyšly veřejně se s vámi můžu podělit o část toho, co se ví že přijde do Power BI v horizontu cca 6 měsíců.
Na dokument o Dynamics 365 Release Notes mě upozornil článek, který napsal Chris Webb zde https://blog.crossjoin.co.uk/2018/03/21/power-bi-roadmap-announcements-in-the-dynamics-365-spring-18-release-notes/
Nejsem translátor, tak Vám napíšu své vlastní shrnutí a své pohledy na věc. Celý dokument v angličtině najdete zde: https://aka.ms/businessappsreleasenotes
Inkrementální aktualizace dat
V Power BI desktopu půjde definovat politiky pro inkrementální loady. Nebude nutno opakovaně tahat celou historii, půjde aktualizovat pouze přírůstek dat.
Přírůstek se bude definovat v Desktopu, ale pro samotnou aktualizaci na straně služby budete potřebovat Power BI Premium
(na pozadí partitioning a tento byl po většinu času Enterprise feature).
Uchovatelné filtry
Minulá aktualizace desktopu přinesla možnost v preview módu zakázat ukládání konfigurace slicerů do příští session.
Čekalo se na to, až to bude podporovat služba. Ta už to umí a umí to automaticky. Když opustíte report, ten si u vestavěných slicerů (ne custom visuals) pamatuje nastavení.
Pokud se chcete vrátit do původního nastavení, je k tomu použitelné následující tlačítko
Zrychlení výpočtů nad Direct Query připojením díky in-memory agregacím
Tohle bylo demonstrováno na PASS Summit key note.
Data půjdou předpočítat na určité úrovni, do této úrovně se bude sahat do in-memory úložiště, větší detail potrápí direct query. Premium feature.
Slideshow režim
Chcete dát Power BI report na obrazovku třeba na recepci, aby se automaticky přepínaly stránky?
Z vlastní zkušnosti mohu říct, že zatím to šlo dělat jen díky vlastní aplikaci, nebo pluginům v prohlížeči.
Ani tak ani tak, to nebylo ideální. Půjde to tedy jinak
SSRS reporty v Power BI Service
Jakože .rdl report. A opět Premium Power BI workspace. Bez SSRS serveru.
Tak tohle je mazec, na který se velmi těším. Než to vyleze, musíme dořešit licence.
Power BI premium workspace integrace s SSAS
V podstatě se bude Workspace chovat jako SSAS server. Z Power BI Premium workspace se stane nadmnožina SSAS.
Některé vlastnosti prvně přibydou do Power BI Premium, pak do SSAS Tabular v cloudu, pak do on premises prostředí.
Některé věci budou dostupné ale jen v Power BI Premium.
Závěr

Nových funkcí ve výhledu je více a já nechci psát telefonní seznam. Shrnul jsem ty nejpřínosnější funkce z odtajněné roadmap, které vidím jako přínosné ze svého pohledu. Trend je jasný.
Udělat Premiovou nabídku lákavější. Momentálně si Premium pořídí firma pouze, pokud ji to vyjde levněji, než Pro licence na všechny uživatele (láme se to někde u 500 uživatelů).
Nebo pokud chtějí zoufale on-premises Power BI report server a nemají SQL Server Enterprise se Software Assurance. Případně je limitují nějaké kapacitní limity (počet aktualizací).
To co se ale chystá do budoucna přinese nové argumenty do diskuze, zda je Premium potřeba.