Podcast

Dobrý den, jmenuji se Jirka Vicherek a vítám vás u dalšího dílu Datatalk podcastu. Mým dnešním hostem je Jakub Kmeť, principál, BI konzultant a tech lead ve společnosti Intex. Ahoj, Jakube.
Ahoj, Jirko.

Dnes si s Kubou uděláme zaprvé základní představení pro ty z vás, kteří s tím nemají zkušenosti, a na druhou stranu se ponoříme do platformy Microsoft Fabric. Budeme si tedy povídat hodně o Fabricu – jak vznikl, co to vlastně je za zvířátko, jak funguje, na co si dát pozor, pokud s Fabricem začínáte, a také o různých tipech, tricích a pokročilých věcech. Dnešní díl tak bude o Fabricu.

Důvodem je, že Intex je jeden z mála českých Fabric Feature Partnerů, takže na tomto trhu málokdo rozumí Fabricu více než Intex, a Jakub jako tech lead a principál má v Intexu v tomto směru největší znalosti. Uděláme si tedy výlet do Microsoft Fabric, velmi důležité platformy, která dost mění pravidla hry.

Než se ale dostaneme k roku 2025 a tomu, jak dnes Fabric vypadá, a také k možným častým nedorozuměním, které o něm datoví profesionálové mají, pojďme si představit tebe, Jakube. Kde jsi získal svůj background, jak ses dostal do Intexu? Takže ještě jednou ahoj.

Můj background je vlastně v aplikované a finanční matematice. V roce 2009 jsem nastoupil na aplikovanou matematiku na Masarykově univerzitě v Brně, kde jsem měl první kontakt s daty a obecně s analytikou. Byly tam předměty jako základy databázových systémů, datamining a podobně. Je pravda, že v té době jsem ještě ten praktický užitek, tedy to praktické použití toho, co nám tam vyprávěli, až tak neviděl. To chvíli trvalo.

Co jsi si myslel, že z tebe bude? Budeš sedět v bance a budeš můj manažer? Asi něco takového. Myslel jsem si, že skončím někde v nějaké finanční instituci, respektive že se budu věnovat nějakým financím. Pak jsem ještě ve studiu inženýrského směru studoval investice a finance, takže asi někde tím směrem. A zhruba tímto směrem se potom vyvíjela i moje kariéra.

Nastoupil jsem už po škole do KBC, mateřské firmy ČSOB, a začal tam pracovat. Byl to můj první job a byla to čistě nějaká administrativní práce, ale už jsme tam kontrolovali nějaká data. Byl jsem nějaký controlling officer, respektive dual control processing officer, jak se to oficiálně nazývalo, ale byla to spousta administrativy. Co bylo dobré, že jsem tam poprvé přišel do styku s komplexnějšími Excelem, s nějakými sanity checky, s makry a VBA, podobně. Takže to bylo super, ale po určité době jsem zjistil, že tahle pozice není úplně pro mě, a rozhodl jsem se tedy hledat dál a přišel jsem do FNZ.

Co je FNZ? FNZ je firma pocházející z Nového Zélandu, která má nyní hlavní byznys ve Velké Británii, a dělá vlastně nějaký software, platformu pro finanční instituce, banky a podobně. Já jsem nastoupil do operations týmu, který se se mnou stěhoval ze Skotska do Brna. Šlo opět o nějakou administrativní pozici spojenou s financemi, s investičními fondy, ale už to bylo o něco více datově podchycené, bylo tam více VBA maker a Excelů, a začalo to přecházet i do využití SQL databází a dat z SQL databází. Takže tak nějak to vypadalo.

Má náplň v FNZ trvala asi rok, přičemž jsem zároveň studoval. Když jsem dokončil školu a udělal státnice, řekl jsem si, že je čas se posunout dál. Věděl jsem, že chci jít blíže k datům, blíže k byznysu a obecně se posunout. Rozhodl jsem se tedy hledat a po několika pohovorech jsem natrefil na inzerát na pozici Business Intelligence Specialist. Hledal jsem tehdy něco jako business analytika, ale tato pozice mi přišla dostatečně blízká, tak jsem odpověděl.

V inzerátu bylo spoustu zkratek – SOS, ISO, SSRS, myslím, že tam už dokonce bylo Power BI, SQL, a to bylo jediné, co jsem znal. Zkusil jsem to a nakonec to vyšlo. A to byl Intex. Tehdy to ještě nebyl Intex, ale Intelligent Technologies. Byl to rok 2016, takže příští rok tomu bude deset let.

Kolik vás bylo tehdy, jak to vypadalo? Byl to jeden malý kancelářský prostor, spíše byt, bylo nás asi 12–13 lidí, včetně Luboše, Radima a dalších asi 10 vývojářů. Dnes nás je asi 70–80. Punkový, startupový začátky, bez produktu, ale nalákalo mě to.

A přestože jsi nerozuměl všem těm zkratkám, nastoupil jsi na pozici BI specialisty.
Ano, byla to juniorní pozice, protože jsem těm zkratkám ještě neplně rozuměl.

Co bylo super a z čeho stále těžíš, byla práce na novém projektu pro food retail, kde jsme rozjížděli reporting. Tehdy to bylo na SQL Serveru 2016, což byla novinka, a vše se budovalo od nuly – tzv. ze zelené louky. Byla to velká škola.

Přišel jsi tedy z prostředí Excelu a kontrolování dat. Měl jsi nějaké znalosti SQL, ale asi to byla především škola, ne?
Ano, bylo to náročné se to naučit, ale musím vyzdvihnout podporu od Luboše, od Intexu a mých kolegů, kteří byli velmi nápomocní. Pracovali jsme jako tým a hodně jsem se naučil. Zadání bylo tehdy přesné – přesné reporty, kde měla být daná tloušťka čáry, barva, to bylo dané v Reporting Services. Data bylo ale potřeba analyzovat, připravit, navrhnout datový model, udělat ETL, integrace a vybudovat OLAP kostku, na základě které se reporty tvořily. Byla to výborná, velká škola.

