Podcast

Dobrý den, mé jméno je Jirka Vicherek.

Ahoj všem, jmenuji se Barbara Hinerová a vítáme vás u nového dílu podcastu Data Talk. Naším dnešním hostem je Sam Kožuch, datový inženýr z firmy Vortex. Ahoj.

Ahoj, Sam.

Ahoj.

Tématem dnešního dílu bude Google Cloud Platform neboli GCP, a jak v něm dělat data engineering, co se v něm všechno děje a jak se GCP stává velmi pokročilým datovým nástrojem.

Nejdříve si pojďme projít tvou velmi zajímavou cestu k datům, datům až do Vortexu. Jak to u tebe všechno začalo, Sam?

Sam: Možná se vrátím na chvíli do školy, pokud můžeme. Já jsem začal studiem ekonomie, takže s daty jsem zpočátku neměl absolutně nic společného. Po dvou letech jsem si uvědomil, že ekonomie není pro mě a že bych chtěl dělat něco jiného. Na škole jsme měli kurz Data in R, kde jsme dělali ekonometrické modely a podobné věci. Tak nějak mě data začala fascinovat. Dokončil jsem bakalářské studium a pokračoval ve škole v Amsterdamu, kde jsem studoval aplikovanou statistiku.

Potom jsem si uvědomil, že další věcí, kterou chci opravdu dělat, jsou data. Následně jsem se dostal do firmy Keboola přes kamaráda, který tam také nastoupil po škole. Hned poté, co jsem dokončil studium v Amsterdamu, jsem nastoupil do Kebooly.

Kdy to bylo?

Sam: Bylo to v roce 2018. Konkrétně jsme začínali v Londýně, kde tehdy fungovala kancelář, která se rozběhla. Oba jsme nastoupili do Londýna. Tehdy to byla relativně malá kancelář, asi deset lidí, kde jsme pracovali na různých klientech, a to nejen londýnských, ale i českých. V Keboolě jsem strávil tři roky, byl jsem dokonce i v Kanadě a pak zpátky v Praze.

Pro mě byla Keboola opravdu skvělá zkušenost. Kromě toho, že jsem tam poznal výborné lidi, například parťáky Pavla a Fíšu, který tam tehdy opravdu hodně pomohl a něčemu mě naučil. Fíša je fakt nekonečná studnice informací, ví úplně všechno, je to pán. Fíša nás vždy motivoval k tomu, abychom se vzdělávali, četli články a podobně. Já jsem to však nikdy úplně neocenil, až do chvíle, kdy jsem Keboolu opustil. Teprve tehdy si člověk přesně uvědomí, co je pro něj nejdůležitější.

Ještě než jsi Keboolu opustil, jaká byla tam náplň tvé práce? Byl jsi více u klienta, když jsi takhle cestoval po světě, nebo jsi pracoval spíš interně? Byl to vlastně consulting, data consulting, stavění datových pipeline na Keboolě?

Sam: Co se týče cestování, tak to bylo jen proto, že jsem chtěl půl roku pracovat v Vancouveru, takže jsem tam zašel za Fíšou a tam půl roku pracoval, pak jsem se vrátil do Prahy, protože mi skončila víza a nechtěl jsem to řešit dál. Jinak šlo o čistě konzultantskou práci, tedy jakýsi návrh architektury datových řešení, optimalizaci a podobně. Bylo to typické pro Keboolu.

Jaký jsi používal toolset a skillset? Vše se dělalo v Keboolě? Dnes jsi data inženýr, tak…?

Sam: Ano, primárně v Keboolě. Používali jsme Keboolu, samozřejmě SQL, Python. Keboola běží na Snowflake, nebo tehdy ještě běžela pouze na Snowflake, takže jsme používali Snowflake, Python a podobně. Měl jsem i přesah do AWS, například S3, Lambda, Redshift a další, ale primárně šlo o konzultace na Keboolu a stavbu pipeline. To byl ten hlavní toolkit tenkrát.

Už jsi během té doby začal pracovat i s cloudovými službami?

Sam: Ano, už jsme trochu řešili AWS. Nebyla to však úplně full cloud zkušenost. Tu plnou jsem získal až v další práci, a to v irské firmě jménem eShop World, dnes jen ESW.

Možná byste měli říci, že jde o retailovou firmu, která dělá e-shopy.

Ano, je to tak. V té firmě je obrovské množství dat, velmi zajímavých dat. Mezi klienty jsou světové značky, které spolupracují s eShop Worldem, takže kdykoliv tam byli, byla to fakt super zkušenost.

Právě tam jsem poprvé pracoval s Google Cloudem, protože celá firma běžela na Google Cloud Platform. Datový stack byl na Google Cloudu, protože infrastruktura běžela na Azure, šlo tedy o multi-cloud prostředí. Takže jsme řešili například propojení těchto cloudů a to, jak dostávat data z Azure do GCP a podobně.

Přechod na cloud probíhal hladce, nebylo to nic těžkého. Asi pomohly i mé zkušenosti s AWS a obecná příprava, například četba článků.

Jo, články od píši.

Ano, přesně tak. Myslím, že Keboola byla velmi dobrou přípravkou na různé use case, komunikaci se zkušenými klienty a řešení různých problémů. To všechno velmi pomohlo při přechodu na cloud.

A jaká byla tvá role v eShop Worldu? Byl jsi v Irsku, nebo jsi pracoval na dálku?

Já jsem byl full remote, pracoval jsem z domova. Moje role byla datový inženýr, takže jsem se hodně věnoval designování a programování datových pipeline.

Co mě tam překvapilo byla nevyspělost datového stacku. Pro kontext, firma měla asi tisíc zaměstnanců, ale datový stack vypadal, jako by šlo o malou firmu s pár stovkami lidí. V týmu jsme byli tři lidé. Většinou tam nebyl pocit, že datový tým je součástí hlavního týmu, spíš to bylo „nice to have“ než nezbytnost. Datový tým byl často „afterthought“.

