Podcast

Ahoj všem, moje jméno je Barbara Hinerová a vítám vás u dalšího dílu Data Talku. Mým dnešním hostem je Štěpán Rešl, Lead Tech Consultant ve firmě Data Brothers. Dneska se budeme bavit hlavně o Microsoft Fabric, takže se určitě máte na co těšit. Ahoj, Štěpáne.

Ahoj Báro, ahoj všichni, jsem hrozně rád, že jsem tady s vámi v Data Talku.

Tak než se dostaneme k Microsoftnímu data-stechu, řekni nám, Štěpáne, jak ses dostal k datům a k Data Brothers? Jaká byla tvoje cesta?

Hele, moje cesta začala tak, že jsem původně neplánoval pracovat s daty. Skoro bych řekl, jako většina lidí, které znám v tomto odvětví. Měl jsem své vlastní vize a cíle... nevím, jak to pojmenovat, chtěl jsem se spíš věnovat programování jako takovému, vývoji aplikací a nějakých krásných utilitek, které by mohly postupně pomoct zjednodušit můj život. No a co čert nechtěl, skončil jsem u dat. Dělám si z toho srandu, ale jsem za to hrozně rád, protože když se dneska na to podívám s odstupem času, tak bych s těmi daty do kontaktu přijít musel, pokud bych chtěl vyvíjet rozumnou aplikaci. Postupně jsem zjistil, že jim chci rozumět mnohem víc než jen na povrchní úrovni potřebné pro vývoj aplikací. Možná to zní zvláštně, že v tu chvíli to tolik potřeba nebylo, ale chtěl jsem tomu rozumět více do detailu, jak lépe řešit návrhové modely, jak s tím lépe pracovat, jaké jsou vlastně všechny možnosti, a tak jsem postupně sklouzl do datové sféry.

Ale začátek byl, jak říkám, víc programátorský — bavilo mě C, C#, a právě proto jsem programoval VBA. To byla vlastně brigáda, kdy jsem psal makra v Excelu pro pár větších společností.

Můžeš jmenovat, pro které?

Nemůžu jmenovat.

Dobře, super.

Nemůžu jmenovat, ale psal jsem VBA makra. To mě docela bavilo.

A kdy to bylo?

To je asi patnáct let zpátky.

Aha, to sedí, tehdy byla VBAčka velmi populární.

Ano, tehdy byly VBAčka opravdu cool, a hlavním cílem bylo automatizovat Excel tak, aby se buňky samy zamykaly a odemykaly v konkrétních okamžicích, psalo se jen na určené buňky a tak dále.

Zní to skoro jako magie.

Jo, ale za každou magií je vždycky nějaký kód nebo logika, jak s tím pracovat.

Postupně přišla příležitost dělat něco trochu jiného, konkrétně adopci Office 365. Tím jsem se od dat trochu vzdálil i od programování a přešel na adopce, konkrétně na zavádění SharePointů. V té době začaly vznikat Teams a začaly se objevovat, takže jsem je řešil. A postupně, jak jsem se více věnoval Microsoftnímu steku, začaly přibývat nové technologie a já začal bloudit i k Azure a dalším věcem.

Tady je opravený text s úpravami pro srozumitelnost, gramatiku a pravopis:

které se v něm nacházely, od síťových databází přes logické úložiště, až po Power Platformu, která byla tak trošku Microsoftem, nebo vlastně Microsoftem trošku separovaně, což je rodina nástrojů, které měly značnou sílu, to znamená, měly dostatečnou kapacitu být samostatné. Jejich jména se obvykle skládala alespoň ze dvou slov, takže například PowerPoint do této rodiny nepatří. A co tedy patřilo do této rodinky silných nástrojů? Byly to Power Apps, Power Automate, Power BI a Power Virtual Agents, což se dnes už takto jmenuje jen částečně, vzhledem k tomu, jak rychle se mění některé z těchto nástrojů, tak si myslím, že některé z nich už se možná ani zítra takhle nazývat nemusí. Postupně do této rodiny přibývaly další nástroje v průběhu času. Na začátku byl jen jeden, a postupně se z různých dalších projektů Microsoftu začaly stávat nástroje, které do té rodiny zapadaly.

Což mi poměrně docela nevyhovovalo, protože například Power Apps jsou velmi jednoduchý nástroj, jak si vyrobit aplikaci, aniž bych musel znát programování, což na jednu stranu má svá úskalí – je tam extrémně omezená možnost přizpůsobení. Spoustu věcí jste prostě odkázaní na to, co je předdefinované, a nemůžete si je přizpůsobit do takové míry, jak byste chtěli. Takže člověk začíná logicky víc zkoumat, otevírá si jejich kód a snaží se najít způsoby, jak tato omezení obejít.

Takže ses vrátil zpět ke svému vývojářskému snu?
No, tak trochu, ale trošku oklikou, protože i když jsem se chtěl věnovat Power Apps, více mě tehdy zaujalo začínající Power BI, což mě zaujalo ještě dřív, než přišly Power Apps. Pro mě to byla velmi zajímavá oblast, která měla určité základy, které jsem dobře znal – pocházející z Excelu. V Excelu totiž v roce 2015 přibyl Power Query, respektive on tam byl už dříve, ale v té verzi 2015 už byl plnohodnotnější. V roce 2013 jsme měli Power Pivot, a pak tam byly i další „Power“ části, jako Power Grid či Power Maps. Ty se postupně spojily a vznikla první verze Power BI, která měla zelené logo. To byl velký šok.

Ano, a původně to bylo hodně zaměřené na finanční oddělení, controlling a finance ve firmách, protože to mělo být nástrojem pro tzv. power uživatele Excelu. Dá se to tak říct, ano. V té době mi to přišlo zajímavé, protože jsem potkával zákazníky, kteří s tím měli potíže, a chtěl jsem jim nějak pomoci.

V tu chvíli jsem se vlastně začal věnovat dvěma poměrně specifickým jazykům. Prvním je jazyk M, tedy Power Query M Language, což je víceméně integrační nástroj právě z oblasti Power Query. Pamatuji si několik prvních reakcí na jeho oznámení, kdy řada lidí říkala: „Proboha, proč dostáváme nový SQL? Nebo jestli tam budu psát úplně to samé.“ A až později mnohým došlo, že...

Pokud chceš, mohu pokračovat s opravou zbytku textu.

Jistě, zde je opravený text:

To není nový nástroj, ani jazyk, který by byl fakt mířený na typické citizen vývojáře. Spíše je určený víc na Power Users, kteří si s tím potom třeba připraveně klikají nebo s tím pracují. Nejedná se o to, že bychom je chtěli učit psát SQL a dělat optimalizované dotazy – SQL tu pořád bude, je extrémně silný a nikdy nezmizí. Tyto jazyky si vůbec nekonkuruji, každý má svůj specifický účel.

Vedle toho je druhý jazyk, to je DAX. Pokud někdo z posluchačů někdy slyšel o jazyce MDX, tedy o multidimenzionálním jazyce, který vznikl pro Analysis Services s multidimenzionálními daty, a pokud ho někdy psal, ví, jaká to byla šílenost. Ten jazyk umožňoval hodně pro přípravu multidimenzionálních kostek, ale znamenalo to, že jste museli psát velmi exaktně, dobře mu rozumět a dopočítat některé náležitosti – nebylo to jednoduché. Některé memorování mě dojeda dodnes straší.

DAX oproti tomu je mnohem příjemnější a rozumnější jazyk pro tvorbu semantické vrstvy. Dobře, nicméně… abych se vrátil k tématu, teď jsme hodně utekli do historie Microsoft Power steku, což je samozřejmě dobře, myslím, že se k tomu ještě třeba vrátíme později.

Takže jsi potom přišel na chuť Power BI a Power nástrojům, řekněme. Ano, a musím říct, že jsem si to oblíbil hlavně díky skupině PPUG – Power Platform User Group – která působí v Čechách a na Slovensku, kde se pravděpodobně potkávají…

