Podcast

Dobrý den, moje jméno je Jirka Vicherek a vítám vás u dalšího dílu DataTalku. Mým dnešním vzácným hostem je Tomáš Sobotík, Snowflake Data Superhero a zároveň Data Engineer a Snowflake Subject Matter Expert ve společnosti Tery.

Ahoj Tomáši.

Ahoj Jirko, díky moc za pozvání.

My si dneska s Tomášem, nepřekvapivě, budeme povídat hlavně o Snowflake a řekneme si taky jeho hero origin story, neboli jeho případ Data Superhero.

Tak abychom začali úplně na začátku: jaká byla tvoje cesta k datům, k superhrdinství a ke Snowflake?

Moje cesta k datům začala už na vysoké škole. Data mě vždycky bavila. Nikdy jsem nebyl ten hardcore vývojář, který by chtěl jen dělat nějaké aplikace, ale vždy mě bavilo propojení technologií s byznysem. U dat totiž musíš jednak něco vyvíjet a zároveň interpretovat výsledky a prezentovat je, takže to pro mě bylo zajímavé.

Studoval jsem tedy v Báňské technické univerzitě v Ostravě a během magisterského studia jsem se nějakým způsobem profiloval k datům. Vzal jsem si všechny volitelné předměty týkající se databází, data miningu a podobných věcí. Dokonce i diplomovou práci jsem dělal z tohoto oboru. Logicky z toho vyplynulo, že jsem po škole hledal zaměstnání právě v oblasti dat.

Já tě mám spojeného s tím, že jsi dlouho působil v Tietu, dnes TietoEVRY, pokud se nemýlím. To není překvapivé, když jsi studoval v Ostravě, protože Tieto je největší IT zaměstnavatel v regionu. Už na škole tě tak nějak cíleně oslovovali, nebo bylo jasné, že je to ten hegemon, a šel jsi do Tieta?

V té době, tedy kolem roku 2010, nebylo v Ostravě tolik možností. Bylo tam Tieto a možná jedna nebo dvě firmy, které se nějak zabývaly daty. Tieto bylo z těchto možností to jediné mezinárodní prostředí s anglickými zákazníky mimo Česko, takže mě to táhlo spíš tímto směrem. Viděl jsem tam větší příležitosti a šanci pracovat na zajímavých projektech. Tieto také aktivně lákalo studenty a ukazovalo, co se ve firmě dělá, takže pro spoustu lidí byla to logická volba.

Jaký byl tvůj první job?

Měl jsem klasickou posloupnost. Pozice se myslím jmenovala BI specialista a šlo o support a lehký vývoj v rámci datového skladu pro jednoho operátora ve Finsku. Takže klasická cesta: člověk začal dělat support skladu, k tomu nějaký lehký vývoj, a prostřednictvím toho nabíral zkušenosti. Postupně se střídali zákazníci i technologie a já dělal stále víc a víc – až po nějaké architekturální návrhy řešení a support, to je komunikace se zákazníky ve smyslu: "Potřebujeme nějaké řešení, zkuste nám to vymyslet" nebo "Zvalidujte to, co tady máme a řekněte nám svůj názor."

Jaký byl tvůj technologický stack, než přišel Snowflake?

Jistě, tady je opravený text:

Em, zkoušel jsi všechny? Jaké jiné databáze jsi vyzkoušel, než přišlo tohle magické? Samozřejmě před 15 lety byla úplně jiná technologická doba než dnes, takže to byly víceméně on-prem řešení, primárně kolem Oracle, což byla zase Tieto – měli zákazníky hlavně na severu, velké korporace, operátory, banky, pojišťovny, retail. Takže tam byla jedna větev – Oracle, a druhá větev byly Microsoft technologie. Já jsem začal s Oracle a nějak mi to zůstalo po celou dobu. Ale nebyl to jenom Oracle, byly tam i další relativně zajímavé technologie jako Netezza, což bylo prostě nové řešení, něco na způsob dnešního Snowflake, i když vlastně řekněme trochu jinak u on-prem, ale zase to bylo cool, nové, rychlé, taková data, takže primárně Oracle, Netezza a tak dál.

A z dalších ETL nástrojů pro mě byla spoustu let Informatica a stavěli jsme řešení kolem Informatiky plus Oracle nebo jiné databázové systémy. A před Snowflakem jsi pracoval s nějakými cloudovými řešeními, nebo byl Snowflake tvůj první vstup do cloudu? Ne, ne, ne. S cloudem jsem začal v roce 2018, a před Snowflakem to pro mě byla Cloudera, takže nějaký Hadoop, Data Lake nad AWS, vlastně v AWS. Takže to byla kombinace AWS technologií a k tomu Cloudera a Hadoop.

No a tak se dostáváme k prvnímu setkání. Kdy jsi poprvé zaznamenal Snowflake a jaká byla tvoje první zkušenost? Snowflake jsem jako firmu vnímal možná od roku 2017, kdy tu byla nějaká nová technologie v cloudu, která řešila data warehousing trochu jinak než doposud. Poprvé jsem měl možnost s tím pracovat asi o dva roky později, v roce 2019, kdy jsme pro jednoho zákazníka stavěli úplně nové řešení na Snowflake. Ten zákazník potřeboval vytvořit nový Business Insight portál pro své B2B zákazníky – byl to operátor. Potřebovali portál, kde by B2B zákazníci mohli vizuálně analyzovat své faktury, jak utrácejí za mobilní služby, a na základě toho jim dávat doporučení typu „máte nevhodný tarif, aktivujte balíček XYZ a ušetříte tolik a tolik“.

Což zní jednoduše, pokud jsi jednotlivec nebo rodina s pěti lidmi, ale pokud jsi firma s pěti tisíci SIM kartami a faktura má několik tisíc stran, je analýza složitější. To byl ten use case. Firma měla strategii být v cloudu, migrovat současné řešení, které bylo postavené na Cloudeře, do cloudu a chtěla vyzkoušet něco nového. Jedna varianta byl Snowflake, druhá byla Redshift, a výběr nakonec nechali na nás, vývojářích. My jsme všichni chtěli Snowflake, takže nám bylo umožněno postavit řešení na Snowflake.

Pokud chceš, mohu pomoci i s další částí textu.

Opravený text:

Byla to práce nad Snowflakem. Zadání bylo takové „OK“, takže tady máte Snowflake, tady máte 10 týdnů, a za 10 týdnů nám vlastně postavte ten Insight portal pro ty zákazníky, a to ve třech lidech. Nikdo z nás do té doby Snowflake neznal, nebo s ním nikdy nepracoval, neměli jsme žádné prostředí, nic – dostali jsme 10 týdnů. Navíc to bylo v létě, takže pokud jste potřebovali něco konzultovat s business lidmi, většina byla na dovolené. Bylo to náročné, občas dlouhé večery, ale nakonec jsme to stihli – v polovině září byl portál hotový. Sklidil obrovský úspěch, protože ten use case byl jeden z prvních pro Snowflake jako firmu v Dánsku. I oni chtěli, aby to uspělo a měli nějaké success stories pro své další zákazníky. Do dneška, když potkám lidi ze Snowflaku z Dánska, pamatují si to a říkají, že dlouhé roky to používali jako úspěšný příklad.

Skvělé, takže ve třech lidech a za 10 týdnů jste vytvořili velký success story pro Snowflake. Když se vrátíme zpátky do minulosti (což je trochu nespravedlivé srovnání, protože už je to pár let zpátky): pro někoho, kdo pracoval v cloudovém prostředí a byl zvyklý na Clouderu, co tě tehdy překvapilo? Čím se Snowflake lišil?

