Názor ke článku HADOOP versus SPARK: Srovnání výkonnosti pro různé ETL úlohy od ded.kenedy - Dokážete třeba předložit opravdu důkaz, že je 10x...

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).