Vlákno názorů ke článku HADOOP versus SPARK: Srovnání výkonnosti pro různé ETL úlohy od ded.kenedy - Ten experiment je od zacatku blbe navrzeny. Neni...

Ten experiment je od zacatku blbe navrzeny. Neni divu, ze to vyjde +/- stejne, kdyz obe reseni delaji +/- to same.

Doporucuji precist minimalne prvni paper o RDD, kde je vysvetleno, proc muze byt RDD (spark) o rad az dva rychlejsi nez MR (hadoop). Zjednodusene by se dalo rict, ze je to zpusobem, jak resi fault-tolerance. MR uklada data mezi jednotlivymi kroky na disk, aby se k nim v pripade vypadku uzlu dalo vratit. RDD uklada pouze informaci o tom, jakymi kroky se k danemu useku dat (partition) da dopocitat v pripade, ze dany uzel vypadne. Coz vyrazne redukuje mnozstvi operaci zapisu, kterou jsou u HDFS opravdu neskutecne pomale.

Pokud mam ulohu, ktera se sklada z jedne operace map (flatMap), musi Hadoop i Spark nacist data do pameti, transformovat a ulozit, neni tam misto pro zadne optimalizace zapisu. Pokud mam ulohu, ktera se sklada z fazi map a reduce, MR (hadoop) dela jeste mezikrok (combiner, byl pouzit?), ktery opet urcitym zpusobem redukuje mnozstvi zapsanych dat na disk, takze rozdily se stiraji. Proto u takto jednoduchych transformaci je v podstate jedno, jestli pouzijes Hadoop nebo Spark.

Spark dava smysl u algoritmu, kde ten pocet kroku je vetsi, typicky u iterativnich algoritmu, kde vystup jednoho kroku vypoctu je vstupem dalsiho kroku. Tam se opravdu projevi to, ze po kazdem kroku neni potreba vsechno ulozit na disk. U uloh, ktere resim (analyza tabulkovych dat), to dava zrychleni opravdu nekde mezi 10x az 100x (podle velikosti dat a algoritmu).

Díky za komentář. Můj záměr a celá ta evoluce těch experimentů probíhala přesně naopak. Aby ty samé řešení předvedly kdo (a jak moc) je rychleší. Na začátku (a myslím jsem to i v textu zmiňoval), jsem chtěl porovnat implementaci stejné úlohy na Hadoop/MR a Spark/RDD. Očekával jsem, že Spark opravdu ukáže, že je snad až 100x rychlejší, že je 10x rychlejší s diskem, a že sort() provede 3x rychleji. No a teprve pak se dostavil výsledek. Že to vyšlo v podstatě stejně, a nedá se říct, že je Spark rychlejší v porovnáním s Hadoop jak se tvrdí (u ETL úloh), byl výsledek jedno velké zklamání.

Fault tolerance jsem vůbec neřešil, dokonce jsem v případě incidentů výsledky ihned ignoroval, abych jejich vliv eliminoval při srovnávání. Spark padá častěji a Hadoop skoro vůbec (tzn. tam by to spíš stejně bylo v neprospěch Spark). Souhlasím pak s tím, jak zmiňujete, že v rámci RDD (resp. spíše díky DAG!!!!!), SPARK může dosahovat lepších výsledků. Vracím se ale k tvrzení v článku: jestli to někde ale může zafungovat, bude to vždy na řádku co jsem naznačil. V průběhu kroku map() se u srovnávacích implementací DAG neprojeví na rychlosti, roli to začne hrát až ve zpracování následujících kroků (pozn. samozřejmě u stejné implementace na obou, u úloh kde data troughput je výrazně nad možnosti zpracování pouze v RAM, nebo podobných ETL).

A díky za zmínku "iterativních algoritmů" a více kroků v rámci jedné implementace. Právě tam DAG dá Spark(u) vyniknout. Sice to okamžitě vylučuje Hadoop ze hry (omezení pouze jedoho cyklu M-R), v kontextu ale "na co se soustředit aby Spark dával smysl implementovat místo Hadoop" je to velmi vhodná připomínka

Aby ty samé řešení předvedly kdo (a jak moc) je rychleší. Na začátku (a myslím jsem to i v textu zmiňoval), jsem chtěl porovnat implementaci stejné úlohy na Hadoop/MR a Spark/RDD.

Kdybyste se podival na to, jak a z ceho vychazi Spark, musel by vam ten vysledek byt zjevny uz od zacatku. Je to neco jako kdybyste vzal maturanta a profesora matematiky a dal jim resit ulohy z Belouna. V takovem pripade by se taky ukazalo, ze profesor matematiky neni zase o tolik lepsi nez ten maturant. Protoze to, co na tech vypoctech trva dlouho, neni vypocet samotny, ale ta rezie okolo, jako nacteni zadani a zapsani vysledku.

