Podcast

Dobrý den, moje jméno je Jirka Vicherek a vítám vás u dalšího dílu Datatolku. Mým dnešním hostem je Jan Ulrich ze společnosti Manta. Ahoj, Honzo.
Ahoj, Jirko, děkuji za pozvání.

My tady do Datatolku zveme datové odborníky a datové profesionály. Tam určitě patříš. Manta jako velmi důležitý datový nástroj vznikla tady v Česku a dobývá svět. Ty máš v Mantě titul, pozici VP of Research and Education. Možná bych začal tím, co vlastně děláš a co máš na starost?

Dělám toho spoustu. Podle tohoto titulu mám na starost market research, to znamená, kde je trh s daty, respektive s metadaty pro nás, kam se ubírá a kam si myslíme, že by se měl ubírat. A zároveň také edukaci, protože data lineage, o které se budeme bavit, je relativně nová nebo pro některé neznámá oblast. Myslíme si, že je potřeba ji víc vysvětlovat a propagovat, proč má hodnotu. A to mě těší, protože to bude hlavním tématem našeho dnešního rozhovoru.

Mám taky pocit, že data lineage je nový pojem pro něco, co tady existuje dlouho a dlouho tady bude. Tak se těším, až do toho skočíme.

Než se budeme bavit ale o Mantě, vaší nabídce a use casech, zajímá mě, jak ses vlastně dostal k tomu být data lineage VP of Research and Education? Jaká byla tvoje cesta?

Ta cesta byla minimálně pro mě dost zajímavá, ale vlastně se celý svůj profesní život pohybuju v datech. Ať už to bylo u ETL nástrojů, hlavně ETL nástrojů, a technického pre-salesu, kde jsem měl příležitost poznat prostředí spousty zákazníků a problémy, které řeší na denní bázi.

Ty jsi byl pre-sales pro Clover ETL?
Přesně tak. Bylo to velmi zajímavé, ale zároveň jsem poznal svět i z konzultační stránky u zákazníka, kde jsem se účastnil migrací například v O2 nebo ve spořitelně.

Všechny tyto příležitosti mě obohatily a zjistil jsem, že stále řešíme do značné míry ty samé problémy. A to je právě zpráva našeho datového prostředí, hlavně těch datových pipeline, jak říkáme tomu, kudy data tečou nebo přes co data tečou. A to mě vlastně přivedlo do Manty.

V Mantě jsi asi neměl rovnou titul VP, to přišlo až teď s vaším velkým a rychlým růstem, kdy obsazujete tyto pozice. Jaká byla tvá první role v Mantě?

Přišel jsem do Manty dělat technický pre-sales a vybudovat tento tým. Byl jsem tam jediný pre-sales konzultant. Jak jsme rostli, budoval jsem pre-sales tým v Americe a začal budovat i technickou část customer success týmu.

S postupným růstem nemohl vše dělat jeden člověk, takže jsem si ponechal tu část, která mě baví asi ze všeho nejvíc. To je povídání o tom, k čemu Manta je, respektive o konceptu data lineage.

Manta je vlastně prostě… [text končí]

Pokud chcete, mohu pokračovat ve formátování nebo pomoct s dalšími úpravami.

Opravený text:

Díky, jak data lineage řešit efektivněji. Super, to mi skvěle nahráváš, tak začněme s data lineage. Odkud se to vzalo, čím je to součástí nějakého takového kontextu, by mě zajímalo. Jak jsem ti říkal před nahráváním, Manta pro mě byla hrozně zajímavá tím, že do mého světa přišla právě s tím pojmem, mám to s ní přímo spojené. Je to pro mě nějaký nový buzzword, ale přitom mi přijde podstata věci vždy platná. Tak za jaký konec to vlastně Manta uchopila a jak teď ten trh vypadá? Já právě strašně nemám rád buzzwordy.

A teď doufám, že se z data lineage buzzword nestane, i když na druhou stranu je to samozřejmě k ničemu dobré i přesto, že to buzzword je. Ale máš pravdu, data lineage je něco, co je zde konceptuálně vlastně strašně dlouho. Data lineage je zjednodušeně řečeno o tom rozumět, odkud nám data tečou, co se s nimi děje v průběhu jejich cesty a kdo jsou jejich konzumenti. Což zní strašně jednoduše, ale spousta datových profesionálů nebo hlavně jejich byznysových protějšků si myslí, že tohle samozřejmě víme, protože jak jinak bychom mohli fungovat? Ale ukazuje se, že to vlastně není tak jednoduché. Hlavní problém nastává, když se do toho jdeme podrobněji. Nebo těch problémů je samozřejmě víc, ale jeden z nich je rozsah našich prostředí, který se za posledních 10–15 let enormně rozrostl. Ať už se jedná o big data technologie, nebo dnešní cloud, hodně se mluví o AI a machine learningu. Z jiného úhlu pohledu to může být také agilní vývoj a přesun odpovědnosti nebo přístupů k datům směrem k byznysovým uživatelům. Takže nám strašně roste zpracování dat a tomu říkáme datové pipeline. S tím nám rostou nároky na jejich správu, abychom vůbec věděli, kudy data tečou a kdo je používá, když s nimi potřebujeme něco dělat nebo je nějak změnit. Tohle řeší celá ta scéna.

Vy jste ale vlastně specializovaný nástroj, ne? V podstatě váš sweet spot jsou enterprise zákazníci s opravdu velkými datovými pipeline a velkými nepořádky.
Přesně tak, přesně tak. Hlavně v tom velkém prostředí se ukáže skutečný dopad. V menších firmách s třemi, čtyřmi systémy to stále dokážeme pokrýt ručně nebo udržet v hlavě jednoho člověka. Ale u velkých podniků se právě ukazuje dopad na efektivitu. Když jsou tisíce databází a systémů, přes které data tečou, nikdo nemá celkový přehled. A když někdo celkový přehled má, je to sice hezké, ale…
To je jedině detail.
Přesně tak, jak říkají Angličané nebo Američané: „Devil's in the details.“ A právě to řešíme. Přistupujeme k tomu tak, že automatizujeme získávání data lineage tím, že analyzujeme kód, který data lineage realizuje. Protože data…

