Podcast

Dobrý den, mé jméno je Jirka Wicherek a vítám vás u dalšího dílu podcastu Data Talk. Mým dnešním vzácným hostem je Ondřej Bote, výkonný ředitel pro Foundation Data and Analytics ve společnosti MSD. Ahoj, Ondřeji.

Dobrý den, ahoj Jirko.

Dnes se s Ondřejem budeme bavit o tom, jak se změnil svět, jakou revoluci přinesly velké jazykové modely do data engineeringu a generování insightů, tedy do věcí, které má Ondřej posledních deset let v MSD na starosti, a o platformách a celém tom základu. Podíváme se na to, jak vlastně přistupovat k generování insightů, k tomu, aby data přinášela hodnotu, a jak nově stavět celý tento proces, protože paradigma se výrazně posunulo s velkými jazykovými modely a dnes agentními systémy.

Než se dostaneme k současnosti a budoucnosti a budeme si povídat o tomto posunu, prosím, představ se našim posluchačům – jak jsi přišel k datům, kde to všechno začalo, a také jak jsi vlastně nastoupil do MSD, kterému jsi věnoval deset let – gratuluji k tomu výročí.

Děkuji za gratulaci! Měl jsem to štěstí, že jsem se datům věnoval vlastně vždycky. Moje kariéra tedy vždy mimo univerzitní vzdělání. Moje univerzitní vzdělání je z Vysoké školy ekonomické, obor finance, bankovnictví a pojišťovnictví, takže jsem byl úplně mimo IT. Při prvním zaměstnání, kdy jsem nastoupil do ČSOB v absolventském programu Křepelky, jsme měli možnost si vybírat, kam chceme pracovat. Já jsem tenkrát měl dvě nabídky, dvě volné pozice, a vybral jsem si úplnou náhodou pozici juniorního projektového manažera při řízení implementace datového skladu. Navzdory okolnostem, nevím jak, od té doby celá moje už 23 letá kariéra se točí kolem dat.

Zaujalo mě to, protože data jsou přísně logická věc, což vyhovuje mému způsobu myšlení, a proto jsem se tomu věnoval. Po ukončení Vysoké školy ekonomické na fakultě financí jsem nastoupil do ČSOB, kde jsem pracoval na datovém skladu v celé řadě různých rolí. Implementovali jsme datový sklad nad Teradatou, používali jsme Informatiku a Microstrategy jako technologie a prošel jsem si řadou rolí. Začínal jsem jako projektový manažer, poté jsem byl takzvaným datovým mapperem, role, která dnes už neexistuje. Mapoval jsem zdrojové systémy do cílových datových struktur bankovních.

Jak jsem to řešil? Jeden člověk mapoval, to znamená určoval, které pole v zdrojovém systému se uloží do cílového datového modelu. Ten cílový model byl přísný bankovní datový model Teradaty či jiných společností, do kterého se musí data správně mapovat. Já jsem psal pravidla, jak se data transformují do cíle, a pak přišel ETL developer, kterému jsme říkali ETLer, který podle mého zadání naprogramoval exekuci v Informatice. Poté jsem to testoval, opravoval chyby, což byla zajímavá práce, protože bylo třeba velmi dobře rozumět logice datového modelu, který, troufám si říct, má přes tisíc tabulek.

Pro představu – to je striktní datový model, každá informace je tam možná pouze jednou, člověk opravdu musí přesně najít správné místo. Pokud tomu tak není, změna datového modelu je sama o sobě velký projekt, protože je potřeba všechno přemapovat. To byla moje druhá role po juniorním projektovém manažerovi.

Dále jsem v ČSOB pracoval na dalších věcech – vyvíjel a definoval reporty na základě dat. To byla logická cesta. Měl jsem data ze společností ČSOB, a tak jsem byl schopen zadat požadavky na report a vytáhnout data do reportovací struktury.

Co mi z toho dnes zůstalo? Je to klasický přístup k datovému warehouseingu: máme zdrojové systémy, stage, nějaký target, data manager a report. Vše jsem dělal manuálně, z role projektového manažera nebo při tvorbě reportů jsem dělal mapování a komunikoval se zákazníkem.

Po třech a půl letech v ČSOB jsem se přesunul na krátkou dobu do Deloitte. Tam jsem pracoval v Deloitte Regional Data Center, což jsem si představoval jako enormně velký datový sklad pro 16 zemí, zatímco ČSOB byla pouze jedna země, takže to byl posun.

Zde jsem se naučil, že může být úplně jiný přístup: místo Datěj, jsme běželi na SQL serveru, místo Informatiky jsme tvořili úlohy ve SQL a prováděli ETL procesy. Pochopil jsem, že objem dat nedefinuje tolik počet zemí, ale komplexita byznysu a zdrojových systémů. V Deloitte mě to bavilo, byly to skvělé zkušenosti, ale komplexita byla nižší než u regulovaného subjektu, jakým banka je. Konzultační byznys nemá tolik zdrojových systémů, ani banka, která má více finančních produktů, zejména ty finanční trhy jsou složité.

V konzultačním byznysu prodáváme lidi zákazníkům, a komplexita je tam z datového hlediska nižší než v bankovnictví. Deloitte byla super, stále mám tam kolegy, se kterými se potkávám.

Po osmi měsících až roce mě oslovila IBM. Důvodem bylo, že v Deloitte jsme používali reportingový systém Cognos, který dnes už neexistuje v původní podobě, ale je součástí Watson stacku od IBM. IBM kupovala Cognos a hledala lidi. Bylo to asi před 18 lety, tedy zhruba kolem roku 2008–2010. Cognos byl tehdy špičkový reportingový nástroj a používalo jej 60–70 % velkých firem. IBM v Praze měla centrálu pro střední a východní Evropu, hledala někoho, kdo bude prodávat a podporovat Cognos, a já jsem do toho šel.

Měl jsem zajímavý náborový pohovor, kde jsem manažerovi řekl, že neumím instalovat software, ale umím pracovat s daty. On řekl, že mají mnoho lidí, kteří umí software instalovat, ale nepracovat s daty, a že já jsem ten, koho potřebují. Tak jsem do IBM nastoupil.

