Podcast

Dobrý den, moje jméno je Jirka Vycherek.
Dobrý den všem, moje jméno je Hinek Volner.

A vítáme vás u dalšího dílu Datatolku.

Dnes k nám do studia zavítala rovnou dvojice hostů z Kiwia, a to Martina Ivanečová, Data Engineering Lead, a Kateřina Ščavnická, Senior Analytics Engineer. Vítejte.
Dobrý den.

My si dnes tady budeme povídat s Martinou a Kateřinou o tom, jak vypadá vlastně datový svět v Kiwi. Budeme se hodně zabývat konceptem data mesh a také se podíváme na to, jak řeší data contracts v Kiwi.

Ještě než se půjdeme podívat do Kiwi, jaká byla vlastně vaše cesta, jak jste se dostaly do kiwi.com? Asi Martinou začni.

Dobré, takže já jsem takový datový dinosaurus. Úplně dávno jsem začínala jako PLSQL developer, potom jsem pracovala ve firmách, které stavěly datové warehousy pro velké firmy, pro telekomunikační operátory, pro ministerstva.
Takže jsem byla takový klasický BI developer, absolutně klasický old school data warehouse tým.

Potom jsem měla takovou velkou zajímavou odbočku. Pracovala jsem v Siemens Smart Infrastructure, kde jsme vlastně stavěli svým způsobem data řešení pro chytré budovy. Od sběru dat, od IoT, od sběru datových bodů ze senzorů až po nějakou vizualizaci a dokonce potom nějakou preskriptivní analytiku, tedy jak fungovat budovou tak, aby se ušetřila energie, nebo aby se nastavila nějaká KPIčka.

Potom, úplně uprostřed korony, jsem se rozhodla, že přejdu do travel company Kiwi a začala jsem tam pracovat jako data platform lead.

Tak já jsem takové datové štěně, spíš bych řekla. Vystudovala jsem matematickou biologii na Masarykově univerzitě v Brně a tam jsem poprvé zjistila, jaké kouzlo data mají a co pomocí dat můžeme zjistit. Po škole jsem nastoupila a začala pracovat jako data scientist v Institutu biostatistiky a analýzy dat v Brně. Po dvou letech jsem nastoupila do Kiwi také během covidové pandemie a od té doby tam pracuji.

No a co jsi jako data scientist dělala v Institutu biostatistiky? Pracovali jsme na nějakém algoritmu pro detekci anomálií, anomaly detection, při sběru medicínských dat. V podstatě se jednalo o odhalování outlierů, nějakých podvodů a podobně.

Tak jste se tedy dostali do Kiwi uprostřed korony. Teď možná, jak vlastně vypadá datová struktura, datový tým v Kiwi? Asi všichni Kiwi znají a tuší, co děláte, ale když se podíváme dovnitř, když jste tam přišli, do jakých týmů jste vlastně vstoupili? Jak si máme představit tu organizaci?

Já jsem vstoupila do takzvaného data platform týmu. Vlastně byly dva data platform týmy dohromady a myslím, že nás bylo asi sedmnáct. Byla to taková situace, že tým měl na starosti stovky datových pipeline. Kromě toho se staral o konkrétní datové use cases, tedy nějaké datové produkty, které se prodávaly na externím trhu. Kromě toho spravoval datovou platformu a také se snažil vyvíjet nějaký interní tooling, například nástroje na kontrolu kvality dat online a podobně. Takže to byla situace před třemi lety, kdy jsem tam přišla.

Já jsem nastoupila do Kiwi jako data analytik, ne jako analytics engineer. Nastoupila jsem do jednoho z mnoha decentralizovaných analytických týmů, které byly věnovány konkrétně na nějaký úsek, na nějakou oblast dat, která jsme v Kiwi sbírali. Tam jsem zjistila, že práce s daty může být někdy docela bolestivá a kvalita dat nebyla nejlepší na světě.

Co si budeme říkat, takže mě to donutilo přesunout se z data analytiky do analytics engineeringu, protože jsem pochopila, že pokud se na zdroji s daty něco nestane a neprovedou se nad nimi nějaké transformace, tak vždycky to bude garbage in, garbage out. Šla jsem proto po root cause, po příčině problému.

Můžeme k tomu později dodat, že v době, kdy jsem přišla, právě nastal turning point, že data už přestala škálovat. Dovtedy jakoby to nějak šlo, byli analytici, vědci v datech, ale hlad po datech rostl a rostl. Už jsme měli data z tolika zdrojů, můžeme popsat kontext – mělo to mikroservisní architekturu, bylo tam několik interních databází, možná padesát až šedesát, z kterých se data tahala a slučovala do jednoho místa. Kromě toho Kiwi nakupovalo data o situaci na trhu od meta serverů, aby věděli, jak konkurenceschopní jsou, aby věděli, na které itineráře se zaměřit.

Kromě toho jsme sbírali data o tom, jak s námi zákazníci interagují na naší aplikaci a webu, a sbírali jsme také data ze sociálních sítí a podobně. Najednou už byl takový hlad, že to přerostlo určitou škálu a přestalo to škálovat.

Takže to byl podle mě zlomový bod, nebo bod, kdy jsme my oba nastupovali.

Já bych k tomu dodala, že to byl zlomový bod nejen pro data platformu, ale i pro analytics stranu. Pro nás to znamenalo, že jsme si nebyli jistí kvalitou dat, nevěděli jsme, kdo je jejich vlastník, koho kontaktovat, nebyla vůbec žádná dokumentace k datům, jen nějaká náhodná tabulka s náhodnými daty a vše ostatní jsme si museli domyslet.

V takovém kontextu co s tím? Jaký byl první krok?