Pokud chceš, mohu ti pomoci doplnit nebo upravit i pokračování textu.

Á lineage vlastně není nic jiného než popis toho, přes jaké ETL nástroje, přes jaké uložené procedury, přes jaký kód vlastně ta data tečou, který ta data přesouvá z jednoho místa na druhé. My jsme toho názoru, že aby tato informace byla užitečná, musí být jednak dostatečně detailní, jednak aktuální a také kompletní. V Mante se tohle všechno snažíme dělat právě analýzou kódů a automatizací, aby naše datová lineage byla dostatečně univerzální a použitelná pro více use cases než jen jeden.

K tomu se ještě dostaneme, ale začněme tím, jaký je váš typický zákazník? Abychom si to uvedli do kontextu, co kvalifikuje vaše lídy? Náš typický zákazník, jak už jsme zmínili, je velká firma. Když to hodně zjednoduším, jsou to většinou banky, pojišťovny, ale také to mohou být telefonní operátoři, obecně manufacturing, retail – prostě dostatečně velká firma, která má své prostředí natolik rozsáhlé, aby ji začala trápit nefektivita, se kterou se potýká. Pokud bychom to chtěli ještě více zjednodušit, tak většinou kdokoliv, kdo má alespoň dva tisíce až deset tisíc zaměstnanců, už bude mít tento problém.

Poptávka po vás tedy pramení z otázky: máme v tom bordel? Zákazníci to obvykle vyjadřují trošku konkrétněji, většinou říkají, že by tomu chtěli rozumět, nebo chtějí procesy dělat lépe, ale v podstatě je to stejné. A v jaké fázi projektu k vám přicházejí? Vrátím se k migracím. Mám pocit, že dokud nepřijde nějaký velký transformační projekt, nejsou tyto záležitosti prioritou. Dokud to funguje, proč se tím zabývat? Je to pravda, nebo to vidíš tak, že datová dospělost ve firmách roste průběžně a postupně se zlepšuje?

Myslím, že je to tak nějak obojí. Za posledních pár let pojem datová lineage nabral na důležitosti. Když jsme před pěti lety jezdili na konference a snažili se vysvětlovat, co datová lineage je a proč ji děláme, spoustu lidí to buď nezajímalo, nebo nevěděli, jak to uchopit. Dnes, když se mluví o datech, data governance a data ops, je lineage základním stavebním blokem, bez kterého nelze vybudovat efektivní systém s reálnou hodnotou.

S tím souvisí také to, že firmy „dospívají“ a uvědomují si, že lineage je věc, která tu byla, je a bude. O to se postará i velikost firmy – není možné vyměnit datový stack každých pět či deset let a postavit ho na zelené louce, kde by vše bylo zdokumentované a všemu by se rozumělo. Celý systém se postupně dynamicky vyvíjí, přidávají se nové prvky, vznikají nové požadavky, jsou tam pokusy i omyly. Stack se sice obměňuje, ale pomalu. V rámci datové lineage se proto snažíme… (text končí).

Celý ten proces je potřeba výrazně zefektivnit. Dobře, takže když máte poptávku, přijdete tam vy, nebo váš vybudovaný pre-sales tým, a začnete to řešit? Jak konkrétně vypadá ten projekt? Kdybych chtěl zítra používat Mantu, stačí mi dát kreditní kartu na webu a jedu, nebo typický klient využívá profesionální služby, implementaci a jedná se o projekt?

Určitě je potřeba nějaká implementace, rozhodně to není něco, co by se dalo zapnout jenom vypínačem nebo kreditní kartou. To souvisí i s naším datovým prostředím. Myslím, že to je část dospívání trhu – ukazuje se, že když jsme něco budovali posledních 50 let, tak pochopit to do detailu nejde jen tím, že zapneme vypínač. Implementace je tedy nutná, ale záleží, jak k ní přistoupíme. My to řešíme inkrementálně – vybereme si oblast, kterou potřebujeme pokrýt.

Teď se dostáváme k use caseům, tedy k problémům, které zákazníci řeší. Ty nejsou jenom jedny, ale vícero. Jeden z nich, když začneme u finančnictví, může být regulatorní nález, například povinný regulatorní reporting. Pro banky je to třeba BCBS 239, někdy se tomu říká i Bejzl. V rámci takového reportingu má banka povinnost dodat nejen reporty a čísla, ale také musí ukázat, jak k těm číslům došla – odkud data vzala, co s nimi udělala, jak je čistila a spočítala. To je docela přímočarý use case, který je pro nás velmi přínosný.

Na druhé straně jsou pro nás hodně zajímavé use case spojené s moderními přístupy, jako jsou data ops, continuous integration, continuous delivery, nebo dokonce data mesh. Tyto přístupy mají stále větší důležitost, protože abychom mohli efektivně dělat continuous integration, musíme přesně vědět, co se s daty děje.

Skvělá otázka, pojďme se vrátit k prvnímu use caseu. Jde o regulatorní proces, je to podle nového zákona? Ne, není to úplně nové, existuje to už nějakou dobu a pořád se zpřísňuje. Obvykle po každé finanční krizi dochází ke zpřísnění a zlepšení regulací.

Máme příklad z Ameriky, kde zákazník potřeboval splnit požadavky finančního regulatorního reportingu. Pracovali s obrovským Excelem s asi 200 sloupci, kde bylo všechno ručně popsané. S postupným zpřísňováním regulatorního reportingu se ale počet sledovaných atributů a parametrů zvětšoval, a zákazník si uvědomil, že tohle už není schopný zvládnout manuálně. Hledal proto způsob, jak celý proces zefektivnit.