V IBM jsem začínal s reportingovým nástrojem, pak jsem pracoval s plánovacím nástrojem – Cognos Planning, který na českém trhu byl velmi známý, protože jej používala řada firem. Pracoval jsem s TM1, což byl nástroj používající MDX oproti SQL, což byla pro mě nová oblast. Pracoval jsem se SPS-kou, Clementinou a dalšími nástroji na řízení rizik. Postupně jsem rozšiřoval portfolio nástrojů od reportingu až po business analytics.

Současně jsem jako člen softwarové skupiny pracoval i s nástroji na tvorbu datových skladů, ETL nástroji a zpracování dat. Měl jsem možnost pracovat i s Netezou, takže jsem si rozšiřoval datový stack.

Byl jsem na správném místě ve správný čas; IBM v té době byla velmi silná, tzv. “velká modrá”. Moc rád vzpomínám na kolegu Honzu Sovku, s nímž jsme byli hrdí na tuto firmu.

Dalším velmi podnětným rozšířením bylo přesunout se z českého trhu na regionální zastoupení. Měl jsem možnost cestovat po různých zemích, poznávat různé kultury i odvětví. Někdy jsem byl v Rumunsku a diskutovali jsme o použití Planning nástroje v ocelářském průmyslu, což není má expertíza, a druhý den jsem byl v České republice a řešil jsem reportingové řešení pro telekomunikační firmu.

Ta různorodost byla obrovská. Bohužel, nebo naštěstí, jsem si uvědomil, že lidé, se kterými jsem pracoval, byli technologicky lepší než já. Já jsem měl skvělé znalosti SQL, MDX, ale nová generace znala nové koncepty a technologie. Pro mě bylo těžké odnaučit se starým věcem, zatímco mladí kolegové to měli v krvi.

Zjistil jsem, že technologicky jsou rychlejší a lepší než já, ale já jsem přinášel přidanou hodnotu v tom, že jsem věděl, co se má udělat a jak zapadá do většího celku.

Proto jsem si uvědomil, že bych mohl být týmovým lídrem, který udává směr a koordinuje týmy, spíše než technickým specialistou.

A díky štěstí MSD tehdy otevřela technologické centrum v Praze. Přihlásil jsem se na pozici lídra reportingových řešení v týmu data science. Mým prvním úkolem bylo doručovat a standardizovat generování insightů pro uživatele data science projektů.

Během svého desetiletého působení v MSD jsem si vyzkoušel mnoho technologií a rolí a nakonec se dostal na svou současnou pozici, kterou jsi uvedl. Nedávno jsem byl vedoucím core engineeringu pro CDN.io; mám na starosti vývoj datově analytického systému z hlediska schopností a funkcí, který se používá napříč MSD při implementaci datově analytických projektů.

Moc gratuluji! Jsi první v Data Talk podcastu s touto pozicí, dáme to určitě do sekce „Gossip“. Chtěl bych se zeptat, co to přesně znamená v organizační struktuře – pod kým sedíš, jak vypadá tvůj tým? Abychom to zařadili, zejména pro ty, co se neorientují v americké korporátní struktuře. Je pozice executive director nad headem a tak dále? Co tato tvoje současná role zahrnuje, kdo je tvůj nadřízený a jaká je tvoje odpovědnost?

Zorientovat se v mezinárodní firmě jako MSD je velmi složité. Máme mnoho divizí, různých oddělení a IT struktur. Je třeba vědět, že jsme opravdu globální firma. Technologická centra máme v Americe, Praze, Singapuru, Hyderabad v Indii – orientace v organizační struktuře je tedy náročná.

Pokusím se zjednodušit. Sedím v IT, nikoliv v byznysu, což je první důležité upřesnění. Dále máme centrální IT a divizní IT. Já jsem v centrálním IT. V centrálním IT sedím v organizaci jménem CDN.io, což je Central Data Analytics, a před půl rokem jsme přidali Office – Central Data Analytics Office. Asi znáte CDO, což u nás máme kombinaci CDO a CDN.io.

Jsme zodpovědní za CDO, což je můj nadřízený, a zároveň vyvíjíme analytický systém jako takový, máme to kombinované.

V rámci CDN.io mám odpovědnost za to, aby analytický systém a celý ekosystém fungoval dobře. Když něco nefunguje, náš tým vyvíjí řešení tak, aby cílem bylo umožnit, aby kdokoliv mohl začít dělat analýzu co nejdříve, někdy už nazítří – aby zákazník nečekal dva měsíce, než dostane prostředí.

Je to běžné u reportingových nástrojů, ale u datových projektů a jejich komplexity je to výzva.

Druhým cílem je, aby ten správný uživatel měl analytické prostředí co nejrychleji k dispozici a mohl generovat insighty v co nejkratším čase, tzv. time to market.

Dalším cílem je rozšířit skupinu lidí, kteří jsou schopní obsluhovat analytický systém.

MSD od počátku, když zde v Praze na Smíchově otevřeli pobočku, vnímám jako centrum excelence – byla to opravdu velká věc. Spoustu lidí z prostředí startupů prošlo MSD a byla to pro ně škola velkého IT, velkého byznysu a velké škály.

Vždy mě překvapovala komplexita a obrovská škála činností.

Podívejme se nyní blíže, protože budeme mluvit o tom, jak se svět změnil. Myslím, že je dobré říct, z jaké pozice k tomu mluvíš, protože tvá zkušenost zahrnuje různé vertikály, typy use caseů a odlišné domény.

Prosím, vtáhni nás do MSD a té komplexity.

Určitě. Na začátek bych tě opravil: MSD nebyla velká věc, MSD je velká věc. Neustále se vyvíjíme a používáme nejmodernější technologie, abychom se posouvali.

Popíšu, jak MSD funguje a kde ta komplexita vzniká. MSD je farmaceutická společnost, která je strukturovaná tak, že máme tři základní oddělení, která ještě násobíme dvěma.

Máme výzkum, tedy research, kde opravdu vymýšlíme léky a hledáme nové molekuly, nové látky, které mohou být účinné a fungovat. To je, jak si umíme představit, velká vědecká práce vykonávaná lidmi s backgroundem v chemii, biologii a pracujícími s daty ve velmi specifických formátech. Pracuje se tam s genomem a veřejně dostupnými databázemi, jde o velmi specifickou oblast…

