Podcast

Dobrý den, moje jméno je Jirka Vicherek.
Ahoj, tady Karel Šmánek.
A vítáme vás u dalšího dílu DataTalku.

Jirko, koho tu dneska máme?
Naším dnešním vzácným hostem je Petr Nemet, zakladatel startupu Datadoo.
Ahoj, Petře.
Ahoj, těší mě.

Petře, Datadoo je český datový startup, velmi úspěšný. Co vlastně děláte?
Pro ty z vás, kteří o vás ještě nečetli na Forbesu nebo Crunchbase, co vlastně Datadoo dělá? Jak jste velcí a tak dále?

Tak v první řadě moc děkuji za pozvání, vážím si toho. Datadoo je – asi to nebude znít moc sexy – ale je to datově integrační platforma, která se zaměřuje na business uživatele. Když to přeložím do lidské řeči, Datadoo propojuje data z různých systémů, nějakým způsobem je čistí, normalizuje a pak je doručuje do cílových systémů, kde se s těmi daty pracuje.

Hodně používané buzzwordy nebo průmyslové termíny jsou ETL, což znamená pohyb dat z těch systémů, kde data vznikají, do systémů, kde se s nimi pracuje, ať už je to datový sklad nebo nějaký dashboardingový nástroj. Pak samozřejmě děláme i reverse ETL, což je opačný směr – vy máte data ve vašem datovém skladu a potřebujete je zpět dostat do různých byznysových aplikací. Typicky máte například seznam zákazníků ve vašem datovém skladu, máte tam nějaký scoringový model a ta data potřebujete dostat do vašeho CRM. Na to lze použít reverse ETL funkce v našem Datadoo.

Takovýto nástrojů tady známe docela hodně. Můžeš nám říct, v čem jste vlastně specifickí, v čem se lišíte od ostatních? Taková trapná otázka, že jo?
Jasně. Určitě ten trh datových služeb a datových integrací se hodně komplikuje a fragmentuje. Naše zásadní propozice je, že jsme no-code nástroj, což znamená, že se orientujeme na uživatele, kteří nutně nemusí být techničtí a nemusí mít znalosti SQL, Python programování a podobně. Samozřejmě je třeba mít alespoň nějakou základní představu o databázích a práci s datovými modely.

Druhá věc, která Datadoo odlišuje, je, že se čistě zaměřujeme na problematiku transportu dat, což je klíčová funkcionalita našeho produktu. Snažíme se do toho vkládat funkcionality na úrovni datové kvality, vyřešení compliance a bezpečnostních otázek, aby zákazník měl jistotu, že data, se kterými pracuje, jsou doručována v odpovídající kvalitě, ve správný čas a na správné místo, kde je uživatel potřebuje.

A v neposlední řadě máme obrovské portfolio konektorů, což jsou komponenty, které umožňují no-code připojení – dnes máme přibližně 250 zdrojových systémů a zhruba 50 cílových systémů, kam lze data doručovat. Tak vypadá Datadoo dneska. Ale ty jsi to zakládal v roce 2018. Jakou vizí jste to zakládali? Jak ses k tomu dostal? Jaká je tvoje historie před Datadoo?

Já jsem se vždycky pohyboval okolo dat na úrovni backendových věcí, infrastruktury. Moje první práce byla čistě developerská v Manchesteru v Anglii, kde jsem pracoval pro firmu, která byla klasickou internetovou programátorskou agenturou, dělali jsme různé e-commerce projekty, webové stránky a podobně.

Majitel firmy byl velký filantrop a spolupracoval s lokálními charitami. Projekt, na kterém jsem pracoval, se jmenoval Rent a Balloon Race. V Anglii jsou balónkové závody poměrně oblíbený způsob, jak získávat peníze pro charity. Typicky charita uspořádá balónkový závod, prodá balónky za pět liber, lidé je vypustí a balónek, který doletí nejdále, získá cenu. Nejednalo se o horkovzdušné balóny, ale o malé nafukovací balónky. Toto je oblíbený způsob fundraisingu.

Samozřejmě to má i ekologické dopady – balónky jsou plastové, znečišťují životní prostředí, mohou zabít ptáky a podobně. Projekt Rent a Balloon Race byl virtuální balonkový závod. Charita si pronajala infrastrukturu, systém sbíral data z meteostanic, získával informace o místním počasí a podmínkách. Charita si mohla vybrat, zda závod proběhne v Paříži, Praze, Londýně, Edinburghu a tak dále.

Uživatel si vybral balónek, jeho tvar, čím ho naplní, kolik helia dá, jaká bude guma, kolik bude balónek vážit. Pak se závod odstartoval, ballónky se vypustily a probíhal výpočet letu v reálném čase podle lokálního počasí. Závod mohl trvat týden, byly tam pravděpodobnostní modely pravděpodobnosti prasknutí balónku podle parametrů.

Zní to jako velmi sofistikovaná práce na relativně jednoduchém projektu. Bylo to kolem roku 2010. V té době jsem se dostal k MongoDB, což bylo prvotní propojení na data. Řešili jsme, do jaké databáze data ukládat, jak je rychle zpracovávat a vizualizovat v reálném čase. To byl můj první kontakt se sofistikovanějšími datovými technologiemi.

