Podcast

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

Ahoj, tady Karoš Mánek.

Vítáme vás u dalšího dílu Data Tolku. Naším dnešním hostem je…

Michal Koláček ze Slido.

Ahoj.

Michale, moc tě tady vítáme a na začátek by se hodilo představit těm pár lidem, kteří Slido nikdy nepoužívali, nesetkali se s tím a nevědí o vaší firmě: Co Slido vlastně dělá? Co jste za projekt?

Tak jo, Slido je taková webová aplikace, která se používá na interakci více méně kdykoliv, kdy je nějaký člověk, co něco prezentuje, a je tam nějaké publikum. Tam se Slido hodí. Funguje tak, že zajišťuje interakci právě mezi tím člověkem, který prezentuje, a tím publikem. A může to být prostřednictvím několika různých možností. Asi nejužívanější je, že publikum chce položit nějakou otázku tomu, kdo prezentuje, a posílá otázky přes Slido. Případně ten, kdo něco říká, chce něco sdělit publiku – může chtít znát jejich názor na to, co zrovna vykládá, získat zpětnou vazbu nebo třeba uspořádat kvíz pro ocenění někoho nebo pro ověření, zda si lidé něco zapamatovali.

Nejtypičtější příklad použití jsou samozřejmě konference. Nicméně u nás jsme se postupně posunuli i do firemního prostředí, kde jsou velké interní akce, například all-hands meetingy, na kterých se potkávají všichni zaměstnanci. Postupně se dostáváme i na menší meetingy a videohovory, kde je také člověk, který něco prezentuje, a může to být klidně jen pět až šest lidí. V takových callích se to dělá hůře, ale i tam Slido přináší hodnotu a zajistí interakci.

Když jsme se bavili před nahráváním, říkal jsi, že překvapivě málo lidí ví o původu Slido, že jde původně o slovenskou firmu, slovenský startup, který byl úspěšně exitován. Můžeš říct něco o začátcích Slido?

To je pravda. Většinou lidé, když se dozví, že jsem ze Slido, se ptají, jestli to je americká firma. A já říkám, že vůbec ne. Slido vzniklo v roce 2012 na Slovensku, založili ho tři lidé: Petr Komorník, Petr Sliuka a František Kryuda.

Vzniklo to zajímavým nápadem – Petr Komorník, který je dodnes CEO, přednášel na univerzitě. Když přednášel, chtěl během přednášky získat zpětnou vazbu od studentů. Nejprve zkoušel sbírat dotazy přes papírky, ale nefungovalo to ideálně, a tak přemýšlel o elektronické formě. Napadlo ho vytvořit webovou aplikaci. Na Startup Weekendu se setkali a vymysleli aplikaci používanou právě jen na zpětnou vazbu.

Někdo pak přišel s nápadem použít ji na konference a umožnit poslání otázek mezi účastníky. To byl úplný začátek. Nějakou dobu se vývoj soustředil jen na konference, kde jsme se dostali až k těm největším. Asi kolem roku 2016 jsme začali rozšiřovat použití i na velké firemní meetingy, například interní akce ve firmách. To získalo velkou dynamiku a zpětnou vazbu.

V roce 2016 a 2017 to hodně ožilo, protože jsme se zaměřili na větší meetingy ve firmách. Já jsem do firmy přišel na konci roku 2017. Potom jsme se ještě více posunuli a začali pracovat i s menšími use casy – například meetingy, videohovory – a proto máme integrace do různých platforem, jako je Microsoft Teams, Google Hangouts či Webex.

Protože to je i nástroj pro prezentace, máme integrace do PowerPointu a Google Slides a podobně. Takže jsme se posunuli spíš směrem k menším případům použití.

Když se blížil COVID, mysleli jsme si, že by to mohl být problém, protože konference asi poklesnou, ale díky tomu, že jsme již cílili na menší meetingy, chceme i tam Slido používat, ten růst pokračoval – rok 2020 byl extrémní růst.

Během roku jsme si řekli, že by nám pomohla finanční injekce, a v roce 2021 nás koupil Cisco.

Od té doby, co jsme pod Cisco, je to už skoro dva roky. Výhodou je, že nás Cisco nechalo pohromadě, celý tým zůstal a jen jsme se připojili k velké korporaci. Zároveň máme svého CEO a dostali jsme prostor i finance na rozšíření týmu a další rozvoj. Zachovali jsme si značku i produkt. I když jsme korporace, Slido jako značka a produkt i tým fungují dál.

Říkáš stále „my“, ale mě by zajímalo, jak ses ty do Slido dostal. Říkali jsme, že jsi studoval v zahraničí a nakonec ses dostal do slovenského startupu. S čím jsi tam nastupoval? Co tě lákalo? A čím se tam zabýváš nyní?

Já jsem ve skutečnosti nestudoval v zahraničí, ale v Brně – jsem Brňák.

Pro Karoše je to zahraničí, to uznávám, protože z jeho východního pohledu je Brno daleko. Já studoval na Masarykově univerzitě matematiku, ale nikdy jsem to nechtěl dělat profesionálně. Přišlo mi to jako hezký koníček, ale chtěl jsem dělat něco úplně jiného.

Po studiích jsem se odstěhoval do Londýna, protože tam je hodně konferencí a zdálo se mi, že bych se mohl věnovat organizaci konferencí. To ale nevyšlo.

Když jsem dál hledal práci, Slido mě zaujalo, protože v roce 2017 hodně rostlo, a říkal jsem si, že by to mohla být zajímavá výzva.

Když jsem nastupoval, vůbec se nevědělo, co budu dělat – ani se to nesměřovalo k datům. Na posledním pohovoru jsem mluvil s naším CEO Petrem Komorníkem, kterému říkáme Komo. Ten mi řekl, že je škoda, že jsem studoval matematiku, ale nijak jsem s čísly nepracoval. Navrhl, abych to zkusil.

Nastoupil jsem tedy a začal pracovat s daty.

Dnes už však máme datatým asi 27 lidí, zatímco když jsem nastupoval, byl jsem třetím člověkem, co si s daty hrál.

Celá firma má asi 270 lidí, takže datatým tvoří přibližně 10% firmy.

Aktuálně vedu analytický tým, který se zaměřuje na více oblastí. Ta analytická část je teď pod mým vedením.

Máte tedy 27 datových lidí? Kolik je z toho tvůj tým?

Jo, asi deset lidí mám přímo já.

A ostatní týmy, můžeš je popsat? Jak máte práci rozdělenou?

Určitě.

Dlouho jsme byli všichni na jedné úrovni a dělali všechno. Postupně jsme se specializovali, ale každý si vlastně stále trochu hraje se vším kolem sebe.

Za poslední rok to ale máme víc vytříbené – teď jsou tři konkrétní týmy.

