Podcast

Dobrý den, vítám vás u historicky prvního dílu podcastu Czech Fabrik. Mé jméno je Štěpán Rešel a se mnou je tady Jirka Vicherek. Ahoj všem!

Tak jo, Czech Fabrik podcast. Jirko, jsme tady společně a nahráváme podcast o Fabriku, podle všeho. Hele, o čem to bude? Důležité je říct, že mým snem bylo, aby Datatalk byla televize. To znamená, že jsem nikdy nechtěl, aby Datatalk byly rozhovory se mnou a hosty, přestože hostů jako je zrovna Štěpán si moc vážím a myslím, že je to super. Vždycky jsem však doufal, že se najdou další nadšenci, kteří pod Datatalkem budou tvořit vlastní podcasty. A tak jsme se domluvili se Štěpánem, který je tady přední odborník na Microsoft Data Stechy a nově Fabrik, MVPčko a všechny další štemplíky. Prosím vás, jenom bych chtěl říct, že MVP v tomhle kontextu neznamená minimální dopravu dat. Děkuju. Znamená to Most Valuable Player, tak jako Michael Jordan, sbíráme trofeje a tak, něco takového, ale v Microsoftním světě. Takže Štěpán je OG a když jsem měl Štěpána jako hosta, byla to skvělá epizoda a řekl jsem si, že takových epizod můžeme mít víc. A vzhledem k tomu, jak je Fabrik obrovské téma a jak teď jede, jsme se se Štěpánem domluvili, že uděláme speciální pořad, který bude vést hlavně Štěpán a já tady budu spíše na něj koukat a klást hloupé otázky. Budeme vám rekapitulovat největší změny ve Fabriku, co se udály, budeme se dívat dopředu, přinášet Štěpánův pohled a dávat vám praktické know-how, jak s Fabrikem správně a efektivně zacházet. No a protože toto je první díl, bude speciální. Vezmeme si velké sousto, a to změny a novinky za celý rok 2025. Štěpáne, když začneme shora, rok 2025 ve Fabriku – nějaké shrnutí, něco jako executive summary, než se vrhneme opravdu do kódu, do jednotlivých funkcí a půjdeme hodně do hloubky, kde už mě možná ztratíš. Takže na té vysoké úrovni – co znamenal rok 2025 pro Fabrik?

Já bych možná ještě než začnu hnedka mluvit o roce 2025, rád bych se ohlédl za rokem 2024, kdy vlastně Fabrik přišel do GA na úplném konci roku. GA v tomhle kontextu znamená General Availability, což znamená, že Microsoft má hotovou podporu a je schopen reagovat, když se něco pokazí. Vždycky se něco pokazí, známe to. A teď to není jen problém Microsoftu, ale obecně. Fabrik přišel v podstatě do GA a tím začal rok 2025. Mluvíme o tom, že se Fabrik začal naplno objevovat. Už se s tím nehraje jen pár nadšenců, ale firmy to začínají mnohem víc objevovat a ponořovat se do toho. Je to pro ně čím dál zajímavější, což je skvělé. Lidé začali víc experimentovat s tělovými licencemi, které jsme v průběhu roku prakticky ztratili, takže peníze začaly proudit směrem k Microsoftu. V rámci toho došlo k extrémním změnám, které nám umožnily vymanit se z funkcí, do kterých jsme byli dříve tlačeni, které byly relativně dost drahé. Teď je můžeme využívat mnohem efektivněji a levněji. Zjistili jsme, že i nízké kapacity, na které jsme se sice dříve spoléhali…

[Pokračování by bylo potřeba, aby text byl úplný.]

Zde je opravený a upravený text:

Koukali jsme se na to a zdálo se, že by to mohla být sranda. Jsou vlastně extrémně výkonné a jsme schopni na nich pracovat extrémně dlouho, dokonce i velké firmy. Takže z mého pohledu na různé zdroje, které slýchávám, tak rok 2024 byl spíše demo, public beta, něco jako preview. Koncem roku 2024 to začnou oficiálně zavádět a v roce 2025 už to bude plnohodnotná, dospělá platforma. Samozřejmě stále ve vývoji, dynamická, ale už to bude tady. Podobně bych to zarámoval – rok 2025 byl tím rokem, kdy technologie přestala dělat dětské krůčky, začala reálně fungovat, běhat a zjišťovat, co dalšího by si mohla do své platformy přidat na základě požadavků uživatelů.

Dokonce i inženýři, které si Microsoft náhodně najal z různých koutů světa, začali dávat zpětnou vazbu – říkali, co by bylo potřeba předělat, aby to bylo mnohem funkčnější. Tyto změny a úpravy se prováděly opravdu velmi rychle. Pojďme se tedy podívat na ty hlavní věci. Kde začneme? Co je pro tebe nejdůležitější?

Za mě jeden z klíčových přínosů roku 2025 je rozhodně podpora čistých Pythonových notebooků. Žádný PySpark, žádná potřeba používat mashup engine pro Power Query nebo data flow, žádná nutnost vždycky sahat po copy aktivitě v Data Factory, ale čistý, krásný Python. To byla pro mě ta největší změna za poslední rok ve fabriku. Jasně, bylo tu toho více, ale právě toto znamenalo, že spotřeba našich CPU, které jsou ve fabriku klíčové a za které platíme, mohla jít výrazně dolů.

Předtím, když jsem spouštěl PySpark, musel jsem často u F2 nebo F4 kapacit zvyšovat výkon – automaticky si „půjčoval“ kapacitu dopředu. To pro PSUGOU modely fabriku nebylo ideální, protože ty platí za celé dny, i když je potřebujete třeba jen na hodinu. To není úplně to, co by si člověk přál, když chce, aby výkon běžel třeba jen jednu hodinu denně. A často to nebylo efektivní.

Na rozdíl od toho mají Pythonové notebooky relativně striktní výchozí konfiguraci – startujete s 16 GB RAM a dvěma jádry a můžete s tím dělat, co chcete. To znamená, že to bude stát přesně jednu jednotku CV. To je skvělé, protože víte, že každá vteřina běhu takového notebooku vás stojí právě jednu jednotku CV. Samozřejmě můžete konfiguraci upravovat, zvýšit nebo snížit výkon, ale standardně, pokud toho moc nebudete měnit, zapnete to na hodinu, po té hodině to vypnete a zaplatíte přesně jednu hodinu. To je skvělé.

Navíc jsou předinstalované spousty užitečných základních knihoven. Nemluvím jen o Pandas – to je dnes už samozřejmost – ale rovnou tam máte například Polars, DuckDB, prostě základní nástroje pro tyto transformace, vše předpřipravené. Můžete to vzít a rovnou začít pracovat, plug and play.

Pokud chceš, mohu text ještě upravit nebo zestručnit podle potřeby.

Jasně, tady je opravený text:

Notebooku, jasně, všichni, co známe Databricks a jeho PySparkové notebooky, víme, že spin-up trvá zhruba 15 minut. PySparkové notebooky ve Fabriku spin-upují v defaultní konfiguraci do minuty, protože Microsoft vás postupně přepojí na aktuálně volné servery, takže to prakticky běží nonstop a fakticky ho takto nečekáte. Pokud máte custom konfiguraci, čekáte opět stejně jako kdekoliv jinde.

No a Python? Lusk. Stačí lusknout prsty a všechno vám běží okamžitě. To je skvělé. Tudíž overhead čekání je prakticky nulový, čekací doby výrazně klesly a já mám možnost dělat úplně cokoliv, co potřebuji. A to by bylo ono.

Je to tak moc powerful, že vás to nechá dělat i věci, které byste neměli dělat. Já si v PySparku dokonce renderoval videa, vedle toho jsem zkusil rozchodit Doom a zahrát si trochu střílečku. A vzhledem k tomu, že to podporuje úplně všechno, můžeme tam dělat jakékoliv blbiny.

