Podcast

Dobrý den, moje jméno je Jirka Vešerek.

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

A vítáme vás u dalšího dílu Datatolku. Dneska naše pozvání přijala skutečně speciální host, a tím je Adrian Toman, člověk, který vystavil data v Productboardu a nyní pracuje jako data engineering manager v Paylocity.

Ahoj, Adriane.

Ahoj.

Ahoj, vítej.

My dneska využijeme Adrianovu návštěvu a budeme ho zpovídat na téma data engineeringu a nějakých best practices a budeme tahat z jeho zkušeností, ať už těch čerstvých teď v Paylocity, nebo právě productboardích.

Než tak jako začneme a vrhneme se do data engineeringu, pipeline first approach a podobných témat, tak Adriane, jaká byla ta tvoje cesta k datům, k té datové scéně a k stavění takovýchto produktů?

Tak já jsem začal v roce 2012 v Gooddate jako solution engineer, v části jako Gooddate consulting, kdy ta hlavní moje zodpovědnost byla vzít od zákazníka data, zpracovat je a nalít je do toho našeho produktu Gooddate. Takže v té době se to ještě jmenovalo solution engineer, ne data engineer, používali jsme nějaké nástroje, ale bylo to takové moje první seznámení s této oblastí, řekněme.

Tam jsem pak přešel do jiného týmu nebo začal jsem tam manažovat tým, kterému jsme říkali managed services, který dělal složitější pipelines, řekněme. Když to byl zákazník, který měl data v nějakém úplně nestandardním systému, potřeboval vyřešit nějaký víc složitější problém, tak můj tým tam stavěl nějaké víc custom řešení pro ně. Takže bylo to celkem zajímavé a hodně jsem se tam naučil.

Můžeme se tady klidně u tohohle rovnou zastavit? Co to znamenalo složitější pipelines? Co vlastně z této doby si odnášíš?

Je to tak. Gooddata v té době používala na pipelines klikací nástroj, který se jmenoval CloudVTL, oni to pak přejmenovali na Cloud Connect. Já jsem si tam vybudoval obrovský odpor k klikacím nástrojům, protože ty tooly jsou skvělé na to, když tam se něco na začátku nakliká a vytvoří. Ale ve chvíli, kdy tam máte něco většího, tak vidíte před sebou plachtu nějakých krabiček a vůbec netušíte, co se tam děje, jak se tam děje, kde máte udělat nějakou změnu. Byla to úplná hrůza.

Takže my jsme v té době začali přemýšlet o nějakém jiném přístupu, jak by se to dalo dělat. A hlavně jsme se chtěli zaměřit na ten počátek té pipeline. To znamená dostat ta data z toho source systému toho zákazníka a dostat je k nám, abychom nad nimi mohli nějakým způsobem pracovat.

A v té době Gooddata v podstatě fungovala tak, že přišel zákazník a řekl: „My tady máme data, tady v tomhle systému potřebujeme, abyste je vytáhli, tady vám na to dáváme nějaké peníze a dostanete je k nám.“ Takhle nějak ten projekt pak spadl do consultingu a my jsme v té době třeba uměli dostat data z nějakého SFTP, uměli jsme je dostat z nějakého strojku, ale když už to bylo nějaké třeba apíčko přímo té firmy nebo nějaké jiné úplně nestandardní endpointy, tak tam to bylo něco, co jsme potřebovali vybudovat.

A my jsme v podstatě ten můj tým vždycky dostal nějaké zadání: data jsou tady, potřebujeme je dostat do databáze. Takže my jsme začali tvořit nějaký základní tooling, který se připojil do toho zdroje, data stáhl a nějakým způsobem je naintegroval do té databáze. Takže to byl ten náš hlavní úkol toho týmu.

No a jaký typ projektu to byl? Bavíme se asi o něčem před rokem 2015? 2013, 2014?

Já myslím, že když to zasadíme na nějaké časové ose, tak to byl rok 2015. Co bych tady jako zmínil, je, že my jsme v Gooddate byli omezení tím, co a takovou technologii, kterou v té době podporovali. A tam bylo rozhodnutí, že datové věci se budou stavět v Ruby, což bylo celkem zajímavé rozhodnutí i v té době, protože teď, když se na to podíváme zpětně, Python to všechno převálcoval, ale GoodData tlačila Ruby relativně dlouhou dobu.

Takže my jsme se rozhodli: „Hele, tak pojďme postavit něco v Ruby.“ Ve své podstatě jsme vybudovali velmi zajímavý tool, který měl dvě části. Vždycky byla část, která vzala data a zaintegrovala je do databáze, a pak byla část, která ta data stáhla z toho zdroje a připravila je v nějaké generické formě tak, aby se dala zaintegrovat do databáze.

A toto bylo asi první místo, kde jsem se trochu zamiloval do modulárního přístupu v data engineeringu, protože jsme vybudovali dva základní moduly. Jednomu jsme říkali sourcing modul a druhému integrační modul.

Sourcing modul se připojil k databázi a stáhnul data na nějaké úložiště. Teď tomu budeme nově říkat datalake nebo něco podobného. Velmi první implementace nebo naše custom implementace. V té době jsem nevěděl, že tomu tak říkáte, ale nějak jsme to tam měli.

Ta část byla úplně nezávislá. Když jste chtěli stahovat data z nějakého jednoho API, druhého API, třetího API, data vám vždycky přistála v tom datalake v univerzální podobě, takže tam probíhala nějaká unifikace.

A pak byl jeden modul, který v té době byl jen jeden, ale byli jsme připraveni jich stavět víc. Ten vzal data a zaintegroval je do Vertiky. V té době Vertika byla databáze, kterou Gooddata používala a používá ji i teď.