Často jsme byli závislí na jiných softwarových týmech, které dělaly vývoj aplikací a mnohdy něco „rozbily“, kvůli čemuž nám „padla“ pipeline, ale nikoho to nezajímalo, protože jsme byli malý tým, který v té době nic neřešil.

No a k tomu full remote, občas se člověk při schůzkách musel hlásit přes mikrofon, aby byl slyšet.

Byla to určitě zajímavá zkušenost. Rok jsem s tím bojoval, ale po roce přišel nový CTO, který byl velmi orientovaný na data. Do té doby datový stack nebyl nic moc, ale pak začal trochu evolvovat. Začali jsme hledat datové vědce, protože předtím jsme měli pouze jednoho datového vědce na celou firmu, což je podle mě velmi málo.

Začaly vznikat datově vědecké use case a data začala být konečně vnímána jako produkt firmy, který je must-have. C-level manažeři si začali dělat dashboardy a začali dělat rozhodnutí založená na datech.

To bylo tedy v roce…?

Sam: 2022. To mě opravdu překvapilo, že se ještě v roce 2022 taková situace může stát.

Jo, pro někoho, kdo pochází z irské datové firmy, kde jsou věci velmi pokročilé, by to mohla být šokující zkušenost.

Po roce 2023 jsem si udělal certifikaci na GCP Data Engineera a hned v ten samý den mě kontaktoval Tomáš Papeš z Vortexu, nyní můj CTO, který mě požádal, zda bych nechtěl nastoupit k němu. Vysvětlil mi, co Vortex dělá a že potřebují datového experta, aby se firma mohla více zaměřit na data, protože zatím se soustředili pouze na infrastrukturu.

Já jsem po dvou letech v eShop Worldu už nebyl spokojený, protože to bylo moc korporátní a řešil jsem například čekání tři měsíce na servis kvůli bezpečnosti. Rozhodl jsem se tedy zkusit něco nového.

Na konci roku 2023 jsem odešel z eShop Worldu a začal ve Vortexu.

Tak co je Vortex?

Jsme Google Partner, zatím malá firma, jeden rok stará. Nedávno jsme se stali Premier Partnerem, což je skvělý úspěch za tak krátkou dobu.

Naším zaměřením je konzultování na GCP, tedy poradenství ohledně infrastruktury, stavbu datových skladů, lakehousů, výběr správných produktů a v současnosti i chatboty, AI a podobné věci.

To, že jste Premier Partner za rok, je opravdu úspěch, gratuluji!

Díky. S mým příchodem se rozšířila nabídka služeb Vortexu právě směrem k datům.

Před mým nástupem jsme se zaměřovali primárně na infrastrukturu, jako je GKE, jaké servery použít a podobně. Za tímto stál Tomáš Papeš, náš CTO, který už dříve pracoval ve firmách Kiwi a Spaceflow, kde toto dělal.

Mě nabídka Vortexu oslovila, protože jsem zde první datový člověk a tým se tak může více věnovat datovým produktům v GCP – datovým skladům, lakehousům, AI, strojovému učení a podobně.

Po nástupu jsem hned začal pracovat na projektu, kde jsme začali dělat datovou analytiku pro klienta.

Jsi fakt hodně zaneprázdněný.

Ano, od začátku jsem byl hodně zaměstnaný. Tomáš mi od začátku říkal, že už máme klienta a začínáme pracovat 2. ledna. Kdybych nenastoupil, bylo by to hodně špatné, potřebovali mě už včera.

Kolik lidí je nás teď ve firmě?

Jsme momentálně osm lidí. Jsme malá firma, jeden rok stará, ale rosteme a právě najímáme nové lidi, abychom rozšířili naši nabídku služeb.

Takže hledáš kamarády do týmu na data?

Samozřejmě, pokud by někdo měl zájem o práci na Looker vizualizacích a podobně, rád přivítám nové kolegy.

Podívejme se na klienty nebo typické use case, které řešíte. Je to spíš správa infrastruktury, nastavení GKE, správný výběr serverů, nebo už i nasazování datových řešení?

Sam: Klienti často přicházejí s konkrétními otázkami nebo žádají optimalizaci nákladů, případně mají specifický use case a chtějí vymyslet odpovídající infrastrukturu.

Co se týče dat, máme klienty z různých segmentů – startupy, SMB firmy jako například finanční startupy nebo blockchainové projekty. Tito klienti často přicházejí s daty, ale sami nic nevidí, neznají například chování svých uživatelů, nevidí využití svých produktů. Chtějí znát svého zákazníka lépe, vědět, jak se používá jejich platforma. Potřebují poradit, jak nejlépe postavit datové řešení a jaké jsou současné trendy, protože nemají žádného odborníka na data.

Předpokládám, že oproti jiným cloudovým partnerům jdete více do…

Sam: Ano, primárně jsou to softwarové jako SaaS firmy. Většina našich zákazníků už je na GCP, není to transformace z vlastních serverů do cloudu. Nicméně máme i klienty, kteří nejsou na Google Cloudu vůbec, například provozují vlastní hardwarovou infrastrukturu (bare metal) a teprve začínají s nasazením do cloudu. Součástí těchto dealů je obvykle migrace datových skladů i infrastruktury.

Máme také zákazníky, kteří jsou s cloudem velmi pokročilí, mají třeba multi-cloud nastavení, jsou na GCP velmi zkušení. My jim pomáháme s datovou částí, protože s infrastrukturou si umí poradit velmi dobře, ale data jsou pro ně často takové „kryptonit“. Takže máme klienty ze všech oblastí.

Nakonec rozdíl není až tak velký. Pokud se klient rozhodne jít do cloudu, vidí v něm super platformu, kde má všechno na jednom místě, nemusí se starat o vlastní servery a podobné věci.

Zatím jsem nezažil klienta, který by po migraci do cloudu chtěl z nějakého důvodu vrátit zpět staré řešení. Cloud je jednodušší a není potřeba řešit vlastní provoz serverů nebo datových skladů.

