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

Otázkou experimentu, získat představu o rychlosti zpracování dat s využitím technologie Hadoop a srovnání s „klasickým způsobem”, jsem se zabýval už velmi dlouho. Vše začalo, když jsem se poprvé s Hadoopem seznámil a viděl výrazně delší dobu zpracovávání dat v nesprospěch Hadoopa. V době publikace článku už od té doby uplynuly více jak čtyři roky. Za tu dobu se mi nepodařilo narazit na nějaké srovnání, nebo se setkat s někým, kdo měl z této oblasti nějakou konkrétní zkušenost. Prostě a jasně NE a NE a NE! 

Setkal jsem se v podstatě pouze buď s těmi, co takové technologie dokázali dodat a detaily tohoto typu vůbec neřešili, nebo se skupinou geeků, zajímajících se pouze o poslední trendy nebo jimi využívané technologie. Od první skupiny jsem nikdy srozumitelné a smysluplné doporučení nedostal. Diskuse s druhou skupinou, s technologickými nadšenci, vždy hned v počátku nabraly směr k právě jimi používanému SW, nebo k “jiným” technologickým superlativům.

Pokud jsem chtěl vědět, k jakému propadu výkonnosti z důvodu nasazení Hadoopa dojde, bylo nutné si to experimenty vyzkoušet osobně. Pro ten účel jsem navrhnoul a realizoval několik způsobů řešení jednoho a toho samého problému. Nejjednodušším způsobem bylo zpracování úkolu Java aplikací na lokálním disku, poté zpracování na HDFS, 3 možné způsoby MAP-REDUCE, na závěr jsem vyzkoušel pro zajímavost i způsob HIVE a PIG dotazem. 

První experimenty jsem dělal převážně na platformě Hortonworks, postupně jsem pak přešel na platformu Cloudera. Stačí si stáhnout image virtuálního stroje a zahájit experimenty. Za 30 minut máte k dispozici celé prostředí, bez nutnosti zdlouhavé instalace a konfigurace.  V případě obou virtualizovaných platforem se jedná o pseudodistribuované prostředí. 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. Pro účely seznámení a rychlé ladění MAP-REDUCE úloh ideální řešení. 

Experimenty byly provedené jak na pseudodistribuovaném prostředí (3 různé), tak i na jednom virtualizovaném mini-clusteru (1 master, 3 slaves). Celkem se jednalo asi o 120 samostatných experimentů, na vzorku dat 250MB, 1GB a 100GB. Prezentovaný výsledek vznikl zprůměrováním relativních výsledků – srovnání výsledků z jednotlivých prostředí, různých vzorků dat. 

