18. října 2015

MDX tutorial 8 – Navigace v hierarchii 1. část

V minulém dílu tutorialu jsme probarali agregační funkce (http://www.neoral.cz/2015/10/mdx-tutorial-7-agregacni-funkce.html) jako nezbytnou prerekvizitu k tomu, co přichází dnes. Postupem času jsme se prokousali k akčnímu tématu a tím je navigace v hierarchii. Jedná se o skupinu funkcí, která bych řekl má v OLAP kostkách snad nejšiřší použití.
Všechno začíná currentmemberem. Ten je naším středem vesmíru od kterého navigace bude začínat, okolo currentmembera jsou další členové hierarchie v různých příbuzenských vazbách. Většina funkcí dává smysl hlavně ve víceúrovňových hierarchiích.
Nad currentmemberem je jeho parent. Currentmember má pouze jednoho parenta. Potomci currentmembera jsou children. Sourozenci siblings.
Navigační funkce se dají obecně rozdělit na dva typy, funkce vracející member (používají se jako souřadnice v tuplu, nebo funkce vracející množinu prvků. Množinové navigační funkce zpravidla kombinujeme s funkcemi agregačními probranými v dílu číslo 7.
Seznam funkcí pro přístup k nejbližším příbuzným. V kulatých závorkách je napsáno, zda funkce vrací member, nebo set.
Funkce
Popis
member.parent
nadřízený člen (member)
member.children
veškeré potomstvo o úroveň níž (set)
member.firstChild
první potomek (member)
member.lastchild
poslední potomek (member)
Siblings
všichni sourozenci pod stejným parentem (set)
member.firstsibling
první sourozenec (member)
member.lastsibling
poslední sourozenec (member)
Parent
Funkce parent nás odkáže v hierarchii na nadřízený prvek. Použítím by mohlo být například procenta v rámci nadřízené skupiny. Na začátek dotaz, ze kterého budu vycházet.
WITH MEMBER x AS
       [Dim Product].[Category-Subcategory-Model-Product].currentmember
       .name
SELECT
       {[Measures].[Reseller Sales]
       ,x}
ON COLUMNS,
nonempty(
       {[Dim Product].[Category-Subcategory-Model-Product].members}
       ,[Measures].[Reseller Sales]
       )
ON ROWS
FROM [MDX Tutorial]
Dotaz vrací prvek z hierarchie category-subcategory-model-product, jeho prodeje a ve sloupci x odkaz na něj
Odkaz na nadřízený prvek v hierarchii
WITH MEMBER x AS
       [Dim Product].[Category-Subcategory-Model-Product].currentmember.parent
       .name
SELECT
       {[Measures].[Reseller Sales]
       ,x}
ON COLUMNS,
nonempty(
       {[Dim Product].[Category-Subcategory-Model-Product].members}
       ,[Measures].[Reseller Sales]
       )
ON ROWS
FROM [MDX Tutorial]

Prodeje nadřízeného prvku
WITH MEMBER x AS
       (
       [Dim Product].[Category-Subcategory-Model-Product].currentmember.parent
       ,[Measures].[Reseller Sales])
SELECT
       {[Measures].[Reseller Sales]
       ,x}
ON COLUMNS,
nonempty(
       {[Dim Product].[Category-Subcategory-Model-Product].members}
       ,[Measures].[Reseller Sales]
       )
ON ROWS
FROM [MDX Tutorial]
Procenta nadřízeného prvku
WITH MEMBER x AS
DIVIDE(
       [Measures].[Reseller Sales],
       (
       [Dim Product].[Category-Subcategory-Model-Product].currentmember.parent
       ,[Measures].[Reseller Sales])
       )
,format_string="percent"
SELECT
       {[Measures].[Reseller Sales]
       ,x}
ON COLUMNS,
nonempty(
       {[Dim Product].[Category-Subcategory-Model-Product].members}
       ,[Measures].[Reseller Sales]
       )
ON ROWS
FROM [MDX Tutorial]

Children
Setová funkce children vrátí veškeřé podřízené prvky z hierarchie a je použitelná například v kombinaci s funkcí avg pro výpočet “průměru v dané skupině” Pokud bychom chtěli porovnávat akutální prvek s průměrem prvků na stejné úrovní, použili bychom spíš funkci “siblings”, což je to stejné jako “parent.children”, případně funkcí “siblings”. Obecně pro práci s navigačními funkcemi pro ladící účely doporučuji funkci settostr, která převede množinu na řetězec.
WITH MEMBER x AS
       settostr(
       [Dim Product].[Category-Subcategory-Model-Product].currentmember.children
       )
SELECT
       {[Measures].[Reseller Sales]
       ,x}
ON COLUMNS,
nonempty(
       {[Dim Product].[Category-Subcategory-Model-Product].members}
       ,[Measures].[Reseller Sales]
       )
ON ROWS
FROM [MDX Tutorial]

Po odladění můžeme spočítat průměr v dané skupině
WITH MEMBER x AS
       avg([Dim Product].[Category-Subcategory-Model-Product].currentmember.children
       ,[Measures].[Reseller Sales]
       )
SELECT
       {[Measures].[Reseller Sales]
       ,x}
ON COLUMNS,
nonempty(
       {[Dim Product].[Category-Subcategory-Model-Product].members}
       ,[Measures].[Reseller Sales]
       )
ON ROWS
FROM [MDX Tutorial]
Ostatní funkce by byly použitelné hlavně, ale nejen v časových souvislostech. Dotaz, ze kterého budu vycházet je následující
WITH MEMBER x AS
       "sem napište výraz"
SELECT
       {x}
ON COLUMNS,
       [Dim Date].[YQMD].[Date].&[2007-10-16T00:00:00]
ON ROWS
FROM [MDX Tutorial]
Začátek a konec měsíce
WITH MEMBER zacatek AS
       [Dim Date].[YQMD].currentmember.firstsibling.name
MEMBER konec AS
       [Dim Date].[YQMD].currentmember.lastsibling.name
SELECT
       { zacatek,
konec }
ON COLUMNS,
       [Dim Date].[YQMD].[Date].&[2007-10-16T00:00:00]
ON ROWS
FROM [MDX Tutorial]
Začátek roku a kumulovaná suma prodejů od začátku roku
WITH MEMBER zacatek AS
       [Dim Date].[YQMD].currentmember.parent.parent.parent.firstchild.firstchild.firstchild.name
MEMBER sumaodzacatku AS
       SUM
       (
       [Dim Date].[YQMD].currentmember.parent.parent.parent.firstchild.firstchild.firstchild:
       [Dim Date].[YQMD].currentmember
       ,[Measures].[Reseller Sales]
       )
SELECT
       { [Measures].[Reseller Sales]
       ,zacatek
       ,sumaodzacatku }
ON COLUMNS,
       [Dim Date].[YQMD].[Date].&[2007-10-16T00:00:00]
ON ROWS
FROM [MDX Tutorial]

Začátek roku i kumulovaná suma by se daly získat i jednoduššeji, ale o tom opět někdy potom :)
Závěr

Navigace v hierarchiích multidimenzionálních OLAP kostek je jedním z nejdůležitějších principů MDX jazyka. Syntaxe není složitá, vše je jen o tom, uvědomit si, kde se v hierarchii nacházíte, kam se chcete dostat a jestli funkce vrací member/set. I většina časových výpočtů se dá realizovat právě přes navigační funkce. Navigačních funkcí je hodně a proto s nimi budeme pokračovat i v dalším díle tutorialu.

12. října 2015

MS Fest 2015

Chtěl bych poděkovat všem, kdo přišli na moji včerejší přednášku na MS Festu 2015. Nevím jak ostatní, ale já jsem si přednášu užil :) Přikládám link na prezentaci, kterou jsem včera promítal se zdroji. Budu se těšit na další ročník a na další konference :)
Link s prezentací
https://drive.google.com/file/d/0B9ZohZ1CALKZVHQ1UU5rdWtwcmM/view?usp=sharing
Až bude dostupné video se záznamem přednášky, přidám také sem