A ono je to vlastně takový jeho seed můstek, který mi pomáhá teď ukázat ještě jednu věc. Zmínil jsem, že PySpark nás tady dost stál. V rámci roku 25 byla zavedena jedna skvělá novinka, která minulý týden dostala další update a posouvá se pořád dál. Jmenuje se to Search Protection, což je věc, která umožňuje nastavit, kam maximálně se v rámci své kapacity chci dostat u backgroundových a interaktivních operací. Znamená to, že můžete zajistit, aby backendové operace nevyhodily všechny reporty.

Sice jsme nyní v roce 25 dostali jen procentuální nastavení, tedy řeknete maximálně 60 % kapacity, což zatím není úplné vítězství, ale je to krok dopředu. Před týdnem byl vydán update, který umožňuje nastavit to na úrovni workspace – tedy workspace může brát maximálně určitou kapacitu. To je výrazný posun, protože jsme na to ještě z privátní bety čekali: potřebujete workspace s velkými loady, které musí být garantované, aby vám neběželo všechno ostatní na úkor těchto úloh. Nebo naopak, řeknete workspace s nízkou prioritou může mít třeba maximálně 5 % kapacity, a ostatní workspace si mohou brát zbytek. Najednou jsou kapacity mnohem lépe delegovatelné a nemusíte mít jich hromadu.

Krásně tyto dvě věci přišly ve stejném měsíci, ve stejném čase, potkaly se a začaly koexistovat. Bavíme se o lednu a únoru, kdy tyto novinky přišly, protože v březnu přišel Fabcon – velká událost, kterou fabrikový marketingový tým označil za největší událost roku. Konalo se to v Las Vegas, pak i tady v Evropě. Letos bude mimochodem v Los Angeles, myslím, že zase v březnu…

Opravený text:

Je zase podzim tady v Evropě a já se těším, že nám z Fabconu, ať už to bude v Los Angeles nebo kdekoliv jinde, přineseš novinky. Když ještě zůstanu u search protection a těch Pythonových notebooků, můžeš dát ještě jeden příklad, jak to řešení fungovalo dřív, co to znamenalo a jak jste to přepnuli?

Jo, hele, příchod čistých Pythonových notebooků pro nás znamenal, že jsme celý náš framework, který jsme na fabriky měli postavený, vzali a kompletně přestavěli. Najednou jsme šli zhruba z 100 CUček na 5. Ten pokles byl extrémní.

A co znamenalo to mezi tím? Třeba napsat celou kódovou bázi v Pythonu?

My jsme ji původně měli v PySparku, orientovanou na Spark. Takže jsme ji kompletně přepsali do čistého Pythonu. Respektive jsme využili Polaris pro interní účely, protože bylo velmi jednoduché učit lidi, kteří měli zkušenosti s PySparkem, používat Polaris. Má totiž strašně podobnou syntax, je to velmi obdobné.

Já osobně mám fakt rád DuckDB. Práce s ním je neskutečná zábava a dokáže opravdu skvělé věci. Rád ukazuju třeba tenhle příklad: používali jsme nějaké monitorovací řešení, kde jedna transformace mohla běžet až hodinu, protože parsovala opravdu rozsáhlé logy s asi 1500 různými atributy na 400 různých rekordových variantách. Tak hodina ještě dobrý?

Jo, jasně.

Když víš, že PySpark je silně typovaný, tak si nemůžeš dovolit tam dát obrovské datové množství bez správného typování. DuckDB tě ale nechá dělat, co chceš, tak jsem to do něj přepsal a z běhové doby hodiny jsem se dostal na 3 minuty a 12 sekund, přičemž šlo o úplně to samé, navíc úplně dynamické — bez starosti, co do toho přijde.

Jakmile toto přišlo, otevřel jsem flašku šampusu a oslavil jsem to, bylo to super.

A ohledně search protection, jak jste to implementovali? Mluvil jsi o nějakých modelových řešeních, jak se to dalo využít? Máš nějaký konkrétní příklad?

Reálný příklad je takový, že jsme primárně řídili rozdělení, jaké množství prostředků může vzít každá jednotlivá interaktivní background operace. To je totiž strašně důležité.

Proč to říkám? Když mám semantický model v Power BI a někdo má napsaný nějaký DAX, tak DAX je nejvíc náročný engine, který máme na CUčka. Myslím, že mluvíme o stovkách procent využití, ale stačí drobná chyba nebo ne úplně ideálně napsaný model a DAX vám umí okamžitě vystřelit využití až na 20 000 % kapacity.

Proč? Protože engine pod sebou provádí velké množství operací, jde o relativně složitý rozklad dotazu. Ten engine nemá stejné optimalizace jako třeba SQL server. Je to soubor pravidel, která se musí dodržovat, jinak to může způsobit totální chaos.

Nedej bože, pokud běžný uživatel otevře report a report začne renderovat stránku. Na té stránce se renderují vizuály po čtyřech… (text končí).

Pokud chceš, můžu ti pomoci i s pokračováním nebo jinými úpravami.

Jasně, tady je opravený text s úpravou pravopisu, stylistiky a plynulosti:

Narážíme na to, že se dotazujeme na data a generují se DAXové dotazy, které se posílají a vrací zpět výsledky. A teď se takhle celá stránka narenderuje, uživatel přijde a řekne, že chce vidět Frantovu omáčku. Vybere si ji a všechny vizuály vygenerují nový DAXový dotaz. A takhle se to tam pořád posílá. Nedej bože, když uživatel kliká, protože vlastně neví, co chce vidět. A najednou v monitoringu vidíš, jak kapacita vystřelila do extrému, přichází šíleně velké zatížení.

Manažerská zpráva je, že nic neběží, protože Fabric má nějaký throttling a ochranu, abyste nepřečerpal Microsoftí kreditku. V tu chvíli je to skvělý nástroj, protože to prostě omezíš. Řekneš: nepojede to teď dál. Tím pádem to spadne do čekání a uživatel odpověď nedostane okamžitě, ale o chvilku později. Ale zároveň si tím zachráníš svůj load a náběh warehouse, což je kriticky důležité. Skvělé, děkuji, že jsi to dal takhle do kontextu. Pojďme dál.

Python notebooky, search protection.

Ano, to bych zmínil – na Fabricu byla znovu představena jedna věc, která úzce souvisí s čistým Pythonovým notebookem, a to jsou user data functions. User data functions jsou v podstatě čistý Pythonový kód. Aby toho nebylo málo, ale jsou udělané tak, že si tam předpřipravíš jednotlivé funkce, které se mohou exekuovat, a uživatel je pak může spouštět.

A tady je právě krásné, k čemu to vlastně je. Teď mám ty notebooky. Jasně, za prvé si můžeme říct, že podle různých přístupů notebooky nemají na produkci co dělat, ale že je tam většina z nás má, je věc druhá. My taky, co si budem. Říkám – to je jeden přístup, ne dogma, kterého bych se chtěl držet.

Tyto functions vznikly pro jednu feature, která byla v Power BI žádána od samého začátku – writeback, schopnost zapisovat zpátky. User data functions mají totiž přímou integraci do Power BI reportu, kde do nich můžete odesílat data podle parametrů, které máte nadefinované v data function a které jste si propustili do Power BI. Namapujete na to jednotlivé vizuály – třeba textový search slicer, dropdown nebo cokoliv jiného, a pak jen kliknete na run.

V Power BI se ta funkce zavolá, předá jí zadané hodnoty, provede se daná akce (například zápis do databáze) a může přijít i refresh vašeho reportu. Takže když chcete mít možnost si postavit vlastní writeback, nebo bezpečnou verzi Power BI pro ovlivňování jednotlivých procesů ve firmě, je to moc silný nástroj.