Co nám to dovolilo bylo, že když jsme přišli k nějakému zákazníkovi s custom problémem, tak jsme jen řekli: „Hele, tady postavíme jeden downloader, který bude řešit specifickou oblast toho problému, připojí se ke zdroji, udělá nějakou tonifikaci a uloží to,“ ale už vůbec nemusí myslet na to, kam se data budou integrovat, co se s nimi bude dít a tak dále.

To byl můj první skutečný kontakt s modulárním přístupem ke stavění pipeline a snažil jsem se to pak aplikovat i na všechny ostatní projekty, které tam byly.

No super, Adriane, myslím, že téma modulárního přístupu k tvoření datových pipeline se ještě zde objeví několikrát, ale pojďme ještě dojet tvou kariérní cestu. Zmínil jsi, že tento přístup se ti vyplatil v další štaci, můžeš nám o tom více povědět?

Určitě. Další štace pro mě byla Rackboard, kde jsem nastoupil v roce 2019. Je zajímavé, že úplně na začátku jsem tam pracoval asi měsíc jako Ruby vývojář, což bylo celkem zajímavé. Pak jsme si s Hubertem a Danielem sedli a oni už dlouho přemýšleli o tom, že by chtěli vybudovat data pro Rackboardu, protože viděli zářnou budoucnost firmy a věděli, že data budou potřeba.

Já jsem byl ve správnou chvíli na správném místě, takže jsme se dohodli, že vybudujeme data engineering team a začneme stavět data v Rackboardu.

To bylo správné místo a správný čas?

Ano, přesně tak. Ten český prostor je relativně malý, takže přes známého známého se člověk dostane k informaci, že je nějaká otevřená pozice a přijde si popovídat. Pak už je to o tom, jestli je vzájemný fit.

Já myslím, že to bylo správné místo a správný čas.

Souhlasím. Adrián je jeden z hostů, které jsme si sem pozvali na základě vašich doporučení.

Právě někdo z tvých bývalých kolegů z Productboardu tě velmi vychválil a neměli jsme jinou možnost než tě sem za každou cenu dostat.

No dobře, a tak pojďme k roku 2019 v Productboardu. Když jsi přišel do Productboardu, jaké bylo tvoje zadání?

Zadání v podstatě bylo udělat interní analytiku v Productboardu. Přede mnou byly pouze základní pokusy o analytiku a používali tam stack Kebula a GoodData, ale nebyla tam velká spokojenost s tím, co existovalo.

Dostali jsme tedy volnou ruku s tím, abychom si postavili vše podle sebe, vybrali technologie, mohli jsme přebrat to, co bylo, nebo začít znovu a vytvořit základní analytiku nad daty a postupně ji rozvíjet.

Zadání tedy rozhodně nebylo striktní, což u startupu asi ani nejde.

Když se podíváme na Productboard, nastupoval jsem tam, když nás bylo asi 40, a odcházel jsem, když nás bylo 400.

To je desetinnásobný růst za tři roky, takže výzvy v oblasti dat a dalších věcí byly veliké a byla to velmi zajímavá doba.

Jak jsi přemýšlel nad budováním stacku pro tak dynamické prostředí? Zmínil jsi, že v Gooddate bylo hodně klikacích nástrojů, které tě nenadchly, a teď jsi měl volnou ruku na to udělat to podle sebe. Jak jsi postupoval?

To je hodně zajímavá otázka. Věděl jsem, že budeme muset velmi rychle iterovat.

Byl jsem si vědom, že když přijdu do byznysu a řeknu „dej mi zadání“, tak ho pravděpodobně dostanu hodně vágní.

Proto jsem to budoval tak, aby se dostávalo co nejvíce dat až ke koncovým uživatelům a budovalo se to až na konci.

Možná to trochu rozvedu.

Rozhodli jsme se používat stack Kebula, Snowflake a Looker.

Krása Lookeru jako BI nástroje je v tom, že tam můžete úplně na konci tvořit svůj datový model.

To znamená, když postavíte vrstvu pod tím genericky, tak do ní cpete velké množství dat a snažíte se správně refreshovat, nemusíte stavět specifické datamarty přímo v ETL, ale můžete je stavět v Lookeru, v metadatech.

To nám umožnilo rychle iterovat a přidávat věci.

Když jsme měli nějaký zdroj dat, neomezovali jsme se jen na deset políček, ale vzali jsme všechno a poslali to na konec.

Snowflake to všechno spočítá, množství dat nás netrápilo, protože je to sloupcová databáze a počet sloupců v tabulce nebyl problém.

V BI toolu pak jsme ukázali třeba jen deset polí, ale když došel požadavek z byznysu, že chtějí další pole, podívali jsme se a často jsme už data počítali, tak to bylo jednoduché přidat v Lookeru a uživatelé je okamžitě měli.

To samé platí i u spojování dat z různých modulů, když máme modul A a B a v budoucnu přidáme modul C.

Spojování těch modulů jsme také dělali v Lookeru, na úrovni metadat jsme rozšířili model o další data z modulu B nebo C, aniž bychom museli přepočítávat cokoliv v ETL.

To nám dovolilo rychle přidávat nová data.

To všechno umožnil Snowflake.

Nemyslím si, že tam člověk může vše optimalizovat, ale krása Snowflake je v tom, že netrávíte čas optimalizací, ale jednoduše tam data vložíte a funguje to.

My jsme nechtěli trávit čas přepočítáváním, indexováním a předpočítáváním dat, ale využít sílu Snowflake, dokud to půjde.

Jako startup jsme měli mnoho zdrojů, ale ne extrémní množství dat, takže nám bylo relativně v pořádku spojovat data až nakonec a nepočítat je předem.

Kam ses dostal za dva a půl až tři roky od té doby, co jste nastavili Snowflake, Kebula, Looker, a je to super rozhodnutí?

Ve firmě přibyl 360 nových kolegů, spousta klientů, nové datové zdroje a mnoho dat.