Pamatuju si to dodnes – byl to úplně jiný svět. Najednou takové „wow“: když si vzpomenu na Clouderu, potřebovali jsme člověka, který pořád ladil ten cluster, na kterém běžely joby, aby to vůbec doběhlo a mělo to výkon, který má mít. Tady nepotřebuješ nic ladit, prostě zapneš Snowflake, napíšeš dotaz, a on doběhne relativně rychle. Další věc byla, že když na Clouderě pustíš cokoli, trvalo minimálně minutu, než se cluster nastartoval. Tady sis napsal dotaz a warehouse, na kterém to běží, byl okamžitě spuštěný – otázka milisekund. To si pamatuju jako první velký rozdíl.

Wow, já jsem nevěřil, že to fakt proběhne. Že to už je ono. Byl to určitě první „wow“ moment – to fakt funguje. Jak to od nich stále slyším, je to taková mantra: „funguje to“. Je to strašně jednoduché s tím začít a používat to. Learning curve je hodně rychlá, když máš zkušenost s nějakými jinými technologiemi.

Kromě rychlosti bylo něco dalšího, co bylo logicky jiné oproti jiným cloudovým řešením?

Myslím si, že technologie jsou víceméně porovnatelné, každá ale dneska směřuje trochu jiným směrem. Hodně se už prolínají, snaží se "držet si své rybníčky". Asi vybavuju, že tohle bylo jiné – Snowflake je software jako služba (SaaS), což Cloudera v té době nebyla. Nepotřebovali jsme žádnou infrastrukturu, nepotřebovali jsme...

Jasně, tady je opravený text:

Mně nic, prostě jsme si vytvořili účet někde na snowflake.com a začali jsme prakticky hned. Nemusíš – v té cloudové hře je to zase jednodušší než v on-prem prostředí, kde trvá měsíce, než někdo schválí objednávku serveru, než se to nakoupí a nainstaluje. V cloudu je to rychlejší, ale zase potřebuješ minimálně nějakého admina, protože nemáš práva, abys si tam sám vyklikával virtuální stroje, na kterých to pojede. Tady, u Snowflake, nám manažer prostě dal kreditku: „Tady máte moji kreditku, jděte do toho,“ a jeli jsme. Takže první deset týdnu jsme měli prostě prostředky.

Po těch deseti týdnech jste si poprvé vyzkoušeli Snowflake, zamilovali se do něj i klient, všichni byli šťastní. Co se dělo pak? Pak ses stal Snowflake subject matter expertem a už jste prodávali Snowflake každému. Už jsi nedělal nic jiného, nebo v Tietu jsi pořád musel řešit AVS a Clouderu?

Co se dělo potom? Už jsem nedělal nic jiného, to je pravda. Subject matter expert jsem ale nebyl dlouho, myslím.

A co dál? Po těch deseti týdnech byl projekt úspěšný, takže dostal zelenou k rozšíření. Takže jsme měli dalších deset týdnů na implementaci dalších use caseů a na konci roku se spustil portál, kde zákazník začal data monetizovat. On začal prodávat přístup k datům svým zákazníkům. Jinými slovy, korporace platily za sadu dashboardů, které vizualizovaly jejich vlastní data o využití mobilních služeb. To byl úspěch jak pro operátora, tak pro Snowflake.

Dokonce tehdy zmiňovali, že portál jim pomohl prodloužit smlouvy s klíčovými zákazníky, protože to bylo něco, co konkurence neměla a nemohla nabídnout. Dneska už to neplatí. Snowflake se zalíbil i lidem ve firmě, takže jsme dostali zelenou na další projekty. Hned další byla migrace z Cloudery do Snowflakeu.

V rámci Tietu jsme potom Snowflake nabízeli i dalším zákazníkům. Poptávka rostla s tím, jak Snowflake získával na popularitě. Další rok měli IPO, jedno z největších v historii softwarových společností. Přibylo zákazníků a pro mě to znamenalo podporu v pre-sales aktivitách. Když například někdo měl požadavek „postavte nám warehouse“, nebo „zmigrujte warehouse do cloudu“, primárně jsme nabízeli Snowflake, protože se nám líbil.

Jak ses tedy stal subject matter expertem a data super hrdinou? Když jsme začínali, pokud jsme chtěli zjistit nějaké informace, jak něco udělat, nejlepší praktiky, způsoby práce, tak těch informací kromě oficiálních zdrojů od Snowflakeu moc nebylo…

Pokud chceš, můžu ti pomoci s dalším pokračováním nebo ještě víc text upravit.

Zde je opravený text:

C nebylo. A mě vždycky bavilo sdílet vlastní zkušenosti, tak jsem začal psát nějaké blogy o tom, co my řešíme, jak to řešíme, a byly celkem populární. Myslím, že ta zpětná vazba od lidí kolem byla pozitivní a pomohlo mi to vlastně se dostat nějakým způsobem do té komunity, která kolem Snowflakeu byla, poznat spoustu zajímavých lidí z celého světa a díky tomu

jsem se naučil spoustu věcí a mohl sdílet to, co my děláme a jak to děláme. V té době jsme se vždycky snažili, když přišla nějaká nová featura, přemýšlet o tom, jak ji zaintegrovat, jak ji můžeme použít. A když jsme to udělali, hned jsem k tomu napsal nějaký blog nebo se snažil to sdílet – tak tady je tato featura, můžete ji použít takhle, takhle, takhle. Samozřejmě před těmi čtyřmi, pěti lety byla situace úplně jiná a bylo to možné, protože těch, řekněme, releaseů nových featur nebylo tolik jako dnes. Dneska už toto prostě není možné, ten záběr je úplně jiný než před pěti lety. Ale to byla ta cesta, vlastně snaha sdílet zkušenosti, nabrat nové a něco se naučit.

No a tak jsi měl nějaký vlastní blog nebo Medium?
Jo, Medium a LinkedIn vlastně. Kombinoval jsem kratší zprávy na LinkedInu a další success story nebo návody, jak něco implementovat, na Medium. K tomu jsem vždy přistupoval tak, že jsem se snažil napsat něco, co bych rád sám četl, co bych rád našel, když jsem řešil tohle a tohle. Takže tímto směrem jsem vždycky přemýšlel a vytvářel nějaký ten obsah.

No a zároveň jsi byl díky té práci v úzkém kontaktu i díky dánskému úspěchu ve styku se samotným Snowflakem?
Ano, jo, v rámci projektu jsme byli denně v kontaktu s lidmi přímo ze Snowflakeu, ať už se sales inženýry, kteří měli za úkol to prodávat, ale byli i technici s technickým zázemím. Takže na začátku, když jsme technologii neznali, byli schopni nám poradit: „Hele, tohle vyřešíš takhle, tohle najdeš tamhle“. A jak jsem nabíral zkušenosti a stával se součástí komunity, dostával jsem se přímo k lidem ze Snowflakeu, kteří vyvíjejí featury, projektovým manažerům za různé oblasti, kteří znali moje jméno, věděli, co a jak dělám, a zajímali se o to, co by nám pomohlo, co dalšího potřebujeme, co je nového, jak by se nová featura dala použít, nebo co tam chybí. Takže se to vlastně takhle postupně rozvíjelo.

No, už tehdy byla ta komunita organizovaná ve smyslu tierů – jako to známe z Google nebo Microsoftu, MVPs a tak. Dá se to tak připodobnit?
Tehdy ne. Možná jsem zkombinoval víc let do dvou věd, ale když se vrátím do roku 2019 nebo 2020, tak komunita určitě nebyla takhle organizovaná. Vím, že existoval nějaký program, kterému říkali Data Heroes nebo něco podobného, ale v rámci Snowflakeu...