Prakticky to funguje tak, že máte Power BI frontend, kliknete na tlačítko a data se propíší do databáze a vše proběhne automaticky. Takže Power BI slouží jako frontend automatizace.

Ano, přesně tak. Příklad třeba z našeho prostředí je…

Pokud chceš, mohu opravit i dalších částí nebo celý text ještě více upravit do formálnější podoby.

Tady je opravený text s upravenou gramatikou, interpunkcí a stylistikou:

My jsme se s tím relativně hodně hráli, takže je třeba řešit budget. Každá doména má svůj vlastní budget, nebo každý manažer má svůj budget. A jednou za čas se provádí nějaký budget review, jako v každé jiné společnosti. V rámci toho se pak vyplní nějaké texty, případně se vezmou nějaká KPIčka, která jsou ale spočítaná přímo v tom reportu.

A teď, když to chceš jenom vzít a dát na nějaké centrální místo, aby to bylo sloučené, tak uživatel pracuje s tím reportem tak jako tak, protože kontroluje, na co vlastně ten budget čerpá a ví, kolik ho má. Pak se přidá další stránka, kde se automaticky načtou jeho KPI, které tam jsou potřeba. On si vyplní statusy, které byly, a klikne jenom na „send“. A to přijde finančnímu oddělení ke kontrole.

My jsme to namapovali tak, že se ještě do Teams poslala zpráva: „Hele, poslal jsem ti review.“ A tím se uživateli strašně zkrátilo, kam všude musí chodit a co všechno musí vyplňovat. Nemusel už nic tahat z Power BI, nikam to dávat, nebo tam počítat. Přesně tak, pak to dá zpět do Power BI.

V podstatě ano, ono se to tam vlastně vracelo, protože finanční oddělení to vzalo, přepsalo hodnoty, uložilo do databáze a další den to ten člověk viděl aktualizované. Takže to není denní zdržení, reálně je to jen pár kliknutí a máš vyřešený, optimalizovaný proces.

Jeden z velkých problémů pro uživatele je, že musí přepínat kontext, když chodí mezi aplikacemi. Proč jim to nedat na jedno místo? A právě tady je to přesně ten případ, který k tomu láká. Viděl jsem už různé bizarní řešení, které se s tím daly udělat.

Například někdo si v Power BI rozchodil Snajka. Power BI jako report renderoval Snajka a on si pomocí tlačítek volal user data functions a měnil směr zobrazení. Myslel jsem, že mám Doom na notebooku jako cool, ale Snajka v Power BI? Kam to povede? Platformy zase…

Do Pokémonů, to jsem měl.

Dobře, ale třeba z pohledu lakehouse by to znamenalo, že mám přístup všude, když jsem tam na CWIte. Další možnost je založit schémata a jenom SQL způsobem garantovat přístupová práva. Paráda, takže už máme jeden, dva, tři způsoby.

Ale já jsem vývojář a potřebuji sáhnout právě třeba na data v lakehouse. To znamená, že potřebuji přistupovat k delta parketám, které se tam válej. To ale není úplně triviální, protože se tam pravděpodobně nepřipojím přes SQL endpoint. Půjdu přes souborovou strukturu a přistoupím přes ABFS.

A to už není úplně triviální vyřešit. A v ten moment začalo rezonovat jedno velmi důležité jméno.

Když byl FABRIC úplně na začátku oznámen, zaznělo tam slovo One Security. Znělo tam One Lake, One Security a pár dalších podobných výrazů… No, to je asi tak, jako když Microsoft měl ve zvyku všem rvát „Power“, tady se rvá „One“. Hlavně One Direction uváděli ve Sphere.

Nakonec z toho vyšlo Unity, doslova.

A o co tady jde, je to, že…

Pokud chceš, mohu text dále upravit nebo zestručnit.

Jistě, tady je opravený text:

One Security je od začátku promyšlený. Teď zase jako One Lake Security, tak bych to začal a rozdělil takto:

Je to zamešlené tak, že mám možnost řídit oprávnění výhradně nad daty, která vstupují do fabriky a která by měla být přístupná. Replikuju tím slova, která byla řečena už dříve – propagovaná skrz celý datový životní cyklus, i v různých workspaces a různých itemech na konkrétní uživatele.

To znamená, že za předpokladu, že chci omezit uživatelům přístup k datům, mohu to udělat jednou a vše se to automaticky zapropaguje. Je to strašně hezká myšlenka, ale není úplně jednoduché ji implementovat.

Je to jeden z důvodů, proč to trvalo tak dlouho, než jsme se k tomu vůbec dostali. Minulý rok to ale přineslo poměrně dost změn, protože jsme získali specifické read access, a dokonce i read-write access do určitého formátu.

Ještě sice ne tak, že by to bylo zapropagováno skrz celý životní cyklus, ale už jen samotná možnost si například vzít PySpark, připojit se na Lakehouse a pracovat s daty, ke kterým mám oprávnění, je obrovský posun.

V rámci One Lake Security teď můžu nadefinovat, kam vývojář může přistupovat, a přímo do těch dat vložit RLS (Row-Level Security), dát tam OLS (Object-Level Security) a zámkovat tabulky.

To je opravdu silný game changer, protože aby toto mohlo fungovat, jakmile nastavím bezpečnost nad file storage (například přes OBFS) a můj nástroj se to snaží použít, musí být jasné, jak se chování bude realizovat.

Funguje to tak, že se spustí nový Linuxový server, který přijme požadavky na oprávnění, vezme data, rozřezává je na příslušné složky, které uživatel smí mít dostupné, a temporérně vytvoří přímý tunel pouze proti té rozřezané části dat.

Takže já jako inženýr skutečně vidím jen průřez mých dat s danými oprávněními a nakonec pouze deploynu.

Při deployi se všechny změny aplikují s těmito omezeními.

Je to velmi zajímavý koncept, protože pokud se bavíme o bezpečnosti, umožňuje to vytvořit opravdu secure prostředí, kde vývojář nemůže vidět všechna data, ale pracuje jen s omezeným vzorkem, který mu byl určen. Na tomto vzorku může připravit a odladit transformace a potom jen provedou deploy.

Celkově někdo má plná oprávnění, ale není schopný deploynout všechna data najednou.

Pokud to shrnu, říkáš, že to funguje na úrovni fyzických souborů, tedy na baseline úrovni, ne pouze v metadatech nebo ve vrstvách nad nimi.

Když jsem se ptal, jestli se data nejdříve načítají celá a pak se osekávají, tak ne – server přímo nabírá jen data, ke kterým mám oprávnění, což představuje efektivní optimalizaci.

Navíc jsi zdůraznil, že protože to je na fyzické úrovni, může se bezpečnost aplikovat efektivně přímo na zdrojová data.

Předtím se oprávnění nastavovala spíše z výšky, přes uživatelské rozhraní nebo metadata, ale teď je to dosaženo tímto nízkoúrovňovým přístupem.

Pokud chceš, mohu upravit i další část, která byla nedopsaná.

Opravený text:

Dá se říct, že to dělám spíš shora. Ale realita je taková, že to implementujeme mnohonásobně hlouběji. Dokonce tady samozřejmě bylo spousta vtipálků, kteří si řekli: „Hele, máme One Lake Explorer. To je prostě jako OneDrive, který si nainstaluji jako desktop a najednou vidím všechny soubory na něm. Tak to zkusím, ne?“ Otevřu si One Lake Explorer, jdu na tu tabulku a ono mi už při pokusu o přístup vyhodí error, že to nejde. Protože ta data sice vypadají, že tam jsou, ale fyzicky jsou celá složka obalená a já se tam nedostanu. Musím jít v tu chvíli popsanou bezpečnou cestou, abych se k nim dostal, což je strašně super. Pro mě je to extrémní vylepšení.