Super.

A teď se podíváme na tvou denní práci a specializaci. Jsem klient, který už má v GCP investovanou infrastrukturu a software engineering, a teď chci začít s datovou analýzou, nebo dokonce s AI, protože Google tvrdí, že to tam je. Jaké jsou první kroky, na které se díváš? Jak vypadá teď landscape?

Sam: Před třemi lety to bylo složitější. Bylo více produktů pro budování datových skladů, lakehousů, AI nebo ML.

Nyní je to mnohem jednodušší. Google začal opravdu tlačit BigQuery jako jednu platformu pro všechno. BigQuery slouží jako datový sklad, lakehouse, podporuje neštrukturovaná, semistrukturovaná data a stále je neskutečně rychlý pro analytické úlohy.

Navíc se dá kombinovat s Google Cloud Storage pro neštrukturovaná data.

V poslední době je zde obrovský push na strojové učení. Současně se Snowflake začal podporovat ML, tak začalo i BigQuery.

Dříve to byly jednoduché lineární regrese a jednoduché modely, dnes je možné přímo napojení BigQuery na Gemini. Ať už přes UI nebo automaticky, Gemini umí pracovat s BigQuery daty, analyzovat je, navrhnout aktualizace dat, dát jednoduchý přehled o tom, co se v datech děje.

BigQuery nedávno také začalo podporovat…

Aj iné jazyky. Nie je to už čisto iba SQL, teraz tam sú napríklad Jupyter notebooky, ktoré sú napríklad práve pre data scientistov super. Dá sa v tom robiť práve ten machine learning, napojiť sa priamo na tie dáta v BigQuery. Je tam aj jedna super knižnica, ktorá sa volá BigFrames, ktorú by mohli data scientisti oceniť.

A práve pre tých data scientistov tie dáta vlastne nikdy neopúšťajú BigQuery, ten tréning vlastne takisto prebieha v BigQuery. Vie robiť aj predikcie, vie vlastne robiť aj vyhodnotenia a tie notebooky sú tým pádom, že sú určené pre data scientistov, veľmi jednoduchým spôsobom na uvedenie modelov do praxe. To áno, ale data science asi nezačínaš hneď, asi to nie je ten prvý, alebo to nie je ten prípad, že chceme AI, tak nám postavte Data Warehouse alebo Lakehouse.

Samozrejme, data science sa nezačína tým, ale začína sa tým, že sa postaví nejaký Data Warehouse alebo Lakehouse, čo v podstate znamená zosumarizovať tie dáta alebo mať ich na jednom mieste. To som skôr len spomenul ako jednu z funkcií, prečo vlastne BigQuery je tak skvelý nástroj, ak to tak môžem nazvať, alebo prečo je to… Ste Google partner, samozrejme.

Áno, musím to trochu promovovať. No, prečo je to práve ten nástroj, ktorý chcete využiť na Data Warehouse, na to, aby ste dostali dáta na jedno miesto? Chcem to využiť. Už som váš, máme dohodnuté ľudské hodiny, rozpočet a všetko.

Tak čo sú tie prvé kroky? Dostať dáta. Dostať dáta z rôznych zdrojov, vlastne definovať si, čo chceme vidieť, čo chceme postaviť. Dostať dáta do BigQuery. Tu záleží na tom, aké sú dátové zdroje. Možno tu môžem spomenúť, že konektivita BigQuery na third-party zdroje alebo Google Cloud všeobecne je trochu obmedzená.

Tu sa dá pekne využiť napríklad Keboola. Keboola má, myslím, 600 – 700 konektorov na rôzne zdroje. Videli sme to už u klientov, že používajú Keboolu ako extraktor v podstate. Tie dáta jednoducho ťahajú zo všetkých zdrojov a potom ich buď pustia rovno do BigQuery alebo do nejakého Warehouse, kde už sa robí všetko ostatné, alebo niekedy začnú robiť analýzy v Kebooli a do BigQuery pustia už len transformované dáta, kde robia AI a ML.

Keboola ako ETL nástroj by Fíša určite nepovolil.

Presne. Prečo nie? Ako dátová platforma.

No tak Data Operations, áno. V podstate, ak to teraz porovnáme, myslím si, že BigQuery sa snaží prezentovať podobne ako Keboola, ako jeden nástroj na všetko, že sa dá… Rovnako ako Snowflake.

Presne tak, podobne ako Snowflake. Myslím si, že to je teraz trend všetkých cloudových služieb vyzerať takto. Je to myslím primárne kvôli tomu, aby prilákali veľkých zákazníkov, pretože pre biznis zdroje je veľmi lákavé vidieť jeden nástroj, ktorý slúži na všetko.

Vidíte to vlastne cez doláre v ich očiach, vidia jednu super platformu, ktorá to dokáže. Takže tak, no.

S tým nalievaním dát sú tam nejaké problémy okrem konektivity? Sú tam nejaké zvláštnosti, nejaké špecifiká, ktoré fungujú inak na GCP, lepšie, alebo na Snowflake?

Alebo keď povieš Snowflake versus BigQuery versus Keboola, je to už tak štandardizované, že ak máš architektúru nebo zámer, tak to, ako sa k tomu dostať, je veľmi podobné? Nejaké špecifiká tam asi nie sú?

Myslím si, že je to skôr iný prístup. Keboola, samozrejme, ak máte konektory na mieru, často stačí zadať API token, API kľúč, nakliknúť to, spustiť extraktor a máte to tam.

Google Cloud niekedy takéto extraktory, hlavne na menšie služby, nemá. Často treba niečo napísať vlastné, mať to ako výnimku alebo využiť napríklad Dataflow, čo je vlastne hostovaný Apache Beam, kde sa dá pripojiť, alebo exportovať do Cloud Storage a z toho sa to dostať do BigQuery.