Že to vyšlo v podstatě stejně, a nedá se říct, že je Spark rychlejší v porovnáním s Hadoop jak se tvrdí (u ETL úloh), byl výsledek a velké zklamání.

Na zaklade tri trivialnich pripadu nemuzes generalizovat. Pokud mas ulohu, ktera je jednoduchy map, nedava to smysl, pokud ale tech transformaci potrebujes provest vic, dava Spark smysl.

Fault tolerance jsem vůbec neřešil, dokonce jsem v případě incidentů výsledky ihned ignoroval, abych jejich vliv eliminoval při srovnávání. Spark padá častěji a Hadoop skoro vůbec

Jeste jednou si precti, co jsem napsal vys. Konkretni pady nejsou vubec podstatne. Podstatne je to, ze zpusob, jakym se resi fault tolerance, se promita do architektury a prubehu vypoctu, bez ohledu na to, jestli v prubehu vypoctu doslo k padu. Jinymi slovy, protoze Spark neuklada kompletni data mezi jednotlivymi kroky, usetri se nemale mnozstvi zapisu. Pokud ale mas jeden nebo dva kroky, ten prinos se nema sanci projevit.

Vracím se ale k tvrzení v článku: jestli to někde ale může zafungovat, bude to vždy na řádku co jsem naznačil.

Ale hlavne to muze zafungovat na jinem typu ulohy. Mimochodem, na tom Hadoopu pouzils combiner? V takovem pripade by chovani melo byt hodne podobne Sparku (zapisuje se jen redukovana cast daneho bloku dat).

díky za zmínku "iterativních algoritmů" a více kroků v rámci jedné implementace. ... Sice to okamžitě vylučuje Hadoop ze hry (omezení pouze jedoho cyklu M-R),

Ale proc? Do doby nez se objevil Spark, se to delalo tak, ze data, co vypadla z map nebo reduce, se nasmerovala do dalsi iterace. Bylo to pochopitelne brutalne pomale, a proto se mimo jine objevil Spark.

je to velmi důležitá připomínka, která by měla být zmíněna poblíž všech těch závěrů, co bych si přál aby si čtenáři z článku převzali. S dovolením Váši zmínku zapracuji do textu článku. OK?

Ano, imho by se sluselo to tam mit od zacatku, protoze jinak ctenar muze nabyt dojmu, ze rychlost Sparku je jen marketingovy blud.

Ke komentářům:
Na začátku mi bylo zjevné jen jedno – že se Spark porovnává s Hadoopem a uvádí se, jak je rychlejší než Hadoop. Přitom experimenty v počátku v podstatě nedávaly vůbec důvod k přechodu na Spark. Dokážete třeba předložit opravdu důkaz, že je 10x rychlejší v práci s diskem při zpracování stejné implementace úlohy? Já osobně chápu význam takového tvrzení tak, že pomalá a náročná úloha z důvodu diskových operací, kterou implementuji v Spark/RDD, by měla být 10x rychlejší. V uvedené analogii a kontextu experimentu by zmíněné tvrzení a vystřízlivění bylo: “Professor je 10x rychlejší” a pak, když jak uvádíte, by professor nebyl rychlejší, zklamání z toho tvrzení by bylo opět analogicky to samé a stejné. Profesor vs. student, Spark vs Hadoop, není tak rychlý jak se tvrdí.

Připomínku k pádům, resp. k řešení fault-tolerance a relevanci k experimentům (I přes skutečnost, že jsem se naopak snažil problematické běhy úloh vyřadit a zcela eliminovat vliv na výsledky) prosím ještě více rozveďte, nebo upřesněte. Moje neporozumění Vašeho komentáře vychází z poznatků, že filosofie zpracování dat v RDD je založena na acyklických grafech (DAG). Tento přístup umožní rozložit (rozplánovat) celou úlohu do meších úloh granularizovaných optimálně pro umožnění distribuovat práci po nodech clusteru a současně i do kroků (partikulárních operací jako map, transformace, join, …apod). To vše (v podobě plánu) se připraví ještě před začátkem zpracovánání dat a node(s) začnou zpracovávat data podle své části plánu. Plán je až tak podrobný, že v průběhu zpracování každého kroku zpracování je zřetelné, jaké fragmenty dat jsou potřebné a pracuje se jen s tím (nepotřebné se ignoruje a tím dochází ke zrychlení zpracování). Následně kdykoliv v průběhu zpracovávání - když node spadne, vezme se jeho “plán” a přiřadí se jinému. Tuto eventualitu jsem vždy ignoroval a význam popisované “fault-tolerance” spíš vidím až v oblasti a případech srovnání možností “self-recovery” (takže Hadoop z kola ihned ven).