A ještě se to dobře prohlubuje. Tohle má být mnohonásobně něco jiného.

Když se bavíme o tom, že vlastně začínáme zabezpečovat tyto části vstupů, musíme mluvit i o tom, že je třeba zabezpečit data i při jejich příchodu dovnitř. To znamená, když chci data natáhnout nebo vůbec k nim přistoupit. To je další velká změna, která do fabriků přišla minulý rok. Máme totiž možnost řídit na úrovni každého pracovního prostoru jeho inbound i outbound přístupy. Dokonce jsme dostali podporu pro Azure Private Linky, což je další extrémní změna a obrovská výhoda najednou.

Pokud se bavíme o zákaznících, kteří jsou pod regulacemi, často si nemůžou dovolit mít Azure Key Vault s přístupem odkudkoliv z webu. To prostě nejde – musí to být striktně omezeno na IP adresy. Jdeš do Azure, zjistíš si IP adresy fabriky, ale zjistíš, že jich je tolik, že stejně nemůžeš nic smysluplně whitelistovat – navíc se ty adresy kvartálně mění. To je bomba. Takže na úrovni IP to nedává smysl úplně.

Další varianta je využívat service tagy, protože fabrik má své service tagy, ale problém je, že fabrikové služby mají poměrně různorodý přístup k tomuhle. Mimochodem, i k těm IP adresám mám jednu drobnost, která je docela vtipná. Fabrik sám o sobě má IP adresový rozsah, který ale nerespektují notebooky, ani PySparkové či Pythonové skripty. Technicky totiž data cestují přes Linuxový server s jeho IP adresou a přesto se snažíš dovolat k cíli. A nedej bože, pokud máš v ETL třeba 30 notebooků, každý má jiný IP rozsah a ty vůbec nevíš, co přesně to bude za rozsah. Je to úplně náhodné, takže to vůbec nezvládneš zkontrolovat.

Právě zde přichází na řadu Azure Private Link, který dává největší smysl. V rámci workspace si řeknu, že chci vyrobit Azure Private Link pro účely Key Vaultu. Jasně, musí být splněna určitá předpoklady – v Azure mám Virtual Network, v ní Subnet, do kterého připojím fabriku. V pohodě, to není žádný problém. Pak tu subnetu připojím ke Key Vaultu. To je taky v pořádku, nic se neděje. V…

Tady je opravený text, zachovávající původní význam a styl:

Do Fabriku přijdu do Workspace, řeknu, že chci založit Private Link vůči Key Vaultu, dopíšu tam jednotlivé požadavky a řeknu deploy. Tak teďka mám šanci jedna ku dvěma až třem, že to víte. Proč dvakrát až třikrát nikdo neví. Každý třetí failne. Je to tak. Prostě se to tak děje.

No a tak to párkrát zkusím a ono se to najednou založí. Stane se to, že já musím vyplnit nějakou message. V tom Key Vaultu mi ta message přijde, já ji potvrdím a v tu chvíli se to všechno prováže a já z notebooku můžu používat nativní knihovny, jako jsou notebook utils pro vás z Databricks, MS Park utils – úplně stejný, akorát Microsoft to přepsal. On umizuje mé notebook utils, proto funguje jak v Python notebooku, tak v PySparkovém. To je ten důvod.

No a v tu chvíli já ho můžu použít, například notebook utils.credentials.get_secret, a vlastně si napřímo nativní knihovnou sáhnout do toho zabezpečeného Key Vaultu, který má přístupy jen pro specifické IP adresy, nebo v tomhle případě jen výjimku toho private endpointu. A já mám krásně vše zabezpečené.

Nemusím se bát a nemusím vymýšlet žádné šílenosti nebo obcházení jako využívání Virtual Network Gateways a přes pipeline stahování něčeho do náhodně vytvořeného souboru někde v Lakehouse, který se pak notebookem smaže. Ne, mám krásnou čistou variantu. Stáhnu, vrací mi to zašifrovaný string, se kterým můžu pracovat a můžu ho předávat dál. Jo, a tohle bylo extrémně důležité, že to vlastně bylo přidáno, protože najednou pro spoustu zákazníků pod regulacemi nebo pod různými bezpečnostními režimy to znamenalo z pohledu bezpečnosti obrovské snížení potenciálních rizik. To je přesně ta cesta, kterou můžou jít.

A obráceně se dá tam nastavit, že do Fabriku nebo do toho konkrétního workspaceu je přístup jen z konkrétních IP adres. To znamená, že můžete donutit svoje lidi, aby se připojovali jen přes určitou výjimku a z ní se tam šli podívat, nebo využívali jakýkoliv bezpečnostní tunel, a říct: „Tento workspace je tak totálně secure, že musíte přicházet právě takhle.“ V rámci toho pak trackujeme každou komunikaci. Za mě strašně důležité, strašně potřebné, a byla to věc, která Fabriku poměrně hodně posunula dopředu.

Možná jsi popisoval, jak tenhle můstek, jak toto otevření nastavit – na jak dlouho je ta práce? Pět minut. Realita je taková, že tady nepotřebuješ žádný kód, je to vyklikáš reálně. Přijdeš do Azure, řekneš: „Chci virtuální network,“ takže založíš. Založeno. Přijdeš, klikneš, že chceš založit subnety, založíš subnety, dáš tam jednu drobnou úpravu, řekneš OK. Přijdeš do Key Vaultu, řekneš: „Připojit na virtuální network,“ done. Přijdeš do Fabriku, tady to jenom zase ve workspaceu pár věcí vyklikáš a řekneš done. To je ono. Čisto.

UIkově je to krásné, vykliká to i biznisový uživatel, což se o některých věcech ve Fabriku říct nedá. Takže kudos Microsoftu.

Co tam máme dál? Tak jo, doteďka jsme se bavili o ně…

Pokud chceš, mohu ti pomoci i s další částí.

Jasně, tady je opravená verze tvého textu:

Jaké formě bezpečnosti. A vlastně i v těch věcech se ty provazby tady dají nastavovat a tak dále. To je strašně super. Ale má to ještě jednu další konsekvenci. Když nasazuješ něco do fabricu – ať poprvé, podesáté nebo jakkoliv – chceš být schopný to nasazovat v podstatě jako code, bych tak řekl. Jasně, spoustu věcí můžeš vyrábět přes API, po technické stránce všechno můžeš ovládat skrze fabric API, z čehož spousta z nás profituje, protože je to výhodné. Na druhou stranu fabric postupně přidal podporu pro Terraform Provider, který se stále zlepšuje.

Právě tady bylo hezky vidět, že někdy v minulém roce někdo měl s Microsoftem hodně úzkou debatu o Terraformu. Terraform byl v Microsoftím blogu za ten rok zmíněný tolikrát, že třeba Terraform Provider pro Microsoft Fabric byl rozšířený o spoustu funkcí – takže chápu, že spolupráce bude super. Ale oni zároveň potřebovali, aby mohli klasickým bashovým nebo SSH přístupem zakládat věci přímo na fabricu. Nechtějí totiž vždycky přistupovat jenom přes API.

Chtějí pracovat úplně stejně jako PowerShellem – třeba říct „create virtual network“ – tady „fabric CLI create workspace“ – a je to hotové. A přesně tohle se stalo: dostali jsme fabric CLI. To je naprosto fantastická věc, protože najednou můžu ovládat fabric třeba i z Raspberry Pi, které mi běží u televize, a nemusím řešit komplikace s API. Můžu pomocí jednoduchého bashového příkazu vytvořit workspace, lakehouse a mám to hotové během pár minut. Pak už jen přijdu a deploynu zbylé věci.

