Hlavní navigace

HADOOP versus SPARK: Srovnání výkonnosti pro různé ETL úlohy

22. 3. 2020 16:08 (aktualizováno) Vilém Řezníček

Spekuloval jsem před časem o výhodách nasazení HADOOP řešení jako náhradě za několik existujících a velmi pomalých ETL úloh. Výsledky experimentu je možné najít zde - v minulém článku. Jestli otázkou tehdy bylo, zda tehdejší úlohy je vhodné nahradit řešením HADOOP/MR nebo nikoliv, nyní experimenty už vedly k ověřování jak by dále zpracování urychlil SPARK. Tzn. budu zde popisovat srovnání implementace dvou jednoduchých (dle mého názoru typických skeletů) ETL úloh, vždy naprosto stejně implementovaných v Hadoop MR a Spark RDD. 

Nejdříve musím přesněji definovat ETL úlohu. Jedná se o takovou úlohu, která na vstupu zpracovává velký objem dávkových dat (je už vhodná paralelizace zpracování dat, vyžadující škálovatelnost úložného diskového prostoru), skládající se typicky z operace načítání, mapování, join/tag, reduce, filter, nezřídka sort, ukládání do cílového úložiště. Velký objem dat na výstupu není vyloučený. Typy úloh charakteristické pro ML, AI, regrese, zpracování datasetů pro vědecký výzkum není předmětem tohoto článku. Důvod je jednoduchý – jsou to úlohy typicky pro Spark, srovnávání s Hadoop MR nedává vůbec smysl. 

Když se zaměříme na vyhledávání srovnání obou technologií, to nejčastější a notoricky opakované, na co zcela určitě narazíte je toto: 

  • SPARK má být 100× rychlejší (NENÍ, U BĚŽNÝCH ÚLOH ZCELA URČITĚ NE) 
  • SPARK má být 10× rychlejší u úloh vyžadující diskové operace (NEMOHU POTVRDIT) 
  • SPARK má být 3× rychlejší u úloh kde je třeba SORT (NEMOHU POTVRDIT) 

Zde chci ihned podotknout a kontrovat komentářům – až na výjimky, tvrzení běžně neurčují, u jakých typů úloh tomu tak (hypoteticky) může být. Dá se tedy očekávat, že na základě takového tvrzení i typicky ETL úlohy mohou být na SparkRDD rychlejší v porovnání s Hadoop MR. Nenašel jsem nikde žádné výsledky reálného a podrobného srovnání jednoduchých úloh, které by to potvrzovaly.

Z tohoto důvodu jsem provedl několik experimentů. Implementoval 3 páry jednoduchých úloh (Hadoop/MR a Spark/RDD), vybrané a navržené speciálně proto, aby ukázaly, jak jsou tato tvrzení pravdivá. Bohužel ani v jednom případě provedených experimentů a srovnávání SPARK zdaleka nesplnil očekávání dle dokola opakovaných tvrzení (viz. výše : 100×10×3 rychlejší). Zde je ale nutné ještě jednou zopakovat – jednalo se vždy o případy implementace typicky ETL úloh. Jednoduché operace, náročné ale na  objem zpracovávaných dat.

Z předchozích experimentů jsem vycházel z poznání, že pokud úloha běžela (dlouho) na jednom stroji (ETL job napsaný v Javě – single thread), stejná logika implementovaná v MR a přenesená do experimentálního clusteru 1+3, způsobila nárůst režie a zpracování pak v Hadoop mini-clusteru trvalo 3 až 5× déle. To je první cena co platíte, když migrujete na Hadoop. To platilo pro jednoduché úlohy typu MAP-SIDE-JOIN. U jiných typů ETL úloh to bylo ještě déle, dokonce i 40× u typu reduce-side-join. To samo o sobě ale není překvapení. Nicméně, nárůst režie byla pořád přijatelná cena za to, co dostanete k tomu. Je to především snadná škálovatelnost díky HDFS a paralelnímu zpracování, vyřešení fault-tolerance apod. Logicky tedy, ihned další otázkou bylo, kam až se musí s velikostí clusteru jít, aby to mělo (hlavně) udržitelný ekonomický smysl a jaké zvětšování clusteru přinese zpracování v “rozumném čase”. Přechodem na cluster 1+3 v podstatě, i v tom lepším případě, došlo k degradaci výkonu na úroveň 11% výkonu (paralelizované řešení při takto malé velikosti clusteru zpracuje za trojnásobný čas to samé, co zvládl předtím jeden dedikovaný stroj). Při takové ztrátě ihned položíte otázku, je něco rychlejšího než Hadoop? Snad ano, Spark to ale bohužel většinou není…