Pokud chceš, můžu dál text upravit a doplnit, případně rozčlenit do odstavců.

Jistě, tady je opravený text:

Tam byla jedna slečna, která to měla na starost, a ještě jako na částečný úvazek. Takže jsem tam něco objevila a říkala jsem si: „Hele, ty tady máš prostě krásný obsah, nechceš se přidat do našeho programu?“ Tak jsem se přidal, ale nebylo to nic víc – poslali mi nějaký merch a tím to vlastně skončilo. Nebyla k tomu žádná komunita nebo něco podobného.

Merch je vlastně ten nejdůležitější a Snowflake má skvělý. Jo, jo, po plyšových medvídcích se na každém datameetu vždycky zapráší, ty jsou první pryč a poráží jakýkoliv jiný merch. Souhlasím, merch je určitě krásný, ale dneska už mi manželka říká: „Prosím tě, hlavně nic nevoz, už toho máme tolik, že to není kam dávat.“ Takže mám speciální skříň jenom na Snowflake merch a děti samozřejmě taky mají medvídky a nějaké další věci, jako malá smířátka.

Když se teď podíváme, jak vypadá komunita Snowflake, jestli je to nějaká super heroes community? Jo, dneska už je to vlastně organizovaný tým. Na stránkách Snowflake je tým, který má na starost jenom tu komunitu.

Když bych chtěl začít na ten track, jak vlastně funguje zapojení? Pokud člověk zadá do Google „Snowflake Community“ nebo „Snowflake Super Data Heroes“, dostane homepage, která popisuje, co ta komunita dělá, jaké jsou aktivity a jak se zapojit. Tracků je spousta – od vystupování na nejrůznějších meetupech a user groups, přes aktivní podporu na Stack Overflow a vlastních fórech Snowflake, až po generování obsahu a sdílení zkušeností. Každému vyhovuje něco jiného.

Takže takhle se může člověk zapojit. Myslím, že komunita pořád funguje tak, že se otevírá jednou za rok a v té době můžeš požádat o to, že chceš být součástí té top tier komunity. Pak je ještě něco, co oni nazývají Snowflake Squad, což je pod tím a je to otevřené celoročně, tam se pak postupně nabírají lidi. Top tier je ale jednou za rok, kdy se musíš přihlásit a Snowflake si sám vybírá, koho chce mít v programu.

V Česku a na Slovensku máš představu, kolik je data superheros? V Česku si myslím, že je to pořád jenom já, a myslím, že to platí i pro Slovensko, protože si nevzpomínám na žádné slovenské jméno.

Super, moc gratuluju! Důležité je taky zmínit, že jsi spolupracoval i s O'Reilly, což je velmi prestižní. Dostalo se tam přes Snowflake, nebo to byl samostatný track, který ti pomohl i ve Snowflake? Bylo to jedno s druhým. Mám pocit, že to je etalon. Říct, že jsi lektor O'Reilly a máš tam nějaké ocenění, je velmi žádané a prestižní.

Dostal jsem se tam vlastně přes Snowflake a obsah. Po pár letech jsem začal dostávat spoustu nabídek ve smyslu: „Hele, potřebujeme napsat knihu o Snowflakeu, o nějaké certifikaci nebo o data engineeringu ve Snowflakeu, o jo…“

Pokud bys chtěl, mohu text ještě více upravit nebo zkrátit.

Opravený text:

K stavění řešení nad Snowflakem mě to nikdy nelákalo v tom smyslu, protože pro mě to byla nějaká neznámá nakladatelství, řeknu. Až pak jednou přišlo O'Reilly. Známé nakladatelství. Ano, ano, to jsem si říkal, člověk ty knihy četl, když studoval, že jo. A najednou oni po mě něco chtějí. A jo, bylo to přesně tak, že mě kontaktoval vlastně editor pro data v O'Reilly, který říkal, že se mu líbí obsah, který tvořím, a že si myslí, že bych mohl být vhodný kandidát na lektora, jestli bych o to měl zájem. A já jsem říkal, že jo, že mě vždycky bavilo sdílet zkušenosti, že by to mohlo být zajímavé, takže tak nějak jsme se domluvili. Od té doby mám dneska už čtyři různé vlastní kurzy o Snowflakeu, které běží na platformě O'Reilly.

Jsou to online kurzy anebo živé webináře?
To jsou online živé webináře. Je to vlastně online, ale zároveň živé – kurz má vždycky vypsané nějaké termíny, lidé se přihlásí a já live prezentuju daný obsah.

Takže máme Snowflake Fundamentals pro úplné začátečníky, čili vlastně „from zero to hero“ – jak se naučit Snowflake a co jsou ty základní věci, potom přes nějaký advanced kurz pro data engineering až po more advanced témata, řekněme optimalizace a performance tuning. Ty kurzy mají různou délku – ta optimalizace a performance tuning je jedna tříhodinová lekce, Fundamentals a data engineering kurz mají vcelku devět hodin, ale je to vždycky rozdělené po tříhodinových blocích, tedy každý týden tři hodiny během tří týdnů.

Moc gratuluju, protože O'Reilly je etalon a silná značka. Já jsem kvůli tomu četl i tu O'Reillyho knížku „WTF – What the Future“ – tam se dost vychlubují, ale i tak mě překvapilo, jaký velký vliv měli na Open Source nebo na vznik AVS a takovéhle trivia mě vždycky baví.

Ale asi pojďme k našemu hlavnímu tématu, kde jsi expert, tedy ke Snowflakeu. Teď už máme tvoji „Superhero Origin Story“ a nějaký background ohledně toho, co jsi dělal předtím, tak začněme s Fundamentals.

Pokud jsem o Snowflakeu doposud jen slyšel, ale nevím, kam si ho zařadit, co to vlastně je, co to dělá?

Snowflake dneska je vlastně datová platforma v cloudu, řekl bych. Oni trochu změnili název, dnes říkají, že Snowflake = AI data cloud. Před x lety to byl primárně datový warehouse v cloudu, takže se nějakým způsobem posunuli. Takže bych řekl, že ano, je to datová platforma v cloudu pro náročnější...

Vyšší datové projekty dneska můžeš stavět na Snowflake od datového skladu přes data science, machine learning, AI až po datové aplikace – prakticky cokoliv. A čemu je to nejblíže? Historicky mám pocit, že to byl nástupce Redshiftu a podobných jako next-gen data warehouse. Bylo to takový buzzword. Dnes by ses na to díval spíš jako na něco blízkého Databricks, nebo je to pořád spíš rychlý warehouse a workload na něm?

Já osobně bych to pořád přirovnal k...

Pokud chceš, mohu pokračovat v opravě i následující části.

Tomu, že je to velmi rychlý warehouse a že na tom workloadu se nabalují další věci, je podle mě zásadní. To je můj osobní pohled, protože jsem zaměřený na data warehousing. Možná kdybys tady měl někoho, kdo se zabývá AI, tak by ti řekl, že se to posunulo někam jinam, ale já to stále vnímám takhle. I když se bavíme o AI nebo o čemkoliv jiném, pořád to stojí na jejich unikátní technologii, kterou vybudovali před 12 lety, když začínali.

A co je ta unikátní technologie, kdybys to měl popsat? Ta unikátní technologie je v tom, že mají oddělený compute a storage, a jsi schopen každou tu službu škálovat nezávisle na sobě. To je jedna z klíčových vlastností Snowflakeu. Druhá věc je pay-as-you-go model, kdy platíš jen za to, co skutečně používáš, bez nutnosti kupovat licence nebo hardware.