Takže pro práci s fabricem bylo CLI extrémně potřeba a minulý rok se oficiálně objevilo na Fabconu, mezi tím dostalo různé další vylepšení.

To větší překvapení ale přišlo, když byl vypuštěný fabric MCP server, který umí komunikovat se Sielikem a nabízí naučené chování podle toho, co potřebuješ. Mimochodem, fabric MCP server je dostupný úplně pro všechny, podobně jako Power BI dostalo MCP minulý rok. Takže – máš MCP server, máš MCP server, máte MCP servery… Ano, teď si všichni hrají s operačními systémy a rozhazují MCP tady a tam. Samozřejmě je třeba počítat s tím, že nejde vždycky hned nainstalovat na Mac se Silicon procesorem, ale většina to zvládne.

Najednou máš všechno relativně pohodlně z AI pohledu, a to bych chtěl zmínit i v souvislosti s cloudem, protože to je jedno z mála, co mě opravdu uchvátilo.

Pokud chceš, můžu text ještě více upravit nebo zkrátit. Stačí říct!

Tady je opravená verze textu:

Tím, jak je to variabilní a dá se s tím pracovat velmi zábavně. A speciálně s jeho podporou MCP serveru, kde má poměrně zábavný přístup k těm věcem, které chceš dělat. Tak z toho najednou umíš vytěžit extrémní benefity a dělat věci strašně rychle. A proč jsem zase zmiňoval Terraform? Protože přesně tyhle věci vyšly v dalším článku na Microsoftním blogu – Terraform Provider for Microsoft Fabric, který dostal podporu pro Fabric's Eli, Workflow Identity a MCP servery. Každopádně, tady někdo to dělá přímo s jejich inženýry, což šlo hezky ruku v ruce.

Je to perfektní, protože v tu chvíli nasazuješ všechno jako kód. No a nasazuješ všechno. Dokážu si představit, že jsou tam omezení, že některé funkce máš jenom v UI nebo někde jinde. Je to tak, že se to pořád rozšiřuje. Nechci zabíhat do detailů, co všechno můžeš a nemůžeš, ale za rok 2025 se tohle strašně posunulo dopředu a realita je taková, že už jsme velmi blízko tomu, aby se opravdu dalo nasazovat všechno.

Třeba na začátku roku 2025 bylo verzování itemů do gitu ve Fabricu docela slušná tragédie. Některé věci šlo verzovat, ale nic moc. V listopadu pak oznámili, že každý jeden item je stoprocentně verzovatelný, včetně všech metadata. To je přesně ukázka toho, jak extrémně rychle se za ten rok vše vyvíjelo, a naskákalo tam spoustu novinek.

Jasně, všichni se furt budeme krpat s tím, že co třeba pořádná Data Lineage nebo nějaký pořádný datový katalog. Ale vzhledem k tomu, co se tam všechno děje, já osobně bych jen čekal, kdy to přijde. Máme sice Purview, který něco takového dokáže, ale vzhledem k tomu, jak rychle Microsoft Fabric posouvá tyhle věci, vůbec bych se nedivil, kdyby nějaký interní tým přišel s tím, že „jo, tady to máte“. Stejně tak se objevilo Sielajko. A vůbec tyhle nadstavbové věci, například nasazování jako code, jsou podle mě obrovskou výhodou – pro standardizaci řešení, když nasazuješ vlastní framework, protože pak nasazuješ věci vždycky stejně, nebo chceš jednu změnu nasadit na všechny zákazníky nebo do všech oddělení najednou. Prostě jak má být. Může to být čisté.

Já to vnímám podobně, že Git byl zatím takovým slabším článkem, vždycky lehce komplikovaný. Microsoft Fabric je skvělá platforma, i když zatím bez dokumentace, což je trochu škoda. Data Lineage a plná podpora ovládání platformy přes kód, s podporou Pythonu a dalších věcí, tam ještě trochu pokulhává. Máš sice dokumentaci a vše, ale pořád neuděláš všechno. No ono je to zvláštní, protože Microsoft Fabric je postavený velmi zajímavě z hlediska metadat. Jestli se někdo z posluchačů někdy zkoušel v tom hrabat, já bohužel ano, možná až moc, zjistil, že tam je strašná spousta servisních tagů, které…

Pokud chceš, můžu pokračovat s opravou nebo přeformulovat další část.

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

Se mezi sebou jako provazbujou. A ty jsi schopný si ten Lineage napsat sám, úplně komplet – od úplného začátku, od vstupu, který ti přichází. Pokud máš třeba Data Gateways a taháš data z on-premu, tak jsi schopný to celé provázat od on-premu až do koncového reportu. To je proto, že to mají dobře otagované. Samozřejmě, pokud děláš nějaké šílenosti třeba v transformacích, tak tam už záleží, jak je to postavené. My například máme metadatový loader, ve kterém si tagujeme i transformace, takže můžeme dopočítat zbytek. Takže to pak vyrenderuješ docela jednoduše.

To je super. A co se týče CLI, co nejčastěji děláš přes konzoli, nebo přes MCP server? Nebo používáš nějaký workaround, místo toho aby ses klikáním prokousal přes API, teď to děláš přes kód?

Jo, jedno ze základních pravidel, které se snažím naučit v těch firmách, když tam přecházím, je: uživatel nemůže zakládat workspace sám. To nejde, je to instantní bordel a problém. Proto je strašně super mít ticketovací systém, kde řekneš: chci založit workspace pro konkrétní účel, vyplníš požadavky a už jsou připravené CLI šablony, které pak jenom řeknou deploy. Při zakládání workspace rovnou přidáš uživatele, protože když zakládáš workspace, nemůžeš tam definovat uživatele, kteří tam budou. Takže do adminů jsou rovnou přiřazení konkrétní lidé a uživatel je přidán třeba jako member nebo contributor podle potřeby. Můžeš tak nastavit i konkrétní parametry workspace.

A předpokládám, že tyhle věci přes API vlastně ani nemůžeš? Naopak, umím mitigo umím replikovat každé UI chování přes API, takže jo, šlo to. Jenže pro spoustu operací potřebuješ uživatelský token, což není úplně ideální, když nechceš někomu ukrást práva. Navíc Microsoft začal některé operace chránit přes MWC tokeny, které není úplně lehké generovat. Navíc k tomu často nemáš ani nástroje nebo dokumentaci, jak to udělat. Celkově je to dost komplikované – musíš mít spoustu tokenů a GUIDů pro konkrétní situace.

A to CLI to elegantně řeší a dává ti jednodušší cestu. Je jednoduchý napsat „fabrik create workspace –name Název“ a rovnou to nasadit. Můžeš to pak nechat spravovat třeba Raspberry Pi nebo Orange Pi, pokud chceš být levný. Ta zařízení jsou malá, nemají velký výkon, ale jsou zábavná.

A jak ovládáte váš fabrik? To je dobrá otázka. Rád bych věděl, jak vy ovládáte svůj fabrik – máte nějakou sadu otázek nebo metod?

Pokud chceš, můžu text ještě více zjednodušit nebo přizpůsobit styl.

Jasně, tady máš opravený text:

Na jaké platformě to bude, když to vůbec nedává smysl – například pan Duma ve fabriku a někdo jiný hádá v Power BI, to je otázka číslo jedna, tu rádi pozbíráme. Festival počítačových her hraných na alternativních zařízeních – to je jedna věc. No a toto je druhá. Hele, já to asi zkusím ovládat přes pračku, to bude sranda. To, že někdo rozjel Skyrim na lednici, je dobrý, ale ovládat fabriku přes pračku by bylo ještě větší sranda. Přesně. Prosím tě, děláš něco s pračkou? Ona vůbec nepere. A ty se podíváš a sakra. Sakra, ona mi založila 50 workspaceů. A všichni se jmenují „barevné čtyři“, „barevné 30 na 900“, „otváček“, „očky“. No, takže CLI jako game changer další. A mně se tam líbí zase, když se podívám na high level, co byl můj trochu strach v té AI demokratizační vlně „One for All“, což je prostředí, kde můžeš data scientistu, data inženýra, BI specialistu i…