Prvním je analytický tým, který je pode mnou a stará se o to, že když jsou data v datovém skladu, tak se vyčistí, správně namodelují a dají se s nimi pohodlně pracovat. Také se data vizualizují, vyrábí se analýzy a výstupy, podle kterých se dobře rozhoduje.

Druhý tým je data engineering, který se stará o vše před námi, tedy o to, aby data z různých zdrojů správně tekla do datového skladu. Oni spravují pipeline a backend i ops kolem dat.

Třetí tým je machine learning engineering. Ten využívá očištěná data poskytovaná analytickými inženýry k vytváření datových produktů nebo feature přímo do Slido.

To je zajímavé, protože člověk by si řekl, že Slido je jen aplikace, kde se zadávají otázky… ale vy tam děláte i hodně práce s daty?

Přesně tak. Pro běžného účastníka konference to vypadá jako seznam otázek, ale my vidíme velký potenciál v těch datech, hlavně textových.

Chceme přinášet hodnotu koncovému uživateli, takže musíme data využít.

Například během konference, když píšete otázku, asi nechcete posílat něco, co už tam někdo napsal, ale nechcete to celé procházet.

Proto máme algoritmus založený na NLP, který detekuje duplicitní otázky a nabídne uživateli třeba lajknout již existující otázku místo vysílání nové.

To je jeden příklad.

Když je otázek hodně, organizátor může lépe pracovat s otázkami, protože je složí do kategorií a přidá štítky, což usnadní orientaci a práci s nimi.

To je práce pro účastníky i organizátory.

Po skončení akce mají organizátoři přehled o tom, co se dělo, mohou získat sentimentovou analýzu nebo celkovou analýzu.

Pokud mají více eventů, mohou porovnat aktivitu mezi nimi, počet účastníků, počet organizátorů pod jejich firmou a další statistiky.

Automatické odpovědi na „blbé“ otázky – to zní zajímavě, ale jste na to už daleko?

To by bylo pěkné, možná tam ještě nejsme, i když teď, jak jsou akce velké, by to už možná šlo.

Líbí se mi, že mluvíš o konkrétních datových produkty a featurách, které přímo interagují s klientem nebo koncovým uživatelem.

Jak velká část práce těch 27 lidí je vymýšlet nové featury a zvyšovat užitnou hodnotu produktu?

Jak moc řešíte produktovou analytiku, business intelligence, standardní transakční data a řízení firmy?

To je dobrá otázka.

Řekl bych, že to závisí na týmech, které máme.

Language engineers jsou téměř výhradně zaměřeni na produkt. Málo kdy dělají něco pro řízení byznysu.

Tráví většinu času tím, jak data posunout dál, například používat NLP k přidávání větší hodnoty koncovým uživatelům nebo organizátorům.

My jsme v datatýmu měli a máme lidi, kteří to řeší z hlediska produktu, skoro jako produktový tým, včetně uživatelského výzkumu a designu, kteří pomáhají i s frontendem.

Takže jeden tým je naplno zaměřený na produkt.

Data engineers se starají o celý flow dat a pipeline, takže u nich je to rozdělené zhruba půl na půl – polovina práce jde na datové featury, polovina na interní potřeby, protože zdroje jsou podobné a práce se prolíná.

Analytics engineering je hlavně interní, starají se o čištění dat a vytváření tabulek.

Ty se pak používají k interním analýzám, dashboardům a rozhodování.

Takže co se týče interních a externích use casů, je to zhruba 20 % pro externí použití a 80 % pro interní, ale externí využití s tím úzce souvisí.

Naše interní práce je také zhruba půl na půl rozdělená mezi produktovou analytiku a business intelligence, například finance a sales.

Jak asi vypadala situace v datatýmu, když jsi do Slido nastoupil v roce 2017?

Kolik vás tehdy bylo? Jak jste si práci rozdělovali? Jaké byly první věci, na kterých jste pracovali? Asi museli jste se propracovat k datovým produktům…

Ano, to je pravda.

Teď to zní hezky – 27 lidí, 10 % firmy, datové featury, NLP… Ale v roce 2017 byla úplně jiná realita.

Byl jsem třetí člověk v týmu, který se datům věnoval, ale nebyl jsem čistě datový analytik.

Tehdy to byl takový datatým, ale technicky jsme vůbec nebyli dobře vybavení.

Všechno jsme měli v tabulkách v Google Sheets a dělali jsme analýzy přímo tam.

Když jsme se napojovali na produktová data, byla to přímo produktová databáze nebo CRM, odkud jsme si dělali exporty CSV a pak je házeli do tabulek.

Byl to takový punk v tomhle smyslu.

Mysleli jsme si, že stačí data napojit do nějaké vyhledávací vrstvy, tabulek nebo dashboardů, a bude to krásné, ale vůbec to nefungovalo, všechno se zasekávalo a nedalo se s tím pracovat.

Technická stránka ale nebyl hlavní problém.

Větší problém bylo, jak nás ve firmě chápali.

Lidé přišli s konkrétní otázkou, chtěli konkrétní odpověď, a my jsme jim to měli dodat.

Byli jsme takoví, že jsme je poslali pryč s podmínkou: „Hraj si s daty a řekni mi správnou odpověď, ideálně tu, kterou chci slyšet.“

Nikdy nebyl prostor se zamyslet strategicky, jak to uchopit, kam posunout a jak udělat škálovatelný řešení.

Firma hodně rostla v letech 2017–2018, a tak to chtělo systém a strukturu.

Naneštěstí v té době to stále chybělo.

[Pokračování textu chybí.]

Otázek bylo čím dál více a my jsme vůbec nestíhali, byli jsme zavalení tolika otázkami, že jsme se nedokázali ani nějak posunout.

Tím otázkami myslíš spíše produktové nápady, nebo spíše interní operativu?

Když produktové nápady, tak v té době nikomu ani nenapadlo, že by datový tým mohl dělat nějaké produktové věci. Možná tam nějaká myšlenka byla, že jednou sedíme na jakémsi „gold mine“, tedy hroudě zlata, o které víme, že je tam někde pod námi, a potřebujeme se k ní dostat. Ale jak ji vytěžit a jak se k ní dostat, to nikdo netušil.

To je na druhou stranu skvělé, že náš CEO i náš CFO byli tak strašně zaměření na data, měli k nim vztah, viděli potenciál, který by tam jednou mohl být, a hodně se ptali. Už od začátku máme velkou podporu v tomto, ale nikdo úplně nevěděl, jak se vůbec k tomu dostat a jaká by mohla být cesta, ani jak dlouho by to mohlo trvat.