Pro mě je klíčová možnost škálovat compute služby separátně a relativně jednoduše, bez nutnosti znalosti infrastruktury – kolik jader, kolik paměti apod. Snowflake to zabalil do jednoduchého balíčku s osmi předdefinovanými velikostmi od nejmenší až po největší, které jsou pojmenované podle velikostí triček, od XS až po 6XL. Tedy opět jednoduchost.

Takže pro mě je to hlavně ta kombinace škálovatelnosti a jednoduchosti, kdy se snaží, aby to bylo snadné pochopit a používat. Nepotřebuješ mít hluboké znalosti infrastruktury, abys to zvládnul používat.

Pro koho je to tedy z tvého pohledu? Věřím, že na webu Snowflakeu najdeš frázi „from early stage startup to Fortune 500“, což je klišé, ale kde bys řekl, že je Snowflake opravdu vhodná první volba? Znám oba typy – startupy, co jedou na Snowflake, i spoustu Fortune 500 společností. Myslím, že každý si tam najde něco podle konkrétního use case.

Pokud se vrátím k data warehousingu, pokud někdo potřebuje stavět analytické řešení, Snowflake je dneska skvělá volba. Můžeš začít během pěti minut a pokud máš nízký budget, použiješ menší compute klustery, pokud máš vysoký budget a větší množství dat, škáluješ dle potřeby.

Pro mě je Snowflake vhodný pro jakoukoliv velikost firmy, pokud řeší data warehousing. Dřív mnoho firem mělo Microsoft SQL Server, který vyžadoval licenci i hardware. Dnes pro spoustu firem dává smysl moderní cloudové řešení jako Snowflake.

Možná jsem trochu ovlivněný, protože hodně pracuju s enterprise zákazníky, takže nemám úplný vhled do menších firem, ale myslím, že Snowflake má široké uplatnění.

Jasně, tady je opravená a lépe strukturovaná verze textu:

A když si vezmeme projekt, který se tam nehodí, tak třeba takový, který nevyužívá datový sklad a můžeš ho celý naklikat ve vizualizační vrstvě. Prostě jednoduché use case, které... Asi jo, tohle by byl kanón na vrabce, si myslím, že pokud to můžeš naklikat...

Něco jednoduchého, nebo ti k tomu stačí Excel. Dneska Excel připojíš na spoustu datových zdrojů, tak proč ne? Další věc, co si myslím, že úplně nebude vhodná, jsou transakční use casey. I když Snowflake dneska už umí i OLTP, tak si myslím, že bych to na tom teď nestavěl. Pořád bych volil nějakou tradiční transakční databázi. Proč? Protože to není na to úplně stavěné. Klasická transakční databáze sice stojí na nějaké licenci, ale nepotřebuješ nic víc a nepotřebuješ tu chytrou vrstvu navíc. Myslím si, že právě proto, že to na to není primárně nastavené. Je to něco, co se možná přidávalo na požadavek některých zákazníků, aby řešení splňovalo i OLTP standardy.

Co se týká nákladů, myslím, že OLTP může vyjít dražší než analytický workload. Určitě to funguje, toho bych se nebál. Možná to dává smysl pro ty, kteří už mají analytický use case ve Snowflakeu a teď přemýšlí, jak tam dostat i transakční data, protože pak nemusí data přelívat zleva doprava, ale budou to mít pod jednou střechou. Ale pokud bych začínal od nuly, hodně bych přemýšlel, jestli to stavět nad Snowflakem, nebo ne.

Mám pocit, že když se nedíváme na klienty Kebuly, kde jsem se se Snowflakem poprvé seznámil a která to má jako feature svého produktu, tak čistých Snowflake klientů tu historicky nebylo tolik. Ale myslím, že se to mění. Nějaké stigma nebo stereotyp bylo, že Snowflake sám o sobě je dost drahé řešení. S tím se určitě taky potkáváš, že je to enterprise řešení. To je první otázka většiny zákazníků: „Kolik mě to bude stát?“ To není jen Snowflake specifické.

Ono se to relativně těžko vysvětluje, protože pro ně je to složité – není to tak, že si koupíš mašinu s licencí za milion eur a pak platíš maintenance poplatek. Tam je to trochu jinak. Vždycky chtějí vědět: „Spočítejte mi, kolik to bude.“ Já se nerad pouštím do přesných odhadů, protože člověk neví, kolik dat tam bude, kolik máte uživatelů a jak často potřebujete refreshovat dashboardy atd. Vycházím z nějakého worst case scénáře: bude to maximálně tolik, ale určitě to bude méně.

Setkávám se často s tím, že lidé si myslí, že je Snowflake drahý. Já se snažím vysvětlit, že tu nic nekupujete dopředu, nekupujete licence a nepotřebujete lidi, kteří se budou starat o hardware, což je další náklad. Je to relativně jednoduchá technologie...

Pokud chceš, můžu text u více upravit podle záměru, aby byl ještě jasnější.

Tady je opravený text s drobnými stylistickými úpravami pro lepší čitelnost a plynulost:

Aby se to současní lidé, které máte v týmu, naučili. Pokud mají znalost SQL, jsou schopní okamžitě Snowflake relativně efektivně používat. Za mě je ta platforma udělaná — nechci říct úplně blbuzdorně, ale nemusíš být expert, abys ji dokázal efektivně používat. Snažím se argumentovat tímto směrem: low floor, high ceiling. To jsou věty, co se často říkají.

Když jsi narazil na pricing, chápu, že protože je to pay-as-you-go a závisí na spoustě parametrů, vlastně nevíš přesně, kolik to bude stát, dokud to nespustíš, a pak to musíš optimalizovat. Je potřeba k tomu přistupovat agilněji než v případě nákupu železa na pětiletku. To chápu, ale právě když tě v tomhle oboru klienti nutí, a ty v tom dlouho jsi, máš nějaké lessons learned, metodiku, uvažovací framework, jak přemýšlíš o těch nákladech, na co si dáváš pozor.

Když bych teď vstupoval do Snowflake, kde bych vlastně měl začít? Co jsou ty věci, které si mám vyjasnit, abych se dostal k nějakému rozumnému rozmezí nákladů?

Mně se zdá, že i Snowflake má k tomu nějaký Excel, kde na základě toho, co máš nyní, umí kalkulovat, že bude to přibližně XYZ. Co mě například vždycky zajímá, je určitě datové volume – kolik dat potřebujete zmigrovat, kolik máte dat, kolik pipeline vám běží denně, týdně, měsíčně, máte nějaké real-time use casy, kdy potřebujete data refreshovat třeba každých pět minut. To je to, co ty náklady hodně zvedne.

Na druhé straně je pak počet business nebo analytických uživatelů, kteří budou Snowflake využívat — například pro přísun dat do dashboardů, což je další takový “žrout” nákladů. Na jedné straně jsou to náklady na nahrání dat, na druhé straně pak spotřeba těch dat.

Vždycky se snažím alespoň rámcově říct: pro nahrání dat budeme potřebovat jeden warehouse velkosti XL, který poběží například šest hodin v noci a provede refresh celého warehouse. Pro business uživatele postačí warehouse velikosti medium, který poběží během pracovních hodin, třeba od 8 do 16 nebo od 9 do 17, což je takový worst case scénář.

Z toho vyplývá odhad nákladů, ale pak se samozřejmě dá optimalizovat — warehouse nemusí běžet nonstop, data můžeme kešovat, nebo jinak optimalizovat v průběhu času. Jakmile to řešení poběží alespoň měsíc, má člověk výsledný rámec a může začít s laděním nákladů.