Úplně první krok byl velmi logický – potřebujeme nějaký doménový zdroj pravdy. Začali jsme modelovat nejdůležitější oblast – počet bookingů, a kolem toho postavit první datový model.

Nechci, aby to vyznělo, že předtím jsme nevěděli nic a najednou víme vše. Samozřejmě zdrojová data byla k dispozici, ale pokud ses ptal pěti různých analytiků, dostal jsi pět různých čísel.

To byla první snaha dát data do pořádku a postavit kolem domén nějaké datové modely.

A když jsme začali, začalo nám to odkrývat příčinu problému a to je právě, že když máme garbage in, tak máme garbage out. Můžeme být jako datoví modeláři, analytici, inženýři, můžeme se snažit vytvořit dobrý datový produkt, ale když na vstupu máme nesmyslná, náhodná data, nepodaří se to.

A chtěla bych zdůraznit ještě jednu věc, která mě trápí – lidé často berou kvalitu dat tak, že když jsou data nekvalitní, dají na ně nějaké transformace, například odstranění duplicit, doplnění chybějících hodnot, že tím se data stanou kvalitními.

To je ale naprostý opak pravdy. To jsou takové hračičkovské případy, ale v zásadě potřebujeme mít ownership, někoho, kdo garantuje data, kdo je popíše a kdo stanoví nad vstupními daty služební úroveň, SLA, Service Level Objectives a podobně.

To je podle mě ta správná cesta.

Datové modelování byl určitě krok vpřed. Nebylo to tak, že jsme něco začali dělat a najednou jsme zjistili, že máme milion problémů a proto jsme si mysleli, že je to krok vedle. Naopak, byl to skvělý směr, ale díky němu jsme zjistili, že máme mezery i jinde a na nich je třeba pracovat.

Bylo to vlastně organizační opatření, protože ve chvíli, kdy jste stanovil domény, začalo to mít vlastníka.

A tím, že to má vlastníka, šla odpovědnost „zezdola“ nahoru. Domény… to je velmi zajímavý paradox datové oblasti. Už deset let se softvér staví kolem domén, ale do datového světa to začalo pronikat až nyní.

Domény a produktové oblasti v Kiwi byly, ale data byla jedno velké úložiště (data lake) a analytics tým se kolem toho nějak točil.

Velmi důležitý krok byl jít za jednotlivými doménami, za softwarovými inženýry v těchto doménách, říci jim: „Ano, nad těmito daty se dělají důležitá rozhodnutí, je potřeba na nich stavět ML modely, my je nechceme jen tak automaticky tahat a slučovat k sobě, chceme, abyste je vy sami vědomě vystavili, popsali a garantovali.“

Často jsme narazili na nepochopení – někteří se divili, že za jejich zády někdo sahá do produkčních databází a odtud data vytahuje, či dokonce s nimi potom dělá nějakou další práci.

Jak těžké bylo takové změny prosadit?

Představme si to takto: pokud firma hladoví po datech, přijít se zpomalením a říci „teď to dáme do pořádku“ je výzva.

Nicméně, je důležité říct, že asi neexistuje firma na světě, která dá na dva roky pauzu a řekne „teď to napravíme a potom se vrátíme do normálu.“

My jsme se to snažili rozumně pochopit tak, že se soustředíme na něco, co přinese nejrychlejší výsledky.

Tedy jsme si vybrali jednu oblast, tam jsme realizovali datové produkty a kontrakty a potom přidávali další týmy.

V našem případě to bylo kolem oblasti bookingů.

Museli jsme tedy co nejdříve ukázat hodnotu, ne že zastavíme vývoj na dva roky.

Organizačně to také znamenalo, že lidem přibyly nové povinnosti. Dříve fungovali „business as usual“, najednou ale žádáme, aby vystavovali data, aby dělali dokumentaci, což do té doby nedělali a možná s tím nemají zkušenosti.

Jak se toto řešilo? Bylo to vyjednávání, nějaké vzdělání, školení?

Byly tam dva klíčové pilíře úspěchu.

Prvním byla podpora leadershipu. Mně teď především děkujeme našemu engineering C-levelu a VP, protože v daném období to bylo pod engineeringem, a ta podpora z horního vedení byla klíčová.

Druhým faktorem, který jsme se naučili hard way, je, že to musí být velmi jednoduché pro vývojáře, pro inženýry.

Musí to být tak jednoduché, že stačí začít streamovat data, nebo je dávkově odčítat.

My jsme hodně času věnovali tvorbě terraform modulů, napsali jsme dokumentaci, vyladili příklady, snažili se vše zjednodušit, jak jen bylo možné.

Vím, že to není všem jednoduché, ale před dvěma lety to bylo asi stokrát složitější.

Takže klíčovou věcí je snižování kognitivní zátěže.

Tedy da se mluvit o devops a data ops, platforma má existovat tak, aby se o to vývojáři nemuseli starat, aby prostě „jenom klikli“.

Ano, platforma, kterou máme, je naším mottem – musí to být self-service.

Data platform tým by neměl muset nikomu pomáhat ani zasahovat.

Když to uděláme dobře, jsme „out of the loop“.

Například mohu uvést příklad z tohoto měsíce ohledně kvality dat.

Snížení zapojení data platform týmu – centralizovaného týmu „out of the loop“ – to byl náš ideál.

Neříkám, že je to úplně na sto procent možné, ale snažíme se být hlavně konzultanti.

Cílem je, že když chceš vystavit data, nebo je konzumovat, nepotřebuješ službu někoho jiného.

Martina, zmínila jsi kromě interních dat i externí. Jak moc to jde posunout, když data konzumuješ externě?

To je velmi velká výzva a neříkám, že to máme dokonale vyřešeno.