Pak jsem se vrátil do Čech, vstoupil do mediální skupiny, která byla v té době jedním z mála datových jobů u nás. Tehdy se titulovalo „web/data analytik“, BI nebylo ještě nijak moc používané. Pamatuji si datové setkání analytiků někde na Smíchově v hospodě ve sklepě, kde bylo asi dvacet lidí – tedy úzká komunita.

Následně jsem přešel do Českých Radiokomunikací, kde jsem měl na starosti architekturu IoT platformy, která pracovala s technologií LoRaWAN. Ta technologie slouží k přenosu dat z low power zařízení na velké vzdálenosti. Měl jsem za úkol navrhnout platformu, která dokáže zpracovávat data ve velkém objemu s vysokým paralelismem a distribuovat je.

V té době jsem začal postupně pracovat na Datadoo po nocích a víkendech. V každé práci jsem řešil nějakým způsobem datovou integraci a přenos dat, a tak jsem viděl, že by to mohl být zajímavý vlastní byznys. V roce 2018 jsem skončil v Radiokomunikacích a založil Datadoo.

Co jsi tedy po nocích a víkendech napsal? Jak vypadalo MVP Datadoo z roku 2018?
MVP byl nástroj, který dokázal vzít výstup z libovolného API a transformovat ho do tabulky, která se mohla poslat dál do nějaké destinace. V té době bylo přibližně 20 konektorů – polovina byla marketingové nástroje jako Google Analytics, Facebook atd., druhá půlka CRM a business nástroje.

Destinace, které jsme podporovali, byly BigQuery, FTP (export dat ve formátu CSV nebo JSON na FTP) a také Google Data Studio (dříve jen Data Studio).

Jak to vypadalo, když jsi do toho skočil? Už jsi měl funding, nebo jsi prostě dal výpověď a začal pracovat?
Pracoval jsem na Datadoo stále, zatímco jsem měl zaměstnání – bylo to spíše jako vedlejší projekt o víkendech a večerech. Výhodou bylo, že už jsme začali získávat první zákazníky a uživatele. Když jsem dal výpověď, nebyl to skok do hluboké vody, protože už jsem věděl, že máme nějakou trakci a že by to mohlo fungovat.

Už to tedy alespoň vydělávalo na rohlíky?
Jo, už na rohlíky to vydělávalo.

Chtěl bych se zeptat na jednu věc. Slyšel jsem jméno Datadoo, ale proč tam máte dvě „D“ na konci? Protože by se to čítalo jako DataDdoo?
To je častá otázka. Když nám nastoupil první marketér, chtěl z těch dvou „E“ na konci udělat dvě „O“, protože ta dvě „E“ mu nedávala smysl. Ale název vznikl jako spojení slov „data“ a „ado“ – „ado“ znamená spojovat. Je to portmanteau – spojení slov. Snažíme se to i zákazníkům vysvětlovat, hodně se nás na to ptají. I tak se ale pořád setkáváme s tím, že někdo píše Datadoo s dvěma „O“ na konci místo s dvěma „D“.

Tak co je Datadoo dnes? Kolik vás je, jaké máte klienty a jaké use-casy řešíte?
Dnes nás je 48, tedy téměř 50 lidí. Začínali jsme ve třech a vyrostli jsme během dvou a půl let. Poslední dva roky byly hodně náročné z hlediska budování firmy a celé organizace.

Základní koncept zůstal stejný – pokračujeme v úzkém segmentu datového transportu, což je produktová kategorie, kterou chceme dál rozvíjet. Velmi narostl počet konektorů i počet destinací.

Došlo také k mnoha změnám v infrastruktuře – provozujeme platformu na Kubernetes, což umožňuje autoskalování. Uživatelské rozhraní prošlo velkými změnami a přidáváme různé funkce.

Myslíme si například, že některé workflowy, které dnes probíhají v Data Warehouse, například kolem datové kvality nebo čištění dat, lze vyřešit už na úrovni transportu dat. Tedy aby uživatel nemusel řešit export z Data Warehouse, ale část práce vyřešil už při extrakci, ještě před doručením dat do Data Warehouse.

Typickými klienty jsou pořád byznysové týmy. Když říkáš, že jste no-code, cílíte primárně na business uživatele?

Dnes je to tak, že zhruba 80 % klientů jsou byznysové nebo datově byznysové týmy. Hodně řešíme marketingové use-casy, salesové use-casy, často CRM, hodně finance – tedy integrace platebních systémů, fakturačních systémů, ERP.

Nové zajímavé use-casy jsou migrace a replikace databází. Například máte nějakou databázi v Postgresu nebo MySQL, kterou chcete částečně uvolnit analytikům pro přístup, takže je replikujete do BigQuery nebo Snowflaku.

A pak je tu reverse ETL, které nahrazuje legacy kód, který firmy měly na interní integraci s CRM nebo jinými systémy. To jsou pro nás nové případy použití, které řešíme.

Zmiňoval jsi, že primární klienti jsou business uživatelé. Jak je to s typem klientů? Máte nějaké zajímavé? Viděl jsem nějaký případ s docela známou značkou, třeba Uber. Můžeš být konkrétnější?

Uber byl jeden z našich prvních klientů, kteří se chytili na MVP, které jsme nabízeli. Oni si nás našli sami. Když jsme spustili první verzi Datadoo, zvolili jsme product-led growth model – měli jsme web, 14denní trial a maximálně self-serve.