Předpokládám, že vše bylo on-premisové?
Ano, SQL Server 2016 on-prem.

Takže to byla tvá první zkušenost s end-to-end projektem Food Retail. Kam jsi se pak posunul?
Posunul jsem se na další on-prem projekty, větší i menší, a pak přišel velký projekt pro Philip Morris, jednoho z našich prvních zákazníků, pro kterého jsme dlouhodobě spolupracovali. Pro mě to byla výjimečná zkušenost kvůli velikosti a způsobu práce v korporátu. Už nás tam bylo více vývojářů, takže bylo potřeba i projektové vedení z naší strany. Systém byl komplexní, co se týkalo množství dat, šíře atd.

Měli jste na starosti nějakou konkrétní doménu, nebo to bylo napříč nějaké infrastrukturní řešení?
Podporovali jsme tým, který spravoval a rozvíjel datový sklad pro českou a slovenskou entitu, postupně také maďarskou, tzv. klastr těchto tří zemí, a vše, co s tím souviselo.

Bavíme se o letech 2017–2018?
Ano, asi tak. Projekt se pak táhnul zhruba čtyři až pět let.

Mezitím začal být patrný přechod k Azure, cloudovým řešením, nové integrační nástroje jako Data Factory, vznikal data lake a další věci, takže jsme se vydali i tímto směrem, což mě velmi oslovilo. Platforma se mi moc líbila, umožňovala snadnou škálovatelnost a parametrizaci. Bylo tam sice ještě mnoho věcí, které nebyly úplně jednoduché, například načítání dat z Excelu přes Data Factory bylo výzvou, ale to bylo naopak zajímavé.

Možná když tě tady zastavím, tak dvě věty, co tehdy znamenaly Data Factory a Data Lake? Všimněme si, že nás poslouchají lidé, kteří jsou ještě zabetonovaní v on-prem prostředí, ale i ti, kteří tuto éru nezažili a neumějí si představit, co znamenal přechod do cloudu, orchestraci a že bylo potřeba hodně kódu, abychom dosáhli jednoduchého řešení. Vem nás vzpomínkami zpátky, co pro vás znamenal přechod na cloud?

Dobře, popíšu, jak vypadá standardní projekt, který jsme implementovali a stále částečně udržujeme. Měl zhruba tři složky. První je Data Lake, což je úložiště, kam shromažďujeme data – strukturovaná i nestrukturovaná.

Druhý je datový sklad, kde stále používáme tradiční SQL databázi – v Azure SQL databázi.

A zajímavé místo je Data Factory, což je integrační a orkestrační nástroj. Tam se tvoří datové pumpy, pipeliney. Obsahuje hodně konektorů na různé zdrojové systémy a umožňuje škálovatelnost a parametrizaci, a zároveň tvorbu komplexních metadatových řešení.

Po přechodu do Azure cloudu přišla na scénu platforma Synapse od Microsoftu. Jedná se o novou platformu s cílem sjednotit Data Lake, Data Factory, databázi a další do jednoho centralizovaného prostředí, nazvaného Azure Synapse Analytics.

My jsme měli jako partnerská společnost Microsoftu tu výsadu, že jsme tam byli od začátku a testovali to, ale potom přišel COVID. Pro mě důležitý projekt byla Chytrá karanténa.

Chytrá karanténa vznikla na začátku pandemie COVID-19, kdy jsme pomáhali centrálnímu řídícímu týmu vytvořit reporting dat o nakažených, testování a dalších informacích. Po první fázi se to přeměnilo v robustnější řešení, kde už nešlo jen o Power BI reporty, ale bylo nutné podchytit i back-end. Nastoupil jsem tam a začali jsme tvořit datový sklad na Synapse.

Byla to výborná zkušenost, nová platforma, ovšem byla tam i velká zátěž kvůli povaze projektu – šlo o životy lidí, což je samozřejmě velmi smutné.

Projekt vyžadoval hodně práce, i přes vánoční svátky. Byla to obrovská škola ohledně technologií a možností práce s daty na této platformě.

Nicméně samotný Synapse z mého pohledu nikdy nezískal takový "love brand". Naopak, na scéně byl vnímán hodně negativně, jako nejasná strukturální skládanka, což nebylo jasné řešení. Hodně lidí vzalo za vděk, že Microsoft už ho netlačí tak intenzivně jako dříve.

Na druhou stranu, jak jsi právě zmínil, dává to smysl – jde o integraci jednotlivých servisů do jednotné platformy.

Než přejdeme k Fabricu, tento trend je evidentní.

Ještě bych se ale vrátil k Synapse. Nemyslíš, že to není úplně špatná platforma, ale měla své problémy a prostě se neuchytila?

Ano, není to úplně špatná platforma, měla své mouchy a nějak se nepodařila prorazit. Microsoft ale z mého pohledu od myšlenky jednotné integrace nástrojů a prostředí neustoupil. Ta cesta zůstala a vyústila v dnešní Fabric, kde už je to podle mě skutečně lepší.

Když se ještě vrátíme ke Chytré karanténě – co vlastně běželo v pozadí, kdo byl konzumující stranou, pro koho jste pracovali? Ptám se zejména proto, že byli jsme i my trochu vtaženi, časotlůkalová například dělala pro bono pro COVID-19 CZ. Odejít od toho bylo hodně lidí, protože byla obrovská emocionální zátěž, ale zároveň vznikly skvělé věci a ukázalo se, jak dokáže česká technologická scéna společně něco dostat na velmi vysokou úroveň.