Tyto skupiny potkávají členové MVP, kteří se zaměřují právě na tento stack. MVP znamená Most Valuable Professional, což je ocenění, které Microsoft každoročně uděluje pár lidem po světě v daných technologiích. Pár je jich také trochu nadhodnocených, bavíme se o pár stovkách.

Mezi nimi je několik MVP zaměřených na Power Platform nebo Azure. Bylo úžasné poslouchat lidi, kteří mají extrémní vášeň pro dané technologie, což mě velmi motivovalo občas přijít tam vystoupit nebo mluvit právě o Power BI, o kterém tam tehdy moc nemluvili.

Takže jsi také získal nějaké ocenění? Už pětkrát po sobě. Jako Karel Gott nebo Slavíci, že? (smích) V České republice jsme teď dva MVP na Power BI, pokud to tak mohu říct – já jsem MVP na Power BI čtyřikrát, poslední ocenění byla za Power BI a Fabric. No, za Fabric ještě nebylo tolik příležitostí, že ano? To jsme ještě nedošli k tématu Fabric, tomu se budeme věnovat později.

Získání MVP vyžaduje komunitní činnost, takže jsem začal víc vystupovat, hodně mluvit o problematice a ponořit se do detailu, takže mám i různé zkušenosti…

A kdo je ten druhý? Jirka Neoral, kolega z Brna. Dobře, zdravíme kolegu z Brna.

No dobře, kam tě pak tato cesta vedla? Mě to vedlo zpátky k Azure, protože jsem chtěl pochopit, jak technologie fungují a jak vlastně vzájemně spolupracují. Pro to bylo potřeba tomu porozumět.

Pokud chceš, mohu text ještě více upravit nebo zpřehlednit.

Jasně, tady je opravená a upravená verze textu:

Jak vlastně to funguje v celém tom ekosystému? Když si na chvilku vezmu na paškál Power BI a rozdrobím ho na jednotlivé části, tak vlastně se skládá z nástrojů, které v Azure docela běžně známe. Nevím, kolik posluchačů tady máme vlastně z Microsoftího stacku – poznáme to podle toho, kolik z vás bude poslouchat, jasně.

Takže, když si odmyslíme prezentační vrstvu a budeme se chvíli věnovat té čistě datové, co se stane? Jakmile vezmu nějaký Power BI soubor a publikuju ho do webového prostředí, tak se vlastně nakontaktuje Azure Data Relay, který zprostředkuje komunikaci do specifického storage accountu. Ten je navázaný na nějakou kapacitu, a do toho storage accountu se začnou načítat moje data. Dobře, a tohle se pak načítá do Data Brothers, nebo jak to je? Hele, takhle to ještě úplně není, ale myslím, že se k tomu dokážeme dostat za chvilku.

Dobře, takže data jsou tedy v storage accountu a veškerá metadata se načítají do Azure Synapse (potřebujeme si upřesnit přesný název, může to být CQL nebo Synapse databáze), abych měl možnost s nimi víc pracovat. Takto se mi tedy začal rozkreslovat celý svět toho, jak Microsoft tenkrát k těm věcem přistupoval. Power BI je vlastně spojení mnoha různých nástrojů, což je super – a mě to zajímalo, chtěl jsem teď víc pomáhat zákazníkům.

A nebyl jsem v tom jediný, kdo to tak cítil, což je ten osudový mustek ke vzniku Data Brothers. Protože stejně tak to cítil i můj bratr Matěj Rešel, a to nás vedlo k tomu, že jsme společně založili firmu Data Brothers.

Dobře, takže taková rodinná firma.
Ano, založili jsme ji opravdu jako dva bráchové, takže jeden význam byl skrytý. Dnes už nás těch bratrů a sester je víc a firma mírně rozrostla.

A ještě prosím, kdy přesně jste Data Brothers založili? Jaký to byl rok? Přesněji – před necelými čtyřmi lety.

Takže posluchači si můžou procvičit odečítání roků, super.

A čím se tedy Data Brothers zabývají? Asi tedy Azurem a Microsoftím Data Stackem? Netřeba se ptát, co vás k tomu vedlo, vzhledem k tvojí profesní historii.

Ano, o tom jsme se už částečně zmínili. Chtěli jsme zákazníkům pomoci dostat z jejich dat co nejvíce užitku. Takže reporting byl vstupním kamenem. Řekli jsme si, že nechceme řešit datovou infrastrukturu ani úplný engineering, chceme dodávat hodnotu. Pomoci zákazníkům vytěžit maximum z toho, co už dnes mají. Tak bych to spíš popsal.

Já jsem se hodně zaměřoval na technickou stránku, brácha spíš na byznysovou, a dohromady nám to nádherně fungovalo.

Postupně se spektrum našich služeb začalo rozšiřovat. Více jsme začali přidávat Azure a další technologie.

Dnes bych řekl, že vlastně řešíme jednotlivé technologie tak, že máme vždy někoho, kdo s nimi umí kooperovat, abychom z toho vytěžili tu primární přidanou hodnotu.

Pokud chceš, můžu text ještě více upravit nebo zjednodušit.

Tady je opravený text:

Ale 2, 4, 4, co je dneska, je pořád primárně reportingová společnost, i když má už svoji inženýrskou divizi.
Jasně, a kolik lidí teď je ve firmě, která vznikla před čtyřmi roky a jedenácti měsíci?
Dneska je nás tam 26, pokud si dobře pamatuju headcount.
No tak to je docela dobrý.
Takže tento tým se skládá hlavně ze specialistů na různé části Microsoftího balíčku.
Tak asi takhle bych to zarámoval.

V rámci toho, co dodáváme, řešíme buď governance jednotlivých nástrojů, hlavně jak ty věci fungují dohromady, aby celá věc byla řízená. Aby nám nevznikly datové bažiny místo krásných, čistých datových jezer.
Aby uživatelé mohli dělat to, co mají, a byli podporovaní samotným nástrojem, bez zbytečných bariér, které tam nejsou potřeba – vše nastavené nějak vyváženě.

Zaměřujeme se také hodně na learning, tedy pomáháme dalším lidem rozvíjet se v jednotlivých nástrojích a posouvat si své kompetenční hranice.
Hlavně fungujeme jako L3 supportní tým.

To spolu souvisí i s tím, co jsi zmiňoval předtím ohledně MVP a aktivit.
Ano, samozřejmě. Stále také řešíme reporting ve velké míře – stavíme reporty na míru, přepisujeme je, optimalizujeme tak, aby zákazník opravdu dostal vysokou přidanou hodnotu.
Velká část našich lidí jsou konzultanti se specializací v různých byznysových oblastech, aby opravdu chápali KPI a konkrétní prvky, které daný byznys potřebuje.

K tomu se nám už nějakou dobu rozvíjí krásná inženýrská větev, respektive už ji máme. To je také hodně kvůli Fabrice, respektive službám Azure, které se vyvíjejí v průběhu času.

Nemyslím tím jen Fabriku, která je u nás od jara minulého roku, ale také například Microsoft Synapse, což bylo zajímavé zakrabičkování – spojení, jak chcete říkat – několika nástrojů dohromady.

Proč taková věc vzniká? Proč bych chtěl spojovat technologie pod jednu záštitu? Na jednu stranu se to může zdát jako konkurenční strategie vůči dalším paralelním nástrojům (které nebudeme jmenovat), ale zároveň to řeší některé problémy, které firmy značně řeší – třeba integraci mezi různými nástroji.

Když pro jedno řešení potřebuji 15 různých nástrojů a potřebuji mezi nimi zajistit synchronizaci a integraci, tak chci mít moderní datový stack.

Ano, přesně tak. Najednou vznikají velké náklady na lidi, kolik toho musí umět a jak s tím pracovat. A v Azure zjistili, že na jednu věc mají asi 12 různých nástrojů.

Skvělé, tak vendor lock-in je daleko víc cost effective.