Pamatuji si páteční odpoledne v našem malém kanceláři v Monty News s kolegou Joelem, spoluzakladatelem. Měli jsme otevřené pivo, když nám přes Slack přišla notifikace, že se někdo s doménou uber.com přihlásil do Datadoo.

Samozřejmě první, co jsme udělali, bylo, že jsme jim napsali a nabídli pomoc, a vznikl z toho velmi pěkný případ. V té době jsme pracovali s Uber Eats, což byla podobná služba jako tady Volt nebo Dáme jídlo.

Uber tehdy hodně expandoval na různých trzích v Evropě i Jižní Americe. Ten případ byl hodně marketingový a salesový. Měli mnoho různých reklamních systémů a sociálních sítí, které potřebovali napojit a získat všechna data na jedno místo.

Je zajímavé, že i technologicky takové firmy, jako je Uber, najdou nějaká hluchá místa. Vidíme to skoro u všech našich klientů, že marketing a byznys jsou určité skupiny uživatelů a my často pracujeme bottom-up.

Stalo se vám jinde, že si vás users ve firmách sami našli a vy pak uzavřeli enterprise deal?
Ano, dá se říct, že to je naše dlouhodobá strategie. Pracujeme vždy bottom-up. Například tak jsme získali také LG. Jeden datový analytik v Koreji nás objevil a postupně to přerostlo v poměrně velký a zajímavý projekt.

Snažíme se tedy začínat na úrovni business uživatelů a postupně přes různé prodejní a marketingové cesty dostat produkt dále do firmy a přiblížit se jejich konkrétním core problémům.

To znamená začínáme čistě salesovými a marketingovými audií... [text končí]

Přepis do spisovné češtiny:

V zásadě se to posouvá dál směrem k věcem, jako je integrace klíčových byznysových systémů, například CRM, ERP a podobně. Říkáš, že je to aktuálně nějaký korduální problém, co je podle tebe takovým základním problémem pro většinu firem?

Pro mě… Ne, co mi přijde opravdu zajímavé – omlouvám se, že ti do toho vstupuji – je, že podobně jako u DBT mě překvapila vaše trakce a úspěch v tomhle velmi zapleveleném trhu enterprise stacku. Máte v podstatě něco opravdu jednoduchého, lehkého, co je jazyku pro uživatele bez programování, tedy no-code, a máte s tím úspěch.

Je to tím, že máte dobře definovaný problém, který řešíte, anebo je to tím, že ostatní firmy střílejí na všechny strany a nevidí, jaká je hodnota v té jedné transformační vrstvě?

To je dobrá otázka. Myslím si, že pro nás bylo klíčové produktové rozhodnutí to, že budeme řešit pouze transport dat, tedy ETL a reverse ETL, plus samozřejmě nějaké související věci, ale nebudeme se věnovat ničemu jinému. Nechceme zabíhat do vizualizací, analytiky, orchestrací a podobných oblastí. Toto nám dává možnost se velmi silně zaměřit na jednu konkrétní oblast, o které víme, že je extrémně komplexní, a to už jen z hlediska množství systémů, které je potřeba propojit.

Když se podíváme na samotný trh, většina datových firem vyrostla v oblasti marketingu a prodeje (sales). Důvod je ten, že právě tyto oblasti se velmi rychle digitalizovaly a zároveň jde o byznysové domény, kde systémy a lidé jsou zvyklí pracovat s daty. Proto je prodat tamno-code prodejní řešení poměrně snadné, protože bariéry vstupu jsou nejnižší.

Náš předpoklad je, že postupně se tento přístup dostane i do dalších byznysových domén. Vidíme například, že nám rostou požadavky na integraci nových systémů v oblasti financí nebo HR. Samozřejmě tam jsou jiné požadavky na bezpečnost a compliance, ale věřím, že jde o postupný proces digitalizace firem a ne o to, že by marketingoví nebo prodejní specialisté byli v tomto něčím speciální.

Obecně je téma datové integrace problematické i pro technologické týmy, jelikož je ten svět velmi heterogenní. Dokážete si představit nějaký core data tým, který má svůj vlastní data warehouse. Máte zkušenost nebo jim dokážete pomoci?

To, čím se zabýváme na úrovni data warehousu, je transport dat do něj a z něj. Snažíme se všechno, co souvisí s přenosem dat, maximálně zjednodušit pro uživatele. Aby neztrácel čas nad rutinními operacemi. Reálně to znamená, když si třeba u nás nastavíte datovou trubku, například chcete vytáhnout data ze Salesforce do BigQuery, my to řešíme až na úrovni automatického vytváření tabulek a definování datových typů v cílovém systému. Normalizujeme datumy, přemapujeme špatné datové typy (například float uložený jako string) do správných typů.

Tím pádem uživatel data warehouse nebo analytik nemusí řešit čištění dat ani datovou normalizaci. Jeho práce by měla spočívat hlavně ve vytváření složitých joinů nebo jiných analytických dotazů.

Pokud jde o technologické týmy, ti jsou obvykle pokročilejší a mohou chtít do workflow přidat prvky data operací nebo další automatizace. Máte pro ně nějaká řešení?

Pro pokročilejší uživatele, například datové analytiky, nabízíme podporu na úrovni data operations případně data lineage, kterou řešíme formou partnerství a interoperability. My definujeme rozhraní (interface), kde končí naše zodpovědnost při dodání dat do data warehouse.