S čím jsi Productboard opouštěl?

Asi největší satisfakce pro člověka, který něco buduje, je, že to lidé používají.

Looker nám dával pěkné statistiky a když jsem odcházel, mělo to měsíčně aktivních uživatelů asi mezi 160 a 180.

To znamená, že téměř polovina firmy používala data, podívala se na ně, někdo s nimi pracoval více, někdo méně, ale lidé tam chodili.

Práce je často nevděčná, když věci fungují, málokdy někdo přijde poplácat vás po zádech, spíš přijdou s žádostí o přidání dalších funkcionalit.

Ale statistiky nelžou, lidé ta data konzumovali, dávala firmě přidanou hodnotu, a to je to, co od toho člověk chce.

To je můj oblíbený způsob, jak poznat startupový product-market fit: vypnete to a sledujete, jak dlouho a s jakou urgencí se klienti ozvou.

Tak hezky popisuješ, že dokud to funguje, nejsou pochvaly, ale když to hodinu nefunguje, tak má člověk plný inbox.

To je podle mě hezký příklad, jak je důležitá role data v organizaci.

Ano, přesně tak.

Ale ať dokončíme tvou dosavadní zářnou kariéru, teď Paylocity.

Na rozdíl od Gooddate a Productboardu je to brand, který jsem ani já neznal.

Můžeš nám říct něco o Paylocity a jak tě zlákali?

Musím přiznat, že před čtyřmi a půl měsíci jsem ten brand také neznal, možná trošku víc, ale je to firma, která je v Čechách prakticky neznámá, protože se specializuje na americký trh.

Nemají vůbec žádné pobočky nikde jinde.

Pro mě jako po Productboardu, když jsem hledal novou výzvu, jsem chtěl zůstat v data engineeringu a říkal jsem si, že je čas se možná podívat do větších firem a zjistit...

Jaké tam jsou výzvy a jak opět získávat zkušenosti z různých oblastí? Pailou City je v podstatě velká korporace, řekněme, má přibližně pět tisíc zaměstnanců, z toho asi tisíc pracuje v inženýringu, takže se jedná o opravdu obrovskou firmu.

Je celkem zajímavé, že u nich jsou data skoro na začátku. Je to firma, o které budu říkat my, protože jsme tam na začátku. Je to firma, která má většinu věcí v on-prem databázích. To znamená, že máme obrovské MS SQL servery, na kterých běží všechny data, na nichž funguje produkt, ale prostě to neškáluje. Rosteme také velkým tempem a už to prostě nestačíme.

A co děláte? Co děláme? Co si u vás mohu koupit? Dobře, to je důležité říct. My děláme v Americe payroll, což možná bude pro diváky z Čech zajímavé, protože v Americe jsou lidé zvyklí dostávat výplatu třeba formou šeků. Máme totiž různé pobočky po celé Americe, kde skutečně máme tiskárny na šeky, které pak těm lidem posíláme poštou, aby... oni dostali svou výplatu.

Specializujeme se na různé firmy, ne na IT sektor výhradně, ale na firmy obecně, které potřebují řešit výplaty. Náš use case je takový, že člověk si tam zadává odpracované hodiny a pak, protože v Americe může být výplata týdenní, dvoutýdenní nebo měsíční, přičemž dvoutýdenní je nejběžnější standard a někdy i týdenní, spustí se tiskárny, vytisknou se šeky a my zajistíme, že výplaty se dostanou k těm, kteří je potřebují.

To je jádro našeho produktu a k tomu přidáváme různé další služby, například jakýsi Facebook pro zaměstnance, kde si mohou zadávat hodiny apod. Postupně, jak rosteme, přidáváme další služby, které našim zákazníkům můžeme poskytnout.

Když si říkáte toto, není divu, kolik dat máte on-prem, zvlášť když je byznys založen na těch šecích a jejich posílání poštou.

A co tě zlákalo, kromě toho, že je to velká americká firma? Jaká je tvoje role nebo mise v tomhle? A než začneme mluvit o Pipeline First přístupu, můžeš to trochu přiblížit?

Jasně. Moje mise byla vést tým čistě zaměřený na data engineering. V Product Boardu se dalo říct, že to bylo data engineering plus data analytics, tady je to skutečně čistý data engineering, tedy práce s daty. Scope je velmi velký. Pro představu aktuálně máme asi 25 data inženýrů, přičemž já teď vedu 15 z nich, což je zatím dočasné, protože v Americe momentálně chybí jeden manažer. Můj tým v Čechách má osm data inženýrů.

Budujeme téměř od začátku datový stack na AWS. Snažíme se dostat data z on-prem řešení i novějších cloudových systémů do jednotného datového skladu a pak je poskytovat různým zákazníkům, ať už payroll klientům, interním uživatelům či data science týmu. V podstatě budujeme základy datového skladu, lake house, jak tomu říkáme.

AWS je nová technologie, kterou využíváme, protože celá firma rozhodla, že vše staví na AWS. To je celkem zajímavé, protože i když jsem měl v minulosti větší volnost při výběru technologií, tady to nelze změnit. Firma má uzavřenou spolupráci s AWS, týmy postupně migrují z on-prem do AWS, takže volba je jasná.

Jak konkrétně vnímáš AWS v Data Engineering? Jaké technologie a služby používáte?

Určitě. V naší raw zóně používáme S3, což je mimochodem velmi pěkná technologie se skvělým škálováním. Aktuálně stavíme transformační vrstvu na serverless platformě EMR.

Zajímavá je i technologie streamingového přístupu. Nikdy jsem s tím moc neměl zkušenosti, ale teď využíváme AWS Event Bridge a SQS queues, které slouží k pokrytí streamovacího use case. Datový tok funguje tak, že data přistanou v Event Bridge, potom jdou do nějaké queue, pak do Kinesis, následně Firehose a nakonec skončí na S3. Takže data ze streamu dostaneme zpět do našeho lake a pak je používáme v transformacích, případně plánujeme jejich další streamové využití.