Důležité je, zda je vendor lock-in. Dokud mám možnost vzít data jedním způsobem a není tam žádná průhledná bariéra – tak to není...

Pokud chceš, mohu text upravit dále pro větší plynulost nebo formální styl.

Tady je opravený text:

Plně vendor login.
Jasně, pravda.
S tím, že třeba když si vezmu ten Synapse, nebo Fabric, tak oni všechna data víceméně storilují v nějakých stretch accountech, což znamená, že je někomu předají třeba na ABS, tedy Amazon bucket S3, což je víceméně úplně to samé.
A prostě mezi nimi můžu vzít a dělat kontroly, cizí kontroly vlastní, pokud využívají stejné podloží. Tím myslím i formáty.
Třeba Parquet.
Třeba Parquet nebo historicky Avro. A teď jsem si určitě naběhl, protože už čekám, jak mi řeknou, že Avro není historický formát, Iceberg ho přece pod sebou má taky. Jasně.

Dobře, takže abych to uvedl na pravou míru, záleží na tom, jaký formát tam máme. Pokud jsme schopni data přenést, tak ten vendor lock-in není úplně tak velký. Je jasné, že za předpokladu, kdy se bavíme o tom, že tam proběhne nějaká customizace v jednotlivých systémech, tak se z toho odchází trošku hůř. Trošku.
No, každopádně, než tady začneme víc do hloubky probírat různé microsoftí technologie, můžeš mi říct ještě nějaké zákazníky, pro které jste třeba nasazovali něco na Microsoftu?
Jasně. Zákazníků je tam celkem dost. Ty, které můžu říct naprosto bez stresu, tak je třeba skvělá společnost Innogy nebo Lynette. To jsou zákazníci, se kterými se spolupracuje naprosto úžasně, protože mají krásné vize toho, čeho chtějí dosáhnout i se svými daty a opravdu ta data používají jako hlavní hnací motor.
Jo, mám radost, že jsou to zákazníci, kteří vědí, co chtějí, vědí, proč vlastně ta data sbírají, co s nimi chtějí zhruba dělat, jaké jsou další kroky, a v tu chvíli se to celé dá postavit opravdu krásně. Je mnohem snazší budovat datovou kulturu.
Jasně, dobře, rozumím. Hele, tak pojďme na ten Microsoftí datastech. Už jsme tady začali se Synapse, tak možná ten datastech nějaký vývoj měl. Už jak jsi začínal mluvit o Power BI, tak to je vlastně také víc nástrojů v krabičce – než říkám slepenina nebo něco, co by mělo negativní konotaci.
Takže oni těch krabiček historicky měli víc?
Ano, mají jich více. Musím říct, že Microsoft, když jednou tu krabičku vyrobí, moc se jí nezbavuje. Prostě zůstávají při ní nebo přendávají funkce z jedné krabičky do druhé. Nebo vytvoří krabičku okolo jiné krabičky. A v tom se člověk může pořád rozhodnout, zda vezme tu menší krabičku, nebo tu větší.

Důvod, proč se tohle děje, je ten, aby kdokoliv měl stále možnost vzít si jakoukoli drobnou část, když ji opravdu potřebuje. Když ale nechce řešit integrace nebo kosty mezi nimi, může si vzít tu větší krabičku, která to zabalí celé. Většinou ale nemusí využít všechno.
Jo, ale stejně si to můžu složit i sama do krabičky – prostě to zabalit a svázat mašličkou.
No jasně.

Takže Synapse, pojďme si říct první krabičku, kterou tady máme na programu.
Takže máme storage account Gen 2, respektive je to Azure Storage account s podporou hierarchických jmenných prostorů (hierarchical namespaces), čímž se jiná...

Pokud chceš, opravím nebo doplním dál.

Zde je opravený text s úpravami pro lepší srozumitelnost, gramatiku a stylistiku:

K tomu říká právě Gen 2. Vedle toho byl Azure Data Factory, který se k tomu připojil, což je samo o sobě určitým způsobem taková forma slepeniny, protože když to vezmeme takhle, je to Azure Data Movement Service, vedle kterého je vytvořen mapping data flow – tedy ETLko. Ano, je to nástroj, který měl, nebo myslím, že má stále za cíl vlastně převést Azure SQL Server Integration Services do cloudu. To, že tam některé věci stále chybějí, může být buď z toho záměru – říct si, že je hezké, že se teď pouští spousta PowerShell skriptů, ale pojďme to vidět trochu jinou optikou, zhodnotit, jestli je to pořád potřeba, a jestli třeba můžeme použít Azure Functions, například. A jak to vlastně co nejvíce přesunout do cloudu, protože Microsoft, jak víme, je silně orientovaný na cloud. Ano, je. Všechny nástroje, které tam jsou, jsou primárně směřovány k tomu, aby se používaly plně v cloudu. Ale co se týče zdrojů on-premises, Microsoft má asi nejlepší podporu i pro tyto věci, ne? Když si vezmeme třeba Microsoft SQL Servery, ty tu jsou vlastně dodnes, stále se rozvíjejí, vytvářejí se nové verze a pořád se na nich pracuje a opravují se chyby. I proto je důležité, aby Microsoft tento tandem podporoval. A když se podíváme na investice, které Microsoft dává do cloudového řešení a vývoje, jsou to úplně jiné částky. Jasně, jsou tu i hybridní aplikace, řekněme. No dobře.

Po Synapse, tedy po jedné z významnějších datových platforem, přišel Fabric jako vlastně náhrada za Synapse? Dá se to tak říct? Ne, určitě ne jako náhrada. Nejdřív ještě k Synapse – což jsme tam nezmínili –, tam byl vlastně serverless SQL, teď nebudeme řešit, jak je realizován na pozadí, ani čím, ale rozhodně nemůžeme říct, že by příchodem Fabricu Synapse skončil nebo byl nahrazen. Fabric je spíše další část, spojení více nástrojů, kdy se na to koukalo tak, že už máme konkrétní prvky, máme i nějakou integraci s Power BI, která byla v Synapse už také přítomná – i když spíše okrajově – ale už tam vznikaly třecí plochy. Týmy si často nerozuměly, každý koukal na jiné uživatelské rozhraní, spolupráce byla jiná, v každém nastavení bylo něco jinak. V Synapsech jsme při práci s SQL endpointy řešili, jestli máme brát data z těchto endpointů, nebo pokud jsou to referencované externí zdroje – jestli se má přistupovat přímo k nim. Co když jsem potřeboval sáhnout ještě něčím dalším, například Sparkem, který je extrémně populární? Jak to celé uchopit? Proto došlo k vytvoření větší platformy, alias Microsoft Fabric, kde máme Azure Data Factory, která už se objevila několikrát, máme z inženýrského pohledu Synapse jako základ pro datové sklady (warehouses), máme tam Sparkové nástroje jako joby i notebooky, Power BI, a...

Pokud chcete, mohu pokračovat v úpravě nebo doplnit celý text podle potřeby.

Jasně, tady je opravený text s lepší plynulostí a srozumitelností:

Máme tam reálný čas přetažený Azure Data Explorer s jeho vlastním jazykem, což je Kusto Query Language. Je to takový hybrid mezi PowerShellem a SQL, asi tak bych to nejlépe popsal, pokud nevíte, jak to vypadá. Dále máme Azure Notifications pro přímé notifikace nad tím, co se nám v datech děje v reálném čase, klidně i Event Streamy. Tím pádem máme zpracování tohoto druhu dat.

Takže máme takovou all-in-one platformu nebo spíš „krabičku“, jak to Microsoft prezentuje. Fabric je totiž prezentovaný jako Data Platform Solution od Microsoftu. Lze tedy říct, že tady máme platformu.

Moc na to sice nevypadáš nadšeně…
Ne, ne, ne, ne. Za mě jsou samozřejmě nějaké drobnosti, které by stálo za to tam ještě dodělat, aby to mohlo být plnohodnotně přijímáno jako velká platforma, ale ty kroky směrem k platformizaci celku jsou obrovské. A jak se tam věci vyvíjely, rozhodně nechci nic hanit.