Cíl experimentu – srovnání rychlosti Hadoop/MR vs Spark/RDD

Experimenty jsem provedl v prostředí AWS. Tam jde testovací úlohy spouštět “izolovaně od produkčních prostředí“. Především proto, že šlo snadno parametrizovat testy, experimentovat s různou velikostí clusteru, používaného HW (počet jader a paměti) apod. Na clusteru v jeden okamžik jsem vždy spouštěl pouze jednu úlohu, aby výsledný čas reflektoval pouze jednu úlohu a nebyl ovlivněný úlohou jinou (což v produkčním, nebo v limitovaném testovacím prostředí v reálných podmínkách je nemyslitelné). Další výhodou testování s využitím cloudových služeb (Azure, GCP, AWS) je, že lze snadno předpokládat, že je vše odladěné a ani jedna z technologií není hendikepována třeba špatným nastavením apod.

Srovnávané implementace úloh

Pro účely testu a srovnávání byly použité (účelově) tyto úlohy, pokaždé implementované jak v HADOOP/MR, tak i v SPARK/RDD (Scala, případně PySpark).

  • Úloha analýzy sentimentu v textu – v podstatě všem notoricky známá úloha, kterou každý vyzkouší ihned po “Hello world” když začíná experimentovat s BigData (většinou se pro analýzu využívá dataset z twitter.com).  Věta se rozloží na jednotlivá slova, identifikují se slova vyjadřující sentiment (join), dle výskytu pozitivních nebo negativních slov se určí sentiment celé věty (tag – P nebo N). Tag se umístí na konec věty a uloží zpět na disk. Tato úloha byla vybrána z důvodu flexibility pro účel testu. Lze ji implementovat jak pouze v kroku map, tak i včetně kroku reduce. Join lze samozřejmě uskutečnit též v libovolně v každém z kroků. Implementace je z perspektivy srovnávání stejná pro Hadoop/MR (Java) a Spark/RDD (Scala). Proč to vše? Jak pro Hadoop tak i pro Spark je vidět, jak se projeví zvolený typ implementace, oba zpracovávají stejný objem dat, stejný objem dat si předávají mezi jednotlivými kroky (map či reduce) a stejný objem dat se ukládá na výstupu. Když odděláte krok reduce(), máte přehled, kolik času zabral pouze krok map(). To byl přesně záměr pro dekompozici faktorů, posuzování a srovnávání. Potvrdí pak výsledky, zda je skutečně Spark rychlejší?
  • Úloha určení hodnoty čísla PI metodou Monte Carlo – přesný popis je zde, zjednodušeně vygenerujete náhodně body (x,y) v definovaném čtverci, v něm uvažujete vepsaný kruh. Z poměru bodů uvnitř a vně vepsané kružnice lze odvodit číslo PI. Oproti však příkladům, co lze běžně najít, pro účely testu byly náhodné souřadnice vždy načítané z disku. Tento typ úlohy byl zvolen též zcela účelově – opět lze srovnat rychlost práce s diskem a zpracování lze též implementovat v obou případech shodně. Co je ale jiné oproti analýze sentimentu je fakt, že výstup z kroku map() se redukuje pouze na dvě hodnoty (vně či uvnitř kroku). Proč? Dozvíte se později. 
  • Základ úlohy určení hodnoty čísla PI metodou Monte Carlo, modifikovaná však pro srovnání operace sort() – předchozí typ úlohy v tomto případě byl mírně modifikovaný – místo redukování na dvě hodnoty (vně/uvnitř), výstupem kroku map() byly souřadnice analyzovaných bodů a jejich vzdálenost od bodu (0,0). Právě dle této vzdálenosti se body setřídily a následně uložily do výstupního souboru. Předpokládal jsem, že z výsledků předchozích úloh už bude patrné o kolik je Spark rychlejší v práci diskem a bude možná dekompozice vlivu rychlosti a posoudit „samostatně“ rychlost operace sort().

