Podcast

Zde je opravený text s drobnými úpravami pro plynulost a správnost:

Dobrý den, moje jméno je Jirka Vycherek a vítám vás u nového dílu Data Talk podcastu. Mým dnešním hostem je Jirka Neoral, expert, konzultant a lektor na Power BI a Microsoft Data Stack. Ahoj Jirko!

Ahoj Jirko, je pro mě obrovskou ctí být tady na druhé straně Data Talk podcastu.

Poslouchám a je mi ctí, že jsi sem přijel. Vítáme tě! Pro nás je to také čest mít tady MVP pro Data Platform a Power BI, což jsou témata, která dnes v tomto podcastu budeme probírat.

Jak jsem říkal, dnes se s Jirkou podíváme, jak vlastně vypadá Microsoft Data Stack, jakou roli v něm hrají Analysis Services, Power BI, jak do toho vstupuje Microsoft Fabric, a taky, co s celým stackem a BI jako oborem dělá vlna Gen AI a jazykových modelů.

Než se dostaneme k současnosti a budoucnosti, pojďme se podívat do minulosti. Jirko, ty jsi velká osobnost, tady lokální a možná i evropské datové scény, pokud jde o Microsoft. Jak to u tebe celé začalo? Jaká byla tvoje cesta? Co jsi všechno musel vydřít, než jsi se stal MVP?

Já mám hrozně rád to slovo…

Myslíš jako minimal viable product?

Myslím most valuable player. Já jsem hrál basket, takže pro mě je MVP vždycky LeBron.

Chápu. No, záleží, jak dlouho tady chceme být – jestli začít od základní školy, střední, nebo až od vysoké. Možná, aby byla nějaká logická linka, můžeme začít od základní.

Můj první počítač jsem dostal s bratrem, když jsem byl ve třetí třídě základní školy, v roce 1993. A byla to nějaká 386, kdy otec řešil, jestli koupit auto, nebo počítač. Říkal, že do vzdělání nás dětí zainvestuje, a koupí počítač. Což se pak ukázalo jako velký úspěch, pařili jsme s bratrem Prehistorik 2 a další skvělé hry.

Tahle kariéra pokračovala ve čtvrté třídě, kdy se mi spolu s kamarádem podařilo zavírovat počítačovou učebnu, což jsme paní učitelce samozřejmě neřekli. Raději jsme ji pak s velkou pompou "odvirovali". To byly úplné začátky.

Protože mě počítače bavily od začátku, říkal jsem si, kam pokračovat dál. Nabízela se v Mohelnici, což je moje rodné město, Střední průmyslová škola elektrotechnická, kde byl i obor Elektronické počítačové systémy. První dva roky byly obecné, pak následovala specializace na elektronické počítače, kde to bylo celkem zajímavé.

Předtím jsem měl ambici stát se programátorem. Učili jsme se programovat v Pascalu, ale moc mi to nešlo. Potkali jsme se tam i s kancelářskými aplikacemi, což později ovlivnilo moje kariérní kroky, o kterých budu mluvit dál.

Zkrátka jsem zjistil, že programátor ze mě asi nebude, když jsem na maturitě neuspěl s asynchronním klopným obvodem...

Pokud chcete, mohu pokračovat v opravě i další části textu.

Opravený text:

Bvod, tak jsem ho sice dobře spočítal, ale potom, když jsem ho zkoušel zapnout, tak k podivu nefungoval. To už byla na té maturitě jediná trojka – za tu praktickou – že jsem to sice dobře spočítal, ale k podivu to nefungovalo. Říkal jsem si, kam bych tak mohl pokračovat, asi to nebude informatika. Takže programátorem nebudu a evidentně ani hardware nebude, to nepůjde, takže mi asi zbývá jenom ten byznys. Celou dobu jsem si říkal: za čtyři roky na elektrotechnice jsem to moc nepochopil, protože jsem byl takový ten salámista, který řeší věci na poslední chvíli a že to nějak dá, což se potom promítlo i do celé vysoké školy. Ale říkal jsem si: když jsem nepochopil elektrotechniku za ty čtyři roky, proč nepokračovat dál v elektro? Takže jsem…

Takže jsem pak dělal přijímačky. Jednak jsem se asi jako jediný ze třídy, kdybych maturoval z matematiky, mohl dostat i bez přijímaček. Já jsem se však rozhodl maturovat z angličtiny, což teď samozřejmě nelituju, protože angličtinu používám každý den. Tenkrát mě to ale donutilo dělat ještě přijímací zkoušky na vysokou školu. Byl jsem v Praze – dostal jsem se tam – a byl jsem i v Brně na VUT, kam jsem se také dostal. Morava byla mému srdci bližší, takže jsem se přesunul do Brna, kde jsem potom i zůstal.

Co jsi studoval na VUT?
Na VUT jsem studoval elektrotechniku, obor mikroelektronika a technologie, což bylo o návrzích těchto částečně obvodů. Snažil jsem se jít cestou menšího odporu, takže jak mi nešly návrhy klopných obvodů na střední, moc mi to nedělalo problém ani na vysoké, a spíše jsem směřoval ke kvalitě. Moje bakalářská práce se týkala vyhodnocování a optimalizace výroby SIGSIGMA a souvisejících věcí, aby bylo možné vyhodnocovat data, aniž bych to musel dělat úplně sám, a také jak tyto procesy řídit.

Posun na manažerskou či konzultantskou pozici byl celkem brzký. To jsem samozřejmě hned nedělal, ale už na střední škole šlo hodně o vyhodnocování naměřených dat i na elektrotechnice. Dělaly se protokoly, občas bylo třeba stáhnout protokol z loňska, trochu změnit čísla, font, aby to vypadalo jako nová verze, což samozřejmě všichni učitelé věděli. Ale člověk se naučil analyzovat a vizualizovat data, a bylo tam i docela hodně práce v Excelu, což se týkalo i bakalářské práce a protokolů o měření. Excel mě provázel celou dobu.

Po bakalářském studiu jsem si říkal, že bych se rád podíval někam do zahraničí, tak jsem chtěl zlepšit angličtinu. Nenapadlo mě však nic horšího, než zkusit prázdninový program v Irsku. I když už jsme v Evropské unii, pokud se chcete opravdu naučit dobře anglicky, Irsko není úplně ta nejlepší volba. Naučil jsem se tam spíš bulharsky a polsky. Dopadlo to tak, že jsem, protože jsem docela líný a ostýchavý, pokud jde o komunikaci, t…

Tady je opravený text s upravenou gramatikou, interpunkcí a stylistikou, aby byl plynulejší a srozumitelnější:

É práce a to, co dělali jiní, jsem měl problém dělat taky, například kecat při prasných pohovorech o tom, jaké mám zkušenosti jako číšník. Nakonec jsem skončil ve fabrice, která pekla mafiny na noční směně na druhé straně Dublinu. Byl jsem potom rád, že mi táta po třech týdnech práce poslal peníze na letenku, abych se mohl vrátit domů se staženým ocasem. Aspoň jako návrat daní z Irska jsem mu mohl vrátit tu jeho otcovskou péči.

Říkal jsem si, že i když mám bakalářský titul z Česka, asi bez jakýchkoli pracovních zkušeností ve světě moc neudělám. Chtěl jsem proto začít na škole něco dělat, tak jsem zkoušel různé manuální brigády. Můj kamarád a kolega, současný šéf firmy, s kterou spolupracuji – Zdeněk Losek (nejmenuje se Oranosek) – s ním jsme hned v prváku byli ve stejném kruhu. Měl možnost být lektorem v počítačové škole GOPAS, která sháněla nové lektory na Office.

Říkal jsem si, že by to mohl být zajímavý přivýdělek. Byl jsem v té době bakalář a nenapadlo mě nic lepšího, než si napsat bakalářský titul i do živnostenského listu. Začal jsem v 23 letech školit naši generaci rodičů, jak klikat myší, což samo o sobě byla výzva. Co se týče Office, měl jsem k nim blízko díky třeba protokolům o měřeních.

Psaním bakalářské práce jsem se stal lektorem Office a s GOPASEM náš vztah funguje od roku 2007. Takže jsi opravdu přešel z učitelské a lektorské strany do oboru technologií a Microsoft stacku? Ano, přišel jsem tam s Excelíkem a postupně jsem se dostal mezi lektory, kteří byli díky Bohu chytřejší a dálkově pokročilejší než já v technologiích a datech. Začali rozjíždět startup DataExpert, kde potřebovali nějaké juniorní pozice, které by naučili – nebylo to jen malé SROčko.

Piloval jsem své Excelové dovednosti na školeních, kde se často používaly věci jako kontingenční tabulky pro analýzy z pohledu běžného byznys uživatele. Pak za mnou přišli ti kolegové – zdravím Erika Cahovou a Milu Petrku –, kteří nás jako tři mladé kluky v té době vytáhli do startupu a začali nás učit věci kolem Microsoft BI a Microsoft stacku.

Co ten startup dělal? Implementoval business intelligence řešení end-to-end – od tvorby datového skladu, přes ETL procesy a analytické služby (SQL Server Analysis Services), až k reportingu, ať už relačnímu, nebo nad OLAP kostkami analytickými.

Když jsem poprvé viděl OLAP kostku, zjistil jsem, že řeší spoustu věcí, které jsem předtím musel v Excelu dělat ručně...

Pokud chcete, mohu upravit i pokračování, nebo další části textu.

Opravený text:

Žít předpočítanou logiku, třeba hierarchii, drillování z roku na kvartál, z měsíce na den, to, co by člověk dělal v reportu opakovaně a opakovaně, to si říkám, že je super věc, to se mi líbí, to je kontingenční tabulka na steroidech. Samozřejmě, abych byl schopný postavit OLAP kostku, potřeboval jsem také nějak ovládnout to, co je pod tím, takže došlo na návrhy datových skladů, jejich implementaci, jejich plnění v rámci Microsoftového SQL stacku. Takže jsem se nevyhnul SQL, tvorbě datových pump přes Integration Services, reportům přes Reporting Services a právě těm OLAPům. K tomu jsem se tak dostal vlastně z téhle strany a moje doména jsou dodnes Microsoft SQL Server Analysis Services, které pokud bych měl zasadit do historie tohoto produktu, tak začaly někdy okolo SQL Serveru 2000. V podstatě se jednalo o podporu self-service pro koncové uživatele, což je vlastně nic jiného než to, co dnes uživatelé Power BI znají jako semantický model.

V podstatě mám mezi sebou propojené tabulky na základě nějakých implicitních joinů a relací mezi tabulkami faktů a dimenzí. A pokud bych chtěl pustit člověka na self-service, aby si udělal analýzu nad datovým skladem, musel by ovládat SQL, musel by ovládat strukturu datového skladu, co je kde propojené, zatímco Excel napojený na Analysis Services stačí, aby si uživatel něco zaškrtl a on mu něco vrátí. Byla to úloha vývojáře semantického modelu, aby ten člověk nebyl schopný se dotázat špatně — aby neudělal špatný join mezi tabulkami, který by způsobil například kartézský součin, nebo aby nesčítal různé verze plánu a neporovnával aktuální verzi se součtem třech verzí plánu. Takže se tam dalo nastavovat třeba nějaké defaultní řezy.

To vše souviselo s dotazovacím jazykem MDX, který se k tomu používá. Excel je vůdčím klientem analytických služeb, nativní MDX klient, a Microsoft udělal tu chybu, že se snažil MDX jazyk strukturovat jako SQL, takže tam najdeme klauzuli SELECT, klauzuli FROM a klauzuli WHERE, a tím je ta podobnost ukončena. Díky tomu, že jsem věděl, jak je to strukturované, byl jsem schopný v tom přemýšlet, protože dotazování...

Samotný Excel nefunguje jako nic jiného než klikání v kontingenční tabulce. Něco chci na řádcích, něco na sloupcích, něco ve filtru. Tak to pak do určité míry akcelerovalo moji kariéru, protože jsem přišel do firmy a říkal, že umím MDX, takže to něco znamenalo, protože ta kompetence tam většinou nebyla. Také se mi vyplatilo, že jsem to hned učil a hned implementoval, díky čemuž jsem měl akcelerovaný vývoj. Narovinu mě moji šéfové do školení strčili trochu dřív, než by bylo možná vhodné, ale o to rychlejší byl můj vývoj. A tak už si asi neškolili generace našich rodičů, to už byli profesionálové s nějakým technologickým backgroundem, zatímco MDX bylo pro nováčky.

Tady je opravený text s větší plynulostí a gramatickou správností:

V podstatě, než jsem začal školit samostatný jazyk MDX, musel jsem si projít samotné základy, a teď, s praktickými zkušenostmi z projektů, už to můžu otevřeně říct – teď už je to promlčené. Začalo to totiž dost paralelně. Tady máš oficiální Microsoft kit ke kurzu – pořádně si je přečti. Materiály na SQL Server 2008 byly trochu jako rození Ježíška za pochodu – návody krok za krokem obvykle nefungovaly, takže jsem se tím musel prokousat sám. V některých situacích jsem byl o dvě kapitoly napřed před tím, co jsem učil, nebo jsem si nebyl úplně jistý v detailních věcech, když člověk přijde z velkého korporátu a neví úplně, jak to tady funguje. Jak říkal kolega z mé bývalé firmy, rostl s každým projektem, já jsem nakonec rostl s každým školením.

To, že školím, mi totiž vždy dávalo několik věcí, které jsou pro mě strašně důležité. Jednak přemýšlím nad tím, jak co nejlépe vysvětlit látku komukoliv tak, aby ji pochopil. Proč ty věci vlastně fungují, jak fungují, a také proč je dělat správným způsobem. Navíc si během školení udržuji znalosti o věcech, které jsem třeba dva roky nepotřeboval, protože o nich pořád mluvím na kurzu. Když je pak potřebuji po delší době, vím přesně, do kterého šuplíčku sáhnout, mám tam ten pattern z minulosti.

Má to ale i nepříjemné vedlejší efekty – kurzy mi při školení bobtnou, protože přidávám víc příběhů do šířky a potom nestíhám původní časovou náplň. Celkově bych potřeboval třeba den nebo dva navíc. Taky mě posouvá to, že na kurzy chodí lidi z různých oborů. Člověk by jinak těžko zvládal pracovat zároveň pro výrobní firmu, banku a třeba i státní instituci. Co mají ale ty firmy všechny společné, je, že řeší peníze. Potřebují reportovat finance a pak najdu paralely v tom, jak implementovat a zobrazit data na frontendu – je to dost podobné. Když řeším tabulky snapshotované v datovém skladu například pro skladové zásoby, je to podobný problém, jak zobrazit výsledky na úrovni reportu tak, aby se nesčítaly jednotlivé snapshoty za jednotlivé dny na úrovni roku. To nedává smysl. Dává smysl počáteční stav, konečný stav a nějaké trendy mezi tím. A co řeší v bance? Tam jsou to třeba zůstatky účtů – v podstatě to samé.