Co tam tedy chybí?
Jedna z věcí, kterou bych opravdu rád viděl v blízké době, je lepší verzování. Ve všech těchto nástrojích je problém, jak to verzovat. Tady máme integrace na Azure DevOps a GitHub, což je taková vtipná otázka, co z toho použít. Když jsme enterprise zákazník v Evropě, máme legislativu ohledně dat. Měli bychom tedy spíš sáhnout po Azure DevOps, protože tam mají servery v Evropě. GitHub už relativně také ano, ale s enterprise plánem, jinak by se data posílala do Ameriky, což by mohlo porušovat regulace týkající se datových hranic. Pokud jsme třeba v Německu, je to ještě komplikovanější, protože tam jsou přísnější regulace.

Když se vrátím k jednotlivým částem fabricu, které bych chtěl verzovat, každá z nich se verzově chová jinak. Takže mám hodně věcí v „krabičce“, které fungují spolu, jak mají, ale právě u verzování vše funguje jinak.

To, že se Microsoft rozhoupal k tomu, aby spojil tolik věcí do jedné platformy, znamená, že musel udělat složité rozhodnutí. Představme si, že na jedněch datech chceme pracovat několika způsoby najednou: například jako jednoduchý ETL tool (třeba Fabric), zároveň s PySparkem, dále pak číst data pro reporting, vybudovat plnohodnotný datový sklad pro transakční dotazy, řešit role-based security a podobně. Základová vrstva musí být tedy opravdu zajímavá.

To, co jsi uvedl, dává smysl, zvlášť když přidáš real-time, což je jiná disciplína.

V tomto bodě došlo k zásadnímu zajímavému rozhodnutí, že se vše postaví na Delta Tables, respektive Delta Lake tables. To znamená, že máme známou a open source technologii, kterou ale musí všechny prvky správně využívat. Jak známe Microsoft, určitě do toho přidali něco vlastního.

Pokud chceš, mohu to i více rozčlenit nebo více zjednodušit.

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

Tak, tu už to máme, dobrý. Myslím, že máme nějaké optimalizační mechanismy v rámci těch parquetů, které můžeme běžně použít, například Z-Order, což je poměrně běžný přístup. Microsoft ale pro své služby, aby fungovaly lépe, speciálně v oblasti prezenčního vyhledávání, vyvinul V-Order. To je další optimalizační mechanismus, který je ale proprietární.

Super, přesně. Jak ale tyhle světy jdou dohromady? Nezdá se to být porušení pravidel? Ne, protože načítání může probíhat stejně jako u jakéhokoliv jiného parquetu nebo delta formátu, jen data jsou uspořádána v jiné struktuře podle Microsoftí logiky. Všechno funguje pod nějakou Microsoftí logikou, ano.

Ale umějí to načítat všechny enginy, včetně třeba DuckDB. Tyto technologie jsou dokonce začleněné přímo do factory integrovaných runtime systémů. A ty runtime se neustále vyvíjejí, částečně díky komunitě na Twitteru – pardon, na platformě X, alias doublebackslash – kam přicházejí nové podněty.

Samozřejmě trochu žertuji s tím Twitterem…

Rozumím. Protože to, co komunita požaduje, se pak často dostane i do User Voice a následně je implementováno v dalších verzích runtime. Dává to smysl? Dává.

Dáte lidem platformu a nástroje, které potřebují. Budou chtít odejít? Záleží na mnoha faktorech. Především na tom, jak dobře platforma funguje, jaká je cena, zda splňuje jejich potřeby, jestli jsou lidé ve firmě na to školeni, a jaká je celková zkušenost všech uživatelů – vývojářů, koncových uživatelů, administrátorů... Je to složité.

Já bych takovou platformu nechtěl jen tak stavět. Je tam hodně proměnných, když se na to podíváš.

Takže nejsi Microsoft, takže... ?

Nejsem.

Můžeš tedy jen implementovat, nebo se na to alespoň částečně podívat.

Přesně tak.

Nebo psát příspěvky na X. Třeba. Nebo pomáhat navrhovat certifikace, které k tomu existují.

Skvělé.

Dobře, tak bych se ještě vrátila k té krabičce. Začali jsme tím, že tam chybí verzování. Z téhle otázky jsem se trochu odklonila, když jsem mluvila o celkovém fungování, ale určitě tam chybí i další věci.

Já mám ale pocit, že verzování tam vůbec nechybí. Spíš bych si přála, aby všechny funkce fungovaly v rámci verzování konzistentně.

Když vezmu třeba Lakehouse, což je důležitý prvek, na kterém to do značné míry stojí, tak když někdo vytvoří verzi, dostane jen prázdný JSON. To je super – taková „prázdná verze“. Nicméně často je potřeba si vypůjčit scripty od Kevina Chanta nebo Pavla Šilového, které je nutné zaem­bedovat, aby bylo možné z verze skutečně vytáhnout data.

Takže se to historicky prolíná úplně všemi směry.

Dobře, jaké jsou t…

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

Jasně, tady je opravená a trochu upravená verze tvého textu, aby byl srozumitelnější a plynulejší:

Je tam ještě něco dalšího nebo nějaké omezení, které vnímáš, třeba ne úplně dobře fungující věci, verzování apod.? Když vezmeme tuhle oblast, zmínil jsem tu jednou MKo, ten MKo vedle jazyka. Z pohledu pokročilých textelistů a Pavel Běkařů je velmi dobře přijímaný, protože ho využívají pro transformace. Samozřejmě přišel Fabrik, který se snažil zaměřit na to, aby dostal data dovnitř do Fabriku, nebo tam dělal transformace tak, aby s tím opravdu mohl pracovat kdokoliv. Jako jak kdokoliv? Třeba jakýkoliv vývojář?

Prostě člověk dostane oprávnění a nemusí třeba vůbec znát Python, takže ho nebudeme nutit do PySparkových notebooků, aby v nich něco dělal, ale dáme mu jiný nástroj. Pro transformační účely vznikl nástroj nazvaný Dataflow, resp. Dataflow Gen 2, který je postavený na MKo, tedy mashupovém enginu, jenž zpracovává číselnou definici toho, co se má stát. Můžeme v něm zakomponovat právě MQL jazyk. Pro tyto účelové transformace si vytočí lakehouse, kde se stageují data, a warehouse, který využívá potřebný výpočetní výkon.

Zní to dobře, ale náklady v momentě, kdy celý proces spustím, jsou vyšší, protože musím vytočit dvě entity navíc. Ty data nějak zpracují – buď je rovnou zapíšou někam, nebo je cílí tak, že se vrátí zpět do mashupu, který s nimi ještě něco udělá, co nezvládly předchozí dvě části, a pak to zapíše dál. Jedna taková "kostička" tak může stát třeba patnáctkrát víc než jeden notebook.

A protože se to často prezentuje tak, že super, napíšete si to v Dataflow, kde je opravdu vizuální UI – například řeknete: chci unpivotovat sloupeček – začnou pak lidi tvořit Dataflow. A přijde chvíle, kdy někdo řekne: "Fabrik vlastně nic neumí, zde máme pár Dataflow, kapacita běží na maximum, transformujeme pár set tisíc nebo pár desítek milionů záznamů." To je přesně problém toho, když někdo používá nástroj na něco, na co není určený. Jasné, to vůbec není k tomu určeno. Možná to ani nikdo dělat nemá.

Dataflow byly původně zamýšlené pro citizen developery – pokud si potřebujete něco rychle vyzkoušet nebo dostat data tam, kam potřebujete, použijte to. Ale pokud to má být produkčně stabilní řešení v rámci firmy dlouhodobě, tak nepoužívejte. Samozřejmě pokud jde o menší objemy dat nebo pokud není potřeba dělat příliš komplexní transformace, je to v pořádku.

