Snowflake, BigQuery nebo Redshift? Tak nevím… | Mňamka #36
V tomhle postu nenajdete seriozní srovnání, které nejprve stanoví kritéria, potom metodu porovnávání, ukáže zajímavé detaily z testů a nakonec spočítá body pro každý produkt. Co nabízíme, je praktický pohled na všechny 3 analytické enginy. Jo a nakonec samozřejmě srovnávací tabulku, jak jinak:-)
Redshift
Z výše jmenovaných nejdéle na trhu. Důležitá součást služeb Amazon AWS. Protože implementuje Postgres SQL dialekt i funkce (a přidává svoje vlastní), je komunita uživatelů obrovská. Každý, kdo kdy viděl nějakou PostgreSQL databázi, může okamžitě začít pracovat. Super! Protože je Redshift staršího data narození, není (narozdíl od zbývajících jmenovaných zástupců) “server-less”, ale když chcete Redshift použít, musíte si nadefinovat cluster, v něm říct, kolik uzlů bude mít, jak jsou ty uzly “velké” z pohledu vCPU, paměti a diskového prostoru. A bohužel se o něj budete muset starat jako o každý jiný databázový server. Aspoň trochu. Jasně, Amazon Redshift poskytuje jako “managed service”, takže neřešíte HW, neinstalujete updaty OS, ale např. musíte řešit, kolik diskového prostoru máte volného. Pokud je to méně, než 50%, může se vám stát, že vaše SQL queries začnou “padat”, protože Redshift během zpracování query alokuje fůru diskového prostoru clusteru. A když mu diskový prostor dojde, tak pro jistotu odpojí všechny uživatele.
Škálování je omezené na resizing clusteru. Můžete přidávat / ubírat jednotlivé uzly. Akorát to může dost dlouho trvat. Třeba i hodiny, pokud na původním clusteru toho máte uloženo opravdu hodně.
Z pohledu datového analytika nebo data “inženýra” budete muset někdy už při psaní SQL kódu myslet na optimalizaci. Bohužel. Budete muset řešit, jak se data ukládají v clusteru, jak probíhají joiny, jak jsou data setříděná. A protože první pravidlo optimalizace - “neoptimalizovat” - vede k tomu, že (naprosto správně) optimalizujete, až když je to třeba, budete svůj SQL kód obrábět neustále.
Když jsem si teď přečetl, co píšu o Redshiftu, nikdy bych si ho nekoupil. Takže, kdy chcete Redhift? Jednoduše: když máte už AWS a nebo o něm uvažujete. Když chcete super spolehlivý warehouse, který je široce podporovaný všemi možnými platformami. Když chcete luxusní analytické funkce s milionem možností. A hlavně, když chcete naprosto jednoduše a dobře řiditelné náklady. Za každý uzel vašeho clusteru totiž podle jeho typu (vCPUs, RAM, HDD) a regionu zaplatíte měsíční fee. Jednoduché, bezpečné, nemůže se vám stát, že vám Redshift vyluxuje kreditu.
Snowflake
Super, hyper, moderní, luxusní, server-less, designovaný přímo pro cloud, díky Keboole v Česku velmi známý a používaný. Dostupný u všech hlavních cloudových providerů (AWS, Azure, Google Cloud) - stačí si vybrat.
Perflektně naimplementované ANSI SQL včetně bambilionu analytických funkcí. Super na zpracovávání JSONů. Díky svoji architektuře - oddělení storage a výpočetního výkonu - a celému server-less konceptu se o nic nestaráte. Prostě tam nalejete dat, kolik chcete, nikde žádný limit. Zapnete si “warehouse” (logická výpočetní jednotka) podle libosti (volíte jen tričkovou velikost XS/S/M/L/XL) a můžete cokoli. Nic neoptimalizujete. Snowflake dělá optimalizaci za vás a poradí si s opravdu “zpraseným” SQL kódem. Samozřejmě všechny vychytávky jako více paralelních warehousů nad stejnými daty, data time-travel apod. jsou vám plně k službám.
Elasticita neomezená: data jsou ukládána na S3 (v případě AWS), takže de-facto neomezenný prostor, warehouse se dá zvětšit jediným příkazem ALTER WAREHOUSE a trvá to několik málo minut. Super!