To je hezký příklad. Jak často se takové věci vyskytují? Mají banky většinou tyto procesy vyřešené, nebo je většina stále manuální?

Tady máš upravený text s opravami a stylistickými úpravami pro lepší plynulost a srozumitelnost:

álně a vlastně nemají nástroj? Každá banka si to řeší jinak. Hodně se to řeší určitě manuálně, ale je to rozhodně jeden z těch častějších use case, pokud jsme ve finančním světě a v rámci governance. Super. Tak teď pojďme k druhému, zajímavějšímu tématu – k inovačnímu, řekněme, nejen nutnému. Mluvíš o DataOps. Kde si mám představit Mantu v tomhle světě? Proč je Data Lineage tak důležitá pro DataOps, continuous delivery a continuous integration?

Možná začnu trošku zeširoka. Ve datovém prostředí, když nasazujeme nové datové produkty, nebo chceme dodat nějaký nový datový produkt, anebo když vůbec začínáme zpracovávat data, tak za posledních třeba 30 let jsme ten způsob práce moc nezměnili. Vlastně si nejprve zjistíme, které data budeme brát a co s nimi budeme dělat. A tenhle proces je dost manuální. Většinou chodíme za lidmi a ptáme se, zda už existují vlastníci těch dat nebo analytici, kteří by nám řekli, které data by byly vhodné. Pak se snažíme řešit případné změny.

Pokud v těch datech potřebujeme udělat nějakou změnu, například když nám Salesforce upraví API a my potřebujeme tu změnu propagovat dál, musíme vůbec rozumět, kde data používáme – v jakých procedurách, ETL procesech, přes jaká API data tečou – abychom tu změnu mohli správně rozšířit. Tyto činnosti mohou zabrat týden i měsíc, bez problémů. A protože takových činností máme hodně, firma začíná být strašně neefektivní.

Cena, kterou za to platíme – ať už my jako vedoucí IT, kteří platí za implementaci těchto změn, nebo koneční zákazníci, kteří to musí nějak zaplatit – je vysoká. Protože se to promítne do ceny služeb. Takže naším cílem je umožnit firmám být efektivnější interně, zároveň konkurenceschopnější, a také lépe sloužit externím zákazníkům.

Reálná hodnota spočívá v tom, že jsme schopni ukázat – nechci říct v reálném čase, to by byl špatný příměr, protože kód se v reálném čase většinou nemění – ale na aktuální verzi kódu umíme ukázat, kudy data tečou. Tím dramaticky zefektivníme a urychlíme analytickou fázi, tedy plánování změn.

Jaké jsou tedy časté use cases, které řešíte a které se promítají do celého datového stacku? Dnes už máme datové pipelines tak navázané a integrované, že téměř všechno souvisí se vším a kód se prolíná celým stackem.

Dnes podle mě už jsme ve stavu, kdy je všechno provázané se vším, i když to možná nenápadné. Nejčastějším a zároveň nejjednodušším use case pro DataOps či Continuous Integration je dopadová analýza.

Krásným příkladem je náš zákazník, který používal webovou službu – myslím, že to byl Workday, ale nechci nikoho tímto jmenovat. Nicméně šlo o velmi zajímavý případ, kdy…

Pokud chceš, mohu pokračovat v editaci i dalšího textu.

Opravený text:

Workday v určitých okamžicích potřeboval změnit API při rozšiřování svého produktu. Zákazník měl problém s tím, že během zhruba 8 týdnů nebyl schopný zjistit, kde ve svém prostředí používá data. Pokud to dělali manuálně, trvalo to dlouho, než prošli všechny lidi a identifikovali všechna místa, což jsme dokázali zjistit my. Tento časový horizont představoval období, během kterého potřebovali změny naimplementovat, aby mohli novou funkcionalitu využívat.

Do té doby nebyli schopni zjistit, kde data používají, aby vůbec mohli něco implementovat. Je to hezký příklad dopadové analýzy. V našich prostředích probíhá spousta takovýchto dopadových analýz, protože, jak jsem říkal, stále zkoušíme něco nového, snažíme se z dat získat víc informací, případně jsou zde byznysové požadavky na změny. Když se dělá tolik těchto dopadových analýz, tak sice termíny jako continuous integration nebo continuous delivery zní hezky, ale ve skutečnosti takové dopadové analýzy mohou trvat i řádově týdny, než se něco opravdu stane. Dopadová analýza je nejjednodušší a nejvhodnější příklad, kde se dá ukázat efektivita nebo přínos zefektivnění procesu.

Velká dopadová analýza může být například migrační projekt. V okamžiku, kdy chceme nahradit starý datový sklad – nebudu jmenovat žádného dodavatele –, ale chceme přejít třeba na Snowflake, který je dnes extrémně populární, nebo do Azure či kamkoliv jinam, potřebujeme zjistit, co systém dělá uvnitř, a zároveň kdo se systémem komunikuje. To znamená, že je potřeba přepsat nebo alespoň přenést logiku, která je v systému, a zároveň upravit všechny interakce, tedy ETL procesy, joby, API, rozhraní a podobně.

Tato rozsáhlá dopadová analýza je vlastně „dopadovkou na steroidech“, protože se skládá z obrovského množství menších dopadových analýz. Ukazuje se, že v migračních projektech strávíme minimálně polovinu času plánováním a analýzou, jak migraci vůbec provést. Pro nás je to velmi zajímavý případ užití, kde se plánovací a analytická fáze dá výrazně urychlit, a zároveň navázat na continuous integration a continuous delivery. Projekt má mnohem více fází – není to jen analýza, ale také implementace a testování.