Předpokládám, že Snowflake jako moderní platforma má vestavěný monitoring, pravidla, alerty a podobně. Přesně tak. Můžeš si nastavit rozpočty, například, že chceš, aby tě určitý tým nebo warehouse stojil maximálně určitý limit za měsíc, a pokud to překročíš, dostaneš alert, nebo rovnou službu vypneš a nebudou moci pokračovat v používání.

Pokud chceš, můžu ti s textem ještě víc pomoci, případně shrnout do stručnější formy.

Zde je opravený text:

K predikci těch nákladů, prostě když si stanovíš svůj budget, tak on na základě toho, jak to používáš doposud, je schopen ti říct, kolik to celkem bude v následujících dvou týdnech. Takže jo, nějak to asi funguje s FinOpsem. Super, tak tímto bych uzavřel fundamentals.

Respektive ještě něco, co máš v rámci svého kurzu na O'Reillym, nebo obecně, máš pocit, že jsou věci, které by lidi, co nepoužívají Snowflake a zatím v tom prostředí nebyli, měli vědět o té technologii?

Napadá mě ještě jedna věc, která mi přijde taky strašně cool, když to porovnám třeba s konkurencí – že Snowflake je vlastně cloud agnostic. Nezáleží na tom, na jakém cloudu už máš nějaké řešení, Snowflake můžeš mít na všech třech hlavních platformách. A stejně tak jsi schopen data sdílet s ostatními – ať už Snowflake zákazníky, nebo i lidmi, kteří Snowflake nemají. Ty data s nimi můžeš sdílet přesto, že oni používají Snowflake rozhraní.

Tohle mi přijde taky strašně fajn, protože najednou nemusíš řešit: „Mám data v Azure a potřebuju je dostat do Google cloudu, jak to propojím?“ U Snowflake fakt nezáleží, kde to máš. Můžeš mít jeden účet v Azure, druhý v Google a třetí v AWS a všechno to funguje mezi sebou.

Co se týče monetizace nebo sdílení dat – například přes datový marketplace – mám dojem, že Snowflake jednu dobu tuto featuru velmi silně prosazoval jako hlavní propozici svého produktu, tedy: „Nad námi můžete monetizovat svá data, už to nebude jenom váš interní warehouse, ale můžete své know-how velmi rychle, efektivně a bezpečně prodávat dál.“ A klienti, kterých máme spoustu, jsou třeba schopni kupovat telekomunikační data nebo marketingová data, která jsou nějak anonymizovaná, očištěná a bezpečná. Potkáváš se s tím často? Máš pocit, že se tato propozice naplnila a že je to killer feature?

Když máš Snowflake, měl bys uvažovat o tom, jak sdílet data. Je to určitě zajímavá fičura, ale nepotkávám se s tím až tak často, jak bych čekal. Jak jsi to teď popsal a jak se to snaží marketovat, tak bych taky předpokládal, že to bude killer feature – že můžete prodávat svá data.

Přiznám se, že osobně nevidím tolik use caseů. Buď jsi startup, který je zaměřený na připravování anonymizovaných datasetů k prodeji dál – a takových je myslím hodně.

S čím jsem se potkal spíš, je to, že spousta enterprise zákazníků uvažuje o nastavení interního marketplace, protože data nabízet ven prostě nemohou nebo nechtějí, ale potřebují je sdílet se svými dodavateli. Viděl jsem třeba use case v retailu ve Skandinávii: velký retailový řetězec chce optimalizovat logistiku a proto sdílí data o kapacitě skladů.

Pokud chceš, můžu text dále upravit nebo zkrátit.

Opravený text:

V jednotlivých lokalitách spolu s dodavateli plánují zásobování. Vím, že jeden z těch use caseů byl okolo Snowflakeu a interního marketplace, který nebyl veřejný, ale fungoval pouze v rámci zákazníka a jeho partnerů. Je to vlastně partnerská síť, tedy B2B. Super.

Když teď přejdeme k pokročilejším věcem a poslouchá nás někdo, kdo má Snowflake ve svém stacku a používá ho, už mu na něm běží buď část, nebo většina workloadů, tak jaké jsou nejčastější dotazy, lessons learned a obecné zkušenosti? Běží vám to, ale když vás pozvou jako konzultanta, abyste se na něco podívali, jaké jsou první věci, kam se díváte, například typické anti-patterny, které zvyšují náklady?

Přesně tak, první věc je podívat se na náklady a způsob, jakým mají nastavené compute warehouse, tedy vrstvu, která běží a počítá dotazy. Je tam samozřejmě defaultní nastavení, které funguje, ale můžete se snadno dostat do situace, kdy platíte víc, než je potřeba, protože neznáte parametry optimalizace nastavení warehouse. To je první věc. Je tam celá řada parametrů, typicky například jak dlouho může dotaz běžet, než ho platforma sama ukončí. Výchozí hodnota je dva dny, což znamená, že se může stát, že v pátek odpoledne někdo spustí špatný dotaz a odejde domů, zatímco dotaz poběží celý víkend. V pondělí ráno se pak objeví vysoké náklady na grafu s nákladovými sloupečky.

Proto se dívám na to, aby si to upravili podle svého use case. Podle mě dotaz nemá běžet déle než hodinu, minimálně pro warehouse, které používají reální uživatelé. Díky rychlosti Snowflakeu jsou uživatelé zvyklí, že dotazy nečekají dva dny. Pokud už dotaz běží víc než hodinu, měl by se přepsat nebo přehodnotit, jaký warehouse se používá, jak je výkonný. Tento limit je první věc, kterou řeším.

Co dál? Další věc je, že někteří začnou se Snowflakem jako POC, všechno běží, funguje, a nabalují další use cases. Dnes už mají produkční řešení, ale nikdo od začátku nesahal na nastavení. Proto se dívám na počet a nastavení warehouse. Momentálně nevím, jestli používáte pay-as-you-go model, tedy pokud warehouse nepoužíváte, měli byste je vypnout, aby se neplatilo za nevyužité zdroje. Snowflake disponuje parametry, které warehouse po určité době nečinnosti automaticky vypnou, ale délka této doby se liší. Pro některé případy je pět minut nečinnosti OK, pro jiné je to...

(Text končí uprostřed, pokračování nebylo dodáno.)

Opravený text:

Je třeba vědět, že warehouse lze vypnout a pro některé use case ti stačí minuta, takže to není až tak dlouhé čekání.

Tady máte prostě warehouse, který používá například nějaká DBT pipeline. Proč tam máte ten parametr nastavený na 10 minut? Když ta DBT pipeline doběhne, už nepotřebuješ dalších 10 minut spuštěný warehouse. Jiná situace nastává, pokud warehouse používají nástroje jako Tableau nebo Klik, nebo jiné reportovací aplikace, protože tam je use case jiný.

Například si otevřeš nějaký dashboard, koukáš na něj třeba pět minut, pak nastavíš filtr a náležitě se to přepočítá. V takovém případě pracuješ s cache. Když warehouse vypneš, ztratíš tu lokální cache, což znamená, že by se musel obsah dashboardu znovu načíst a znovu počítat, což není příliš efektivní. Protože pokud warehouse používá Tableau, klidně tam můžeš nechat ten parametr nastavený na 10 minut, protože lidé ho používají jinak, než v případě DBT pipeline, a ušetříš tím, že data budou v cache a nebudeš je muset znovu logovat.

Další věc je, jakým způsobem se data nahrávají do Snowflake. Je důležité rozlišovat, zda je to efektivní. Někdo může říct: „Potřebuju nahrát 100 GB dat denně, potřebuji proto velký warehouse – dejme tomu XL.“ Pak zjistíš, že máš jen jeden nebo dva soubory o velikosti 50 GB a divíš se, proč to běží tak dlouho. Velikost warehouse v tomto případě nehraje moc roli, protože je potřeba paralelizovat celý proces. Je třeba mít stovky nebo tisíce menších souborů, aby bylo možné vytížit všechna jádra warehouse, oproti tomu, když máš dva velké soubory, vytíží se jen dvě jádra a další zůstanou nevyužitá, takže proces trvá stejně dlouho, jako kdybys použil warehouse poloviční velikosti.