Abychom si to shrnuli – co tedy bylo výsledkem vaší práce, kdo byl konečný uživatel dat?

Primární konzumující stranou dat byl centrální řídící tým. Našim přímým zákazníkem byl někdo na Ministerstvu zdravotnictví (NaKIT) a data poskytoval většinou ÚZIS.

Centrální řídící tým byl například premiér nebo ministři?
Nemohu ti je úplně vyjmenovat, přímo s nimi jsem nepracoval, to zajišťoval NaKIT, ale obecně ano.

Dobře, a s kým ještě jste jako tým spolupracovali?
Spolupracovali jsme se třemi entitami – NaKIT, ÚZIS a armádou, což byla také výborná zkušenost.

Dobře, vraťme se k Fabricu, máme o čem mluvit.

Ještě jsi říkal, že Intex má v současnosti 70–80 lidí a že primárně pracujete s Microsoft Stakem, asi skoro exkluzivně. Je to tak? Máte certifikace gold partnera na Analytics, Data Platformu a Cloud Platformu?

Předtím, než se vrátím k Fabricu, pro kontext: Naši klienti jsou převážně firmy v Česku a na Slovensku, ale máme i zahraniční zákazníky z Velké Británie, Ameriky nebo Švédska.

Mezi známé značky, pro které pracujeme, patří například Dr. Max, Tesco, výrobce vědeckých mikroskopů ze Zbrna a také potravinová síť Hruška, což je zajímavý zákazník z retailu.

Přejděme tedy k Fabricu.

Podobně jako u Synapse díky vztahu s Microsoftem a vaší specializaci předpokládám, že jsi o Fabricu slyšel dříve než ostatní – „before it was cool“.
Ano, o Fabricu jsem slyšel ještě před tím, než se tak jmenoval, protože jsme měli možnost se zapojit do private preview programu, tehdy se jmenoval Trident.

Zajímavé je, že v některých částech Fabricu dodnes najdete zmínky o Tridentu – například jako název endpointu, nebo knihovny. Takže pozor na ty původní názvy, většinou se zachovávají dlouhodobě.

Můj oblíbený příklad je PageRank, což je způsob řazení výsledků Googlu – jméno pochází od Larryho Page, není to „Web PageRank“, ale „Larry Page’s Rank“. Něco pojmenovali ve dvou minutách jako vtip a i po 20 letech to pořád funguje.

Takže zpět k Tridentu. My jsme se do toho Private Preview ...

Programu jsme měli možnost něco tam vyzkoušet, vlastně zjistit, co se tam snaží udělat. Hlavní část mé práce byla v Synapse. Už tehdy bylo vidět, že Fabrik se snaží integrovat back-endovou část Synapse do známého, uživatelsky přívětivého prostředí Power BI. Vzali Data Engineering, Machine Learning věci ze Synapse, jako Spark, a nějakým způsobem je integrovali do Power BI prostředí. Myslím, že se jim to celkem podařilo.

Jasně, pustili to v nějaké preview verzi, mělo to určité problémy, ale už... Jeden z důvodů, proč jsem vás sem pozval, je, že se mi strašně líbí, jak o Fabriku mluvíte – nelakujete ho na růžovo, ale říkáte porodní bolesti. Fabrik je tady jak dlouho? Už skoro dva roky? Jo, dva roky od doby, kdy je v GA, a myslím, že byl asi rok v preview. Přesné datumy teď neznám, ale něco takového.

Tak pojďme navázat – začali jste Fabrik nasazovat u prvních klientů, prvních pilotů, tak co byly první věci, které nefungovaly optimálně?

My jsme ho začali nasazovat prakticky hned, samozřejmě po nějaké dohodě se zákazníky, ještě když to bylo v preview. Microsoft tvrdě tlačí ten přístup „pojďte si to vyzkoušet, zapněte trial na 60 dní a jdeme na to“. Vyzkoušeli jsme to s dvěma odvážnými zákazníky, které jsme měli na spolupráci. Mnoho věcí bylo skvělých, spousta věcí se dalo rychle udělat a začít nějak náčrtně tvořit. Zároveň to stále bylo v preview, trial verzi a člověk nevěděl, jestli to, co tam bylo včera, tam bude i dnes, nebo jestli se něco nezmění, nepřejmenuje a tak dále. Vývoj byl tedy poněkud náročný.

Nenabourávalo vám to práci?

Mám takovou zkušenost – když jsme začínali s Fabrikem i školeními. Například školení FIAT, což je microsoftí školení, které pořádáme každý měsíc. Připravoval jsem se na první školení, kde jsme byli jedna z prvních firem v Evropě, která to dělala. Proklikal jsem se k tomu, připravil se. Druhý den s kolegou jsme prošli lekce, vše šlo dobře, až jsme došli k vytváření modelu – tam některé formátování metrik, které jsme viděli den předtím, už nebylo přítomné.

Při školení to bylo nepříjemné, protože člověk prezentuje před lidmi a říká, že něco tam bude, ale ono tam není. Live demo, ano. Tohle se občas stává s vlastním softwarem, že vývojáři změní něco před prezentací zákazníkovi. To už není pravda. Ve vztahu k tomu, o čem mluvíme, je to stále work in progress. Po dvou letech je to lepší, ale...

Od doby, co je to v GA, má to rozhodně lepší úroveň. Platforma je teď mnohem vyspělejší a technologický dluh, který dříve měla, je do značné míry smazán. Často se používalo srovnání s platformami jako Databricks, které jsou zralejší. Myslím, že teď už to tak není. Obzvlášť když má člověk normálně placenou verzi Fabriku, tak už se věci tak zásadně nemění pod rukama. Některé věci, které nejsou úplně dotočené, jsou označeny jako preview, takže je to jisté riziko, ale základ tam je.