Všechny firmy také řeší požadavky typu zabezpečení dat, řádkovou bezpečnost. Potřebují, aby lidé odpovědní za region, produktovou kategorii nebo obchodní segment viděli jen svá data – a to často na velmi granulární úrovni. Manažer odpovědný za spotřební elektroniku má vidět spotřební elektroniku, manažer za podkategorii iPhone vidí jen iPhony. Tyto patterny se bez ohledu na segment prolínají. Pro mě bylo ideálním řešením vždy Analysis Services.

Tebe pak možná časem bude zajímat, jak jsem vlastně došel k Power BI, ale ještě bych se teď chtěl zastavit...

Pokud chceš, mohu text ještě více upravit, upravit do formálnějšího stylu nebo rozdělit do odstavců.

Jasně, tady je opravený text, aby byl srozumitelnější a plynulejší:

Číš ke kámošům do startupu Professional Services začínající firmy. To bylo tvoje první setkání se zákazníky a v rámci konzultantské části Professional Services tady přijde Jirka a vysvětlí vám to a správně nastaví. Bylo to trochu náročné, hlavně proto, že jsem byl mladý kluk, možná trochu víc.

Je to podobné jako když jsem začínal jako elektrotechnik – stojíš v učebně před generací, která je někde jinde, a z pohledu byznysu, třeba ohledně Excelu, oni to dělají v praxi, zatímco ty děláš jen protokoly o měřeních. Takže začínáš, jak jsme se bavili v minulé epizodě, s někým o finančních poradcích – když nemáš zkušenosti, můžeš to pokazit, ale snažíš se vypadat profesionálně. Oblek, kravata.

Jakmile jsem získával větší jistotu v technických věcech, postupně jsem odhodil kravatu, pak oblek a nakonec i tričko. A podobně to fungovalo v konzultantské praxi – člověk se snaží vypadat profesionálně. Tenkrát jsem měl problém, že jsem se bál udělat chybu a nechtěl jsem říct, že nevím. Teď už nemám problém přiznat, že něco nevím, a ve finále klient to ocení, když jste k němu transparentní. Když víte víc, než nevíte, je to v pohodě.

Co byly ty případy? Co jsi vlastně řešil? Bylo to čistě na úrovni tehdy MDX? Jak to nastavit? Nebo to už byla byznysová stavba kompletního B.I. řešení?

Jeden z mých prvních projektů byl u České moravské záruční a rozvojové banky, kde šlo o finanční reporting nad analytickými kostkami, které obsahovaly data na úrovni denních zůstatků. Pokud ale člověk chtěl jít na transakce, musel do datového skladu, který vycházel z SQL. Pracoval jsem tedy na tvorbě grafiky, psal dotazy vůči kostkám v MDX, ale také SQL dotazy a dělali jsme propojení mezi nimi.

Typičtí klienti byli středně velké české firmy, o kterých jsme nikdy neslyšeli, ale které měly obraty v řádu miliard. Byly to jak menší výrobní firmy – například firma vyrábějící trička s potiskem, nevím, kolik měly zaměstnanců.

V rámci BIA Experts jsme dělali i projekty třeba pro Polikliniku, kde jsme zautomatizovali reporting, například dohled nad výrobou. Využili jsme mapové podklady – ukazuje se výrobní hala, máme mapu, z ERP systému vidíme stav stroje – červená značí, že stojí, žlutá že běží.

Vizualizační vrstvou byl Reporting Services, tedy celý Microsoft BI stack. U některých klientů jsme tak budovali datové sklady, naplňovali je daty z ERP systémů. Jednou z mých prvních výzev byla snaha zorientovat se v SAP Business One a dostat z něj data do datového skladu.

Pokud chceš, můžu ještě upravit nebo zjednodušit případně doplnit nějaké části.

Jistě, zde je opravený a lépe strukturovaný text:

Není to o moc lepší? Ne, tam šlo o to, že jsi měl ty SAPové tabulky, nějaké oitem, oinov, tak si tam pak psal do komentářů nesmysly jako „bafaloma passevaze“ a další nevhodné poznámky do popisků. Starší kolegové mi vysvětlili, že takhle to dělat nemůžu, ale pak člověk pochopí, že „item“ je pravděpodobně položka, „inov“ je invoice, tedy faktura. Už tehdy mě ty starší kolegové vedli k tomu, že máme projektové Visual Studio a systém pro žádosti o software.

Abychom si byli schopni zájemně vyměňovat informace, i když vývojářů nebylo moc, bylo důležité mít možnost se vracet k tomu, kde jsme byli minulou středu. Vše tam probíhalo, takže to byl široký záběr, který mi časem pomohl dostat se na architektonické pozice. Díky tomu, že jsem byl zapojený do všech fází BI vývoje – od logického návrhu datového skladu přes jeho implementaci, plnění a inkrementální aktualizace až po analytické modely a vizualizační vrstvu. V té době šlo primárně o SQL Server a Reporting Services.

Řekl jsi, že vývojářů nás bylo málo. Už ses tehdy považoval za vývojáře? Přišel mi tvůj začátek moc hezký a motivační. Občas tu máme hosty, kteří zní jako americký sen – na co sáhli, to bylo zlato, nikdy neudělali špatný krok a od začátku bylo jasné, že budou hvězdy. Ale ty jsi hvězda vlastně byl až oklikou. Jak jsi nad sebou v té době přemýšlel? Jak jsi uvažoval o práci? Přicházel jsi z BI, tedy Business Intelligence?

Ano, přesně tak. Firma se dokonce jmenovala BI Experts, což kluci brali s humorem a říkali, že jsou spíš „bývalí experti“ – možná budeš muset tento komentář vystříhat, uvidíme. Dnes jsou součástí Safeuru, což je také pravda. To už je dávná historie a zároveň jedna z těch firem, se kterými spolupracuji i teď, než bude krátce uzavřena, protože byla koupena Safeurem.

Považoval jsem se za vývojáře a když jsem se chtěl naučit nějakou technologii (a drží mě to dodnes), snažím se si na to najít ve volném čase projekt, na kterém si řeknu: „Toto je moje cvičení, ze kterého si něco odnesu, protože mě to zajímá.” Na takovém cvičném projektu se pak technologii skutečně naučím.

Například jsem si paralelně s výukou Office začal dělat vlastní OLAP kostku nad daty, ačkoliv nataženými jen z Excelu. Měl jsem tam historická data o tom, kolik lidí jsem vzdělával v určitém roce, abych mohl dělat meziroční analýzy, sledovat trendy a statistiky, třeba kolikrát jsem učil Excel 1, Excel 2 nebo Excel 3. To byl takový cvičný projekt, který jsem si vytvořil nad svými vlastními daty kompletně end-to-end. Bavilo mě to, protože jsem pracoval s něčím svým.

Paralelně – ještě před příchodem projektového týmu – jsem začal dělat...

Pokud chceš, mohu pokračovat v úpravě i další části textu.

Opravený text:

O pro zákazníka. Takže mi to umožňovalo pochopit ten proces kolem toho. Jo, dělám to z nějakého businessového důvodu, protože mě zajímá, kolikrát už jsem ukazoval, jak se kopírují vzorečky v Excelu, abychom nemuseli pořád přepočítávat na kalkulačce. Mám to podobně – neumím mluvit, vysvětlovat nebo školit věci, kterým nerozumím, neumím je odhadnout, potřebuji věci chápat, neumím je nechápat. Tehdy – píše se rok kolik? – když se ze mě stal ten architekt a když jsem měl to celé, všechny vrstvy toho stacku nebo té business logiky? Architektem bych se v té době vůbec nenazval, spíš tak nějak… Byl to rok 2009, kdy jsem začínal ve společnosti BI Experts. Byl jsem v té době pro ně juniorní vývojář a postupně byla vize uvést některé juniory do analytických služeb, druhé do Integration Services, třetí do Reporting Services a pak si dali roundtable, že budou dohánět zbytek. Takže to byl plynulý přechod. Já jsem v té době pořád ještě učil i ty officeové aplikace, což byla pro mě taková stabilita. V tom startupu nebylo práce ještě tolik, ale postupem času se to více a více překlápělo k BI.

Říkali jsme si, no Office už pro mě v tuto chvíli nejsou zajímavé – učit Excel nebo Access. Byl jsem celkem oblíbený a dokázal jsem to asi vysvětlit tak, aby to lidé pochopili, nebo si to alespoň mysleli. Postupně jsem pak přidával a přibývala projektová zkušenost. Potom jsem dostal příležitost, nebo už jsem příležitost hledal, protože chtěl jsem to zkusit nějakým trochu jiným způsobem. Juniorem se člověku časem přestane líbit, když už mu naroste sebevědomí a nechce už dělat za juniorské peníze, takže jsem hledal, co bokem. V té době jsem už celkem pravidelně učil v Gopasu databázové kurzy s ohledem na Microsoft BI. Tehdy jsem se neúplně kompetentně, ve zpětném zrcátku, pouštěl i do jiných akcí. Gopas mi dal třeba i možnost zajít si na náhled lekce jiného lektora – mít příležitost podívat se, jak učí jiný člověk, a rozšířit si tak technickou kompetenci, což bylo pro mě tehdy úplně super.

Jak jsem ti říkal, že jsem po čtyřech letech něčemu pořád nerozuměl, po pěti letech magisterského studia, kde po bakalářském programu následovala magisterská elektrotechnická výroba a management, jsem to pořád nepochopil. Za těch devět let jsem se tedy přihlásil na doktorát. Nechtěl jsem obvody opustit. Nechtěl jsem elektrotechniku opustit, měl jsem téma z technologického pohledu – akumulátory, protože se mi zalíbilo sexy slovo elektromobil. Doteď říkám, že jsem vlastně inženýr na baterky, i když si z toho moc nepamatuju, protože jsem v tom pak vůbec nedělal. Na doktorát jsem se hlásil hlavně kvůli pasivnímu příjmu, protože bylo možné získat stipendium doktorského studia a zůstaly mi do 26 let ještě některé studentské výhody – jako například Šalinkarta a nižší odvody z…

Opravím a upravím text tak, aby byl plynulejší, srozumitelnější a stylisticky správný:

A sociální a zdravotní pojištění jsem platil jen jako vedlejší činnost. No a dizertace se samozřejmě nenapsala sama, takže tolik k mému bakalářskému studiu, vlastně tedy bakalářsko-doktorskému. Pak jsem se začal snažit najít nějaké další angažmá a bylo to dost vtipné, protože jsem chodil do různých firem, náhodou většinou v Brně. Prvním významnějším zákazníkem byla firma AVG, ne Avast. Tam jsem přišel poprvé. Dnes už je to samozřejmě něco úplně jiného, gem, což znamená, že jsou o krok dál – a to jsem ani nevnímal.

Mimochodem právě AVG byl nástroj, který mi v té čtvrté třídě umožnil odvírovat počítač. Byl to můj lovebrand, jinak bych měl jedničku zkoušku. AVG mě zachránilo. Pak jsem šel na pohovor – tenkrát jsem ani nevěděl, co slovo „intern“ znamená. Kdysi tam právě moje bývalá dělala nějakou pozici a já říkal: “Nevím, co je intern, ale zajdu na pohovor na interna.” Pohovoroval mě pozdější bývalý kolega, kterého jsem znal z kurzu. Díky tomu jsem nemusel dělat technické testy – když tě tři dny školicí kurz na Reporting Services proškolí, tak už si aspoň děláš představu, kde jsi se znalostmi.

To mi potom hodně pomohlo i u dalších angažmá, že jsem nemusel absolvovat jiné technické testy, protože školení pro mě fungovalo v podstatě jako marketing. Takže jsem šel do AVG jako BI intern, vlastně stážista – nebo nakonec jako externista na IČO –, a dělal jsem dílčí věci, většinou spojené s Analýzy Services, což byla moje alma mater.

Během toho jsem dělal i další projekty pro menší i větší zákazníky, ale většinou přes třetí strany. Nechtělo se mi totiž řešit obchod sám, neměl jsem na to kapacitu, rozhodně ne na fulltime alokaci v Praze. Takže pokud mě poslouchá nějaký recruiter...

Napište mi? Ne, že by mi neměli psát, ale většinou svůj business už teď dělám na osobních vazbách s firmami, které znám z minulosti, takže spolupráce už běží.

Myslím si, že už jsem v podstatě za vodou, a že patřím ke konzultantské expertní elitě.

Říkáš Analýzy Services – zjistil jsi v té době, že tohle budeš dělat, že na tom vybuduješ svou doménu a budeš v tom expert? Ano, to byl ten obor, který mě vždycky nejvíce bavil. Baví mě i datové sklady, psaní SQL, logický návrh datového skladu, ale pokud jde o reporting jako takový, nejsem trpělivý člověk a rád už předávám detailní práci někomu jinému, aby to bylo „pixel perfect“.

Právě proto se objevily Analýzy Services a možná trochu později i Power BI. Microsoft totiž v roce 2010 oznámil novou verzi SQL Server Analýzy Services, která je hostovaná v Excelu. Doplněk pro Excel, který se jmenoval Power Pivot – to bylo něco nového, krásného a úžasného.

Pokud chceš, mohu text ještě víc upravit nebo rozdělit na odstavce podle potřeby.

Opravený a upravený text:

Vlastně použitý jazyk DAX, který je doposud používaný jako jazyk pro implementaci business logiky v Power BI. Řekli: Analysis Services, jo, ale tady je to nové, krásné, úžasné Power Pivot pro Excel. Pak si začneš klást otázky, kam to v rámci toho stacku spadá.

Mě strašně zaujal ten bývalý lektor Office, že nějaká technologie přináší možnosti SQL Server Analysis Services na desktopu. Vyloženě možnost nahrnout tam větší objem dat než nějakých 1 048 576 řádků, které se dají uložit na list. Protože jsi omezený pamětí, vlastně nějakou Power BI pamětí. Jsi schopný tam dělat implicitní joiny mezi tabulkami, tak, jak to jde teď třeba v Power BI v rámci nějakého diagramového zobrazení.