Nakonec se tedy dostáváme k tomu, že máš používat nástroje na to, na co jsou určené. Myslíš si, že Microsoft tohle dobře komunikuje? Že je jasné, co je na co? Protože já se v tom docela ztrácím vzhledem k množství nástrojů, které mají. Je to poměrně komplikované, protože ne vždy je jasná vize a účel každého nástroje.

Kdybys chtěl, můžu ti s tímhle ještě víc pomoct nebo upravit konkrétní části.

Opravený text:

Počet týmů, které to vyvíjejí, je veliký a každý chce, aby byl jeho nástroj nějakým způsobem využívaný. Takže... ne. Musíš tomu rozumět hodně do detailu, abys byl schopný vůbec určit, že dobře použiješ Dataflow na tohle, ale na něco jiného zase použiješ něco jiného. Jasně, na něco použiješ třeba notebooky, nebo si třeba vypůjčíš pomoc úplně zvenku. A třeba když už tady mám Databricks, tak si zavolám je na pomoc, aby mi to předpočítali a vlastně mi to nezasáhlo do SKUčka toho fabriku. Protože tady jsou tyhle koncepty pořád krásně provázané. A já třeba ve fabriku z Data Pipelines můžu spustit job v Databricksech, který mi všechno zprocesuje, uloží si data pro své účely v rámci storage accountů, kam pak k tomu můžou přistupovat data scientisti a dělat tam cokoliv, co potřebují, i v rámci této vrstvy nebo případně vrstvy mimo fabrik. A já potom tuto část, kterou oni zprocesovali, můžu natáhnout do fabriku zase hrozně jednoduše. Takže i v rámci toho obřího Microsoftího stacku a všech nástrojů má smysl šahat i mimo. No jasně. A to už se dostáváme k tomu, co jsme tady ještě nechtěli říkat — k Databricksu, který Microsoft hodně tlačil, než vymyslel tady krabičku fabrik. Pojďme si ale, než to začneme srovnávat a než si řekneme, jestli mám teď všechno přesunout z Databricks do fabriku, říct krátkou odpověď: nepřesunujte všechno do fabriku, děkuju. Dobře, to už nemusíme řešit. Každopádně mě ještě zajímá, v jakých případech a pro koho se vlastně hodí využití čistě Microsoft fabriky, řekněme.

Mám, a teď přemýšlím, že chci používat třeba Power BI — pro koho je to zkrátka vhodné, v jakém případě je to pro mě dobré řešení? Jasně, v první řadě bych řekl, že pokud jsem firma, která kooperuje s Microsoftími technologiemi — a co to znamená? Mám třeba SharePoint, mám Teams, běžně využívám O365, mám své lidi nějak zvyklé na jejich nástroje — tak budu mít k této technologii poměrně blízko. Pokud chci používat třeba Power BI, jak jsi zmínila, tak Fabrik je poměrně logická cesta. Fabrik jako takový je poměrně dobrý pro menší až střední podniky, jak se dostat relativně levně k datovému skladu. Co to znamená levně? Nejnižší verze fabriků, to znamená F2. Jako formule? Ne, ne, F je prostě zkratka pro fabrik a 2 je počet SKU, který dostávám. Takže F1 verze neexistuje. To je super, máme 2, 4, 8, 16, 32, 64, až do 2048. Můžeme mít kolik chceme, třeba 30x F2. A co tedy zahrnuje nejlevnější balíček? Nejlevnější balíček zahrnuje úplně všechno, co jsme tady už vyjmenovali, zahrnuje i storage account pro data. Za data, která tam jsou uložená, platím zvlášť, ale bavíme se třeba o 2 TB, což je asi 20 dolarů měsíčně, takže storage není tak drahý. Storage právě není drahý, mám v tom Azure Data Factory, mám tam Spark, který můžu využít v tu...

Tady je opravený text s úpravou gramatiky a stylistiky pro lepší srozumitelnost:

Chvíli to jedu poměrně naplno, nejsem tam limitovaný tím, co můžu udělat. Mám tam limit na počet konkurenčních notebooků a celkový počet notebooků ve frontě. To znamená, že pokud mi běží aktuálně dva notebooky, nemůžu spustit další dva. Musím počkat. Prostě musím počkat, protože mám i nějakou frontu, která funguje dle principu first in, first out – tedy zpracovává se v pořadí, ve kterém přišla.

Mám tam nastavené logické pipeline. Mám možnost využívat jak lakehousy, tak warehousey, a dokonce i Data Explorer, takže tam mám i real-time data. Jasně, tedy celou tu "krabičku". Ale spíš mě zajímá, co se týče výpočetního času, což je velmi cenná měna současnosti i budoucnosti.

Mám tam dvě jádra, a co všechno na ně můžu v daný moment alokovat, to prostě udělám. Na F2 mám dvě jádra, na F4 čtyři jádra. A bavíme se o compute units, takže je to celkem slušné. Dokážu s tím udělat hodně muziky – opravdu hodně. Pokud tam pracuje člověk, který opravdu ví, co dělá, dokáže z toho vytěžit obrovskou sílu, protože Microsoft připravil ještě další specifické engine.

Například, když řeknu, jak dlouho mi trvá nastartovat sešnu v Databricks? Přibližně 15 minut. A tady? Asi 3 vteřiny. Proč? Protože je to nativní řešení. Microsoft servery běží 24x7 a jsou navržené právě pro tento tzv. native workload. V momentě se připojujete k už běžícímu stroji, ke své sešně. Ten stroj byl buď volný, nebo vám nastartuje nový, což trvá okolo 3,5 minuty.

Dobře, shrnu to: je to výhodné, pokud chci rychlý přístup k lakehousu, datovým skladům (warehouse) a analytickému stacku, který je poměrně rozsáhlý – a to za relativně velmi příznivou cenu. Což jsme ještě neřešili – model F2 v PSUGO (pay-as-you-go) stojí zhruba 6 000 Kč měsíčně, což je cenově výhodné. PSUGO model se platí po hodinách, což znamená, že to můžu přesně dimenzovat.

Pokud si zaplatím rezervaci (například na celý rok) pro dvě jádra dopředu, mám slevu 41 %. Takže bych řekl, že se to vyplatí, případně má smysl o tom přemýšlet.

Teď mě zajímá – mám Databricks a přemýšlím, zda všechno, co mám v Databricks, vzít a přesunout (migrovat) do Azure Databricks nebo Azure Synapse?

Jak říct – vždy hodně záleží na tom, co se snažíš vytvořit za scénář. Pokud v Databricks už máš výpočty dobře nastavené, máš tým, který je zvládá spravovat a jsou na to zvyklí, navíc máš vše optimalizované z hlediska ceny, pak nedává smysl migrovat. To říkám naprosto jednoznačně.

Pokud chceš využít Power BI, což tady bylo také zmíněno, tak Azure Synapse určitě nepohorší. Ale v Power BI můžeš natáhnout data z Databricks také poměrně jednoduše. Když si koupím třeba F2, tak v něm nemám Power BI k dispozici. Takže to stejně musíš...

Pokud chceš, mohu pokračovat a dokončit i poslední část textu podle potřeby.

Tady je opravená verze textu s úpravami pro lepší srozumitelnost, plynulost a gramatiku:

Licencovat to musíš stejně. Abych měl pro uživatele vlastně licenci, bavíme se o F6400 a vyšších třídách. To zní jako hodně vyšší kategorie než F2. Ano, to je takový... No a cenově je tam potom rozdíl opravdu značný?

Při rezervaci si zarezervuju jádra na rok, že? Jasně. Když si zarezervuju těch 64 jader na rok a skutečně je alokuju, tak to vyjde asi na 81 dolarů měsíčně. Proč se nebavíme v korunách? Ne, protože v dolarech to zní lépe, chápu.

Pokud se nebavíme o PSvU, pak je to něco kolem 8000 korun. Jo, jasně. To už jsou jiné časy.