Power BI konektory na „On Premise“ zdroje a zabezpečení dat

PowerBI jako nástroj na hraní je super, to už jsem vás snad přesvědčil v předchozích článcích. Je PowerBI dobré i na práci? To chce sadu otázek a odpovědí, abychom to byli schopni vyhodnotit
Časté otázky zní:
Otázka: Kam můžu reporty nasadit?
Odpověď: Aktuálně PowerBI cloudová služba, případně Pyramid server. Pyramid server asi většina z nás nemá (zatím nemám ani osobní zkušenost, třeba výhledově). Možná tedy většina z nás v prvé fázi sáhne po cloudové službě. S tím ale souvisí
Otázka: Jak zabezpečím data? Co uvidí různí uživatelé ve stejném reportu?
Otázka: Jak udržím data aktuální? Budu muset data aktualizovat, abych viděl aktuální stav dat tak, jak jsou v databázi?
Na tyto otázky by měl odpovědět právě tento článek.
Propojení světů
Pokud máme data „u nás“ (on premise) a reporty „u nich“ (v cloudu), musíme tyto dva světy nějak propojit. K tomuto v současné době Microsoft nabízí dva typy konektorů, které souvisí jak s modelem zabezpečení, tak s aktualizacemi dat.
Analysis services konektor
Jak název napovídá, jedná se o konektor na Analytické služby SQL Serveru. Je potřeba jej nainstalovat na serveru, kde běží Tabulární instance Analysis Services. Konektor v současné době funguje právě POUZE proti Tabulární instanci SSAS. Jeho základní výhodou je, že umožňuje živé připojení do dat. Konektor je schopen rozpoznat, kdo sedí na druhé straně a kouká na data přes PowerBI portál. Tedy dá se řídit práva k datům na straně databáze rolemi. Tento způsob zabezpečení funguje pouze v tomto režimu s SSAS konektorem. Pokud váš Tabular běží v režimu DirectQuery nemusíte ani data aktualizovat. Jakmile se změní v databázi, když kliknete na refresh u reportu, report odráží aktuální stav dat. Dashboard ne, dashboardy využívají 15 minutovou cache. Pokud byste využívali tabular s InMemory úložištěm, stačí aktualizovat data v tomto tabularu na straně databáze, aby se to promítalo do reportu. Server na kterém je konektor nainstalovaný musí být ve stejné doméně, jako váš účet přes který se přihlašujete do PowerBI.com portálu. Konektor nefunguje s loginy „onmicrosoft.com“.
Konektoru se dopodrobna věnuje článek v angličtině
Pokud vás zachvátila panika, protože tabular nemáte. Máte jako většina firem nejen v České republice multidimenzionální modely SSAS. Znamená to, že nemůžete dělat reporty přes PowerBI proti vašim multidimenzionálním modelům?
Ne, znamená to pouze, že nemůžete použít „živé připojení“ s aktuálními daty. Pořád můžete používat
Power BI Personal Gateway
Tento konektor je použitelný pro většinu on premise zdrojů včetně SQL Serveru a Analysis services. Jen funguje v jiném režimu. Nainstalujete jej na server, kde máte zdrojová data. Nastavíte účet pod kterým se budou data aktualizovat ze strany PowerBI.com portálu v pravidelných intervalech. S ohledem na zabezpečení tedy uživatelé kterým nasdílím report vidí všichni stejná data v reportu, protože se report plní pod servisním účtem. Nedá se tedy využívat rolí na databázové straně. Power BI Personal Gateway nemůže být nainstalována na stejném serveru jako Analysis Services konektor. Funguje pouze na 64bitovém operačním systému a je potřeba vytvořit pravidla ve Firewallu. Způsob nastavení a různá omezení najdete v angličtině zde
Kompletní seznam zdrojů, pro které Gateway můžete použít najdete zde
Některé datové zdroje jdou aktualizovat dokonce bez Gateway, například Google Analytics
Dynamické, živé dashboardy
Výše popsané techniky umožňují pouze data aktualizovat, nezaktualizují však data v reportu. Pokud byste chtěli, aby se report dynamicky měnil jak se budou měnit data, máte v současné době dvě možnosti, Azure Stream analytics umí výstup vykreslovat v PowerBI, případně se dá PowerBI donutit aplikačně přes Rest API. O tom možná někdy potom.
Závěr