Myslím si, že Snowflake má prístup niekde medzi. Pri Google Cloud je to momentálne tak, že niekedy chýbajú extraktory a treba si to napísať sám. Neplatí to pre všetko. Napríklad napojenie na Google služby je perfektné.

Či už hovoríme o Analytics, kde sa dáta streamujú priamo do BigQuery a je to skoro vendor lock-in, lebo nie je iný spôsob, ako tie dáta dostať, než ich priamo streamovať do BigQuery. Či už ide o YouTube dáta a podobne, to všetko je na Google veľmi dobre vyriešené.

Ale keď sa ide inam, napríklad na Amplitude alebo iné produktové platformy, konektivita už nie je taká dobrá. Tam musia robiť workarounds alebo písať vlastné konektory.

A máte tam dominantné použitia práve v marketingu, e-commerce, Internet of Things, online?

Na Google Cloud?

Asi by si nepostavil BigQuery sklad len tak. Primárne by som v BigQuery stále robil analytiku. Určite marketingové use case a reportingové use case sú na to fakt skvelé. BigQuery je na to perfektný.

Stále to však nie je transakčná databáza. Nie je to náhrada za SQL Server, MySQL alebo podobné. Stále je to primárne analytics first, všetko ostatné je až sekundárne. Alebo analytics a AI/ML first. Dnes je totiž všetko AI first. AI je teraz.

No dobre, tak som nalial dáta, a tým to asi nekončí.

To určite nie. Tak čo sa deje potom?

Potom začína tá zábava. Vlastne, pre mňa tá fun part. Hrabanie sa v tých dátach, čistenie dát, prepájanie s dátami firmy. Tam sa stále používa BigQuery.

Samozrejme, treba to nejak zorchestrovať. Potom potrebujeme ďalší servis.

BigQuery má niečo, čo podporuje orchestráciu samo. Scheduled queries, ale nie je to tak silné ako napríklad Cloud Composer, čo je Airflow.

Takže keď sa tvoria transformácie, druhý krok je napísať tie transformácie a tretí krok ich zorchestrovať.

BigQuery samo o sebe nemá veľmi dobrú funkcionalitu na definovanie postupnosti query. To treba riešiť v Composer alebo iných third-party nástrojoch, ktoré query spustia na BigQuery.

Predpokladám, že už je to hostované v GCP, zabalené.

Presne tak. Airflow je full managed, vlastný Composer, nespravujete nič, len stlačíte tlačidlo, je to všetko napojené na VPC, máte tam permissions a je to krásne prepojené.

Samozrejme, nemusíte riešiť permissions, pokiaľ nechcete, ale defaultne má prístup na BigQuery, takže má prístup k dátam. A máte to na tej istej faktúre.

Pokiaľ by ste nakupovali od jedného dodávateľa, takže tak.

Takže primárne využitie Composer je orchestrace.

Keď už máte scheduled a robíte nad tým svoju magiu, sú nejaké best practices na to, ako to robiť správne, ekonomicky a efektívne?

Áno, určite. Každý nástroj má best practices – do's and don'ts, aby náklady neboli astronomické.

Napríklad používanie partitioningu na BigQuery.

Raz som zažil, že môj manažér postavil query, ktoré bežalo celý rok bez partitioningu, a každý hodinový beh spotreboval asi 5 TB dát.

Pre porovnanie, 1 TB stojí na Google Cloud cca 6 dolárov, takže každý deň boli náklady približne 600 – 700 dolárov.

Takto to vyšlo na vysokú faktúru za rok.

Query však fungovala, fungovala perfektne.

Potom sme to optimalizovali a náklady klesli zhruba na desatinu.

A k dispozícii sú aj add-ony na úrovni query, či už na optimalizáciu pomocou clever designu query, ako napríklad predpočítanie joinov, nenormalizované tabuľky, ktoré sú v kolonárnom engine výhodou.

Joiny síce efektívne fungujú v BigQuery, ale v produkcii by som sa nespoliehal na ťažké joiny a radšej by som si dáta predpočítal a mal pripravené tabuľky pre vizualizáciu v Looker alebo inej BI platforme.

Na to BigQuery poskytuje super guidance – pri písaní query v UI vždy ukáže, koľko dát query spotrebovala, ako prebehlo shuffle, prepočty a pod.

Plus graf, ako query vyzerá.

Čiže pri optimalizácii sa trebárs pozrieť, čo query hovorí o spotrebe, kde je problém, prečo spotrebuje toľko dát.

To sú best practices pre SQL a transformácie.

Keď prídeš k hotovému, čo hľadáš? Kde sú najčastejšie chyby alebo problémy?

Väčšinou ide o query level chyby, napríklad nesprávny partitioning, alebo selectovanie stĺpcov, ktoré netreba.

BigQuery pomáha len enumerateovať tie stĺpce, ktoré sa skutočne používajú, takže čím menej stĺpcov je v selecte, tým menej sa spotrebuje dát a tým rýchlejšie to beží.

Samozrejme, BigQuery je veľmi rýchle.

Jeden z dôvodov, že sme si nikdy nevšimli, že query spotrebovala 600 dolárov denne, je práve ten, že to trvalo len 10 sekúnd.

Keby to trvalo dlho, bolo by to podozrivé.

Ale práve to, že je BigQuery rýchle, znamená, že na to treba dávať pozor.

Nie je ťažké napísať zlú query ani takú, ktorá denne spotrebuje 600 dolárov.

Je to úplne jednoduché.

Na akej úrovni to sleduješ? Predpokladám, že máte monitoring a kontrolu spotreby.

Áno, Google Cloud má full FinOps.

Dá sa spraviť billing export, ktorý dáte do BigQuery, kde sú surové dáta.

Čo sa týka každej query, tá vytvorí job, ktorý obsahuje detaily o tom, koľko dát spotreboval a podobne.

Na základe toho existujú tabuľky, na ktoré sa dajú vytvárať alerty a následne aj analytika.

Bežne máme alerty, ktoré monitorujú náklady.