A byl jsem to schopný dělat přímo z Excelu, prototypovat, a doteď je to podle mě produkt, který stojí na straně business uživatelů, protože Excel má téměř každý ve firmě, kdo nepoužívá jiné produkty, jako třeba Google Sheets. Že je schopný tohle používat a je schopný používat tu technologii SQL Server Analysis Services.

Bohužel Microsoft nikdy úplně vhodně nekomunikuje, kam ten produkt míří, pro jakou cílovou skupinu. Takže když řekli: "Tady je ten Excel," pak začneš narážet na limity té technologie.

Dobře, jsou to Analysis Services, jsem schopný tady dělat nějaké výpočty, vypadá to velmi jednoduše, skoro jako Excelové vzorce, a tím pádem všechno strašně hezké a funkční.

No ale pak si řekneš: „Tak dobře, jakým způsobem to budu sdílet s ostatními uživateli ve firmě?“ V rámci Excelu zjistíš, že i kdybys měl 64bitovou verzi Power Pivotu Excelu, tak to můžeš sdílet jako soubor. No, to je úžasné, ale moji zákazníci chtějí používat například row-level security, nebo obecně řídit, kdo má přístup k čemu.

Tady ty soubory jsou vlastně celé – stejně jako Power BI Desktop Data Import – přenosné někam úplně bokem, bez centrální správy, což je výhoda i nevýhoda.

Jakým způsobem budu ty aktualizace provádět a jak to budu automatizovat? Nemáme na to úplně nástroje.

Pak přišla serverová integrace, kde pro Power Pivot v rámci SQL Serveru přišla integrace se SharePointem, tak jsem se začal šťourat do SharePointu. Ale to bylo na minimalistické úrovni, kde jsem byl schopný otevřít Power Pivot soubor v SharePointu, tenkrát ještě on-premises.

Zažil jsem absolutní peklo se snahou nakonfigurovat SharePoint a Excel Services v kombinaci s Power Pivotem a SSAS tabulkovými modely. Když někdo získal přístup k datovému modelu, viděl buď vše, nebo nic, protože buď měl přístup k souboru, nebo neměl nic.

Maximální velikost souboru byla nějakých 2 GB.

Tyto Excel Services jsem vnímal jako začátek self-service přístupu – Excel byl dostupný komukoliv a přinášel v lehké verzi možnosti technologie Analysis Services na desktopu, ale bez propracovaného cloudového bezpečnostního modelu.

Přeformuloval jsem text, aby byl srozumitelný a bez gramatických chyb, zachovávající původní význam. Pokud chcete, mohu text ještě zkrátit nebo upravit do formálnější podoby.

Opravený text:

A se školením to byl schopný používat i byznysový uživatel. Pak tam přibývaly další věci, jako doplněk do Excelu Power Query, který vlastně umožňoval načítat data z různých datových zdrojů, které jsou v dispozici teďka. Já jsem úplně zíral, když jsem viděl nějaká videa od produktového týmu Microsoftu, co se dá dělat a jak jednoduše se to dá realizovat. Třeba transformace jako unpivot dynamicky, bez ohledu na to, jestli potřebuji 15 sloupečků, nebo jestli jich potřebuji 20, překlopit tabulku ze sloupců do řádků a udělat to dynamicky. Na pár kliknutí to šlo. Já jsem tu stejnou úlohu dělal v serverových nástrojích. Ptal jsem to v SQL, dynamický unpivot jsem programoval, dělal jsem to v Integration Services, a nebylo to úplné peklo, ale nemělo to k peklu daleko. Možná spíš očistec. Tak si říkám, tohle je úplně super technologie a začal jsem ty věci dál popularizovat i na konferencích. Moje první konferenční přednáška byla buď na Techedu, kde jsem přednášel dohromady s Arikem Sahou, což bylo fajn, protože se za něj mohl člověk schovat, protože je dvoumetrovej chlap. Tam jsem přijel, byl to jeden z šéfů na sbírce Expert, a pak jsem k tomu přidal další. První samostatnou přednášku jsem měl na Show IT v Bratislavě na téma Power Pivot pro Excel. Říkal jsem si, že tohle je úplně úžasná věc, strašně jednoduchá. Pak jsem začal přidávat i další doplňky. Po Power Pivotu a Power Query přišlo Power View, což byl předchůdce postavený na Silverlightu – budiž mu země lehká – vlastně předchůdce Power BI. Začal jsem to používat sám, ať už na pilotní projekty, nebo co by to mohlo dát firmám, které mají zájem o self-service a nechtějí jít do serverových Analysis Services. Začal jsem to popularizovat i díky tomu, že jsem byl dříve jako lektor motivovaný. Moje odměna se odvíjela podle certifikací, které jsem měl v dané technologii, a mohl jsem se tak vyšplhat výš, což bylo motivující nejen finančně, ale třeba i výrazným příplatkem za to, že je člověk MVP. Měl jsem kolem sebe pár Microsoft Most Valuable Professionals z jiných oblastí a říkal jsem si, že kdybych tohle měl, už bych si možná mohl říct, že jsem velký kluk. Takže mě to dostává k tématu MVP – když jsi ho poprvé získal, co to znamenalo? Já kromě toho, než jsem byl MVP, abych mohl vůbec učit oficiální Microsoft kurzy s oficiálními příručkami, což jsou ty s kódem MOC, musel jsem být certifikovaný na danou technologii a v dané oblasti složit zkoušku. Měl jsem takových zkoušek desítky. Teď už tolik certifikací nedělám, občas si je zkusím, abych zjistil, jak na tom jsem. Měl jsem tedy status Microsoft Certified Trainer, který mi přinášel benefity jako přístup k různým zdrojům pro kurzy, ale i například k softwaru v rámci MSDN subscription – tedy přístup například k Visual Studiu, SQL Serveru, licencím na Windows Server, takže jsem si mohl hrát, tvorit virtuální stroje a nastavovat prostředí.

Tady je opravený text s úpravou interpunkce, gramatiky a stylu, aby byl srozumitelnější a plynulejší:

Si tady ty prostředí. Časem k tomu pak přibyly ještě Azure kredity. No a vydal jsem se na tu cestu, protože MVP je ocenění za přínos v komunitě. Jednak člověk musí být nějak technicky zdatný, a jednak by se měl o své znalosti nezjištně dělit. A to jsem přirozeně dělal už dřív, protože školení se do toho úplně nepočítá. Školení je komerční aktivita, kterou děláš za peníze, ale já jsem ve svém volném čase psal blog.

Přednášel jsem na user groupách, takže ta myšlenka se tam zrodila – chtěl jsem, aby MVP bylo oceněním za přínos komunitě. Když jsem se bavil s jedním ze svých mentorů, tak jsem vlastně od začátku chtěl Power BI jako novou hračku, která kombinuje věci z SQL doplňků a frontendu. Říkal jsem si, kde bych to nasadil. Popularizoval jsem to přirozeně na různých konferencích a akcích, ať už placených, nebo neplacených, už od první verze. Mimochodem nevím, kdy bude podcast vycházet, ale myslím, že 24. 7. 2025 Power BI slaví 10 let od General Availability, takže už je to docela dlouho.

Jeden z mých mentorů mi řekl, že ten rybník už je docela plný, takže musím být něčím jedinečný. Já jsem svoji přidanou hodnotu viděl v poskytování lokalizovaného obsahu. Neměl jsem tolik potřebu, což bylo dáno i životní situací, jezdit na mezinárodní akce a každý druhý víkend přednášet na nějaké mezinárodní konferenci. MVP ocenění přišlo tak, že jsem začal víc psát o tom novém a dělal jsem to lokalizovaně právě u Power BI.

V současné době jsem dost známý hlavně díky Power BI, ale Power BI pro mě znamená podložku datové práce. Na Power BI koukám zase jako na SQL Server, analýzy, servisy a něco navíc. Když si člověk otevře Power BI Desktop a podívá se na procesy, zjistí, že mu běží proces msmdsrv.exe, což je proces SQL Server Analysis Services. Data jsou tam hostovaná právě tam.

Musel bych se vrátit ještě pár let zpátky, kdy jsem udělal velkou změnu v kariéře: potřeboval jsem se nechat zaměstnat, protože jsem čekal dítě v roce 2015 a nechtěl jsem už přes den sedět na hotelu a večer vyřizovat meetingy s americkou firmou. A být 14 dní v měsíci, nebo spíš tři týdny, někde na hotelu v Praze, mi nevyhovovalo. Potřeboval jsem zůstat stabilně v Plzni.

V té době jsem předtím proškolil v Gopasu úspěšně budoucí kolegy ze společnosti Dixons Retail, která později změnila název na Dixons Carphone, následně na Carphone Warehouse a tak dále. V podstatě se jednalo o největšího prodejce elektroniky ve Spojeném království, Japonsku a dalších zemích světa. Když mě táhli na...

Pokud chcete, mohu pokračovat a pomoci i s další částí textu.

Opravený text:

Pohovor byl tedy ve 14 hodin a jednalo se o společnost, která má 3 000 kamenných obchodů po celém světě, působí mezinárodně. Jejich centrum měli, nebo mají stále, v Brně. Měli centrum v Excellence v Brně na Trnitě. Pak tam došlo k nějakým změnám, které by šlo ještě příběhově rozebrat. No ale přišli za mnou poté, co jsem proškolil lidi z jednotlivých oblastí. Řekli: „My tady máme potřebu, přecházíme z Teradaty na Microsoft Stack, protože ten byl vybraný. Jako technologii, do které chceme jít, vidíme, že umíš Microsoft Stack. Potřebujeme architekta toho řešení, protože vidíme, že jsi allrounder, který rozumí všem aspektům a orientuje se v té technologii. Nehyperoptimalizuješ jen jednu část procesu, ale vidíš to celé.“

Teď si vzpomněl na ještě jednu zajímavou věc. Rok 2015, tedy období, kdy přichází Power BI. Než se ale dostaneme k Power BI, jak na tom byl cloud? O cloudu jsem už mluvil. Já jsem ze startupového prostředí, a když jsem slyšel o cloudových akcích, které probíhaly asi před 10 lety, a tam se mluvilo o Salesforce a podobných věcech jako o „věcech zítřka“, jaký byl stav cloudu a tvůj pohled na něj v roce 2015?

Tak já jsem začínal využívat své licence Microsoft Certified Trainer a snažil jsem se některé věci aspoň testovat. V té době, tedy před rokem 2015, byl velký hype kolem Big Data. Dosti populární byl Hadoop. Tak jsem si testoval různá řešení a porovnával výkon mezi tím, na co jsem byl zvyklý, tedy Microsoft SQL Serverem, a právě těmito novými technologiemi. Samozřejmě jsem nebyl expert. Někdy jsem možná poškodil svoje jméno tím, že jsem si řekl: „Naučím se to, udělám o tom přednášku a tak si to vyzkouším,“ možná jsem však nedostatečně uvedl kontext toho, co vlastně dělám. Ale člověk nemůže být expert na všechno. Předtím třeba co se týče Power doplňků pro SharePoint, řekl jsem si, že je tam hranice, za kterou už nepůjdu. Takže cloud jako takový již fungoval, začala se používat Azure SQL Database. Postupně jsem si to zkoušel, ale neměl jsem moc zkušeností s implementacemi.

Pak za mnou přišli ohledně on-premise nasazení Microsoft Business Intelligence řešení. Pro mě bylo velmi zajímavé, že tam bylo použito SQL Server Parallel Data Warehouse, což ti možná něco říká — jednalo se o řešení pro paralelní zpracování dat. Fungovalo to podobně jako Hadoop, který měl headnode a compute nody, které paralelně vyhodnocovaly dotazy. Stejně tak Parallel Data Warehouse byla fyzická „krabice“, která měla čtyři výpočetní nody a jeden headnode. Byla to technologie, která se v té době ještě moc nepoužívala. Pro mě to bylo velmi zajímavé z hlediska paralelního zpracování dat — data nebyla indexována na jedné mašině, ale distribuována na více serverech. Místo aby se řešily výkonové problémy jen na jednom stroji, byly data paralelně zpracovávaná... (text končí).

Zde je opravený text s lepší češtinou, gramatikou a stylistikou:

Pokud nahradíš jeden typ výkonových problémů úplně jiným typem, tak bohužel v tom rybníku pak chybí expertíza a máš výrazně méně zdrojů, na které se můžeš obrátit. Díky tomu, že se jednalo o opravdu velkou fyzickou appliance, kde bylo několik SQL Server Enterprise edicí zapojených do clusteru, který musel být navíc propojený s Windows clusterem, aby to vůbec fungovalo jako jeden celek, pošleš dotaz na headnode a pak se něco stane a nakonec ti to vrátí výsledky. Říkám si: „Tyjo, to je cool.“ Ale problém byl... Ty jsi to chtěl zase vrátit k hardware. Vidím to jako tu linku, že jsi nikdy neopustil elektrotechniku. Nechtěl jsi do čistého softwaru, chtěl jsi něco, čeho se můžeš fyzicky dotknout. Nebo tak nějak – jednoduše to byla technologie, na kterou jsem jinde nemohl sáhnout.

Bylo paradoxní, že ta appliance byla drahá jako čert. SQL Server Enterprise edice nepatří mezi nejlevnější softwarové licence, zvlášť když se cena odvíjí od počtu jader. Tak si to vynásob pětkrát, přidej cenu za hardware, přidej cenu za Software Assurance a ještě k tomu, když chceš udělat nějakou aktualizaci, potřebuješ Microsoft inženýra, který to celé updatne, ale zabere mu to tři dny.

Tenkrát jsme už měli reporting jako mission critical, protože bylo potřeba analyzovat prodeje. Další výzvou bylo, že jsme chtěli mít data se zpožděním nejvýše 30 minut, aby bylo možné analyzovat prodeje během největších špiček v roce, například Black Friday, který jsme měli jen jednou za rok. V roce 2015 trval Black Friday jeden či několik dní, ale význam toho dne byl takový, že za jeden den se udělal obrat za normální týden. Proto bylo kritické, aby měli prodejci komplexní reporting se zabezpečením, který jim umožňoval vědět, jestli plní své KPI, například pokud měli televizi v akci.