Propojit cloudovou službu s onpremise světem není zase tak těžké, ja by se na první pohled mohlo zdát. Narozdíl od pekla, které jsem zažil s Data management gateway pro PowerBI v O365, byla práce s oběmi konektory výrazně jednodušší a až na drobné problémy hladká. U SSAS konektoru jsem narazil pouze na problém s onmicrosoft doménou. U Personal PowerBI Gateway jsem dokonce na problém nenarazil. Proto se zde v článku také vůbec nezabývám nějakou konfigurací s obrázky krok za krokem. Kdybyste však s konfigurací měli problém, napište komentář pod článek. Nebo mi napište mail.

5. října 2015

MDX tutorial 7 – Agregační funkce

V dnešním díle MDX tutorialu se zaměřím na agregační funkce. Tohle téma je samo o sobě možná méně záživné, ale nezbytnou prerekvizitou pro funkce navigační a časové. A ty záživné rozhodně jsou :) K těm se blížíme a čeká nás velmi brzy aplikované MDX.
Agregační funkce nám nad množinou prvků a volitelně číselným údajem vrátí skalární hodnotu (jedno číslo).
Většina agragačních funkcí má stejnou syntaxi
Funkce(Set, Výraz)
Na začátek dotaz, ze kterého budu ve výkladu vycházet. Nejprve na řádky vypíšu posledních 14 dní, které mají prodeje.
SELECT
       {[Measures].[Internet Sales]}