To jsou typické chyby a oblasti, kde je možné ušetřit. Pokud máš na nahrání dat klidně celou noc, třeba ti nevadí nějaké malé čekání v frontě – není problém, když data budou nahraná v 4:05 nebo 4:15, když je potřebuješ až v 8 ráno.

Snažím se vždy začínat od nejmenší velikosti warehouse a podívat se, jak proces poběží. Když potřebuješ, zvětšíš kapacitu a zase sleduješ. Taková ta nejlepší praxe je, že při zvyšování velikosti by se měla doba zpracování zkrátit minimálně o 50 %. Pokud ne, znamená to, že nevyužíváš warehouse na 100 %, což ale nemusí vadit, pokud ti nevadí vyšší náklady.

Nakonec si kupuješ prostor a jistotu. Co se týče architektury, jestli začínáš s jedním datovým warehouse a jak ti přibývá... (text končí)

Pokud chceš, můžu ti i upravit text dál, nebo rozdělit na odstavce.

Tady je opravený text s úpravami pro lepší srozumitelnost a gramatickou správnost:

U use case scénářů vytvářím další a další datové sklady. Koukáš se na to, jestli je optimalizuješ tak, že jeden data warehouse dělá víc věcí, nebo zda je best practice používat microservices přístup, kdy každý warehouse má vlastní určení a můžeš sledovat využití konkrétně toho warehouse i jednotlivých položek. Já bych řekl, že existují dva typy přístupů. Někteří lidé preferují microservices přístup, tedy jeden warehouse na konkrétní use case nebo tým, cokoliv, a jiní zase říkají, že je lepší to co nejvíc konsolidovat. Já se přikláním k druhému přístupu – raději mít méně warehouseů, ale plně vytížených na 100 %. Čili bych se díval na to, jak je warehouse vytížený. Pokud mám například jeden warehouse pro HR, marketing a finance jednotku (přičemž každý by měl normálně svůj vlastní), proč to nemít jeden, pokud je jejich vytížení pouze kolem 20–30 %?

Samozřejmě je dobré rozdělit věci aspoň minimálně. Snažím se vždy říkat, že minimálně by měl být samostatný warehouse na ETL a načítání dat – to dává smysl mít oddělené. Pak může být jeden pro uživatele, business analytiky a developery, a další pro dashboarding a reporting. Takhle bych to rozděloval minimálně, samozřejmě můžeš mít i víc skladišť, pokud je chceš škálovat různými způsoby nebo pokud potřebuješ sledovat, jak který department nebo uživatel warehouse využívá.

Existují na to i nástroje, které umožňují vidět využití i v rámci jednoho warehouse. Když se takto konsoliduješ, jsi schopný lépe zajistit a kontrolovat, že warehouse skutečně vytěžíš na maximum, místo toho, abys měl třeba pět warehouseů vedle sebe, přičemž každý využívá jen 30 % kapacity.

Co se týká compute versus storage, je to něco, co se ve warehousingu často řeší, a různá řešení to nastavují různě – jestli chceš mít všechno uložené a k datům málo sahat, nebo to naopak mít minimalistické, abys neplatil moc za storage, ale počítal s častými dotazy a výpočty. Když jsou tyto dvě věci oddělené, jde o dvě různé oblasti a problémy. Existují i best practice týkající se storage. Já osobně říkám, že storage je v porovnání s computem levný, takže se nebojme naistalovat tam cokoliv, co si myslíme, že bude v budoucnu využité.

Co se týká best practice ohledně storage, dnes můžeš do tabulek nahrát prakticky cokoliv, nejen relační data, ale i JSON formáty, spoustu zpráv z různých API. Já tedy věřím, že pokud na to máme use case, že to jednou využijeme, je lepší data naloudit.

A co optimalizace dotazů – jak často vidíš problém s tím, že do systému sahají třeba juniorskí vývojáři, kteří tam napíšou nějaký neoptimální kód, který způsobuje větší spotřebu zdrojů, než by bylo nutné? Je to podle tebe častý problém, nebo to v té škále není tak hrozné? Jak jsem říkal, je to relativně uživatelsky přívětivé. Za mě je Snowflake Optimizer – tedy proces, který vytváří query plán pro tvůj...

Pokud chceš, můžu pokračovat s opravou další části textu. Dej vědět.

Tady je opravený a stylisticky upravený text:

Dotaz je super v tom, že spoustu věcí už řeší za tebe, takže nad tím nemusíš tolik přemýšlet, na rozdíl od dřívějších časů. Za mě, pokud aspoň trošku znáš SQL a znáš základní pravidla, třeba že kartézský join opravdu není to, co bys chtěl, tak se do úzkých nedostaneš tak snadno. Samozřejmě, pokud ti dotaz běží třeba hodně minut, existují nástroje, jak ho analyzovat. A ty jako admin zase máš nástroje, jak uživatele usměrnit, aby se takové situace opakovaly, například pomocí nastavení parametrů.

Musím přiznat, že buď mám osvícené kolegy, nebo problém typu „tohle mi neběží, potřebuji to optimalizovat“ vlastně řešíme docela vzácně. Když už, tak jde spíš o profesní zájem, kdy mě zajímá, jak platforma funguje, a zda se něco dá udělat jinak, třeba zrychlit dotaz o pár sekund nebo desítek sekund. Ale není to tak, že by někdo tlačil na to, že dotaz běží minutu a musí běžet za 50 sekund kvůli každodennímu spouštění, které by ročně ušetřilo značné náklady. Ty úspory vůči vynaložené práci nejsou tak obrovské.

Ohledně samotných SQL dotazů úspora nebývá tak veliká. Vidíš někde ještě prostor pro zlepšení, lepší architekturu, a tím i smysluplnější náklady? Obecně podle toho, jak je Snowflake postavený – jako sloupcová databáze – není úplně vhodné psát dotazy typu „SELECT * FROM tabulka“. Pokud máš tabulky relativně široké, řekněme se stovkami sloupců, znamená to, že musíš dělat full table scan. A pokud tabulka má navíc miliony, stovky milionů řádků, tak je to jednoznačně něco, co výkon výrazně snižuje.

Když si pak rozklikneš dotaz, kde máš třeba deset různých common table expressions (CTE) a nakonec z celkových tří set sloupců vybereš jen dva, vždycky si říkám: „Tohle jde přepsat, a úspora bude značná.“ Ten dotaz bude pak mít úplně jiný výkon. Ale ne všem to dojde, protože ne každý chápe architekturu technologie. Lidé jsou zvyklí, že když vyvíjejí nějakou pipeline, jednoduše si napíšou dotaz „SELECT *“ a pak si výsledky filtrovat.

Snažím se proto edukovat, vysvětlovat, jak to funguje, aby nemusely být zbytečně čteny celé disky. Kde jsem někde četl, nebo slyšel, že nejlevnější data jsou ta, která vůbec nemusíš načíst, protože proč bys měl načítat něco, co vůbec nepotřebuješ?

Máte nějaké vychytávky nebo funkce, které používáte často, případně které mají ostatní zapnuté, ale nevyužívají, nebo naopak nemají zapnuté, a měli by je mít?

Když se vrátíme k performance tuningu – není to něco, co bych dělal denně, spíš to vychází z profesního zájmu o technologii. Například u složitějších dotazů, které běží desítky minut, se snažím podívat, jak jsou postavené…