U interních dat jsme většinou dokázali najít vlastníka, nebo ho jsme určili, když nebyl jasný.

Komu vlastně data patří?

Přesně tak.

Před několika týdny byla na Slacku debata ohledně poptávky po datech z fintech domény a fintech engineeringu.

Odpověď byla: „My vám ta data nevystavíme, protože nevíme, jak je garantovat.“

Upřímně mě to těší, protože když data nejsou garantovaná a není možné popsat jejich kvalitu, není dobré je dávat dál, aby se na ně nikdo nespoléhal.

Vím, že to může znít krutě, ale na to jsme došli.

Co se týče externích dat, to je obrovský problém, protože se snažíme najít nejbližšího konzumenta těchto dat.

Když mluvíme o datech, která získáváme zvenčí nebo kupujeme, snažíme se najít, kdo je jejich vlastník.

Někdy to funguje, někdy úplně ne.

Důležité je, že pokud data nemají vlastníka, neměli bychom je používat.

Co se týče interních dat, kdy doménový tým je vlastníkem dat, máme některé týmy, které jsou ohledně spolupráce skvělé.

Jsou zde datalidé, vlastníci dat. Máme tam jeden tým, který proaktivně hledá chyby ve svých datech, v datových modelech a reportech postavených nad nimi, a dobrovolně nás kontaktují, například když se domnívají, že nějaké číslo je mimo realitu, nebo je spočítané jinak.

Tyto síly už se postupně spojují – jak ze strany producenta, tak i konzumenta dat.

Komunikace o kvalitě dat se aktivně řeší a diskutuje.

Vlastníci dat jsou většinou inženýři, kteří staví systém a mají zodpovědnost za to, že data jsou správně generovaná.

Nebo je to doména více byznysová, zlomek odpovědnosti může být i na konzumentovi, který s daty pracuje dále.

Máme systém organizovaný tak, že existují source aligned data produkty, které skutečně můžeš používat a někdo je garantuje.

Nad nimi potom analytics engineering, pokud je třeba, vytváří agregované datové produkty.

Analytics inženýři mají také doménovou specializaci a pracují blízce s engineering týmem.

Takže za source aligned data odpovídá vždy engineering tým, který systém staví.

Když je potřeba agregovaný model, má za něj odpovědnost analytics engineer specializovaný pro danou doménu.

Mohli bychom si na jednom příkladu popsat, jak takové vlastnictví dat vypadá technicky?

Předpokládám, že to nekončí pouze u meetingu, kde se řekne „vy vlastníte ta data“ a tím to končí.

Dobře, můžeme to popsat společně, protože to má dvě části.

Za jednu velmi důležitou část chci poděkovat Kateřině, která ji vymyslela a rozjela skvělý proces.

Jak to tedy funguje nebo fungovalo při on-boardingu datových produktů?

Sestavili jsme důležité atributy, které potřebujeme od dané domény.

Šli jsme za engineering týmem a product managerem dané domény, představili jsme jim celý návod, co od nich potřebujeme.

Nejraději máme, když si uvědomí vlastníci, že nechceme vytvářet přesnou fyzickou kopii modelu z jejich databáze.

Chceme získat business pravdu o tom, co se v dané oblasti děje.

Pokud se nám podaří v některých doménách, hlavně u streamingu, modelovat nějakou business událost, například uložený booking, což…

[Pokračování textu zde končí.]

Text přepsaný do spisovné češtiny:

Obsahuje celou tu byznysovou pravdu, neobsahuje 50 %.

Takto jsme přišli, zkusili jsme i namodelovat ten event, když to nešlo, tak jsme alespoň nějakou abstrakci v podobě view vytvořili a publikovali to batchovým způsobem. No a pak vlastně přišla další důležitá věc, a to je zaručit jednak nějaké service level agreement na to, že ta data tam budou v tu a tu dobu v určité kvalitě, a zároveň si hlídat, že když vznikne daná doména, ten produkt svým životem, přibudou tam nové funkce, tak aby se to správně reflektovalo i do toho source line data produktu. A zde se dívám na Katie, protože ona přišla s takzvaným data collaboration procesem, který nám toto hlídá. Katie, pochlub se.

Jo, v podstatě ta potřeba nějakého procesu vznikla tak, že už to technicky fungovalo ukázkově, máme data mesh, produkují se data, máme nějaké tabulky a tak dále, ale ve chvíli, kdy došlo k nějaké sémantické změně dat nebo kontextu, nevím, změnily se hodnoty, které se propagují do sloupce, cokoli, co nějak ovlivnilo kontext těch dat, tak nám to v podstatě nikdo neoznamoval, my jsme o tom nevěděli a končilo to tak, že jsme měli v lepším případě výpadek dat, a v horším případě jsme to ani nevěděli a závěry z dat, která jsme vyprodukovali, byly dost odlišné nebo nám v podstatě dávaly špatnou odpověď.

Takže jsme si sedli v Kiwi a uznali jsme, že tohle je fakt problém a potřeba s tím něco udělat, proto jsme vymysleli nějaký data collaboration proces, což je proces, který zajišťuje spolupráci mezi analytics zástupci nebo lidmi pracujícími na nějakých agregacích, doménovými vývojáři a produktovými manažery, kteří jsou za to zodpovědní, jaké funkce budou vydávány, co se bude dít s tím produktem a tak dále.

Je to v podstatě soubor nějakých hard a soft opatření, kdy soft opatření jsou takové zásady komunikace živě mezi týmy. Nastavili jsme si, kdy je nutné komunikovat, v jakých případech, v jakém kontextu, u jakých tabulek, jakých změn a tak dále.