Činnost. Více výzkumu a vývoje už to být nemůže. To už asi opravdu ne.

Druhou věcí je, že samozřejmě, když někdo vymyslí lék nebo nějakou látku v tento moment, tak musí někdo přijít na to, jak ji vyrábět. Zajímavý problém je, že vlastně něco vymyslet, co se vyrábí ve zkumavce, je něco jiného než to vyrábět ve velkém, takže musí proběhnout nějaký proces uvažování o tom, jestli to vůbec jde vyrobit a jak to vyrobit.

Pak přichází velká část firmy, která je vlastně supply chain, tedy zásobovací řetězec, která lék vyrábí, a regulace kolem té výroby je velmi striktní. Protože tady se vlastně bavíme o lécích pro lidi a u každé dávky, u každého léku musí být stoprocentní jistota, že je v pořádku.

Takže jsme vlastně v supply chainu ve výrobě, která je velmi komplexní z principu, ale zároveň striktně regulovaná z důvodu ochrany zdraví lidí.

Když se zamyslíme nad datovou stránkou věci, tak co toto generuje, je nám asi jasné, že to je za prvé úplně něco jiného než výzkum a vývoj, a za druhé datové objemy jsou enormní, protože skutečně musíme monitorovat, mít informace o každém šarži a o každé produkci daného léku.

Historicky musíme být schopni kdykoliv doložit celou historii, kdyby se něco stalo, takže ty datové objemy jsou opravdu obrovské.

A když je lék jednou vyrobený, tak ho někdo musí prodat, a to je ta třetí část. Tam je to vlastně asi to, co všichni známe víc – je to marketing, obchodní činnost, prodej a zase tam je datový objem velký a úkoly jsou úplně jiné, typicky v oblasti marketingu a obchodu.

Řekl jsem, že to nakonec znásobím dvěma, protože máme jednu divizi, která vyrábí léky pro lidi, a druhou část firmy nebo divizi, která vyrábí léky pro zvířata. A i když se na první pohled může zdát, že je to totéž, už z pohledu regulativy je to samozřejmě úplně jiné z logiky věci.

Další zajímavý koncept u výrobků pro zvířata je, že u zvířat můžeme měřit, jak se zvířata mají, jak jsou zdravá nebo nejsou zdravá, podle jejich chování.

To znamená, že může docházet k datové monetizaci produktů, které v oboru nazýváme „wearables“ – tedy zařízení, které zvíře nosí a které ho pravidelně monitoruje a poskytuje informace o jeho chování.

Což samozřejmě, jak si asi dokážeme představit, u lidí není úplně vhodné nebo běžné. Takže jsou to na první pohled stejné věci, ale regulace, objemy dat a informace, se kterými se pracuje, jsou zcela odlišné.

Váš systém tedy pokrývá všechny tyto oblasti? Je to něco jako all-in-one?

Mým cílem je, abychom v našem oddělení postavili systém tak, aby pokrýval všechny tyto oblasti. Samozřejmě ideálem by bylo mít jeden systém, ve kterém se řeší všechny úkoly.

Pravda je ale taková, že to nikdy nebude možné. Řešíme tedy klasickou situaci, kdy jsme schopni pokrýt přibližně 80 % potřeb, a pak samozřejmě jednotlivé divize logicky mají své specifické potřeby a systémy, které neskalují napříč divizemi ani napříč celou firmou.

My to máme tady hodně zjednodušené, protože na tom příkladu s upáčeným lékem říkáme, že není jen jeden typ upáčeného léku.

Je jich vícero a každý řeší jiné úlohy a tak dále. To bych přirovnal k tomu, jako kdybych řekl, že v těžkém průmyslu vyrábíme stroje a je jedno který. Není to tak, je to velmi, velmi rozdílné.

Stejně tak i ve výzkumu jsou různé typy výzkumů: jeden pracuje s genomem, jiný úplně jiným způsobem, takže datová základna je skutečně různorodá.

To mi přijde fascinující a rád bych se dostal do detailů jednotlivých věcí, ale na to tady nemáme prostor. Pro mě bylo důležité ukázat, s jakými doménami, různostmi případů užití, dat a problematik ve své práci pracujete.

A když už jsme u toho IT, které pro to staví platformu, pojďme k tématu: mám pocit, že tuto pohádku opakujeme poslední dva a půl roku, ale za poslední půlrok se to materializuje natolik, že kdo to nevidí, ten podle mě nemá v oboru co dělat.

Jak se tedy změnil tvůj pohled na data engineering, datové pipeline, na stavbu takových systémů, které jsou schopné pokrýt takto různorodé potřeby? A co to říká o světě BI, datové analytiky a data engineeringu? Pojďme se na to podívat. Je to velké téma, začni, odkud chceš, myslím, že máme o čem mluvit.

Změna je skutečně velká a nejen velká, ale i rychlá. To je takový obecný výrok, který může říci každý.

Já bych začal tím, jak se změnil reporting za posledních deset let a zkusil na to napasovat, jestli se data engineering nemění podobně. To bude podle mě zajímavá úvaha.

Když jsem nastoupil do IBM, byl jsem technický presale na Cognos, tedy na reportingové řešení. Co to znamenalo? Znamenalo to, že jsme prodávali řešení IT divizím.

Chodili jsme za IT, říkali: „Máte reportingový systém? Nemáte? My tady máme Cognos, který pokryje vaše reportingové potřeby.“

Paradoxně to znamenalo – a už jsem to i trochu popsal, když jsem pracoval v ČSOB – že před deseti lety byly rozdílné role: jeden člověk dělal zadání reportu, nebo zadání datové pipeline, a druhý report naklikal a udělal.

Proto se reporty dávaly do IT, protože IT je vyvíjelo a byznys je konzumoval. To je dnes nepředstavitelné a úplně to narušuje agilní kontext, protože report se vyvíjel tři měsíce, a za tři měsíce už se potřeba změnila a chtěl se jiný report.

Takže tam vzniká technický dluh a ty reporty jsou nefunkční.

Co se tedy děje v reportingovém světě? Dějí se dvě věci. První je, že v posledních pěti letech se reportingová řešení neprodávají do IT, ale přímo do byznysu.