Děláka, který to nikdy neviděl, odpustit a pro všechny a toho – to je vždycky… To je marketing. To je marketing, jako one size doesn't fit them all, nikdy to nefungovalo. No, tak tomu už po těch letech vlastně nevěřím. A trochu jsem se bál, že i s Power BI a tak, že to budou hrozně táhnout do těch uživatelských funkcí, že to bude zbastlené, že to bude vypadat hrozně dobře a bude to prostě na prospektech, a bordelci budou říkat „jo, to chci konečně“, ale přitom ten podvozek bude pořád seskládaný z těchto servisu dohromady. Ale teď, jak mi to vyprávíš, tak to zní, že ta priorita byla opravdu pro ty nejhlouběji – jako data engineers a experty – dát jim možnost to ovládat a udělat z toho powerful platformu pro ty power users jako první, a potom postupně nějak rolují demokratizaci. Nebo je to tvůj bias, když jsi power user expert hluboko, a tak z těch novinek vybíráš ty víc infrastrukturní, více data engineerské, více hluboké a exaktní? B je správně. Jo, hele, já jsem explicitně vybral ty novinky, které jsou zajímavé pro mě. Samozřejmě, je tam spousta dalších variant, které jsou víc marketingové, nebo end-user směrované. A jsou tam věci, které mi loni přišly a jsou to přesně ty věci, kde jsem měl extrémní obavy, co to vyvolá u nějakého bordiáka. Typickým příkladem jsou fabriku agenti, data agents. To jsou agenti, které si můžu potenciálně natrénovat na to, aby odpovídali konkrétním business otázkám, a když se pak uživatel ptá kopilota, tak kopilot se může rozhledat mezi těmito specializovanými agenty. Což furt nezní tak špatně, muselo by to ale dobře fungovat. Dneska to je už mnohonásobně lepší. Když to vypustili z pohledu – zase z pohledu popkonu, tedy v businessu, tak v Evropě to nefungovalo, sypalo to chybami, set konstantně nevycházelo správně. Teď už to relativně dobře funguje, dá se to nastavovat, ale je potřeba to nějak licencovat. Ano, ve fabriku platí, že jedna licence vládne všem. Ale naštěstí, a tady opravdu velkým slovem říkám „naštěstí“, je tam podpora proto, že já…

Pokud chceš, můžu ještě upravit více do srozumitelnější formy, případně více strukturovat. Stačí říct!

Tady je opravená verze textu, upravená pro lepší srozumitelnost a gramatiku:

Můžu mít separátní kapacitu, třeba právě jenom F2, nějakou maličkatou, aby mě to nepálilo v kapse, a říct, že všechny kopilotí kosty se buduijou do ní. A je úplně jedno, na jaké kapacitě já se dotazuji – vždycky se to nebyluje tam. Tohle mimochodem taky přišlo jako novinka zvaná Fabric Copilot Capacities, je to normální F, jenom jedno zaškrtávátko – zaškrtnout a hotovo.

Takže tenhle bias pro manažery a podobně tam taky je, ale na něm se taky hodně pracuje. Ale to, co já právě chci ukázat, je, že ačkoliv marketing by neměl stačit jen těmto novinkám, prostě „hej, máme tady tohle a tohle“, na pozadí vzniká spousta úprav na technické rovině, na bezpečnostní a infrastrukturní úrovni, které nejsou tolik promovány, ale jsou klíčové pro to, abychom byli schopni platformu dále dodávat.

A jsou klíčové pro to, aby někdo platformě mohl věřit. To mě opravdu těší. Byl jsem dříve trochu biasovaný, protože Fabric bylo všude strašně moc a ještě nebyl na to připravený – říkal jsem si, kam to všechno to řvaní a povyk povede a jestli budou schopní to opravdu doručit – tedy „under-promise, over-deliver“. Na začátku to spíš vypadalo jako velký over-promise a nedoručování. Ale podle toho, co teď říkáš, tak do roku 2025 i z inženýrského, strategického a možná architektonického hlediska, tedy na úrovni architektury platformy, se stalo strašně moc věcí.

A to je ještě jeden speciální bod – který krásně ukazuje, že si jsou vědomi vlastních chyb, což mě opravdu velmi těší. Tým, který je odpovědný za lakehouse a warehouse, řídí jeden člověk, který je extrémně oddaný své práci. Lidi, kteří zažili v Power BI datamarty, vědí, o kterém týmu mluvím, protože je to pořád ten samý tým. Datamarty zanikly úmyslně, ale byl to pilotní test, jestli vůbec něco takového může ve Power BI vzniknout.

A když se ukázalo, že může, Fabric nabral extrémní obrátky. Problém, který tu dlouhodobě byl, je ten, že mám Lakehouse, do něj naliju data ve formě delty, která se mi jako tabulky zobrazí a mohu je dotazovat přes SQL Endpoint. V začátku to bylo prezentováno jako „náhrava dat“ – vidím je okamžitě. Ale takhle to nikdy nebylo, nefungovalo to tak jednoduše.

SQL Endpoint musí data zaregistrovat, musí si rozšířit schéma a vědět, kam se dál dotazovat. Je fajn, že mám checkpointy delty a JSONové logy, které mi říkají, co se změnilo, ale pokud tato kontrola a rozšíření metadat pro SQL Endpoint neproběhne, data neuvidím.

Tato tzv. metadatová synchronizace obvykle trvá pár vteřin. A tady je docela klíčový prvek: hned od začátku v dokumentaci je napsáno, abyste používali vacuum a optimize na vaše tabulky, aby tam nebylo příliš mnoho checkpointů, moc JSONů a podobně.

Pokud chceš, mohu pokračovat v opravě zbytku, jen mi pošli další část.

Extrémně velké množství malých parketových souborů způsobuje typický datový problém – problém velkého počtu malých souborů. Znám ho všichni, milujeme ho, je to zajímavý bizár, ale prostě to tak je.

Když jste měli těchto souborů hodně, synchronizace endpointu trvala velmi dlouho. Dokážete tipnout, jak dlouho? Když jsi říkal tři vteřiny, já bych řekl tři minuty, v řádu minut. Dobrý, já jsem říkal i tři dny. To je přesně ukázka toho bizáru, který může nastat.

A ty jsi nad tím neměl kontrolu, nevěděl jsi, jestli už je to synchronizované nebo ne. Představ si, že vezmeš svá data, uložíš je do lakehouse zpracovaná třeba Pythonem, a teď je chceš vidět v Power BI, chceš se na ně podívat a nevíš, kdy uvidíš nová data, nevíš, kdy je máš obnovit. Nemůžeš uživateli nic říct, je to nekontrolovatelné. Nebo nedej bože může nastat bias.

Každý uživatel si může data transformovat. Dáme jim data flow, která přistupují k lakehouse pomocí síťového endpointu. A pak zase koukáš na stará data. To prostě není možné. Nemůžeme si dovolit vydávat stará data jako nová, tím spíš ne do reportu.

Z tohoto důvodu vzniklo API pro ruční refresh tohoto endpointu. Můžeš data nalít, spustit refresh, sledovat průběh díky tomu, že je to synchronní, takže můžeš průběh sbírat. Když refresh doběhne, můžeš spustit vše ostatní. Když to vynutíš, nemusí endpoint čekat na registraci změny.