Co se tedy za ty dva roky změnilo a co lidi odrazovalo od Fabriku?

Momentálně má Fabrik na všechno vlastní API, vše je zálohovatelné, verzováno, takže je plná podpora DevOps, CICD a podobných věcí. V tomto je to fakt dobré. Nedávno přidali také SQL databáze, writeback z Power BI umožnili a podobné zajímavé funkce, které to posunují na jinou úroveň.

Předtím než se pustíme do těch cool funkcí, tak obecně, dává ti smysl spojit Power BI se Synapse platformou?

Pro mě jsou to logické kroky, platformizace. Když mluvíme o Synapse, tak reason to believe, tedy důvod tomu věřit, mi dával smysl. Jsou to služby vedle sebe, používají je stejní lidé na stejné úrovni a děláme to jako platformu. Pokud se Synapse nepovedl 100%, tak vezmu Synapse a Power BI, kde jsou trochu jiné uživatelské skupiny a části stacku, a spojím je.

Přijde mi to náročnější, ale když o tom mluvíš, zní to, jako že jim to trefili. Máme ve firmě, pokud to hodně zjednoduším, rozdělení na Power BI specialisty a Power BI developery a na data inženýry, kteří pracují s Fabrikem, se Synapse funkcemi. Myslím, že v praxi tyto dva světy více propojují. Power BI vývojáři si dokážou připravit transformace dat ve Fabriku, do Synapse by asi nešli. Praktická stránka je, že když mám prostředí, kde trávím 90 % času, nemusím se přepínat do jiných rozhraní, ale jednoduše přejdu do workspace v jiném prostředí.

Je to velmi jednoduché, každý si ve Fabriku najde, co potřebuje – SQL, Python, Power Query známý z Power BI. Naopak data inženýři jsou blíže technickému světu, SQL, notebookům a přirozeně sledují výsledné reporty, které prezentujeme zákazníkům. Ty světy se takto vzájemně doplňují a nebyla to špatná cesta.

Nemyslím, že každý teď dělá všechno, to rozhodně ne. Ale je cítit propojení.

Pojďme se podívat na to, co je Fabrik?

Je to Power BI a Synapse dohromady?

Víš, 1 plus 1 je 3, jak se říká. Kromě synergie, co to vlastně znamená? Je to jenom, že někdo vzal dva produkty, spojil je a říká, že máme nový produkt? Nebo vidíš nové platformní věci, které Synapse ani Power BI samy o sobě nenabídly?

Určitě platí, že 1 plus 1 je v tomto případě 3. Je to trochu nadsazené, ale kromě samotného data engineeringu a vývoje reportů tady mám více jednotnou správu nad datovými produkty a nástroji, které používám.

To je dobré, lze to řídit pomocí domén, což podporuje datovou manažerskou architekturu. Můžu si tam uložit například marketingová data, marketing a management k nim mají přístup, ale například finance ne.

Ten, kdo zná Power BI workspace, si dokáže představit, že to lze označit jako doménu a workspace lze seskupovat, delegovat oprávnění a nastavení.

To je něco navíc.

A teď je doba AI, takže přichází integrace různých kopilotů, ať už pro vývoj, nebo pro dotazování dat. Je tam možnost tzv. data agentů, což jsou „roboti“, kteří odpovídají na otázky nad lakehouse nebo semantickým modelem.

Data agent úplně nezodpoví každou otázku a za to bych ruku do ohně nedal, ale je to funkce, která Fabrik posouvá dál a bude se dále rozvíjet.

Myslím, že Fabrik přichází i s datovou vědou – což je něco, co jste označili jako výhodu zejména proto, že jste více v BI světě a tradičním.

Já jsem velmi rád, že jste dnes tady, protože díly, kde se 50krát diskutuje o agentech, jsou poslední dobou vzácné.

Platformizace přináší i pokročilou analytiku, i když to nesmíme nazvat AI nebo LLM. Mluvili jsme o Spark enginu, takže to směřuje k Databricks, který vyšel z datové vědy, z Python světa.

Naše oblast je tradiční BI, datové sklady a Power BI.

Ve Fabriku je aktivní i složka real-time intelligence, jsou tam KQL databáze a podobné nástroje.

Takže to nám umožňuje také real-time zpracování.

Zároveň jsou tam nástroje pro machine learning, integrované ve formě známého ML Studia, takže platforma je opravdu široká.

„One platform rules them all, one platform binds them.“, doufáme, že vás do temnoty nezavede.

Ještě něco?

Zní to hrozně hezky, jako „too good to be true“. Ale Power BI má svoji interní logiku, strukturu a pohled na svět, stejně tak Synapse.

Pokud to vezmu z hlediska rolí – BI specialista s reportingem a „last mile“ dat versus někdo, kdo se hrabe v datech, je nízko v ingestionu a píše ETL – jsou to dva různé pohledy.

Jak se Fabriku daří tyto dvě role spojovat?

Musíš přepínat logiku? Je to tak, že jedna část je Power BI, a já si nasadím „powerbi čepici“, a druhá část je data engineering, kdy nasadím jinou roli? Nebo je to spíše sjednocené a jen jsme vytvářeli doménové silá?

Myslím, že to je stále poněkud oddělené, ale naší rolí je to více a více propojovat.

Co dělám ve Vintexu, je právě spojovat tyto dva světy – Power BI a data engineering –, aby si vzájemně lépe rozuměli.

Power BI vývojáři, kteří vytvářejí vizualizace a modely, by měli lépe rozumět data inženýrům a naopak.

Myšlenka je, že centrem je datový model – data a co z nich můžeme vytěžit.

Myslím, že jak se dnes Power BI vyvíjí, a jak se vyvíjí backend, je těžké to spojit do jedné roviny.