Jsou vytvořena tak, aby byznys uživatel, a teď používám široký termín „byznys uživatel“ – může to být byznys analytik, ad hoc uživatel – byl schopen si report sám vytvářet nebo alespoň upravovat.

Máme byznys uživatele, kteří nemají technické vzdělání, a i když někteří byznys uživatelé mají technické znalosti, principem je, že díky růstu vizualizačních nástrojů, jako jsou Tableau nebo Power BI, se reporty prodávají přímo byznysu.

To znamená, že nejdůležitější je, že insight si už generuje byznys sám.

Role IT se zásadně mění – IT už nevytváří insight, ale provozuje reportingové nástroje a snaží se je nabídnout co nejlépe.

Zajímavý příklad je, když založíte v bance nebo v jiné firmě nové oddělení – jak dlouho trvá, než můžete použít nějaký vizuální nástroj? Je to za hodinu? Nebo po třech měsících, protože IT musí udělat spoustu kroků?

Nyní se tedy role IT mění: už negeneruje insight, ale je provozovatelem nástrojů.

Další posun je v tom, že reportingové nástroje začínají využívat doporučovacích mechanismů. To znamená, že report není „hotový“ jako takový.

Já jako uživatel bych chtěl přijít ráno k počítači a říct si: „Co je nového?“

Když se podíváte, jak klasicky reportingový nástroj fungoval, měl červené hodnoty, a vy jste klikali na důvody červených signálů např. z důvodu nějakého produktu nebo regionu a dohledávali jste příčinu.

Teď je potřeba koncept změnit tak, že ráno přijdu, otevřu počítač a nástroj mi řekne: „Pojď se podívat, tady je problém – u produktu X nebo na trhu Y.“

Reportingové nástroje tedy generují insight. Mohou tak činit na základě nějakých událostí, anomálií v datech, například outlierů.

Další koncept je, že insight může generovat i někdo jiný – například regionální obchodník dostane upozornění, že ostatní regionální obchodníci sledovali nějaký datový pohled, který by mohl být zajímavý i pro něj.

To samozřejmě neznamená, že standardní reporty nebudou potřeba. Jsou oblasti, kde je mít musíme, protože musí existovat takzvaný single source of truth, alespoň na úrovni konsolidovaných metrik.

Ale práce s reporty se posouvá dál – do fáze, kdy insight už není statický report, ale dynamicky generovaný.

Myslím, že je důležité to vnímat jako posun od reportů, které vytváří IT, přes reporty, které vytváří byznys, až ke stavu, kdy reporty přímo nevytváříme, ale insight vzniká automaticky.

Tento posun je na trhu obecně akceptován a považován za správný.

Je zajímavé porovnat to s datovým inženýrstvím.

Já si myslím, že zatím jsme stále ve stavu, kdy většinu datových pipeline, zejména těch s byznysovou logikou, generuje IT.

Podíváme-li se na tradiční implementace, stále je zde datamart, který spravuje IT, tedy datová pipeline vytváří IT.

Časem bude docházet k posunu, že se tato činnost bude blížit byznysu, tedy tomu, kdo definuje datamart.

Protože, když uvažujeme paralelu s reportingem: kdo řekne, jaká data v datamartu mají být? Ne technicky, ale co vůbec tam má být.

To říká byznys.

Byznys zadává byznysovou úlohu a podle toho někdo navrhne datamart.

A zde přichází velký přechod.

Když už mám byznysovou úlohu, a mám nějaký systém – třeba LLM model – který umí tuto úlohu vzít, podívat se na data a vygenerovat odpovídající datové struktury, tak se dostáváme do stejného problému jako s reporty.

Když mám zadání: „chci vidět toto“, mám data a jsem schopný vygenerovat vizualizaci.

Tento posun zatím ještě není plně realizován, ale podle mě k němu bude docházet.

Myslím si, že budeme směřovat k tomu, že se datová pipeline bude sama generovat a data budou připravena tak, aby byla „AI ready“ – tedy data budou připravena tak, aby vizualizační nástroje, a teď už nemluvme pouze o reportovacích nástrojích, snadno konzumovaly data, věděly, co v datech je, jak je propojit a na základě toho generovat insight.

To je obrovská změna.

Současný stav trhu je podle mě takový, že datovou pipeline můžeme rozdělit na dvě části.

První částí je ingestová pipeline, tedy přesun dat z jednoho systému do analytického úložiště.

Opomeneme nyní možnosti jako data sharing či mesh koncepty, ale stále musíme mít data dostupná.

Generování ingestových datových pipeline je do jisté míry snadné a pro firmu přínosné.

V ingestové části zpravidla není byznysová logika, takže z podstaty nemusí nikdo detailně popisovat, co bude s daty dělat, protože jejím cílem je data jenom přenést na místo, kde budou k dispozici.

Automatizované generování těchto ingestových pipeline umožní standardizaci.

Dříve byla skupina lidí, která ingestová pipeline zaváděla.

To bylo velmi náročné a zdlouhavé.

Představme si, že tuto skupinu lidí nahradíme popisem toho, jak pipeline generovat, a systém si ji vytvoří sám.

Pro LLM modely je to triviální úloha – vytvořit kód dle zadání.

Generování pipeline je jen první krok.

Pokud chceme plně automatizovat systém, pipeline musíme i automaticky testovat, nasazovat a koordinovat s uživatelem, protože „human in the loop“ pravděpodobně bude potřeba.

Můžeme rozvinout i další oblasti, například automatické generování technických datových kontrol.

Můžeme automaticky zaregistrovat změnu zdroje dat, zastavit plnění datové pipeline a upozornit poskytovatele dat, ať už interního nebo externího.

Takže už jen v datovém ingestu lze hovořit, ačkoli jsme na hraně mezi agentním systémem a automatizací, o celé řadě automatizačních či agentních kroků, kde je potřeba činit rozhodnutí.

Je to krásná první úzká cesta, jak systém budovat.

Zároveň je tam nízké riziko, protože ingestová pipeline obecně neobsahuje byznysovou logiku, nebo ji tam mít nemusíme.

Pokud máme pipeline takto definovanou, je všechno v pořádku.

Můžeme tedy dojít k tomu, že standardní datová pipeline bude generovaná napříč všemi týmy a divizemi ve firmě.

To je standardizace, na kterou jste se ptal.