Napríklad ak query presiahne 100% dnešnej spotreby voči priemeru za posledný mesiac, pošle sa upozornenie.

Optimalizujeme náklady a máme na to alerty.

Čo s kvalitou dát? Máš na to best practices?

Riešite data quality?

Riešime. Je to od zákazníka k zákazníkovi. Niektorí si to riešia, iných to absolútne nezaujíma.

Začnú to riešiť až pri zapojení machine learningu.

Zažil som prípady, keď to bolo postavené fakt skvele a data quality nebola problém, napríklad primárne kľúče boli vždy unikátne.

Ale aj prípady, keď nebolo postavené dobre a vznikali problémy.

Data quality sa rieši po transformácii, napríklad či čísla dávajú zmysel, či nemáme duplicitné kľúče, alebo null hodnoty.

To by mohlo totiž robiť chaos vo vizuálnej vrstve.

Vo vizuálnej vrstve to môže robiť veľký problém, pretože manažér sa na to pozrie a povie, že to nedáva zmysel a nikdy im nespoliehajú na také dáta.

Prvý dojem z dát je dôležitý.

Ak uvidia chybu, okamžite strácajú dôveru a neveria ani reportom, ani automatickým e-mailom s reportom.

Takže data quality určite treba riešiť.

Čo sa týka vizualizačnej vrstvy, musím používať Looker? Je to jasná voľba?

Není to nevyhnutne pravda.

Myslím, že je veľmi dobrá voľba, Google má Premier partnera na Looker, ale môžete používať čo chcete.

Looker je asi najlepší po vizuálnej stránke.

Čo sa týka funkcií, všetky majú podobné možnosti.

Každý si musí vybrať, čo mu najviac vyhovuje.

Looker nie je viazaný len na BigQuery, dá sa napojiť na Power BI, Tableau, GoodData alebo open source Metabase.

Nie je pravda, že keď sme na GCP, musíme používať Looker.

Je tiež free alternatíva Lookeru, ktorá sa volá Looker Studio, predtým Data Studio.

V rámci namingovej politiky je tam chaos, pretože sú tam Looker, Looker Studio Pro a Looker Studio.

Je to free nástroj a na to, že je zadarmo, je dobrý.

Môžete si tam vytvoriť niečo, ale pre zložité metriky to nie je ideálne.

Ak sa metriky počítajú v BigQuery a Looker Studio sa používa len ako vizualizačná vrstva, potom netreba veľa.

Aký je prístup Lookeru, keď hovoríš o rôznych vizualizačných prístupoch? Je vidieť, že Looker a Looker Pro sú akvizícia iných firiem a že sa ešte plne neintegrovali do Google, alebo už je to úplne googlovský, seamless prístup?

Povedal by som, že Looker Studio Pro a Looker Studio sú typicky googlovské.

Looker zatiaľ nie úplne.

Keď kúpili Looker, nebola to googlovská firma, a prístup je úplne iný.

Každopádne feature set Lookeru Pro je veľmi dobrý, či už čo sa týka modelovania, počítania metrik alebo semantickej vrstvy pre užívateľov.

Uživatelé už vědí, jak používat Explore. A mnoho funkcí, které jsou ve full verzi Lookeru, si Google půjčil a implementoval je například do Looker Studia. Třeba právě Explore, jak jsem zmínil, což je prostředí, kde si business uživatelé připravují data, vloží si tam nějakou tabulku a sami si dokážou postavit vlastní report. To je něco, co Google převzal od plnohodnotného Lookeru a začlenil do Looker Studia.

V jakém případě zvolíte který produkt? Jaký je váš rozhodovací strom? Je to do značné míry záležitost rozpočtu. Looker je samozřejmě prémiová platforma, která je adekvátně naceněná, zatímco Looker Studio je zdarma, respektive stojí 9 dolarů na uživatele. Takže záleží na velikosti týmu, na rozpočtu i na konkrétním použití.

Řekněme, když chceme dělat jen velmi jednoduchou analýzu, Looker Studio je zcela dostačující. Pokud chceme embedovat naše dashboardy do vlastního portálu a mít kontrolu nad tím, co uživatel vidí, například na úrovni atributů a podobně, začal bych se zajímat o Looker Studio a Looker. Samozřejmě to závisí na firmě. Některé firmy jsou ochotné platit za plnohodnotný Looker, ale v Česku jich zatím mnoho není. Většinou spíše směřují ke Looker Studiu nebo k Power BI, případně třeba GoodData.

Myslím, že vizualizaci nemusíme rozebírat příliš do detailů. Záleží na vašem konkrétním použití a rozpočtu, pak si jednoduše vyberete, co vám vyhovuje.

Minulý týden, tedy alespoň od doby našeho natáčení, proběhl Google Next a tam jste se jistě dozvěděli spoustu novinek, zejména v oblasti umělé inteligence. Co je budoucností cloudu a proč je to právě AI?

Přesně tak. Možná by mě zajímalo začít na té cestě od začátku – jak nahráváte data, transformujete je, čistíte a vizualizujete. A jak to nyní všechno budete dělat s pomocí AI?

Já jsem AI adopter už delší dobu, využíval jsem ji jako pilot už dlouho. Myslím si, že co se týče data engineeringu vůbec, je to skvělá věc, pomáhá například i s best practices, při psaní dotazů, nebo i při psaní Python kódu.

Co se týče Google Next, jak jste říkali, hlavním zaměřením Google je AI. S Tomášem Papežem jsme si na menší sázce spočítali, kolikrát zazní výraz AI během prvních pěti minut opening keynote. Bylo to tak časté, že jsem po deseti minutách ztratil přehled, protože toho bylo opravdu hodně. Kdo by zvládl BigQuery na dopočet?

Přesně tak, potřebovali bychom tlačítko, které bychom mohli zmáčknout a počítat takto.

Budoucností u Google je tedy jednoznačně AI a její integrace do datových produktů, zejména pak do BigQuery, Composeru, notebooků a dalších nástrojů.