Máte nějaká ponaučení? Říkáš, že to je samozřejmé, ale představuju si, že variant, jak to udělat, je nespočet. Přišli jste na to, co je moc detailní, co je moc svazující a co je naopak příliš volné a pak to nikdo neudržuje?

Samo o sobě bylo náročné přesvědčit data ownery, že něco takového je potřeba, protože oni neviděli ty problémy, které jsme měli my. Museli jsme jim často ukázat hodnotu dat a ukázali jsme jim, že když tato hodnota není, dostane se to až k senior managementu, investorům a tak dále, a to je něco, co nikdo z nás nechce mít na svědomí.

Takže prvním klíčem bylo ukázat jim tu hodnotu dat, druhým trpělivě opakovat stále dokola, že je to důležité, a být dost vytrvalý, nenechat se odbýt, protože tam byl určitý odpor. Jak říkala Martina, čím jednodušší proces, tím lepší pro všechny.

V podstatě jsme to ohraničili tak, že ve chvíli, kdy se mění něco v tabulkách, které používáme, většinou máme seznam kritických datasetů, tak v tu chvíli by nám měli prostě dát vědět a my si už vyhodnotíme, zda je to informace, se kterou musíme něco dělat, nebo ji můžeme ignorovat.

A k těm soft a hard opatřením – stále je mým snem, že to budeme mít podchycené hard opatřeními. Tedy například data quality checky, detekce anomálií a tak. To máme, máme interní nástroje, nyní používáme jiný tooling, ale to ukáže ex post, že nastal nějaký problém, že se změnila distribuce nějakého atributu a pravděpodobně nastane problém v datech nebo něco začne chybět.

Ale to je pozdě. Můj nesplněný sen je mít to podchycené nějakými integračními testy. To znamená, že data, která vystavují týmy, jsou na nějakém místě ve formě, takže si představuji, že když přidám novou funkci, budu validovat, že když udělám booking, tak očekávám, že hodnota je uložena na nějakém mocku nebo sample datech a zároveň v analytické rovině, v datovém produktu, jsou tyto očekávané hodnoty.

Takže vidím budoucnost v dvojím přístupu: tento kolaborativní proces soft a pak hard opatření, automatické enforcement. Myslím, že tam ještě nejsme, ale tam je cesta, kombinace obou přístupů.

Když říkáte, že to má být co nejjednodušší, a jsem doménový vlastník, softwarový inženýr, co pro mě znamená vystavit vám ta data? Co to znamená úplně poprvé? Asi tam přijdou nějací pomocníci od vás z dat a nastavíte pipeline, že?

Ano. Technicky je to tak, že pokud ještě nemáte za sebou onboarding proces, dostanete návod, jedna A4 dokumentace, kde je takový blueprint, jak pipeline postavit, a někdo z data platform týmu vám reviewne váš kód. Ale důležité bylo, že to neuděláme za ně, protože tím se nikdy nepozná kód pořádně.

Zároveň jsme to udělali tak jednoduché, aby to nevyžadovalo být data inženýrem s několikaletou praxí. Když už se to jednou stane, máme dva způsoby: buď batch, nebo stream.

Stream je z implementačního hlediska jednodušší, protože pro softwarového inženýra to znamená, že na nějakém bodě zavoláte publish event bez drobných komplikací a publikujete do topiku. Batch je zase vlastní pipeline v Airflow, která posílá notifikace do kanálu v případě selhání.

Pokud je tým jednou onboardnutý, tak business as usual probíhá tak, že se někdo ozve – produktový manažer, analytik, inženýr – že potřebují od daného týmu nějaká data, a ti to rozšíří, přidají novou entitu do datového produktu, nový atribut a tak dále. Data Quality Validations (DQVčky) jsou také součástí onboarding procesu – někde je coverage lepší, jinde horší – ale tím onboarding končí a produkt žije vlastním životem.

Práce ownerů ale nekončí, protože pak analytics tým nebo datový konzument má často mnoho dotazů na kontext dat, co znamená která hodnota, který sloupec a podobně. A většinou ti ownři jsou zároveň producenti agregovaných datových produktů, které analytici zveřejňují. A právě proto je krásné vidět tu živou diskuzi o datech mezi softwarovým inženýrem a analytikem o tom, co co znamená.

Co se stane, když spadne data quality check? Předpokládám, že se někomu pošle notifikace, ale řešíte i pohled konzumenta, například: „Tady nám vypadla data z bookingu, tak je veškerý reporting založený na těchto tabulkách nyní neplatný?“

Máme například zdravý boj o to, co je data quality check a co je „fašismus“ – nebo business anomálie, tedy situace, kdy data jsou v pořádku, ale děje se něco podivného v byznysu. Podle toho se rozhodujeme, jak postupovat.

Pokud pipeline spadne, modely se nenapočítají, dojde ke skutečnému incidentu a nastupuje pager duty, někdo musí v noci vstávat a řešit to.

Pokud jde o nějaký outlier nebo méně závažnou anomálii, přijde notifikace do Slacku a řeší se to další den. Existuje tedy taková hranice mezi urgentními a méně urgentními incidenty.

Některé týmy jsou schopné zastřešovat oba typy data quality checků – kritické chybějící data i byznysové kontroly, například zda se v datech neobjevují položky, které by tam neměly být, nebo nejsou data správně propagovaná.

Co se týče technologií, které používáte a jak v kódu vypadá to domlouvání se o vlastnictví?

Když jsme začínali, technicky jsme použili, co bylo dostupné. Vím, že dnes mnoho vendorů nabízí datamesh ready řešení, ale před dvěma lety jsme vzali, co jsme měli.