Na začátku jsme zmínili Pipeline First přístup. Můžeš nám blíže popsat, co to znamená pro tebe a proč je to dobrá cesta?

Dívám se na to z pohledu snahy propojit data engineering se softwarovým engineeringem a aplikovat principy softwarového inženýrství do data engineeringu. Když jsem začínal, data engineering byl často o klikacích nástrojích bez možnosti verzování a review kódu. Myslím, že data engineering může od software engineeringu hodně získat, třeba verzování (git), review kódu, popisování pipeline v textové podobě, což umožňuje lepší správu a kontrolu.

Například v Good Data jsme měli nástroj na integraci dat, v Product Boardu jsme začínali s Kebulou, která však žádné takové možnosti neměla. Proto jsme integrovali Kebulu s Gitem. V Kebule máme produkční transformace, na které nesaháme přes UI, ale nasazujeme je jen přes Git. Máme standardní workflow – development branče, master branče, a když je změna na master, automaticky se nasadí do Kebuly.

Nemáme velké releasy, ale nasazujeme malé změny postupně, vždy s review a testem. Díky tomu dosahujeme kvalitní produkce bez větších problémů. A ve větší firmě, jako Tepejo City, je to ještě srozumitelnější – vše je infrastructure as code, všechny servery v AWS se nasazují přes kód – definujeme, jak mají být servery postavené, pipeline rovněž v kódu.

Máme v Tepejo City tři produkční a tři vývojová prostředí, takže nasadit změny znamená nasadit do pěti prostředí. Bez takového přístupu si neumím představit, jak bych spravoval například Cloud Connect plošinu – bez infrastruktury jako kódu by to jednoduše nešlo.

Zmiňoval jsi, že jsi velkým fanouškem DBT. Můžeš říct něco víc o této populární technologii? Předpokládám, že jsi fanouškem proto, že ti pomáhá v této filozofii.

Ano, DBT silně podporuje tuto filozofii. Moje první zkušenost byla před rokem a půl až dvěma, kdy jsme začali DBT nasazovat v Product Boardu a migrovali tam části transformací. Je důležité zmínit, že DBT samo o sobě nestačí – data je stále potřeba do databáze dostat. V praxi je to vždy kombinace DBT a dalších nástrojů.

DBT podporuje code first přístup – je to kód, kombinace SQL a Jinja templatingu z Pythonu, což je skvělé. Umožňuje modulární stavbu, definici vrstev, standardizaci. Pokud chcete aplikovat templaty na transformace dat – například pro inkrementální refresh, kde potřebujete znát primární klíč, datumy apod. – lze to v DBT definovat jednou a pak používat opakovaně. Díky tomu je menší šance na chyby.

Samozřejmě, když v kódu chybu najdete, může se porouchat vše, ale po opravě se to samo spraví, což je také výhoda.

Jak probíhaly konkrétní kroky v Product Boardu, když jste se rozhodli pro DBT? Stačí licence a jde se do toho?

Rozhodnutí bylo trochu širší. Dlouho jsme používali Kebulu, která má nevýhodu, že pokud chcete mít přímý přístup k datům pod Kebulou, není to jednoduché. Jediná možnost je vytvořit sandbox, do kterého nahrajete data a s nimi pak pracujete. Přímý přístup k datům mimo Kebulu není možný, což nás v některých ohledech limitovalo.

Zjistili jsme, že máme hodně opakovaného kódu v transformacích. Navíc jsme se rozhodli v Product Boardu modelovat datový sklad podle Datavolt 2.0, což je zajímavý a jednotný způsob, jak tvořit tabulky a celou architekturu, který lze velice dobře šablonovat.

Kebula však nepodporovala templaty, což nás omezovalo. Proto jsme přemýšleli, jak začít dělat věci jinak – buď napsat něco nad Kebulou, podobně jako jsme integrovali Git, nebo mít věci přímo ve vlastním Snowflakeu a nebýt tak limitování Kebulou.

Výhoda mít data v našem Snowflakeu spočívá také v tom, že můžeme nasadit nástroje pro kvalitativní dohled nad daty – například analyzovat výpadky nebo nekonzistence. Chtěli jsme tedy dostat data do našeho Snowflakeu, který dobře známe a můžeme jej efektivně spravovat.

Takže my jsme už ten vlastní Snowflake udržovali dlouho pod tím Lookerem. Včera, když jsme to dělali dříve, bylo to tak, že jsme všechno spočítali v Kebuli, pak jsme vzali finální tabulky a jednoduše jsme je vyexportovali do našeho Snowflaku. Nad tím Snowflakem pak byl náš Looker. Řekli jsme si tedy, pojďme to posunout trošku víc doleva, což znamená, že vyexportujeme data v téměř jeho formátu do vlastního Snowflaku a nyní na to aplikujeme dbt.

Toto rozhodnutí pro nás nebylo složité, protože jsme již měli část technologického stacku připraveného a pouze jsme ho v podstatě posunuli trochu na jednu stranu. Technologii jsme znali, tedy pro nás byla jediná novinka dbt, nikoli samotná databáze. Rozhodnutí tedy bylo relativně jednoduché.

Tým byl samozřejmě velmi nadšený, protože ta technologie, data engineering s dbt, je v podstatě oblíbená a hodně o ní lidé slyší. Technologie je pěkná, takže jsme se rozhodli do toho jít. Samotná migrace nám trvala asi půl roku nebo možná déle, než jsme vše postupně promigrovali, otestovali a tak dále. Byl za tím určitý náročný úkol pro tým, který však podle mě stál za to, protože práce s novým řešením byla výrazně jednodušší.