Pro mě je zajímavý, jak američtí kolegové říkají „snowball efekt“. Pokud uděláme špatnou dopadovou analýzu na začátku, což může vypadat jako relativně malá nebo nevýznamná část, postupně se všechny chyby nabaľují jako sněhová koule. Když uděláme špatnou analýzu, může se stát, že implementace nebude úplně správná a… [text končí]

Jasně, tady je opravený text s vylepšenou interpunkcí, gramatikou a stylistikou, aby byl plynulejší a srozumitelnější:

Podle té analýzy na to přijdeme až během testování a vlastně projdeme část cyklu zbytečně. Musíme se vrátit zpátky, analýzu dodělat, něco upravit, potom doimplementovat tu chybějící část nebo tu, která byla udělána špatně, a znovu to přetestovat. A takhle nám to kolečko jednak zdržuje časově, což nemůžeme vrátit, ale jednak nám to i prodražuje celý projekt.

Mně se hrozně líbí, že na jednu stranu mluvíš obecně, třeba o migračním projektu a tak podobně. Na druhou stranu, když jsi říkal, že máš zkušenosti z toho, jak se to dělalo v Outuďku nebo v České spořitelně, tak v tvých očích vidím tu reálnou zkušenost a bolest, kterou jsi s tím prožil.

Dřív jsi neměl mantu, nebo když jsi dělal tyhle projekty, jaký byl status quo? Jaké bylo řešení?

No, řešení bylo většinou manuální. Byly to spíš pokusy. A teď tady nejmenuji žádného konkrétního zákazníka, protože každý to dělá trochu jinak. Status quo v roce 2015, ale vlastně možná i dneska v mnoha firmách je podobné, bylo takové, že vzít nějakou dokumentaci – to znamená dokumentaci ze samotného vývoje konkrétního systému – a podívat se, co tam vlastně je. Pak ideálně vzít i změny, které se staly v průběhu dalších deseti let, což je většinou ten největší problém.

Takže to je jedna část. Druhá je snažit se to vytáhnout od lidí, což znamená hodiny a hodiny schůzek, kde se potkáš s pěti lidmi a řešíte, odkud data tečou, jak to funguje a proč. Pak je další schůzka s technickými lidmi, kteří ti řeknou, že to ve skutečnosti funguje úplně jinak. Takže je to spousta času stráveného, z mého pohledu extrémně neefektivně, a je to hodně bolestné.

Myslím, že spousta zákazníků si uvědomí, když zjistí, že tohle pro ně nebude fungovat, že ten problém v budoucnu nezmizí. Že to nestojí tři hodiny týdně, ale třeba tenhle měsíc tři sta hodin. A najednou to vyplave na povrch.

Přesně tak. Je zajímavé si uvědomit, že když analytik něco dělá, většinou se baví s lidmi, takže stojí čas nejen toho analytika, ale i dalších lidí, protože vždycky se s někým baví. Takže časová náročnost vlastně rychle roste a člověk, který s tím analytikem mluví, nemůže dělat svou vlastní práci. To se všechno sčítá.

Je to vlastně snowball efekt. Mně se často vrací, že ten snowball efekt je hezký příměr, který do toho zapadá, když se na to člověk dívá z širšího pohledu a vidí celý tok vývoje, co se musí stát, kdy z malé kuličky vznikne obrovská koule – jak finančně, tak časově.

Líbí se mi, že to, co popisuješ, podle mě vysvětluje i produktový vývoj a růst manty, nebo přenesení jakýchkoliv produktů. Že silná hodnota vaší propozice je v té analytické první fázi.

Pokud chceš, můžu provést ještě detailní úpravy stylu podle cílového publika nebo formálnosti projevu.

Jistě, zde je opravený text s lepší srozumitelností, gramatikou a interpunkcí:

A vlastně, jak vnímám Mantu za posledních pár let a jak roste jako platforma, tak tam přidáváte další funkce, aby to nebylo jednorázové – udělám si mapu, podívám se, ale stejně jako svět se stává agilnějším, už se nedívám jednou za rok, jak se mi změnily příjmy a výdaje, ale sleduju to v reálném čase, jak mi to přichází na účet. A s tím se změnil i váš přístup.

Vnímáte to správně, popisujete to správně, že hledáte, jak zvýšit hodnotu v dalších částech, nejenom v první analytické fázi, která je téměř jednorázová, ale jak tu analýzu protáhnout, aby v životním cyklu dat vždy byla nějaká přidaná hodnota?

Přesně tak, jednak je to tím, ale to, co jste právě popsal, je hodně o vysvětlování hodnoty datové platformy – stále řešíme ten případ dopadové analýzy, ale přínos není jenom v dopadové analýze samotné, ale je mnohem větší, když se sečte napříč celým životním cyklem. Takže máte naprostou pravdu.

Druhý úhel pohledu, kam rosteme, je ten, že používám příměr s klasickou papírovou mapou a navigací. Mít papírovou mapu je sice fajn a můžeme podle ní navigovat, ale digitální transformace v případě papírové mapy není pouze to, že ji dostanu do počítače a místo papíru ji mám na obrazovce. Skutečný přínos je v tom, že ji začnu používat jinak. Mám GPS navigaci, která mi hlásí, kudy mám jet, kde mám zatočit, když minem odbočku, tak mi trasu přepočítá a navede mě.

A to je přesně to, co děláme i s datovou linií. Někdy tomu říkáme aktivní metadata – tedy že mapa, jak ji dnes používáme, je fajn, protože bez ní bychom byli ztracení, ale další krok je poskytovat hinty nebo notifikace o tom, co se děje.

Například máme zákazníka z oblasti healthcare, který budoval datový sklad posledních 30 let. Ten sklad je dnes obrovský a bohužel se v něm nikdo úplně nevyzná, je tam spousta částí. Tak dlouho budovali datový sklad, až z něj vznikl dataleg – alespoň částečně. Mnoho částí je už nepoužívaných, ale nikdo o tom neví, protože to úložiště je tak rozsáhlé, že nikdo netuší, co se z něj používá a co ne.