Potřebovali vědět data téměř v reálném čase. Když se produkt neprodával, tak aby mohli začít řešit, proč tomu tak je. Protože tato paralelní "příšera" byla udržována tři dny, potřebovali jsme jí dvakrát – redundance. Mission critical systému rozumím, jednu potvoru – to ne, potřebovali jsme hardware dvakrát. Měli jsme jednu sadu, se kterou jsme mohli pracovat, a druhou produkční. Jednu používali na descent test, druhou na produkci. Když šla produkce aktualizovat, přepli jsme reporting na testovací server, přemapovali reporty a subscriptions. Nebyl to jen paralelní data warehouse, měli jsme ještě další enterprise systémy, kde běžely ostatní služby.

Super, teď tě zastavím a pojďme se vrátit k Power BI. Jasně, taková potvora už asi běží jen zřídka, ale pokud někde ano, tak mi jich je líto.

Pokud chceš, můžu text ještě víc zestručnit, nebo naopak více vyhladit.

Zde je opravený a stylisticky upravený text:

Power BI „sežralo“ velkou část toho BI stacku a z něčeho, co, jak říkáš, začalo jako plugin do Excelu, se stala platforma, pokud to tak chceme správně nazývat. Mám pocit, že já i spousta posluchačů to dnes považujeme za samozřejmost. Je tu Power BI, které je vizualizační vrstvou a má spoustu společného podvozku s dalšími technologiemi. Jasně, vychází z těch předchozích nástrojů. Když jsi se setkal s Power BI, byl to pro tebe aha moment jako třeba s PowerPivotem, nebo to bylo spíš marketingové zabalení několika služeb dohromady a vlastně jenom velké haló?

Já bych to ještě doplnil, protože to velmi souvisí s celým technologickým stackem. My jsme tam měli ještě server Analysis Services pro korporátní řešení a některé reporty šly přes Reporting Services. Buď tak, že si uživatel mohl ad hoc prohlížet data, nebo mu byla data zasílána formou subscription. A do toho přišlo Power BI. Říkal jsem si – ty reporty jsou krásné, všechno vypadá moderně, voní to interaktivitou a je to hlavně „sexy“. V té době se také spekulovalo, jestli Power BI má nahradit Reporting Services. Můžu doplnit, že ne, ale ještě se k tomu vrátím.

Moje první produkční nasazení Power BI bylo právě na Black Friday, konkrétně na pokrytí intradenního reportingu. Power BI služba byla tehdy ještě v plenkách, infrastruktura nebyla příliš robustní. Nevím, jestli to nebylo dobře zdokumentované, nebo jsem ty informace jenom nečetl, ale nevěděl jsem o některých fyzických omezeních Power BI, která tehdy platila. Nejvíce šlo o počet aktualizací za den a o maximální velikost dat – což jsou během Black Friday intradenního reportingu naprosto klíčové věci. Především počet refreshů byl omezený na 8 za den.

Takže když jsi vytvořil report, pilotoval ho a ukazoval ostatním, měl jsi problém. Scheduler Power BI služby nebyl tak robustní, jak je dnes, takže pokud jsi chtěl spustit refresh až po dokončení procesu v datovém skladu, musel jsi to načasovat na celý půlhodinový blok. Někdy se refresh spustil o čtvrt, jindy o tři čtvrtě hodiny, a po 8 refreshích se prostě zastavil. To bylo nepříjemné především ve špičce. Proto jsme hledali řešení.

Opět se vrátím k SQL Server Analysis Services. Nakonec jsem se na tu špičku stal „refresh agentem“ – ručně jsem aktualizoval data v Power BI Desktop a pak je nahrával do Power BI služby, protože jsem nevěděl o omezení počtu refreshů. Toto omezení platí v licenci i dnes; možná si spolu ještě projdeme licencování Power BI a vysvětlíme, kde jsou ty hranice.

Tohle byla jedna z velkých bariér. Snažili jsme se tedy říct: budeme mít frontend, který splní požadavky, bude moderní a hezký, a díky tomu, že Power BI má napojení na SQL Server Analysis Services, budeme kromě datového importu využívat také připojení naživo (live connection) k analytickým službám. V podstatě jsme tím oddělili backend od frontendu...

Pokud chceš, mohu text doplnit i o další části nebo zestručnit.

Opravený text:

ntendu, protože analytické servisy fungovaly u nás v infrastruktuře jako serverová služba, kterou jsme mohli orchestrace i s dependencemi ze SQL Server agenta. Když bylo potřeba – například jakmile dojel datový sklad – přepočítala se kostka, poslali se reporty a když si uživatel v live connection kliknul na refresh, viděl nové a voňavé data za poslední půl hodinu. Časem jsme začali narážet na druhý problém.

Když jsem přešel do té firmy, bylo to díky tomu, že engine byly dva. Pod Power BI běží takzvaný tabulární engine, ale mnohem delší historii a produktovních projektů jsem měl postavených na MDX, tedy na multidimenzionálních analytických servisech. Takže do čeho půjdeš? Půjdeš do neprobádaného světa, kde nejsi jistý, jestli nenarazíš na nějaké limity, třeba díky tomu, že tabulární engine drží data v paměti. V té době jsem to úplně nevěděl – a šáhl jsem vedle.

Sáhl jsem po multidimenzionálním engine, uděláme to starým způsobem, což nás časem začalo zase omezovat. Díky rozdílům a podpoře mezi těmi dvěma jazyky, které se používají v jednom a druhém, vznikaly komplikace. Pro Power BI je nativní jazyk vlastně DAX. DAX je postavený pro tabulární model, a proto pracuje s placatou tabulkou. Multidimenzionální kostka žádnou takovou tabulku nemá.

Zjistil jsem, že některé typy výpočtů jsou ze strany Microsoftu blokované, aby koncový uživatel nemohl špatně dotazovat data a aby nebyli schopni garantovat výsledek. Typicky jakékoliv výpočty používající iterátory. Když jsem byl na prvním MVP summitu u produktového týmu, řekl jsem, že mám problém: snažím se mít živé připojení na Analysis Services, chci přidat číslo, například zobrazit číslo v tisících, ale tato funkce je blokovaná. Přidat míru (measure) na úrovni reportu tedy nešlo.

Proto jsem se pak do toho korporátního multidimenzionálního modelu musel vrátit a dělat nový počítaný člen přímo tam kvůli jednomu reportu. Tohle nás časem limitovalo. Tabulární model pak postupně ty multidimenzionální Analysis Services na pozadí plynule nahradil. Nebylo to hned, nebyl to PowerPivot, ale engine se postupně vyvíjel a integroval do dalších technologií, kde ho dnes pořád známe v Power BI.

Když si otevřeš Power BI Desktop, uvidíš, že na pozadí běží služba Analysis Services. A když se připojíš k Power BI Premium workspace nebo dedikované kapacitě ve Fabric, připojíš se prostřednictvím Management Studia, jako bys pracoval přímo s Analysis Services serverem. Podvozek je stejný.

Možná že pro tebe byl příchod Power BI velkým krokem, protože jsi získal hezčí vizuály, interaktivitu a lepší uživatelský zážitek. Na jednu stranu ano, ale já se na to vždycky snažím dívat holisticky. Když máš v ruce jen hřebík, všechno pro tebe vypadá jako kladivo, ale já už jsem měl za sebou několik různých nástrojů a technologií, takže…

Pokud chceš, můžu pomoct i s dalším přepisem nebo rozčleněním textu pro lepší srozumitelnost.

Pořád, i do dneška, když se bavíme, se někdo někdy pixel-perfect věnuje reportům, které se exportují do Excelu, protože na nich někdo pracuje. Já tomu říkám "plachta science". Co je "plachta science"? To je situace, kdy vyexportuješ Excel se 60 sloupci a 60 tisíci řádky a pak na tom děláš kontingenční tabulku. To považuji za "plachta science". Přesto některé exportované věci považuji za reporting services jako doplněk k tomu, co nabízí Power BI. Takže pokud potřebuji vizualizaci, která je interaktivní, sáhnu po Power BI. Pak řeším limity: vejde se mi to do importu, nebo potřebuji sáhnout někam jinam – ať už analytické služby, Data Factory, Power BI dedikovanou kapacitu – nebo co od daného reportu vlastně čekám. Protože pokud chci zpracovávat data v tabulkách, Microsoft zatím nepřišel s lepším nástrojem pro práci s tabulkou než Excel. I pro lokální business modely, pro pokrytí potřeb některého menšího oddělení, může člověk klidně vystačit s doplňkem Power Pivot pro Excel. Proč bych sahal po Power BI, abych tahal data z Excelu a pak je z Power BI dále exportoval do Excelu, když při tom exportu mám rozházené formáty?

Rozumím, kam se chceš dostat – ty jsi říkal, že právě v práci MVP jsi zvolil Power BI jako specializaci, jako "flavor", která je nová a zajímavá, jako cesta. Ale z tvé historky to neznělo jako zamilovaný vztah. Já jsem byl zamilovaný a pořád jsem. Každá technologie má své výhody i limity, a já jsem byl schopný a ochotný sdílet i ty místa, kde jsem narazil na hranice. Z pohledu komunity se to cení – když někdo prošlape cestu, abys viděl, že se tam nemusíš vydat i ty. Nebo naopak – v první iteraci jsem to zkusil metodou, kdy se bohužel SQL Server Agent stala i moje šéfová, zatímco já seděl v letadle zpátky do Brna. Šéfová, která byla Britka, report refreshovala a uploadovala ho během víkendu, což člověk úplně nechce. Opravili jsme to příští rok a přišel jsem s frameworkem, který s podporou širšího týmu, kde kluci z datového skladu a i kolegové z reportingu odvedli skvělou práci, pokrylo obchodní požadavky.

Super, kam směřuju, je fakt k MVP. Co to znamenalo? Ty jsi začal docela hezky, překvapilo mě, že tvoje největší síla je v Analysis Services a Power BI byla vlastně jen "flavor" nebo cesta, něco navíc, něco "sexiness". Když ses stal poprvé MVP, bylo to jako Power BI MVP? Ano, první MVP bylo Power BI MVP. Začal jsem ten produkt víc popularizovat místo psaní článků a přednášení na core témata, jako byl multidimenzionální model, který už začínal mít za sebou zenit, psal jsem jednodušší postupy, jak dělat věci v Power BI. A to...

Tady je opravená a stylisticky upravená verze textu:

Bylo to v roce 2015, nebo až o rok později? Spíš až v roce 2017. A teďka uvidím... Po deseti letech školení ses konečně stal MVP. To ani ne, ono to vlastně není jen za školení, ale hlavně za přínos komunitě. MVP se člověk nestane ze dne na den. Musí mít za sebou spoustu aktivit, relativně třeba přes 30 za rok, a být v tom dlouhodobě. Navíc musí přinášet nějakou unikátní hodnotu.

Já jsem si své rozlišení oproti skvělým zahraničním hvězdám vyložil tak, že budu poskytovat lokalizovaný obsah. Také to bylo kvůli tomu, že jsem ve volném čase nechtěl jezdit po víkendech na zahraniční konference, protože mám doma malé dítě. Pro mě byla cesta psát blog, vystupovat na lokálních komunitních akcích, jako je třeba Česká Windows User Group, tedy VUG.cz. Když hledáte, najdete tam spoustu přednášek, které jsem tam dělal. A postupně mě někdo z kolegů, který už MVP status měl v jiné oblasti, nominoval. Řekl si: "Hele, tady je Jirka, který se věnuje Power BI," což byl v té době relativně nový produkt, a tak mi tu nominaci schválili. Od té doby se to nějak vezlo.

Držíš to pořád?
Držím. Teď ke konci, začátkem července, probíhá obnova statusu, tak uvidíme, jestli to zase dostanu.
Držíme palce.
Díky.

Což může znamenat, že můžeš být MVP i v oblasti Analytics 100X.
Přesně tak, tohle může být moje MVP labutí píseň — pro ně to nahráváme.

Když nás poslouchá někdo, kdo by rád byl MVP, nebo to zní skvěle a chtěl by vědět, jak se stát MVP, jaký je podle tebe ten proces? Nemyslím teď oficiální popis na MVP stránkách, ale z tvého pohledu — co je na tom nejtěžší, naopak kde je největší přínos být MVP?

Pro mě osobně, a nemůžu mluvit za ostatní, je to hlavně o motivaci pracovat pro komunitu. Tito lidé to nedělají jen kvůli titulu nebo odměnám, ale protože žijí komunitní činností a chtějí se dělit o know-how. Mělo by to být dělané nezištně, nejde jen o přednášení na akcích.

Nemůže člověk dát za rok dvacet přednášek na komerčních akcích a pak si napsat do aktivit, že je MVP vyhovuje. Většinou to takhle nefunguje. Člověk by měl být v komunitě aktivní delší dobu, mít rozumný počet komunitních aktivit — počítají se zejména odpovědi na fórech, blogy, podcasty, videa, přednášky, tvorba komunitního obsahu, moderování fór i pomoc s organizací akcí jako dobrovolník. Tyto aktivity se hodnotí z dlouhodobého hlediska.

Nevím přesně, jak dlouho ten proces trvá, ale znám velmi málo lidí, kteří MVP dostali rychle. V současnosti máme ve světě Power BI MVP dva – mě a Štěpána Erchela, kterého jsi tady měl už v podcastu. Štěpán navíc byl MVP také na Microsoft Fabric, což je docela unikát. On je asi jediný, kterému MVP schválili hned první rok po nominaci. Hodně pomůže, pokud tě nominuje někdo z Microsoftu nebo zkušený MVP.

Pokud chceš, mohu ti text ještě více zestručnit nebo přizpůsobit konkrétnímu stylu.