To znamená, zaručujeme kvalitu a načasování dat, ale jak je používají dál, už je na zákazníkovi. Pokud chtějí řešit sofistikované datové transformace, doporučujeme nástroje jako DBT.

Máme partnerství s firmou Kolibra, která řeší data lineage, takže pokud má datový tým složitější datový stack, chceme být jeho funkční součástí, ale neintegrovanou plošně do všech procesů, které nejsou v našem hlavním workflow – tedy v transportu dat.

Máš zkušenosti od klientů, jak reagují BI týmy, když marketingová, byznysová nebo sales oddělení si pořídí vlastní datová řešení? Vede se vám často debata, že mají dlouhé termíny, a proto si našli vlastní nástroje?

My propagujeme tzv. hub and spoke model správy dat, což je v data managementu poměrně běžný přístup a ideální model organizace datových týmů u našich klientů.

V rámci tohoto modelu existuje centralizovaný datový tým, který řeší architekturu, výběr nástrojů, compliance, data warehouse a podobně. Data operace jsou ale řízené jednotlivými byznysovými týmy, například marketingem, sales, financemi.

Tyto byznysové týmy mají tzv. citizen data scientisty nebo citizen data engineery, kteří fungují jako spojka mezi centrálním datovým týmem a lidskými týmy v byznysu.

Tento model se nám jeví jako ideální, protože právě tehdy, když zákazník má data warehouse a tím pádem investuje i do lidí, kteří se o něj starají, začíná pro nás být spolupráce výhodná.

I když máme zákazníky, kteří pracují jen s Google Sheets a vytvářejí tam vizualizace či mají propojení přímo do Tableau nebo Power BI, považujeme to spíš za marketingovou vstupní bránu.

Pro nás je zásadní, zda zákazník má data warehouse, protože to ukazuje závazek k práci s daty na finanční i personální úrovni.

Zmínil jsi, že většinu funkcionalit, které bývají na úrovni enterprise řešení, outsourcujete partnerům nebo přenecháváte cílovým a zdrojovým systémům. Říkal jsi, že se ale věnujete datové kvalitě. Proč? A je to skutečně ETL nebo ELT, protože u datové kvality se často říká, že je potřeba mít přístup ke zdrojovým datům?

My tomu říkáme ETLT, což je náš přístup. Já často uvádím za příklad Fivetran, kterého považujeme za našeho největšího konkurenta. Ten přístup je takový, že data z exportu ze zdrojového systému doručí do data warehouse většinou velmi surově.

Pak se očekává, že se budou nad tím provádět poměrně náročné transformace, například v DBT, kde se data čistí, normalizují a podobně.

Tento koncept je pro dodavatele data warehousingových řešení výhodný, protože zákazník platí nejdříve za přenos dat do Snowflake nebo jiného data warehouse, pak za storage, compute, a ještě za zpracování dat v DBT. V důsledku může být moderní datový stack poměrně drahý.

My se vůči tomuto přístupu vymezujeme v tom, že spousta dat, která se dnes přenáší, je duplicitních, části jsou zbytečné a zákazník za ně vlastně platí.

Platba za storage a compute způsobuje, že když máte v databázi víc řádků nebo sloupců, než je potřeba, query trvá déle a vy platíte víc.

Náš koncept je proto přesunout většinu čištění, normalizace a práce s kvalitou dat už na úroveň extrakce. Typicky jde například o bezpečnostní a compliance otázky.

Například pokud se napojíte na systém, který produkuje data o mzdách, dnes musíte data po exportu do warehouse opatřit maskováním, aby k nim neměli přístup všichni analytici.

My tuto věc řešíme už na úrovni extrakce, kde si zákazník může definovat, že určitá data jsou citlivá a vyloučit je z transportu, aby vůbec nešla do data warehouse.

Zároveň se snažíme, aby data, která do data warehouse doručujeme, byla maximálně připravená k analytickému použití – jsou znormalizovaná, mají správné datové typy a po této úpravě jsou analytické dotazy co nejjednodušší.

Což samozřejmě zároveň znamená, že je pro zákazníka levnější je provozovat.

Pokud jde o datovou kvalitu, nemáme ambici být plnohodnotný nástroj pro její řešení, ale věříme, že mnoho problémů lze vyřešit už na úrovni extrakce.

Typicky například řešíme duplicitní data, máme engine na detekci anomálií.

Jsme schopni rozpoznat na toku dat, že došlo k anomálii v datech, a zákazníka na to upozornit.

Je také možné nastavit pravidla, že pokud se objeví například více než 20 % nulových nebo anomálních hodnot ve sloupci, celá downstream operace je zablokovaná, aby nedocházelo k dalším škodám.

Pokud zákazník chce sofistikované řešení datové kvality, my s těmito konzultanty nesoupeříme, ale tvrdíme, že základní problém už umíme řešit na úrovni extrakce.

Jak to máte s řešením složitějších problémů, například s čistěním adresních dat, která bývají velmi neuspořádaná?

My řešíme opravdu jen základní věci. Jako první filtr.

Představte si dvě nádoby. V první je hodně znečištěná špinavá voda.

My jsme něco jako kávový filtr, který odstraní velké nečistoty, ale bakterie už z vody nevyloučí.