Dosáhneme toho, že centrální tým nebude mít backlog a byznys nebude muset zaměstnávat lidi na práci, která nemá byznysovou hodnotu.

Generování datové pipeline pak může být otázkou minut.

Protože pustit se do kódu není složité.

Další obrovskou výhodou je, když tento proces provedeme správně – a zde už hovoříme o vizionářském pohledu do budoucnosti – že si můžeme vybrat výpočetní engine, kde bude pipeline běžet.

Představme si situaci, kdy víme, co chceme dělat, známe nejlepší postupy a jsme schopni generovat datovou pipeline pro dva odlišné výpočetní enginy.

Proč bychom to chtěli?

Protože pipeline může být levnější, nebo výhodnější provozovat na jednom enginu než na druhém.

Volba závisí na objemu dat, jejich typu.

Jak jsem už říkal, máme mnoho typů dat…

(ukončeno v textu)

Zdravím vás všechny,

můžeme se bavit o nestrukturovaných datech. Vlastně ta datová pipeline může pořád zůstat stejná, nebo samozřejmě nebude stejná, může být generovaná, ale vybírám si ten compute engine na storage. Storage bych samozřejmě chtěl mít možná jeden, ale zase sharing mě umožňuje to propojit.

Takže k těm benefitům, o kterých jsem mluvil, se dá přidat ještě jeden, a to je, že optimalizuji cenu té datové pipeline tím, že jsem schopen dynamicky řídit, kde poběží. Tím pádem odpadá otázka, jestli je to velký nebo malý projekt. Protože při malém projektu nepotřebuji složité řešení, u velkého ano, a můžeme to dynamicky řídit.

A tohle se dá dělat samozřejmě i na začátku, že nějakým způsobem zanalyzuju, nebo přístroj zanalyzuje, kde by to bylo nejlepší. Ale datové pipeline se v čase mohou vyvíjet a já můžu mít nastavený expertní systém, který ty datové pipeline monitoruje.

Prvním cílem takového systému je proaktivně hlásit nekonzistence nebo nějaké problémy s kvalitou dat, tedy data health, aby bylo možné zastavit situaci, kdy by někdo přijal rozhodnutí na základě špatných dat. Což je skvělé, protože to ušetří mnoho úkolů lidem a umožní odhalit chybu daleko dříve.

To je takový hygienický faktor, který tam rozhodně má být. Když mluvíš o data health, pokud tomu správně rozumím, tím, že tyto pipeline nemají byznysovou logiku a jsou čistě v kódu, je dnes mnohem levnější a výhodnější je všechny generovat. Je tak levné je generovat, že tím odpadá velké strategické rozhodování na začátku, jako například: jaká data tam půjdou, kam compute umístíme, a zda nám ten compute vydrží rok. Nebo jestli za rok budeme stále používat stejný kód a tu pipeline a že přepnutí bude těžké kvůli logům na tenhle compute a nutnosti vše přepsat na jiný.

Dostáváme se tak do světa, kde je přepnutí lehké a můžu v čase dynamicky měnit řešení dle aktuálních dat, provozu, změny podmínek nebo ceny dodavatelů.

Je to podobné, jako jsi říkal u reportingu — v tradičním waterfall modelu je velké rozhodnutí na začátku, dlouhá analýza, protože to stojí hodně peněz, pak to děláme, a mezitím je realita vzdálená měsíce. Dnes se dostáváme k agilnímu přístupu, kdy díky zlevnění kódu můžeme některá rozhodnutí odložit do doby, kdy uvidíme, jak věci v reálu probíhají. A můžeme vyzkoušet obě řešení a vybrat to lepší, budoucího stavu, kam se chceme dostat.

Samozřejmě je tam spousta dalších úskalí, než jsme právě zmínili, ale v principu to tak funguje.

A teď bych se zeptal: jaký je podle tebe v březnu 2026 největší „bottleneck“ této budoucnosti? Mám totiž pocit, že technologicky to už docela funguje — například LLM modely generují hezký kód, máme základní agentní systémy, standardizaci a dokumentaci, víme, jak systémy postavit, ale přesto se to někde zasekne. Musí si někdo sednout k tomu systému, otestovat ho a nastavit, což není vůbec jednoduché.

Vygenerovat pipeline je jen jedna část, nasadit ji dynamicky do různých prostředí je druhá část, a pak mít přehled, kde a kdy ta pipeline běží, mít konzistentní informace o historii běhu a data lineage, to je to, co je komplexní. A pak existuje i ten human in the loop, protože i když je to ingestion pipeline bez byznysové logiky, následné insighty generované na těchto pipeline, které nazýváme data creation či data byznys logikou, z nich vycházejí.

A cokoli nefunguje, znamená, že všechno následující bude špatné. Systémy musíme prověřovat a ověřovat, že fungují správně, přičemž nebude nikdy stoprocentní jistota, protože LLM modely nefungují stoprocentně — je tam vždy riziko.

Jedna další věc je změna mindsetu, přístupu inženýrů. Představme si tým deseti inženýrů, kteří generují datové pipeline. Říkáme, že to vlastně může dělat pouze jeden, což je problematický přístup, protože ostatní inženýři budou říkat, že generovaný kód není tak dobrý jako ten, který napsali oni sami. Můžou mít částečně pravdu, nebo nemusí.

Chci tím ukázat, že change management je náročný jak na úrovni datových inženýrů, kteří systémy používají, tak na úrovni byznys stakeholderů, protože jde o přenesení a akceptaci rizika, že se to nepovede, že nebude tolik lidské práce a že nebude nikdo „za kým jít“, když něco nebude fungovat správně.

Já to ještě posunu dál a zobecním tento přístup. Na straně byznysu bychom měli datové pipeline generovat automaticky. Pak se můžeme podívat, co to znamená v rámci data creation.

Nebo se na to můžeme podívat i s načtenými daty — jak bych chtěl vytvořit datový produkt.

Lehce se tedy podíváme, že bych chtěl napsat v přirozeném jazyce, že chci datový produkt, který obsahuje určité metriky, dimenze a je za dané časové období. Nic nám nebrání takový datový produkt vygenerovat, pokud mám data popsaná a AI ready — tzn. vím, jaká data mám, jaké jsou metriky a mám nějakou kontextovou vrstvu nad daty, která dovede přeložit dotaz z LLM nebo AI do SQL.