V datameshovém konceptu se používá terminologie „output port“, což je způsob, jak přistupovat k datům – může to být SQL, API endpoint, file nebo stream. Data produktu by se mělo dát přistupovat různými způsoby.

U nás je to méně agnostické – máme BigQuery na Google Cloudu jako analytics engine. Do BigQuery tabulek ukládáme data, která se mohou i streamovat přes Pub/Sub, což je také jeden z output portů. Pub/Sub data se mohou dále ukládat do BigQuery, což je SQL output port.

Dále máme případy, kdy data (například srdcová data) jsou v DCS bucketu, což je další výstupní port. Data tedy reprezentují významově stejný datový produkt, ale jsou konzumována různými způsoby.

Technologický stack je tedy GCP, BigQuery, Pub/Sub, Dataplex – což je built-in GCP data katalog. Ten jsme ale zjistili, že není vhodný pro všechny uživatele, můžeme se k tomu vrátit.

Data kontrakt realizujeme tak, že si vytvoříme BigQuery dataset, připevníme ho Terraformem. Všechno, co vytvoří softwarový inženýr, se dělá v Terraformu: vytváří BigQuery tabulky, pipeline v kódu a tak.

Na konci přidávají označení, kdo je owner, kde je Slack kanál, kontakty na osobu a další metadata – SLA, frekvence updatu, data quality odkazy a další kontextové informace. To je kódově zachytená kontextová informace.

Co ale ještě není podle mých představ, je automatické prosazování (enforcement) tohoto kontraktu – že by něco automaticky kontrakt četlo a na základě něj se něco dělo.

Je začínající boom nástrojů okolo data kontraktů, které jsou aktuálně velmi aktuálním tématem.

Je to jediný způsob, jak to dělat? Mám dojem, že jste si to vzali ze software engineeringu: end-to-end zodpovědnost, pager duty a tak podobně. Předpokládáte, že takto je nový průmyslový standard a datové produkty budou takto vznikat? Nebo existují jednodušší způsoby pro menší firmy?

Pro menší firmy si myslím, že by toto byl overkill. Jak jsem zmiňovala, došli jsme do bodu, kdy už nám to technicky a organizačně neškálovalo kvůli velkému množství dat a týmů.

Menší firma, která nemá tolik dat ani tolik různých zdrojů, nepotřebuje takovýto komplexní systém. Pokud má dva doménové týmy, začít hned s papírováním a kontrakty se mi zdá zbytečné.

Problém v Kiwi byl ten, že máme mnoho doménových týmů, hodně analytiků a analytics inženýrů, takže vznikla potřeba nějaký kontrakt vynutit, protože už nikdo nevěděl, která data jsou správná a která jen kopírovaná z původní databáze.

Ten data tag, o kterém mluvila Martina, se zobrazuje v datovém katalogu Kiwi. Uživatelé, když se dívají na data nebo metriky, vidí, že dataset má data kontrakt, který jim dává jistotu, že data jsou správná. Aspoň si to myslíme.

Tam svítí jméno toho doménového ownera, jakože kdo je za data odpovědný?

Ano, je to pod tím podepsané. Je tam určitý psychologický efekt – když něco spadne, je jasné, kdo je za to odpovědný.

Úkol je velmi náročný – koordinace byznysových domén i technologií. To je kompletní audit firmy.

Jak náročné to bylo a jak dlouho to trvalo?

Trvalo to asi dva roky. Ale opakuji, nebyla to zastávka na dva roky, snažili jsme se kontinuálně ukazovat hodnotu, že jdeme správným směrem.

Pokud potřebujete, mohu text dále upravit, ukázat oddělené části apod.

Směrem k něčemu lepšímu. Mohu ještě dodat, že jsme se rozhodli jít cestou buy vs. build, což nám hodně uvolnilo ruce, například u datové platformy. Mluvím o Airflow, předtím jsme investovali hodně našich zdrojů a kapacit do budování interních nástrojů. Když jsme si ale řekli, že pokud něco už někdo vymyslel, raději si to koupíme – ať se to týká Degové, Čeka a tak dále – ušetříme tím čas a rozvazujeme si ruce.

Platforma díky tomu zhruba zkrátila čas asi o polovinu, takže lidé byli nadšení, protože to nebyla jen investice, ale přinesla to přímé a zřejmé výsledky v rozumném čase.

Co se týče datových kontraktů, od prvotního setkání, kde jsme začali diskutovat, jak to zrealizujeme, to trvalo asi tři čtvrtě roku. Je to běh na dlouhou trať. V současné době máme onboardovaných zatím pouze asi pět týmů do procesu spolupráce s daty – což nejsou jen tak ledajací…

Pět týmů z kolika? Máme asi 20 týmů. Ano, desítky. Takže asi čtvrtina.

Není to pouze o tom, že si s nimi sedne člověk a vysvětlí hodnotu dat, ale je to také neustálá práce, protože i doménoví vlastníci najdou nějaké chyby a je tam mnoho diskuzí a témat, co je třeba opravit. Proto je důležité například pořádat check-in schůzky s lidmi, kteří se zavázali k datovým kontraktům, protože někdy mají otázky, nejsou si jisti, jestli všechno dělají správně, chtějí feedback a tak dále. Není to tak, že se řekne: „Tady dáme nějaký kontrakt, hotovo, máme 20 týmů, můžeme pokračovat.“ Je to stálá práce.

A ještě hodně práce neznamená, že když máme nějaký proces, jsme za vodou a hotovo.

Jak do toho všeho zapadá koncept architektury Data Mesh? Zmiňovali jste, že když jste nastupovali, architektura byla spíše nějaký data lake nebo něco podobného. Když se mluví o self-service a podobně, většina firem totiž začala s data laky, data lakehouse a podobnými koncepty.