Z té komunity. Člověk se může nominovat sám, ale otázka je, jestli do toho člověk chce jít, nebo nechce. Za mě je to hromada neplacené práce. V podstatě jakákoliv tvorba obsahu, ať už podcastů nebo YouTube videí. Škoda, že nemáme video, abyste viděli, jak tady pláču. Ano, je zatím spousta práce. Možná tomu rozumím, nedělejte ty věci kvůli tomu štemplu, protože to je těžký trade-off. Co je pro tebe ten benefit toho statusu? Největší benefit pro mě je napojení přímo na produktový tým. Já se k těm věcem dostanu dřív než běžná veřejnost. Jsem v distribučních seznamech, kde chodí e-maily. Člověk se může podívat na verzi Power BI a desktopu ještě předtím, než je reálně vydaná, aby to byl schopný okomentovat – kde jsou ty největší bugy. Takže preview, insight, nějaký direct access. Ano, ale třeba i náhled na roadmapu. Pro mě osobně největší benefit byl, že jsem si mohl několikrát zajet do Redmondu a promluvit si přímo face to face s produktovým týmem, kde nám představili, tohle jsou ty novinky, dejte nám zpětnou vazbu o tom, co si o tom myslíte. Nebo naopak, i vy jste na front line. Pojďte nám říct, s čím vy válčíte jako implementátoři, s čím válčí vaši zákazníci, co je problém, ať ho můžeme odstranit. To se mi moc líbí, protože mám pocit, že u čím větších softwarů a značek má člověk pocit, že to mají vyřešené, že všechno vědí, že přece kdyby to nefungovalo, tak to je proto, že nechtěli, aby to fungovalo. Ale ve chvíli, kdy se s nimi pobaví, zjistí, že je to softwarový tým, jako znáte, tady z Prahy, Brna a Mohelnice, který dělá chyby, někdy mění kurz, zůstávají tam atavismy, jsou v tom bugy a něco nedohlídnou, protože nejsou zákazníkem. Takže se mi líbí, že je to taková demystifikace celého procesu. Je to tak, a vlastně oceňuji interakci s produktovými skupinami, kde se můžeš potkat přímo třeba s product managerem konkrétní oblasti a říct mu, co tě trápí, i v malé místnosti, když byla skupina Power BI MVP ještě malá. Takže mít možnost si popovídat jenom na dané téma. Nebudu říkat slovo „copilot“, které je teď poslední dobou v Microsoftu populární, ale dřív to bylo bizarní a pořád je to tak, že se snaží táhnout samozřejmě ty sexy nové věci, a přitom nemají dořešené úplně ty základní věci. První rok, když jsme řešili ten intradenní reporting, se mi strašně líbilo, že jsme schopní zobrazit ta data i na mobilu – mobilní aplikace pro Power BI. Nepoběhla jen na Windows Phone? Běžela na všech platformách a dokonce to byl Apple’s REST. Od té doby, co tam není Steve Ballmer, který údajně (to beru jako parličky, protože jsem se bavil se zaměstnanci Microsoftu) pokud potkal někoho na záchodě a držel něco jiného než Windows Phone, dokázal mu to vyrazit z ruky, takže mu pak spadlo do pisoáru. Od té doby, co je tam Satya, je údajně výrazně lepší a více rozumný. Za mě nemáme mečko.

Jasně, tady je opravený text:

Developers, developers, developers.

To je pro mě vrchol – Steve Ballmer tleskající, to jsem měl rád a zase si myslím, že dobře vzal na sebe tu komunikační roli „bad guy“ a po jeho odchodu je to všechno růžové, krásné a je to nový Microsoft. Když ještě tady zůstanu, tak vnímám také, že se změnil pohled na Microsoft. V jednu dobu, a to byla zrovna ta doba, o které mluvíme, byl Microsoft vnímán jako „evil company“ za Steva Ballmera – prostě ten hrozný. Pak přišel nadělá a najednou je to zase cool, takový Apple-like. Už nejsou Windows ty core produkty, ale všechno roste. Jak jsi tohle vnímal? Styděl jsi se někdy za to, že nosíš Microsoftní tričko?

Tak opět jsem byl přizvaný na nějaké diskuze, kde prezentuji Power BI jako ETL nástroj. Ale kluci, Power BI nikdy nebyl myšlený jako čistě ETL nástroj. Nebudu jmenovat žádnou společnost, ale já jsem si říkal, že jsem schopnej pokrýt jen určitou část věcí, a budu buď rozvíjet svoji kompetenci v rámci jednoho technologického stacku, nebo se budu snažit sedět na více židlích a pak nebudu dělat nic pořádně. Takže já jsem se za Microsoft nestyděl. A někdy, jako předtím jsem mluvil o mobilním BI, samozřejmě můžeš dát zpětnou vazbu: „No, ono je hezký, že můžeš říct Siri na Apple Watch, ukaž mi číslo, ale k čemu ti to je, když máš běžný mobilní telefon a nezobrazí se ti tam tabulka celá, protože to není responzivní?“ Takže říkám, mohli byste si dodělat tuhle část, to je pro mě důležitější než „Hello Siri, ukaž číslo na dashboardu na hodinkách“. Teď zase marketingově směřujete třeba k Copilotovi, ale je super mít možnost o tom s produktovým týmem diskutovat.

A když jsme u Satyi Nadelly, tak je také zajímavé zjistit, jak to funguje uvnitř. Microsoft v době, kdy používá cloudové služby, má podle všeho nejlépe otestovaný kód, jaký kdy měl – protože to testují sami na sobě. Bylo mi řečeno, že update fungují tak, že máme nový kód, nasazujeme ho nejdříve do interních Microsoftních tenantů, a teprve po nějaké době ho deployneme globálně, až třeba do Evropy. Pokud je problém, eskalace u Satyi Nadelly nejsou žádná legrace – když nefungují reporty, které chtěl vidět, tak to prostě dál nepůjde.

A to je podle mě i to, jak ten cloud funguje. Když jsem mluvil o paralelní příšeře, tak teď si dokážu v rámci Azure Data Factory vytočit službu jako jednu z komponent, nebo v Azure Cyclical Data Warehouse. Můžeš si přidávat nody, odebírat nody. Jsou to věci, které jsou z tohohle pohledu opravdu jednoduché. Takže si myslím, a možná hejtoři budou hejtit, ale já jsem přesvědčený, že Microsoft má roadmapu a uchopení platformy pokryté celkem hezky end to end. A to ať už jde o data management...

Pokud chceš, mohu upravit i dál, jakmile budeš mít pokračování.

Tady je opravený text:

Ono koneckonců mají to taky v každém Gartneru, v čem jsou jakoby lídři. A prostě mi to dává smysl. Pro mě osobně nedává smysl měnit a přecházet na jiného vendora, protože proč bych to teď dělal, když mi to s Microsoftem nějak funguje. Jo, to jsi zase dobře udělal. Šlo spíš o to, jestli nebyly momenty, kdy jsi myslel, že typicky v tom datovém steku ti to něco sežere. Říkal jsi Hadoop a Big Data, tak to byla jedna taková past, trend, vlna, která tam určitě byla. Moje první vzpomínka byla na Snowflake. Vypadalo to, že Snowflake sežere úplně všechno, že je to desetkrát lepší než jakákoliv jiná technologie. Chvilku jsem měl pocit, že teď ostatní jsou dobet.

Jsou tady nové fajn věci, které možná byly zajímavé. Každopádně pojďme zase trošku zrychlit. Jsme v roce 2016 nebo 2017, jsem MVP Power BI. Když se podíváme na dalších třeba pět let, období 2017–2022, tak zaprvé do toho vstupuje cloud, teda už víc, a zadruhé z mého pohledu to, že z Power BI se stává z nástroje platforma. Nejprve spíš marketingově a potom skutečně, že se to rozšiřuje a už si vlastně v některých případech vystačíš pouze s Power BI, že nepotřebuješ řešit třeba datový sklad. Jak tohle vnímal, jak na to nahlížel?

No, to, že datový sklad nepotřebuji, bych rozporoval, protože ten potřebuješ pořád – pořád potřebuješ dělat datové modely nad něčím. Power BI začínal jako self-service produkt a byl čistě zaměřený na koncového uživatele. Nicméně licenční model, kdy se v té době platilo 10 dolarů za uživatele měsíčně za Power BI licenci, byl naprosto nestravitelný pro obrovské korporace, které potřebují zalicentovat firmu jako celek. Takže pak přišly kapacitní modely Power BI Premium a řešily některé neduhy, o kterých jsme se bavili, počet refreshů, velikost dat, ale hlavně jsi měl zalicencovanou celou firmu pro čtení. Nebylo to však to první, co se snažili vykrýt, přišlo to až později. A postupem času tady tyhle věci přibývaly.

Mně přijde jako škoda a chyba, že někteří lidé a firmy tak přemýšleli o tom, že pokud používají Microsoftí stack, musí z něj používat všechno. Přitom pokud mám funkční datový sklad na Oracle, ale potřebuji Power BI reporty, tak to stále jde. Nic takového není blokováno. U současného klienta máme třeba Amazon Redshift a teď v poslední době řeším přechod ze zmiňovaného Snowflake – hotové semantické modely přemapovat, aby běžely nad Databricks. Vybrat z celé platformy jen tu část, která je pro mě relevantní, protože o tom mluvíme jako o platformě. A to, co funguje, nemusím měnit.

Moje velmi laické poznatky jen z doslechu a konverzací s chytrými a zkušenými lidmi jsou, že byla vlna specializovaných nástrojů na každou část procesu, a že si to člověk může poskládat, jak chce.

Pokud chceš, text můžu ještě upravit, aby byl srozumitelnější nebo formálnější.

Jasně, tady je opravený text:

Ego kostky, totálně modulární systém. Teď mám zase pocit, že z té fáze decouplingu jsme se dostali do fáze couplingu, protože se všechno platformizuje. I když by měla platit pravidla typu API, standardy a podobně, mám pocit, že teď jdeme spíš do nějaké centralizace – do „one solution, one subscription“, mít na faktuře jedno číslo, nemít víc vendorů a tak. Jak se na to díváš ty? Kdy doporučuješ Power BI, když mám jiný stack?

Prakticky je to akorát v situaci, kdy potřebuju Power BI. Mluvíš o tom couplingu, a to spadá pod Fabric, který vlastně Power BI rozšiřuje – Power BI je nadmnožinou Analysis Services a umožňuje dělat stejné datové modely, zároveň pak nabízí frontend a framework, jak to sdílet s koncovými uživateli a nějakou orkestraci bez nutnosti chodit mimo portál. Takže ano, můžu celé řešení postavit klidně na Azure službách – vytvořit datový sklad jako Azure SQL Data Warehouse, nad tím pipelines v Azure Data Factory a reporty v Power BI. To už je ale ta forma couplingu, o které jsi mluvil, stejně jako Synapse například, které nabízí podobné řešení „v jednom balíčku“. Můžete používat jednotlivé služby samostatně, nebo je zkombinovat dohromady. Možná zpočátku nebude tak dobré, jako když si ty „kostky“ poskládáte sami, ale dává to nějakou baseline pro ty, co nechtějí vše tolik propojovat – tady už máte setup, který spolu funguje. Takto momentálně přemýšlíme o Fabricu.

A ještě než skočíme k Fabricu – já se na to moc těším, ale přiznám se, že Synapse jsem zažil spíš negativně. Je to taková půl cesta – ani ryba, ani rak. Velká propozice, malá delivery. Jak se na Synapse díváš ty? Byl to evoluční krok, který musel proběhnout, abychom se třeba dostali k Fabricu? Nebo slepá vývojová větev, která byla chyba, byť dávala smysl v daný moment? Já ho za sebe nepotřeboval, nevím jestli díky Bohu, protože jsme ten stack měli poskládaný jinak. Z pohledu Microsoftu to ale byl logický krok integrovat ty věci, aby to bylo jednodušší pro zákazníky, ať už licenčně, nebo technicky. Když si vytvoříš vlastní řešení na míru, může být pro tebe ideální, ale nemusí být efektivní. Z tohoto pohledu byl Synapse předkrokem k tomu, co pak přišlo s Fabricem. Aspoň tak to vidím já.

Super, tak pojďme k Fabricu. Kdy jsi poprvé viděl preview Fabricu jako MVP? Dostal jsi NDH, bylo to tady, všichni se těšili. Bylo to od začátku myšleno jako zabiják všech ostatních platforem, nebo to spíš vyrostlo potichu?

Popravdě s Fabricem pracuju poslední dva roky spíš než že bych byl u veřejných preview a měl čas vše zkoušet, což je dáno tím, že v roce 2021, po covidu, jsem už potřeboval jedním ...

Pokud chceš, mohu pokračovat v úpravě i zbytku textu.

Jistě, tady je opravená verze textu s lepší srozumitelností a jazykovou úpravou:

Byl jsem korporátně poněkud opotřebovaný, takže jsem se rozhodl zase změnit formát své činnosti. Vrátil jsem se ke konzultantské práci a dělal různé implementace, ale opět jsem byl svázaný týmem, nebo chcete-li "technologickým vázáním", které tam bylo. Používali jsme zase multi-services a Power BI. Už jsem neměl tolik času věnovat se implementacím ve volném čase, spíš jsem se tomu jen věnoval teoreticky a říkal si, že by bylo fajn to někde nasadit. Ale jak to tak bývá s prvními verzemi, nemyslím si, že by už bylo hned vše produkčně připravené pro dané workloady, protože nikdo ještě neměl skutečně osahané ty ostré hrany – podobně jako když se před lety začínalo s Power BI.

Takže je to vhodné spíš pro proof of concept, že budeme některé věci dělat ve Fabriku, ale chce to rozvahu a postupnost. Na druhou stranu jsem přesvědčený, že Fabrik se nyní dostal do fáze, kdy pokud stavíš řešení úplně od nuly a nechceš si komplikovat život propojením mnoha různých zařízení, tak si z Fabriku můžeš vybrat jen ty komponenty, které jsou pro tebe zajímavé. Nemusíš nutně použít všechno. Záleží na tom, jak jsi zvyklý fungovat. Pokud máš fungující řešení s ETL, které plní data do relačního datového skladu, a nepotřebuješ lakehouse ani se učit Python, možná to vůbec nepotřebuješ. Naopak, pokud potřebuješ cyklové komponenty, které Fabrik nabízí, ale zjistíš, že tvůj workload funguje jiným způsobem a potřebuješ řešit data Pythonovými workloady, tak využiješ tuhle část.

Na Fabriku se mi líbí, že nabízí sestavení komponent z různých částí na jednom místě. Komunikace mezi nimi bude výrazně jednodušší, než když bys to musel nastavovat sám. Ale zároveň to, co funguje například v Azure Data Factory, se do pipeline ve Fabriku plnohodnotně dostane až postupně, nebude to celé hned. Podobně je to s funkcionalitou Azure SQL Database, která je dál než SQL Database ve Fabriku, a tak dále. Nicméně pro start nové projekty Fabrik přináší dost výhod a odbourává některé limity, které dříve byly doménou například Power BI Premium.

Na začátku totiž Power BI Premium stál kolem 5000 dolarů za kapacitu měsíčně, pokud jsi chtěl více než osm aktualizací za den v běžném workspace. 5000 dolarů za kapacitu není málo. Pravda je, že firma tím měla licenci pro čtení reportů v celé firmě, což je velká výhoda. Otázkou je, jestli ti stačí kapacita P1, nebo potřebuješ vyšší. Ale Fabrik nabízí některé věci, které dřív Power BI Premium workspace řešil jako server analytických služeb, už teď můžeš dělat i na Fabrikové kapacitě F2, která stojí relativně málo co se týče kapacitních jednotek – začíná na zhruba 150 dolarech měsíčně a přitom nabízí minimálně více refreshů.