Jak jsme si říkali, Google během posledního roku integroval AI do celé své platformy. Dříve to bylo Duet, nyní přejmenované na Gemini. AI pomáhá například s návrhy dotazů přímo v BigQuery, nebo při nastavování bezpečnostních pravidel – tam teď funguje Duet AI, respektive Gemini v oblasti bezpečnosti.

Toto zaměření je stále více propojené právě s BigQuery a celým datovým ekosystémem.

První oznámenou funkcí je, že je možné připojit data z BigQuery přímo do Gemini za účelem generování textu. Například máte sloupec v tabulce, vložíte ho do Gemini a generujete text. Vše probíhá přímo v BigQuery.

Jde například o marketingové účely. Můžete vytvářet popisky LinkedIn příspěvků nebo marketingové kampaně přímo ze sloupce.

Takže zadáte sloupec, který obsahuje mnoho dat, a Gemini vám z těchto dat vytvoří textový přehled. Nebo máte kampaň, název, tagy, a Gemini vám vygeneruje popisek kampaně.

Možná se to bude týkat spíše základní strategie, nejsem si jistý, jestli jsme už natolik daleko, aby to správně chápalo strategii.

Gemini také umí dělat datovou analýzu – vkládáte data, ona vám vyprodukuje čísla, pár vět o tom, co se v datech stalo apod.

Tato funkce je implementována i v Lookeru. Looker dlouhou dobu neměl žádnou integraci s Gemini nebo s nějakým chatbotem či LLM modelem, nyní se to změnilo. Looker už začíná fungovat na základě přirozeného jazyka: položíte otázku, on vám dá graf, vysvětlí, jak k němu došel.

To je právě Explore, o kterém jsem mluvil.

Kromě analýzy pomocí Gemini Google také nedávno představil funkci zvanou Data Canvas. Představte si ji jako editor nebo IDE, kdy místo lineárního psaní dotazů SQL tvoříte „brain mapu“, myšlenkovou mapu, která zobrazuje, jak dotazy píšete, a vše ovládáte pomocí jazyka.

Otevřete si BigQuery, spustíte canvas, zadáte, že chcete vidět určitá data, napíšete to do textového pole, a on vám dotaz vytvoří, spustí a zobrazí data.

Funkce je zatím v preview, já ji zatím nepoužívám, oznámili ji teprve před týdnem, ale myslím si, že to bude skvělá funkce pro datovou exploraci.

Často se mi stává, že když debuguji data, mám lineární textový soubor s SQL dotazy, kde postupně něco mažu nebo se nedokážu orientovat, jak jsem přešel z jednoho kroku na druhý.

Tvorba canvasu jako brain mapy bude výrazně jednodušší pro sledování těchto kroků.

Nejdřív jsem si myslel, že je to spíš gimik, ale po zamyšlení jsem přišel na to, že je to opravdu užitečné.

Ať už na debugování, nebo i pro uživatele, kteří nemusí být SQL experti, analýza pomocí přirozeného jazyka pro ně bude jednodušší.

Takže ta funkcionalita vytváří nějakou lineáž dat? V podstatě hledá vztahy mezi daty, mezi různými zdroji?

Spíše hledá vztahy mezi tím, co do toho dáte.

Například chcete vidět objednávky určitého uživatele, otevře se okno, kde uvidíte, že tento uživatel měl v březnu určitou spotřebu, a vedle toho se napojí další okno spojené s touto informací.

Vytvoří se mezi nimi „link“ a systém zpracuje data z předchozího okna a budete moci filtrovat například jen na březen a daného uživatele.

Je to tedy vizuální propojení.

Je to vhodné pro nějaký konkrétní případ, pokud chci třeba pracovat s jedním uživatelem.

Co když ale chci vytvářet klasický finanční dashboard pro firmu?

Je to spíše zaměřené na exploraci a debugging, ne na samotný reporting.

Na ten už slouží například Gemini nebo Gemini integrované přímo do BigQuery, kde můžete zadat požadavek typu „napiš mi dotaz, který udělá to a to“ a dostanete výsledný SQL zápis, který pak můžete deployovat nebo naplánovat.

Je to něco jiného, ale je těžké to popsat bez vizuální ukázky.

Canvas bych přirovnal k ThoughtSpot – jde o brain mapu pro debugging a exploraci dat.

Co se týče AI vylepšení, jak jsem říkal o noteboocích, BigQuery už dnes slouží jako AI datová platforma. Notebooky se dají propojit přímo s Vertexem, což je AI platforma Google na GCP.

Nezaměňovat s „Vortexem“, což se stalo několikrát, že klienti pletli název Vertex a říkali Vortex.

Google se soustředí na propojení BigQuery s Vertexem, který slouží pro monitoring, evaluaci, trénink modelů a další funkce.

Dřív jste museli rovnou pracovat ve Vertexu, teď to můžete dělat přímo v BigQuery.

Přešli jsme tedy z AI podporovaného data engineeringu na GCP k samotnému vytváření AI.

Je rozdíl mezi Gemini a Vertexem?

Ne, spíše jsem chtěl říct, jak jsou BigQuery a AI propojeny. Dříve bylo nutné data exportovat z BigQuery, nyní se přímo připojíte k Vertexu z BigQuery, například přes notebook a využíváte Python kód přímo v BigQuery.

A co je tedy Vertex? Je to AI platforma, která slouží například k deployování modelů nebo ke správě verzí.

Pokud máte model vytvořený v BigQuery, objeví se ve Vertexu, kde ho můžete deployovat na API endpoint pro online predikce.

To dříve nebylo jednoduché, spojení mezi BigQuery a Vertexem chybělo.

Očekáváš, že BigQuery „spolkne“ Vertex?

Říkáš, že BigQuery je datová platforma a zároveň AI platforma, proto může dojít ke konsolidaci, nebo jsou to dva samostatné produkty fungující bez problémů vedle sebe?