Power BI bude asi mají vznikat specializované role – více zaměřené na vizualizace a více na technické aspekty.

Power BI nyní přichází s TMDL, což je přepis modelu a reportu do kódu, takže jej lze upravovat v kódu.

Je to tedy mnohem technicky náročnější než před deseti lety.

Na druhou stranu to přináší škálovatelnost a výhodu, že jakmile je model v kódu, může na něj být aplikován agent, což je současný trend.

Před asi dvěma týdny jsme pořádali hackathon, kde jsme to zkoušeli s Power BI a MCP serverem.

Je to jiný styl práce.

Potvrzuješ tedy, že to jsou dva trochu odlišné světy?

Jak je to integrované? Je to jednotné uživatelské rozhraní, které získalo „tvář“? Nebo tam cítíš tu hlubší integraci?

Co je za tou magií, aby se tyto dva světy na platformní úrovni potkaly?

UI je jednotné, ale velká přidaná hodnota je tzv. one lake.

To je také často skloňovaný pojem, ale co prakticky znamená?

Představ si, že si koupím Fabrik, mám svůj tenant, své pracovní prostředí, a to si můžu představit jako jedno velké úložiště, jeden velký data lake – one lake.

Mám tam různá workspace a je to tříděné.

Do one lake se ukládají data ze všech engine, které Fabrik nabízí – Spark, real-time KQL databáze, SQL databáze nebo Power BI direct lake storage mode.

Všechna data jsou uložena v jednotném open source formátu Delta Lake, který je znám například z Databricks, myslím, že jej vyvinuli oni.

Veškerá data jsou tedy uložená ve stejném formátu na one lake, což velmi usnadňuje práci.

Data lze s nimi jednoduše manipulovat pomocí notebooků, SQL databází – velmi rychle lze dostat data z různých engine v rámci Fabriku.

V tom je velká přidaná hodnota – jednoduchost a unifikace celkového prostředí.

Zní to opět „too good to be true“, tak co to vlastně je ta Delta?

Delta je formát, přesněji naddstavba formátu Parquet, kterou tradičně známe.

Umožňuje nad Parquet daty verzování.

Můžu se podívat, jak vypadala předchozí verze dat.

Pokud spustím update na nějakém řádku tabulky nebo sloupci a zjistím, že byl špatný, mohu velmi rychle změny vrátit zpět.

Mám přístup k historii, tzv. time travel, kdy sleduji změny dat v čase.

Je to nadstavba, která umožňuje sledovat verze dat.

Co je na tom zajímavé a co se týká Fabriku – veškerá data jsou uložena v Delta formátu, který je založený na Parquet souborech.

To znamená, že data nejsou nijak „zablokovaná“ – můžu je snadno přenášet někam jinam.

To, že původně pochází z Databricks, naznačuje, že jde o nový standard.

Můžeme to přirovnat k podobným formátům jako Snowflake Iceberg, nějaká obdoba.

Byli jsme u delty a one lake – co nám to tedy přináší?

Že je to jednotný formát, na jednom místě.

To umožňuje jednoduše sdílet data mezi týmy, platformami, workspacemi.

Mohu mít jeden jednotný workspace, jeden lakehouse, kde sedí jediná pravda.

Pomocí tzv. shortcutů mohu data zpřístupnit jiným uživatelům v jiné doméně.

Pokud dám příklad z Intexu, máme management workspace, který používáme jako lakehouse...

[Text končí zde.]

Mám v něm, já nevím, 20 tabulek, ale vím, že potřebujeme tyto tři tabulky dostat do tohoto workspace, protože tam řešíme nějaké kapacitní plánování. Ty tři tabulky tam prostě dostat, abych nemusel přesouvat data, nezačínal žádnou pipeline, nemusím vlastně nic dalšího dělat, pouze tam nastavím takzvaný shortcut, nějaký „pointer“ na ten správný soubor v mém jednotném lakehouse nebo v tom jednotném zdroji pravdy.

A to je vlastně ta governance, to je asi spojeno právě s tou governance a architekturou data mesh, kdy vlastně najednou mám řazení a organizaci, mohu to přeskočit a dávat to na domény nebo na jednotlivé týmy.

Ano, ano. A to je právě nové využití těch shortcutů, těch zkratek. Vlastně si to lze představit jako shortcuty, které známe běžně z počítače, třeba ve Windows a podobně. Funguje to úplně stejně. A pak jsou tam takzvané shortcuty, které jdou mimo ten fabrik, ale fungují velmi podobně. Já vím, že mohu nastavit takovýto shortcut na soubory na Azure Data Lakeu, nebo na S3, nebo na Google. To je super, nemusím přenášet vysloveně ta data, pokud to nepotřebuji. Data mi leží na mém S3 nebo na Data Lakeu Azure, ale já je mohu využívat a dotazovat ve fabriku.

Samozřejmě, platí se za nějaký transfer.

Jo, ok. Protože mi to zase zní jako „good to be true“, budu to pořád opakovat, chápu, že to nevyřeší všechno. Takže když se zeptám pro kontext: teď fabrik běží na kolika klientech?

V podstatě poslední rok, dva fungujeme s tím, že každý nový projekt jde na fabrik, nebo skoro každý. Máme nějaké spolupracující týmy. Celkově je těch klientů zhruba 10 až 15, které máme na fabriku.

No a říkáš, že máš zkušenost napříč. Tak v jaké chvíli píšeš ETL a vyléváš data nějakou pipeline někam jinam a v jaké chvíli ti stačí shortcut? Existuje nějaké rozhodování, nebo jak?

Shortcut zvládne i to. Určitě tam existuje více možností, jak ta data dostat. Microsoft nebo best practice říká, že pokud máš databázi, tak používáš mirroring. To je něco, co zapneš a automaticky ti synchronizuje celou databázi, nebo vybrané tabulky, v near real time do fabriku. Velmi jednoduché, snadno nastavitelné. Na pár kliků jsme to nedávno nastavovali v Snowflake u jednoho zákazníka.