Velmi se mi líbilo, jak někdo z vás zmínil, že dbt razí přístup „pipeline first“. Když bych já byl pipeline, také bych preferoval „pipeline first approach“, obdobně jako je populární „America first“. Nyní sis říkal, že v Paylosity dbt nemáš, ačkoliv zásady a pravidla pro správný data engineering a datovou platformu jsou od začátku stejná. Jaké jsou tedy první věci, na které se díváš, když máš čerstvou zkušenost s Paylosity?

Děláš takzvané discovery, objevuješ on-prem databáze, sleduješ, jak ta data tečou, jaké jsou... Co hledáš? K čemu se mentálně ukotvuješ? Asi už se ukotvuji v tom, že to bude strašně moc práce, která potrvá roky. Ale je to hodně zajímavá práce.

Myslím, že principy data engineeringu jsou v posledních letech relativně dané a dá se říci, co by vaše pipeline měly mít, abychom je považovali za dobré. To se přes léta extrémně nemění. Co se mění, je tooling, který máme k dispozici. Dneska s toolingem, který máme, se pipeline dají dělat jednoduše i dobře. To je myslím důležitý poznatek.

Když se vrátím k otázce o Paylosity, tak vím, že někde na určité vrstvě budeme muset udělat unifikaci formátu dat. Mám na mysli, že máme zdroje dat – hlavní jsou SQL databáze – někdo používá Postgres, někdo MongoDB nebo něco jiného, to ale není klíčové.

V systému máme data uložená v různých systémech vytvořených před 25 lety i systémy vytvořenými před půl rokem. Každý systém má data uložená jinak a používá trochu jiné standardy. Vidím, že pokud toho hned na začátku nebudeme nějakým způsobem řešit, a data pustíme do dalších vrstev a transformací, bude každý tým, který ty transformace dělá, muset řešit unifikaci klíčů, datumů a dalších atributů.

Proto prosazuji vytvořit první vrstvu, kde provedeme základní úpravy a čištění dat hned na začátku. Toto platí pro velký rozsah Paylosity, ale myslím, že je to validní i pro startupy, kde je třeba získat dohromady jen dva zdroje dat.

Investice času do unifikace dat a základních čisticích funkcí – například přesun dat do UTC – se vyplatí. Osobně jsem už několikrát řešil problém s různými časovými zónami, letními časy a podobně a věřte mi, že to nechcete řešit, proto si data chcete unifikovat co nejdříve.

Existují krásné funkce, které data přesunou do správného času a s nimi dále můžete pracovat. Pokud chcete mít jinou časovou zónu, uděláte to úplně na konci, všechny nástroje to umí a je to super.

Takže toto teď musíme udělat, protože v systému to ještě není a budeme muset tu práci investovat, která ale není na začátku obrovská, a podle mé zkušenosti se to vyplatí. Myslím, že to je skvělé, protože jsi zmínil právě ten „pipeline first“ přístup.

V Paylosity je takový přístup nutností. Když máš tým 15 lidí, bez toho se neobejdeš. Jsou to praktické drobnosti, které lze aplikovat i v menším rozsahu.

Je ještě něco dalšího? Kdybych byl teď člověk začínající kariéru BI analytika či data inženýra, kdybych byl jediný, kdo připravuje pipeline, a vedle mě měl kolegu připravující reporty – kde bych se měl uchytit?

Nepůjdu rovnou stavět stack na dvacetinásobnou škálovatelnost, ale...

Myslím, že jedna z velmi důležitých věcí, která možná trochu naráží na můj modulární přístup, je vyhnout se špagetovému kódu.

Moje první zkušenost byla s tvorbou reportů pomocí stored procedur. Pamatuji si, že některé stored procedury měly 200 řádků. Abych změnil skutečně něco malého, musel jsem se dva dny studovat, abych si byl jistý, že změnou nezlomím něco dalšího.

Když člověk na začátku potřebuje dělat věci rychle, je tendence tvořit špagetový kód – jak ve software engineeringu, tak v data engineeringu. Je to hodně podobné.

Myslím, že se opravdu vyplatí přemýšlet o rozčlenění na menší části. Menší celky jsou totiž z dlouhodobého hlediska lépe spravovatelné. Když váš tým bude růst, je katastrofa, kdyby dva inženýři pracovali současně ve stejné dvoutisícové řádkové stored proceduře.

Sice existují nástroje jako git, které umožňují práce na stejném souboru, ale je to bolestivé řešit konflikty. Testování také trpí.

Pokud však kód rozdělíte do menších částí – například jeden kolega pracuje na sourcingu dat a druhý na transformacích – a máte mezi nimi jasný interface (on mi dodá toto, já čekám toto), můžete na tom pracovat paralelně.

Přemýšlení o rozdělení na malé části a skládání těchto částí za sebou je výborné. V softwarovém inženýrství jsem zažil aha moment, že kód se nepíše jednou, ale bude se refaktorovat a pravidelně upravovat.

Nestaví se web jednou a deset let pak běží, ale web a software neustále vyvíjíte, denně přicházejí nové změny – je to nikdy nekončící práce. Tento velký posun od Waterfall modelu k Agile představuje nutnost kód správně organizovat, protože do něj kontinuálně zasahujeme. V softwaru říkáme, že máme pořád hledat ty „šroubky“ – proto si na začátku definujeme, kam je uložíme.

Toto je určitý paradigm shift, který jsem viděl v softwaru a nyní ho vidím i v datech. Z jednorázových Waterfallových analýz se stávají dashboardy, produkty, které jsou automatizované a přetavené do reálných akcí.

Další zajímavá oblast je automatické testování, což je v softwarovém inženýrství standard, ale v data engineeringu stále není úplně běžné. Na začátku, když potřebujete rychle dodat něco byznysu, bych tam velkou testovací vrstvu nemontoval, protože to je náročné, nástroje nejsou ještě úplně vyspělé a lidé nejsou zvyklí.