Problém 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í či negativní výrazy (zjednodušené vyhodnocování 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. LOCALFS: 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. HDFS: Java aplikace stejná jako 1), načítá ale vstupní soubor a soubor slovníku z HDFS (Hadoop filesystem), výstupní soubor je uložený též do HDFS.
3. Hadoop MAPONLY: Veškeré operace vyhledávání významu slov a vyhodnocení sentimentu se provádí v mapperu, výstupem z mapperu je přímo výstupní soubor v požadovaném tvaru (označené věty, positivně či negativně).
4. Hadoop 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 postoupí reduceru a ten ho jen uloží 1:1 do výstupního souboru. Záměrem bylo rozeznat rozdíl (oproti způsobu 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 map-reduce REDUCESIDEJOIN: Na vstupu jsou dva mappery (jeden pro emitování slov ze slovníku, druhý slov z vět 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 dle slov, určení patřičné polarity) a vytvoření výstupu. Tento způsob oproti předchozímu ukáže vliv na odezvu z nutnosti data před reducerem setřídit a seskupit dle klíče. Tato fáze obvykle to bývá zabiják všech prostředků co máte pro zpracování k dispozici. 
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“. V dnešní době se už od tohoto způsobu ovšem upouští.

Zde v textu musím ještě jednou zdůraznit : důvod experimentu a i jednotlivých způsobů řešení bylo zjistit, jak se zvýší nároky (resp. jak se zpomalí) zpracování dat, když využijete jednotlivé metody. Zjednodušeně, pokud víte o kolik se zpracování zpomalí, lépe určíte, kolik uzlů v clusteru to vykompenzuje. Paralelní, tedy distribuované zpracování, je právě to, co u Hadoopa očekáváte a využijete. Místo vyjádření "že se to pohybuje někde u stovek uzlů” to budete vědět přesněji. Není to zcela určitě u stovek, ve Vašem případě to může být už u 7 až 10-ti uzlů (viz. další  článek). 

V grafu uvedené výsledky jsou uvedené „relativně“. Tzn. operace na HDFS (metoda č.2) byla o něco málo pomalejší (resp. HDFS bylo 1.7× pomalejší), než to samé na lokálním disku (1). Realizace řešení MAPONLY (3) byla 3 krát pomalejší než zpracování na lokálním disku (1).  ReduceSideJoin (5) byl „pomalý“ vždy – až 13× oproti způsobu MAPONLY. Zcela záměrně jsem ale nepoužíval Combiner (další prostor pro zrychlení). Ještě hůře na tom byl skript PIG (7), ten jsem do grafu už ani nezahrnul (až 100× pomalejší). 

Příjemně jsem byl překvapený u Hive (7). Pro tento zvolený typ úlohy byl jen 6× pomalejší než připravený MAPONLY. Pokud beru v úvahu možnosti využívání SQL datovými analytiky (nebývají to vždy programátoři), pro ad-hoc účely v případě běžně (i malého) clusteru získaný benefit jejich samostatnosti (nezatěžuje svými požadavky BI oddělení) své opodstatnění určitě najde. 

Závěr: Výsledky srovnání jsou orientační. Neočekávejte, že ve Vašem případě by byly výsledky na desetinu přesně to samé. V konečném důsledku bude záležet především (dle významnosti), který způsob řešení budete muset implementovat, jaký objem budete muset zpracovávat a kolik uzlů budete mít k dispozici. Rozhodně bude záležet i na kvalitě map-reduce kódu. 

Velmi pravděpodobně ale relativní srovnání metod bude velmi podobné. Tuto znalost snadno využijete na odhad, kolika uzly bude nutné přechod na Hadoop/HDFS vykompenzovat. Nemusíte pracovat jen s doporučením dodavatele, úsudek si uděláte jednoduchým experimentem nebo odhadem sami.

Poznámka na konec:

Toto je druhá, stručnější revize článku – na základě komentářů od čtenářů. Odebrané pasáže uvedu někdy v dalším pokračování. Dalším komentovaným bodem byla v tuto dobu už zastaralost technologie Hadoop. Zmiňuji opět, že jsem se zajímal právě a jen o Hadoop, s motivem zjistit si sám, jak výrazně vzrostou požadavky na výkon aby vykompenzovaly zvýšené provozní režie systému. Hadoop je i v této době pořád dobré a ověřené řešení pro běžné  „use-case“, které řešíme v BI denně. Navíc pořád platí, že Hadoop je v porovnání s ostatními nenáročný na HW, snadno se implementuje, škáluje, Java programátora seženete rychleji a levněji než je tomu u Scaly! 

Pokud víte, co získáte (paralelní zpracování, levný storage, vyřešenou redundanci dat) za jakou cenu (komplexita, zvýšené režie), dokážete si navrhnout optimální řešení. Nebo ho v opačném případě ihned zavrhnout. 

Toto je přístup, který velmi v našem oboru postrádám. Místo toho se řešení často navrhují ne s ohledem na fakta, ale na marketingové bludy. Například v komentářích zmíněný Spark u Vás určitě nebude 100× rychlejší (jak se všude dočtete). V dalším článku uvidíte, že to rozhodně 100× není :-), že je to prostě jen donekonečna opakovaný blud (viz. výsledky dalšího experimentu  HADOOP vs. SPARK).

Jak až do podrobností jdete Vy, když hledáte to správné řešení pro sebe?