Ty pevné částice ale odstraníme a pro mnoho firem nebo use case to je dostačující.

Obzvlášť pokud na druhé straně nemají kompetence na specializované nástroje pro data quality, ale chtějí mít alespoň základní očistu dat.

Zajímala mě ještě jedna věc – kdo dělá tu práci s reorganizací dat do kanonického nebo normalizovaného modelu? Máte na to něco poloautomatizovaného, nebo to dělají uživatelé?

Dnes to funguje tak, že vytváříme tzv. konektory – komponenty, které vezmou značnou většinu libovolných API výstupů a nějakým způsobem je znormalizují do dvourozměrných tabulek, se kterými se dá dál pracovat.

Tuto věc vyvíjíme a udržujeme interně.

My držíme údržbu nad každým API, na které se připojujeme.

Máme interní engine, který stáhne zdrojové API, vygeneruje základní transformační pipeline.

Jde o naše vlastní technologie, která dovoluje vzít libovolný API výstup – ať už JSON, XML nebo CSV – a dostat ho do použitelné podoby.

Pak s tím pracujeme dál.

Tuto pipeline vytvoří automat, ale samozřejmě lidský zásah je potřeba, aby data dočistil, doplnil o metadata a podobně.

Takto vznikají konektory.

Jednou z velkých výhod, kterou zákazníkům poskytujeme, je fakt, že se nemusí sami starat o údržbu těchto konektorů a veškerých změn v API.

Tímto způsobem zajišťujeme kvalitní a stabilní napojení na datové zdroje s minimálním úsilím pro naše uživatele.

Konec přepisu.

Je to tak, že my dneska o sobě tvrdíme, a minimálně ve srovnání s naším konkurentem to skutečně platí, že máme nejrychlejší tzv. Time to Connector, tedy dobu, během které jsme schopni garantovat zákazníkům i v rámci smluv vytvoření nového konektoru zhruba do deseti pracovních dnů.

To znamená, když za námi někdo přijde a řekne, že chce například deset let starý SAP, tam to zrovna těch deset pracovních dnů asi nebude. Ale máme konektor na SAP a samozřejmě pak jsou systémy, které jsou jednodušší, a jiné složitější, ale střední doba je zhruba kolem deseti pracovních dnů.

Samozřejmě rekord máme asi kolem 15 minut, když jsme byli schopni vytvořit konektor během 15 minut. Když se to protahuje, tak to většinou způsobují nějaká byrokraticko-administrativní opatření, například bezpečnostní audity, udělení přístupu a podobné věci.

Ještě mám rychlý dotaz. Ty jsi vlastně říkal, že jsi pracoval pro české radiokomunikace, kde se dělá IoT, a mnoho věcí, které jsi dělal dřív, jsi se snažil zakomponovat do svého produktu. Má to vliv vlastně i na real-time? A případně mě ještě zajímá CICD.

Ano, super, skvělá témata. Naše vize je dnes taková, že zákazník si u nás zvolí zdroj, zvolí si destinaci, a platforma sama vyřeší, jaká je na to optimální architektura přenosu dat.

Samozřejmě, MBP bylo na čistý batch. Prostě tam běžel nějaký cron, který se v určitou dobu zavolal, vytáhl API call, transformoval to do databázové tabulky a někam to přenesl a zapsal.

Časem jsme přidali primárně pro spojení mezi databázemi streaming, což znamená klasické streamované spojení. Když potřebujete přesně replikovat databázi, naše platforma podle objemu určí optimální přenos.

Například pokud máte relativně málo řádků, záleží na technologii, třeba MySQL databázi s tisíci řádků, a zdrojem máte BigQuery, tak pro takový objem je optimální batchový insert, pokud nepotřebujete real-time.

Pro větší objem používáme load file, tedy v řádu milionů řádků – data se vytáhnou, uloží do souboru, pak se přes cloud storage nahrají a následně se importují.

Pro opravdu velké objemy v řádu desítek milionů řádků až terabajtů se automaticky nastaví streamované spojení, které přenáší data řádek po řádku.

Dále podporujeme i něco, čemu se poměrně ošklivě říká webhooky – systém vystaví event, ten musí být zachycen a přeposlán dále.

Tento způsob souvisí do určité míry s prolínáním mezi námi a klasickými iPaaS platformami, jako jsou Zapier či Make, pro určité workloady.

Poskytujeme všechny dnes nejvíce používané typy datových přenosů.

A k tomu CDC – jenom když to namátkou zmíním…

CICD jsi myslel?

Ano, CICD – Continuous Integration, Continuous Deployment.

Ne, já to řekl špatně, chtěl jsem říct CDC.

Čiže Change Data Capture.

Přesně tak.

Už je pátek, tak si to zaměním.

Takže kluci, tohle je pro nás velké téma. CDC podporujeme, záleží na technologii a na zdrojové a cílové databázi.

Obecně u zdrojových databází se snažíme u většiny systémů, kam doručujeme data, podporovat klasické insert, upsert, truncate insert, insert ignore a dokonce i delete.

To znamená, že když se v té zdrojové tabulce změní nějaká data, jsme schopni přenést i smazání dál.

Na úrovni CDC pro určité databáze, typicky pro MySQL, podporujeme čtení přímo z binlogu.