POZN: Na základě reakcí v komentářích zde musím zdůraznit – cílem je srovnat Hadoop a Spark. Proto každý typ úlohy musel být implementován v Hadoop/MR a též to samé I v Spark/RD (Scala). Navíc úlohy byly vybírány tak, aby je bylo možné smysluplně rozložit na elementární (a v ohledu na výsledky) izolovatelné kroky. Jedině tento přístup umožní dekompozici faktorů výsledků srovnávání. V opačném případě by to bylo jako srovnávat “jablka s hruškama”. 

Výsledek srovnání

Závěry dělám z testování v prostředí Amazon AWS v rámci POC, každý typ úlohy zpracovával 200GB vstupní soubor, použitý HW (pokud neuvádím v textu jinak) m5×.large (master i nodes). Srovnání nejsrozumitelněji prezentuje níže uvedený graf. Z celkového množství testů předkládám výsledky z testování na 3. velikostech clusteru (1+7 modře, 1+12 červeně a 1+15 žlutě), hodnoty reprezentují délku zpracování úlohy, vedle sebe jsou výsledky HADOOP vs SPARK, pro vybrané typy úloh.

Závěr

Při srovnání úloh map and reduce Spark nedosahoval lepších výsledků (snad dokonce byl i mírně horší). Tzn.  

  • tvrzení, že je Spark 10× rychlejší při práci s diskem nemohu potvrdit. 
  • Nelze ani potvrdit, že Spark je 3× rychlejší při operaci sort(). Výsledku jsou téměř totožné.
  • Co dle výsledků nelze potvrdit (tím pádem tento zaužívaný blud ani zcela vyvrátit) je fakt, že Spark může být až 100 rychlejší. U ETL (což byl hlavní účel srovnávání) tomu tak zcela určitě není.

K čemu tedy Spark?

I přes zklamání, že Spark asi není tím ultimátním řešením pro výrazné zrychlení ETL úloh, jeden typ úlohy dal záměrně Spark technologii šanci excelovat. Když se pozorně zaměříte na srovnání úlohy pro určení hodnoty čísla PI (π MONTECARLO MapAndReduce), uvidíte, že Spark dokončil úlohu za zlomek času potřebného na stejné zpracování Hadoopem. Spark provedl v maximálně možné míře veškeré toky dat a operace v paměti, oproti tomu Hadoop provedl operaci map(), uložil mezivýsledky na disk a pak následně vše znovu načetl pro zpracování v kroku reduce(). Proto je zde SPARK dosahuje takového zkrácení času zpracování.

Jednoduše : U úloh zpracovávajících velký objem vstupních dat, kde nelze veškeré zpracování provést  jen v operační paměti, pouze v případě operaci reduce() lze provést ve velké míře v operační paměti, bude Spark zřetelně rychlejší než Hadoop. Buď ušetříte zde a SPARK bude rychlejší, nebo je jedno, zda provedete implementaci v Hadoop MR nebo Spark RDD.

Zjednodušeně, rozhoduje pouze a jen tento řádek:  

POZN: Na základě jednoho komentáře zde je ještě dobré doplnit, že pokud v rámci zpracování úlohy aplikujete několik cyklů map-reduce, bude Spark též s velmi pravděpodobně rychlejší, nebo alespoň implementace jednodušší. V případě řešení Hadoop to lze realizovat pouze kaskádou samostatných MR procesů (vyžadujících načítání a ukládání dat mezi kroky/úlohami), což Spark díky způsobu zpracování nevyžaduje (viz DAG). 