Myslím si, že je to možné. Google často produkty přejmenovává, konsoliduje a spojuje.

Momentálně je ale BigQuery primárně analytický a AI nástroj, zatímco Vertex je zaměřen na machine learning a AI na vyšší úrovni.

Nemyslím si, že k úplnému spojení dojde hned, možná v budoucnu.

Vertex má stále funkce, které BigQuery nemá, například stavbu chatbotů nebo fine-tuning LLM modelů.

To je něco, co ve BigQuery nejde.

BigQuery má některé AI funkce, ale ty pokročilé jsou ve Vertexu.

Takže bych řekl, že pro jednodušší případy a business uživatele BigQuery zatím stačí.

S rostoucími požadavky na pokročilou AI a LLM modely bude nutné řešit Vertex AI.

I když propojení mezi BigQuery a Vertexem existuje, jsou tam extra funkce, jako je ladění parametrů a další.

Je tam také samostatné cenové nastavení u Vertexu?

Ano.

Takže konsolidace nemusí být úplná.

I když vše dostanete na jedné faktuře, pozice pro Vertex je viditelná.

Máte klienty, kterým zapojujete Vertex? Jaké mají use case?

Na začátku jsi zmiňoval, že už stavíte chatboty. Předpokládám, že to je jeden z hlavních use case pro Vertex.

Ano, je to například zákaznický support bot.

Máme zákazníka, který má data v Magentumu nebo Premyslu a chce využít BigQuery k postavení chatbotu, který bude pomáhat zákazníkům vybírat produkty z jejich webu, případně pomáhat s objednávkami, pokud mají problém, že objednávka nedorazila, a tak dále.

Má to velký potenciál, ale nastavení je poměrně komplikované.

Jak víme, chatboty často halucinují, což může být frustrující.

Pokud chatbot pomáhá zákazníkům vybírat produkty, může to ještě více frustraci způsobit, nebo to může představovat potenciální zdravotní riziko.

Třeba když klient prodává potraviny nebo doplňky stravy a zákazník se zeptá, zda produkt obsahuje alergeny, chatbot musí mít velmi přesnou a ověřenou informaci.

Musí tam být extra úroveň zabezpečení a verifikace dat.

Tento use case aktuálně řešíme.

Je to skvělý use case, ale i komplikovaný.

Je to pro nás zároveň významná zkušenost, protože AI chatboty jako pole jsou relativně nové, je to zhruba rok až rok a půl stará oblast.

Ne všichni jsou ochotni se do toho ponořit, ale máme štěstí, že máme zákazníka, který vidí potenciál a chce s námi v tomto rozvíjet.

Podíváme-li se na architekturu a best practices, o kterých jsi mluvil na začátku, mění se něco s příchodem AI éry?

Například zvyšuje se důležitost, aby měl model více kontextu, nebo naopak je klíčovější kvalita dat, aby si vybíral jen čisté, relevantní věci?

Je třeba jiný přístup v paradigmatech, pokud víte, že data budou použita pro strojové učení?

Myslím, že kvalita, čistota a správnost dat jsou stále velmi důležité.

Náš chatbot si například stahuje data přímo z BigQuery, pokud tam budou špatná nebo nesprávná data, třeba popisy produktů, tak se to samozřejmě projeví.

Není to vaše práce zajistit správnost dat, ale spíše práce klienta.

Nicméně záleží na správném nastavení procesů, aby popisy měly smysl a byly správné.

Musím přiznat, že co se týče stavby chatbotu, mám na starosti spíše datovou stránku, zatímco ostatní věci, jako grounding a další, řeší jiní, proto nemohu zodpovědně odpovědět na tuto část.

S příchodem AI funkcí, které Gemini nabízí, kdy vám například řekne, že váš dotaz není správně napsaný, navrhne best practices, vizualizuje, vytvoří konektor, dopíše Python skript, co ty osobně očekáváš, že nebudeš dělat za rok nebo dva?

A kde se budeš naopak muset více zaměřit?

Dobrá otázka. Jestli nás to nahradí, jsem stále na vážkách. Zatím se snažím zjistit různé případy použití…

Když se na něco zeptám, ať už na GPT nebo Gemini, není to stoprocentní. Člověk na tom pořád musí trochu přemýšlet, že? Přesně tak, člověk na tom stále musí přemýšlet. Není to tak, že prostě uděláme copy-paste a jedeme. Přesně tak.

Momentálně vnímám Gemini, GPT a podobné nástroje spíše jako parťáky, jako takové co-piloty. V určitých případech je to super. Ve své předchozí práci se mi podařilo napsat za pomoci AI, přesněji co-pilota, 130 testovacích případů za asi 6 hodin. Já jsem mu dal prompt a on to napsal za mě, já jsem to pak jen otestoval a opravil. Takže v takových případech jsou data inženýři v pohodě jako QAčka. Já musel testovat Python kód, a právě takhle to fungovalo.

Myslím si, že chatboty a AI budou tou nejlepší věcí, co mít. Už teď to dává určitý vhled, pomáhá nám to s psaním dotazů a podobně. Ale také si myslím, že ještě dlouho potrvá, než nás zcela nahradí. Často je tam lidský faktor a nejlepší praktiky pocházejí z nějakých praktických zkušeností, které chatboty zatím nemají. Takže je to spíše parťák, a myslím si, že ještě nějakou dobu parťák zůstane.

I když řešíme chatbota na support portálu, bude za tím stále nějaký lidský faktor, který bude sloužit jako druhá úroveň podpory, protože 100% se tomu nedá věřit. Bude tam nějaký data engineer, manažer AI nástrojů, přesně tak, master.

Když se podíváš na vývoj, jakým BigQuery, GCP platforma a celý ekosystém za poslední dobu prošli, jak to vidíš dál?