Vznikl u vás Data Mesh na základě těchto datových kontraktů, nebo jste naopak řekli, že potřebujeme Data Mesh architekturu, abychom organizačně udrželi zodpovědnosti?

Bylo to vlastně obráceně. Řekli jsme si, že potřebujeme ownership, a ten vlastnictví dat nastane opravdu tehdy, když data budou na doménách – opravdu u lidí, kteří rozumějí, o jaká data jde.

Technicky to možná není úplně jednoduché. Něco jsme zlili do velké PostgreSQL databáze, ale používali jsme i BigQuery. Nyní jsme to trochu otočili a řekli jsme týmům: Data Mesh koncept, doménové vlastnictví dat a self-service platforma. Máte platformu, publikujete data a ta budou ležet ve vašem GCP projektu – tedy vašem prostoru v Google Cloud Platform.

Máte strukturu v GCP v oddělených projektech, to je váš prostor se svými BigQuery tabulkami a Google Cloud nabízí možnost propojení mezi projekty, což byla jedna z výzev. Představte si, že toto je vaše, vy si manažujete přístupy k tomu, data jsou ve vašem prostoru, dokonce umíte alokovat náklady speciálně na váš GCP projekt. Zároveň však neztrácíme výhody centralizace data lake house, kde jsou data dostupná na jednom místě, ale infrastruktura je segmentována do samostatných GCP projektů na úrovni týmů.

Co je hlavním obchodním cílem tohoto projektu kromě přirozené potřeby dát data do pořádku? Asi to nejdůležitější je šťastný zákazník na konci. Vím, zní to jako klišé, ale data potřebujeme, abychom vytvořili dobrý produkt, aby zážitek z cestování byl plynulý, abychom věděli, kde jsme kompetitivní a kde je potřeba zabrat.

Chceme tedy z dat v konečném důsledku vytěžit byznysovou hodnotu pro naše uživatele.

Druhým cílem je zlepšit život nám – tedy dát lidem možnost self-service. Nechtějí čekat na Slacku na odpovědi na otázky typu „Kolik bylo bookingů v ten a ten čas.“ Některé z těchto věcí už máme pokryté, ale to je budoucnost – data musí být dostupná a lidé se mají sami obsluhovat. To je náš sen.

Pro koho to děláme? Pro našeho šťastného zákazníka na konci a pro naše šťastné datové konzumenty.

Self-service se už začíná dařit. Možná, Katie, máš nějaký pěkný příklad? Jeden tým v rámci produktové domény, ve které jsem, je Content Quality Team.

Před dvěma lety byl tento tým zcela závislý na analyticích a analytických inženýrech. Kontrolovali kvalitu obsahu a když byl nějaký problém, kontaktovali nás, že se jim něco nezdá v datech. Analytik musel většinou investigovat, protože Content Quality tým, jako datoví konzumenti, moc nechápal, co se v datech děje, do jaké tabulky koukat v té obrovské databázi s stovkami tabulek, navíc většinou neměli přístup. Vše bylo velmi nešikovné.

Tento stav byl před dvěma lety. Nyní je ten tým plně samostatný, my o nich v podstatě nevíme. Agregovaný datový produkt, který používají, si získal důvěru uvnitř jejich týmu. Vědí, že data jsou správná a že odrážejí to, co potřebují vidět.

Pokud mají podezření na kvalitu dat či na nějaké záznamy, kontaktují přímo doménové vlastníky dat. Už nás neoslovují. My maximálně hrajeme roli zprostředkovatele komunikace, ale nejsme ti aktivní detektivové, kteří hledají chyby. Týmy si to řeší mezi sebou a my jsme mimo hru.

Změnilo se díky tomu složení týmu? Představuju si, že se to rozvolnilo, lidé, kteří byli zvyklí vytvářet reporty, přešli do business týmů, jsou blíže byznysu, a naopak se tým platformních inženýrů a analytiků zúžil nebo hodně změnil.

Pokud jde o analytics representatives, snažíme se podporovat self-service co to jde. Je to možné tam, kde jsme proces implementovali a funguje dobře. Analytici se tak mohou zaměřit na generování insightů pro business a přinášet větší hodnotu. Ale ještě nejsme úplně tam.

Self-service není jen stavět reporty nebo dashboardy – to by neměla být role analytika. Používáme BI tool Looker, který využívá asi jen třetina lidí na denní bázi pro drill down, slice and dice.

Tam, kde datový agregovaný produkt existuje, je obrovské snížení ad hoc žádostí. Kde produkt není, je to složitější.

Je super, že analytici nemusí klikat dashboardy. Samozřejmě se to dotýká i data science – modelování, pokročilé použití, automatizace.

Jak do toho celé domény zapadá tradiční BI svět, kde „číslo je číslo“?

Naše data science týmy jsou soustředěné hlavně kolem domény vyhledávání – tedy výsledky vyhledávání itinerářů, ale zejména oceňování a pricingu. Jsou doménově vyhraněné.

Je důležité říct, že předpřipravené datové produkty jim velmi zkracují čas na přípravu dat, feature-izaci. Hlavním cílem v této oblasti je zkrátit životní cyklus vývoje nových ML modelů.

Když máš vyčištěná, garantovaná data, je potom jednodušší realizovat nové nápady a stavět na nich ML modely.

Díky self-service a vizibilitě si lépe umím říct, co je možné postavit a koho kontaktovat, když data chybí.

Ještě máme prostor vylepšit spolupráci, protože máme spuštěných více projektů.

Hodně jsme mluvili o organizaci, teď se bavme o technologii. Martina, na začátku jsi říkala, že dnes všichni tvrdí, že jsou ready na Data Mesh, ale narážíte na limity některých nástrojů, které byly postaveny na staré architektuře? Nebo jsou to spíše organizační věci a tech stack nemusí jít tolik dopředu?