Další postřehy z experimentů

  • Za celou dobu experimentů, i v praxi, se mi zdá, že SPARK „padá častěji“ (DAG). Pozorovatelně víc, než Hadoop.  
  • Všechny testy a časy jsou měřené vždy při běhu jediné úlohy na clusteru, nicméně i při několika experimentech, kdy úlohy byly spuštěné všechny v jeden okamžik současně, celková doba dokončení všech úloh byla skoro stejná (někdy o 3–5 procent kratší). Z toho si lze vyvozovat, že tyto poznatky co uvádím, jsou relevantní i pro odhady v reálných provozních podmínkách, kde úlohy běží konkurentně.  
  • V experimentech na AWS v nadpoloviční většině PySPARK byl mírně rychlejší než SCALA (běžně o 3–5 procent rychlejší). Proč tomu ale tak je se mi nepodařilo zjistit. 
  • Při experimentech s velikostí clusteru (1+7, 1+12 a 1+15) při stejném použitém HW byly výsledné celkové náklady na zpracování úloh téměř stejné. Pouze u jedné úlohy (π MONTECARLO MapAndReduce HADOOP) náklady vzrostly o 25% u velikosti clusteru 1+15 oproti konfiguraci 1+7. Pro zbytek úloh se celková cena neměnila. Tzn. pokud zpracování provozujete v cloudu, cluster si “nastartujete” pouze na dobu zpracování dat (jak je tomu u AWS, kde jsem testy prováděl), dává smysl zvolit větší cluster, dokončit úlohu v kratším čase a zaplatit stejně jako u menšího clusteru, který by zpracovával úlohu delší čas. Podotýkám, že zcela zodpovědně mohu potvrdit, že do zpracování byl vždy zapojen každý node clusteru (současně tedy vždy pracovalo 7, 12 a pak i 15 instancí na jedné spuštěné úloze, nikoliv pouze některé ze zmíněných 15-ti) 
  • K podobnému zjištění jsem dospěl při experimentech s různým HW (m5.xlarge, m5.2×large a m5.4×large) při stejné velikostí clusteru (1+7). Výsledné celkové náklady na zpracování úloh byly opět téměř stejné. Pouze u úloh (π MONTECARLO HADOOP) náklady vzrostly o 100% u m5.4×large oproti m5.xlarge. Pro zbytek úloh se celková cena neměnila. Pro zajímavost uvádím, že provoz jednoho uzlu m5.4×large (16 core/64GB) Vás stojí v nákladech 4× více, než m5.xlarge (4 core/16GB). 
  • V začátku článku jsem uvedl, že po migraci jednoduchých úloh na Hadoop vlivem režií narostla doba zpracování stejných úloh (ale implementovaných v MR) asi 3×. Až při velikosti clusteru 1+7, což je výrazná degradace výkonu, se doba zpracování vrátila zpět na stejnou hodnotu. Tzn. v případě těchto experimentů jeden „stroj“ nahradí cluster (stejné HW) o velikost 1+7 (instance m5.xlarge, 4core, 16GB).  Při zvětšování velikosti clusteru do úrovně 1+10, při stejném použitém HW,  byl patrný efekt ve výrazném zkracování doby zpracování dat. S dalším rozšiřováním se přínos snižoval
  • Tvrdí se, že SPARK exceluje na HW kde je dostatek RAM (100GB+). Při experimentech jsme měnili současně velikost paměti a počet dedikovaných jader. Nárůst výkonu byl patrný při přechodu z 16GB na 32GB, přechod 32GB na 64GB už nebyl tak výrazný a další vylepšování už vzhledem k ceně pořízení/provozování takového HW v našem případě by stejně nepřicházelo v úvahu. SPARK je skutečně možné považovat za „mírně“ rychlejší řešení.   

Poznámka na konec: Toto je druhý, mírně přepracovaný obsah článku. Na základě komentářů od čtenářů jsem v některých pasážích udělal změny pro lepší srozumitelnost, zdůraznil některá fakta a zakomponoval i některé z podnětů z komentářů. Oproti prvním článku jsem se rozhodl komentáře pod článkem ponechat. Doporučuji si je pročíst a udělat si úsudek svůj.