Pokud chceš, mohu také upravit a doplnit zbytek textu, jen ho sem vlož.

Opravený text:

Joiny, tedy v jakém pořadí se tabulky spojují dohromady. Snowflake preferuje tzv. right-handed tree, což znamená, že větší tabulky jsou na pravé straně a menší na levé straně joinu. Opět to dělá optimizer automaticky za tebe, takže nemusíš nad tím nijak přemýšlet. Pokud ale máš dotaz, který běží dlouho a má ne úplně optimální výkon, podíváš se na query plán. Pokud nevíš, jak ho číst, uvidíš tam nějaký strom a může ti to být nejasné. Tento problém lze jednoduše vyřešit přeuspořádáním tabulek, jak se spojují, což může mít dopad na výkon.

Ty jsi se ptal i na další funkce, tedy featury. Mluvíš trochu i o architektuře dotazů a o tom, jak ji přeskládat. Bavili jsme se o compute a velikosti warehouseu a nějaké architektuře. Moje otázka je spíš na samotný nástroj – co všechno nabízí. Hodně tu chválíš optimizer, ale jsou tam i další featury, které lidé třeba ve školení neznají nebo nepoužívají, přitom pro tebe jsou denní praxí a usnadňují ti práci s platformou?

Jo, jedna z funkcí může být například Snowpipe. To je feature pro continuous data ingestion, kdy nahráváš data do Snowflakeu na základě notifikací z cloudového úložiště. Je to automatizace datového příjmu, takže nemusíš mít samostatný proces, který je třeba nastavený v něčem jako Airflow. Používáš nativní feature platformy, čímž odpadá starost o ingestion. Navíc k ingestion musíš přidat správně naškálovaný warehouse, který má vhodnou velikost. Snowpipe je serverless feature, takže o compute se nestaráš – to ti zajistí Snowflake automaticky.

Dobré použití? Typicky near real-time use cases. Například když zákazník odklikne souhlas/ne souhlas s příjmem marketingových materiálů, chceš mít tu změnu co nejdřív ve skladu nebo marketingovém nástroji. Další případ jsou jakékoli případy, kde potřebuješ data co nejrychleji „nasadit“, bez čekání na noční dávkové zpracování.

A co úplně pokročilé, super vychytávky pro „Snowflake maga“, kterým rozumí jen ti, kdo strávili v Snowflake tisíce hodin? Co řešíte s dalšími datovými experty a vývojáři? Jaké jsou tyto tipy pro tu tříčlennou skupinu posluchačů?

Páne, nevím, jestli ti odpovím, ale to se...

Nejčastěji řeší, jak zjednodušit život vývojářům. A to jsou třeba věci, které se mi líbí, protože se snaží nějakým způsobem upravit SQL. Je to technologie, která je desítky let stará a více méně stejná. Teď se tam ale přidaly funkce, o kterých si myslím, že tam měly být už dávno. Potřebuješ vybrat všechno z tabulky kromě dvou auditních sloupců, například data vytvoření řádku a podobně. Buď napíšeš hvězdičku, ale ta ti vybere i sloupce, které nechceš, nebo musíš vypisovat těch deset, sto či sto padesát sloupců. Přidali tedy něco jako exclude, kdy řekneš „vyber mi všechno, kromě tady toho“, což mi přijde super. Nerozumím, proč tam tohle dřív nebylo.

Další věc je dynamický pivot. Když potřebuješ otočit řádky na sloupce, musíš většinou přesně definovat seznam hodnot, které chceš otočit, ale já ne vždycky znám jejich rozsah. Proto tam přidali dynamický pivot. Nebo něco, co nazývají soft join, což je vlastně spojení tabulek pro časové řady, kdy potřebuješ spojit data podle časových intervalů. Dřív jsi musel implementovat logiku typu: „Tento čas je větší než tamten, ten druhý je menší než jiný,“ všechny podmínky naházet dohromady, seřadit je a vybrat první vhodný. Nyní to jen napíšeš jako soft join mezi tabulkami s určitou podmínkou a on ti automaticky data spojí. Opět zjednodušení, protože dřív bys to napsal na desítkách řádků kódu, dnes to zvládneš na dvou.

To jsou věci, které se mi líbí – že vývojáři přemýšlejí, jak život zjednodušit.

Než se dostaneme k naší poslední části, kterou je samozřejmě JNAI, zmínil jsi, že platforma za pět let hodně vyrostla a brutálně se proměnila. Sám o tom mluvíš a všichni ji vnímají jako platformu. Když se podíváme na produkt, co z nových částí, které nejsou datovým skladem, používáš? Co ti přišlo fakt dobré, co ti zjednodušilo život – ať už jde o marketplaces, snowparky, nějaké vizualizační vrstvy a podobně? Mám pocit, že se to posouvá hodně blízko uživatelům.

Souhlasím. Technologie je úplně jiná než před lety. Tempo, jakým přidávají nové funkce, je takové, že někdy mám problém stíhat sledovat, co vše se přidalo, jak se to používá a jak to integrovat. Proto jsem už skoro přestal sledovat úplně všechno a snažím se zaměřit jen na to, co mě skutečně zajímá. A tady bych zmínil to, co mi je blízké – tedy data engineering a související věci. Za mě přidali spoustu věcí, které se týkají data engineeringu. Dnes můžeš na jedné platformě mít úložiště, tedy data warehouse, ale i pipeline pro transformaci dat, třeba jako náhradu dbt nebo něco podobného, a dokonce i orchestraci. Vlastně jsi... (pokračování textu).

Pokud chceš, mohu pomoci i s další částí textu.

Jasně, tady je opravený a trochu upravený text, aby byl plynulejší a srozumitelnější:

Jsi schopen ty joby orkestrovat, máš k tomu nějaké GUI, kde vidíš, jak jsou ty tasky mezi sebou propojené. Čili když to přeženu, tak si myslím, že jsi schopen postavit i warehouse včetně těch pipeline jenom nad těmi funkcionalitami, které tam postupně přidávají. Teď DevOps – další velká oblast, jak automatizovat spoustu procesů uvnitř toho warehouseu, třeba deploymenty mezi procesy a verzování kódu. Teď tam přidali podporu pro nějaké integrace Gitu.

Deklarativní definice database change management objektů znamená, že ten objekt nemusíš psát pomocí DDL skriptů, ale prostě řekneš: tady je objekt tabulka, která má seznam těchto sloupců. Když se ten objekt změní, tak prostě upravíš definici a Snowflake se postará o to, že daný objekt zalteruje do podoby, jakou jsi nadefinoval ve skriptu, aniž by ti přitom ztratil data. To jsou podle mě skvělé funkce, které se mi líbí. Nechci říct, že díky nim Snowflake ukradne zákazníky jiným technologiím, ale budeš mít jednodušší život v tom, že najednou můžeš mít víc věcí pod jednou střechou na jednom místě a zjednodušit si celý stack tím, že tyto věci zvládneš dělat přímo tam.

Dynamické tabulky jsou další příklad deklarativní definice datové pipeline. Ty neříkáš, jak se data mají dostat z bodu A do bodu B, ale pouze nadefinuješ cílový stav – tady je tabulka, kterou nahráváš pomocí skriptu, třeba SQL dotazu. Snowflake platforma potom, kdykoliv jsou data dostupná na zdroji, nahrává data do tabulky s tím, že si nadefinuješ nějaký lag – tedy jak stará data mohou být. Platforma ti data postupně aktualizuje, pokud dojde ke změně. Ty jsi definoval, jak má cílová tabulka vypadat, a pokud jsou splněné určité podmínky, data se nahrávají inkrementálně – tedy přidávají se jen změny. Pokud podmínky nejsou splněné, tabulka se nahradí celá kompletní. Tohle všechno je přímo v Snowflakeu, tyto tabulky můžeš navzájem orchestrálně propojovat a získáš tak reálnou datovou pipeline.