Takže když už mám něco nastavené a funguje mi to úplně v Databricks, tak nemá smysl to migrovat do Fabriku. Rozumím. Stejně tak, pokud tam mám ve Databricks Unity katalog, tak je migrace úplná blbost.

Jasně, ale co se týče nových uživatelů, Fabrik je vlastně odpověď Microsoftu na Databricks – je to něco, co dělá skoro to samé, ale ve vlastním prostředí Microsoftu. Ano, dá se to tak říct, přitom Databricks máme i v Azure, že jo, taky v jejich prostředí.

Jo, ale tam Microsoft přichází o výpočetní čas a podobně. No, jak se to vezme, protože bych řekl, že v Exceltech... No jasně, ale typický příklad je Hyperscaler, který…

Víš, kam mířím? Jo, myslím, že ano. Nevím, nevím, jestli to teď vybruslím.

To je dobré.

Hele, řekl bych ještě jednu důležitou věc, která se poměrně zásadně liší – když si vytáhnu data z některých Microsoft služeb. Teď si například chci začít tahat data ze zákoutí...

Ze zákoutí? Jakého zákoutí? Řeknu si, že chci vytáhnout data z interních API Power BI.

No tak, to je jiné.

Abych to mohl vůbec udělat, musím se tvářit jako uživatel. Kde ale vezmu uživatelský token? Jak ho generuju, když mám OAuth 2? No to nevím.

Pokud to chci dělat jako běžný uživatel, tak je to těžké. Jsem schopný token udržovat až 90 dní tak, že si zahraju na vývojáře, který uživateli jednou otevře pop-up okno a získá refresh token – 90 dní si pak můžu token obnovovat, pokud to admin nepřekazí.

To zní složitě.

No, jsme datoví odborníci, víme, jak se s daty manipuluje. Všechno samozřejmě v rámci pravidel. Ale v tu chvíli si hodně hraju s těmi tokeny.

Speciálně v tak velkém prostředí, nedej bože, kdyby někdo takhle postupoval u admina. V tom případě bych radši použil service principály, to dává větší smysl. Jenže ne všechny endpointy se dají zabezpečit přes service principály, protože nejsou pro ně podporované. Tokeny, které se vracejí, jsou jiné. Některé endpointy nemají podporu oprávnění pro service principály nebo je neposkytují.

Pokud chceš, můžu text ještě styličky upravit, aby byl více formální či naopak hovorový.

Tady je opravený text s odstraněním gramatických a stylistických chyb, aby byl text plynulejší a srozumitelnější:

No a v tu chvíli třeba ve Fabriku máme krásnou knihovnu, která se jmenuje Notebook Utils. Původně se jmenovala MS Spark Utils, ale byla přejmenovaná. Tato knihovna mi vlastně umožňuje využít sešnu uživatele, který vyrobil ten notebook. To znamená, že já jako autor propůjčuji notebooku svoji sešnu a kdykoliv ho spustím, jsem schopen si token vzít a použít ho proto. Ale já jako vývojář jsem to tam fakticky dal a neměl by mě někdo takhle jednoduše naklonovat.

Nejde o refresh tokeny, jde o to, že jsem vývojář, dávám to tam a přemýšlím, k čemu bych to měl použít – třeba ke komunikaci s Azure Key Vaultem. To je služba, do které si můžu uložit jen ty své tajné klíče, aby se k nim nikdo jiný nedostal, a odtamtud si je pak bezpečně vytáhnu jako string.

Dobře, a co se teda týče toho, o čem jsme mluvili, tedy Databricks? Tohle například v Databricksu takhle jednoduše neudělám.

Jo, mně to taky nepřišlo moc jednoduché, aspoň ne to, co jsi říkal.

No, u TLS.credentials je to sice technicky jedna knihovna a jedna funkce, a hned mám secret vytáhnutý.

Dobře.

Takže z té stránky to můžeme říct, že je to docela straightforward. Samozřejmě pokud má uživatel dostatečný přístup ke Key Vaultu.

Integrace Databricksu a Key Vaultu ale už tak straightforward není.

Takže ve Fabriku je výhoda, že má lepší komunikaci s Microsoft stackem.

Překvapení.

No naštěstí žádné překvapení není, ale je dobře, že to tak je.

Já vím, protože to tak nebylo vždycky.

Jo, tyhle komunikace se taky postupně pořád zlepšují, a protože je to jeden z důvodů, proč vznikají takovéto nástroje, je fajn, že se toho drží.

Tak mohl bys dát nějaký souhrn, jak je možné, že se Databricks a Fabrik spolu kamarádí?

Jasně. Za prvé spolu komunikují na úrovni toho, že Fabrik je schopen spouštět Databricks joby.

To znamená, že když potřebujeme, můžeme z Fabriku relativně jednoduše prostřednictvím Data Pipelines pár kliknutími poslat trigger jobu. Co všechno ten job udělá a jaká data k sobě pustí, je už na něm.

Jo, takže tato komunikace tam funguje. Stejně tak, když už mám Databricks v Azure, tak většinu dat ukládá do nějaké Azure databáze, cyklové databáze, nebo do storage accountu. Tam pak můžu opět z Fabriku přistupovat buď přes shortcut, nebo přímo přes nějaký endpoint či mirrorovanou databázi.

Takže tam může být vzájemná komunikace, přičemž změněný shortcut funguje v podstatě na vyžádání.

To je nová fíčura?

Ano, je to stejný shortcut jako na počítači.

Aha, rozumím.

Prostě máš na ploše shortcut na nějaký program, a úplně stejně se chová tenhle. Jakmile se tam připojím, podívá se na zdroj uložiště a ukáže, co tam je.

Takže pokud já pošlu job na Databricks, ten to spočítá, vrátí výsledky, pipeline mi řekne „super, máš to tam“ a spustí například Spark notebook, který už...

Pokud chcete, mohu text ještě více upravit nebo zkrátit podle cílové potřeby.

Opravený text:

Ta data v lakehouseu jsou shortcutnutá na to, co vrátil ten Databricks. Takže já vlastně můžu využít i ten Databricks pro výpočty. Například když chci pracovat s opravdu velkým objemem dat a přitom mít malý fabrik, nechci za něj moc platit, třeba verzi F2, a chci využít například jenom pro warehouse, tak mám tuhle možnost. Vlastně si můžu sáhnout přímo na ten Databricks, který provede ty velké výpočty, udělá mi tam všechno, a potom mi je naservíruje na stříbrném podnose, a já si s nimi pak dělám, co chci dál. K tomu můžu postavit GraphQL, protože to je další věc, kterou nám fabrika k tomu nabízí.

Jo, jasně, takže to spolu docela hezky kamarádí a na nějaké pokročilejší datové operace můžu stále využít Databricks a nepatlat se s tím na jednom místě, ano. A i Microsoft to prezentuje na konferencích, takže tahle integrace bude mnohem větší, že by měla přijít podpora Unity katalogu a všeho. Takže vůbec provázaní těch nástrojů můžeme očekávat ještě víc.

Skvělý. Nicméně, když už mám data zpracovaná, ne úplně hotová, ale teď s nimi chci něco dělat a dostat je mezi uživatele, kteří je potřebujou, tak přirozeně sáhnu po Power BI, že jo? Prostě reportovací nástroj. Když už se chci držet tohohle ekosystému, tak bych asi měl. Když mám verzi F62, F64...

F64.

Jo, pardon. Tak v tu chvíli by dávalo největší smysl používat Power BI, protože za viewery už neplatím. I menší společnosti Power BI používají, mají jenom licence třeba pro editory. Ale jasně, v tu chvíli...