Akorát to všechno stojí peníze:-) a ne úplně málo. Snowflake používá celkem přehledný kreditní systém, kredity is můžete předplatit a nebo platit pay-as-you-go. To je na vás. Snadno se vám ale může stát, že vás faktura za Snowflake nepříjemně překvapí.
U menších projektů se Snowflake finančně nevyplatí. Např. výkon, který vám dá XS warehouse je často stejný nebo nižší, než 1-uzlový Redshift cluster v té nejnižší konfiguraci. Za $320/mo dostanete XS warehouse pouze v režimu 5x8 (Snowflake má auto-suspend/resume mod), kdežto to samé dostanete u AWS za necelých $200/mo a to v režimu 7x24.
Takže kdy Snowflake? Když opravdu potřebujete jeho elasticitu v řádu minut. Např. normálně jede vaše orchestrace na “S” warehouse, v noci to upadne a vy potřebujete chybu opravit, “sjet to znovu” a přitom stihnout ranní deadline. Pak totiž stačí změnit velikost warehouse, dopočítat vše potřebné a pak warehouse zase zmenšit. Akorát vás tahle orchestrace bude stát minimálně 2x tolik (přechod mezi sousedními velikostmi warehouse, např. XS->S, znamená dvojnásobný počet kreditů, který potřebujete na 1hod běhu warehouse).
Ještě jeden dobrý důvod, kdy použít Snowflake: když požadavky vašeho německy mluvícího CTO obsahují aspoň 2 z následujících klíčových slov: serveless, cutting-edge, best-of-breed, highly-scalable, fully-managed… (doplňte dle potřeby). Neuděláte chybu.
Ještě jedna aktuální poznámka ke Snowflake. Ve srovnání s ostatními zde jmenovanými analytickými DB, Snowflake na můj vkus vykazuje až příliš vysokou míru výpadků v dostupnosti, což je často velmi nepříjemné, protože Snowflake umí vypadnout přesně, když to úplně nejmíň potřebujete.
BigQuery
API based analytický engine, který Google původně vyvinul pro svoji interní potřebu (třeba, aby počítal reporty v Google Analytics). Teprve potom ho dal k dispozici jako součást Google Cloud Platform. A když ho ve verzi 2 “obalil” standardním SQL, stal se z BigQuery pro mě černý panter.
O architektuře se toho mnoho nedozvíte. Jenom to, že Google je schopen alokovat dodatečné výpočetní prostředky v rámci plánování běhu každé vaší query v podstatě nad neomezenou velikostí vašich dat! Z hlediska SQL umí všechno, na co jste v ANSI SQL zvyklí, akorát např. LEFT JOIN neumí s operátorem “<” a pár dalších věcí... Spousta data lidí ale BigQuery nemá rádo. Proč? Přestože o BigQuery má v podstatě většinu vlastností, popsaných u Snowflake (server-less apod.), to co lidem na BigQuery nejvíc vadí, je, že prostě nemá žádný hejblátko, kterým by se dalo něco zrychlit nebo optimalizovat. A taky, že občas narazíte na některé limity, které BigQuery stanovuje pro váš projekt. Třeba když vaše SQL obsahuje příliš mnoho UDPATE statementů, můžete dostat chybu “Too many updates” apod. Ale řekněme si na rovinu. V podstatě limity jen ukazují na nějaký anti-pattern, který váš projekt obsahuje.
BigQuery je - narozdíl od Redshiftu a Snowflake - perfektně integrovaná do prostředí Google Cloud, takže např. v IAM můžete přímo nastavovat role jednotlivých Google účtů vůči jednotlivým datasetům (schematům), které v rámci projektu (databáze) máte. V Redshiftu je to tohle mnohem víc krkolomné, ve Snowflake v podstatě nemožné, možná v rámci jejich Enterprise edice.
Co mě nejvíc baví na BigQuery, je cenová politika. Platíte za obsazený diskový prostor a zprocesovaný objem dat. A hlavně, prvních 10GB storage a 1TB zprocesovaných dat měsíčně vám dá Google zdarma! Takže fůru dnešních tradičních analytických projektů, které nejsou datově intenzivní, lze provozovat, aniž by vás to stále jediný dolar:-) A když tyhle limity překročíte, je cenová politika velmi vstřícná.
Kdy tedy použít BigQuery? Když chcete vlastnosti Snowflake, akorát nepotřebujete mít možnost “přitopit” kreditkou výpočetní výkon, protože to prostě nejde. A když chcete moderní SQL analytický warehouse s velmi přátelskou cenovou politikou. A když vám nebude vadit, že vaši kámoši, co mají v práci Snowflake budou nad vámi možná trochu ohrnovat nos:-)
Na závěr slíbená srovnávací tabulka. Tak. Do mě milá data komunito!
@rado

Radovan Jirka
datový detektiv
LinkedIn
Microsoft Fabric vs. Power BI: Jaké jsou rozdíly? | Mňamka #496
Výběr správného nástroje pro analýzu dat může být náročný vzhledem k množství dostupných možností. Od společnosti Microsoft se nabízí dvě populární volby, kterými jsou Power BI a Microsoft Fabric. Pojďme se podrobněji podívat na jejich funkčnost, design, bezpečnost, zaměření na jednotlivá odvětví a mnoho dalšího.
Příběh transformace Crocodille ČR s Bizztreatem | Mňamka #495
🔊Jsme pyšný, že s vámi můžeme sdílej skutečný příběh, který píšeme už několik let s naším velkým klientem Crocodille ČR. Právě totiž vyšla nová epizoda Data Talku, ve které máme prostor vyprávět tento příběh! 💥 Reference je tou nejlepší zpětnou vazbou na naší práci, a tady ta reference zaznívá přímo od Jiřího Brothánka a dostává reálný hlas. 🥪 Jsme součástí transformace Crocodille ČR od počátečních někdy i bolestivých kroků, přes výzvy až po triumfy! Jiří Vicherek vede rozhovor s Jiřím Brothánkem, Head of IT v Crocodille, a naším team leaderem Tomášem Dědkem. Společně odhalují, jak jsme s Crocodille postupovali na cestě od tradičních business modelů k implementaci moderního BI a nyní i AI! 🕵️ Jsme hrdí, že můžeme být datovými detektivy pro jedny z hlavních hráčů na českém trhu.🎧Nenechte si tu epizodu ujít!
Zpracování dat z LinkedInu prostřednictvím ETL nástroje Bizzflow | Mňamka #494
Pro některé je LinkedIn pouze sociální sítí, na které mají svůj profesní profil, jen aby se neřeklo a pro některé může být LinkedIn jakási svatyně personal brandingu a navazování profesních kontaktů. Fakt, že LinkedIn generuje celosvětově až 80% B2B leadů ze všech sociálních sítí jen potvrzuje to, že zvláště pro firmy je LinkedIn skvělým místem, kde prezentovat svoje produkty či služby. V dnešní mňamce bych ráda mluvila o tom, jak jsem postupovala ve své bakalářské práci na téma Zpracování marketingových dat prostřednictvím ETL nástroje Bizzflow a v podstatě tak představit velmi krátký příběh, jak jsem se dostala z nápadu až k hotovému dashboardu.