Právě ta registrace změn byla příčinou, proč to mohlo trvat třeba tři dny, protože bylo takové množství souborů, že nebyl schopen je zpracovat. Takže teď máš nový endpoint, kterým tohle můžeš dělat.

Tuhle možnost bylo možné používat i dříve, ale pouze neoficiálně, teď vzniká oficiální API.

To byla ukázka, že si byli vědomi problému. Když jsem se o tom bavil s Charlesem, který je vlastníkem týmu, řekl jsem mu, že lakehouse je nepoužitelný bez použití tohoto privátního endpointu. On přiznal, že to vědí, a že je to způsobeno současnou implementací. Snaží se to přepracovat a vymyslet lépe.

Zatím co udělají a co budou vypouštět příští týden, je toto nové API, které je dočasným řešením, než problém skutečně vyřeší.

Skutečně se snaží adresovat problémy, alespoň nám dají quick fix, jako je toto, a zároveň plánují kompletně přepsat engine, který k tomu napsali. Za mě mají velký respekt – mluvil jsem i se zbytkem týmu a jsou opravdu velmi oddaní své práci.

Tady je opravený text:

Tenhle tým.
Možná jak se jmenuje Charles, příjmením, ať ho můžou?
Charles Lep.
Kdybych měl takové jméno, taky bych byl v Microsoftu někdo.
No, oni tam mají dva weby.

Kristofere a Charles. Takže Charles Webb. Můžete sledovat jeho tým. To je super doporučení, určitě.
Mimochodem, Charles je člověk, který chce každý feedback. Charles si říká: rozsévejte můj tool naprosto napříč, i ty nejnižší úrovně.
My jsme se poznali, takže jsem mu poslal asi 15 A4, co nefunguje, co je blbě. A on mi za 10 minut odpověděl: „Můžeš na call?“ Připojil jsem se na call, tam mi 10 minut děkoval, pak zavolal svoje inženýry, a procházeli jsme bod po bodu a rovnou jim dával timeline, kdy ty věci budou opravené.
To je extrémně oddaný člověk. Opravdu super.
Skoro škoda pro Microsoft, jak o tom mluvíš. Hustý.
Zároveň v kontextu toho, že v tak velkých enterprisech byste takových lidí našli málo, a o to větší kudos Charlesovi.

Co tam máme dál?
Hele, mám tady ještě jednu docela horkou novinku na závěr, hot take.
Je to věc, která byla představena na Ignite, tedy úplně na konci roku.
Kdo z vás sledoval Ignite, asi jste zachytili, že historicky Microsoft všude dával Power, pak tam dával One. Teď dává dvě písmena, která štve úplně všechny: IQ.
Máme Work IQ, máme Office IQ, jestli si to pamatuju správně, máme Azure Foundation IQ a máme Fabric IQ.
Což je další poměrně velká novinka, mířená hlavně na byznysové uživatele.
Říkám „víc“, protože to bez IT a lidí okolo úplně nepůjde.
Ne úplně ne, ale bude to náročné.

Technicky na co fabric IQ cílí a jaká je základní myšlenka?
Bavíme se o tom, že je to preview, velmi preview, takže prosím přistupujte k tomu tak.
Zároveň bylo odhaleno pár karet, ale Microsoft drží hlavní info hodně u těla, takže jsem zjistil, kam to všechno může směřovat, protože na jednu stranu je to hodně vzrušující, na druhou stranu je to trochu nejasné.

První věc je tam ontologie.
Zkuste se v hlavě zamyslet, kdo z vás ví, co je ontologie? Nemyslím filozofickou definici, já to také neznal do hloubky. Jen jsem to slyšel.
Přesně, jsou tři úplně odlišné přístupy ke stejnému pojmenování.
Z pohledu inženýrů je to, jako kdyby letadlo už bylo v provozu, takže právě vyšlo z hangáru, a oni říkají: „Yes!“
Cíl je takový, abyste byli schopní sestavit konkrétní entity, které se vztahují k vašemu problému a daným datům.
Jakmile tohle sestavíte, měla by IQ složka být schopná hlídat, jestli se tyto stejné datové entity a problémy už někde jinde ve fabric nevyskytují, aby nevznikaly duplicity, a aby bylo možné je případně společně naroubovat.

A taky abych mohl potom vytvořit nějaký graf.
A tady se bavíme o t…

Pokud chceš, mohu ti pomoci s pokračováním a doladěním i dalších částí textu.

Opravený text:

O tom, že do Fabriku přišly ještě grafové databáze. A vlastně vůbec jejich přítomnost. No, tak vytvářím nějaký knowledge graf. Knowledge graf, kde mám vlastně jednotlivé tyhle biznisové celky, které obsahují jednotlivé datové entity. Cíl toho celku je takový, aby AIM mohl přijít, podívat se na ten graf optikou konkrétního departmentu, když mu položí dotaz, a on ví, kde pro danou problematiku najde potřebná data a jak si je vzít, aby s nimi mohl následně cokoli udělat.

Protože k tomu máme právě ty data agenty, o kterých jsme mluvili, kteří se na to dají přesně napojit. Vedle toho přišli s další komponentou, která se jmenuje operational agent. Operational agent má reálném čase sledovat naše data, která jsou napojena v tomhle komplexu, a má být schopen rovnou vyvolávat reakce. Znamená to například říct: Hele, v pohodě, byznysu naše letadlo prodělává přesně v ten moment, kdy stojí, protože tady máme pět letadel, která stojí. A rovnou hlásit a spouštět tyto operační věci – to je myšlenka.

Insidey se nějak pouští. A toto je ta myšlenka zatím, jakoby IQ. Na papíře to zní dobře. Na druhou stranu, z mýho laického pohledu, to spíš připravuje půdu pro agenty a samo o sobě jako řešení na glosáře nebo něco podobného asi nebude dokonalé. Vlastně nějakou část práce a discovery uděláš tak, že nezačínáš na úplně čistém papíře a neobcházíš oddělení s otázkami typu „čemu říkáte obrat“, protože máš nějaký mustr. Ale na konci dne stejně budeš muset ty oddělení obejít a vše si ověřit.

Taky tohle je právě cíl – aby se naplnila ta ontologie, což je v podstatě ta itemová fabrika, tak aby si ji vyrobily jednotlivé departmenty a správce to pak jenom celé provázal. Je tam poměrně hodně práce, která se musí udělat, aby tohle mohlo fungovat.

Ještě jednou říkám, že je to v preview, spousta věcí tam třeba ještě nefunguje. Viděl jsem to, a říkám si, že si to potřebuji osahat a vyzkoušet, protože zatím je to pro mě strašně neuchopitelné, jak s tím vlastně pracovat. Přišel jsem, napojil to na lakehouse, který má v sobě schémata, a řekli mi, že to nepodporují. Takže mi to prakticky zabilo veškerou funkčnost. Neříkám, že to třeba teď už není vyřešené, ale od té doby jsem s tím neměl možnost tvořit.

Takže úmyslně prezentuju tu myšlenku a jsem hodně zvědavý, co to za tři měsíce bude, jak se to posune, protože věřím, že docela hodně. Vzhledem k tomu, jaká jména v Microsoftu kolem Fabrik IQ operují, tak tam na pozadí probíhá něco velkého. A bude to ještě zajímavé.

Když se podíváme na celou IQ suite, je to čistě označení, že teď všude “mlátí” IQ, nebo je to řada, která propojuje všechny ty celky dohromady, reálně. Jako otevření agentům možná? Ano.

Takhle to, co se dělo, teď nevím, jestli to bylo minulý rok, nebo již částečně předminulý, tak došlo…

Text jsem upravil co nejvíce podle původního významu a stylu, ale s důrazem na gramatickou správnost, interpunkci a plynulost. Pokud chcete, mohu vám pomoci ještě s jinou formou, například formálnější nebo stručnější.