Nicméně v momentě, kdy pipeline tvoříte modulárně, přijde čas, kdy se vyplatí začít psát testy – alespoň unit a integrační testy.

Proč? Když to prodávám juniornějším inženýrům, říkám, že testy přidávají vysokou míru jistoty.

Třeba u dvoutisícové stored procedury dobře pokryté testy znám všechny use cases. Když změníte něco a spustíte testy, víte na 95 %, že nic nerozbíjíte. To vytváří u vývojářů klidnou hlavu.

Bez testů je to stres – udělám změnu, otestuji ji, ale při nasazování se modlím, aby nic nepadlo. Modlit se je sice fajn, ale není to ideální.

Proto říkám, že modulární design usnadňuje psaní testů, protože menší části se testují lépe, stejně jako ve software engineeringu, kde jen malé funkce efektivně testujete.

Při budování datového produktu nebo pipeline uvažujete o tom, zda tam testy budou. Záleží na udržitelnosti, počtu lidí na projektu, zda se k tomu budete vracet nebo jestli jde jen o pilotní projekt.

Můj pohled je trochu jiný – beru to jako úroveň vyspělosti data engineering týmu a firmy. Tým postupně projde fázemi a když přijde rozhodnutí, že začneme psát testy, pak bych preferoval psát testy ke všemu, abychom si vybudovali tzv. „muscle“ – návyk a schopnost psát testy.

Psaní testů je totiž dovednost, kterou se člověk musí naučit – data engineer i software engineer. Na začátku to trvá déle, ale jakmile má člověk návyk a používá vhodné nástroje, zpomalí to vývoj jen minimálně.

Dovolím si být trochu „ďáblovým advokátem“ – data engineering se čím dál více blíží software engineeringu v principech a praxi. Když mluvíme o skillech správného data engineering specialisty, ten musí zvládnout i základy QA, skoro je to softwarový inženýr.

Bylo by dobré, kdyby chápal i business analytika nebo stranu, která s ním komunikuje. Naopak ve světě softwaru jsou dnes typicky specializace – DevOps, Continuous Integration běží automaticky a bez zásahu.

Není zvláštní, že zatímco softwaroví inženýři se čím dál víc specializují na frontend, backend a další, tak v datech potřebujeme „datové šampiony,“ tedy lidi, kteří umí zvládnout široký záběr? Je to dáno mladostí a rychlým vývojem oblasti. Ve startupu je full-stack inženýr často cennější než skupina specialistů.

Specializace se v datech samozřejmě děje. Když se dívám na práci v Product Boardu, moji data inženýři byli i data analytici a business analytici. S růstem týmu se specializovali.

U Paylosity jsou moji lidé primárně data inženýři, kteří nepřicházejí tolik do styku s byznysem, protože máme produktové manažery, kteří to řeší. Můžou se tedy více specializovat na kódování.

K testování: když něco vyvíjíme, testujeme to. Myslím, že málokdo má tolik ega, aby si myslel, že napoprvé napíše komplexní kód bez jakéhokoli testování.

Jde o naučit se dovednost přenést myšlení o testování do kódu, tedy napsat testy a integrovat je do vývoje.

Je to něco, co se člověk může naučit, má k tomu schopnosti, protože to vlastně už v podstatě dělá – jen se to musí naučit formálně pojmenovat a implementovat.

Tímto přepisem jsem upravil text do spisovné češtiny, zachoval 100 % obsahu, metody vyjádření, a mantinely dané zadáním. Pokud bude potřeba, rád text dále rozčlením či upravím.

Je to třeba se naučit. Ale myslím si, že v oblasti data engineeringu nejsou nástroje ještě tak dobré jako v software engineeringu. Nebo je možná problém trochu jiný, tudíž těžší na testování. Máme tam problémy s přípravou dat, což je vždycky dost pracné a únavné.

Takže problémy v oblasti data engineeringu ohledně testování existují a jsou poměrně komplexní. Musím přiznat, že jsem zatím neviděl ideální řešení, u kterého by se dalo říct: „To je úplně super a perfektní.“ Vždy tam nějaké problémy zůstávají.

Otázka je, jestli data engineeři nejsou naopak software engineeři, kteří se zatoulali směrem k datům. Protože popis jejich práce, pokud odmyslíme byznysovou část a pokud nechceme, aby data engineer rozuměl byznysovým dopadům dat, je v podstatě čistě software engineering.

Myslím si, že je to velmi zajímavý pohled. Když se podívám na svůj tým, jsou to v podstatě software engineeři, kteří přišli dodat řešení. Je to poměrně zajímavé, protože jsou to skvělí inženýři, ale nemají tolik zkušeností s data engineeringem.

Když jim zadám úlohu, například že potřebuji naintegrovat jednu tabulku do druhé, tak oni s tím nemají zkušenosti, nevědí, jak se to dělalo dříve nebo jak by se to dalo udělat. Ale zase mají zažité principy, třeba automaticky píší unit testy pro kód a přemýšlejí, jak psaní testů zjednodušit. Ví, jak vytvořit infrastrukturu přes kód a podobně.

Mají tedy spoustu zkušeností, které jsou velmi užitečné pro naši práci, ale co se týká data engineeringu a co to znamená transformovat data, jaké problémy tam jsou, třeba čištění dat, tak tam zatím zkušenosti většinou nemají.

Je zajímavé pozorovat, jak tito lidé pronikají do oblasti data engineeringu úplně stejně, jako jsem do ní já pronikal před jedenácti lety.