Zákazník řešil několik případů – jednak kde jsou data pacientů, jestli jsou správně kontrolována a zpracována, kdo k nim má přístup. Zároveň zjistili, že část datového skladu se vůbec nepoužívá, takže při plánované modernizaci, která byla plánovaná asi za dva roky, nemusejí migrovat všechny datové toky. Tím, že migrace do cloudového prostředí je nákladná jak z hlediska úložiště, tak výpočetního výkonu, jim to přineslo značné úspory.

Teď nevím přesně, kolik to bylo, ale úspory byly značné, zároveň jim to výrazně zrychlilo práci s daty.

Pokud chcete, mohu text ještě rozdělit na jednotlivé odstavce nebo přidat další úpravy.

Opravený text:

Ten migrační projekt – takže to byl zase ten snowball efekt. Mně se to pořád…

Jde o kombinovanou úsporu, ke které došli vlastně tím, že řešili nějaký úplně jiný případ, který se týkal zprávy dat pacientů. Je to hrozně hezké, vidím, jak se opravdu dvakrát měří a jednou řeší. Když to vůbec nezměříš, dáš to od oka, uděláš to manuálně, tak potom můžeš jít znovu řezat. Můj rodinný život, domácí práce, to ukazuje – že bych měl analytickým částem možná věnovat víc času. Každopádně tohle chápu. Otázka je, co je Manta teď vlastně zač. Když přijdu k vašemu klientovi, kdo používá Mantu a při jakých příležitostech? Co je dneska Manta? Jak se vám daří ji dostávat právě do data ops, nejenom do linie a analytických projektů, auditů a podobně, ale i do produkčního prostředí každodenní datové rutiny?

To je strašně zajímavá otázka. Uživateli Manty ve firmách je opravdu hodně. A teď možná trochu odbočím od data ops: jsou to datoví inženýři, vývojáři datových vědců, lidé, kteří navrhují uložené procedury nebo implementují nějaké ETL joby. Jsou to data scientisti, kteří dnes tráví hodně času ne přímo vědeckou prací, ale dohledáváním informací o datech a ověřováním, zda je mohou použít nějakým konkrétním způsobem. Jsou to datoví analytici, byznys analytici, kteří se většinou pohybují hlavně v plánovací fázi. A jsou to třeba i testeři, kteří provádějí testing. Takových případů je opravdu mnoho.

Pokud bych měl uvést jeden konkrétní, který je podle mě velmi zajímavý, je to právě z prostředí testování. Situace byla taková, že zákazník potřeboval testovat změny, které provedl v kódu. Protože změn dělali hodně a měli jen jedno testovací prostředí, bylo to komplikované: testy byly závislé na konkrétním nastavení prostředí a když je udělali ve špatném pořadí, výsledky neodpovídaly. Přišli proto s nápadem, že si testovací prostředí budou stavět dynamicky pro každou konkrétní změnu. Potřebovali vědět, jak velkou část datového prostředí musí zreplikovat. Díky tomu, že to dělali v cloudu, pro ně nebyl problém automatizovat proces replikace. Spojili to ještě s anonymizací dat, ale vlastně zreplikovali jen tu část prostředí, kterou potřebovali pro testování, postavili si ji konkrétně pro ten test a pak ji zase zrušili.

K tomuto potřebovali znát závislosti mezi daty – v rámci datové pipeline bylo třeba vědět, které části datového prostředí je potřeba zreplikovat, přitom to chtěli udělat co nejrychleji a nejefektivněji, tedy replikovat co nejméně. Na základě informací dodávaných Mantou si přes API vytáhli, odkud data tečou – jen to opravdu důležité – zreplikovali tu část, postavili testovací prostředí, pustili test a pak ho zrušili. To byl jeden hezký příklad.

Druhý…

Opravený text:

Příklad, který byl k tématu continuous integration a continuous delivery, se týkal zákazníka, který se rozhodl dělat velice malé změny, ale dodávat je rychle, aby nečekal na nějaké čtvrtletní releasy a podobně. Ty změny byly v jejich analytickém prostředí, což znamenalo částečně interní prostředí a částečně závislost na datech, která přicházela zvenku, například z webové analytiky a podobně. Tím, že dělali hodně změn, které měli izolované a chtěli je nasazovat nezávisle, se v agilní metodologii mohlo stát, že se něco úplně nenaplánovalo správně, že se něco posunulo, nebo se změnily priority. Proto bylo potřeba vědět, v jakém pořadí mají ty změny aplikovat, případně která změna je závislá na které jiné, aby se nerozbila lineage.

Právě to byl případ, který měli před používáním Manty – během testování a nasazování těchto změn se jim často stával snowball efekt, kdy hodně věcí bylo rozbitých. To je stálo strašně moc času – bylo to úplně frustrující, na opravy a řešení těchto problémů. Díky lineage byli schopni automatizovat jednak pořadí nasazení těch změn, pokud je už měli hotové a potřebovali je jen nasadit, ale zároveň dokázali reagovat na situace, kdy se hotová změna posune a v dalších změnách je potřeba něco upravit, aby odrážely, co už bylo nasazeno.

Tento příklad ukazuje, jak data lineage pomáhá v continuous integration a continuous delivery, zejména vzhledem k objemu změn, které byly řádově malé desítky týdně, což se dříve zvládalo hodně špatně. Věřím, že je to zajímavý příklad z oblasti continuous delivery a continuous integration ve větším měřítku.