Jasně, ale ty jsi to zažil, tak bys nám o tom mohl něco říct. Byl jsi tam ještě předtím, než se tyto věci začaly dělat. Zajímalo by mě tedy právě, kdo ty nápady přinesl. Trošku jsi na to odpověděl, ale vlastně jak se ty nápady začaly zapracovávat do produktu? Jak je začal adresovat tým, a na základě čeho se tým třeba rozdělil?

Ten tým v tu chvíli ještě ani neexistoval. Na začátku tam nebylo nic. Naštěstí přišla klíčová osobnost v tomto, a to byl Marek Šupa, náš dlouhodobý data lead, který už tu nyní není, protože se posunul do jiné pozice, ale od začátku roku 2018 až do loňského října byl naším data leadem. Ten to úplně otočil.

Na první pohled se snažil udělat velkou změnu datového stacku. Prostě ten stack technicky změnil – převedl ho na nějakou standardní úroveň, aby to bylo škálovatelné a aby bylo možné přemýšlet i nad datovými produkty v budoucnu a připravit to právě na tu budoucnost. Šlo o vybudování datového warehouse.

My jsme si tehdy, kvůli tomu, že rozpočet na to nebyl až tak velký, ale zároveň protože tomu věřím jako dobrému přístupu, zvolili open source řešení. Postavili jsme to tak, že jsme použili Apache Superset pro vizualizaci, Apache Airflow pro orchestraci pipeline a scripty jsme si většinou psali sami v Pythonu pro stahování dat. Vše jsme hodili na AWS do Athény, protože AWS jsme dlouhodobě používali. Athéna tedy sloužila jako warehouse a na tom technicky celý systém stál.

Co ale bylo podle mě ještě důležitější, byla změna pohledu na to, co datový tým je, co může být a jak má pracovat. Hlavní myšlenka byla, že datový tým může fungovat jako produktový tým s velmi podobnými rysy, protože data jsou vlastně produkt. Když člověk nad tím přemýšlí, cokoliv, co ta data vytváří – ať už jde o nějakou konkrétní funkci přímo do Slido, nebo třeba dashboard či automatizaci – to jsou datové produkty.

Když tedy přijmeme, že datový tým je vlastně produktový tým, musí se podle toho i chovat. To znamená, musí být zaměřený na uživatele, sbírat to, co uživatel potřebuje, být vždy o krok napřed a posouvat se společně s uživatelem. A hlavně dělat věci skutečně s nějakou vizí, se strategií.

Největším posunem bylo přestat dělat to, co jsme měli předtím – odpovídání na konkrétní dotazy jednotlivců s konkrétní odpovědí „na míru“. Naopak jsme šli cestou automatizace, škálování a posouvání systémů tak, abychom ještě před tím, než přichází uživatel s nějakým nápadem, už o něm věděli a byli na něj technicky připraveni.

To nám umožnilo úplně jiný způsob přemýšlení – stát se vlastníky datového produktu, vědět, kam ho chceme posunout, jak získávat zpětnou vazbu a pracovat s interními i externími uživateli. Stavíme minimální použitelný produkt (MVP) a vše děláme technicky automatizovatelně. To v původním postupu vůbec nebylo možné.

Předtím se otázky řešily jednorázově; i když to bylo v SQL, bylo to špatně nastavené v hlavě. Najednou jsme to však mohli posouvat.

Navíc nám to dalo prostor i pro lepší komunikaci s kolegy. Mohli jsme říct: „Dobrá otázka, co kdybys mi dal na to týden? Nedělám to hned, ale za týden to bude hotové. Uděláme ti dashboard, kde nebudeš mít data jen pro jeden konkrétní případ, ale budeš si to moci naklikat sám a získáš je okamžitě. Nemusíš čekat, až ti to udělám.“

Můžeš uvést konkrétní příklad?

V roce 2017 jsem půl roku odpovídal na dotazy typu LTV (lifetime value) jednotlivých kohort podle toho, kdo se přišel zeptat. Teď, když někdo přijde, řeším to jinak: „Kohorty jsou zajímavé, pojďme se bavit obecně o kohortách, vyjeď si to sám.“ Konkrétně si vzpomínám například na otázky, které jsi řešil minulý rok nebo před pěti lety.

Možná bych navázal tím, jak probíhal ten proces, protože se to často opakovalo a jak jsme to nakonec vyřešili.

Často za námi chodili account manažeři nebo zákaznické supporty – u nás jsou to dvě rozdílné role –, kteří spravují účty. Přicházeli za námi s žádostí o data o chování klienta v minulosti, o vývoji, kolik mají eventů, uživatelů, o počtu položených otázek. Nejen pro sebe, aby věděli, co se děje, ale aby to mohli předávat klientovi.

V roce 2017–2018 to v podstatě bylo tak: „Tady je konkrétní účet, dej mi přesná data.“ To samozřejmě zabíralo hodně času i nám.

Řekli jsme si: „Dost! Postavíme velký dashboard se všemi metrikami, které vás mohou zajímat. Vybereme ty nejpoužívanější, začneme těmi klíčovými, tedy minimálním fungujícím produktem (MVP). Postupně můžeme metriky přidávat, vy si budete moci filtrovat údaje, které potřebujete, a mít je k dispozici sami.“

Najednou už nemuseli za námi chodit, mohli si to vzít sami, dát to do prezentací a podobně. Naše úloha se posunula jinam – starat se o to, aby metriky byly správně nadefinované, správně fungovaly a hlavně učit lidi, jak s daty pracovat, jak je správně vytáhnout, interpretovat a třeba je dobře prezentovat klientům.

Když to posunu ještě o úroveň dál, řekli jsme si: „Když už to máme interně, proč to nedat i zákazníkovi?“ To byl další krok – vzali jsme tabulku a dostali ji přímo do produktu, takže již delší dobu můžou klienti ve své analytice přímo ve Slido na organizační úrovni vidět ta data.

Samozřejmě tam mají méně metrik než my interně, protože nedáváme všechny sledované metriky, které interně sledujeme, ale mají základní přehled na stejné platformě.

Shrnu-li to, začali jsme u exportu CSV z interní produkční databáze, které jsem posílal kolegovi na Slacku, a dnes máme automatizovanou tabulku, která se vizualizuje v interním dashboardingu nebo je k dispozici klientovi přímo v aplikaci.

Jasně, ale trochu mi utíkáš od otázky, na kterou jsem se původně ptal. Spíš mě zajímá, jestli tam opravdu někdo praštil do stolu – nevím, jestli to byl ty nebo někdo jiný – a řekl: „Teď to budeme dělat správně, nabráníme hodně lidí a budeme dělat produktové funkce, které budou viditelné pro koncového uživatele“. Bylo to takové „moonshot“ rozhodnutí, nebo to bylo spíš postupné, kdy jste jen změnili mindset, začali dělat věci trochu jinak a začali nabírat další lidi?