Takže se skutečně dostáváme do fáze, kdy koncový uživatel definuje, jaký datový produkt chce, a on mu vlastně vznikne.

Pokud půjdeme dál, tak prvním krokem by podle mě mělo být, protože agentní systémy jsou zde, že uživatel nechce datový produkt, ale insight.

Když tedy použijeme tento přístup, uživatel řekne, že chce vidět konkrétní informaci.

Prvním krokem je zjistit, jestli existuje report nebo reportingové řešení, o kterém jsme už hovořili. Dnes nemusí být jen reportingový nástroj, odkud můžeme insight získat.

Druhým krokem je zkontrolovat, jestli není jednoduché obohatit reportingové řešení, aby ten insight vznikl.

Třetí krok je podívat se na existující datové produkty a zjistit, jestli insight tam není.

Čtvrtý krok je pokusit se kombinovat datové produkty dohromady a jeden obohatit.

Pátý krok je vytvořit nový datový produkt, pokud již nemáme zdrojová data.

Třetí krok potom je zjistit, že nemáme ani zdrojová data.

Nyní, když někdo zadá takovou otázku, mělo by proběhnout toto vše a v ten moment…

Vy generovat a stavět celý systém není vůbec triviální řešení, ale akceptace uživatelů, že takto bude celý proces fungovat, je klíčová.

Protože jsme vlastně přeskočili člověka, který dělá ETL joby, člověka, který nakládá data, člověka, který dělá změny v datovém modelu a člověka, který vytváří reporty.

To je obrovská změna paradigmatu, na kterou jsme zvyklí.

Dokonce už u reportů si na to zvykáme, proto jsem se snažil tu paralelu navázat.

Tam už jsme schopní přijmout, že se insight generuje.

Takže toto je ta velká změna, která dle mého čeká.

Spojit to všechno dohromady bude složité a bude to bolet — zejména kvůli inženýrské části.

Generování insightů můžeme nechat klidně na strojích, protože byznys už ví lépe, co chce.

Ale pokud přistoupíš na to, že ti zasahují do kódu, který jsi posledních deset let tvořil a generoval a teď dostaneš horší kód, který je však levnější, rychlejší a lze ho kdykoliv zahodit, to zasahuje do identity a smyslu tvé práce.

Určitě tomu rozumím.

Myslím, že posun bude mnohem větší a jeho dopady širší, než jaké jsi popsal ty.

Momentálně v data engineeringu nástroje pipeline vyvíjejí inženýři a byznys je spíše definuje.

Možná se posuneme k tomu, aby byznys byl schopen sám definovat datové pipeline.

V budoucnu IT bude vlastnit procesy a metodologii generování pipeline — ne prostředí, kde se píše kód, ale to, jak se generuje.

Byznys pak říká, jakou pipeline potřebuje.

To bude diametrální změna jak pro byznys, tak pro IT.

Práce v IT tu samozřejmě bude, ale bude zaměřena na to, jak nastavit pravidla, aby pipeline vznikala konzistentně přes všechny datové zdroje.

Jak mít vše pod kontrolou, jak ovlivnit generování pipeline tak, aby to nebyl black box, ale aby bylo jasné, kdy chceme striktní přístup, a kdy větší flexibilitu.

Ty nuance, které jsme zmiňovali na příkladu farmaceutické firmy, jsou různé požadavky, včetně regulatorních.

To znamená, že regulatorní reporting, který je po nás požadován úřady, nemůže být generován všude stejně s malými odchylkami.

Systém tak musí být správně nastaven.

To je těžké.

Ano, jasně.

Musíme vědět, jak systém nastavit tak, abychom dokázali dělat obojí.

Je tam hodně práce.

Cílem je, aby se byznys mohl věnovat byznysu.

Jak jsem říkal na začátku, v IT je cílem doručit byznysu rozhodnutí nebo insight z dat co nejrychleji.

A co nejrychleji znamená automatizovat generování s co největší pravděpodobností správného výsledku.

Nebo se rozhodnout, že někde generování nechceme.

Toto je směr, kam směřujeme, a proto je potřeba udělat mnoho kroků.

Zvláště pro generování insightů a datových pipeline se dnes trh zaměřuje na zvýšení efektivity datových inženýrů.

Jak jim pomoci, aby LLM modely dokázaly usnadnit generování datové pipeline?

První změna mindsetu je klíčová.

Nástroje jako Copilot pomáhají inženýrům psát kód rychleji.

My chceme být ve fázi, kdy se kód generuje automaticky a my ovlivňujeme proces generování.

Musíme „přepnout“ v hlavě a přijmout, že já jako inženýr nejsem zodpovědný za konkrétní kód, ale za to, jak se generuje.

Možná to bude výzva.

Je to podobné jako ve financích: finance jsou zodpovědné, že systém sedí, funguje, ale nejsou zodpovědné za to, jestli oddělení A nebo B vydělávají peníze.

Oni drží logiku a nastavení systému — core kompetenci.

Možná toto není úplně ideální příměr, ale kdo v datovém světě drží odpovědnost za to, že vše v dané doméně funguje? To je složitá otázka.

Zkusím odpovědět.

Říkal jsem, že IT je zodpovědné za to, že datová pipeline se generuje správně.

Aby to však umělo, musíme chápat data nad systémem.

Musíme tedy vytvářet kontextovou vrstvu, která zná, kde se která data nachází.

Tu už neděláme jen jako standardní metadata, tedy například „tato metrika znamená tohle, tento produkt tohle“, ale pro agentní systém, který na to kouká shora.

A ten systém, který generuje pipeline, musí rozumět, jestli určitá data jsou k dispozici, nebo ne.

Musíme mít tedy ontologie, taxonomie, vazby mezi objekty, aby AI engine či agentní engine pochopil, jaká data jsou, jaké mají souvislosti.

A zde je příměr, který jsi uvedl: někdo z byznysu musí udržovat vazbu mezi produktem a zákazníkem.

Musí definovat, co znamená zákazník a produkt.

Toto je práce na straně byznysu, ne IT.

Máme datové standardy, které něco takového popisují, ale zde mluvíme o kontextové vrstvě nad daty, která je až o dvě úrovně abstraktnější, aby ji jazykové modely uměly využít při generování.