Je to kombinace. Jak jsem zmínila u mého snu o datových kontraktech, nemáme automatizované řešení, doufám, že jej jednou budeme mít.

Dobrý příklad je, že GCP umožňuje mít BigQuery entity v rámci svých projektů a dotazovat je, zatímco AWS tuto funkci neměl zpočátku, přišel s ní později.

Dále jsme měli self-hosted Airflow a chtěli zorganizovat Airflow tak, aby každý tým měl vlastní workspace, což nešlo na některých managed Airflow platformách – jednu jsme našli, která to umožnila.

Firmy začínají sledovat tento trend decentralizace, ale ještě není mainstream.

Ještě mám jednu otázku. Mluvíme o Data Mesh architektuře a datových kontraktech jako o základním lepidle, které přineslo odpovědnost a odemklo procesy.

Někteří hosté řeší stejné problémy hlavně z pohledu data governance, tedy zavádění správy dat nebo lineage nástrojů, které vytvoří mapu datového toku a ukážou, jak data vznikla.

Vnímáte data governance a lineage jako jiné pohledy na totéž, nebo vám šlo hlavně o organizační a osobní stránku, protože týmy byly ve zmatku?

Všechno je propojené. Ohledně data governance máme velmi funkční tým, který rozpoznává, na co se máme zaměřit.

Nechceme vařit oceán, ale kategorizujeme data na velmi důležitá, dobrá k mít a pak na dáta, kde nemusíme tolik investovat effortu do kontraktů, on-call služeb a podobně.

Toto drží právě data governance tým, který dohlíží, co je potřeba splnit u nejdůležitějších dat – kontrakty, kontroly kvality, garance.

Lineage jsme řešili domácky, měli jsme nástroj, který notifikoval ve Slacku změny a pingoval centralizovaného vlastníka dat.

BigQuery nabízí automatizovanou lineage, ale my ji neuměli dobře využívat.

Dokud jsme neměli jasného vlastníka dat, bylo zbytečné vědět, kde se něco pokazilo, protože jsme nevěděli, co s tím dělat.

Takže lineage je důležitá, ale ne jako detailní pohled do zdrojových databází, protože rozhraní pro vydávání dat je nastaveno a garantováno v datovém produktu.

Důležitější je pak zkoumat, jak vznikají agregace, co a jak se počítá.

Lineage nám do konkrétního problému moc nepomohla, alespoň nástroje, které jsme použili.

Chci dodat, že lidé „zdola“ velmi uvítali existence Data Governance týmu, protože konečně cítíme, že za námi někdo stojí.

Už nejsme ti, kdo jen dupou a křičí, že data jsou špatná a čísla nesedí. Teď máme někoho, kdo nám pomáhá cestu prorazit.

Kdo se pomůže vyřešit problém s doménovým vlastníkem dat, který je ochotný investovat vlastní čas, otevře diskusi a navrhne řešení.

Pro lidi, kteří vytváří agregované datové produkty, je to velký krok kupředu.

Jaké jsou vaše hlavní lessons learned ze dvou posledních let? Co vás celý proces naučil, co byste udělali jinak, co byste doporučili někomu, kdo je ve stejné situaci jako vy před dvěma lety?

Začnu datovými kontrakty. Naučili jsme se, že klíčové je, aby někdo „koupil“ koncept a pochopil problém, který nás trápí.

Umět prodat hodnotu dat bylo pro nás velkým pomocníkem. Bez toho bychom to nedokázali tak prosadit.

Druhá věc, kterou chci zdůraznit, je, že to může být velmi frustrující proces a je třeba se obrnit trpělivostí.

Není to tak, že napíšeme nějaké pravidlo, nasadíme data a je hotovo přes noc.

Je to práce na léta, takže nevzdávejte to.

Chtěla bych dodat, že je potřeba vydržet i komunikačně – že lidé mají tendenci lpět na starých zvyklostech a problémy, které jsou už vyřešené.

Je to důležité ustát, protože lidé žijí ještě v minulosti.

Pro mě to byl velký change management, transformační projekt.

Byl to datový projekt, nebo spíše projekt inženýrský?

Ty jsi na začátku, Martino, říkala, že podpora nejvyššího inženýringu a ten jakýsi „štípl“, že máte nějakou autoritu měnit zavedené pořádky, byla hrozně důležitá. Když bych se teď podíval na priority inženýringu, byla to velká věc, anebo byla to velká věc pro vás, ale vlastně malá věc pro ně?

Mně to zní jako velký zásah, na který se muselo spojit hodně lidí, organizačně to bylo složité, nějaký onboardingový proces. Do toho se samozřejmě vyvíjel produkt, nastoupili jste za covidu, kdy řešíte stavení, ten trh se musel brutálně měnit tam a zpátky, priority kolísaly, rozpočty se škrtily. Takže vlastně…

Asi jsme měli trochu štěstí v tom, že když jsem přišla začátkem roku 2021 do Kiwi, tedy opravdu v té vrcholné době covidu, ale byla tam vždy taková kultura nebo mindset, že covid přejde a bude to zase dobré a lepší, a vlastně pak ta čísla bookingu několikanásobně překonala to předcovidové období. Lidé byli opravdu hladoví po cestování, toto se skutečně stalo. Byla tam vždy optimistická nálada, že má smysl do toho investovat, upravit si to a potom to budeme moci využít, až se trh opět obnoví.