A co tedy GenAI? A ptám se na dvě části. První je přímo v produktu – zůstaňme u funkcionalit Snowflake – má vlastní chatbota, ne? Jasně, nějakého copilota. Ten ti umožňuje psát SQL dotazy. Jak to podle tebe zjednodušuje práci, jak to teď vidíš a jakou v tom vidíš budoucnost? Určitě to zjednodušuje život, ale musí se k tomu přistupovat rozumně. Stále si myslím, že je potřeba mít znalost dat, která chceš analyzovat, a také SQL kódu, který ti systém vygeneruje, protože ne vždy bude optimální. Není to úplný „game changer“, ale pro spoustu uživatelů, kteří neumí SQL a přesto potřebují data analyzovat, existují různé způsoby, jak jim práci usnadnit...

Pokud chceš, můžu ti pomoct s další částí, stačí říct.

Tady je opravená verze textu:

Stupnit. Tohle může hodně pomoct v tom smyslu, že někteří například umí ten dotaz přečíst a vědí, co dělá, ale už ho neumí třeba zestrojit. Čili tady to používají jako nějakou nápovědu, takže si myslím, že je to dobré. Přiznám se, že to moc nepoužívám, pořád je pro mě rychlejší ten dotaz napsat, ale používám to tak, že samozřejmě nenosím v hlavě všechny funkce a fíčury, takže když nevím, jestli použít funkci XY nebo nějakou jinou, tak se zeptám. Prostě potřebuji dělat tohle, řekni mi, jakou funkci na to mám použít. Takže knowledge base? Přesně tak. Ale že bych si tam vygeneroval dotaz nebo nějakou pipeline a jenom ji slepě vzal, tak to ne.

Vidíš, že by se to mohla promítnout do jiných částí produktů, že třeba by ti to automaticky doporučovalo nějaké věci? Jo, to si myslím, že ano. Tam je obrovský potenciál například v těch optimalizacích, ať už kostů – což dneska něco podobného funguje –, kdy mají nástroj, který projde tvůj setup a třeba z pohledu bezpečnosti ti říká, že máš seznam uživatelů, kteří nepoužívají multifaktorovou autentizaci, nebo máš uživatele, kteří i když mají zapnutý single sign-on, pořád mají lokální heslo. Dělá to jakýsi security audit. Totéž si myslím, že se dá dělat na základě kostů. Když ti nástroj projde data a řekne, že máš třeba 30 tabulek, které jsi nepoužil za poslední měsíc, přitom každý den do nich nahráváš data – potřebuješ je, nebo ne? Takže myslím, že na tyhle věci rozhodně potenciál je a ano, myslím, že něčeho takového se určitě dočkáme, že to bude snadné.

Ti budou napovídat, jak platformu používat co možná nejlépe. A z druhé strany, z pohledu inženýringu, je AI čím dál víc rostoucí kategorií datového světa. Čím dál více je zde strojové učení a trochu jiný přístup než klasický BI přístup k projektům. A s generativní AI to úplně explodovalo. Takže, jak jsi říkal, že Snowflake je teď AI data platform? Jo, AI data cloud. AI data cloud, promiň, promiň. Takže to není platforma, je to celý cloud. Takže AI data cloud. Vidíš nějaký posuny a vidíš u vás, že máte víc machine learning nebo generativních AI use caseů a že platforma je na to víc připravená pustit tenhle typ workloadu a být infrastrukturou pro AI projekty, nejenom BI a data analytics?

Určitě. Myslím si, že to nebude jen Snowflake, to budou všechny velké platformy. AI dnes hýbe světem a nikdo nechce zůstat pozadu, přijde mi, že všichni do toho pumpují ohromné množství peněz, jen aby drželi krok a mohli říct, že mají XY feature, které využijete pro generativní AI. Co se týká nás, tak máme nějaké use case jak pro generativní AI, tak pro AI obecně. Máme data scientisty, kteří se snaží – dříve jsme používali SageMaker, dnes prakticky všechno běží na Snowflake v kontejnerech – takže se snaží využívat...

Pokud chceš, mohu text i více zestručnit nebo upravit styl.

Tady je opravený text:

Ty featury, které Snowflake nabízí. Jo, viděl jsem první use case v produkci, co se týká Gen.AI, byl to nějaký korporátní chatbot, který vlastně komunikuje se zákazníky a nabízí nějakou interní knowledge page jako řešení problému. Funguje to hezky, takže jo, myslím, že nás čeká zajímavá doba ve smyslu toho, že se posuneme od té doby, kdy jsme viděli spoustu vytuněných a krásných dem na prezentacích, jak to všechno může fungovat, k nějakým reálným use caseům. Najednou ty featury nejsou private preview nebo in development, ale můžete si je vyzkoušet a přemýšlet o tom, jak je využít.

Když jsme takhle prošli ten Snowflake ekosystém, jakou budoucnost predikuješ nebo na co se můžou uživatelé Snowflake těšit? Na co se ty těšíš, že se stane, nebo jaký je ten trend?

Jo, těším se. Já bych asi nebyl nejlepší v předpovídání budoucnosti, minimálně co se týká akcií Snowflake. Když sleduju jejich vývoj, tak to není úplně pozitivní. Když kupuješ, tak to padá. Přesně tak, takže to je moje nejhorší akcie asi. Takže nevím, jestli jsem ten správný, kdo by měl předpovídat budoucnost.

Ale na co se těším, nebo jak to vidím? Myslím, že bude pokračovat platformizace technologie. Je vidět, jak se snaží rozkročit do všemožných oblastí, kousnout si kousek koláče a nabídnout zákazníkům ucelené řešení. Že když už u nás máte tohle, můžete mít i tohle, tohle, tohle a máte takový vendor lock, že pak se vám hůř odchází, když už tam máte všechno vybudované. Je vidět, že se snaží šlapat i do oblasti data governance a podobně.

Na co se já těším? Zůstanu v mé oblasti, což je data engineering. Těším se, že spousta feature, které jsou zatím pořád in preview, se posunou dál a že budeme schopni ten stack zjednodušit. Místo Terraformu budeme používat nativní featury pro definici objektů a třeba některé věci budeme schopni zmigrovat z Airflow přímo do Snowflake, takže to všechno bude… pod jednou střechou.

Pod jednou střechou.

Pod tvojí Snowflake střechou.

Děkuju moc, Tomáši, držím palce a jsem rád, že tady máme takového superhrdinu v Česku, který nás takhle zastupuje ve světě. Držím moc palce všem, co nás poslouchali, a pokud chtějí vědět víc, doporučím tvůj newsletter, který je pro mě zdrojem novinek do našeho DataTalk newsletteru o Snowflake. A taky pořád máš vypsané O'Reilly kurzy, jestli se nemýlím.

Jasně, kurzy pořád probíhají, víceméně každé dva až tři měsíce je nějaká nová iterace. Fundamentals bude někdy začátkem prosince a myslím, že budou i v příštím roce, takže ať se lidi podívají na O'Reilly.com a najdou si to tam. Chystám taky videokurz, který by měl být v průběhu příštího roku. Nevím přesně kdy, ale snad bude týkat přípravy na Snowflake certifikaci, zase pod hlavičkou O'Reilly.

Super, děkujeme moc, těšíme se, držíme palce a zase někdy na viděnou.

Díky moc, čau.

Pokud chceš, můžu text ještě stylově upravit nebo zkrátit.