Názor ke článku HADOOP versus SPARK: Srovnání výkonnosti pro různé ETL úlohy od ded.kenedy - Aby ty samé řešení předvedly kdo (a jak...

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.