Zůstanu u této otázky. Ano, opravdu někdo praštil do stolu. Nebyl to já, byl to Marek, který přišel v roce 2018 jako nový data lead, a doslova řekl: „Takto to nejde.“

Došlo k obrovskému přerodu v relativně krátkém čase. Technické nasazení šlo rychle, nezabralo moc času. Ale vybojovat si v týmu a v celé firmě to, že se to má takhle dělat, to bylo ráz na ráz. Muselo to být docela tvrdé.

Mindset se měnil postupně, ale spíš v hlavách ostatních. My jsme byli docela rychle naklonění změně, protože jsme věděli, že předtím to nejde, jen jsme nevěděli, jak to posunout. Byli jsme zahlceni konkrétními otázkami, a proto jsme nemohli myslet strategicky. Ten posun přišel s Markem.

To vyžadovalo poměrně velkou investici, že? Jednak přerod technologického stacku je jedna věc, což se dá pochopit, a možná to zvládne i existující tým. Ale ty jsi říkal, že byl i značný nárůst lidí. Šel ten nárůst ruku v ruce s novým stackem, nebo to šlo postupně?

Postupovalo to ruku v ruce. Klíčový tým, který Marek postavil pro infrastrukturu, byl relativně malý. Jakmile se ukázalo, že to je správná cesta, začali jsme nabírat lidi. Tým rostl přirozeně, nabírali jsme hlavně do pozic, kde bylo nejvíc potřeba lidí.

U nás je specifické, že už na začátku, a nyní častěji, nám lidé přicházejí interně. Pracují s daty, učíme je to a oni jsou k tomu nadšení, všichni jsou tak nějak součástí týmu.

Náš hlavní recruitment je tedy interní – lidé sami přicházejí, chtějí k nám, chtějí být s námi. Díky tomu tým pořád roste.

Co se týče nápadů, už jsme zmínili, že máte nějaké hlavní lidi, kteří je vymýšlejí, ale byli jste i taženi poptávkou klientů? Ti vám přicházeli s vlastními představami – například pět konkrétních funkcí, které chtěli implementovat? Jak jste to zohledňovali oproti vašim interním nápadům?

Přišli s nějakými nápady, nejčastěji chtěli vidět, co se na jejich účtu děje, což bylo nejčastější přání. Na straně klientů ale nepotřebovali tolik detailů, měli základní potřeby.

Na druhou stranu, a to je opět otázka produktového přístupu, jedna věc je feedback, druhá je, že někdo má vizi a strategii a ví, kam chce posunout produkt. Ten člověk totiž ví, jaké jsou možnosti.

Takže do jisté míry nápady přicházejí interně. Máme už několik let Slack kanál, který se jmenuje Data Ideas, kde si zadáváme nápady, když nás něco napadne.

Také Slido pravidelně organizuje interní hackathony, desktopové i datové – datatony – tedy dvoudenní či třídenní akce, kde se tyto bláznivé nápady mohou naplno realizovat.

Postupně se z těchto nápadů zformoval tým, který se jim plně věnuje.

Samozřejmě začali jsme hlavně infrastrukturou, ale teď už máme například tým Machine Learning Engineering, který se těmto věcem věnuje na plný úvazek.

Můžeš uvést nějaké konkrétní věci, které vypadly z vašich hackathonů nebo datathonů? Říkáš „šílené nápady“ versus „rozumné featury“, které jsi zmínil.

Určitě bylo spoustu bláznivých nápadů, některé téměř nesmyslné.

Nedávno na vánočním hackathonu jeden z našich kolegů, Miro Bodiš, který se stará o CRM a závodně jezdil na skateboardu s výbornými výsledky – byl jedním z nejlepších slovenských skateboardistů – vymyslel, že si na skateboard připevnil telefon a při jízdě rozeznával, jaký trik udělal. Na základě toho pak hlasoval ve Slido.

Šlo o zkoušku, jak by bylo možné hlasovat skateboardem.

Nevím úplně, jestli to někdy v produkci nasadíme, ale pro Míru to byl skvělý nápad, který tři dny programoval, vytvořil k tomu pěkné video a fungovalo to.

Myslím, že je to spíš pro něj, ale samotný nápad je podle mě krásný.

Vidím v tom potenciál, jako ve startupovém světě, například na velké interní konference, All Hands a podobně, kde jsou chytré židle a měří se CO2. To může být skvělá zpětná vazba o tom, jak lidé reagují v průběhu přednášky.

To je prostě vzácný prostor pro inovace.

Dalším projektem, na kterém jsme pracovali s datovým týmem na některém hackathonu – i když není v produkci – bylo ovládání Slido hlasem. Člověk mluví a systém v reálném čase rozpoznává jeho příkazy, posunuje prezentaci, zapíná nebo vypíná Slido, přidává otázky a podobně.

Hrali jsme si s tím a bylo to fajn.

To už je ale pár let zpátky.

Michale, už jsi tu několikrát zmínil váš tech stack. Jsem na tvůj meetup a naše posluchače určitě zajímá váš technologický stack. Zmínil jsi kombinaci AWS a Athény, můžeš být trošku detailnější?

Jistě.

Je to tak, že backend běží na AWS, vše máme na Athéně.

Pipeline – tedy způsob, jakým se tam data dostávají – stále stojí na vlastních skriptech napsaných převážně v Pythonu. Orchestrace běží přes Apache Airflow.

V některých dalších konkrétních zdrojích… (text zde končí).

Text byl přepsán do spisovné češtiny s dodržením 100 % obsahu, rozčleněný do odstavců a s opravami gramatiky i diakritiky.

Rojích to zkoušíme automatizovat, například jsme si hráli s Meltanem, což je také open source nástroj, a zkoušeli jsme zjistit, jestli by to bylo možné využít. Nicméně zatím se stále držíme toho, že pro nás je nejvýhodnější si držet vlastní, specifické custom řešení, zejména pro interní zdroje, kde to jinak moc nejde.

Dále, když celý proces posuneme, tak to celé běží přes Kubernetes, kde si to všechny spouštíme. Pro analytiku a data modeling pak používáme dbt, ve kterém děláme úplně všechno od stavění modelů, dokumentování, testování až po nastavení různých automatizací. Například posíláme data do naší prezentační vrstvy, kterou je Apache Superset – také open source projekt od Apache, a tam máme nastaveny další automatizace.

Kromě toho zajišťujeme i vnitřní nástroje a automatizace, například Slack boty, automatické reporty nebo e-maily. O všechno toto se staráme my, ačkoliv by to spíše nemělo spadat pod tým dat, ale my chceme přidávat hodnotu všude možně, a proto se o to staráme.

Napadlo mě, že často potřebujete nějaká data v reálném čase, nebo něco, co běží hodně rychle. Hodně jsi zmínil workflow běžící na Atíně, která je z principu pomalá, protože je založená na SQL a podobných technologiích, které na real-time nejsou úplně vhodné. Jak toto řešíte?