Můžeš tak...

Pokud chceš, mohu text ještě upravit víc podle konkrétního zaměření či stylu.

Tady je opravený text s lepší srozumitelností a gramatikou:

A mezi pracovními prostory, workspace deployment pipeline, takže si jsi schopný řešit integraci s Gitem a přímo na úrovni workspace verzovat obsah. Kdybych měl používat Power BI jen tak, čistě pro Power BI, tak tyhle nové věci, které Fabrik otevírá, by pro mě stály za to ten Fabrik pořídit třeba i v minimalistické konfiguraci.

Když se podívám na budoucnost Power BI a otázku, jestli Fabrik Power BI „sežere“ — vlastně už to v zásadě udělal. Dedikované kapacity přecházejí plynule z Power BI samostatně do Power BI Premium a vychází to právě z kapacitního modelu. Nově už nebude možné pořídit samostatnou dedikovanou kapacitu Premium, současní klienti mají svoje kontrakty do konce, potom budou přecházet. Takže se z Power BI stane spíš nástroj, a pokud chceš platformu — tedy platformu na úrovni Enterprise — tak prostě Fabrik, nebo nic.

Pokud chceš kapacitní model, kde třeba potřebuješ zalicencovat celou firmu pro čtení, tak už jenom z pohledu nákladů potřebuješ Fabrik, alespoň dedikovanou kapacitu F64, anebo musíš zůstat u starého licenčního modelu. Koupit si Power BI Pro samozřejmě půjde, myslím, že pro malé firmy a uživatele tam žádná nucená změna nebude. I když se před časem cenově zvedla cena, nyní stojí 10 USD za uživatele měsíčně, ne 14, kolik to bylo dřív — je to asi i kvůli inflaci a tak, takže to půjde dál.

Malé firmy určitě nebudou nucené přejít na nějaké kapacity, které by se jim nevyplatily. Můžeš si Fabrik zvážit podle funkcí, které jsou dostupné jen na dedikované kapacitě. Na druhou stranu, pokud už máš datový sklad, nemusíš ho nahrazovat Azure SQL Database nebo SQL Warehouse nebo Warehouse ve Fabriku, nemusíš data úplně migrovat. Stejně tak, pokud máš data v Databricks, nemusíš je všechny přesouvat do Fabriku. Můžeš si z platformy „vyzobat“ jen to, co je pro tebe použitelný a důležitý.

Spousta firem si to spočítá už i na základě licencování. Dřív to bylo jednodušší: kapacita F64 stála 5000 dolarů měsíčně, a když se to rozpočítalo na původních 10 USD za uživatele, tak pokud firma měla víc než 500 čtenářů, stalo se efektivnější zalicencovat celou firmu a mít dedikovanou kapacitu Premium. Nyní to licenčně nahrazuje Fabrik, stejný princip, ale s přidanými vlastnostmi.

Mohou ale existovat také určitá skrytá rizika. Fabrik běží na principu kapacitních jednotek, které jsou schopné dočasně přetížit kapacitu a udělat nějaký pík, který se pak projeví padajícími výkonovými operacemi na backendu, například při refreshi větších datových modelů.

Pokud chceš, mohu text dále upravit nebo zjednodušit podle potřeby.

Opravený text:

Co je jako kapacita F64, může jít až o několik úrovní výš.

A tím pádem vypálíš ty kapacity hned zpočátku a v extrémních případech to může vést k zastavení kapacity na 24 hodin. To pak klade větší nároky na monitoring, pokud bys to řešil z pohledu Power BI. A když se na to podívám z historického hlediska, říkal jsi, že Power BI je nástavba Analysis Services a Fabrik je nástavba Power BI a dalších věcí. Když půjdeme do toho, na čem jsi vyrostl a v čem rozumíš pořád nejvíc, nejspíš v republice, tedy Analysis Services, jak tyto změny a trendy dopadly na tuto klíčovou technologii? Nebo je to prostě základní technologie, která běží všude, a ať si vymýšlejí, co chtějí na vrchu, tady to funguje a je svět ještě v pořádku?

No, právě nevím, jestli jsem tedy největší v republice, to bych ponechal jiným, každopádně Analysis Services jsou nedílnou součástí Power BI služby, a tím pádem pokud používám Power BI ve Fabriku nebo i samostatně, vždy tam budou Analysis Services, protože je to technologie, která hostuje datové modely a používá stejné úložiště VertiPaq engine. Pokud by to posluchače zajímalo víc do hloubky, mohou si na Vogu prohlédnout nějaké záznamy přednášek, kde jsem o tom mluvil.

Takže pokud je někdo, kdo už je zběhlý v Power BI nebo začíná s BI obecně, tak deep dive do Analysis Services, která bude stále aktuální, bych mu rozhodně doporučil. Začít se vzdělávat v té technologii, v tom podvozku, v tom engine.

To určitě ano, protože když člověk rozumí tomu engineu, může se vyhnout škodlivým dopadům, které souvisejí třeba s tím, jak jsou data ukládána. Data jsou ukládána stejně v Analysis Services, Tabular, Power BI a Power Pivot – to je prakticky stejný princip. Já na kurzech a konferencích často lidem říkám: používáte Power BI, tak už používáte Analysis Services. Je to pak otázka škálování. Můžete si vybrat, jestli použijete malý datový import, kde možná máte omezení na velikost zdroje nebo počet refreshů, ale už teď používáte Analysis Services, protože píšete DAX. A úložiště pod tím je stejné.

Pokud ale potřebuji větší data nebo vyšší frekvenci, musím jít buď do dedikované kapacity, nebo mohu stejnou technologii použít jako virtuální server nebo fyzický Analysis Services. Stále jde o stejný příběh a můžu na to dělat live connection. Ten engine je stále stejný.

V podstatě Microsoft, když vydá novou větší verzi Analysis Services, už ty preview buildy integruje do technologií, jako je Power BI, kde ten backend, který řeší jazyk DAX a úlohy pro Analysis Services, je tam. Nechci říct, že to testujeme jen u sebe, ale do určité míry to tak je. A je to řízené a mají to docela dobře zvládnuté.

Stejně tak do Azure Analysis Services, pokud by člověk chtěl tuto technologii použít samostatně, může. Ale do značné míry Azure Analysis Services už... (text končí).

Jistě, zde je opravená a stylisticky upravená verze vašeho textu:

Můžeš nahradit workspace dedikovanou kapacitou – buď Power BI Premium, pokud ji firma ještě má, nebo Fabric s dedikovanou kapacitou, pokud to dává smysl. A dává. Jen zase přemýšlím, jestli náhodou nemáš v ruce kladivo a všechno vidíš jako hřebík, tedy jestli Analysis Services nejsou tvoje „nové MDX“. Já neumím opravovat auto, umím jen vyměnit pneumatiky, ale do motoru mě nepouštěj. A myslím, že je to tak správně, ale zároveň asi vždy bude prostor pro automechaniky.

To určitě ano, ale je potřeba vědět, že Power BI zahrnuje i Analysis Services, ale není to jen Analysis Services, stejně jako Fabric. Takže pokud mám nějaký byznysový problém, který vyžaduje datového inženýra, který pracuje v Lakehouse nebo ve Fabricu – mimochodem, český překlad Fabricu je „dům na jezeře“ nebo „dům u jezera“, což asi dává smysl – pořád může být relevantní tento use case. Stejně tak budu stále vytvářet datový model nad nějakými daty, která musím nejdřív strukturovat třeba do datového skladu. Takže ano, potřeba datového skladu tam stále zůstává, protože Power BI není nástroj, který by uchovával data v historických souvislostech, neřeší čištění dat a není to něco, co bych chtěl k tomuto použít.

Power BI slouží zejména k tvorbě – a to je klíčová úloha, je to právě ta Analytic Services, je to podpora celého servisu svým způsobem. Tvořím semantický model, do kterého mohu zapojit koncové uživatele – tady to máš, neumíš žádný dotazovací jazyk, ale přes nějaké grafické rozhraní vytváříš front-end. Těžkou část můžeš udělat jak v Analytic Services, tak v Power BI, je to jedno. Pak samozřejmě následuje tvorba vizualizací, a tam se může člověk opravdu vyřádit. To už v Analytic Services neuděláš – ale je to jen jeden díl skládanky.

Dobrý je rozumět tomu, co je pod tím, i co je nad tím, a myslet na to v širších souvislostech.

Pokud bych měl říct, co je specifické pro Analytic Services a Power BI, kde to v rámci řešení nikdy neuděláš jinak, tak je to koncept measures. Když vytvoříš measure v DAXu, funguje na libovolných úrovních hierarchie – třeba udělám meziroční srovnání aktuálního a minulého roku, napíšu třeba tento rok minus minulý rok. A funguje to stejně, ať jsem na úrovni roku, kvartálu, měsíce nebo dne. Stejným způsobem. A já jen driluji nahoru a dolů.

Kdybych chtěl totéž dělat relačně, pořád bych někde přepisoval SELECT nebo GROUP BY klauzule, tady nemusím. Můžu si to udělat sám. Ale věci, které zvládnu spočítat přímo ve zdroji nebo v nějaké ETL/ELT pipeline, jsou počítané věci na detailní úrovni. A vlastně to udělám líp, když to nebudu dělat přes DAX.

Protože cokoliv se počítá row-by-row, jsem schopen spočítat přímo jinde – ať už v data lakeu, nebo v datovém skladu, záleží na architektuře celého řešení.

Co jsou za tebe nejčastější mýty, chyby nebo předsudky, se kterými se...

Pokud chcete, mohu text i dále upravit, případně rozšířit či zestručnit. Stačí říct!

Zde je opravený text:

Potkáváš lidi, co používají třeba dark patterns? Prostě něco, co se říká a rád bys to vymítl. Nebo něco, co nejčastěji klientům opravuješ. Jsou tam nějaké takové věci, které z nějakého pohledu mohou vypadat logicky a přirozeně, ale čím víc do toho člověk proniká, tím lépe pochopí, proč to tak není. Typicky například joiny zprava doleva, zleva doprava, protože ten computer funguje jinak u některých jiných scénářů, třeba u databázových věcí. To je něco, co já znám.

Je něco specifického pro Analysis Services nebo Power BI?

Kdybych měl vypíchnout třeba tři věci, abychom tady nebyli příliš dlouho — three hours later — od tří hodin a nepodívejme se dál, můžeme pokračovat.

Za prvé je to nepochopení toho, jak jsou data uložena v Analysis Services a kam byl ten engine původně směřován. Power BI na rozdíl od klasických relačních databází, které — nechytějte mě za slovo — mají v defaultním úložišti Row Store. Klasická relační databáze je optimalizovaná na datové stránky, které jsou navrženy tak, aby bylo možné načíst celé záznamy, celé řádky. Například když chci najít celou objednávku podle čísla objednávky, pak budu číst příslušnou datovou stránku. A také je podle toho indexováno — index je vlastně jako rejstřík v knize, který mi říká, že objednávky od X do Y najdu na daných datových stránkách, a pak dál.

Nicméně tohle není vhodné pro Power BI, protože Power BI ukládá data na úrovni sloupců, tj. používá Column Store. Díky tomu, že moje nejčastější úloha při tvorbě metrik je suma sloupce, není efektivní číst mnoho datových stránek, které obsahují i jiné informace než ty potřebné. Když mám data rozdělená po sloupcích, získávám výhodu, že mohu načíst pouze relevantní data, která se týkají mého dotazu.

Druhý benefit je, že data, která mají stejný datový typ a často se opakují, mohou být lépe komprimována.

Engine VertiPack, který je použitý v těchto třech technologiích, automaticky dělá nahrazení pomocí slovníku (dictionary encoding). Problém nastává, když je mnoho unikátních hodnot — tím větší je slovník a také výkon může klesat. Lidé pak do modelů vkládají věci, které nepotřebují, a největším anti-patternem je používání „SELECT * FROM tabulka“, tedy výběr všech sloupců, i když je nepotřebují.

To není specifické pouze pro Power BI, ale tady to má ještě větší dopad. Největšími žrouty místa jsou sloupce s vysokou kardinalitou, tedy ty, které mají mnoho unikátních hodnot. Power BI se proto snaží vytvářet slovníky i tehdy, když je to z principu nekomprimovatelné.

Poté lze pomocí analytických nástrojů, jako je VertiPack Analyzer, zjistit, co zaujímá místo v rámci modelu.

Pokud chcete, mohu text dále zpřehlednit nebo rozdělit do odstavců.

Opravený text:

Nejvíc místa zabírají typicky dlouhé texty, například global unique identifier, který je ze svého principu globálně unikátní. Pokud global unique identifier naimportujeme do Power BI reportu, Power BI se pro něj snaží vytvořit slovník, ale vypíše mi něco jako „kardotena“, „bafala“, „mapa“, „se veze“, když chci něco hledat nebo filtrovat. Pokud takový global unique identifier není použitý jako klíč v rámci relace na jinou tabulku, je z byznysového pohledu úplně k ničemu. Stejně tak se tomu dávají, a to je nejčastější antipattern, se kterým se mě pak lidé ptají, proč tam ten sloupec vůbec je.

Power BI bylo navrženo jako nástroj product a self-service, aby si byznysový uživatel byl schopný udělat report sám, a proto veškeré datové typy sloupečků date/time automaticky na pozadí vytváří čtyři další sloupečky navíc podle hierarchie: rok, kvartál, měsíc a den. První věc, kterou lze udělat, je vypnout auto date/time v nastavení Power BI reportu, protože většinou, pokud mám více než jednu faktovou tabulku, tak stejně budu vytvářet společnou dimenzi, kterou budu filtrovat obě faktové tabulky. Vytvořím si tam vlastní hierarchii, místo aby mi každý datový typ date/time vytvořil čtyři extra sloupce, které pak VertiPak engine bude muset nějakým způsobem zkomprimovat.