Sdílet

  • 10. 2. 2020 10:18

    Murphy

    Díky za článek, jedinou podobnou práci (bez těch marketingových keců) jsem našel zde, je sice staršího data, ale stále určitě relevantní k vašemu článku: 2015_LiuLu_MS­.pdf. Jsou tam pěkně udělané grafy zátěže memory a cpu, tam je pak pěkně vidět, kde je Spark pomalejší a kde rychlejší (viz. rozdíl zpracování Hadoop "na disku" a Spark "v paměti").

  • 10. 2. 2020 17:55

    ViR

    Díky za komentář a link. Samotný dokument jsem neviděl, ale ty výsledky srovnání jsem už viděl publikované (bez kontextu toho paperu to publikoval asi ještě někdo jiný). Až na vyjímky, ani tam ale výsledky rozhodně neukazují, že je Spark tak rychlý, jak se obecně tvrdí. Když jsem dělal své experimenty, chtěl jsem hlavně vidět tu problematiku odděleně. Tzn. jak jedou úlohy které čistě závisí na práci s diskem (bez možnosti vykonat operace pouze v RAM), sort(), join() apod. Je potěšující, že v dokumenty uvedené výsledky spíš výsledky tohoto experimentu potvrzují, než vyvraceji :).

    PS: Sorry pokud ten popis experimentů působí jako "marketingové kecy". Záměrem bylo zmínit relevantní informaci, kde jsem experimenty dělal a na jakém konkretním HW. Nic tendenčně ve prospěch "Ama....u". Z toho co bylo dostupné mi vybraná služba pro experimenty byla nejpřístupnější.

  • 10. 2. 2020 14:46

    ded.kenedy

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

  • 10. 2. 2020 19:26

    ViR

    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

  • 10. 2. 2020 21:00

    ded.kenedy

    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.

  • 11. 2. 2020 11:32

    ViR

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

  • 11. 2. 2020 14:37

    ded.kenedy

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

  • 11. 2. 2020 15:28

    ViR

    Do dalšího vývoje tohoto vlákna z pozice autora článku a moderování směru diskuze jsem se rozhodl už dál nestupovat. Význam DAG, kauzalitu, včetně porozumění anglického textu (a pak i okolního kontextu odkud pochází) chápu rozdílně.
    Za komentáře však, veškeré další příspěvky a názory ( to i od jiných čtenářů) však budu vděčný. Ponechávám proto další diskuzi nadále otevřenou.

  • 11. 2. 2020 16:59

    ded.kenedy

    Význam DAG, kauzalitu, včetně porozumění anglického textu (a pak i okolního kontextu odkud pochází) chápu úplně rozdílně.

    To je problem. Podivej se jeste treba na jeden z uplne prvnich clanku z roku 2010: https://amplab.cs.berkeley.edu/wp-content/uploads/2011/06/Spark-Cluster-Computing-with-Working-Sets.pdf

    Klicove slovo DAG tam nenajdes ani jednou, za to fault tolerance se to jen hemzi.

    (a pak i okolního kontextu odkud pochází)

    Jaky okolni kontext mas na mysli?

  • 14. 2. 2020 17:47

    Uncaught ReferenceError:

    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.

  • 16. 2. 2020 23:44

    ViR
    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ě"?

  • 21. 2. 2020 21:59

    Uncaught ReferenceError:

    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.

  • 16. 2. 2020 15:02

    bez přezdívky

    Tohle je velice nešťastný článek. Souhlasil bych s autorem snad jen v tom, že pro něj Hadoop ani Spark nebudou tím, co hledá. A pak s tím, že opravdu existují úlohy, kde to má smysl a objem vstupu a složitost transformace a počítání jsou takové, že na jednom stroji je to nepraktické.
    Dopručil bych ke čtení např. Anatomy of flawed microbenchmark https://www.ibm.com/developerworks/library/j-jtp02225/index.html a pak zamyšlení jestli má smysl měřit počítání Pí pomocí Monte Carlo nebo zpracovávat 200GB dat a vyvozovat závěry o Hadoopu či Sparku. K tomu druhému snad také https://www.chrisstucchio.com/blog/2013/hadoop_hatred.html z roku 2013. Dnes jsme zase jinde. Měřit na AWS a zahazovat výsledky, které nezapadají do (pochybně) zvolené koncepce měření.

  • 17. 2. 2020 11:58

    ViR
    Radime,

    Neodhadnu nyní co tím míníš, když píšeš "že pro něj Hadoop ani Spark nebudou tím, co hledá". Domnívám se, že jsi to jen četl zrychleně a spoustu podstatných informací jsi přehlédnul. Nehledal jsem řešení, srovnával jsem, hledal jsem dál možnosti jak by už existující H/MR řešení Spark dále urychlil.

    Opodstatnění zahrnutí úlohy odhadu čísla PI do experimentu, objem dat použitých pro test, stejně jako zmínka o zahazování výsledků, AWS,...to vše by bylo možné opět vysvětlovat, doporučuji ale raději pozorně vše ještě jednou přečíst..