Mám ale takovou šťouravou otázku, Honzo, na tebe. Já vnímám Mantu jako super datový startup, na který můžeme být ve světě hrdí, a tomu, jak vám roste, tleskám. Přesto jste pro mě trochu zástupcem toho enterprise starého IT stacku. Možná tím, že – kdybych byl zlý jazyk – bych řekl, že klientům pomáháte držet legacy infrastrukturu. Mají data rozprostřená všude, lepená dohromady, jak říkáš – 30 let – a pořád to lepí dál, mají armády programátorů, kteří dohledávají, co ti před nimi nejlepší bastlili. Měl jsem dokonce pocit, že podobně jako UiPath, a nemluvím teď jen o Mantě, ale UiPath mám za příklad stejného nástroje, pomáháte vlastně prodloužit život starému stacku, starému světu – jako kdybyste prodlužovali život spalovacím motorům. Někdy mám z toho takovou pachuť v puse. Slyšíš podobné názory často?

Já přiznám, že je moc často neslyším, ale myslím, že je to super otázka. Pokud je Manta vnímaná tímto způsobem, určitě stojí za komentář. Za mě je to naopak přesně jinak. Zákazníci p… (text končí).

Říkají, že mají problém se zbavit starého, legacy světa. Důvodem je to, že mu vlastně nerozumí – byl budován třeba 30 nebo 10 let, klidně i relativně nedávno, ale pořád to bylo vytvářeno dlouhou dobu. Teď tomu nerozumí, nevědí, kde začít, nemají přehled, kolik bude migrace stát, jak dlouho potrvá a s jakými daty pracuje.

Proto pro ně řešíme jednak rychlý vhled do toho, co systém dělá a s kým komunikuje, na základě čehož je možné migraci lépe odhadnout a naplánovat. Současně poskytujeme detailní analýzu, díky které dokážeme v rámci migrace urychlit analytickou fázi – o tom už jsme se bavili – aby se ze starého světa dostali rychleji a efektivněji pryč.

Někdy by se to mohlo brát i opačně – že se tak vlastně „vymigrujeme“ pryč. Pro mě je to přesně opačně. Asi to souvisí s typem zákazníků – nejsem uživatel, a proto v marketingové komunikaci vnímám cílení na uživatele legacy systémů, což dává smysl, protože se do nich nejhůř dostává, pravděpodobně mají největší technický dluh a problémy.

Je to trochu úsměvné, když vidím blogový článek o novém konektoru a čtečce Kobolu, protože ve mě to v startupovém prostředí vyvolá kontrast. Stále někdo používá Kobol, což je bohužel rozšířená technologie – ale možná z toho pramení můj pocit. Máš pravdu, před Mantou jsem nevěděl, kolik je skutečně aktivních uživatelů Kobolu. Je to fakt neuvěřitelné – třeba většina pojišťoven nebo healthcare organizací má pořád v Kobolu svůj core systém, podobně ve finančním sektoru.

Přesně to je ale příklad, kde se lidé bojí do Kobolu šáhnout, protože nerozumí tomu, co systém dělá. Mají tam jediného člověka, který to udržuje nebo udělá nutné změny, které se ale většinou dělají izolovaně – a navíc se příliš neodvažují sahat na rozsáhlejší úpravy, aby něco nerozbili. Nemají nikoho, kdo by případné chyby dokázal opravit.

Tady u Kobolu je tedy zajímavý příklad, jak pomáháme najít způsob, jak se do systému dostat a jak ho zmigrovat jinam. Prvním krokem je vytvoření mapy systému, druhým pak samotné aktivní použití.

Momentálně řešíme s jedním zákazníkem v Kanadě migraci datového skladu, který je napsaný v Microsoft Integration Services a NetEase. Snaží se to přenést do cloudu, tedy částečně změnit a přizpůsobit pro AWS Glue a Redshift. Mají obrovské množství datových pipeline a tabulí, a ruční přepis by je stál strašně moc času a zdrojů.

Tady je opravený text:

Není to moc, to se nám skoro nevyplatí dělat. Je téměř lepší to nechat dožít a začít nové budovat na zelené louce. Nicméně co teďka řešíme, je zkusit to, protože v nějaké fázi tam mají kroky, které jsou víceméně technické, jako nějaké čištění, historizace a podobně. Vlastně se teď snažíme využít LLM (velkých jazykových modelů) k tomu, abychom velkou část nového kódu vygenerovali jenom na základě existujících informací. Samozřejmě to nejde obecně — pokud nám někdo poslouchá a klepe si na čelo, že jsem se zbláznil, tak s tím naprosto souhlasím. Ale některé technické kroky mají architektonicky hezky navržené, takže by to mohlo být možné. Takže místo toho, abychom pomáhali udržovat legacy systém, pomáháme se ho rychleji zbavit.

Honzo, to mě ale přivádí zpátky k té jednorázovosti versus SaaS nástroji, které mám v datasteku pořád. Jakmile tedy vyřešíte a vaši klienti se zbaví COBOL systému, nepřijdou o potřebu používat Mantu, nebo to vyčistí? Není to nějaký přechod mezi dvěma generacemi softwaru? Potom se zbavíme těch nejmenovaných SAPů, budeme ve všech hezkých cloudových systémech, všechny produkty budou mít API a budeme mít absolutní vizibilitu?

Bylo by to krásné, kdyby to tak bylo, ale já osobně tomu nevěřím. Myslím si, že poté, co se zbavíme COBOLů a budeme všichni v cloudu, a každý si vybere svůj oblíbený nástroj, přijde nový cloud nebo nový produkt, do kterého se dostaneme do stejné situace. V podstatě jsme už v tom byli třeba před dvaceti lety, kdy se myslelo, že SAP bude generálním dodavatelem, který vyřeší celé prostředí firmy, včetně CRM, ERP a podobně. Oracle mělo stejnou ambici, ale nakonec se ukázalo, že přišel nový Salesforce, který byl hezčí, lepší, funkčnější — a začali jsme používat právě Salesforce. Starý reporting nebyl tak hezký, velký vendor ho nevyvíjel ani neudržoval, a začaly se používat novější nástroje jako Tableau, Power BI, Looker nebo něco dalšího.

