Hlavní navigace

HADOOP : Kdy má cenu o něm uvažovat, kdy ještě ne.

Včera 12:16 (aktualizováno) | Vilém Řezníček
O experimentu získat představu o rychlosti zpracování dat s využitím technologie Hadoop a pak to srovnat s „klasickým způsobem” jsem přemýšlel už velmi dlouho. Vše začalo, když jsem se poprvé s Hadoopem seznámil. Experimentoval jsem s příklady úloh dle tutoriálů (map-reduce) a seznamoval se s vytvářením první dotazů v Hive/Pig. První experiment jsem dělal převážně na platformě Hortonworks. Šlo o virtualizované vývojové prostředí a i na výkonném HW odezvy systému se mi zdály neadekvátně pomalé. Tzn. na nějaké praktické použití, byť i v malém rozsahu, to bylo zcela nevhodné. Virtualizované platformy (které jsem používal) jsou většinou určené k odzkoušení. Stačí si stáhnout image virtuálního stroje a zahájit experimenty. Toto je hlavní jejich výhoda – za 30 minut máte k dispozici celé prostředí, bez nutnosti zdlouhavé instalace a konfigurace. Jedná se o pseudodistribuované prostředí, kdy jednotlivé komponenty běží pouze na jednom uzlu. Tzn. výhoda distribuovaného a paralelně běžícího zpracování se zde neuplatní, za pár minut ale lze zahájit experimenty.

Rozhodně bylo v tu dobu vždy vhodnější řešit i práce menšího rozsahu běžným způsobem, který byl několikanásobně rychlejší (DB dotazem v RDBM nebo jednoduchým programem v Javě). Nicméně tím, že zpracování probíhá na takových systémech paralelizovaně, existuje bod zlomu, kdy paralelní zpracování začne být výhodné. Osobně stačí tušit, že někde takový bod zlomu existuje (samozřejmě ne v pseudodistribuovaném prostředí ale až v clusteru). Rozpačité je, když máte vyřešit úkol pro klienta, musíte se za sebe na začátku rozhodnout, kterým způsobem to budete řešíte (Hadoop, nebo klasicky). Mlžit asi budete muset, když se rozhoduje klient řešit to sám na své straně a chce tuto problematiku konzultovat s Vámi. Jak mu poradit, na základě čeho konkrétně doporučit to správné řešení? Pánem situace určitě budete, když máte správné argumenty, když klientovi chcete technologii třeba dodávat a pak i dlouhodobě podporovat.  

V době publikace tohoto článku uplynulo od doby prvních experimentů už více jak 4 roky. Za tu dobu se mi nepodařilo setkat se s někým, kdo má praktické zkušenosti na takové úrovni, že by bylo možné tyto otázky konzultovat. Najít si způsob nalezení bodu, od kterého je vhodné řešení paralelizovat, nebo alespoň znát doporučení, co bude v konkrétních případech relevantní posuzovat a dle čeho pak rozhodnout. Setkal jsem se v podstatě pouze s těmi, co takové technologie snadno dokázali dodat, ale z této oblasti nedali srozumitelné a smysluplné doporučení. Dodavatelé předloží vždy argumenty, že je to výhodné a detail není důležitý. Proto jsem se vrátil k počátkům experiment s Hadoopem pokusil se osvětlit si vše svépomocí. Navrhnout a realizovat několik způsobů řešení jednoho toho samého problému. 

Úkol k řešení: Zvolil jsem to nejjednodušší a snadno srozumitelné zadání. Zpracovat vstupní textový soubor, kde se vyskytují (mimo jiné), positivní a negativní slova (výrazy). Ve vstupním souboru jsou věty, u každé věty je úkolem ji označit tak, aby bylo vidět zda v ní převládají positivní, nebo negativní výrazy (zjednodušené vyhodnocení sentimentu). K určení, zda má slovo positivní nebo negativní význam, je určený slovník obsahující výčet takových slov (reálně s CZ slovníkem obsahující 20.000 slov bylo možné dosahovat spolehlivosti 65%, s využitím pokročilejších metod lze dosáhnout až 80%). 