Pokud je to soubor na S3 nebo Azure Storage, tak použij shortcut.

To je tedy best practice: databáze – mirroring, soubor na některé z platforem – shortcut.

Ale realita je taková, že databáze jsou různé, někde starší, špatně se nastavuje, někde nechceš dělat mirroring, protože bys to nezaplatil, někde vůbec na ta práva nepustí. A SAP? No, na poslední konferenci představený koncept submirroring, ale všichni známe SAP, takže možností je tam hodně.

Takže nějaké pipeline rozhodně nezbytně potřebujsme.

Pak jsou různé API zdroje, které často musíš stáhnout nějakým Pythonem nebo jiným kódem. Takže možností je hodně.

Přesto, v rámci základních Microsoft zdrojů se dá data do fabriku dostat jednoduše a rychle, a potom se dělá hlavně ta zábava s byznys logikou a transformacemi.

Integrace z různých systémů do fabriku je poměrně jednoduchá, je tam hodně přípojek a možností.

Co je ale čas use case, který řešíme se zákazníky, je to, že uživatel reportu chce zadat nějakou informaci přímo v reálném čase z reportu. Například dívám se na nějaká data, na nějaký budget, a chci k tomu zadat úpravu, komentář nebo něco podobného.

To je zase něco nového ve fabriku a Power BI.

Existuje nástroj Translytical Taskflow přímo v Power BI, který využívá funkci User Data Function ve fabriku, což je Pythonový kód, který se velmi jednoduše spustí přímo z Power BI.

Tím se otevírá možnost zadávat jednoduché úpravy, komentáře a pracovat s daty v reálném čase přímo z reportu.

Mám zpětnou vazbu od koncového uživatele nebo reportera.

Je to skvělé.

Co se zatím používalo, nebo co má stále své místo, jsou Power Appky, které se dají integrovat do Power BI reportu.

Samozřejmě je to vyvinutá technologie, která funguje dobře, ale potřebuje licenci.

Pro jednoduché use casy je toto nyní velmi efektivní.

Ve fabriku přidali tradiční SQL databázi, známou jako ZHRU, což je rychlé, transakční, podporuje procesy a není to nějaký složitý engine s Deltou, ale tradiční databáze.

To je něco „cool“, co fabrik posouvá na vyšší úroveň v kontextu s Power BI.

Mám plnohodnotnou datovou platformu, zdrojové systémy, reporting a interakci zpět s uživatelem.

Super.

Vidím to jako sign-upy na steroidech, integraci na všechno ostatní, co se týká Power BI.

Když se podívám na historii posledních let, měl jsem pocit, že z Power BI, původně čistě vizualizačního nástroje, se stává platforma.

V Power BI dělají data inženýři, a vy jste byli známi například MDX a dalšími věcmi.

Posouvá se to z prezentace, jak PowerPoint na steroidech, na SQL platformu, která může škálovat, má CICD a další věci.

Jak vidíš budoucnost Power BI?

Když Power BI přineslo věci ze spodní části stacku, a Signups věci z vrchní části, teď se potkali uprostřed a vznikl Fabric, při tom byly změny v licencování.

Kde je dobré používat Fabric, když používám Power BI?

Takže ta původní otázka, co to znamená pro Power BI.

Power BI má své nezastupitelné místo – je to vizualizační nástroj, velmi jednoduchý a intuitivní k používání.

Pokud mám malý objem dat, nepotřebuji komplexní logiku, nepotřebuji snapshotování, tak Power BI je pořád výborný a v Power Query se dají dělat zajímavé věci.

Na co být opatrný?

Když to začne být velmi komplexní, hodně dat, příprava náročná, pak je lepší přesunout to na backend, do databáze, do lakehouse nebo někam, kde Fabric nabízí možnosti.

Takže data připravím na backendu a Power BI používám jen pro vizualizaci a reporting.

S tím přichází riziko, protože když zapnu všechno a všechno mi běží na jedné Fabric kapacitě, kterou mám koupenou, tak máš jeden výpočetní výkon.

Výpočetní operace v Power Query, ať už v Power BI nebo v Dataflows Gen 2, jsou výpočetně náročné.

Tolik je trik ve Fabricu: spravovat to, udržovat, aby to krásně fungovalo, nesekalo se.

Takže to je největší výzva projektů Fabric.

Je velmi jednoduché něco udělat rychle, něco dodat, ale udělat to tak, aby výkon kapacity stačil, to je výzva.

Máte nějaké tipy a triky, co jste se naučili u klientů?

Když přijde nový kolega s Fabric, ale je zvyklý na jiné datové řešení, jsou nějaké workarounds nebo něco, co ty sleduješ první?

Nejčastější věc je sledovat monitoring platformy.

Fabric je SaaS, tak si ho koupíš jako celek, vše je tam, nic ti nebrání to používat.

Proto je monitoring velice důležitý.

Říkáme každému novému developerovi či zákazníkovi, aby hned nainstaloval monitoring aplikaci, což je Power BI report postavený na datech z fabriky.

Vidíš, co kolik stojí, který notebook kolik výpočetního výkonu spotřebuje, která pipeline kolik, který report kolik, který dataset kolik.

Takže věnovat tomu pozornost a naučit se to číst.

A když jsi viděl spoustu těch monitoringů, jsou pro tebe nějaká překvapení, antipatterny, co jsi dříve optimalizoval?

My to máme jako rýč, protože byl levnější.

Vidím trade-off: když děláš standard, vše je přístupné, děláš mirroring, tak vidíš ty dolary.