Druhá věc je nepochopení samotných typů připojení. Power BI na své základní úrovni, pokud nepočítám Fabrik, vždycky podporovalo import dat. Tam začaly maximální velikosti a musíte se bavit o datových refreshích. Často se také používá druhá metoda, a to DirectQuery. Když otevřeš Power BI report, musíš si představit, že co vizualizace, to dotaz. Nativní jazyk v Power BI je DAX. DAX je nástroj použitelný proti VertiPak úložišti nebo Analysis Services, a proto DAX proti Analysis Services funguje rychle. Pokud ale pošleš DirectQuery připojení na SQL databázi, Power BI musí to, co jsi naklikal ve vizuálech (posílané jako DAX), přeložit do nativního jazyka zdrojové databáze. A co vizuál, to dotaz.

Pokud máš stránku přeplněnou vizuály, Power BI to nezvládne vyhodnotit ani při importu. Počet vizuálů významně ovlivňuje výkonnost celého reportu, protože si je rozdělí na nějaké dávky zpracování. Abych nezacházel do technických detailů, automatický generátor dotazů nikdy nebude tak dobrý, pokud se musí přeložit do SQL v jakémkoliv SQL úložišti – ať už Microsoft SQL, Oracle nebo Databricks. Musíš si vždy představit, že děláš dotaz do podkladového zdroje.

Často se mi stává, že zákazník nechce duplikovat data importem, chce mít všechno například v Databricks, Snowflake nebo jiných zdrojích – jak sliboval Data Lake (než přišel Data Lakehouse). Data Lake byl slibem, že všechno nahrneš do jednoho místa a bude...

Pokud chceš, mohu pokračovat s opravou nebo doplněním textu dál.

Tady je opravená verze textu s lepší gramatikou, stylistikou a srozumitelností:

To bude fungovat. Jo, takže ten datový import bude vždycky z tohoto pohledu nejrychlejší, protože importovaný model je optimalizovaný.

Když to uděláš správně, bude to nejrychlejší provedení. Záleží samozřejmě na tom, kolik SQL dotazů aplikace generuje vůči úložišti a co ty dotazy vlastně dělají.

Co se týče komunikace se zákazníkem – my nechceme duplikovat data, všechno máme v databázích nebo v nějaké jiné technologii – to je jedno. Problém je, že oni při každém dotazu a při každé interakci, kdy kliknou na jakýkoliv slicer, dělají skinny tabulky se stovkami milionů záznamů. A to jen kvůli tomu, aby vlastně neduplikovali data. Pak se diví, že to běží pomalu. Například když si pustíš tabulku s 170 miliony řádků, tak že to doběhne za 7 sekund, není zase tak špatné, když děláš table scan.

A pak se ptáš: „Proč jedete data v reálném čase?“ Jeden z dotazů, které vždy kladu, je: „Jaké máte požadavky na aktualizaci dat, když řeším vaše řešení?“ Odpověď často bývá: „Co nejrychleji.“ Ale tady mluvíme třeba o měsíčních datech, takže opravdu potřebuji při každé interakci dělat table scan 170 milionové tabulky, abych bušila do těch databází nebo Snowflake, když by mi stačilo data přepočítat jednou měsíčně a mít je importovaná? To je druhý antipattern – použít nevhodnou metodu pro konkrétní použití.

Samozřejmě pokud máme nějaká near real-time data, můžeme se bavit o hybridních řešeních, ale to už by bylo zbytečné zabíhání do detailů.

Kdybych měl zmínit něco třetího (a možná jsem na to zapomněl), tak je to používat nástroj na jeho určený účel a ne na něco jiného.

Stejně to platí i při importu dat přes Power Query. Power Query také posílá a překládá dotazy pomocí procesu, který se jmenuje query folding – naklikaný dotaz převádí do nativního jazyka datového zdroje, do kterého se ptáš. A dělá to více či méně efektivně. Pokud ale umíš sám napsat SQL, tak ho vždy napíšeš lépe, protože Power Query používá metodu „select from“, „select from“, „select from“ atd. Přestože Microsoft doporučuje nedělat příliš mnoho úrovní zanorených subselectů, Power Query nemá moc jinou možnost, jak to genericky udělat.

Takže, když přijdeš k novému klientovi a děláš assessment, na co se díváš jako první? Předpokládám, že na to, jak mají rozdělenou databázi, jestli používají plachtovou metodu (jak jste říkala „plachtová metoda“). Existují i nástroje typu autodiagnostiky, kde si můžeš sám proklikat pár kroků a zjistit, jak na tom zákazník je.

Já bych to rozdělil ještě dál – pokud přijdeš ke klientovi, který už má existující řešení a potřebuje analýzu nebo konzultaci k tomu, co má, tak většinou přicházejí s konkrétním problémem, který chtějí řešit. Tam se to nedá úplně zobecnit, ale u nových řešení...

Pokud chcete, mohu pokračovat nebo text dále upravit či rozdělit do strukturovanější podoby.

Jistě, tady je opravený a stylisticky upravený text:

Řešení na zelené louce – první požadavky, které mám, se snažím rozdělit na oblasti. Týká se to například oblasti reportingu, protože vím, že na úrovni datových semantických modelů je analytický model mým „formálním modelem“. To znamená, že pokud potřebuji data pohromadě, musím je mít v jednom semantickém modelu. Pokud však jde o dílčí oblasti, jako jsou například lidské zdroje versus výroba a sklady, pak lidské zdroje (HR věci) budou pravděpodobně separátním problémem pro separátní lidi a raději bych je hned na vstupu oddělil. Pak se snažím tyto oblasti sprioritizovat podle toho, kdo je jejich byznysovým vlastníkem, která oblast je nejdůležitější a kolika lidem má sloužit. Důležitá jsou také specifika ohledně požadavků na spouštění reportů a zabezpečení dat – například zda všichni uživatelé, kteří přistoupí do reportu, uvidí všechno, nebo jestli je třeba navrhnout granulární přístup tak, aby lidé odpovědní jen za svou oblast viděli pouze svou oblast. To jsou primární věci, které mě zajímají při návrhu řešení na zelené louce. Pokud vím, že postačí data s denním zpožděním (end of day), není to problém a stačí provést import dat.

Pokud potřebuji jít více do reálného času, je třeba zvolit jiný přístup. Otázka je, jak konkrétně, a já přistupuji oblast po oblasti. Například prodeje jsou asi nejsnáze uchopitelnou oblastí. Vytvářím dimenzionální model klasickým způsobem podle Kimballa. Co potřebuji analyzovat a podle čeho? Například faktovou tabulku, kterou navrhnu buď jako snapshotovanou, nebo jako transakční. Pokud mám data řádově v desítkách milionů záznamů, například „kdo, kdy, čeho“, pak mi z toho vzniknou high-level dimenze. Následně si vytvářím matici prodeje, kdy procházím jednotlivé dimenze – například prodej přes druhý kanál, pak zase jiné dimenze. U prodeje přes internet umím rozlišit zákazníka, u klasického kamenného obchodu maximálně identifikovat obchod, kam přišel. Díky tomu mám odlišný pohled a vznikají high-level objekty, které poskládám do relačního datového skladu. Teprve na tomto základě vytvářím nad tím v analytických službách nebo v Power BI semantické modely.

Jednou z klíčových otázek při návrhu řešení je také podpora self-service BI – zda bude řešení určeno pouze pro IT, nebo zda do něj pustím i koncové uživatele, aby s daty mohli sami pracovat. To pak znamená, jak „blbovzdorný“ musí být semantický model. Pokud by firmě stačily pouze statické reporty, může to zvládnout IT samo bez větších problémů. Pokud však chceme dát uživatelům možnost samostatné analýzy, málokdo je pustí přímo do datového skladu. Často slyším, že uživatelé do datového skladu nemají přístup a musí být zaškolení a ovládat specifické technologie. Myslím, že ten kontext byl, že uživatelé jsou spíše byznysoví analytici nebo programátoři…

Pokud potřebujete, mohu text ještě více upravit nebo zkrátit.

Zde je opravený text:

Analytik s Pythonem z Commerce říkal, že tu není juniorní marketingová manažerka na sousedním oddělení, ale že je důležité, abych se zastavil u hostů. Je něco na technologické úrovni, na co se díváš jako první, aniž bys měl businessový kontext? Nebo jsou to ty dark patterns, o kterých jsi už mluvil?

V podstatě tam nemám nic tak specifického. Je jedno, jestli to jsou Microsoftí cykly, nebo Oracle, případně Databricks — ten semantický model a jeho logické schéma závisí na tom, jak jsou data uložená uvnitř, a jak Power BI funguje při vyhodnocování jazyka DAX a z minulých verzí. Řekl bych, že je to vázané na technologii, a vztah mezi dvěma tabulkami se řeší stejným způsobem, ať už je to postavené na Excelu, nebo na datovém skladu. Jediné, co pak řeším, je škálovatelnost a velikost.

Možná je jedna věc, kterou vnímám jako svůj assessment, a to je — mám pocit, že OLAP kostky, o kterých jsi mluvil, jsou trochu zastaralé. Stejně jako když někdo dnes říká „big data“, ale za posledních deset let trochu zaspal, mám pocit, že pokud firma pořád řeší OLAP kostky, je o krok zpět. Jak jsou na tom podle tebe OLAP kostky? Přijde klient a ty mu řekneš, že řešením jsou právě OLAP kostky?

V zásadě ne. OLAP kostky jsou synonymem pro SQL Server Analysis Services. Název „kostka“ pochází z jejich multidimenzionální podstaty — pokud vezmu měřítko a doplním dimenze například kdy a kde, vznikne mi třírozměrná kostka dat. Takže multidimenzionální OLAP kostka drží data tímto způsobem.

Vznikaly v době, kdy byla paměť drahá a data se snažili ukládat na disk. Jazyk DAX ještě neměl adopci, jakou se čekalo, a byl postupně nahrazen tabulárním modelem, kde PowerPivot byl první variantou. Účel OLAP kostek je ale stejný jako u tabulárního modelu nebo Power BI semantických modelů — jde o semantický model, kde připravím nějakou business logiku, kterou pak může používat i samotný business uživatel.

Oba modely dnes existují vedle sebe a fungují i nadále, ale spíš kvůli zpětné kompatibilitě. V SQL Serveru lze mít nainstalované obě instance a provozovat je paralelně, což jsme sami z hlediska provozní stability také dělali. Ale pokud bych dělal nové řešení, není smysluplné uvažovat o multidimenzionálních OLAP modelech. Často se setkávám se zákazníky, kteří mluví o „kostce“, ale myslí tabulární Analysis Services — pořád to jsou Analysis Services. Multidimensionální varianty už nejsou součástí roadmapy Microsoftu, navíc nikdy nebyly k dispozici jako služba Platform as a Service v Azure. V současné době je možné je provozovat buď na vlastním hardwaru, nebo...

Pokud chceš, mohu pokračovat v úpravě a úpravě zbývající části, až ji dodáš.

Zde je opravený text:

Kýmkoliv ve virtuálu u libovolného vendora cloudového, ale není to něco, co by mělo před sebou zářivou až stříbrnou budoucnost. Takže ten tabulár jako takový řeší právě neduhy multidimensionálu, proto ho začali v roce 2009 předělávat. Firma, která multidimensionál má z jistotických důvodů, tak má dvě varianty. Díky tomu, že jsem stále lektor, občas ke mně přijde někdo, kdo potřebuje udržovat starý systém v chodu, protože člověk, který to měl přede mnou, odešel. Potřebuje alespoň základní znalosti, které mu dokážu vysvětlit, protože si to stále ještě pamatuju, ale na druhou stranu dělat nový vývoj na týmu je úplně mimo. Z tohoto pohledu super.

A když se podíváme na věci, které mají zářnou budoucnost, tak než se dostaneme ke slonu v místnosti zvanému LMS, Gen AI a Copilot, je tu otázka, co může nahradit tabuláry? Tabuláry mají svoji hranici, kde už to nedává smysl, a něco jiného může být další výkrok. Další vývojový krok bude pravděpodobně OneLake, i když nevím, jestli ho zcela nahradí. Microsoft o OneLake mluví jako o OneDrive pro data – data jsou v jednom datalake a máš tam soubory v parquet formátu, které by měly být srovnatelně rychlé jako importované datové modely. Zatím jsem to nezkoušel na praktických projektech, takže nemohu říct, zda je to úplně pravda nebo ne. Ale může to být další výkrok.

Stejně jako import může koexistovat s DirectQuery do relační databáze, tak je důležité znát scénář, což do velké míry souvisí s byznysovými otázkami a požadavky na zpoždění dat. Například, pokud data putují do domu u jezera, musí je tam dostat nějaká pipeline, nebo pokud dělám reporting přímo nad zdrojem. Dává tedy smysl mít více variant místo jen dvou.

Takže co říkáš, že příchod nových nástrojů neznamená, že staré problémy vyžadují nutně nové nástroje, nebo že staré nástroje nejsou dobré. Já například do dneška používám Reporting Services pro účely, na které jsou vhodné. A sám nejsem jediný, v republice je těch lidí docela dost. Když potřebuji například automatizovaný report, který upozorní, že skladové zásoby rostou nad produkci XYZ na dané fabrice o více než 50 tisíc dolarů za den, je to report, který napíšu jako SQL dotaz a pošlu ho automaticky mailem skrz data-driven subscriptions, ať už orchestruji z Power BI, nebo z Reporting Services. Skvělé.

A teď velký závěr. Přišel ChatGPT, Microsoft, OpenAI, v různých obdobích byl vztah vřelejší nebo méně vřelý, ale máme tady Copilota. Sám se s tím hodně hraji. Co to bude znamenat pro Microsoft Data Stack? Všichni to tlačí všude a není nástroj na produktové mapě, který by neměl nějakou Gen AI funkci – počítá se s tím do budoucna, kde to za tebe dává smysl a pomáhá už teď. Jaký to bude mít dopad na...

Pokud chceš, mohu pokračovat v opravě nebo úpravě textu.

Jasně, tady je opravený a lehce upravený text pro lepší srozumitelnost:

A tu práci, ten obor a ten stack do budoucna.

Já bych to rozdělil do několika částí. První by byl pohled Power BI developera nebo i Analysis Services, protože jsou to fakt propojené nástroje. K čemu to například používám já? Musel jsem si v další fázi zkoušet věci na svých vlastních soloprojektech, které jsou úplně nesouvisející s danou prací, abych si procvičil, jak to vlastně funguje, kde jsou hranice, k čemu to je dobré a k čemu ne, aby byl schopný klást správné dotazy.