Sáhnu po Power BI a tam si udělám jakoukoliv vizuální vrstvu, kde mi hodně pomáhá to, že ve fabriku se u každého lakehouse i warehouse automaticky staví semantický model. Ze semantického modelu můžu rovnou stavět reporty, protože u každého lakehouse i warehouse si mohu v UI vyklikat relační vazby, vytvořit si tam míry v DAXu, případně dnes už i role v security vyklikat a rovnou to dostat do reportů. Pokud k tomu warehouse přistupuji samostatně, mohu si normálně otevřít ciklový endpoint a poslat si tam jakoukoliv formu security, kterou potřebuji. A pak Power BI můžu použít buď ve webu, tedy webovém rozhraní, nebo v desktopové aplikaci a vytvořit jakýkoliv formát, který chci.

Jenže víme, že Power BI je dlouhodobě vnímáno jako takový „PowerPoint pro data“.

Jo jasně.

To řekl někdo, ne?

Ano, to dokonce zaznělo z úst jednoho z Microsoftích vlastníků této technologie, čemuž všichni moc děkujeme. Od té doby se to trochu koriguje, protože původně to řekl záměrně, aby to přiblížil uživatelům na manažerské úrovni, že je to vlastně hrozně jednoduché – s kliky, klepy, dragem a dropem. Bomba. Ale v odborné komunitě to způsobilo trochu rozruch, protože spousta datových expertů říká: „Super, ale je to jen vizuální nástroj.“ Tady je krásně barevný...

Tady je opravený text s lepší strukturou, gramatikou a interpunkcí:

Grafiky. Takže, vzhledem k tomu, že na pozadí toho pořád běží nějaká sloupcová databáze, nějaký Vertipák, máme tam zmíněný DAX pro tvorbu té semantické roviny, máme tam pár query pro nějaké transformace, už takhle, když to jakožto jenom jmenuju, se toho stihne mnohem víc než jenom to, že si tam klikám, klikám, draguju a dropuju.

Jako OK, teď tam vyrobím relační vazby na klikání – dobrý, hezký. Ale když si z toho na chvilku vynechám ten fabrake a měl bych jenom Power BI, tak jsem schopen v rámci Power BI si sáhnout na libovolný API endpoint, stáhnout jakákoli data, nakombinovat je právě díky Power Query dohromady a vlastně si postavit v podstatě účelovou databázi přesně pro ten daný scénář. A ještě k ní před ní jako plácnout semantickou rovinu, aby z toho mohli uživatelé dostat ty správné odpovědi.

Ale jasně, ve finále, ať chceme nebo nechceme, vizuál prodává. To znamená, že pro spoustu lidí to asi vždycky bude jen takové to klikátko a vizualizátko, i když se tam dá vlastně udělat mnohem víc. Co je víc? Tady to, co jsem jmenovala – že můžu vlastně naintegrovat všechny ty věci dohromady. Můžu si tam zastavit práci data engineeringu, který by mi normálně měl připravit data.

No jasně, takže z toho může vzniknout nějaké self-service údělátko třeba. Ano, může mi vzniknout nějaký self-service nástroj nebo nástroj, který bude mířený pro departmental BI, pro team BI – to znamená pro nižší segmenty – jenže na druhou stranu to může sloužit i pro corporate reporting. Samozřejmě v tu chvíli je ale dobré, aby to nevyvíjel někdo na koleně, ale někdo, kdo tomu opravdu rozumí, protože pod tím krásným hávem pořád běží Analysis Services.

A Analysis Services už tady poměrně dlouho běží v tabulárním režimu, kde se bojuje o slušný výkon vzhledem k tomu, co se s daty kontinuálně provádí. Jasně, zmiňovala jsem self-service, tak asi by stálo za to říct, že self-service má mnoho podob. V hrozně velkém množství lidí ho strašně chtělo. Jo, chceme self-service pro naše data. Co to ale znamená? Že si každej může sáhnout na všechna data? Jako je tam třeba Franta nebo Maruška v účtárně, co si prostě sáhnou třeba na IT logy? K čemu jim to bude? No úplně k ničemu.

Nebo třeba to, že si někdo vyjede platy všech lidí ve firmě – to by asi taky nebylo úplně nejlepší. Samozřejmě záleží, v jaké firmě. Jasně, ale už tady musíme stáhnout nějaké bezpečnostní výraznější pohledy. Určitě. Ale když se bavíme třeba o tom, že mám nějaké oddělení, třeba v bance, a teď nejde udělat report, který slouží všem, ale jsou tam uživatelé, kteří vědí, co z toho chtějí dostat, potřebují mít pohromadě datové zdroje a třeba si poskládat svůj vlastní pohled – třeba potřebují vědět držby na pobočkách a nejčastěji nakupují… zboží, nevím, něco takového.

Super, v tu chvíli už máme aspoň věci, co z toho chc…

Pokud chcete, mohu text dále upravit a dokončit podle potřeby.

Zde je opravený text s lepší interpunkcí, gramatikou a stylistikou:

Musíme je dostat. A teď vlastně, kde ta data jsou? Pokud máme i popsáno, kde ta data jsou a jestli s nimi pracovat – pokud máme nějaký krásný datový katalog, bylo by to skvělé. Pokud víme, kdo ta data vlastní, máme datové stévárdy a jsme schopni se k nim přesně dostat, abych kdykoliv mohl zjistit, kde jsou tvoje data, a dostal odpovědi, bylo by to fajn.

Tohle ale není moc častý případ, že by lidé nebo firmy měly ta data v takovém pořádku. A to ani na úrovni těch menších týmů, řekněme pomyslně menších, jako třeba Power BI, versus pak větších konceptů na celé platformě. Tam už jsou tyto problémy většinou mnohem větší. Velmi často se bavíme o takové formě buď totálního punku, nebo řízeného punku, či něčeho mezi tím – kdy bereme, že dobře, víme, kde data zhruba jsou, víme třeba, kdo je většinou vlastní, ale nejsme schopni říct, kam přesně data vždycky dorazí. To je bohužel velmi častý scénář.

Ale máme tady nějaké lidi, kteří to alespoň dozorují, zkoumají, zda se náhodou někdo nedostal k datům, ke kterým nemá přístup, nebo nedělal něco, co nemá. Pokud se aspoň toto děje, můžeme se už bavit o tom, jak to je víc řízené.

Samozřejmě krásný scénář, který se také občas děje, je ten, že máme nějaké IT oddělení, které nastavuje nějakou správu dat (governance), jak se celé tyto týmy mají používat, a dozoruje to z pohledu nějaké expertízy. Většinou však tyto záležitosti obstarává BI tým, který pak připravuje například jednotlivé "gold" datasety, připravuje někde dokumentaci a vždycky poskytuje data, která lze bezpečně použít. V tu chvíli můžeme mluvit o self-service a je to krásná myšlenka, ale za ní je strašně moc práce.

No jasně, těžko uskutečnitelná. Ale už jsou firmy, které tam třeba jsou a funguje jim to. Asi bych neřekl, že jsou na tom úplně stoprocentně, ale existují určité úrovně zralosti (maturity levely), které lze identifikovat. Když se firmy rozhodnou jít tímto směrem a postupují v těchto úrovních, je to hrozně zajímavé pozorovat – opravdu, jak postupují po těch stupních.

Málo kdy jsem zažil, že by firma přišla a řekla: „Nejdřív nastavíme pravidla, než budeme zavádět nástroj.“ Většinou vidím něco naopak – „Zavedli jsme nějaký nástroj, a potřebujeme teď nějak koordinovat, zjistit, jestli to někoho zajímá.“ Ukazuje se, že je složitější to celé pak koordinovat než samotné zavedení nástroje na začátku. Ale trend se pomalu obrací.

Minimálně z toho, co já vidím, čím dál víc firem přichází s tím, že chtějí nějaký nástroj zavést. Například Fabrik má pár lidí, kteří s tím experimentují, vytvářejí nějaké workspaces, a teď už vlastně narazili na tenký led – nevědí, co si mohou dovolit, jak bude třeba fungovat nastavení oprávnění. Nestálo by za to nejdřív řešit celková pravidla? A skutečně tohle začínají firmy řešit.

Pokud chcete, můžu text ještě více upravit podle konkrétního stylu nebo zkrátit.