Dřív jsme si dělali "cestičky" a tahali data, teď to hodíš všechno na jednu hromadu, zpracujeme jakýkoliv datový typ a přeložíme.

Ale to je výpočet, to všechno stojí, stejně jako verzování dat, to je storage.

Někde je cena.

Dostal jsi dobře tu podstatu, že ve Fabricu, když si ho zajišťuješ, kupuješ kapacitu, což je výpočetní výkon – tedy compute – pod kterým je spousta věcí.

Storage se platí zvlášť.

Někdy se říká, že storage je levný, ale nemusí to tak být.

Přidaná hodnota Fabricu je kapacita, propojení s Power BI, front-endem, jednoduchost, hodně no-code nástrojů převzatých z Power BI, jako Dataflow Gen 2.

Takže je to jednoduché, rychlé, ale dražší.

Typický úzký hrdlo, které řešíme u každého zákazníka, je Excel na SharePointu, odkud potřebují dostat data.

Měřili jsme, když použiju Power Query, kde je skvělý konektor, připojím se, udělám malé transformace, mám to rychle hotové a funguje to velmi jednoduše.

Pokud to udělám pomocí kódu nebo složitějšího nastavení, třeba copy activity v pipeline Data Factory, ušetří to možná více než polovinu kapacity.

Takže pokud mám stovky takových zdrojů, přecházíme k vlastnímu kódu.

O to důležitější je governance: nenechat se uvázat na jednu kapacitu, mít oddělenou kapacitu na produkci a test, a pokud je kritický workload, zvlášť kapacitu.

A možnosti jsou velké: zapínat, vypínat, škálovat.

To přináší mnoho možností, ale je potřeba si na to dát pozor.

Předpokládám, že defaultně je to – můžeš všechno, je to magie, ale drahé.

Přesně tak.

Rychlá Proof of Concept funguje hezky, rychle doručíš, ale pak se musíš vracet a dívat na jednotlivé části a přepracovávat je.

Také bych zmínil fungování Fabric komunity, což je komunita kolem Fabricu a Power BI.

Vzniká hodně nástrojů na monitorování, sledování a vyhodnocování.

Nejznámější je asi FUAM, nástroj vyvinutý zaměstnanci Microsoftu nebo jako side project, který nasadíš notebookem s oprávněními a monitoruje celý fabrik a spotřebu.

Pokud jde o viditelnost nákladů, jedna z velkých kritik Fabricu byla, že nikdo neví, kolik to stojí, všichni to mají zdarma, ale jednou začne platit.

To se změnilo, už jsi schopný odhadovat a manipulovat s cenou.

Samozřejmě je to složité, záleží na mnoha faktorech.

Fabric stále má trial, a člověk nikdy přesně neví, kdy skončí.

Mnoho zákazníků přešlo na placenou verzi, někteří tam jsou i přes rok a půl.

Pokud jde o tradiční pořízení, koupit a podobně, existují možnosti, jak to odhadnout.

Existuje pricing kalkulátor, kam zadáš počet CSO uživatelů, analytiků, jaký engine používáš (Spark, custom apod.).

Je to odhad, protože nevíš, kolik ti uživatelé skutečně pošlou dotazů a v jaké kvalitě.

My máme 10–15 projektů za sebou, takže máme v hlavě know-how, jak to běžně vypadá.

Platíš compute a storage klasicky.

Jsou tam aspekty jako seeds a podobně, jde o kombinovaný pricing, platíš hlavně za výkon.

To je to tajemství.

Kupuješ kapacitní jednotky, které se jmenují F2, F4, až třeba F1024.

To číslo označuje počet kapacitních jednotek dostupných za sekundu, což je tvůj výpočetní výkon.

Jsou dva modely: PSUGO, kde platíš za to, co spotřebuješ, a rezervovaný, kdy si koupíš kapacitu na rok, dostaneš 40 % slevu a máš to levnější.

Navíc můžeš škálovat z F2 na F4 a platíš za nadlimitní spotřebu dražší sazbou, ale nejsi zamčený.

Jde to flexibilně.

Je to ale složité.

Do toho vstupuje ještě bursting and smoothing.

To znamená, že když pošleš výpočetně náročnější dotaz, než kolik máš zakoupenou kapacitu, například dotaz potřebuje 1000 jednotek, ale máš jen 500, fabrik to zvedne a „půjčí si“ těch dalších 500 z budoucnosti.

Postupně v následujících 24 hodinách, když workload klesne, se tato půjčená kapacita „dohání“.

V tom je ten trik.

Zní to dobře, protože umožňuje, že když interaguji s reportem, tak —

Bože, když tam běží to ETL nebo něco podobného, tak mi to pěkně běží. Pokud si však načerpám velké množství těch jednotek z budoucnosti, může se mi stát, že mi to ke konci dne přestane fungovat. Už se to zastaví a jednoduše řekne: ty už sis načerpal svůj objem. To je vlastně častý problém, který se vyskytuje a je třeba se s ním naučit pracovat - buď restartovat tu kapacitu, což ovšem něco stojí, nebo ji dočasně zvýšit, či něco podobného. A pak tu máme pojem bursting a smoothing. Bursting je onen peak, tedy nárazový nárůst, a smoothing je vyčerpávání budoucnosti.

Je to velmi zajímavý koncept, který je těžko pochopitelný a uchopitelný, když s tím chceš prakticky pracovat a vlastně ladit tu platformu. Nikdo přece nechce preventivně platit například za 128 jednotek kapacity, když mu stačí jen 64.

Ve vztahu k Power BI, co jsem odkukal a zaslechl, tak ty nejvyšší licence Power BI mají nějakou expiraci a vše se prodává přes Fabric. Licencování Power BI je vlastně poměrně jednoduché, řekl bych. Máš Power BI Pro licenci, která stojí asi 14 dolarů, pokud se nemýlím, a pak máš Power BI Premium per user licenci, která stojí okolo 25 až 28 dolarů. Navíc bylo možné zakoupit Power BI Premium kapacitu, což byla vyhrazená výpočetní kapacita, kterou sis koupil. To už nyní není, ale můžeš si pořídit kapacitu Fabric.