A to je popis, který musí být na straně byznysu.

Je zajímavé, že byznys rád generuje reporty a strašně rád je také udržuje.

To, že udržuje kontextovou vrstvu, je nutná podmínka pro funkčnost agentních systémů.

Jakmile dojde k byznysové změně, musíme upravit kontextovou vrstvu.

Agent je pak schopen podle toho cosi přegenerovat nebo upravit.

Paradoxně budeme potřebovat nástroje, prostředí, mechanismy a procesy, jak byznys může udržovat kontextovou vrstvu nad daty.

Nejde tedy jen o popis dat, ale třeba o grafovou databázi, její rozhraní, definice ontologií a taxonomií, protože bez toho to nebude fungovat.

Takže zodpovědnost na straně byznysu se posune, ale máme datové stewardy, kteří mohou pomoci, takže se budeme dál posouvat.

IT bude zase zodpovědné za správnou funkčnost všech komponent tak, aby se insight či pipeline generoval správně.

A to v kombinaci s praktiky, které do systému zavádím, s kontextovou vrstvou nad tím, co generuji.

A zde stále nejsme.

I když jsme mluvili o data health, uvnitř firem to nemusí být tak růžové, jak se zdá.

To potvrzují i konzultační firmy, které zjistí, že situace je jinde.

Mě to však těší, protože práce je ještě hodně.

Ať si to tedy shrneme: jedna věc je dokument…

Ace, datový katalog, data governance – znovu mluvíme o tom, jak se z data governance stal ústřední princip z něčeho, co bylo nejvíce „fuj“ a spojeno s regulacemi a obtěžováním. Jak se díky datovým produktům a jejich rozšíření data governance stala nějakým ústředním principem, který pomáhá a není závislý na technologii, a najednou odemyká potenciál datových produktů.

Semantické vrstvy a popsání businessové logiky – to jsou všechno věci, které zde řešíme. Důležitost těchto aspektů skokově roste, včetně data governance, a musíme na to najednou nahlížet úplně jinýma očima a z úplně jiného úhlu pohledu. Je to evoluce principů, o kterých právě tady diskutujeme.

Měli jsme čistý waterfall model, kdy jsem postupně skládal jednotlivé části a nakonec získal report. Ten přechod je v tom, že potřebujeme lépe popsaná data, více metadata, protože do procesu bude vstupovat agent, který nám do hlavy nevidí. Klade se tedy větší důraz na věci, které v minulosti nebyly považovány za tak důležité, aby nám to odemklo potenciál. Nebo se na to mohu dívat špatně a celé je to převrácené, a některé koncepty jako data governance, dokumentace či semantické vrstvy je třeba zcela zahodit – protože staré koncepty, které tu byly dlouho a dávaly smysl v čistě logickém, analytickém světě, který šel chronologicky nebo jednostranně, už nejsou funkční v dnešní době totálních zpětných vazeb, automatizace a agility.

Velká otázka tedy zní: jaký koncept se ještě teď drží a lidé jej nasazují, ale ve skutečnosti je již mrtvý? Přemýšlel jsem, jak to formulovat. Jde o revoluci a evoluci zároveň. Je to samozřejmě evoluce, protože schopnosti LLM (velkých jazykových modelů) a kognitivních modelů postupně přibývají, ale zároveň extrémně rychle, což je právě ta revoluce. Dříve bylo tempo technologických změn mnohem pomalejší; dnes s LLM je to neuvěřitelně rychlé. Pro mě je rozdíl mezi evolucí a revolucí časový rámec. Z tohoto pohledu se mi těžko rozhoduje, zda jde o evoluci nebo revoluci.

Podle mě je však nutné o principech data governance přemýšlet úplně od samého začátku. Data governance principy by měly být začleněny již v prvním kroku generování datové pipeline. V této kontextové vrstvě bychom měli řešit například i bezpečnost (security). Nejde pouze o zjištění bezpečnostních aspektů, ale o definování, kdo k datům má přístup. To je opět součástí kontextu dat.

Měli bychom být schopni — a teď nemluvme o technologické implementaci, ale o konceptu — integrovat do kontextových vrstev informace o bezpečnosti, kdo k nim má přístup, zda jsou data citlivá, kdo je za ně odpovědný. Kdo spravuje ontologie, taxonomie, semantickou vrstvu – všechny tyto aspekty a kdo je datovým správcem (data steward) za dodatečné zdroje, které musí vzniknout. Z tohoto důvodu je důležité mít v těchto vrstvách pohledy datových stewardů.

Z tohoto úhlu pohledu si myslím, že jde o velký krok, protože množství aktiv a artefaktů, které bude data governance řešit, bude mnohem větší. Dokonce se můžeme bavit o určité správě těch modelů, které data generují – tedy o governance nad těmito modely. Kdo je správcem, vlastníkem modelu či agenského systému, který je generuje? To může být IT oddělení.

Opět je třeba mít nad tím striktní governance, která musí být prováděna. Potřeba začít dělat věci jinak? Myslím, že hodně záleží na konkrétní firmě.

Dnes máme všechny firmy data-driven, ale když se ptám na konferencích či přednáškách, kolik firem má skutečně data stewarda jako samostatnou dedikovanou roli a ne jen přidělanou k jiné činnosti, tak to může být zhruba 30 až 50 % firem. Není to stoprocentní. Myslím, že spíše ještě méně. Takže samostatných rolí je méně, záleží na prostředí, ale ukazuje to, že všichni víme, že data stewardship je důležitý. Bez data stewardshipu se velmi těžko funguje, protože nemáme businessového vlastníka dat, ale přesto takové role na trhu ještě nejsou.

Nyní navíc tento vývoj zrychlujeme a říkáme, že data stewardship možná nestačí. Musíme mít někoho, kdo vlastní a udržuje vazby – ontologie, taxonomie, kdo udržuje celý systém, kdo řeší bezpečnost a podobně. Jak rychle se dokážeme přizpůsobit tomu, že tito lidé nebo jiní převezmou tyto role, netroufám si odhadnout. Bez toho však hrozí, že nebudeme schopni důvěřovat výsledkům generovaným systémy, což je zásadní problém – jakmile se jednou ukáže, že výsledky jsou chybné, je to velký problém.