Ale zpět k té otázce, určitě se to dalo uskutečnit díky leadershipu inženýringového týmu, bez toho by to určitě nešlo. My jsme se mezitím přesunuli pod jinou část organizace, data se přesunula, máme nového VP of data, takže teď spadáme pod produktovou část. I v tom lze najít nějaké benefity, protože teď můžeme více spolupracovat s byznysem a podobně.

Vím, že když lidé spolu komunikují, organizační struktura není až tak důležitá, ale určitý její aspekt to samozřejmě má. Je to nějaký signál? A co tato změna vlastně přinesla, když máte vlastní datové oddělení a už nejste součástí inženýringu?

Bylo to čistě organizačně-kompetenční, nebo to zapadá do toho, že jste samostatný produktový tým, který má datovou platformu jako svůj produkt a ten si vyplácí?

To je velmi dobrá otázka. Možná posluchači znají zákon Conwaye, že organizační struktura určuje architekturu. Já si ale trochu myslím, že to není tak úplně pravda, protože v tomto uspořádání stále děláme to stejné, opravdu máme inženýry per domény, analytiky per domény, softwarové inženýry v doménách, takže pokračujeme stále v této linii a dává to takto smysl.

To, že jsme organizačně spolu, je spíše o tom, aby zde byl funkční alignment, tedy že profesionální vývojáři a lidé s daným řemeslem vědí, jak spolu růst. Tak na to teď nahlížím, uvidíme, jak to bude za rok, ale zatím jsem optimista, že tak, jak to máme nastavenu, to i nadále funguje, protože v tomto uspořádání jsme zhruba půl roku.

Dále datová platforma je produkt a je to, jak jsem říkala na začátku, téměř dvoutýmová platforma. Nyní je datová platforma prostě tím subjektem, který poskytuje platformu, ten „link“ a nemá řešit konkrétní pipeline, úzké sítě a tak dále. Je to tedy štíhlý tým, který se stará o to, aby všichni konzumenti dat, producenti dat, ML inženýři mohli pracovat rychle a efektivně.

Super! A teď mi přišla na mysl tématika ML inženýrů. Jak se díváte na novou vlnu generativní AI a možné use case?

Já předpokládám, že když máte již vnitřní pořádek, tak cokoliv nového nebo nějaká inovace je tím jednodušší, jak jsme už mluvili o data science.

Jak se díváte na generativní AI modely?

Vidím to ze dvou aspektů. Jeden je opravdu ten, co je pro koncového uživatele, a tomu jsme se snažili ihned věnovat, jakmile to vyšlo ven, ať to byl PaLM nebo GPT a mnoho use case, velká naděje v zákaznickém servisu. Ale osobně mě zajímá zejména ta vnitřní operational efficiency.

Tím, že přišla generativní AI, najednou lidé, kteří neměli tolik dovedností, například v SQL či Pythonu, mohou vzít data, nahrát je do tzv. cold interpreteru GPT-4, ptát se, a on jim zpracuje analýzy a podobně. To je na jednu stranu skvělé, na druhou stranu to přináší velká rizika.

A to proto, že když, jak jsme si řekli, garbage in, garbage out – pokud do systému vložíme data, která nejsou validovaná, nemají semantický smysl atd., může to vést k chybným výsledkům. Já jsem to sama otestovala – nahrála jsem vzorová data a GPT mi zaměnil source a destination letiště, a tak generoval nesmysly.

Proto je o to důležitější mít vyřešenou baseline, základní vrstvu, mít dobrou dokumentaci, mít garantováno, že data jsou kvalitní, a tím pádem být schopni naskočit na jakoukoli takovou vlnu, která přijde.

Druhá věc je pojem halucinace, tedy zamyslet se, jak tento fenomén řešit. Nikde nemáme záruku, že se to v budoucnu nebude dít i s těmi nejlepšími a nejkvalitnějšími daty. Prostě to tam bude pořád.

Tuto část ještě nemám úplně vymyšlenou, jak to udělat, aby nám AI obecně pomohla dospět k výsledkům s co nejnižším rizikem zkreslených či úplně nesmyslných výsledků.

Mám k tomu ještě jednu poznámku. Minulý týden jsme byli s Kateřinou na konferenci, kde jsem mluvila s člověkem z datové platformy velkého foodtech startupu a ukázalo se, že přesně řešili datové kontrakty.

Vzpomněla jsem si na jednu reálnou situaci, kdy měli nějaký zdroj dat a jeden atribut přestal být plněn, ale tak plíživě, že nezazněl alarm. Měli model, který doplňoval ten atribut na základě nějaké distribuce, aby byly data použitelná pro trénink dalšího ML modelu.

Ale ta data postupně mizela tak, že nakonec tam nechodila žádná skutečná data a model je jen dopočítával. Nakonec tedy trénovali na zcela simulovaných datech, aniž by o tom věděli, protože kontrakt nebyl dostatečně ošetřený nebo zajištěný.

Nevím, co by mě děsilo víc – kdyby to vůbec nefungovalo, nebo kdyby to fungovalo extrémně dobře, protože bych se asi lekla, že už třeba nepotřebuji kvalitní data. Možná se jednou dostaneme do fáze, kdy budeme konzumovat metaverzum a fyzická realita nebude tak důležitá.

Martino, Kateřino, moc děkujeme za tento příjemný rozhovor a přeji vám, aby se vaše vysněná self-service budoucnost naplnila.

Děkuji moc.

Děkujeme.

A to je všechno. Děkujeme, že jste doposlouchali další díl Datatolku. Děkujeme také našim partnerům – BigHubu, Vypnotu, Mantě, Natinu a také mně, GeneBeamu, Seznamu.cz a MUSE.

Pokud vás zajímají další informace ze světa datových technologií a československé datové scény, navštivte naše stránky datatolk.cz.

Nechť vás provázejí data.