Jasně, tady je opravený a upravený text:

K sloučení všech kopilotů v podstatě do jednoho a už máš jenom agenty, kteří to distribuují, což je přesně ten hlavní benefit – aby jich nebylo 150. Například Power BI měl 8 vlastních kopilotů, což byla schizofrenie na entou a navzájem si spolu neměly jak povídat. Teď aspoň trochu komunikují. Ta představa, že vlastně propojím všechny tyhle světy, je hodně zajímavá.

To mi připomíná Google, protože tohle byl trošku jejich systém – jednu funkčnost měli v různých formách v různých částech a řezech. Když to přišlo na trh, věděl jsi, že je to testovací, ale že z toho vznikne jedna platforma nebo tři různé. To zní zajímavě, protože jsem vnímal Google jako agilnější v tomhle směru – přichází s novými funkcemi rychleji, zatímco Microsoft byl pro mě spíš vodopádový, jako ledoborec: jdeme tímhle směrem a hotovo. Ale teď, jak o tom mluvíš, slyším v Microsoftu nějakou agilitu, zkoušení a nejasnost, což je pozitivní. Na druhou stranu neznám jejich plány, takže na to úplně nemůžu zareagovat.

Mně ta vize přijde zajímavá právě v tom, že chtějí do kancelářských nástrojů (officeových) opravdu integrovat moderní technologie, aby uživatel mohl začít budovat vlastní znalostní bázi, včetně fabrikového konceptu a Azure Foundation IQ, což je velmi zajímavý koncept, který tady vznikl. Mimochodem, Fabric Foundation má pro nás obrovský význam.

Azure Foundation – ty modely, které tam můžeš vyrobit, se dají přímo mapovat na fabrikové loady. Mně se moc líbí, že Microsoft mnohem víc, minimálně v mých očích, propojuje svoje technologie dohromady a dává jim jednotný rámec. To v tak širokém portfoliu produktů, platforem a cílových segmentů není vůbec jednoduché řídit.

Ne, to vůbec ne. Microsoft má obrovské množství zaměstnanců, týmů a velmi složité priority ve všech vývojových procesů. Já jsem měl možnost nahlédnout pod pokličku jejich developerského procesu – jak vybírají priority a plánují je. Nemají to vůbec jednoduché.

Chápu, že jim budeme vždycky nadávat, to prostě budeme, ale snaží se.

Za mě se mi líbí, že jsi kritický a říkáš věci narovinu, což je důležité. Na druhou stranu z našeho povídání zvedá moje důvěra a dávám velký palec nahoru Microsoftu, hlavně konkrétně ve Fabricu. Z něčeho, co byla dřív slepenina, je za rok velký posun, což ani u startupových řešení nebo menších projektů nebývá obvyklé. Za to klobouk dolů.

Možná to shrneme tak, že jsme tady dnes prošli nějaké novinky, které se odehrávají koncem roku 2025, přestože už máme rok ‘26, a novinky budou pokračovat dál.

Kdybys chtěl, můžu ještě text nějak zkrátit nebo upravit do formálnější podoby.

Jako hodně, ale blíží se nám zase událost, takže už každý rok, kdy se toho oznamuje nejvíc, kdy se oznamují věci, které většinou člověk nečeká — alias Fabcon. Dneska tady několikrát padl ten minulý a čeká nás vlastně ten další, který bude probíhat v březnu. Rozhodně si myslím, že to bude věc, kterou je dobré sledovat, protože opravdu se tam oznamují velké věci.

Většinou ty věci, když jsou oznámeny, jsou v early phases, takže bych to i tak bral, ale aspoň je dobré vědět, kudy vlastně Microsoft směřuje. Je to velmi pragmatické a příjemné to sledovat. Odmyslete si 90 % marketingu a pak se dostanete k realitě. Prostě chápeme, že marketingový hype je tam potřeba.

Já jsem strašně zvědavý, co vlastně Fabcon přinese, protože toho může být relativně hodně. Pořád je zde silný tlak na agentivizaci, tedy přidávání MCP serverů. Minule byl velký tlak, aby stihli do posledního Fabconu, který byl v říjnu, dodat, že jsou všechny položky verzovatelné — to bylo šílené. Takže jsem hodně zvědavý, co se teď s tím objeví.

Za sebe čekám zase nějaké novinky v real-time řešeních, prostě tak, jak bývá obvyklé. Čekám spoustu nových informací právě o Fabric IQ. Myslím si, že tam může přiletět docela hodně novinek.

A pokud jste si všimli zajímavého vzoru, tak každý Fabcon Microsoft oznamuje spolupráci s nějakou další firmou. Měli jsme spolupráce s Oraclem, se SAPem. A do Fabricu byly velmi rychle potom přidávané konektory přímo do těchto nástrojů, aby šlo co nejrychleji dostat data. Jsem tedy zvědavý, kdo přijde teď.

Když už před časem slíbili spolupráci se Snowflake, všichni jsme čekali, co z toho bude. A ta současná integrace Snowflake a Fabricu tam a zpátky je opravdu skvělá. Víte, že v Lakehouse můžete pokládat otázky přímo na data uložená v Icebergu, a stejně tak ze Snowflake můžete dotazovat data uložená na Delti. Tato integrace je opravdu hezké pozorovat.

Ukazuje to, že Microsoft už si nehraje jen na svém písečku, ale víc přemýšlí z pohledu, že všichni používáme něco jiného a jsme v tom dobří. Tak to prostě pojďme spíš otevřít a pomoct si tím, jak to dotáhnout dál a ukázat, že naše platforma umí fungovat se všemi.

Jsem hodně zvědavý, jaká další firma se do tohoto stacku přidá. Z businessového pohledu je to velmi zajímavé, protože přímé napojení na konkurenci z jejich segmentu enterprise — možná právě tam Snowflake běží — a tato platforma má být ta centrální One Platform. Je to odvážné, ambiciózní, a zaslouží si to potlesk.

Děkuji, že jsi zmínil Fabcon, protože tím bych to vlastně uzavřel pozvánkou k Tobě. Já jsem tady support, Robin k tvému Batmanovi. Už se můžete těšit na další díl Czech Fabric.

Podcastu se Štěpánem a mnou, který bude právě po Fabconu a před Buildem. Takže někdy v dubnu se můžete těšit na další epizodu vašeho nejoblíbenějšího a nejlepšího podcastu o Fabrici v Česku, která vyjde zhruba za dva až tři měsíce. Podíváme se v ní, jak se tvá očekávání naplnila, co můžeme čekat, že na Buildu budou prezentovat, a kam se Microsoft stack a Fabric ubírá. Já jsem na to moc zvědavý a jsem rád, že jsme o tom mohli teď také trochu popovídat ve třetí epizodě SubtenSvěta.

Těším se na další díl, protože můj entusiasmus do těch novinek je velký, takže jsem opravdu zvědavý, co tam bude „bublat“ v tu chvíli, když Build začne.

Ještě jednou moc děkuji za pozvání, to je opravdu fajn. Díky moc!

A děkujeme i vám všem, kdo jste si poslechli tento podcast. Doufáme, že se vám náš nový podcast líbil a že se k nám budete pravidelně připojovat. Už připravujeme další témata, nebojte, máme jich pro vás mnohem víc, takže se můžete těšit.

Mějte se krásně a ahoj!

Děkujeme, že jste doposlouchali až sem, a také díky našim stálým partnerům a členům Data Talk klubu. Jsou to: Saska, TV Nova, Direct Technologies, Good Data, Myton, Colors of Data, BeStreet, Flow, Carl Data Company a Intex. Díky moc za podporu a za to, že s námi provázíte svět dat.