Mně přijde, že už jsme tu hodněkrát řešili moderní data stack. V našem rozhovoru jsme narazili na to, že kdysi nebo nedávno komplementární produkty, cloudové úložiště Snowflake a Keboola, jsou najednou v některých případech konkurenční, navzájem si berou hodnotu. Rozrůstají se a v některých use casech jsou přímými konkurenty, přestože předtím byly komplementárními produkty. Jak to vidíš ty? Bude to tak, že za pár let bude všechno v cloudu a…

…co tam nebude dostupné na dvě kliknutí, nebude existovat. Stejně jako u mobilních aplikací, kde máme App Store, tak neexistuje trh s aplikacemi pro iPhone, které by nešly přes ten App Store.

Jasně, myslím si, že nebude všechno v cloudu. Stále existují zastánci on-premise řešení, a to buď kvůli regulacím, nebo z toho důvodu, že to vědí lépe spravovat, přijde jim to lepší, lépe se to dá optimalizovat z hlediska nákladů. Dokonce jsem se setkal s názorem, že momentálně někteří zákazníci migrují zase z cloudu zpět na on-premise, protože je to pro ně levnější. S tím bych možná i souhlasil.

Náklady na cloud, pokud člověk neví, co dělá, nebo se v nich nevyzná, mohou být docela komplikované. A taky záleží na objemu dat, který máš – při určité velikosti už se vlastně pronájem může prodražit.

Přesně, nedává to smysl.

Napríklad vím, že věda řeší streamování 5 TB dat za sekundu nebo něco podobného, co by vlastně z cloudu nedávalo smysl kvůli síti, latenci a podobně. Tam je on-premise jediná možnost, řekněme jediná životaschopná varianta.

Myslím tedy, že nebude všechno v cloudu. Některé společnosti, pro které to dává smysl, do cloudu půjdou. Cloud přece jen stále více přitahuje zákazníky.

Dneska, upřímně, když založím vlastní firmu, vlastní startup a chci stavět nějakou infrastrukturu a pracovat s daty, tak jdu do cloudu. Je to jednoduché, škálovatelné. Go-to-market je prakticky okamžitý, nemusím se o nic starat. Zaplatím možná nějaké menší přirážky, když to umím dobře nastavit a optimalizovat a využít free tier, který cloudové služby nabízejí, lze to dobře rozjet bez zbytečných komplikací a nákladů.

A když už jsem v cloudu, tak je budoucnost multicloudu? Nebo bude všichni vendor locknuti?

Načež všichni budeme „na něčím píčku“.

Přesně, omlouvám se, zapomněl jsem na sponzora epizody. Myslím si, že určitě nebudeme všichni vendor locknutí u jednoho cloudu. Společnosti jsou často trochu paranoidní.

U nás například v e-shopovém prostředí, když jsme řešili změny, byla jistá paranoia z AWS, protože Amazon je také retailová společnost. Nechtěli to vůbec moc řešit, protože měli strach, že by jim mohli náhle zrušit infrastrukturu nebo toto.

Myslím si, že multicloud dává smysl pro větší firmy. Tam už asi dává smysl mít samostatný datový stack – ať už samostatný cloud na data, nebo například datovou platformu a operační systém dat, jako je Keboola.

Takže krátká odpověď – nemyslím si, že budeme vendor locknutí na jeden cloud. Bude to multicloud, bude to různorodé. Trh se stále vyvíjí, nové nástroje a služby vznikají. Bude to klasický trh, kde ten, kdo nabídne nejlepší funkce a cenu, získá nejvíc zákazníků.

Budeme to střídavě vidět – jednou byl nahoře Power BI, jednou někdo jiný, pak někdo nový. Je to vidět i u nás v Česku, kde Google Cloud před pěti lety prakticky neexistoval a teď na něm běží Alza, Rohlík a další – začíná to mít svou relevanci.

Takže myslím, že to bude nahoru-dolů a nebudeme vendor locknutí. To je dobrá zpráva.

Tak to mě těší. Já mám někdy temné myšlenky o budoucnosti a trochu se toho bojím. Na jednu stranu mě překvapuje, že cloud je v roce 2024 stále téma. Už to není jen hype.

Chodil jsem na cloudové akce před deseti, dvanácti lety a tehdy to byl hype. Teď je to „plateau of productivity“.

Vidíš to stejně, že? Já byl taky překvapený, že v roce 2022 je téma data warehouse stále aktuální. Je to dobré znamení, že to dospívá.

Ano, je to vidět v rámci gaussovy křivky.

Mám radost, že to nevidíš černě, co se týče vendor lock.

A co tě čeká v GCP v nejbližších měsících? Na co se můžeme těšit?

Navážu na to, co jsme vzpomínali minulý týden. Nedávno se konal Bullnext v Las Vegas, kde byla spousta nových funkcí. Něco podobného se bude konat i v Praze – Google Cloud Summit Praha. Je to akce organizovaná přímo Googlem, takže se tam budou prezentovat nové funkce.

Dozvíte se tam všechno, co jste slyšeli i dnes. S tím rozdílem, že některé funkce už budou nasazené v produkci a zákazníci s nimi budou mít zkušenosti.

Letošní termín je 12. června 2024, tedy červen.

Ano, přesně tak. Používáme překladové API pro tento rozhovor, můj „Gemini“. To je roztomilé.

Určitě tam budu, jsem „cancer“, cancer culture.

Možná to je správná tečka na závěr.

Určitě.

Děkujeme moc, děkujeme za rozhovor. Moc děkujeme za super rozhovor, že jste mě zde přijal a že jste to vydrželi s námi poslouchat. Bylo to skvělé. Díky, že jste nás vzali na cestu GCP, na výlet. Těšíme se někdy příště a držíme palce.

Děkujeme pěkně.

A to je vše. Děkujeme, že jste doposlouchali až sem. Děkujeme také našim partnerům: BigHubu, Intexu, Sastce, ByStreetu, Colors of Data, Revolt BI, GoodData, Keboule, eMarku, Karl Data Company a Datamindům.

Pokud vás zajímá víc, navštivte naše stránky datatalks.cz a přihlaste se k odběru našeho newsletteru.