Proto si myslím, že se vyplatí začít generovat datovou pipeline již pro ingest (zpracování a nahrávání dat). Protože, jak jsme říkali, tam ještě není businessová logika, jde o technologickou část, kterou provádí IT, které například vlastně udržuje ty modely.

Při správném nastavení toho procesu je možné to použít a škálovat do dalších kroků. Problém je, že největší přidanou hodnotu pro firmu přinese generování insightu. Automatizace generování insightů urychluje proces primárně.

Mohu sice urychlit datovou pipeline a ingest, ale pokud mám například tradiční datový sklad, jehož releasy trvají tři měsíce, ani tak moc neušetřím, protože insight získám stále pomalu. Bude tedy opět soutěž mezi rychlostí a kvalitou.

Quick winy jsou obvykle až na konci procesu – vygenerování insightu, datových pohledů, se systémem dlouhodobě udržovaným, s kontextovou vrstvou, dobře popsanými daty, s jasným určením, kdo má k nim přístup, atd. To je běžný problém, který řešíme dnes a denně, a který řešíme už více než deset let ve firmách. Může mít nyní ještě větší dopad, i když si možná vždycky říkáme, že při každé technologické změně bude vše jiné.

Líbí se mi, jak ukazuješ, že svět se změní, ale zároveň říkáš, že to bude trvat. Aby systém a celé prostředí nově fungovalo, bude třeba postavit základy, a to bude vyžadovat mnoho práce a hodně hodin chytrých lidí.

To mě vede k tomu, že mimo jiné vyučuješ na VŠE na ITN Business. Co tedy říkáš studentům? A druhá část otázky zní: co to znamená pro současné data inženýry, co bys jim poradil? Mám pocit, že když mluvíš o štěstí, bylo štěstí, že jsi si uvědomil, že ostatní píší kód rychleji a lépe, a proto jsi se věnoval vysvětlování businessu směrem nahoru. Toto uvědomění čeká mnoho dalších lidí.

Začnu teda otázkou na data inženýry. Myslím si, že část data inženýrů se budou muset stát „data neinženýry“ (tedy zaměřit se více na business). Protože, jak jsme říkali, systém se bude rozdělovat – někteří inženýři budou rozumět businessovému kontextu, budou vědět, co chtějí, a budou schopni ověřit, zda byla práce správně provedena; to je ta neinženýrská část.

Generování datové pipeline a udržování kontextové vrstvy nemusí být jednoduché. Jde o posun směrem k většímu porozumění datům. Mnoho data inženýrů díky své práci s daty jim totiž paradoxně velmi rozumí, protože musí řešit technické problémy v datové pipeline, zda něco duplikuje nebo nefunguje – to jsou detaily, které business často nezná.

Často tedy data inženýři nejvíce rozumí datům, mají významný potenciál vydat se cestou businessu, říct, že chtějí být ti, co mají oblast dat na starost, rozumějí jim a udržují kontextovou vrstvu. Generování datové pipeline by pak bylo spíše doplňkem.

Druhá část data inženýrů se bude muset zaměřit na udržování systému tak, aby datové pipeline byly generovány správně. Jinými slovy, budou řídit, co musí být obsaženo, jaká pravidla platí, a případně systém rozšiřovat o své vstupy – ne přímo do jednotlivých datových pipeline, ale tak, aby bylo jejich generování správné.

Jde o mentální posun a většinou jde o víc technickou roli. Na druhou stranu to je evoluce IT – stále větší abstrakce.

Kolik dnešních inženýrů řeší, jak se něco počítá přímo na maticích? Historie IT je příběhem abstrakcí – od hardwaru přes software až k psaní v high-level jazycích, a dnes s LLM to radikálně zrychlujeme tím, že píšeme v přirozené řeči, která se propisuje na nižší úrovně softwaru a hardware.

Souhlasím plně.

Jen se vrátím k otázce revoluce nebo evoluce. Nejsem si jistý. Na mnoho změn jsme měli hodně času. Teď to nevíme.

Nevím, jak rychle budoucnost přijde, ale každý musí být připraven. Já osobně měl v IBM deset let (nebo osm let) na to, udělat si toto uvědomění. Myslím, že nikdo už takový čas mít nebude. To je ten rozdíl revoluce, o které jsme tady mluvili.

A co se týče studentů, kteří studují například na VŠE v programu Data and Business, mají se ještě učit SQL? Dobrá otázka.

Z mého pohledu je odpověď ano. Program Data je skvěle strukturovaný, protože kombinuje praxi s teorií. Student si v něm může uvědomit, co ho skutečně baví – jestli spíše businessový kontext nebo technický.

Studenti si musí uvědomit, že nepotřebují „unlearning“ (tedy přeučení, vymazání starých vzorců), protože nejsou zatíženi legacy technickými dovednostmi jako my v IT. Oni naopak na tyto věci jen nahlížejí z hlediska své budoucí práce.

Pro ně tedy koncept klikat si datovou pipeline nemusí ani existovat.

Pokud studenti mají možnost kombinovat praxi a nahlédnout do fungování systému, mají mnohem větší možnosti volby, stejně jako jsme měli my na vysoké škole.

Skvělé.

Ondřeji, moc děkuji. Jsem velmi zvědavý. Na tebe čeká zajímavý čas. Žijeme v zajímavé době, která je tak rychlá, že přináší mnoho příležitostí a zároveň rizik.

Děkuji, že jsi nám na základě svých zkušeností a know-how přiblížil jednu z velkých změn, která čeká datovou analytiku, BI a celý tento svět.

Těším se, že se brzy setkáme a probereme, co z toho se naplnilo, jak to vypadá v praxi, kde jsou úzká místa (bottlenecky) a co se podařilo vyřešit snadněji a rychleji, než jsme čekali.

Moc děkuji za možnost si s tebou povídat.

Děkuji.

Děkujeme, že jste nás doposlouchali až sem. Děkujeme také našim stálým partnerům a členům Data Talk klubu, kterými jsou SASka, TV Nova, Direct Technologies, Good Data, Myton, Colors of Data, Bistreet, Flow, Karl Data Company a Intex.

Děkujeme moc za podporu a nechť vás provází data.