ON COLUMNS,
tail(/*poslednich 14 dni*/
nonempty(/*množina datumů, která má nějaké prodeje přes internet*/
       {[Dim Date].[Date].[Date]}
       ,[Measures].[Internet Sales]
       )
       ,14
       )
ON ROWS
FROM [MDX Tutorial]
Z řádkové množiny si vytvořím pojmenovaný set „Posledních 14“ a počítaný člen „x“, jehož význam se bude měnit dle použité agregační funkce. Zatím zadávám natvrdo konstantu 1.
WITH SET [Poslednich 14] AS
       tail(/*poslednich 14 dni*/
       nonempty(/*množina datumů, která má nějaké prodeje přes internet*/
       {[Dim Date].[Date].[Date]}
       ,[Measures].[Internet Sales]
       )
       ,14
       )
MEMBER x AS
       1
SELECT
       {x}
ON COLUMNS
FROM [MDX Tutorial]
Nejdřív spočítáme celkovou sumu, abych zde stále neopakoval stejný select, který si můžete přečíst nahoře, budu měnit jen definici počítaného členu.
SUM( «Set»[       , «Numeric Expression»] )
Spočítá sumu číselného výrazu nad množinou
MEMBER x AS
       SUM( [Poslednich 14]
             , [Measures].[Internet Sales]
       )
AVG( «Set»[, «Numeric Expression»] )
Průměr v dané množině (null hodnoty jsou z průměru ignorovány).
MEMBER x AS
       AVG( [Poslednich 14]
             , [Measures].[Internet Sales]
       )
Další funkce, které mají stejnou syntaxi, jen jiný význam jsou
·        MAX – spočítá maximum
·        MIN – spočítá minimum
·        MEDIAN – spočítá hodnotu uprostřed statistického výběru
·        STDEV – směrodatná odchylka
·        VARIANC – rozptyl
Funkce která sice má stejnou syntaxi, ale trošku vybočuje z řady významem je funkce
AGGREGATE( «Set»[, «Numeric Expression»] )
Aggregate je „chameleon“ Počítá nad množinou prvků agragaci, dle nastavení zdrojového měřítka. Pokud má zdrojové měřítko nastavenou sum, počítá sumu, má-li LastNonEmpty, počítá LastNonEmpty, počet pro count atd. Hodí se speciálně u časových kalkulací uložených v dimenzi.
Další kdo vybočuje z řady je funkce Počet
COUNT( «Set»[, EXCLUDEEMPTY | INCLUDEEMPTY] )
Zde není aplikovatelný argument číselný výraz, zato přibyly dva příznaky, zda do počtu chceme zahrnout prázdné, či ne.
A pro přehled poslední Počet unikátních
DISTINCTCOUNT( «Set» )
Závěr:

Agregační funkce jsou nezbytné pro další fungování v rámci funkcí setových, či časových. V dnešním blogu není mnoho příkladů, ale těchto se dočkáte právě v nasledujících dílech o navigaci, případně práci s časem.

29. září 2015

Analysis services – výběr vhodného typu modelu

Do SQL Serveru 2008 byla volba jednoduchá, Analysis services podporovaly pouze model multidimenzionální a nebylo moc z čeho vybírat. Časem se to ale začalo komplikovat, prvně přišel PowerPivot poté Tabular a jak to tak bývá, čím víc možností, tím těžší výběr. Klienti a účastníci kurzů se mě často ptají, potažmo i historicky ptali v dobách začátků PowerPivot. Je PowerPivot lepší než SSAS? To teď máme zrušit staré multidimenzionální modely a přebouchat veškerou logiku do PowerPivotu? A obdobné dotazy dostávám s tabularem. Má cenu předělávat stávající multidimenzionální řešení do tabularu? Nejen na tyto dotazy by měl odpovědět tento článek.
Průřez typy
Multidimenzionální model
Dostupnost – dostupný od verze SQL Serveru 2005 v té podobě v jaké jej vidíme dnes v edici standard a vyšších
Historicky vzniknul v době, kdy ještě nebyla tak dostupná operační paměť, tudíž se hledaly způsoby jak efektivněji uložit data na disku. Pro dosažení vysokého výkonu se přišlo s úložištěm MOLAP, do „živých“ dat se dá koukat díky úložišti ROLAP. Coby nejstarší model je nejlépe zdokumentovaný, nejrozšířenější, umí řekl bych 100% funkcí a je to ten ke kterému se srovnává.
Jedinou nevýhodou multidimenzionálního modelu je jeho relativní složitost. Při tvorbě je potřeba nastavit docela dost věcí, aby byl model nastaven „optimálně“. Pro výpočty, dotazování, zabezpečení se používá jazyk MDX. Naučit se MDX si žádá nějaký čas a přece jen pro vývojáře zvyklé pracovat s placatými tabulkami a teorií množin, jedná se o přechod bolestný :) I proto jsem začal psát na blogu MDX tutorial, jehož první díl najdete zde http://www.neoral.cz/2015/05/mdx-tutorial-1-uvod.html
Tudíž jedinou nevýhodou multidimenzionálního modelu je jeho relativní složitost a z toho plynoucí vysoké nároky na vývojáře, aby to bylo udělané dobře, v případě některých kalkulací aby to vůbec bylo udělané :) I když i to se dá vyřešit stylem. Pokud to nevím, tak jim řeknu, že to nejde :)
PowerPivot
PowerPivot poprvé spatřil světlo světa někdy kolem roku 2010 v dobách Excelu 2010 a SQL Server 2008 R2. Jendá se o zjednodušené Analysis services v Excelu, která se dá provozovat i serverově. Jedná se na pozadí také o tabulární model. Funguje to tak, že v Excelu vytvoříte model a o tento se můžete podělit tím, že hotový dokument včetně vizualizací vypublikujete do dokumentové knihovny SharePointu. Licenční nároky na serverové řešení jsou z těch vyšších. Budete potřebovat minimálně BI edici SQL Serveru a Sharepoint Enterprise (o zobrazení se starají Excel Services). Alternativou může PowerBI v Office 365
Při tvorbě modelu se data načtou do paměti, kde se nad nimi provádí operace. Pro tvorbu výpočtů se používá jazyk DAX, který je pro tvorbu výpočtů výrazně jednodušší než MDX (zápis vypadá jako Excelový vzorec). Klíčová omezení jsou maximální velikost souboru, který se dá otevřít v prohlížeči tedy 2GB. Tedy Modelem je vlastně Excelový soubor a tento je také jednotkou zabezpečení. Nedají se zde tvořit role kde v rámci jednoho modelu uvidí různí uživatelé různá data jako v případě serverových modelů. Dále je zde problém s kompatibilitou verzí. Model, který vytvoříte v Excelu 2010 vás po otevření v Excelu 2013 vyzve k upgradu. A zpětně ve 2010 již model nemůžete editovat. Stejně tak člověk bez nainstalovaného doplňku nemůže data z modelu číst. PowerPivot se dá načíst do Visual studia jako tabulární projekt a tímto závislost na nutnosti mít nainstalovaný doplněk odpadá, dají se řešit role, partitioning... Funkční omezení jsou shodná s Tabularem
Tabulární model
SQL Server 2012 přišel s možností nainstalovat tabulární instanci analysis services. Je postaven na stejných principech, jako PowerPivot, ale nepotřebujete k němu SharePoint a jedná se o serverové řešení bližší multidimenzionálnímu modelu. Ve zkratce Tabular kombinuje jednoduchost PowerPivotu a výhody serverového modelu. Pro rychlost dat načítá data do paměti (v surové podobě jak jsou ve zdroji, neaplikují se zde žádné agregace). Typ úložiště může být buď in memory, nebo direct query,případně kombinace obojího. Tabular umí cca 80% funkcí, kde funkční omezení jsou následující.
·        podpora pouze vazby 1:N, dá se ohnout aby dělal vazbu 1:1 pouze s jednosměrnou filtrací.
·        parent child hierarchie sice jsou k dispozici, ale pouze přes DAX funkce. Kde musíte pro kažodu úroveň zvlášť napsat vzorec. Tedy pro 50 úrovní by se jednalo o 50 vzorců, které byste museli napsat. Oproti tomu Multidimenzionální model si je schopen rekurzivně načíst všechny úrovně sám
·        hůře se zde pracuje s týdenní časovou logikou, což je dáno způsobem, jakým se definuje kalendář (americký vs evropský týden)
·        nedají se vytvářet počítané členy v dimenzích (chybí mi časové kalkulace v dimenzi, které fungují na všechny měřítka)
·        nedají se zde nastavovat defaultní membery, uživatel by mohl omylem zagregovat i to, co nemá
·        nejde provádět Writeback
·        překlady dat se musí provádět přes DAX
·        KPI indikátory nemají možnost definovat trendové šipky, jestli se jedná o nárůst, nebo pokles
Shrnutí, porovnání, scénáře
Multideminzionální model umí všechno, Tabular s PowerPivotem ne. První stěžejní otázka zda má smysl předělávat stávající fukční vyhovující řešení z multidimenzionálu do PowerPivotu/Tabularu? Nedává to absolutně žádný smysl. Nepřinese to nic navíc, naopak můžeme přijít o některé klíčové funkce a můžete dokonce pohořet s výkonem. Tabular drží data 1:1 vůči zdroji v paměti a teprve pak nad nimi provádí výpočty.
Nad PowerPivotem a Tabularem má smysl uvažovat v případě nového vývoje. Po PowerPivotu sahám v situacích, kdy potřebuji model, který má v rukou uživatel a je schopen si ho sám spravovat, případně aktualizovat data. Přece jen na co dělat pro tří členný tým serverový model. A kdyby řešení mělo přerůst z lokálního řešení na serverové, můžu jej jednoduše zmigrovat do tabularu. PowerPivot taky s oblibou používám na prototypování, abych s klíčovým uživatelem probral funkčnost. Přece jen vývoj jde rychle a čím dřív dostanu zpětnou vazbu tím lépe. Problém je, že dokud uživatel nevidí, nedá dobrou zpětnou vazbu.
Pokud chci serverové řešení kde bude kontrola na straně IT/BI týmu. Rozhodovací strom vypadá zhruba následovně (ne nutně v daném pořadí)
Jakou má klient verzi a edici SQL Serveru. Pokud se jedná starší 2012 a/nebo standard edici, je „odsouzen“ k multidimenzionálnímu modelu. Což nemusí být nutně špatně
Nebude mi chybět některá z vyjmenovaných funkcí? Zejména defaulty, many to many vazby, práce s týdnem, parent child hierarchie?
Velikost dat, jsem schopen nacpat celý model do paměti a když to udělám, bude to dost rychlé? Multidimenzionální model přestože bere data z disku může být rychlejší, protože data předagregovává. Z 10 milionů řádků pro jeden den se stane jedna buňka. Sečíst 365 buněk za rok z disku může být rychlejší, než udělat stejnou operaci na 3,65 miliardami řádků v paměti. Tabulární instance se bude taky delší dobu restartovat, musí data načíst z disku do paměti.
Pokud jsem došel až sem, můžu si zvolit v čem to budu dělat raději :)
Závěr