To znamená, že se napojíme na binlog, vidíme, co se aktualizovalo, co bylo vloženo, co smazáno, a podle toho replikujeme dál.

MongoDB má oplogy, podporujeme také Postgres, SQL Server.

Samozřejmě není to úplně pro všechny technologie.

Pro některé technologie se CDC řeší klasicky tak, že existuje sloupec updated_at nebo created_at, podle kterého poznáte změny, nebo se to řeší na úrovni dotazu.

A někdy máme i trigger-based přístup, kdy se vytvoří databázové triggery na insert, update, delete operace.

Ty se zapíšou do speciální tabulky, která obsahuje například ID, a my podle toho čteme změny a replikujeme je dál.

Microsurfer?

Microsurfer?

Ano, takhle. Zkratek začínajících na C…

Vrátím se ještě k tomu, že jsem rád, že jste zmínili Zapier a Make, protože tam vidím větší konkurenci, nebo spíše z pohledu marketingu – pro ty use case, o kterých mluvíte, jsou to nástroje, do kterých bych se podíval jako první.

Na druhou stranu jste říkal velmi zajímavou věc – jak rychle jste schopni generovat nové konektory a že váš Secret Engine, který provádí tu inteligentní část, tedy z čeho do čeho a jak, je vaše největší vlastní hodnota.

Jde o to, že jste přišli na to, jak automatizovaně propojovat byznysové systémy a rychle vytvářet konektory.

To je jeden z velkých tajných zdrojů, samozřejmě vedle toho je celý extrakční a doručovací engine, který ve finále řeší detaily implementace, získávání dat z jednotlivých API.

Začíná řešit i to, že každý API používá trochu jiný autorizační mechanismus, stránkování, a každý má různou strukturu.

Třeba potřebujete zavolat jeden API call, který vám vráti seznam všech ID zákazníků, a pak pro každého zákazníka voláte separátní API call, abyste získali detaily.

Celý engine toto zvládá a navíc umí paralelizovat requesty, takže když řešíte stránkování a offsety, máme něco jako emitované requesty.

Nastavíte si počet workerů a tím určujete, kolik paralelních volání chcete odbavovat.

Různá API mají různá limity, například kolik callů za určitý čas můžete provést, takže engine toto umí řídit.

Transformační engine je tedy základ, ale kolem něj se nabaluje celý stroj, který pokrývá všechny nuance různých API.

Druhým velkým tématem je reverse ETL, tedy problém z opačné strany.

Primárně, když doručujete data do datových skladů, je to relativně bezpečné prostředí.

Můžete si definovat integritu dat přes cizí klíče, unikátní klíče a další constrainty, takže je to poměrně bezpečné.

Ale když děláte reverse ETL dotaz, který může třeba změnit všechny zákazníky v CRM nebo podobných systémech, které nejsou na to úplně designovány, objevují se komplikace.

Náš engine proto řeší, jak s těmito situacemi pracovat, aby nedošlo k problémům, případně umožňuje obnovu dat v případě potřeby.

Ty jsi říkal, že jste jedna z těch mála firem, které používají Go.

Takových firem je tady málo a lidí znajících Go také není mnoho.

Ve vaší firmě máte asi dva nebo tři.

Otázka tedy je ohledně time to market, resp. time to connector.

To by vás mohlo zpomalovat.

Vidím tam na jedné straně výhodu rychlosti, ale na straně druhé možný nedostatek hotových konektorů, pluginů, knihoven.

Možná je i kód trochu komplexnější.

Jak moc vlastně je to Go a jak moc tam používáte jiné jazyky?

Říkal jsi Kubernetes.

Proč právě Go?

To je skvělá otázka.

Go jsme zvolili z několika důvodů.

Historicky jsem hodně pracoval v C a Go mi přišlo jako dobrá kombinace – výkonný jazyk umožňující psaní vysoce výkonných služeb, paralelismus, mass processing, a zároveň uživatelsky přívětivý.

Jazyk má garbage collector, takže se nemusíte starat o management paměti, jako v C.

Naše infrastruktura a stack jsou ale výrazně vrstvené.

Go používáme pro cca 13–14 microservices, které dělají skutečný těžký tah – přenos, transformaci dat, extrakční a frontovací engine.

To všechno běží v Go.

Víme, že pro tyto úkoly potřebujeme výkonný, robustní kód s podporou paralelismu.

Samozřejmě používáme i jiné technologie.

Náš transformační engine běží v Go, ale instrukce do něj vkládáte v JSONech.

To znamená, že hlavní komponenta je v Go, ale pro tvorbu nových konektorů píšete konfigurační JSON soubory.

Díky tomu tvorba konektorů není programátorský úkol, ale konfigurační.

To nám dovoluje fungovat efektivně.

Dále používáme i PHP pro byznys logiku.

Když máte nějaký frontend, API, kde potřebujete mít větvenou byznys logiku, je PHP vhodné.

Frontend píšeme čistě ve Vue.js.

Přistupujeme k datové hlíze a technologickému stacku jako k domu – na některá místa použijete beton, jinde cihly, sádrokarton, nebo jiné materiály.

Tedy kombinace backendu v Go, uprostřed PHP, a frontend ve Vue.js.

Na českém trhu je asi málo takových kombinací.

Mně osobně se líbí Go, které zatím skoro nikdo nepoužívá, a PHP, které už někdo vysloveně nepoužívá.