Do nedávna jsme všechno dělali batchově, což znamenalo, že jsme si data stahovali jednou denně, vytvářeli repliky pro různé databáze a ukládali vše do AWS na S3, bez velkého řešení real-time dat.

Ale máme strategii vidět dopředu, a proto jsme si řekli, že v nějakém okamžiku bude real-time potřeba, nejen pro nás, ale i pro externí požadavky, kdy chceme data dodávat průběžně. Po delším zvažování jsme zvolili Kafku a Clickhouse, na kterých jsme postavili něco, co nazýváme DataPi, nebo Data API, které aktuálně obsluhuje první interní use case.

Vize je, že to bude zajišťovat kompletně jakoukoli práci s daty. Interně to bude dále rozvíjeno, přebírá stará API, která jinde nefungují než v datatýmu, a do budoucna je plánováno i pro externí uživatele.

Už nyní máme konkrétní případ, kdy si klient může vyexportovat data přes Data API, pokud chce detailní výstup, nejen zobrazení v produktu.

Technologicky Kafka běží na Kubernetes, nejste tedy ten typ, který podpírá pouze managované služby?

Ano, používáme Kubernetes. Integrace do dalších produktů nás velmi posunuly, například pokud jde o Google Meet a strategii přidávat addony pro jiné softwary. Je toto úzce spojeno, nebo je to spíše korelace?

Integrace nám pomohly lépe pochopit, že vazba mezi nástroji je extrémně důležitá. Člověk sám o sobě nedokáže moc změnit. Například nástroj Slido – pokud chceme mít dopad ve firmách, nemůžeme požadovat, aby uživatelé stáhli CSV a něco s tím dělali ručně.

Pokud chce organizace Slido používat pravidelně, musí být proces automatizovaný, data se musí přenášet do datového skladu, podobně jako u nás s jinými nástroji, a pak se může vizualizovat v dashboardech.

Interně jsme také zjistili, že produktové API je často předimenzované a mnoho datových věcí by šlo lépe popropojovat napříč nástroji než řešit přes produktové API. Proto jsme se rozhodli vytvořit vlastní řešení, které nám umožní být vlastníky dat, to znamená mít široký datový produkt a pracovat s daty napříč celým Slidem, což otevírá možnosti téměř kamkoliv.

Co se týká automatizace, napadá mě koncept data ops – do jaké míry to řešíte? Máte vše v Gitu, release pipelines, oddělené prostředí a tak dále? Jak to máte nastavené?

To přišlo s přístupem, kdy data vnímáme jako produkt. Předtím jsme vůbec nevěděli, co data ops je, byli jsme naivní. Po změně, kdy datový tým funguje jako produktový tým, začali jsme používat inženýrské praktiky, starat se o to jako o software.

Všechno jsme probrali, dali do Gitu a automatizovali pomocí skriptů, což zahrnuje i data ops. Zpočátku bylo vše velmi jednoduché – nastavili jsme vlastní testy dat a posílali alerty na Slack, abychom věděli, pokud něco nefunguje.

Dnes už jsme dál – díky dbt, které umožňuje psát testy přímo vedle modelů, máme všechny modely otestované a vše cpeme do CI/CD pipeline, používáme GitHub. Snažíme se, aby se vše testovalo automaticky ještě před nasazením do produkce, aby tam nemohlo být něco nežádoucího.

Máme automatizované kontroly formátování Pythonu, kompilaci dbt modelů (které momentálně jenom kompilujeme, ale brzy budeme i testovat správnost). Také zajišťujeme, aby změny v repozitáři musel vždy zkontrolovat tým vlastnící příslušnou část.

Dbáme na to, aby pull requesty a změny v kódu byly dobře udělané, ale co nejvíce automatizované, aby recenzent mohl věnovat pozornost hlavně kvalitě a smyslu změn. Tento přístup používáme od roku 2018, ale postupně vykonáváme stále více činností.

Podíváme se na dbt, které jsi zmínil mnohokrát – kdy jste ho nasadili a jak se jeho používání vyvíjí s rozvojem nástroje? Co jste používali předtím?

Pro nás bylo nasazení dbt zásadní. Dříve jsme dělali transformace na míru v SQL skriptech, což bylo podle mě nevhodné a zbytečně složité.

Dbt jsme zkoumali dlouho, ale až v roce 2021 měl dbt plugin pro Atínu dostatečnou úroveň, aby bylo možné jej použít plnohodnotně.

Pro ty, kdo neznají dbt: jde o nástroj, který na první pohled vypadá jako pouhý SQL výkonný nástroj, kdy se modely píší v SQL, přičemž můžete používat i podmínky a cykly. Každý model je SQL příkaz, který transformuje data a dbt zajišťuje jejich správné uspořádání.

Dbt ale má i další funkce, například dokumentaci v YAML souborech a testování. To podporuje automatizace a produkční přístup k datům, kde vše je v repozitáři a verzováno v Gitu.

Můj názor na dbt je takový, že dříve se snažili lidem SQL zjednodušit, pak vzniklo Python kódování nad SQL, aby se předešlo komplikacím, a nyní existují nápady na další zjednodušení nebo jiný jazyk, který by byl kombinací Pythonu a SQL pro selekty. Takže vývoj jde stále dál.

Je zajímavé, jak Python dostal druhý dech a stal se opět velmi populárním jazykem díky machine learningu, ačkoliv předtím slábl. A SQL jako jazyk existuje téměř 50 let, stále se používá, ačkoliv už mnohokrát bylo prohlašováno, že je mrtvý.

Právě dbt trochu pomáhá SQL nadále udržovat, protože usnadňuje psaní SQL příkazů bez nutnosti se starat o detaily jako tvorba tabulek či aktualizace, o což se dbt postará samo.

Zmínil jsi, že implementace dbt nebyla vždy jednoduchá. Mohl bys dát nějaké rady nebo tipy těm, kdo dbt zavádějí? Na co si dát pozor?

První rada je nasazovat dbt raději až později. My jsme ho měli v nějakých vlastních custom skriptech, protože jsme ho nemohli mít dřív. Po roce práce v custom řešení jsme celý převáděli do dbt a byla to několik týdnů náročné práce a velký bolest hlavy.

Důležité je také se od začátku inspirovat existujícími zkušenostmi a způsoby práce s dbt. Tehdy ještě nebyla tak rozvinutá komunita a množství tutoriálů jako dnes. Dnes dává smysl plánovat s předstihem, jak repozitář uspořádat, jaké pluginy používat a jak projekt škálovat, aby se později předešlo velkým problémům.