Vybrané způsoby pro srovnání rychlosti vyřešení úkolu:

  1. Java aplikace, přečte vstupní soubor na lokálním disku (filesystém, který využívá operační systém), rozloží na věty/slova, identifikuje ve větě positivní a negativní slova, označí větu zda v ní převládají positivní či negativní slova a uloží ji do výstupního souboru.
  2. Java aplikace stejná jako 1), načítá ale vstupní soubor a soubor slovníku z HDFS (Hadoop filesystém). Vstupní soubory již i pro každý další způsob jsou v vždy v HDFS, výstupní soubor též.
  3. Hadoop job – MAPONLY. Veškeré operace vyhledávání významu slov a vyhodnocení sentimentu se provádí v Mapperu, výstupem je soubor v požadovaném výstupním tvaru (označené věty, positivně či negativně).
  4. Hadoop job – MAP-REDUCE (MapSideJoin). V podstatě se jedná o stejný způsob jako 3), výstup mapperu (který už je v podstatě to, co má být výstupem řešení) se podstoupí Reduceru a ten ho jen uloží 1:1 do výstupního souboru. Záměrem bylo rozeznat rozdíl (oproti způsoby MAPONLY), jakým podílem se projeví na zhoršení odezvy práce s diskem a operace před a v průběhu fáze Reduce.
  5. Hadoop job – MAP-REDUCE (ReduceSideJoin). Na vstupu jsou dva Mappery (jeden pro emitování slov ze slovníku, druhý slov ze vstupního souboru), data pak v rámci kontextu řešení zpracuje následně Reducer. Ten je zodpovědný za spojení informací z obou zdrojů (join) a vytvoření výstupu (jiná struktura, objem zachovaný). Tento způsob oproti předchozímu ukáže vliv na odezvu z nutnosti data pře Reducerem setřídit a seskupit dle klíče. 
  6. HIVE query – předchozí způsoby vyžadují znalost programování (java) a znalost paradigmatu map-reduce. Hive umožňuje ten samý úkol vyřešit pomocí SQL dotazu. Takový dotaz dovede formulovat převážná většina datových analytiků (určitě je to jednodušší, než programovat mapReduce job).
  7. PIG script – podobně jako Hive query, nepotřebuje přímo dovednosti programátora. Není to přímo SQL dotaz, snadno ho připraví i „neprogramátor“.
Zde v textu musím ještě jednou zdůraznit : předtím, než se ponoříte do zkoumání detailů – neposuzujte prosím způsoby z pohledu „smysluplnosti“ řešení úkolu vyhodnocení sentimentu jednotlivých vět. Důvod experimentu a i jednotlivých způsobů řešení bylo posouzení, jak rychle lze jednotlivými způsoby získat výstupní data, při zachování stejných objemů dat mezi komponentami tak, aby bylo možné udělat si představu o nárůstu komplexnosti a prodloužení doby odezvy (času potřebného na zpracování). Srovnání pak napoví, co lze od jednotlivých způsobů očekávat. Alespoň v mém případě výsledek pomohl se v tom trochu zorientovat.

Na tomto grafu lze vidět, relativně dobu trvání zpracování úlohy jednotlivými způsoby.

Prezentovaný výsledek vznikl zprůměrováním výsledků asi 120ti samostatných experimentů – spouštěním v několika prostředích: na osobní stanici kde vytvářím map-reduce joby, na dvou virtualizovaných platformách (Hortonworks, Cloudera) a taktéž na virtualizovaném miniclusteru (1 master, 3 slaves). Test na „dospělém clusteru“ je připravený, čeká ale teprve na svůj čas. 

V grafu neuvádím čas v absolutní hodnotě, výsledky jsou proto uvedené „relativně“. Mohu ale konstatovat, že prezentovaný výsledek proporčně reflektuje výskedky z každého použitého prostředí. Tzn. ve všech prostředích operace HDFS (metoda č.2) byla o něco málo pomalejší, než to samé na lokálním disku (1), realizace řešení pouze v Mapperu (3) byla 3× pomalejší než zpracování na lokálním disku (1), ReduceSideJoin (5) byl „pomalý“ vždy. Ještě hůře na tom byl skript PIG (7), který v grafu ani nezobrazuji. Překvapení bylo ale vidět srovnání rychlostí mezi způsobem PIG (7) a Hive (7). Hive dotaz (SQL) byll dokonce rychlejší než ReduceSideJoin (5). Podotýkám, že jsem záměrně nepoužil u metody (5) Combiner.

Závěr : Zlom, kdy je vhodnější palalelizovat zpracování z výsledku ještě nyní není vidět. Ten bude zřetelný až z výsledků z reálného clusteru. Pokud ale řeším, zda teď uvažovat o Hadoopu a jedná se o objemy stovky GB, vždy budu pokračovat konvenčními způsoby a Hadoop pro řešení nevyberu. Proto se tomu asi skutečně říká technologie pro BigData :-). V okamžiku být limitován místem pro uložení dat, HDFS nebo jiný podobný filesystém by byl asi v mém případě první důvod pro přechod na platformu Hadoop. Zpracování dat v HDFS je o něco pomalejší, získám však snadno velmi snadno dostupný prostor k ukládání a uchovávání dat. Prostor mohu kdykoliv rozšiřovat bez omezení a to i postupně. Tím se otevře i možnost zpracovávat data metodami s využitím paradigma „map and reduce“.