Takže vlastně noví vendory s novými myšlenkami pořád přicházejí, a hlad po zlepšení tady pořád je. Myslím si, že problém se jen posouvá, ale ta potřeba rozumět našemu datovému prostředí zůstává. Jako fanoušek firmy Keboola je pro mě zajímavé, jak se rozšířil počet datových nástrojů. Jak jsme říkali na začátku, dřív jsi měl jednotky, centrální databázi, nějaký warehouse a nad tím analytickou vrstvu. Dnes máš desítky různých aplikací, propojených datovými pipeline, a na tom jsou postaveny reálné produkty a naceňování.

Zdá se mi, že komplexita roste. Na druhou stranu se objevují i nové standardy, že…

Pokud chcete, mohu dál upravit nebo rozšířit text.

Jasně, tady je opravená a upravená verze tvého textu pro lepší srozumitelnost a plynulost:

Právě něco, na čem tady pracoval Superface, jsou prostě nějaké automatizované aplikace a tak. V tohle ale ty nevěříš, že by to bylo možné, že…

Jak říkám, jde o standard nebo řešení technologického charakteru. Já věřím, že něco určitě přijde a něco pomůže. My jsme jedno z těch technologických řešení, které pomáhá. Ale myslím si, že v tom celkovém měřítku, že by tady přišlo něco opravdu revolučního, co kompletně změní datový tok tak, že najednou bude skutečně automatizovaný a automaticky propojený, tak k tomu máme při nejmenším ještě daleko.

A ono to s tím datovým nástrojem a složitostí našeho datového prostředí, jak se zvětšila, bylo také takovým částečným enablerem, nebo právě požadavkem – tou demokratizací a přesunem k agilnímu přístupu i na byznysové úrovni. Mnoho byznys týmů říká: „My bychom si radši data spravovali sami nebo je analyzovali sami, protože jim rozumíme a můžeme s nimi pracovat víc experimentálně. Když si něco chceme vyzkoušet, nepotřebujeme to rovnou implementovat přes IT.“

Přechod datových lidí blíž k byznysu je o tom, že nechtějí čekat půl roku, než jim IT něco dodá, protože jsou na konci pořadí a ani neví, jestli to vůbec bude k něčemu. Experimentování, sandboxy a podobné věci jsou pro ně důležité.

To zase na straně IT souvisí s tím, že je někdy těžké rozumět datovému prostředí, které spravují. To vede ke vzniku více a různorodějších nástrojů a komplikaci datového prostředí. A potom je těžké udržet konzistenci a vidět návaznosti či závislosti — a to jsou hlavní problémy.

Přesně tak. I když data nebo jejich zpracování přesuneme blíž k byznysu, tak byznys bude efektivní jen tolik, kolik má kontextu k těm datům. Vlastně řeší stejný problém jako IT – rozumět datům, jen teď to řeší sami. Potřeba porozumět datům a jejich tokům, odkud data skutečně přišla, zůstává. Jen ji trochu „rozmělníme“ pomocí self-servisu, demokratizace či data meshu a přesouváme ji k byznysu. Ale všichni pořád řešíme ten samý problém — pochopení, kde se data vzala, co s nimi děláme a kdo je dál používá.

A to navazuje na abstraktnější, hůře uchopitelné pojmy jako je důvěra v data nebo transparentnost datového prostředí, našeho prostředí obecně. To je strašně těžké uchopit a kvantifikovat. Když někdo řekne, že nevěří reportu a raději se zeptá obchodníků, jak k tomu přistoupit?

Myslím si, že jedním z kroků je lepší porozumění prostředí tak, aby bylo konzistentní, aktuální a kompletní…

Pokud chceš, mohu upravit i zbytek, dej vědět.

Zde je opravený text s opravou gramatiky, interpunkce a stylistiky:

… těch klíčových kroků. Pro mě je to zajímavé a hrozně mě těší, že to popisuješ jako nějaký trend. Já jsem v jednu chvíli měl pocit, že naopak trh je plný blackboxů a přicházejí single purpose krabičky, které ti vyřeší super právě tenhle jeden datově analytický problém a tu krabičku potom napojíš jinam. Ale jsou to většinou blackboxy, které ti spíš napovídají, co dělat, než abys věděl proč. Takže mám radost z toho, že ty vidíš větší transparentnost a v tomhle vidíš budoucnost.

Tak co je výstupem z Manty? Jak si to mám představit? Když mám nějaké self-service BI a tým s tím chce pracovat, tak pro co si jde do Manty? Nebo co jim posílá Manta? Aby věděli, že pracují třeba s nějakým revenue, a aby přesně věděli, jak vzniklo to jedno konkrétní číslo?

Přesně tak, přesně tak. Takže ten úplně nejednodušší, triviální výstup z Manty je vlastně mapa. To znamená, že si k tomu konkrétnímu číslu v konkrétní položce reportu mohu zobrazit, z jakých dat se spočítalo a třeba i jak se spočítalo, aniž bych musel mít přístup do těch 30 systémů, kterými ta položka prošla. Přesně tak. To je takový jednoduchý základní pohled.

Pohled s vyšší přidanou hodnotou jsou pak například věci jako: tady se ukázalo, že máme nějaký report, který se však přestal plnit. Datový zdroj ho přestal naplňovat po nějaké migraci, což ideálně by se nemělo stát, protože tu migraci jsme udělali správně, kompletně. Víme přesně, na koho má dopad, ale mohlo se to stát. To je třeba jeden příklad.

Druhý příklad pro data scientisty je hezký: Když učíme machine learning modely, tak je učíme na nějaké datové sadě. Ta datová sada má nějaké předpoklady, něco musí splňovat. Co se stane, když nám tu datovou sadu někdo změní a my si toho nevšimneme? Pak může ten machine learning model dávat nepředvídatelné výsledky, protože začal fungovat na datové sadě s jinými charakteristikami.

