Hlavní navigace

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

10. 2. 2020 15:06 (aktualizováno) Vilém Řezníček

Po dlouhé době, toto je zase krátké navázání na experimenty. Tentokrát  s Hadoopem a Sparkem. Před časem jsem spekuloval o výhodách nasazení HADOOP řešení jako náhradu za několik existujících a velmi pomalých ETL úloh. Výsledky experimentu je možné najít zde. Jestli otázkou tehdy bylo, zda tehdejší úlohy je vhodné nahradit nebo nikoliv, poslední experimenty už vedly k ověřování, jak by dále zpracování urychlil SPARK. Už v tu chvíli, kdy jsem výsledky publikoval, jsem obdržel mnoho komentářů že Hadoop je už pomalá technologie a jediným smysluplným řešením už je jen SPARK. 

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 je 100× rychlejší (NENÍ, U BĚŽNÝCH ÚLOH ZCELA URČITĚ NE)
  • SPARK je 10× rychlejší u úloh vyžadující diskové operace (NEMOHU POTVRDIT)
  • SPARK je 3× rychlejší u úloh kde je třeba SORT (NEMOHU POTVRDIT)
Nenašel jsem nikde žádné výsledky reálného srovnání, od dob prvních experimentů jsem poté vždy zahrnoval do srovnávání i SPARK. Bohužel ani v jednom případě SPARK zdaleka nesplnil očekávání dle dokola opakovaných tvrzení (viz. výše : 100×10×3 rychlejší). Až teprve nedávno se mi podařilo experimenty provést souhrnně v prostředí AWS. Tam jde testovací úlohy spouštět “izolovaně od produkčních prostředí“, šlo snadno experimentovat s různou velikostí clusteru i používaného HW (počet jader a paměti). 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í v 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. Výsledky tak mají “pěkné kontury” a není třeba zahrnout do úvah ovlivnění okamžitým vytížením clusteru, běžícími úlohami, i jednotlivé testové úkoly byly psané pro srovnání konkrétních (srovnávacích) parametrů.
Co jsem chtěl ověřit
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 (než zpracování na jednom stroji). 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.
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. 
Pro účely testu a srovnávání byly použité (účelově) tyto úlohy, 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ístní 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 i 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šach 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. 
  • Úloha určení hodnoty čísla PI metodou Monte Carlo modifikovaná 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().
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).
  • 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 (současně ale však 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í.
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í velký objem vstupních dat, kde nelze veškeré zpracování provést  jen v operační paměti, pouze v případě,  že naproti tomu samotnou 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.
Zjednodušeně, rozhoduje pouze a jen tento řádek:  
Kromě jiného, ještě několik postřehů:
  • Za celou dobu experimentů, i v praxi, se mi zdá, že SPARK „padá častěji“ (GAG). 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) a 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í narosla 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). 

POZN: Součástí experimentů bylo i testování jak se projeví na rychlost zpracování dat změna HW a velikost clusteru. Výsledky lze shrnout takto:
  • 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í. Obecně – subjektivně bych řekl pro typické ETL úlohy „až 1.5× – maximálně a se skřípěním zubů!“. Jediná úloha, kde potvrdil svoji převahu (řekněme 10×), byla úloha, kde SPARK nevyžaduje diskové operace mezi kroky MAP a REDUCE ( π MONTECARLO MapAndReduce HADOOP versus π MONTECARLO MapAndReduce SPARK). Tyto dvě úlohy byly specificky navržené pro tento účel, dát možnost SPARKu předvést, jak v rámci RDD provede krok REDUCE rychleji než HADOOP. 