No a kdy jsi tedy převzal roli data engineera, když jsi byl dříve ruby developer? Je nějaký moment, kdy si říkáš: „Tyjo, už nejsem klasický vývojář, jsem data engineer?“ Myslím, že to bylo hlavně během práce v Product Boardu. Moje cesta byla na začátku data engineer, pak software engineer a zase data engineer.

V Gudatě jsem skutečně dělal pipeliney, což lze označit za data engineering. Pak jsem začal programovat kód, takže jsem se učil programovat. V Product Boardu jsem opět dělal data engineering, ale tam už jsem byl více manažer.

Adriáne, jsi nejlepší člověk na světě pro nás a jsme rádi, že tě máme. Stejně jako ve startupu, tak i v podcastech platí, že jeden engineer je fajn, ale lepší jsou dva backendy a dvě frontendy.

Je příjemné, že máš ty zkušenosti a pohled z více stran. Chtěl jsem se ještě zeptat na testování. Říkal jsi, že v data engineeringu jsou složitější nebo jiné problémy, na které nástroje nejsou úplně připravené. Jaký máš tedy svůj oblíbený stack? Co rád používáš, co naopak ne? Nebo to asi není úplně agnostické, protože všechno je stejně špatné?

Musím přiznat, že my si většinou budujeme vlastní řešení. DBT samo nabízí testovací strategii a pro někoho, kdo chce začít psát testy a používá DBT, je to podle mě skvělý postup a stojí za to se držet jeho rád.

Například v Playout City tvoříme prakticky vše ručně, přistupujeme k tomu jako k software engineeringu. Máme funkce, které provádějí transformace, píšeme to bez Sparků, pracujeme se vstupními a výstupními datovými rámci.

Základní test, který se snažíme používat všude, je, že vytvoříme testovací vstupní datový rámec a očekávaný výstupní rámec. To je základ, kdy můžeme modelovat různé use cases.

Například když je transformace pět joinů, co se stane, když v datech některá tabulka či klíč zmizí nebo se změní? S těmito use cases si hrajeme, ale je to stále relativně pracné.

Dříve či později budeme muset buď vyvinout vlastní nástroje, nebo se poohlédnout po dostupných řešeních na trhu. Přiznávám, že poslední dobou jsem v tomto směru nedělal průzkum, takže nevím, co je nového.

Co se týče pipeline, co používáš jako první, co otevíráš, čím začínáš stavět? Jsou dnes v Playout City nebo co jsi vytvořil v Product Boardu nějaké charakteristické rysy?

Myslím si, že stack je spíše otázkou úkolů, které je potřeba udělat. Playout City je obrovská firma a náš stack není na začátečníka příliš vhodný.

Pokud chceš správně dělat pipeline a chápeš důležitost, tak máš nějaký checklist, který nezáleží na tom, zda používáš DBT nebo něco jiného, ale říká: „Testuju.“

Řekl jsi, že testování souvisí s maturitou týmu. Jak vnímáš jednotlivé fáze této maturity? Když začínám s testováním, do čeho bych se měl pustit jako první, abych postavil dobrý základ?

Myslím, že jsme to trochu načali. Má smysl co nejdříve standardizovat a čistit data. Začal bych s několika funkcemi, které budu aplikovat různě na data, která přijímám.

V jakém nástroji? Mám rád ELT přístup, tedy nahrát data co nejdříve do databáze a pak na nich aplikovat transformace v databázi.

Tooling, který kolem toho Honza postavil, je robustní a obsahuje spoustu věcí, které pomohou i v budoucnu a usnadní i tento proces.

Takže můj doporučený postup je dostat data do databáze, vytvořit základní vrstvy, mezi kterými data přeshopuju, a pak začít transformovat.

Na co se při tom díváš? Děláš transformace, sleduješ datovou kvalitu a vztahy jednotlivých zdrojů.

To je prakticky práce data engineera. Některé přístupy ti umožní nahrát data do databáze a začít se na ně dívat.

Musíš zhodnotit kvalitu dat, protože pokud ze zdrojového systému dostaneš „brutální garbage“, nic pěkného nad tím nepostavíš.

Někdy se stane, že zdrojová data jsou velmi špatná, a je třeba říct: „Tady z těchto dat nic nepostavíme.“

Pak je potřeba strávit čas jejich opravou nebo spravováním, protože jsou nekvalitní.

Říká smysl jít k týmu, který data vlastní, a říct: „Nepracujeme s tím, pokud neupravíte tyto věci, aby data byla rozumná.“

Je lepší otevřeně říct, že nemůžete data použít, než slíbit byznysu dodání a později je muset odmítnout kvůli nekvalitě.

Proto je dobré si data vzít k sobě, udělat sanity check, zjistit, jestli vypadají rozumně, zda obsahují potřebné informace, a na tom stavět dále pipeline.

Záleží samozřejmě na konkrétním use case, nelze přímo říct, co přesně kontrolovat v datasetu.

Jde spíše o to podívat se na data, zhodnotit je a provést pattern recognition – to je trochu otázka zkušeností.

Líbilo se mi, jak jsi mluvil o datech jako o standardu, na kterém pracuješ dlouho a nakonec zjistíš, že problém je v jedné chybné hodnotě ve sloupci.

Můžeš doporučit ještě pár věcí, které by mohly posluchačům ušetřit týden nebo dva práce?

Myslím, že je dobré na začátku definovat naming standard pro všechno, co vytváříte.

Není to sice přímo o datech, ale o schématech. Pokud si řeknete, že zdrojové tabulky budeme pojmenovávat tímto způsobem, stagingové tabulky jinak, primární klíče jinak a reference zase jinak, vytvoříte si standardní kulturu.

Třeba jestli budete používat všude lower case názvy, tak je používejte všude, čímž si hodně pomůžete.

Ve firmě Datavolt jsou standardy nádherně definované v dokumentaci i v knize.

Člověk ví, co je v jaké tabulce, jaká metadata jsou v každé tabulce, co je primární klíč, který sloupec značí datum aktualizace.