Power BI vývojové nástroje nikdy nebyly primárně určeny pro vývojáře, kteří pracují s kódem, například ve Visual Studiu. To se ale nyní docela mění. O tom měl krásnou přednášku Roj Romanov, produktový manažer z Microsoftu, na posledním Data Pointu, kterého jste byli i partneři v rámci datatolku. V podstatě pod vším existuje nějaký kód — Power BI semantický model se dá vyskriptovat do jazyka nazvaného TMDL (Tabular Model Definition Language). V podstatě jde o textový soubor. A pokud vím, že je pod tím takový text, jsem schopen některé věci v definicích textového souboru upravit, třeba s pomocí LLM (Large Language Models).

Jeden ze scénářů, který jsem nedávno řešil, byl přepojit data z jednoho typu databáze na druhý, kde se mění úplně ten konektor, který bych normálně řešil v Power Query přes grafické rozhraní. Měl jsem 19 tabulek, z toho několik partitionovaných, například po 13 kusech podle typu fabriky, což dělalo asi 134 dotazů, kde jsem potřeboval změnit konektor. Navíc v nových datech byly použity jiné pojmenovací konvence — například místo mezer byly podtržítka, všechna písmena malá, a podobné vzory.

Pokud mám takový textový skript, můžu říct GPT, Copilotovi, Claudeovi nebo jiné AI: „Potřebuji v tomto vzoru, kde je odkaz na Synapse, přepsat na Databricks, přeházet konektor, který vypadal na dva řádky, na jeden řádek a do každého SELECTu přidej na konec SELECT * FROM tabulka LIMIT 100, abych mohl bez refreshování celého datasetu ověřit strukturu dat.“ Pak to všechny dotazy projede, aby se ověřila správnost struktury na malém vzorku. Když je vše v pořádku, AI odebere LIMIT 100 a dataset se může přepočítat celý.

Nemusím tedy ručně procházet 134 partitionovaných tabulek a navíc je potřeba, aby nad semantickým modelem seděly správné návaznosti — takže například pokud v tom modelu jsou sloupce, musí odpovídat zdrojové struktuře (source columns). Já jsem řešil, že ve zdrojových názvech nahrazuju mezery podtržítky podle stanoveného designového vzoru, protože něco bylo v jednom schématu a teď je to v jiném. To není jen o jednoduchém CTRL-F a CTRL-H, je potřeba umět tohle sofistikovaně zadat.

Pokud chceš, můžu ti pomoci text ještě více zestručnit nebo přizpůsobit konkrétnímu účelu.

Opravený text:

Ávat a říct a rovnou mi to uložit jako textový soubor, abych to tady nemusel kopírovat přes stránku z nějakého okna. Takže to je jeden scénář. Druhá věc je, kromě této modelové definice, že je teď možné uložit i report v novém formátu PBR – popis reportů zase v textové podobě. Pokud potřebuji zjistit, a to je dost komplexní, když máš semantický model a chceš zjistit, co se z toho semantického modelu používá a co ne, tak chceš odklikávat asi 10 reportů, a v extrémním případě jich je samozřejmě ještě výrazně víc, potom půjdeš stránku po stránce, vztah po vztahu a budeš si říkat: "Je tady ten sloupec použitý?" Ne. Vím, že to je PBR, tak jsem si nechal napsat skript, mám tady workspace, napiš mi PowerShellový skript, který mi stáhne všechny soubory z daného workspace jako PBIX, stáhne je, potom je nějakým způsobem sám, ať už dávkově nebo jiným způsobem, převede do toho nového formátu, který potřebuje ty textové popisy, a pak mu řeknu: tady máš model, tady máš zazipované všechny...

Všechny reprezentace těch reportů. Tady máš soubor z Vertipak Analyzeru, který obsahuje informace o velikostech, tedy který sloupec zabírá kolik místa. Vyhoď mi z rámce kandidáty, zajímají mě sloupce, které nejsou použité ve vizuálech, ani nejsou referencované mezi vztahy, které by byly použité ve vizuálech, nejsou použité ve vazbách a seřaď mi to jako Excelovou tabulku podle maximální velikosti sloupce, od největší po nejmenší význam. Hodíš mu tady ty tři vstupy a něco z toho vypadne. Neříkám, že to je v první iteraci hned dokonalé, ale na druhou stranu máš od čeho odrazit. Kde hledat optimalizaci. Přesně tak. Ale i třeba použil jsem ho i na psaní PowerShellu, který už sám nepíšu, kdybych se to měl naučit. Je to můj technologický dluh. Nedám to jednoduše dohromady, tak řeknu: vygeneruj mi ten PowerShellový skript. Jsem schopný si ho pasivně přečíst, vím, co to dělá. Nenapsal bych to sám. Takže napiš mi PowerShellový skript, který mě ověří, dá mi jako prompt ID workspaceu, pak se mi zobrazí dialogové okno, kde vyberu složku, do které to chci uložit. Je to skoro – neříkám, že geniální, ani že to nejde napsat lépe, ale kdybych měl to stejně... To ulehčení je obrovské. Procházet hromady videí a návodů na YouTube, kde sleduješ návod od nějakého člověka, nebo něco předpovídat podle naučených národností, tak než se prokoušeš k tomu, co opravdu potřebuješ, tak tady to dostáváš velmi rychle a v kondenzované podobě, pokud víš, jak se zeptat. Takže je to nástroj osobní produktivity na úrovni nástrojového stacku a funkcí. Co se týče funkcí, tak tady pro ty vývojové nástroje si je schopen použít integraci s Copilotem pro Git. Pokud bych měl vzít jako copilota, tak copilota je několik v rámci té platformy Fabrik. Bylo to dost nedostupné ještě relativně nedávno, protože aby člověk mohl používat copilota a ptát se ho na dotazy nad semantickým modelem, potřeboval drahou kapacitu, která začínala někde na 5 000 dolarech měsíčně za kapacitu. Takže jsem ho začal reálně testovat...

Jistě, zde je opravený text s úpravou gramatiky, interpunkce a stylistiky pro lepší srozumitelnost:

Je to relativně nedávno, ale sleduju borce ze zahraničí, kteří se tomu věnují hodně a snaží se ho právě přinutit k tomu, aby dělal i to, co nemá dělat. Konkrétně pro posluchače Data Goblin – jak on se jmenuje, to je zase bohyně, ale můžeme to potom dát do popisku epizody. Data Goblin si myslím, že je dost specifický. Specifický seriál videí o copilotech právě pro Power BI a pro Fabrik.

Na straně semantického modelu potřebuješ dost výraznou přípravu toho semantického modelu, abys byl schopný nad ním klást otázky. Teď se otevřely dveře, že jsi schopný použít i kapacitu na té nejnižší úrovni F2. Tím pádem můžeš třeba používat copilota jenom na dotazování semantickými modely a dokonce se na úrovni tenantů dá nastavit, že chceš dedikovanou kapacitu pro copilota. To znamená, že jsem schopný se ptát toho semantického modelu a všech dat, které existují v tom ekosystému Fabrik, nějakým způsobem, a přitom můžu mít F2 kapacitu za 150 dolarů za měsíc, která když se přepálí – protože strašně záleží na tom promptu, jakou kapacitu něco spotřebuje – tak jsem však nezastavil chod firmy kvůli tomu, že mě pak nebudou refreshovat mission-critical semantické modely.

Jak se tobě povedlo v roce 2015? To byly jenom jako pošty aktualizací. Rozumím. Co to bude znamenat pro ten stack? Ten stack to bude znamenat to, že veškerá data, která budeš mít pod jednou hlavičkou toho Fabriku, po určité přípravě, si budeš schopný dotazovat na veškerá data, která máš v rámci toho Fabriku – semantických modelů, datových domů, jezer, realiků, verhausu – a přitom to bude respektovat princip nějaké row-level security, man-like security, že člověk by se měl dostat jenom k těm datům, která pro něj budou relevantní.

Můžeš si dělat sumáře v rámci reportů těch stránek, co vidíš na stránce – co bys vypíchl v rámci toho datového modelu? Tam je potřeba hodně ohnout ten semantický model a připravit ho na dotazování. Ale líbí se mi z pohledu platformy to, že ty věci nemusíme sami propojovat. To bude propojené za tebe.

Z pohledu administrátora si budeš muset ty věci hlídat, aby třeba ta bezpečnost byla správně nastavena, aby když se bude ptát biznysák, mohl mu být vrácen jenom relevantní obsah a ne jinak. Musíš tady hlídat věci jako monitorování využití zdrojů. Myšlenka mít data zaintegrovaná do jednoho celku, který spolu mluví, je podle mě dobrá. Jak jsme se bavili o dekouplingu a couplingu, tady ten coupling dává smysl, protože generativní AI pak bude moct pomoci i třeba při dotazování se na data bez ohledu na to, kde v rámci toho Fabriku leží.

Ta cesta, řekl bych, že ještě k tomu, aby to fungovalo ideálně, pár let ještě chce, ale někde bylo potřeba začít. I díky tomu začali s těmi platícími zákazníky, kteří měli vysoké kapacity, a teď se to teprve otvírá na nižší SKUčka toho Fabriku. Nicméně z pohledu dlouhodobé datové strategie mi to dává smysl.

Co to bude znamenat pro stavění BI? Bude to znamenat větší self-service, že už se ani nebudu muset učit nástroje, p---

Pokud chcete, mohu text ještě dále upravit, rozšířit nebo zkrátit dle potřeby.

Tady je opravený text:

Protože se budu ptát přirozeným jazykem, a na druhé straně, na straně právě developerů, to, co jsi říkal – lépe udělat základy, aby do toho mohl pustit náhodný přirozený jazyk a fungovalo to. Jakože podobně, jako když přišlo Power BI, tak najednou odemyká tu vrchní vrstvu, že do toho může kdokoliv, ale v tu chvíli si potřebuji zamknout nebo udělat pořádek v té spodní, protože už do ní pouštím lidi, co vůbec neví, a můžou tam dát třeba „SELECT *“. Je to přesně tak, jak říkáš. Vývojáři semantických modelů budou muset hlídat líp ten základ, aby ten kopilot neblouznil, aby odpovědi, které budeme s těmi daty dávat, byly opravdu správné.

A budou to vývojáři semantických modelů, nebo to bude built-in? Je to něco, co jako další dva roky vyvíjí LLM a infrastruktury kolem, takže to teď musíš fixovat, ale Microsoft to za dva roky fixne za tebe, nebo je to tak specifické právě pro semantickou a tu byznysovou logiku, že to prostě musím zafixovat, protože to není žádný best practice, to je totálně na míru? Myslím si, že cesta, kdy to bude dělat ta AI sama za nás, aby si sama sobě ještě připravila ten semantický model, tak aby byla schopná vracet odpovědi, na základě kterých jsem schopný dělat byznysová rozhodnutí, je ještě docela dlouhá. Nedokážu si to představit v horizontu dvou, tří let, myslím, že ta nejodpovědnější práce bude pořád na straně vývojářů, ale ti si zase můžou práci usnadnit pomocí generativní AI, třeba doplnit anotace v rámci modelu popisu reportů. Aby „Mežrata“ a „Oná“ byly synonyma, když se odvolávám na „vrať mi prodeje“, nemyslím prodeje bez daní, ale prodeje s daní, nebo počet kusů – když řeknu „show me sales“, co má vrátit? On se může rozhodnout, že teď sesumuje částky přes různé měny, což samozřejmě není úplně správné, takže se v současné době musí podívat na to, co přesně dotaz vrátil, a člověk by se měl stále podívat, co to vlastně udělalo, a neměl by se slepě spoléhat na to, že „tohle vypadlo z umělé inteligence“. To je prostě pravda.

O to náročnější bude příprava podkladů, hodně nachystat semantický model, aby na něm mohla dobře fungovat umělá inteligence. Takže jsem rád, že minimálně tobě umělá inteligence práci rozhodně nevezme, spíš ji usnadní a přidá klienty, kteří řeší potřebu národní architektury a chtějí to postavit nějak strategicky a podívat se na semantickou vrstvu.

Já ti moc, Jirko, děkuju, že jsi tady dneska se mnou byl a procházel svoji hvězdnou kariéru from zero to hero. Aby to nedopadlo jako kometa, aby to nebylo...

Svahvězda, která se zemitila sama.

To jo, já si myslel, že myslíš brněnskou Kometu, tak ta se teď naopak docela daří, ne? Myslím v Zoner Areně.

Já hokej úplně nesleduju.

Taky nevím.

Tak to jsme se potkali dva. Každopádně ještě doporučím tvůj blog a Windows User Group, kde je tečka VUK s dvojitým „v“ – .cz.

Jasně, tady máš opravený a stylisticky upravený text:

Kde najdeš spoustu přednášek na různá témata, a doporučím ti také tvého chatbota, virtuálního Jirku, který je naučený právě na tvých a Štěpánových podcastech Power BI Kafíčko. Říkám to správně? Ano, Power BI Kafíčko.

Tento chatbot obsahuje informace jednak z blogů, jednak ze záznamů přednášek a jejich textových přepisů, a také z epizod podcastu. Můžeš si s ním popovídat, ale nespoléhej slepě na to, co ti vrací.

Na mém blogu Neuro.cz najdeš v pravé liště odkaz s názvem „0.0 Jirka“, odkud si můžeš chatbota otevřít a nezávazně s ním konverzovat. Je tam i popis natáčení, jak to testovala moje manželka a jak jí ten chatbot „zavařil“. Chatbot tě totiž může „zavařit“. Pokud tě dnešní díl bavil, neváhej si popovídat s virtuálním Jirkou.

Ještě jednou děkuji a věřím, že jsme dnes otevřeli tolik zajímavých témat, že se brzy potkáme znovu a k některým z nich se podíváme do větší hloubky.

Jirko, i tobě děkuji za pozvání, bylo mi ctí. Potěšilo mě, že to vyšlo na národní svátek, a velmi si cením toho, co děláš pro komunitu – ať už na fyzických akcích, nebo s podcastem, protože vím, že je za tím obrovská práce. Díky za to, je radost potkávat lidi jako jsi ty.

Díky moc a zase někdy. Mějte se!

Děkujeme, že jste doposlouchali až sem. Díky také našim partnerům a členům Data Talk klubu: Intex, Sasca, Bistreet, Colors of Data, Revolt BI, Good Data, Kebula, Emark, Carl Data Company, Data Mind, Notino a Flo.

Pokud chcete zůstat v obraze, co se týče české datové scény a globálních datových technologií, nezapomeňte se zaregistrovat k odběru našeho týdenního newsletteru na datatalk.cz.

Nechť vás provází data!

Kdybys chtěl, můžu ti s textem ještě dál pomoci nebo ho upravit pro konkrétní použití.