Přístě se pokusím srovnat úlohy non-ETL typu. Když se tvrdí že je jeden 100× rychlejší, tak určitě nějaké existují. Jinak by to tvrzení byly jen marketingové bludy donekonečna opakované a citované :-) 

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 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. Co je ale potěšující, a to vidím teď v tom článku, jsou výsledky srovníní úloh s implementací K-MEANS a Naive Bayes. Na Hadoop bych to nikdy v reálu nenasadil, to srovnání ale přesně sedí s tím, co bych od toho teď na základě svých výsledků očekával. Opět ale, pokud půjdeme do detailu, celé to spočívá v analogicky pouze a jen k soustředění se k tomu řádku kódu, který jsem uvedl :-) Díky za odkaz!!!!!

    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

    bez přezdívky

    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ář, chápu hned tu první větu. 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 a 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íš 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. To jste uděřil hřebíček na hlavičku. 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 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?

  • 10. 2. 2020 21:00

    bez přezdívky

    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

    bez přezdívky

    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. Je už nyní mimo hranice, kde bych si přál diskuzi držet a zachovat ještě konzistentnost s článkem. 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

    bez přezdívky

    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?

    Je už nyní mimo hranice, kde bych si přál diskuzi držet a zachovat ještě konzistentnost s článkem

    Chapu, ze zachovavat konzistentnost s clankem je trochu problem, kdyz ty experimenty jsou od zacatku spatne navrzene, viz muj prvni komentar.

  • 14. 2. 2020 17:47

    Tomáš2

    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 (asi) ještě nesetkali osobně. Konkrétně problematiku nasazení v ETL, otázky velikosti clusteru a i potenciálu Spark jsme přímo konzultovali - vyměnili jsme si spolu hned několik emailů a řešili to podrobně po publikaci prvního článku. Jak jsem psal v úvodu článku tohoto - je to srovnání Hadoop a Spark, úlohy jsou jednoduché, úplně stejné, aby se nesrovnávaly "jablka s hruškama". Účelem bylo publikovat výsledky jednoduchého srovnání a dokonce je to inspirováno naší předchozí komunikací. Stejné úloha implementována v obou technologiích. Mám rád experimenty a jejich výsledky rád konfrontuji s doporučením konzultantů a dodavatelů technologií. Kdybych od nich měl takové odpovědi místo pochybností, neměl bych důvod se srovnáváním zabývat :-)

    V kontrastu neustále opakovaných tvrzení o rychlosti a srovnávání jsem udělal srovnání pro sebe, případně i další, kdo by o tom měl pochybnosti a zajímal se o to. 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 komentářů byl i od Tebe.

    K velikosti souboru: uváděných 200GB mohu na základě několika testů označit za zcela reprezentativní vzorek dat k účelu srovnání. Vycházím z výsledků jak 50, 100, 200 GB, tak i testu až s 500TB. To byl jeden z prvních elemetárních testů. 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. Ironie toho všeho je, že účel toho všeho bylo reagovat "právě na to, jak se to (slepě) dělá v praxi" a to, že jsem chtěl znát jak je to ve skutečnosti. Na základě vlastních experimentů. Z toho co jsme spolu diskutovali tak experiment ukázal, že u jednostupňových ETL úloh Spark přínos mít nebude (čas zpracování se nezkrátí 100x), že optimum rychlost/cena lze běžně očekávat při clusteru velikosti 1+10 (nikoliv jak jsi uváděl že se to bude lámat řádově u 100 a více).

    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 konfrontaci přímo výsledků co uvádím. Výsledků konkrétního experimentu dle popsané metodiky a stanoveného cíle. Tzn. že někdo uvede konkrétně typ implementace úlohy, metody, experimentu (MR vs RDD), kde dosáhl jiného nebo podobného výsledku. 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".

    Po předchozí zkušenosti už jsem tušil, že budu muset počítat s něčím podobným. Očekával jsem ale přesto, že zareagují profesionálové v oboru a zmíní více hintů, jako je třeba Tebou zmíněná komprimace ukazatelů. Konkrétně toto je přesně příklad, co by si zasloužil více rozvést, pokud k tomu tedy máš konkrétní poznatky. I když jsem nic takového experimentálně neověřoval, očekával bych stejně zlepšení jen v jednotkách procent, nikoliv zlepšení 100x víc, ani 50x a ani 2x. Ty zcela určitě máš k tomu přesnější informace a je škoda, že se o to nepodělíš. Takhle to má cenu jenom "střílení od pasu"... Přitom zcela určitě vím, že by o tyto informace měli zájem i jiní čtenáři.
  • 16. 2. 2020 15:02

    Radim Kubacki

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

  • Včera 11:58

    ViR

    Radime,

    možná to v úvodu bude nutné zdůraznit - Hadoop je (spíše pro mne bylo) výchozí řešení, celé je to o tom, že jsem se v článku snažil o srovnání se Sparkem. Abych mohl potvrdit, nebo vyvrátit, že Spark je/není 100/10/3x rychlejší, jak se neustále dokola a slepě opakuje a tvrdí. 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í, hledal jsem dál možnosti jak zpracování urychlit :-)

    Zjednodušeně by se to dalo vysvětlit - chtěl jsem aby čtenáři bylo zřetelné, že pro ETL (až na vyjímku co jsem popsal) by nemělo cenu migrovat existující MR na Spark, pokud by někdo očekával slepě, že to tím zrychlí. Nedá se očekávat v podstatě žádné pozorovatelné zrychlení ETL u typů úloh založených na popsaných vzorech. Naopak má být zřetelné, že se dá očekávat zvýšený podíl padajících jobů, počáteční problémy s přechodem na jiný systém (Spark, Scala, MR/RDD rozdíly) a v neposlední v řadě vytušit zvýšené náklady. Za programátory (Scala je pořád i o poloviny lépe ohodnocená než Java), zvýšené pořizovací a provozní náklady na infrastrukturu (Spark má výrazně vyšší nároky než Hadoop).

    Migrovat na Spark bude mít smysl pouze a jen u úloh jak jsem uvedl, režie systému lze definovat více exaktněji (zlom u 1+7) než fádní "u několika stovek uzlů v clusteru", obrázek o optimu výkon/cena HW si uděláš ze závěrů lépe, než z tvrzení dodavatele/kon­zultantů že potřebuješ pro Spark alespoň 200GB RAM a víc. Když se podíváš na výsledky, rozhodně výkon neporoste do astronomických výšek jak cena za HW dimenzovaný dle doporučení konzultanta naučeného "opakovat co má naučené", nikoliv co je reálné. Pozor, bavíme se o ETL typu úloh - u ML, streaming a výcestupňových MR je to samozřejmě jinak!! To jsem však neřešil a jasně jsem se v článku v tomto vymezil. Netvrdím, že kdokoliv jiný bude mít stejné výsledky. Budou však blíže, než fádní technologicko-marketingové bludy co čteme a věříme jim. To vše má smysl ještě jednou zdůraznit.

    Důvod zahrnutí úlohy odhadu čísla PI do experimentu, stejně jako zmínka o zahazování výsledků (prováděná účelově), AWS,...lze opět vysvětlovat, lepší ale bude pozorně vše ještě jednou pročíst a vyhodnotit . Ty linky dle mého názoru jsou irelevantní, nebo alespoň na míle vzdálené od řešeného tématu. Budu rád, pokud toto vlákno bude pokračovat dál. Za další komentáře, příspěvky a názory ( to i od jiných čtenářů) budu vděčný. Ponechávám proto další diskuzi nadále otevřenou.