Je to krásně unifikované, člověk nemusí přemýšlet, co sloupec znamená, když data čte, což ušetří spoustu času.

Podle mě není vůbec těžké si na začátku definovat tyto standardy – řeknete si, že budete dělat pár věcí a přísně se jich držíte, a je to.

A týká se to hodně pozdější fáze projektu a týmu.

Kde ve vašem týmu dnes tyto standardy držíte? Kde je mají lidé k dispozici v Product Boardu nebo jinde jako know-how a dokumentační zdroj?

To je zajímavé. Já jsem zastánce, že standardy se mají vynucovat a kontrolovat.

My jsme je dali do linteru, takže při kontinuální integraci kontrolujeme kvalitu kódu a jestli standardy jsou dodržovány.

Pokud někdo standardy poruší, nepustíme kód dál.

Lidé si na to rychle zvyknou, takže je to v pohodě.

Samozřejmě je dobré mít standardy i někde napsané třeba ve Wikipedii nebo Notion, ale pro mě je důležité, aby dokumentace byla blízko kódu.

Jsem odpůrce vytváření rozsáhlých dokumentačních stránek, protože rychle zastarávají, nikdo je nečte a jsou na obtíž.

Čím blíže kódu a čím víc jsou standardy ověřovány v nástrojích nebo linterech, tím to týmu více pomůže a vyplatí se to.

Hezky jsi to shrnul. Někteří říkají, že každá dokumentace je už prohranou bitvou.

S tím souhlasím.

Myslím, že jsme pro posluchače připravili spoustu konkrétních tipů, které mohou rovnou začít používat.

Je ještě něco, co jsme nezmínili a co by tě mrzelo, že pro posluchače nezaznělo? Nějaká věc, na kterou teď přemýšlíš?

Jo, je tu jedna věc z mé manažerské zkušenosti ohledně vedení lidí a ega.

Přečetl jsem dobrý citát: „Když je ego jediná věc, která vám brání něco udělat, měli byste ego stranou a prostě to udělat.“

Spojuji si to s přijímáním zpětné vazby.

Lidé velmi rychle rostou, pokud jsou otevření feedbacku a radám od zkušenějších.

Naopak ti, kdo mají větší ego a berou feedback jako osobní útok, rostou velmi pomalu.

Také zkušenost říká, že málokdo ti dává zpětnou vazbu s úmyslem ti ublížit.

Spíše se dívají na kód a říkají: „Myslím, že by to šlo udělat lépe, proč to tady není jinak?“

Pokud to ale vyhodnotíš jako: „Ten kód je špatný, musí se přepsat,“ je to špatný přístup.

Lepší je říct: „Proč si myslíš, že je tvůj přístup lepší?“

A oni ti řeknou třeba, že před rokem psali podobný program a použili při tom knihovnu, která jim práci usnadnila.

Člověk pak může získat cenné tipy a zlepšit kvalitu kódu.

Tím končí přepis původního textu do spisovné češtiny se zachováním 100 % obsahu a významu.

To je zajímavá knihovna, proč bych si na ni nepodíval a proč bych ji příště celou nepoužil? A něco se člověk naučil, udělalo ho to efektivnějším a posunulo ho to daleko. Takže já si myslím, že je to hodně pro juniory nebo středně pokročilé lidi, kteří jsou občas na takovém vrcholu a myslí si, že všechno ví nejlépe.

Pak jsou zajímavější senioři, kteří si řeknou: „Já vím hodně věcí, ale taky vím, že strašně moc věcí nevím.“ Takže já si takové lidi rád poslechnu, popřemýšlím nad tím a zkusím si to nějak zakategorizovat.

Co bych tady ještě dodal, je, že není to o tom, že mi někdo něco řekne a já to hned udělám. Spíš jde o to, co chce tím člověk říct. Když mi někdo něco řekne, předtím, než zareaguji, si tu věc trochu v hlavě otočím, promyslím ji a řeknu si: „Hele jo, to mi dává smysl,“ nebo „to mi nedává smysl,“ a v pohodě.

Ale někdy je první reakce lidí obranná a to podle mě není třeba, protože vždycky všichni rosteme společně a když máme v týmu dobré prostředí pro výměnu názorů, pracují všichni efektivněji, cítí se lépe a celý tým funguje lépe.

To je podle mě moc hezká tečka našeho jinak velmi praktického a za to ti moc děkuji, i velmi odborného povídání.

Co tě osobně a tím pádem Payload City Data Engineering Team v nejbližší době čeká?

Čeká nás spousta věcí. Máme před sebou hromadu práce. Potřebujeme vybudovat další pipeline, zlepšit podporu streamingu. Je tam spousta úkolů, na kterých budeme pracovat. Vše bude souviset s AWS a bude to výhradně přístupem software engineeringu. Takže nás čeká hodně práce.

A tady si dovolím malou vsuvku: aktuálně máme volné místo pro senior data inženýra. Pokud vás něco z toho, co jsem dnes říkal, zaujalo a lákalo by vás pracovat nad AWS, se Sparkem, ve firmě, která má mnoho dat a spoustu práce před sebou, klidně mi dejte vědět a můžeme si popovídat.

Po tomto povídání mám chuť se to naučit.

Moc děkujeme, držíme palce a doporučujeme zde pana manažera Adriana. Určitě ne naposledy, vždy tě tady rádi uvidíme. Děkuji moc.

Moc děkuji, Adriane, bylo to moc fajn.

Taky děkuji za pozvání.

A to je vše. Děkujeme, že jste doposlouchali další díl Datatolku. Děkujeme také našim partnerům: BigHubu, VipNoutu, Mantě, Natinu a Takamě, GeneBeamu, Seznamu.cz a Mius.

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

Nechť vás provází data.