Takže oni to vlastně pouze překlopili. V souvislosti s Fabricem je zajímavé, že Premium se láme na měsíční jednotku F64. Proč je to důležité? Pokud mám nižší kapacitu než F64, potřebuji pro používání Power BI uvnitř Fabricu ještě i Power BI Pro licenci. Tudíž si ji musím dokoupit. Pro každého uživatele, který chce report číst, potřebuji i tuto licenci.

Pokud jsem na F64 a vyšší, potřebuji Power BI Pro licenci pouze pro ty, kteří ty reporty tvoří – tedy pro buildery. Pro ostatní uživatele stačí licence Free, kterou bych nyní nazval Fabric Free licence.

Když se zeptám, vím, že to závisí, ale jak velké firmy mají zakoupenou licenci F64? Dej mi anonymizovaný příklad firmy, která má F64 zakoupenou. Bylo to okolo 500 uživatelů, u kterých se to láme. Pokud tam mám zhruba 500 uživatelů, často se to už vyplatí – máte F64 Free licenci a předtím se vyplatilo platit zvlášť licence.

Podle toho, jak o tom mluvíš, to zní, že nejenom z poklesajících nákladů, ale i nějakou částí příjmů Power BI, pokud ne úplně funkčně, tak abychom byli féroví. Pro koho je podle tebe Fabric? Mám pocit, že Databricks byly hodně "heavy weight", úzká skupina, musel jsi být velmi pokročilý. To samé platí pro Snowflake. Teď, když mluvíš o Fabricu, připadá mi více demokratizovaný, že nůžky jsou širší a zasahuje více do světa Power BI a jeho uživatelů.

Tak komu bys doporučil používat Fabric?

Z mého pohledu je Fabric v podstatě pro kohokoliv. Pokud někdo nevyžaduje opravdu nějakou obrovskou platformu, kde si může nastavit každý detail svého výpočetního výkonu toho clusteru, například z parku ve světě data engineeringu, ale stačí mu jednodušší přehled a dostupnost začít něco dělat, tak Fabric je pro kohokoliv.

Můžeš si zapnout trial, máš hned všechny možnosti Fabricu k dispozici – všechny služby, všechny funkce, které si můžeš zapnout a začít zkoušet. Zda jsi malá firma, kde si zapneš nějakou F2 kapacitu, ten nízký tier, který v rezervované hodnotě stojí třeba 130 nebo 150 dolarů měsíčně po trialu, nebo velká firma, kde máš třeba několik kapacit, tak si najdeš to svoje.

Jestli jsi data inženýr, napíšeš si Sparkový kód, komplexní transformace, nebo jsi Power BI reportbuilder či data scientist a děláš nějaké machine learningové modely – určitě si tam najdeš své.

Určitě je to pro každého, stačí zapnout dvěma kliky, vyzkoušet a uvidíš, jestli ti to sedí nebo ne.

Navíc mě baví, že jsi tak zavřený v Microsoft stacku, že to fakt je pro mě a pro tebe Fabric tak velké téma, že je to goliáš, který vstupuje na trh. Zatímco v minulosti jsme řešili jednotlivé platformy a Databricks proti Snowflake byla velká debata, mám pocit, že přichází třetí hráč, který má potenciál je sfouknout jako svíčku.

Nevím, jestli je úplně sfoukne, ale určitě, jak jsi říkal, že nejsi zamčený v jednom světě, myslím, že to je trend – datové platformy spolu budou dobře spolupracovat a fungovat, a že už je to vidět.

Je to například mirroring ze Snowflake, nebo podobné věci, spolupráce s S3, s AWS, nebo s nějakými nástroji Databricks přes Deltu a podobně. To je supervěc, protože cloudové platformy spolu komunikují.

Co si přeješ, aby Fabric dodělal v příštím období? Co ti tam ještě chybí a na co se mohou běžní uživatelé Fabricu těšit?

Mně velmi chybělo API a další věci, které doplnili, pro vývojářskou práci, pro větší zralost platformy – takové drobnosti, které mě potěší při každodenní práci.

Například velmi dlouho je v preview funkce databázových schémat v Lake House a je to už asi rok nebo rok a půl a já pořád čekám, kdy se to z preview dostane do GA.

To je moje vysněné, že se to jednou povede.

Ale myslím, že to jsou spíše drobnosti z těch větších věcí. Třeba ještě doladění datových agentů a podobných funkcí, aby to bylo spolehlivější, ale to už není otázka Fabricu, ale obecně datových sad.

A já ti přeju, aby se nejen toto, ale i tvá další přání ohledně datových platforem a tvé práce splnila.

Děkuji moc, Kubo, že jsi nám udělal takový deep dive do fenoménu Fabricu a trochu mi napravil ten obrázek, který jsem měl – přestože je to stále z velké části v preview, podle toho, co říkáš, je to dospělá platforma.

Myslím, že by měla dostávat větší pozornost nejen z pohledu datových profesionálů v Microsoft stacku, ale celého trhu.

A tady v naší kotlině si myslím, že i dalších datových stack řešení, protože prostor v moderních datových stackech se zužuje díky Fabricu.

Moc ti děkuji, těším se na další update a kam se posunete. Držím palce.

Děkujeme, že jste doposlouchali až sem, a děkujeme i našim partnerům – členům Data Talk klubu: Intex, Saska, Bystreet, Colors of Data, Revolt BI, Good Data, Kebula, Emark, Carl Data Company, Datamind, Notino a Flo.

A 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.