Opravený text:

Ptát se na tyhle otázky je hrozně hezké. To je super. Hrozně mě to hřeje na srdce, když pak fakt přijdou v obavy, zabývají se tím koncepčně a opravdu chtějí – teď dělají všechny ty kroky, aby to pak mohlo fungovat. Takže jsem ráda, že existují. Existují a je jich víc a víc, což musím dodat. Už jsem jednou vybruslil z otázky na kopilota, ale ráda bych ji tam teď hodila. Tak co ten kopilot? Který? Jaký? No ten Microsoft. No který? Já nevím. Protože je to problém – jich je spousta. Super. Jenom ve fabrice jsou asi čtyři. Proč? Aktuálně. Protože natrénovat jeden model, který bude umět všechno, je těžké. No, já bych řekl nesmyslné, ale...

Asi tak. Za prvé, kopiloti v rámci fabriky jsou vázaní na licenci. Jo, takže třeba v F2 vůbec nejsou, ne? Nejsou tam všichni. Jo, takhle. Dobře, ať se tady nebavíme o všech, nebo o čtyřech, dobře, tak můžeš. Já bych vyjmenoval, co teď tam máme. Jeden je v Power BI, který má sloužit pro prezentační vrstvu. Jo, že mu řekneš, co chceš v Aby udělat, a on vygeneruje report. Jo, jo, takže to je vlastně takové instantní. Ano, v podstatě ano. Tak to je jeden. Druhý, který tam potom je, je pro více Power Query, který jsme tady zmínili, ten jazyk M, právě v tom Dataflow. Dobře, takže mi má poradit s Mkem – chci transformovat data, vyextrahuj mi to nebo cokoliv. Pak tam máme pro SQL v Warehousech. Jasně, takže prostě generuje SQL, případně vysvětluje kód. Jo, jasně, ještě jsme tam měli i explanatory. A samozřejmě v rámci Power BI existuje dlouhodobě – i když to tak nebylo vždy označováno jako kopilot – nástroj pro DAX, který umí zase vygenerovat kód, vysvětlit, co dělá. Ale že by ti odpověděl na otázku, když přijdeš třeba k Pythonovému notebooku a zeptáš se, co se tam změnilo od tvé poslední návštěvy, to ne. To nedá, ale to by byla dost užitečná věc. No, to jo. Obecně to funguje a dělá, co slibuje. Na stupnici od jedné do deseti takhle – za předpokladu, že položím prompt správně, tak umí poskytnout relativně relevantní výsledky. Z pohledu člověka, který kód radši píše sám, protože má plnou kontrolu – bere to jako ztrátu času. Má pod tím úplnou kontrolu, a proto to vnímá jako relativní ztrátu času. Pokud už se bavíme o nasazování něčeho většího, aby to bylo fakt cost-effective, tak řeším každou milivteřinu, která se exekuji. Když pak srovnám kódy a on mi vyplivne něco, co stojí třeba 27 vteřin, a já to napíšu pod vteřinu, tak je to velký rozdíl. No, no, no. Když si vezmu jiný pohled a to je ten costovej, tak představa, že mám jednoho vývojáře, který si dopisuje s chatbotem, který mu vlastně má psát jeho práci, a při tom mi stojí zhruba třetinu nákladů na to SKU a bojíme se o F64 v daný okamžik, tak se mi to vůbec nelíbí. Protože takhle tam budou sedět tři a mám 90 % kapacity v trupu a spadne mi nápověda do skladu. Těch 30 % jsem samozřejmě trochu přestřelil …

Jasně, tady je opravený text s lepší srozumitelností a plynulostí:

Lidi, ale pokud tam pokládáte jeden dotaz za druhým, tak se to stát může. Takže mě hlavně zajímá, jak daleko jsme od toho slibovaného scénáře. To znamená, že já vůbec nic nevím a teď, samozřejmě trochu přeháním, ale jako pilot, nebo ať už je to pilot nebo nějaký jiný AI agent kdekoliv, mi strašně ulehčí práci, udělá za mě polovinu, nebo já nevím kolik — teď říkali, kolik procent času práce to zabere. Jsme od toho asi ještě kus cesty. Nemůžeme čekat úplnou automagii. Z pohledu toho, že chci dodat co nejefektivnější kód, bych řekl, že jsme hodně daleko. Ale když to vezmu z hlediska toho, že potřebuji splnit zadání nějakým způsobem, tak nejsme daleko. Myslím, že dnes už to dokáže splnit zadání, ale je to nebezpečné. Je to extrémně nebezpečné třeba v rukou juniora, který to začne brát jako dogma. Buď to bere jako dogma, co mu to vrací, jak se má ten kód psát, nebo když nerozumí vygenerovanému kódu, nemůže ověřit, jestli výsledky jsou správné.

Jeden takový příklad: relativně nedávno kolega Kurt Buhler alias Data Goblin vydal článek o copilotovi ve firmě. Budu citovat přímo jeho část, kde se ptal na DAX, tedy semantický jazyk. Zeptal se copilota pětkrát a dostal pětkrát jiný kód a ani jednou správný výsledek. Super, tedy funguje to velmi dobře, že? Tam je právě ten problém, že psát kód, který tvoří semantickou rovinu, je docela složité. Když máme model o sedmdesáti tabulkách — i když je to staré schéma — pořád může být problém z extrémního množství konfliktů. A potom je potřeba se bavit o tom, jak začít tvořit modely, které budou mít slovníky, aby tyhle AI agenty mohly používat k generování správných věcí.

Takže mám dělat svou práci dvakrát jen proto, abych se mohl na tu věc zeptat jako chatbot? Ne, děkuji, rozumím. Takže message pro komunitu je asi taková, že psát kód sám se pořád víc vyplatí než si chatovat s chatbottěm. Určitě. Pokud jsem junior, měl bych se tomu raději vyvarovat. Pokud jsem zkušený vývojář, můžu to použít k úspoře práce, k vymýšlení nějakého konceptu, který si pak třeba dodělám. V tom nevidím problém. Většinou nebo aspoň něco vygeneruje. Máme třeba GitHub Copilota, který má celkem dobré povědomí o kódovém prostředí a na základě toho, co jste napsali, vám dokáže našeptat alespoň jeden řádek nebo doplnit část funkcí, které pak dopíšete sami. Takže super, píšete část kódu a dopisujete zbytek. Nějaké zefektivnění tam je. Ano.

Pak samozřejmě už vznikají věci jako GitHub Spark, ale to sem dneska asi nepatří a ani nemáme čas to řešit.

A co vás čeká v Data Brothers? Co máte v plánu? Na co se těšíte?

Pokud chceš, můžu ti ještě pomoci s nějakými stylistickými úpravami nebo shrnutím.

Opravený text:

Těšíme se, že v květnu, což je sice relativně nedaleko, ale stejně relativní období, připravujeme druhý ročník konference Datapoint Prague, která je zaměřená na všechny datové technologie z Microsoftího prostředí. Na tom teď pracujeme poměrně intenzivně a doufáme, že se nám podaří navázat na úspěch loňského ročníku. Budeme rádi, pokud se tam setkáme s mnoha novými tvářemi, a pokud se vše podaří, příští rok už rozšíříme zaměření i mimo Microsoftí stack.

To zní skvěle. Posluchači, v květnu vás tedy čeká konference – call to action!
A já ti, Štěpáne, děkuji za rozhovor.
Já také všem moc děkuji za poslech a Štěpánovi za pozvání sem do Data Talku.
Děkujeme, že jste doposlouchali až sem, a díky také našim partnerům a členům Data Talk klubu:
Index, Saska, By Street, Colors of Data, Revolt BI, Good Data, Keboola, Emark, Karl Data Company, Data Mind, Notino a A Flow.

Pokud chcete být v obraze o české datové scéně a globálních datových technologiích, nezapomeňte se registrovat k odběru našeho týdenního newsletteru na datatalk.cz.
Nechť vás provází data.