My jsme například všechno napsali v jedné vrstvě, transformovali špinavé zdroje vícekrát v jednom procesu, což vedlo ke kolizím a cirkulárním závislostem, které nejdou řešit.

Po roce jsme proto zavedli tzv. staging layer, tedy vrstvu před dimenzionální a reportingovou, která připravuje data správně před dalším zpracováním. To je lepší udělat hned na začátku.

Dodnes to nemáme dokonalé a přidání staging layer po roce a půl bylo ještě bolestivější než přepisování původního řešení.

Typické rady jsou tedy: naplánovat si dobře strukturu projektu, začít se staging layer a inspirovat se existujícími standardy, aby se předešlo velkým následným problémům.

Z novinek z minulého roku – máte něco, co výrazně ovlivnilo tvůj pohled na dbt? Dbti původně vnímáš jako malý nástroj, jazyk, a neviděl jsi ho jako velký software střed moderního datového stacku.

Jsou dvě věci, které stojí za zmínku.

První jsou metriky, které dbt představilo loni jako důležitou myšlenku. Často se totiž stává, že člověk si vytvoří vizualizaci v nástrojích jako Superset, Jupyter notebooku nebo jinde, ale metriky se ukládají odděleně v každém nástroji.

Dbt chce tento problém řešit takzvaným „headless“ přístupem, kdy metriky jsou definovány přímo u zdroje v YAML souborech, které dbt využívá. Tím vzniká jednotné místo pro metriky a otevírá se prostor pro další automatizace.

Tuto věc doladili loni a nyní je to významný krok směrem k větší jednotnosti a efektivitě práce s daty.

[další část textu neobsahuje další informace, viz poskytnutý úryvek]

Jsme profesionální editoři českých podcastů.

Úkol:
Přepiš text do spisovné češtiny.

KRITICKÉ:

• Zachovej 100 % obsahu
• NIC nevynechávej
• NIC nezkracuj
• Význam musí zůstat stejný

Pravidla:

• oprav gramatiku
• oprav diakritiku
• rozděl do odstavců
• zachovej všechny informace

TEXT přepsaný:

Takové, že tam v podstatě může být nadefinováno úplně cokoliv, co si člověk namyslí, například year over year, year to date a ještě nějaké transformace, vše, co tam je. No a pro ně je to také velká možnost. Vymysleli to tak, že když člověk používá jejich placenou verzi, která je v cloudu, může se připojit na jejich servery a přímo se dotazovat na jednotlivé metriky přes něco jako API nebo ten server, a to ať už z nějakého Jupyter notebooku, nebo z nějaké prezentační vrstvy. Vše je zadefinované v jednom YAML souboru a jednoduše se ptá skrze ten server.

My ale používáme na dbt takzvanou core verzi, což znamená, že si to celé manažujeme sami. Přesto můžeme dělat automatizace, například ty metriky automaticky pushovat do Supersetu a tam si s nimi hrát.

Nyní máme projekt, kterému jsme chtěli věnovat pozornost, aby to šlo lépe. Z tohoto pohledu máte teď metriky zadefinované v Data Warehouse, nebo ve vizualizačním nástroji?

Právě že v tom vizualizačním, ale obecně tedy všude. A my to máme ještě horší, protože to původně nebylo zadefinované přímo tam. Proto máme i jiný způsob, který sice říkám až se skoro stydím, ale tak se to standardně dělá, a to je OLAP cube. Prostě máme obrovskou kostku, kde jsou důležité dimenze a kolem dvou set metrik. Jenže to je katastrofa, protože jakmile chce člověk přidat větší granularitu, nejde to. A když jednou kostku vytvoří, už se skoro nedá změnit.

Od toho se chceme distancovat, nechceme to tak dělat a raději použít ty dbt metriky. Myslím, že v tom je velká síla. Myslím si, že tímto směrem půjde i spousta dalších firem. Případně ještě tabulární model.

Navíc, zmínil jsem dvě věci, ale zapomněl jsem na jednu důležitou, která je důležitá pro ty, co začínají s dbt – a to jsou makra. Makra nejsou jenom nějaké funkce, spíše jako v Pythonu, kdy si může člověk definovat vlastní funkci, nebo použít nějaký balík (package), který si nainstaluje do svého dbt projektu a využívá to, co vytvořil někdo jiný. Tyhle věci jsou často open source, takže když se někdo s něčím neztotožňuje, může to opravit, přidat nebo si postavit vlastní makra, nemusí znovu vymýšlet kolo.

Například, když má člověk data z Google Analytics, nemusí vymýšlet, jak modely psát a jak čistit špinavá data, ale využije jen balík, který na to je, a ten mu automaticky vytvoří pět modelů, na kterých může pracovat bez nutnosti vše psát sám. My to konkrétně nepoužíváme, ale vím, že to takto funguje, a balíků je tam stovky, takže je škoda toho nevyužít – stojí to na ramenou titánů.

Co se týče technologie, možná to s tím souvisí. Ty jsi říkal, že používáte Athenu jako hlavní transformační engine. Máte vůbec nějaký zájem z Athenu „utíkat“, použít ji jen pro část operací a na zbytek něco jiného?

Trochu nás to omezuje. Poslední dobou hlavně rychlost – Athena je pomalejší, což nás limituje. Druhá věc je, že Athena není úplně standardní řešení. U nás je dbt uprostřed celého systému, ale dbt v základu Athenu moc nepodporuje, je to jen další konektor řešený komunitou.

Kdybychom mohli použít například Snowflake, který Cisco v rámci firmy používá, otevřely by se dveře k mnoha balíkům, které na Athenu nejsou, protože stojí na SQL příkazech pro Snowflake SQL flavor, které by bylo na Athenu nutné přepsat ručně. To je první věc.

Druhá je škálovatelnost – Snowflake je na ní jednodušší, Athena není primárně navržena jako analytický data warehouse.

Ještě jedna věc k dbt, kterou jsi zmiňoval – dokumentace. Zmiňoval jsi, že tam věci dokumentujete: governance dat, business dictionary, vlastníky, popis transformací, aby třeba uživatelé z byznysu nebyli ztracení a věděli, zda k datům mají přístup či nikoliv. Říkal jsi, že máte spíš datovský sentiment v celé firmě, předpokládám, že to tak je. Jak to máte u vás?

U nás je dokumentace opravdu klíčová. V rámci práce produktového týmu nebo pro developera je zásadní, aby dokumentace nebyla založená na tom, že je něco v hlavě, ale aby bylo vše napsané tak, aby tomu rozuměl jak interní člověk, tak kdokoliv, kdo na tom bude dále pracovat nebo koncový uživatel.

Dokumentujeme úplně všechno – modely, co znamenají, proč tam jsou, k čemu slouží, i jednotlivé atributy v modelech. Často dokumentujeme i makra nebo automatizace a související README soubory nebo návody – jak co dělat.