Tabulární model a PowerPivot multidimenzionální model nenahrazují. Mohou být vhodnou alternativou v závislosti na aplikaci, kterou řešíte. Každopádně jsou jednodušší na naučení se. Nicméně pokud jste se již prokousali „multidimenzionálním peklem a MDX jazykem“ můžete u něj klidně zůstat. Jste-li SSAS nepoznamenaní, tabular může být alternativa. Alternativa, která má však své hranice o kterých je dobré vědět. Osobně v řešeních kde potřebuji vědět, že je neprůstřelné sahám zpravidla po multidimenzionálním modelu, pro „aplikační“ lokální modely po PowerPivotu.

9. září 2015

Novinky v SSRS 2016 CTP 2.3

Dobré ráno s novým článkem o BI, tentokrát o novinkách v Reporting Services SQL Serveru 2016, který je aktuálně ve fázi CTP (Comunity Technology Preview) 2.3 Pro ty z Vás, kteří rovnou zkusí skočit na manažerské shrnutí v sekci závěr můžu říct, dnes není potřeba postupovat tímto způsobem, článek je krátký :) Dnešní článek píši protože jsem na Twitteru napsal, že jej napíšu v záchvatu euforie, že jsou nějaké novinky v SSRS. Berte jej také prosím s nadsázkou, veškeré informace jsou sice pravdivé ale přece jen psané subjektivně :)
Když jsem se ze záznamů přednášek z konference Ignite dozvěděl, že dojde k nalití nové krve do této prastaré technologie byl jsem nadšený. Přece jen my, kteří SSRS používáme, čekáme několik let a několik verzí SQL Serveru na novinky jako na smilování.
Drobné ohlédnutí do historie SSRS
Update z 2005 na 2008 (starším akcím se věnovat nebudu, tohle není cesta do pravěku)
masivní update, nezávislost nové verze na IIS, grafy předělány z vizualizací „styl pravěk“  do vizualizací „styl 20 tého století“ (grafy které vypadaly jako vystřižené z Office 2003 skok na grafy podobné Office 2007), přibývá nová vizualizace budík (a kdo by budíky neměl rád)
2008 -> 2008 R2
Přibyly nám nové grafické komponenty jako například mapa, databars, sparklines a indicators, zbavili jsme se některých nepříjemností ve vývojových nástrojích. 2008 R2 bych označil za poslední masivní update. V této edici jsme mohli také poprvé pracovat s PowerView, přestože PowerView nepovažuji  za produkčně použitelnou technologii. Z omalovánek jménem PowerView sice rychle vypadnou relativně pěkné vizualizace, ale technologie, ve které nejde přepsat titulek grafu... V grafu nejde změnit barva výseče a celově máme téměř nulovou kontrolu nad vizuálními prvky. PowerView je podle mě mrtvá větev vývoje, tohle řeší PowerBI desktop. Tento článek však neměl být o PowerView, ale o SSRS
2012
Nic zásadního
2014
Nic zásadního
Aktuální stav
K poslednímu většímu vylepšení/rozšíření SSRS tedy došlo v roce 2010 ve verzi SQL Serveru 2008 R2. Proto totální euforie při očekávání ohlášených 2016-kových novinek. Předchozí CTP nepřinesly nic zásadního, přestože jsem zatím instaloval každou verzi. Poté vidím na Twitteru něco co vypadá naprosto úžasně CTP 2.3 se screenshotem něčeho, co jsem v SSRS zatím neviděl. Říkám si, to je ono, už to přišlo. Instaluji. Mám s tím trochu problémy, nedá se udělat upgrade, musíte odinstalovat staré CTP a nainstalovat nové. Vývojové nástroje zatím pokulhávají, Data Tools do Visual Studia zatím neobsahují vývojové nástroje pro novou verzi. Chci-li vyzkoušet nové prvky musím z Report Manageru spustit Report Builder. Report Builder je v nových barvách, místo Office bílé máme novou sexy šedou barvu.... Vypadá to, že v této verzi CTP byly SSRS opravdu překopány do něčeho nového. Euforie a potřeba ohmatat si tuto novou technologii
Náhodné ohmatávání (technologie)
Píšu select, dělám klasickou tabulku určenou primárně pro export do excelu a zkouším klasické triky, které nefungovaly v verzích předchozích. Zapínám ve vlastnostech tablixu opakování hlavičky při tisku a aby první řádek držel na obrazovce při rolování. Funkce která nefungovala od verze SQL Serveru 2008... v SQL Server 2016 CTP 2.3 nefunguje dál a musí se obejít přes advanced mode a oklikání vlastností FixedData, Repeat On New Page. Nenechám si rozhodit úsměv a testuji dál. Ukládám report na server a zkouším otevřít v IE. Nový renderer se mě ptá: „Vidíte report pořádně? Pokud ne, nechte zpětnou vazbu, tohle je Preview verze“ Report vidím dobře, stejně jako tlačítko pro tisk. Zkusím stejný report otevřít ve Firefoxu. Stejný dotaz zda vidím report dobře. Report ano, tlačítko pro tisk reportu dobře nevidím. Ve Firefoxu a Chrome se nezobrazovalo a stále nezobrazuje. Neočekávám tedy ani lepší renderování například na mobilních zařízeních
Říkám si, přece když ten Report Builder vypadá tak nově a moderně, musí zde být něco nového. Zkouším klasický sloupcový graf. Vypadá stejně „klasicky“ jako vypadal ve verzi 2008 R2. Nezbývá než se podívat do dokumentace, co by mělo být nového a nacházím dva nové typy grafů Tree Map a Sunburst. Tree Map zobrazuje dlaždice s největší dlaždicí pro kategorii s největším podílem až po nejmenší. Tento typ Grafu má v sobě již nějakou dobu Power BI Desktop. Jak to vypadá se můžete podívat na obrázku 1