Snad některým z Vás čtenářů výsledek tohoto experimentu pomůže k rozhodování, kam se dál ve vaší společnosti ubírat v oblasti zpracování dat dále. Nebo alespoň pomohl mít ten „feeling“, jak by vypadalo řešení ve vašem případě nasazení Hadoopa. No a až se mi podaří realizovat tento experiment v využítím použitách kódů i na dospělém clusteru, podělím se velmi rád o výsledky a sepíšu podrobněji další postřehy, hodící se vývojáři, tak i specialistům pro další rozhodování o nasazení nové technologie.

Použité zdrojové kódy a query vystavím v dohledné době na Git, do té doby v případě zájmu posílám obratem emailem na vyžádání.

  • 8. 2. 2018 0:35

    Tomáš2

    Článku nějak vůbec nerozumím :)

    "...už více jak 4 roky. Za tu dobu se mi nepodařilo setkat se s někým, kdo má praktické zkušenosti..." Opravdu? A kde jsi se snažil setkávat? Už několik let běží https://www.meetup.com/en-AU/CS-HUG/, sám mám za sebou desítky workshopů, vždy je někdo k dispozici.

    Hadoop u nás v ČR používá většina bank a snad všichni operátoři, Seznam a spousty dalších společností a to již spoustu let.

    MAP-REDUCE je už dost obsolete, nemá smysl dnes na něm měřit performance, v praxi se již používají navazující technologie. Měřit výkonnost bez deklarované HW konfigurace a rozložení dat je tak nějak k ničemu.

    Ano, pokud máš GB dat, nemá smysl nasazovat hadoop, efektivita se láma přibližně nad desítkami TB, kde povětšinou končí konvenční warehouse (zejména kvůli ceně).

    Pokud chceš konzultace, ozvi se.

  • 10. 2. 2018 14:09

    Marek (neregistrovaný) ---.ipv4.broadband.iol.cz

    Vzhledem k tomu, že se jedná o blog, nevím, proč čekáte kvalitu akademického paperu. Poselství článku by se sice mohlo vejít do věty "pokud se vám to nevejde na disk, nasaďte hadoop", ale blogy jsou přece od toho, aby tam lidé sdíleli nějaké širší zkušenosti.

    Osobně oceňuji autorův postup "mám pomoct klientovi, ale nevím, co je dobře a kde je ta hranice -> vyzkouším si to
    a když už jsem to udělal, udělám z toho blogpost". Nemá smysl přece řešit, co je dneska in, co už včera bylo out atd. Na to jsme my ajťáci nekonečně tvrdohlaví ;)

  • 10. 2. 2018 18:15

    Tomáš2

    Marek: jo, máš pravdu, autor si s tím dal nějakou práci, měl předpoklady, udělal závěry, je škoda, že nezkontaktovat někoho se zkušenostmi, mohl svoji práci vynaložit ku většímu prospěchu ostatních.

    To, jestli je něco "in" nebo ne v tomhle nehraje takovou roli. Jak se začaly množit data, zjistilo se, map reduce není nevhodnější nápad a bere příliš prostředků a času při složitých úlohách, lepších výsledků se postupně dalo dosáhnout i u běžných databází. Hive naopak velice nešikovně škáluje, prodleva několik desítek vteřin před každým dotazem není příjemná.

    Tyhle technologie jsou i teď příliš složité a komplexní, návody na netu v podstatě nejsou, ze zkušenosti vím, že dostat se do toho svépomocí je náročné a výsledky jsou žalostné.

  • 10. 2. 2018 20:23

    Maros (neregistrovaný) 89.24.56.---

    Chcel by som vediet, kolko ludi sa zaujimalo o tuto otazku skor nez zacali pisat. Ja by som bol velmi opatrny! Spark na tom klidne moze byt ako dobre napisany mapreduce a aj tomu tak casto byva. Obzvlast, pokial ide o busy produkcne prostredie.
    Hadoop rozhodne nie je mrtvy. Nie kazda spolocnost su totiz pankaci a moze menit technologiu kazdy rok. Napríklad banky. Tu su len dcerske spolocnosti a vyuzivaju infrastrukturu matiek. Tam mozete zabudnut na instalaciu najnovsich technologii.

    Článok by mal mať viac podrobností alebo by mal byť kratší. Ocenujem ale, ze sa tym niekto zaobera, srovnava a pise o tom.

  • 11. 2. 2018 19:03

    Tomáš2

    Maros: není pravda, že banky využívají infrastrukturu matek, co jsem viděl, všichni mají svoji, svoje soutěže, svoje technologie, nějaká konsolidace je v tomhle světě minimální.

    Zrovna ty konzervativní banky patří k těm, které tyhle nové technologie adoptují jako houby poměrně rychle, stačí se podívat na jejich otevřené pozice https://kb.jobs.cz/detail-pozice/?id=G2-1177455075-aden_brand0, klíčová slova jsou třeba BI analytik, nejnovější verze hadoopu a sparku v produkci zpravidla hledej právě u bank :)

    Byl by zájem o články z tohoto oboru? Zajímá to někoho?

Přidávat nové názory je zakázáno.