A teď k další dokumentaci – všechny naše procesy se snažíme napsat na papír, úplně všechno. Aby práce nebyla vůbec závislá na konkrétním člověku, ale kdokoliv to může kdykoliv asynchronně otevřít a udělat sám. Platí to pro datový tým, který potřebuje přidat novou transformaci nebo sestavit DAG v Airflow, ale funguje to i pro externí lidi, respektive lidi mimo datový tým ve firmě Slajd.

Pro nás, zejména analytický tým, je asi nejdůležitější ten use case, že chceme, aby lidé s tabulkami sami pracovali, hráli si s nimi, vizualizovali a hrabali se v datech. Proto musíme mít vše napsané. Velmi dbáme na to, aby to tam vše bylo.

Vytváříme také tutoriály, například jak použít Superset, jak pracovat s dbt, přidáváme odkazy, máme data handbook, kde najde člověk odkazy, jak se naučit SQL, používat Superset, a krok po kroku, jak se v datech ve Slajdu naučit orientovat a získat lepší rozhodnutí.

Používáte na dokumentaci nějaké speciální nástroje, nástroje „super handy“ nebo jen klasickou wiki na Confluence či něco podobného?

Máme to tak, že dbt obsahuje něco, co se jmenuje dbt docs, což je statická webová stránka, kterou lze kdekoliv hostovat. Vše máme v YAML souborech, takže i dokumentace existuje přímo tam – což je veliká výhoda, protože dokumentace prochází review.

Když člověk dělá nový model nebo mění atribut, mění zároveň i dokumentaci. Nestane se, že je něco nespojené nebo mimo. Vše prochází jedním pull requestem, který kontroluje obojí, a změny se projeví společně, když se nasadí do produkce.

Díky tomu, že dbt generuje statickou webovou stránku, jednoduše ji zveřejňujeme jako interní stránku, kde lidé najdou naše modely. Rozšířili jsme to tak, že tam mají i dashboardy, které používáme a jsou tam zadokumentované, stejně jako analýzy.

Máme tam také SQL dump, kam lidé dávají jednorázové SQL dotazy pro případ, že se někdy hodí. Všechno je na jednom místě, dohledatelné v dokumentaci, takže i člověk bez přístupu do repozitáře nebo nepřihlášený jej může najít.

Ještě poslední věc. Týká se to možná méně dbt, ale zmínil jsi, že teď máte docela velký tým pro strojové učení (machine learning). Zaměřujete se hodně na NLP a představuji si pokročilé frameworky jako TensorFlow, Keras, PyTorch apod. Jak tohle řešíte? Zmiňoval jsi Jupyter notebooky, máte třeba Kubeflow, používáte Kubernetes? Máte MLOps či něco podobného?

Do detailu do toho nevidím, protože je to na okraji naší práce, ale vím, že se používají Jupyter notebooky, kde se modely vytváří, a následně se spouští přes AWS Lambda funkce. Nic komplexnějšího momentálně nemáme.

Vize do budoucna je, že obdobně jako jsem popisoval data API, by se mnoho věcí mohlo obsluhovat přímo přes API, kdy by se produkty dotazovaly a výsledky přes API tlačily. Takže to není tak, že byste vy ten proces orchestraci kompletně řídili – oni jsou v podstatě jen jakousi „parazitní“ vrstvou, která si data bere.

Je to tak?

Ano, přesně tak.

Ještě poslední otázka. Mluvíš o organizaci o cca 270 lidech, zmiňuješ, že data opravdu proudí napříč a používají se. Při diskusi o vzdělávání jsi říkal, že se snažíte rozšiřovat datovou gramotnost napříč celou organizací bez ohledu na pozici. Máš to na starost ty? Jsou v této oblasti nějaké programy, zkušenosti či tipy, které ses za posledních pět, šest let naučil a které fungují či naopak nefungují?

Velmi nás to formovalo opět díky dbt a komunitě kolem něj, protože kromě dbt samotného tam vznikla komunita lidí, kteří tomu říkají analytics engineering, a my se s tím hodně ztotožňujeme.

Je to role někde mezi datovým inženýrem, který dělá datové modelování, a datovým analytikem, který vytváří insighty. Analytics engineer musí zvládat obojí a je někde mezi nimi.

Tato role, kromě tvorby modelů, má i třetí úkol – učit ostatní, buď datové analytiky nebo přímo byznys uživatele, jak s daty pracovat a s výsledky, které analytics engineer vytvoří.

My s tímto přístupem souzníme, protože naše organizace je poměrně velká. V určité fázi byl datatým poměrně velký, ale analytický tým tvořili jen dva lidé – já, který jsem se staral o oddělení sales, account management a customer success, a kolegyně Danka, která řešila produkt a finance, tedy celkové metriky.

Ačkoliv nás byli dva, starali jsme se o asi 150 až 200 lidí. Podařilo se nám to zvládnout díky technickému přístupu a automatizaci, která šla škálovat.

Ale už tehdy jsme věděli, že dva analytici nebudou stačit, až tým poroste. Už v té době jsme měli myšlenku, že pokud má celý systém fungovat, musí se všichni naučit s daty pracovat sami, jinak se zblázníme a škálovat to nepůjde.

Do toho jsme se proto vrhli, protože to šlo ruku v ruce i s myšlenkou analytics engineering.

Vytvořili jsme dokumentaci tak, aby si kdokoliv mohl přijít, a my říkáme: pokud chceš s daty pracovat, tady máš vše popsané. Když má problém, sedneme si jeden na jednoho, ukážu mu to, ale já to za něj nedělám. Ukážu, jak na to, aby si to pak dělal sám.

Tento osobní přístup se snažíme udržovat a zároveň děláme další aktivity – posíláme datové dotazníky (surveys) a spoustu dalších věcí, protože chceme, aby lidé s daty pracovali sami a my jim jen umožňujeme přístup.

Ty jsi několikrát zmínil přístup „my jim to ukážeme, oni se naučí, oni si to udělají sami“. Můžeš popsat, kterou část datového procesu (Data Engineering Pipeline) nebo BI pipeline ti lidé zajišťují?

Je to od chvíle, kdy my dokončíme přípravu tabulky. Zní to možná extrémně, ale řekl bych, že vlastně ani nemáme datové analytiky úplně klasicky. Vynechali jsme je. Máme Analytics Engineers, kteří se starají o kvalitu modelů a výuku ostatních. Dále máme lidi v byznysu – například developery, kteří vyvíjejí své funkce, produktové manažery starající se o tým, account managery, kteří potřebují vědět, jak se chovají jejich zákazníci.