Druhý typ vizualizace který přibyl je graf typu sunburst. Tento typ grafu si můžete prohlédnout na obrázku 2

Po přečtení dokumentace k jednotlivý verzím a publikaci reportů na web vidím další příjemnou funkci pauza pro subscription. Není potřeba zakazovat v SQL Server agentovi job se strašidelný názvem, tato funkce se dá provést i v report manageru :)
Závěr
Co se zatím změnilo.
Report Builder má šedé pozadí místo bílého. Je to pěkné, ale kvůli této „vychytávce“ bych nové reporting services nekoupil. Nové 2 typy grafů (sunburst, treemap), pauzování subscriptions v report manageru.
Co se zatím nezměnilo.
Přetrvávají chyby předchozích verzí. Například zobrazení reportů v alternativních prohlížečích, nefunkční zatržítka pro opakování řádků při tisku tabulek, ukotvení na obrazovce a podobně. Vizualizace zůstává stejná jako v 2008 R2.

SQL Server 2016 až do verze CTP 2.3 nepřináší žádné zásadní novinky v SSRS. 2 nové typy grafů a šedé pozadí v Report Builderu to nevytrhnou. Nicméně jako vývojář si uvědomuji, že resuscitace 5 let nedýchající mrtvoly si žádá čas. Na obhajobu společnosti Microsoft musím říct, že v žádném CTP neuváděli “jedná se o edici, která způsobí revoluci v reportingu” Asi si budu muset dát pár verzí CTP oraz a počkat si na finální produkt, abych viděl jestli se technologie posunula, nebo ne.

1. září 2015

Data Mining vs. Machine Learning

Minulý týden mi vyšel článek na MSDN na téma Data Mining vs. Machine Learning. Jedná se o lehce modifikovanou verzi předchozího článku a Azure Machine Learningu. Porovnávám obě technologie a popisuji, v čem je ML jiný, než DM

http://blogs.msdn.com/b/vyvojari/archive/2015/08/27/data-mining-vs-machine-learning.aspx