Názor ke článku HADOOP versus SPARK: Srovnání výkonnosti pro různé ETL úlohy od ViR - Ke komentářům: Na začátku mi bylo zjevné jen jedno...

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é?