Vlákno názorů ke článku HADOOP versus SPARK: Srovnání výkonnosti pro různé ETL úlohy od Uncaught ReferenceError: - Tohle celé vypadá špatně, nechceš se někdy stavit...

Tohle celé vypadá špatně, nechceš se někdy stavit na meetup/školení a popovídat jak to vypadá v praxi?

200GB dat je strašně málo, abys vyrovnal režii, kterou to má, hadoop a spark pořizovat na tahle malá data nemá často smysl, ta výhoda nastává až daleko dál. ETL, která v praxi výdám mají deset, dvacet a více stages, pak přesně MR selhává, důvod už vysvětlili ostatní.

Čteš všechna data a ty někam přesouváš, tam není moc výhoda těhle technologií, v praxi vidím používání sloupcových datových souborů, velké datové sady, z kterých se filtruje zlomek, který se dále zpracovává a spojuje s jinýma datama.

Dal jsi si s tím práci, ale jde vidět, že máš velké nedostatky v praxi s těmito nástroji. Připrav si daleko složitější příklady, nějaké komplikovanější ETL na zpracování dat, pak uvidíš rozdíl. Vidím v tvém popisu spousty nejasností, zmíňka, že zvednutí paměti z 32GB na 64GB nepomhla může být způsobeno komprimací ukazatelů u JVM. Rychlejší pyspark oproti scale je zajímavé vzhledem k tomu, že se na pozadí stejně spouští scala a práce se do ní překládá.

Chybí mi tady s jakými parametry sparková úloha běžela, stejně tak chybí stejná informace u hadoopu.

Ahoj Tome. Na meetupy chodím, jen jsme se tam ještě nesetkali osobně. Tohle konrétně se tam ale přece stejně neřeší! Oproti tomu konkrétně problematiku nasazení v ETL, otázky velikosti clusteru a i potenciálu Spark jsme konzultovali přímo spolu - vyměnili jsme si spolu hned několik emailů a řešili to podrobně po publikaci prvního článku.

Popsaný experiment a získané výsledky jen reflektují to, že doporučení dodavatelů technologií bývají hodně “naučené”, odpovědi na konkrétní měřitelné parametry fádní. Spíš doměnky než fakta, případně pel-mel všeho co příjde na mysl. Tohle je třeba to, co já tvrdím že je špatně. Kdybych měl takové odpovědi místo pochybností, neměl bych důvod se srovnáváním zabývat.

Jistě si vzpomeneš, že v diskuzích a příspěvcích k minulého článku se objevovaly hlavně výtky, že Spark je 100x rychlejší a nemá cenu zkoumat Hadoop a jednotlivé typy úloh, které se typicky v ETL používají. Jeden první z takových výstřelů byl právě od Tebe.

Z toho co jsme spolu diskutovali tehdy, experiment nyní ukázal, že u jednostupňových ETL úloh Spark přínos mít nebude. Čas zpracování se u popsaných ETL úloh nezkrátí. Na základě tvého komentáře i další komunikace, naopak Spark neměl mít v Hadoopu žádnou konkurenci. Optimum rychlost/cena lze z výsledků experiment očekávat již při clusteru velikosti 1+10, nikoliv jak jsi uváděl že se to “bude lámat” řádově u 100 a více. Neustále jsi omílal vysoké režie, nedokázal jsi je ale vůbec kvantifikovat. Takže jak nyní uvádíš “200GB dat je strašně málo, abys vyrovnal režii, kterou to má” – to vycházíš ze zkušeností, víš, nebo tipuješ? Velikost 200GB zcela eliminuje zkreslující vliv režie na popisované výsledky. To není doměnka, to je ověřená skutečnost jako u spousty dalších faktů, které jsem v článku uvedl.

Když si projdeš Ty, a i ostatní čtenáři vsechny příspěvky a komentáře, jsou v článku uvedené výsledky, metodika i řešené úlohy jen zpochybňovány (pokud vůbec jsou ještě relevantní k zaměření článku). Nikde jsem ale doposud neviděl konstruktivní konfrontaci přímo výsledků, metodiky, smyslu experimentu. Vše je to o tom, že je "něco" špatně (nebo dokonce vše), nesouvisející nebo tématicky hodně vzdálený link, zpochybňování teoretických a praktických znalostí, ...nebo odkazy na jiné nesourodé technologie, ...prostě téměř vždy "celkově KO".

Co je tedy vlasně špatně? Na základě jednoho experimentu dokážu lépe odhadovat režie, požadavky na HW, performance, Spark nasadit tam kde skutečně bude lepší než Hadoop (nikoliv dle bludu 100/10/3x). Tím pádem mohu lépe odhadnout pořizovací a provozní náklady, škálovat celé řešení, lépe plánovat další rozvoj. Nemusím spoléhat jen na výstřely od pasu. Mám exaktní, měřitelné a zdokumentované podklady. I když bych zjistl, že něco z toho je nepřesné, napravím to a zase mám bázi na které mohu dál stavět. Toto je tím co dle Tebe "celé vypadá špatně"?

tohle je již pokročilé téma nad úroveň toho, jaká je u meetupů poptávka, ptej se, lidi, kteří to znají z praxe tam jsou.

Tady jsi připravil ideální situaci pro hadoop, opřel jsi se o výkon disků a čekal jsi, že spark bude 100x rychlejší? Zkus svůj test upravit následně a sleduj jak se mění rozdíly i pro jednostupňovou úlohu:
- zvyš počet soubor na desítky tisíc, hadoop má velké problémy s mnoho soubory a neumí je efektivně združovat, spark se s tím vypořádává lépe
- nenačítej celou bázi dat, ale její část (tj. začni filtrovat, v praxi málokdy vidím potřebu načíst úplně vše), použij jiný formát souborů pro spark (parquet, orc), kde díky sloupcovému uspořádání si dobře rozumí s filtrováním
- přidej Hive metastore, udělej z toho tabulku, soubory rozděl do partitions a napočítej statistiky
- spark dobře neumí využít hodně paměti pro jeden proces, rozděl úlohu na tisíce executorů, každému stačí málo paměti a využij škálování do šířky, v tomhle spark exceluje proti MR

Test jsi si napsal už s nějakým předpokladem a jen jsi prokázal, že spark funguje obdobně jako MR pro čtení všeho z disku.

MR v praxi selhává ve prospěch sparku právě z důvodu, že nemáš nikdy vše ideální. Úlohy jsou složité, data mají vysokou granualitu, potřebuješ filtrovat, na clusteru máš nemalou zátěž atd.

Při nabídkách řešení nad hadoopem vždy děláme výkonnostní testy podle plánovaných úloh a jedná se o reálná měření, nedělají to tak ale všichni. Spark není vždy tou správnou volbou a opět se rozhoduji podle potřeb, dnes jsou již na výběr i další nástroje.