Ti všichni, kdo rozumí svému businessu, si sami vytvářejí vlastní analýzy a používají data. Když chtějí vytvořit graf, otevřou Superset, který umožňuje psát vlastní SQL nebo vytvářet vizualizace jednoduše na základě existujících tabulek.

Někteří lidé používají jen filtraci v dashboardech, což je pro nás obrovská úleva, protože kdybychom museli dělat vše manuálně, zbláznili bychom se.

To nám pomáhá, protože lidé chtějí s daty pracovat. Jde to až do vedení – CEO Komo, celý výkonný tým věří datům a považuje je za základ pro rozhodování.

Konec přepisu.

To jako jenom pomocí čeho se má rozhodovat, ale je to rozhodně součást, že jo, tak kvantitativní nějaká kvalitativní složka. Tak ty lidi cítí, že ta data jsou důležitá, chtějí si s nimi hrát a právě proto je ten tým IT – to už jsem říkal –, tak jako velký, že ti lidé začnou tím, že si něco filtrují, pak začnou psát SQLka, tak zjistí, že se to dá dát jako do Gitu a že to je docela sranda a že s námi je sranda jako s datovým týmem a najednou zjistí, že už nejsou v nějakém týmu, ale jsou spíš takoví jako datáři a spíš jsou s námi a chtějí si upravovat modely a učit to ostatní, aby spíš byli takoví jako data champions a tak to nějak posouvat dál a to se nám stává docela často.

Tak to vám moc gratuluju, zní to jako hrozně pěkně a z tvého vyprávění mám taky chuť se přihlásit do Slidou a jít dělat do vašeho datového týmu.

Co vás teď čeká, začátek roku 2023, máte určitě velké plány s CISKem za zády, co pro tebe jsou priority toho roku?

My určitě chceme investovat teďka hodně do toho, abychom zas a znova byli připraveni na tu budoucnost. Takže my interně chceme v tom analytickém týmu si zase zajistit, že se nebudeme muset starat o nějaké zbytečné věci, které nám jenom přinášejí práci, konkrétně třeba s těmi metrikami, kterých jsem zmiňoval. To je takové velké, že chceme tam doladit to, abychom mnohem lépe udržovali, lépe si s nimi hráli, aby byly jednotné, a chceme to dobře propojit právě se SuperSetem, který pořád používáme od toho začátku až do dneška, mít tam nějaké lepší automatizace a obecně bychom chtěli, abychom měli co nejméně té manuální práce, protože ta automatizace tam je, ale není to úplně dotažené, takže takový až skoro jako data ops to trošičku je, a toho bychom se technicky chtěli zbavit, abychom mohli být připraveni na víceméně cokoliv, speciálně mám tam teď i nějaké větší interní analytické projekty a chtěli bychom, abychom na ně měli prostor a nemuseli se tam babrat s nějakými blbinami nebo chybami zbytečnými. A to je spíš tak vnitřně.

No a potom mám takovou druhou věc, kterou doufám, že se nám podaří během roku ještě víc rozvinout. Začali jsme loni a to je mnohem bližší spolupráce s komunitou kolem nás. Zase je to trochu inspirace od DBT, protože ona celá stojí hodně na komunitě a to je možná i její nejsilnější devíza. Řekl bych, že dokázala kolem sebe natáhnout velmi zajímavé lidi a mně to přijde hrozně sympatické. Říkal jsem si, že když to dokážou dělat oni na celosvětové úrovni, tak proč to nevyužít a nedělat něco podobného i v Česku, protože jsem zjistil – a to je taky pěkné, takové otvírání dveří –, protože to dělá málo lidí, je to pár takových bláznů, dneska už možná ani tolik ne, ale v době, kdy jsme začali, to bylo pár bláznů.

Když jsem zjistil, že v DBT v Brně používá už jen jeden člověk, tak jsme se s Michalem Dubravčíkem z Kentico – dnes už to není Kentico, dnes se to dělí na Kentico a Content AI – chodili spolu jen na pivo, protože nikdo jiný neexistoval. Pak jsme zjistili, že je pár lidí v Praze, a nakonec z toho vzniklo, že máme takovou malou DBT komunitu datovou, kde jsme dělali skrze i meetup právě s Product Boardem, dost se známe se STRV, kde se také používala DBT, tam je Josef, který teď dělá data science, ale je jinak nadšencem DBT. V Týpnotu taky mají hrozně rádi DBT, takže tam jsme také hodně blízcí a obecně i v Brně třeba teď Kiwi má rovněž svoje use cases, a Kiwi je navíc hodně na Slovensku, takže tím, že naše headquarters jsou v Bratislavě, máme k tomu taky blízko.

Takže nejenže máme nějaké DBT meetupy, kdy jsme byli na tom prvním pražském meetupu někde v září, ale jsme organizovali jeden i v Brně před Vánocemi. Zároveň děláme datové meetupy v Bratislavě, začali jsme právě s takovým komplexem a vlastně se poměřujeme s tím, co je kolem nás, ale fakt díváme se, jak se to dá dělat a říkáme si, že my to umíme dělat taky velmi zajímavě, ať už je to na Slovensku nebo v Česku, to je celkem jedno, ale můžeme dělat hezké věci, které nás baví a posouvat to dál.

A nejenže člověk jezdí na konference někam do Ameriky na QLS, což je Re:build konference, kde poslouchá všechny ty lidi ze zahraničí, ale i česká stopa tam je a je v Česku a na Slovensku.

Děkujeme, Michale, myslím si, že tě budeme rádi mít tady znovu, protože o tom mluvíš hrozně hezky a asi mluvím za sebe i za Karla, že to cítíme podobně. Že tady v Česku a na Slovensku je spousta know-how, hodně skvělých lidí, firem, obrovská hodnota, která je nevytěžená, ti lidé se málo potkávají, málo o tom píší, nemají kde, a to bereme i za takovou svoji roli a vizi – přinést sem prostor pro tyto debaty. Děkuju moc.

Přesně, Kéleme, jsem rád, že to vnímáte podobně. Jsem moc rád za tento podcast, za to, že ho děláte, a za to, že jste mě samozřejmě pozvali, ale to, že ho vůbec děláte, je podle mě velká přidaná hodnota pro celou komunitu, takže velký dík za všechny.

Já taky díky, těším se na DBT konferenci.

Tak jo, budu se těšit. Čau.

Čau.

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

A pokud se vám tato epizoda líbila, doporučte ji prosím dál. Klikněte na srdíčka, na hvězdičky, dávejte subscriby, ať nám svítí dashboardy zeleně, křivky dělají hokejku a všichni stakeholderi schvalují extra budget.

Ještě jednou vám děkuju. Poděkování patří také mým kolegům, Nikovi a Iris, stejně jako členům našeho partnerského klubu – BigHubu, Deep Note, Atakamně a Mantě.

Pokud máte návrh, nějaké tipy na hosty, 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.