Je to běžně používaná kombinace.

Samozřejmě vím, že se vůči PHP hodně lidí vymezuje a existuje tzv. PHP bashing, což je takový programátorský folklór.

Ale poslední verze PHP, a to není podcast o programovacích jazycích, se hodně zlepšily, zejména v objektovém modelu, inspirovaly se Javou a velmi nám to vyhovuje.

Je potřeba používat technologie podle jejich určení.

Psát těžkou business logiku v Go je noční můra, ale psát robustní backendové služby v PHP není vždy tou nejlepší volbou.

A když to srovnáme třeba s Pythonem, v tomto případě bych volil PHP.

Takže z tohoto důvodu jsme se rozhodli takto.

Ještě rychlý dotaz – říkal jsi, že to běží na Kubernetes.

Jak máte například multitenancy a oddělení dat klientů?

A také jak řešíte GDPR, například ohledně lokalizace dat?

Dnes Datadu funguje pro většinu klientů jako cloud-native single platform.

Oddělení dat řešíme na úrovni šifrování.

Každý datový tok každého klienta šifrujeme jiným klíčem.

To znamená, že i když se data na úrovni hardware setkají, jsou zašifrována jiným klíčem.

Oddělení je tedy řešeno na aplikačně-logické úrovni.

Co se týče multitenancy, máme i extrémně důležité klienty, kteří mají velký workload.

Ti běží díky Kubernetes na dedikovaných strojích.

Některé komponenty mohou být sdílené, včetně těch velmi důležitých klientů, ale některé jsou výhradně vyhrazené, například extraktory či writery.

Z hlediska GDPR a dalších standardů, primárně běžíme na AWS.

Jsme schopni garantovat, že data jsou procesována v dané geografické lokalitě.

Cluster je nasazený na několika místech.

Pro menší workloady, kde klient potřebuje mít přístupová data třeba pro Power BI, máme tzv. smart cache – malý pseudo storage.

Zákazník si může zvolit konkrétní geografickou lokalitu, například ze všech lokalit, které AWS podporuje, aby jeho data tam fyzicky byla.

Opravdu velmi dobré.

Když jsi mluvil o extraktorech, zdá se, že máte výborný přehled o moderním datovém stacku, co se s ním děje.

Zdá se, že jste hodně přemýšleli o tom, kde je vaše místo.

Máte konkurenty jak mezi velkými enterprise řešeními, která řeší i vaše oblasti, tak na druhé straně jsou tu i lehčí, mnohem menší řešení.

Jak vnímáš moderní datový stack a jeho pojem buzzword?

Co pro tebe znamená a jak se mění požadavky globálních klientů?

Jaké trendy vidíš?

Myslím, že směr je správný.

Datové odvětví se stává komplexnější a více heterogenní.

Je tam více datových zdrojů a formátů, se kterými se pracuje.

Je proto přirozené, že se trh začíná fragmentovat.

Zpočátku to byla end-to-end řešení, která pokryla vše od extrakce přes...

Storage až po vizualizace analytics. Dneska má úplně perfektní smysl z hlediska té komplexity, to, že máš oddělení vendory, které řeší kus celého datového stacku.

Na druhou stranu jsem tady zmínil Fytron jako našeho konkurenta. Myslím si, že zrovna jejich produktová strategie, kdy oni o sobě říkají, že dělají jen ETL nebo jen ELT, a třeba nejdou do reverse ETL, mi už, přestože jsem obhájce modelu modern data stacku, úplně nedává smysl. Protože si myslím, že má smysl se specializovat, ale na úrovni nějakých ucelených celků. Pro mě je transport nebo přenosová infrastruktura jeden ucelený celek. Nemyslím si, že má smysl mít extra vendora, který vám bude dělat extrakce do Data Warehouse, a pak dalšího vendora, který vám bude dělat reverse ETL z Data Warehouse do nějakých datových aplikací.

Samozřejmě ten modern data stack dnes, jak je pojatý, kde hodně dominuje Snowflake a mluví se o DBT, pro spoustu firem začíná být extrémně drahý. Dochází k tomu, že se za Data Warehousingová řešení platí compute i storage. To znamená, jakékoliv transformace, které v rámci toho modern data stacku probíhají, jsou poměrně velmi nákladné. Ten koncept, že se data vytáhnou v poměrně surové podobě nějakým vendorem, ten vendor je transformuje, tedy opět se propálí nějaký compute engine, a další vendor nad tímto compute enginem Data Warehouse udělá data quality řešení, to může být velmi drahé.

To je jeden z faktorů, se kterými se setkáváme poměrně často. I na úrovni extrakcí – tím, že dostanete do procesu méně dat, ale zato kvalitnějších, se vám zlevní všechny downstream služby, které jsou navázané na spotřebu Data Warehouse computu.

Druhá věc, kterou vidíme, je ta, že ve firmách, hlavně těch větších, začíná být běžné používat více Data Warehousingových technologií, což začíná být dost specifické na úrovni jednotlivých týmů. Dříve bylo typické, že firma se rozhodla, že bude mít jeden Data Warehouse – například od Amazonu – a do něj dala veškerý workflow. Ale jak Data Warehouse nástroje jako BigQuery, které jsou víc serverless a mají nižší bariéry vstupu než například Redshift nebo Snowflake, získávají na popularitě, některé týmy, například v AdTechu z marketingu, používají především BigQuery.

