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