Možná, podle části kde v souvislosti o rychlosti Sparku uvádíte – cituji “paper o RDD, kde je vysvetleno, proc muze byt RDD (spark) o rad az dva rychlejsi nez MR (hadoop). Zjednodusene by se dalo rict, ze je to zpusobem, jak resi fault-tolerance”.
Tohle je spíš lépe vztahovat přímo k DAG než k “fault-tolerance”, nebo se pletu? Tzn. potřebu upřesnění vidím především v tom, že Spark by mohl být rychlejší o řád až dva nikoliv díky faul-tolerance, ale díky tomu, ze používá DAG. Až z toho pak přece teprve vyplývá potenciál rychlejšího zpracovávání dat, současně s elegantním vyřešením požadavků na fault-tolerance. Souhlasíte, nebo poukazujete na něco jiné?

Dokážete třeba předložit opravdu důkaz, že je 10x rychlejší v práci s diskem při zpracování stejné implementace úlohy?

Nezlob se, ale nemam v planu vyhazovat cas a penize za to, abych zjistil, jak extra pomaly je Hadoop. Pokud te to zajima, navod, jak takovy experiment zkonstruovat, jsem ti nabidl vyse.

Já osobně chápu význam takového tvrzení tak, že pomalá a náročná úloha z důvodu diskových operací, kterou implementuji v Spark/RDD, by měla být 10x rychlejší.

Stale to nechapes. Uloha, ktere vyuziva diskove operace a celkove vyuziti diskovych operaci jsou dve naprosto odlisne veci. V prvnim pripade se jedna o diskove operace nutne ke zpracovani samothne ulohy, v druhem pripade o operace, ktere zahrnuji i rezii celeho systemu. A to je presne to misto, kde je Spark lepsi nez Hadoop.

Tuto eventualitu jsem vždy ignoroval a význam popisované “fault-tolerance” spíš vidím až v oblasti a případech srovnání možností “self-recovery”

To je ale zasadni problem, na ktery se tu snazim celou dobu upozornit. Hadoop fault-tolerance zajistuje tim, ze vsechna data jsou po provedeni kazdeho kroku materializovana na disk, coz muze znamenat obrovske mnozstvi diskovych operaci bez ohledu na to, jestli k nejakemu padu doslo, nebo ne. Spark si mezi kroky uklada jen jednotlive transformace (DAG, chces-li), cimz se vyrazne eliminuje mnozstvi diskovych operaci.

Tohle je spíš lépe vztahovat přímo k DAG než k “fault-tolerance”, nebo se pletu? Tzn. potřebu upřesnění vidím především v tom, že Spark by mohl být rychlejší o řád až dva nikoliv díky faul-tolerance, ale díky tomu, ze používá DAG.

Pletes se, precti si ten paper: https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final138.pdf

RDDs provide an interface based on coarse-grained transformations (e.g., map, filter and join) that apply the same operation to many data items. This allows them to efficiently provide fault tolerance by logging the transformations used to build a dataset (its lineage) rather than the actual data.

A protoze diskove operace jsou ty nejpomalejsi, tak toto je opravdu klicova vlasnost. DAG (zminene "transformation used") je jen zpusob, jak popsat operaci s daty. To zrychleni je hlavne v tom, ze u slozitejsi transformaci neni potreba materializovat jednotlive kroky (jako u hadoop), aby byla zajistena fault-tolerance.

Až z toho pak přece teprve vyplývá potenciál rychlejšího zpracovávání dat, současně s elegantním vyřešením požadavků na fault-tolerance.

Ta kauzalita je tam presne opacne. Neni problem sestavit operace (DAG), to dela kazdy programovaci jazyk, ale zajistit efektivni fault-tolerance. Nejjednodusi je delat checkpoints, a po kazdem kroku ulozit vsechna data, aby se v pripade vypadku k nim dalo vratit. Pokud se ale data maji ukladat ve vice instancich (HDFS), je to brutalne pomale, proto Spark prisel jen s ukladanim transformaci a ty jsou prave ve forme DAG.

Dava to smysl, u distribuovanych systemu se musi s vypadky uzlu nezbytne pocitat, ale i tak nastavaji jen zridka. U MR je zotaveni po vypadku uzlu rychlejsi (proste data cte jiny uzel), ale je to za cenu toho, ze bezne operace jsou nasobne pomalejsi nez by bylo nutne (protoze se vse musi zapsat na disk).