Hezkým příkladem opět na lineage je takzvaná aktivní lineage – notifikace, že v okamžiku, kdy mi někdo změní datovou sadu. To znamená, že třeba nejde jen o zdrojová data, ale že přidá nový vstup. Místo jen vstupu z Facebooku přidá ještě vstup z LinkedInu, Instagramu nebo TikToku. Ta datová sada pak začne vypadat jinak. A pokud nemám notifikaci o tom, že se datová sada změnila, a nepřetrénuji machine learning model, výsledky, které dostávám, nemusí být adekvátní.

Takových případů, kde závislosti a složitost našeho datového prostředí život výrazně komplikují, je hodně. Podle mě je to přesně ta věc, která nikdy nezmizí, i když, jak jsi říkal, budeme mít nějaké blackboxy, které řeší konkrétní problém, což je skvělé. Blackboxy ale vždy něco konzumují a něco produkují, a my o tom musíme vědět, i když je to blackbox. Ideálně bychom pak potřebovali vědět i to, co se v něm děje…

Pokud chceš, můžu pokračovat či dále upravit, případně rozdělit text do přehlednější formy.

K určité míře, ale minimálně ty závislosti externí prostě potřebujeme znát. No Honzo, mně se tam líbí, jak mluvíš třeba o těch blackboxech a machine learningu. Máš pocit, že vzniká víc a víc machine learning produkčních pipeline? Já mám pocit, že tohle je trend na trhu, a že z data science jako někoho, kdo půl až rok a půl vytvářel nějaký model, pak s ním přišel a implementoval ho, se stává víc IT obor, zase continuous delivery, věc, která je součástí i toho BI stacku. Vnímáš to tak?
Rozhodně, naprosto. A podle mě vlastně spousta z těch B2C firem machine learning modely upravuje strašně často nebo je používá skutečně v živých systémech, například Netflix, Uber – doporučování, optimalizace, to tam prostě funguje. Za nás rozhodně, z našeho pohledu, z pohledu Linije, jsou tam pro mě takové dvě, tři oblasti. Jedna je pořád ta, co se týká závislostí – jaká data do machine learningu vstupují, co z toho jde ven, kde se to používá. To je jedna oblast. Druhá oblast je quality of life data scientistů. Už jsem to tu trochu zmiňoval, ale spousta data science inženýrů reálně nedělá data science. Bohužel. Dělají inženýring. Přesně tak. A vím, že spousta z nich je z toho poměrně frustrovaná, protože jednak připravují data a zároveň dohledávají kontext k těm datům – jestli je mohou použít pro konkrétní účel, jestli to dává smysl, nebo jestli už to nejde. Ta laťka je mnohem výš ve chvíli, kdy jde model do živé produkce a firmy na tom rozumí a mají automatizované procesy, než tomu bylo dřív, kdy někdo vytvořil model nebo report.
Přesně tak, přesně tak. A ta třetí úroveň zase souvisí trochu s governance nebo většími tématy, jako je etické použití dat. Protože dnes se hodně řeší, kde se machine learning používá, jaká data používá, a co se s těmi výstupy děje. Jdou do automatického použití okamžitě, nebo procházejí lidským schválením? A samozřejmě, jak je machine learning populárnější, začínají se používat i v mnohem citlivějších oblastech. Například i v rámci smluv se zákazníky vidíme otázky směřující k machine learningu a AI, jestli Manta AI machine learning používá a jakým způsobem, protože to začínají řešit. Už to není jen studentské cvičení, kde si to vyzkoušíme, ale může to mít reálné dopady na skutečné lidi.
Takže to vypadá, že machine learning a data science část bude čím dál důležitějším zdrojem nových klientů a potřeb na trhu? Vnímáte to stejně?
Co ještě vás čeká v Mantě?
No, v Mantě nás čeká spousta práce. Teď se mnohem více zaměřujeme na aktivaci metadat, t…

Jasně, tady je opravený text:

Takže výrazně rosteme a pořád hledáme lidi, jako všichni. No, teď to podle mě není úplně pravda. To, že hledáte lidi, je spíš výjimka. Natáčíme tenhle podcast na konci září 2022. Tak to je pozitivní, no. Takže gratuluju! A pravda je taky, že jste nedávno dostali velkou investici. Nejlepší čas asi, že?
Přesně tak. Právě jsme dokončili Series B – 35 milionů dolarů od portfolia investorů, což je super. A tak se těšíme, jak můžeme pokračovat dál.
Já vám držím moc palce. Ať se vám daří, ať šíříte českou datovou knowledge do světa a máme další super firmu, na kterou můžeme být hrdí.
Děkuju moc, Honzo, že jsi přijal pozvání, a doufám, že se brzy uvidíme znovu.
Já děkuju moc za pozvání a za rozhovor.
Díky, že jste doposlouchali DataTalk až sem. Jak se vám tahle epizoda líbila? Co byste na našem podcastu zlepšili? Koho pozvat příště? Dejte mi prosím vědět, co si myslíte. A to můžete buď osobně na příštím DataMesh meetupu, nebo hned teď na mail jirka-datatalk.cz.
A pokud se vám tahle epizoda líbila, doporučte ji dál. Klikajte na srdíčka, na hvězdičky, dávejte subscriby, ať nám svítí dashboardy zeleně, křivky dělají hokejku a všichni stakeholdeři schvalují extra budget. Ještě jednou vám děkuju.
Poděkování patří také mým kolegům, Nikovi a Iris, stejně jako členům našeho partnerského klubu – Big Hubu, Deep Note, Atakamě a Mantě.
Pokud máte návrhy, tipy na hosty, témata, organizujete vlastní event nebo byste chtěli datovou komunitu podpořit jinak, určitě mi dejte vědět. Díky.
Nechť vás provází data.

Pokud chceš, můžu text ještě víc upravit podle stylu či formálnosti.