V podstatě tyto týmy chtějí query. Pro složitější případy, které jsou blíže centru firmy, pak dominuje často Snowflake, někde Redshift, jinde zase i Mongo. Vidíme, že výběr datového storage začíná být drivovaný byznys týmy, což jsem osobně nečekal. Pro nás je to dobře, protože to vytváří další komplexitu na úrovni datového stacku firmy a větší potřebu pro přenos dat apod.

Kdybych dnes nedělal data, ale pomáhal jiné části stacku, kde vidím příležitosti kromě transportu, který je teď momentálně hlavní? Vidím prostor v datech kvality. To je podle mě největší výzva adopce dat. Troufnu si tvrdit, že pokud nějaký datový projekt ve firmě selže, tak je to kvůli špatné datové kvalitě. Ta může být způsobena mnoha faktory – třeba lidským faktorem, vstupními daty nebo procesem samotným. Z mého pohledu je to největší slabina.

Souhlasíš, Karle? V dnešním světě machine learningu roste důležitost kvality dat.

Byla vždycky důležitá. Jak jsme mluvili o Takamě, na tom vyrostli před sedmi až osmi lety, takže souhlasím. Ovšem data quality se musí řešit primárně na úrovni primárních systémů, protože tam se nejlépe ohlídá, aby byznys uživatelé nezadávali nesmysly. Dále je možné provádět post-processing v Data Warehouse nebo Data Lake; to má potom zajímavý dominový efekt.

Když máte postavený reportingový systém, může být poměrně jednoduchý: data se extrahují ze zdrojových systémů, ukládají se a vizualizují. Organizace na těchto datech postaví rozhodovací mechanismy – například pondělní meeting management boardu, kde se hodnotí výsledky minulého týdne. Na schůzce promítají dashboard, a ti, kteří sedí v místnosti, často vůbec nevědí, odkud data pocházejí. Implicitně předpokládají, že data jsou správná a věří jim. Proč by ne? Přitom ale stačí banální chyba ve zdrojovém systému – například někdo místo tisíce zadá sto tisíc – a tato chyba projde všemi systémy. Management pak vidí „super“ výsledky a rozhoduje se investovat více na daném trhu.

Určitě je potřeba zaměřit se na primární data, ale jak datový stack začíná být více navázaný na firmu, bude stále důležitější zavádět checkpointy a bariéry, které chyby odhalí. I banální překlep může způsobit obrovské problémy.

Už přejdeme k basketbalu – co vás čeká v roce 2023 v Datadu?

V roce 2023, pokud budu mluvit o produktově-technologických věcech, půjde hlavně o business as usual věci jako nové konektory, zlepšování interfejsů a podobně. Velkým tématem bude compliance a bezpečnost. Chceme tlačit funkce, které uživatelům definujícím datasety řeknou, jestli jsou datová pole potenciálně mimo compliance, například v souvislosti s GDPR či CCPA. Uživatel si bude moci zvolit, že chce, aby dataset byl compliant, a systém mu ukáže, která pole má vyřadit.

Dále chceme výrazně investovat do funkcí na data quality, přidávat možnosti business pravidel, aby se minimalizovaly situace, které jsem popsal jako problematické. Nakonec budeme rozšiřovat reverse ETL – přidáme konektory a investujeme do této oblasti, protože zde vidíme velký problém a potenciál.

Komu bys letos doporučil Datadu vyzkoušet?

Freemium účet má určitá omezení, ale pro skutečný test bych doporučil firmám, které mají Data Warehouse a jejich hlavní problém je, že nejsou schopné dostat data ze svých systémů do Data Warehouse. Tedy chtějí zlepšit systémovou konektivitu ve firmě, případně mají řešení, které je „natvrdo“ zakódované, tedy bastl, custom kód apod.

Dále bych doporučil Datadu firmám, které hledají řešení reverse ETL. My sami jsme nedávno kompletně přešli na náš vlastní reverse ETL. Používáme HubSpot jako primární CRM s veškerými informacemi o zákaznících a uživatelích, měli jsme proto těžkou integraci s vlastní aplikací na míru. Správa těchto custom řešení zaberala půl úvazku. Po přechodu na Datadu interně všechny problémy, které jsme měli, vyřešíme a nabízíme toto řešení i dalším klientům.

Tak moc držíme palce a děkujeme, že jste dnes přišli vyprávět o ETLT.

Děkuji také za pozvání.

Děkujeme, že jste doposlouchali Data Talk až sem. Jak se vám líbila tato epizoda? Co byste na našem podcastu zlepšili? Koho pozvat příště? Dejte mi vědět, co si myslíte – buď osobně na příštím Data Mesh Meetupu, nebo hned teď na mail jirka@datatalk.cz.

Pokud se vám epizoda líbila, doporučte ji dále. Klikněte na srdíčka, hvězdičky, dejte subscribe, ať nám svítí dashboardy zeleně, křivky dělají hokejku a všichni stakeholdeři chválí extra budget.

Ještě jednou děkuji. Poděkování patří také mým kolegům Nikovi a Iris, stejně jako členům našeho partnerského klubu BigHub, DeepNote, Atakamně a Manitě. Pokud máte návrhy, tipy na hosty či témata, děláte 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.