cseh gábor kócsó balázs váradi szabolcs -...

Budapesti M¶szaki és Gazdaságtudományi Egyetem

�Big Data� elemzési eszközök nyíltforráskódú platformokon el®adásjegyzet

Készítette:

Cseh Gábor

Kócsó Balázs

Váradi Szabolcs

El®adó: Prekopcsák Zoltán

Lektorálta: Holczer Tamás, Prekopcsák Zoltán

BMEVITMAV15

Budapest, 2014LATEX

Tartalomjegyzék

1. Bevezetés 4

2. Elosztott rendszerek, Hadoop, HDFS 62.1. Elosztott rendszerek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1. Elosztott fájlrendszerek . . . . . . . . . . . . . . . . . . . . . . . . . 72.2. Hadoop története . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3. Hadoop HDFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4. Hadoop szerver szerepek . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4.1. Name Node (NN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4.2. Secondary Name Node (SNN) . . . . . . . . . . . . . . . . . . . . . 102.4.3. Data Node (DN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5. Adatm¶veletek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5.1. Olvasás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5.2. Írás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3. MapReduce 123.1. Az általános MapReduce modell . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.1. 1. Feladat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.1.2. 2. Feladat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.1.3. Hadoop MapReduce felépítése . . . . . . . . . . . . . . . . . . . . . 143.1.4. Hadoop Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.1.5. Meghibásodások . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4. MapReduce programozási minták, Streaming 174.1. 1. feladat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2. 2. feladat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.3. 3. feladat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.4. 4. feladat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.5. Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.6. Adattömörítés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5. Hadoop csomagok, SQL for Hadoop: Hive 225.1. Hadoop csomagok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.1.1. Flume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.1.2. Sqoop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.1.3. Hive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.1.4. Pig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.1.5. HBase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.1.6. Mahout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1

TARTALOMJEGYZÉK

5.1.7. Zookeeper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.2. SQL for Hadoop: Hive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.2.1. A Hive felépítése . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6. Pig programozás 266.1. Bevezetés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.2. A fájlok feltöltése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.3. A script megírása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.3.1. Reláció de�niálása . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.3.2. Reláció de�niálása sémával . . . . . . . . . . . . . . . . . . . . . . . 286.3.3. Reláció létrehozása egy másik relációból . . . . . . . . . . . . . . . 286.3.4. Adatok kiírása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.3.5. Oszlop kiválasztása a relációból . . . . . . . . . . . . . . . . . . . . 296.3.6. Adatok írása a HDFS-re . . . . . . . . . . . . . . . . . . . . . . . . 296.3.7. Két reláció illesztése (Join m¶velet) . . . . . . . . . . . . . . . . . . 296.3.8. Adatok rendezése . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.3.9. Adatok sz¶rése és csoportosítása . . . . . . . . . . . . . . . . . . . . 30

6.4. További források . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

7. Hadoop klaszterek kon�gurációja és üzemeltetése 327.1. Hardver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327.2. Operációs rendszer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337.3. Hálózat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337.4. Disztribúció . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347.5. Feladatok ütemezése és kvóták használata . . . . . . . . . . . . . . . . . . 34

8. Hadoop 2.0 - YARN, Tez, Spark 358.1. Hadoop 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

8.1.1. Kialakulása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358.1.2. Különbségek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358.1.3. YARN job futtatás . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

8.2. Tez . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378.2.1. Eloszott rendezési példa Tez-ben . . . . . . . . . . . . . . . . . . . 37

8.3. Impala . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388.4. Spark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398.5. Storm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

9. Hadoop & NoSQL: HBase 409.1. Adatbázis-kezel® rendszerek . . . . . . . . . . . . . . . . . . . . . . . . . . 40

9.1.1. Elosztott adatbázis-kezel® rendszerek . . . . . . . . . . . . . . . . . 409.2. NoSQL adatbázis-kezel® rendszerek . . . . . . . . . . . . . . . . . . . . . . 419.3. HBase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

9.3.1. M¶ködése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439.3.2. HBase adatszervezési példa . . . . . . . . . . . . . . . . . . . . . . 44

A. MapReduce Patterns, Algorithms, and Use Cases 45A.1. Basic MapReduce Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

A.1.1. Counting and Summing . . . . . . . . . . . . . . . . . . . . . . . . 46A.1.2. Collating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2

TARTALOMJEGYZÉK

A.1.3. Filtering (�Grepping�), Parsing, and Validation . . . . . . . . . . . . 47A.1.4. Distributed Task Execution . . . . . . . . . . . . . . . . . . . . . . 47A.1.5. Sorting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

A.2. Not-So-Basic MapReduce Patterns . . . . . . . . . . . . . . . . . . . . . . 48A.2.1. Iterative Message Passing (Graph Processing) . . . . . . . . . . . . 48A.2.2. Distinct Values (Unique Items Counting) . . . . . . . . . . . . . . . 51A.2.3. Solution II: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52A.2.4. Cross-Correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

A.3. Relational MapReduce Patterns . . . . . . . . . . . . . . . . . . . . . . . . 54A.3.1. Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54A.3.2. Projection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54A.3.3. Union . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55A.3.4. Intersection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55A.3.5. Di�erence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55A.3.6. GroupBy and Aggregation . . . . . . . . . . . . . . . . . . . . . . . 56A.3.7. Joining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3

1. el®adás

Bevezetés

BigData de�níciója: Olyan nagy és komplex adathalmaz, amelyet már a szokásos al-kalmazásainkkal nem tudunk kezelni.

Ez nem egy túl pontosan értelmezhet® de�níció, ezért ez felhasználási területenként vál-tozik (1.1. ábra). Ha a felhasználási terület

� az Excel, akkor 1 millió sor, ha

� valamilyen memória alapú feldolgozóeszköz, akkor amennyi memóriánk van,azaz 4-8 GB, ha

� valamilyen adatbázis pl. MySQl, akkor 50-100 GB, ha

� az általunk készített hatékony diszket jól használó programok, akkor 1 TB

fölött számít BigData-nak. Nagy általánosságban azt lehet mondani, hogy 50-100 GBalatt nem számít az adat BigData-nak, mert egy nagy memóriával rendelkez® felh® szol-gáltatással ezek az adatok még nagyon jól kezelhet®ek.

1.1. ábra. A BigData értelmezése a felhasználási terület függvényében

4

EL�ADÁS 1. BEVEZETÉS

Ett®l nagyobb adatmennyiség esetén már csak valamilyen elosztott rendszerrel tudjukhatékonyan kezelni az adatainkat, ilyen elosztott rendszer a Hadoop. A scale up felfogásszerint, ha egy gépen szeretnénk minél nagyobb számítási kapacitást, akkor csak egysze-r¶en felskálázzuk (azaz több memóriát és er®sebb processzort teszünk bele), míg a scaleout szerint teljesen hagyományos PC-ken elosztott rendszerben gondolkodunk.Egy másik felfogás szerint onnantól beszélünk BigData problémákról, amikor az adatolyan nagy, hogy az már részévé válik a problémának, például amikor már nem férünk amemóriába, vagy amikor már egy számítógépen napokig fut az adott feladat. Összefog-lalva bármilyen probléma, amely abból származik, hogy túl sok adatot kell kezelni. Ezeklegtöbbször valamilyen hardver korlátból adódnak (1.2. ábra), amelyek egy normál PCesetén

� 12-24 TB méret¶ merevlemezt,

� 32-64 GB méret¶ memóriát

jelent. Ezen felül jelent®s probléma az is, ha egy átlagos 2 TB méret¶ merevlemezr®lle akarjuk olvasni a teljes tartalmát, akkor az 6 órába tellene a merevlemez átereszt®képessége miatt.

1.2. ábra. A hardver korlátok egy átlagos PC esetén

5

2. el®adás

Elosztott rendszerek, Hadoop, HDFS

2.1. Elosztott rendszerek

Az elosztott rendszerek lehet®vé teszik azt, hogy bármilyen m¶veletet több számítógépközött elosztottan hajtsunk végre, ezáltal megnövelve annak sebességét, kapacitását, ren-delkezésre állását. Egy elosztott rendszer rengeteg számítógépb®l állhat, melyek egy közöscél érdekében együtt tudnak dolgozni, és m¶ködni. Ezek a számítógépek egy hálózaton(vagy akár az interneten) keresztül vannak egymással összekötve, így tudnak kommuni-kálni.Fontos megemlíteni, hogy a meghibásodás ténye teljesen más, mint egy egyedülálló szá-mítógép esetében. Az elosztott rendszerek ezt rugalmasan tudják kezelni, folytatódik arendszer futása szinte észrevehetetlenül. Egyedülálló gép esetében természetesen ez nemlehetséges (a hiba típusától függ®en). Ez a fajta rugalmasság azért is fontos, mert egytöbb tíz vagy száz gépb®l álló hálózat esetén a meghibásodás egy napi vagy heti rendsze-rességgel el®forduló esemény, és nagyon fontos, hogy 1-2 gép kiesése esetén a többi gondnélkül tovább m¶ködjön, s®t lehet®leg a feladatok futása se szakadjon meg.Többféle célra is használják ezeket a rendszereket:

� Elosztott adattároló központok: Ezeket a rendszereket kifejezetten nagy mennyi-ség¶ adatok tárolására találták ki. Mivel egy adathordozón és számítógépen megle-het®sen limitált a tárolható adatmennyiség, így ezt több számítógépen több adat-hordozón tudjuk tárolni. Többnyire az adatok megfelel®en vannak replikálva is, ígyaz adatvesztés kockázata jelent®sen lecsökken.

� Elosztott számítási kapacitás: A másik nagy felhasználás, amikor az elosztottrendszereket a teljesítményük miatt kapcsolják össze egy nagy számítási felh®vé.Ilyenkor egy bizonyos nagy számításigény¶ feladatot nagyon gyorsan és hatékonyanvégre lehet hajtani, míg ez egy önálló számítógépen több évig eltarthatna (pl. gene-tikai minták elemzése). Az ilyen típusú rendszerek lehetnek el®re kon�guráltak, éstelepítettek, de lehetnek akár önkéntesek is, ahova egyszer¶ felhasználói számítógé-peket az interneten keresztül kapcsolnak be a rendszerbe, és használják az er®forrá-saikat. (Ezek lehetnek a GRID computing, HPC, Volunteer computing, Distributedprogramming, MPI. Ezek mindegyike számítás- és nem adatigényes feladatokra van-nak optimalizálva.)

6

EL�ADÁS 2. ELOSZTOTT RENDSZEREK, HADOOP, HDFS

2.1.1. Elosztott fájlrendszerek

Régen egy 1 GB-os merevlemezt körülbelül 4 MB/s sebességgel tudtunk olvasni. Máraa technológia sokat javult a tárolható adatmennyiség terén, de az olvasási sebesség növe-kedése nem a várt értékeket mutatja. Egy ma kapható 2 TB-os merevlemezt 100 MB/ssebességgel tudunk olvasni, ami még így is lassúnak mondható abban az esetben, ha ateljes lemeztartalmat szekvenciálisan végig szeretnénk olvasni (kb. 5,5 óra). Ha ezt azadatmennyiséget elosztva 100 db merevlemezen tárolnánk, akkor az adatokat ugyanilyenolvasási sebesség mellett szinte néhány perc alatt fel tudnánk dolgozni. Emellett a sta-tisztikák szerint 100 db merevlemezb®l 5 hibásodik meg évente. Ezen okok miatt kezdtékel létrehozni az elosztott fájlrendszereket.Az elosztott fájlrendszerek lényege, hogy a fájljainkat egy kliens-szerver architektúra se-gítségével tárolhatjuk illetve érhetjük el. Egy elosztott fájlrendszerben egy vagy többközponti szerver található, amelyek tárolják az alapvet® információkat a többi szerverr®l,melyek száma elméletben korlátlan lehet. Ezek a kitüntetett szerepkörrel rendelkez® szer-verek tárolják a fájlstruktúra hierarchikus felépítését, a metaadatokat, és a fájlok konkrétszerveren való helyét. A gyakorlatban legalább kett® központi szervert használnak annakérdekében, hogy redundancia biztosított legyen.Ha egy elosztott fájlrendszerbeli fájlt egy kliens géppel szeretnénk elérni, akkor gyakor-latilag semmilyen különbséget nem veszünk észre, tehát teljesen olyan, mintha az adottfájlt egy darab szerveren tároltuk volna, vagyis a tároló Node-ok struktúrája elfedésrekerül. Err®l az elfedésr®l az elosztott rendszer gondoskodik. Az elosztott rendszerek er®s-sége abban rejlik, hogy általuk könnyen elérhet®ek több kliens számára is ugyanazok azadatok, és gyakorlatilag egy központi tárolóegységr®l beszélünk, a kliensek nem tárolnaklokálisan olyan fájlokat, amelyek más kliensek számára is fontosak lehetnek.

2.2. Hadoop története

A 2.1. ábrán látható a Hadoop rendszer fejl®déstörténete. Eredetileg a Hadoop egy elosz-tott fájlrendszerként indult, amelyet a Google kezdett el fejleszteni Google File Systemnéven. Ezután többen megpróbálták ezt reprodukálni, és elkészíteni Open Source projektkeretein belül.

2.1. ábra. Hadoop kialakulásának története

Ezek után a Yahoo is elkezdte ugyanezt a rendszert saját maga elkészíteni. A próbálko-zásoknak és a fejlesztéseknek köszönhet®en egyre többen elkezdték használni a Hadooprendszert (pl. Facebook, Last.FM), és ennek következtében az Apache felkarolta, és egy

7


dedikált Open Source fejlesztési projekt keretein belül a mai napig ®k foglalkoznak a té-mával. Több nagy cég üzleti szolgáltatásként is elindította a saját továbbfejlesztett éskiegészített verzióját. A 2.2. ábrán látható, hogy 2012-ben a Hadoop rendszert céges kör-nyezetben 1 éven belül nagyon sokan tervezik bevezetni, tehát jelent®s növekedés várhatóa piacon.

2.2. ábra. Bevezetni kívánt technológiák céges környezetben

2.3. Hadoop HDFS

A Hadoop rendszer egy teljesen saját, egyedülálló elosztott fájlrendszert használ, a Ha-doop Distributed File System-et (HDFS). Ez a fájlrendszer arra lett tervezve, hogy kife-jezetten nagy méret¶ fájlokat tároljunk rajta, mivel a rendszerben nagy adathalmazokontudunk valamilyen lekérdezést, vagy m¶veletet egyszer¶en végrehajtani. Például log-okesetén érdemes nagyobb egységekben tárolni az adatokat, így nagy fájlméret érhet® el.Az adatokat általában egyszer letároljuk, és többször teljesen végig kell olvasnunk ®ket(full scan).A Hadoop fájlrendszer arra lett tervezve, hogy átlagos otthoni PC-kre vagy átlagos szer-verekre is telepíthet® legyen, ezzel is azt ösztönözve, hogy költséghatékonyabban tudjunkegy elosztott rendszert kialakítani (ez nagy mértékben különbözik a SAN szemlélett®l).A HDFS egy blokkalapú fájlrendszer (tipikusan 64-256 MB egy blokkméret), tehát a nagyfájlok (tipikusan a GB-os nagyságrendben) ilyen méret¶ blokkokra darabolódnak szét, ésa blokkok egymástól függetlenül tárolhatók más-más er®forrásokon, és számítógépeken.A blokkméretet az elérési id® miatt kell nagyobbra venni, mint egy átlagos fájlrendszeresetében. A fentebb említett 64-256 MB blokkméretnél nagyobbat már nem érdemesválasztani, mert ezzel elveszítenénk a párhuzamosítás lehet®ségét, mivel a számítási fel-adatok esetében a blokkok betölt®dnek a memóriába, tehát így több is befér egyszerre,nem kell állandóan cserélgetni ®ket a számítás során. Ez a gyakorlatban azt jelenti, hogyegy 1 GB-os fájl esetében, 1 MB-os blokkok esetén az olvasás során a merevlemez fejének

8


mozgatása 1000 · 10ms keresési id®t jelent. Nagyobb blokkméret esetén ez a késleltetésjóval csökken.Ezen kívül nagyon fontos, hogy minden blokk replikálódik legalább egy - de általábantöbb (2-3) - másik számítógépen is, tehát ezzel elkerülhet® az adatvesztés (Hadoop eseténaz alapértelmezett replikációs faktor a 3, ez azt jelenti, hogy minden blokk 3 különböz®helyen van eltárolva). Ha kiesik egy számítógép, azt egyszer¶en kivehetjük a rendszer-b®l, és egy újat tehetünk a helyébe. Ezáltal a rendszer nagyon jól skálázható, rendkívüljól m¶ködik óriási géppark esetén is. A blokkok helyének meghatározását egy komplexterheléselosztó algoritmus határozza meg, ami többek között �gyelembe veszi az egyesgépek terhelését, a replikálásból származó adatforgalom minimalizálását, illetve a minélnagyobb megbízhatóságot (ennek érdekében lehet®leg több rack illetve adatpark között ismegosztja a replikákat).

2.4. Hadoop szerver szerepek

A fájlrendszerben több kitüntetett szereppel rendelkez® gépnek kell lennie ahhoz, hogy azegész rendszer megfelel®en tudjon m¶ködni (2.3. ábra).

2.3. ábra. Hadoop szerver szerepekforrás: http://www.atlantbh.com/how-to-build-optimal-hadoop-cluster/

2.4.1. Name Node (NN)

Ebb®l általában egy van egy Hadoop rendszerben, feladata a metaadatok tárolása éskarbantartása. Gyakorlatilag ® tudja azt, hogy milyen mappák, milyen fájlok találhatóaka fájlrendszeren. Ezt két fájl segítségével tudja tárolni:

� Namespace image: Ez egy lenyomat a fájlokról, mappákról.

� Edit log: A legutóbbi namespace image-hez képest történt változtatásokat írja le,ezáltal nem kell mindig azt az image-t frissíteni, ami jelent®s er®forrásigénnyel járna.Ennek ellenére ezt a log-ot egy id® után bele kell f¶znünk a namespace image-be,mert feleslegesen nagy méret¶vé válna.

9

http://www.atlantbh.com/how-to-build-optimal-hadoop-cluster/


Fontos megemlíteni, hogy a Data Node-ok rendszeresen jelentik a náluk lév® blokkoklistáját a Name Node-nak, amit természetesen ® nyilván is tart. Így ha egy kliens a NameNode-hoz fordul egy fájlért, akkor ebb®l a naplóból tudja, hogy melyik blokkok kellenek,és a jelentésekb®l el tudja irányítani a klienst a megfelel® Data Node-hoz, ugyanis ezenjelentések nélkül a Name Node nem tudná, hogy milyen blokkok találhatóak a Data Node-okon (amelyek nem kerültek mentésre még a namespace image-be).A metaadatok tárolásának hátránya, hogyha a Name Node kiesik, és a metaadatokrólnincs biztonsági másolatunk, akkor minden adatunk elveszik annak ellenére, hogy �zi-kailag az adatblokkok megmaradnak a Data Node-okon. Ennek kiküszöbölésére RAIDés/vagy NFS (Network File System) technológiákat használnak, így mind helyileg, mindhálózaton is tudjuk ezeket tárolni.Létezik egy Name Node High Avaibility megoldás, amely szerint több Name Node van arendszerben. Így mindegyik folyamatosan tárolja az információkat és közülük valamelyikaktív, a többi pedig passzív, a kliensek pedig mindig az aktívhoz fordulnak. Az aktívkiesése esetén ekkor bármelyik passzív rögtön átveheti az aktív szerepét. Ez a megoldástermészetesen jelent®sen nagyobb terhet ró a Name Node-ra, hiszen biztosítani kell akonzisztenciát az aktív és passzív Name Node-ok között.

2.4.2. Secondary Name Node (SNN)

Ez a szerepkör ahogy els®re gondolnánk nem egy másodlagos Name Node, tehát az el-nevezése megtéveszt® lehet. Feladata az, hogy segítsen a NameNode-nak az általa tároltadatok kezelésében, és a namespace image karbantartásában. � gondoskodik arról, hogya fentebb említett Edit log-ot belef¶zze a Namespace image-be, és ezeket újra átadja azels®dleges Name Node-nak.

2.4.3. Data Node (DN)

Ezek a számítógépek tárolják gyakorlatilag a fentebb említett adatblokkokat. �k jelent-keznek be a Name Node-nak egy fájl keresése során, hogy annak a fájlnak egy blokkjanáluk található meg (reporting). A reporting folyamatosan megy, így szerez tudomást aName Node a túl és alul replikált blokkokról, illetve így tudja a klienst a megfelel® DataNode-hoz irányítani.

2.5. Adatm¶veletek

2.5.1. Olvasás

Az olvasást egy példán keresztül mutatjuk be. A 2.4. ábrán láthatjuk, hogy a kliens el®-ször a Name Node-dal veszi fel a kapcsolatot (Ê), akinek megmondja, hogy a �Results.txt�állományt szeretné olvasni. A Name Node az általa tárolt metaadatok alapján megmondjaa kliensnek, hogy ennek a fájlnak három blokkja létezik, és a blokkok külön-külön melyikData Node-okon vannak tárolva (Ë). Ezután a kliens egyesével közvetlenül az adatblokko-kat tartalmazó valamelyik Data Node-hoz fordul, és letölti azokat (Ì) (minden adatblokkesetében az azt tartalmazó valamelyik Data Node-hoz).

10


2.4. ábra. HDFS olvasásforrás: http://blog.csdn.net/suifeng3051/article/details/17288047

2.5.2. Írás

Az írás hasonló módon történik, mint az olvasás. A 2.5. ábrán látható, hogy a kliensel®ször felveszi a kapcsolatot a Name Node-al (Ê), hogy ® egy File.txt-t szeretne tárolni,amelyet 3 blokkra tudott felbontani. A Name Node visszaküld annyi Data Node címet,amennyi blokk szükséges (Ë). A kliens ezután közvetlenül a Data Node-oknak elküldi azegyes blokkokat (Ì). Ha ez készen van, akkor a Data Node-ok replikálják az új blokkokat(Í), és jelentik ezt a Name Node-nak (Î).

2.5. ábra. HDFS írásforrás: http://blog.csdn.net/suifeng3051/article/details/17288047

11

http://blog.csdn.net/suifeng3051/article/details/17288047

http://blog.csdn.net/suifeng3051/article/details/17288047

3. el®adás

MapReduce

A MapReduce nem egy programnyelv hanem programozási modell, egy programozásikeretrendszer, amely megadja, hogy hogyan hozzunk létre elosztott programokat. Kife-jezetten alkalmas arra, hogy nagy adathalmazon dolgozzon elosztott módon, sok adatpárhuzamos feldolgozására van kitalálva. Mivel nem egy programnyelv, ezért van megva-lósítása többféle programozási nyelv esetén is, például Java, Python, R stb. A MapReducenem csak Hadoop speci�kus, más adattárházakat is lehet MapReduce-ban programozni,ilyen például a MongoDB.

3.1. Az általános MapReduce modell

Egy példán keresztül nézzük meg az általános MapReduce modell m¶ködését. Adottegy adathalmaz, amely h®mérsékleti értékeket tárol. Határozzuk meg az évi maximumh®mérsékletet.

Adat: év, hónap, nap, óra, perc, város, h®mérséklet (nagy adathalmaz)Eredmémy: év, maximum h®mérséklet (kis adathalmaz)

Ha egy gépen szeretnénk leprogramozni ezt a feladatot, akkor egy sima maximum ki-választást kell valamilyen nyelven implementálnunk, így nem kell memóriában tartani azadatot, egyszeri végig olvasással meg tudjuk mondani a kérdésre a választ. Ha viszont márannyi adatunk van, hogy egy gépen ezt nem tudjuk tárolni, akkor valamilyen elosztottrendszeren kell az adott problémát megoldani. Ez viszont nem egyszer¶, ezért találtákki a MapReduce keretrendszert, amely elfedi a programozótól a párhuzamosítás feladatát(pl.: nem kell foglalkozni a gépek közötti kommunikációval, különböz® hibák és kiesésekkezelésével, er®forrás kiozstással stb). A keretrendszer alapvet®en kulcs-érték párokondolgozik, egy szöveges tartalom esetén a kulcs az, hogy a fájl hanyadik sora, és az értékpedig a sor tartalma szövegként. A MapReduce a nevéb®l adódóan két lépésb®l áll egyMap-b®l és egy Reduce-ból.

Map: (K1, V1) −→ list(K2, V2)Reduce: (K2, list(V2)) −→ list(K3, V3)

A Map lépésben kulcs-érték pár jön bemenetként és egy újfajta kulcs-érték párt, listátfog kiadni a kimenetén. A Reduce lépés a Map kimenetén lév® kulcs-érték párokat kapjameg, olyan formában, hogy az azonos kulcsokhoz tartozó összes érték egy listába kerül.

12

EL�ADÁS 3. MAPREDUCE

Err®l a lépésr®l a keretrendszer gondoskodik. Végül a Reduce kimenetén újabb kulcs értékpárokat fogunk kapni. Nézzük meg ez alapján az el®bbi példát:

Map: (sorID, sor) −→ (év, h®mérséklet)Reduce: (év, list(h®mérséklet)) −→ (év, max(h®mérséklet))

A Map bemenetén kulcs-érték párokat kapunk, ami jelen esetben sorazonosító-sor párokatjelent. Érdemes kiadnunk minden sorból, hogy melyik évr®l szól az a sor és mi volt azottani h®mérséklet. Ezzel lényegében a Map lépésben ebb®l az adatból kisz¶rjük aztamire szükségünk van, és minden sorra kiadjuk ezt a párost úgy, hogy az év lesz a kulcs.A Reduce bemenetén megjelenik az év mint kulcs és az összes abban az évben mérth®mérséklet. A Reduce-ból pedig kiadjuk az évet és a maximum h®mérsékletet.A MapReduce keretrendszerben megírt program esetén a programozónak annyi a fel-adata, hogy logikailag megírjon egy Map és egy Reduce függvényt majd a keretrendszergondoskodik róla, hogy elossza ezt a feladatot. A Map függvény bemenete lehet blokk,fájl de akár sor is és a bemeneten egymástól függetlenül soronként hajtódik végre. Teháta Map lépés triviálisan párhuzamosítható. A Reduce lépés is, hogyha megkapja az egykulcshoz tartozó összes elemet akkor az is egyszer¶en párhuzamosítható. A keretrend-szer azt biztosítja számunkra, hogy amikor kijönnek ezek a kulcs érték párok akkor ezbiztosan megérkezzen egy Reduce függvény bemenetére úgy, hogy az összegy¶jtés mártulajdonképpen megtörtént. Ha két gépr®l beszélünk akkor úgy lehet elképzelni, hogymeg van írva egy Map függvény, (hogy hogyan lehet kiszedni az évet és a h®mérsékleteketaz adatokból) és itt a Map függvénynek meg van adva az, hogy páros évszámú adatokataz egyikhez a páratlan évszámú adatokat a másik géphez küldi. A Reduce gépen történikezeknek a listába rendezése, kulcs alapján a beérkez® adatokat rendezi és utána könnyedénlétre tudja hozni ezeket a listákat. Hadoop esetén az MapReduce keretrendszer �gyel alokalitás elvére is, tehát minden adatot lehet®leg ott dolgoz fel, ahol az rendelkezésre áll,így nagyban csökkentve a hálózati kommunikációt, és növelve a sebességet.

3.1.1. 1. Feladat

Vannak dokumentumaink vagy valamilyen szöveges fájlok amik soronként tetsz®leges szö-veget tartalmaznak, az elvárt eredmény az, hogy minden szóra mondjuk meg, hogy hány-szor szerepel.

Map: (sorID, sor) −→ (szó, 1)Reduce: (szó, list(#)) −→ (szo, #)

Ahogy látunk egy szót, azt rögtön kiadjuk a Map oldalon, míg a Reduce oldalon egy simaszámlálót kell megvalósítani. Ennek egy variációja, ha a Map oldalon megszámláljuk azegyforma szavakat a sorban, és a szavak számát adjuk meg a konstans 1 helyett. Az utóbbimegoldás nagyobb terhet rak a Map oldalra, viszont csökkenti a hálózati kommunikációtés a Reduce oldal terhelését.

3.1.2. 2. Feladat

Kérem az összes sort amiben szerepel a BME szó.A feladatot Map oldalon lehet a legegyszer¶bben megoldani. A kiadott kulcs bármi lehet.A Reduce egyszer¶en megismétli a kimenetén a bemenetét.

13


Map: (sorID, sor) −→ (?, sor)Reduce: dummy reduce

3.1.3. Hadoop MapReduce felépítése

3.1. ábra. A MapReduce m¶ködése Hadoop eseténforrás: http://www.drdobbs.com/database/hadoop-the-lay-of-the-land/240150854

Vannak HDFS blokkjaink, a Hadoopban az esetek jelent®s részében egy Map task egyHDFS blokkon dolgozik (egy HDFS blokk egy számítógépet jelent). A Map feladat so-ronként egymástól független, általában JAVA-ban megírt program részletr®l beszélünk,indul egy JVM és az soronként elkezdi feldolgozni. A kimenetét pedig megfelel®en irányí-tani kell a Reduce-ok felé. Az a feladata, hogy a megfelel® kulcsú elemeket a megfelel®Reduce-hoz juttassa el. A Map után létezik még egy Partitioning függvény ami kap egykulcsot és megmondja, hogy melyik Reduce folyamathoz tartozik, lényegében ez egy hashfüggvény. A Particioning-et már a Map gépen végezzük. Tudunk csinálni egy Combi-ner függvényt is ami egy adatblokkon a Partitioning után lefuttat egy másik függvényt is.Tudunk írni saját particionáló függvényt is de alapértelmezetten egy egyenletes hash függ-vény, amely csak nagyon egyenetlen adateloszlás esetén nem m¶ködik jól. Ahhoz, hogymajd a Reduce-nál össze tudjuk gy¶jteni a kulcshoz tartozó összes értéket egy nagy Sor-tolást kell végrehajtani, történik egy lokális sort így lesznek kisebb eredményhalmazainkamik már rendezettek és ezt küldik el a Reducer-nek. A kisebb eredményhalmazain-kat egy összefésüléses rendezéssel érdemes összef¶zni (természetesen err®l a keretrendszergondoskodik). A Reduce a kimenetét egy HDFS fájlba szokta tipikusan kiírni. Ahogy azarchitektúrából látszik egy MapReduce feladat indításának van egy elég nagy overhead-je(ez akár perces nagyságrendbe is eshet), tehát csak kell®en nagy feladatok esetén érdemeshasználni, és interaktív feladatokra nem igazán alkalmas.

3.1.4. Hadoop Cluster

Vannak hasonló szerepek mint a fájlrendszer esetében. Master szerep: JobTraceker, ® felelazért, hogy egy teljes job végrehajtásra kerüljön. A TaskTraceker pedig a végrehajtásért

14

http://www.drdobbs.com/database/hadoop-the-lay-of-the-land/240150854


felel®s, vannak neki szabad kapacitásai, Map illetve Reduce slot-ja (mennyi az ® kapa-citása) és a JobTraceker ezzel gazdálkodik, egyszer¶en odaadja neki a feladatokat, hogymelyik Map függvényt melyik Reduce függvénnyel futassa le. A TaskTrackernek semmiinformációja nincs arról, hogy a többiek hogy állnak, néha visszaszól a JobTracekernek,hol tart a feladatával (HeartBeat). Lényegében minden szervezési logika itt is a Master-ben (JobTrackerben) összpontosul. A 3.2. ábra az írás és olvasás m¶ködését szemlélteti.Mi történik amikor egy számítási feladatot szeretnénk végrehajtani. Van egy kliensünk,egy JobTrackerünk illetve több TaskTracker. Illetve van egy HFDS (közös fájlrendszer)amivel mindenki tud kommunikálni. Az els® lépés az az, hogy a kliens bejelentkezik aJobTrackerhez, hogy szeretne egy feladatot végrehajtani. Erre válaszul kap egy azonosítótés egy jogosultságot, hogy onnantól kezdve azzal a job-al foglalkozzon. Különböz® szük-séges dolgokat a HDFS-re másolja a kliens (Map és Reduce kódja illetve a el®re megírtlibrary-k amiket ezek a függvények felhasználnak) lényegében a job-nak egy teljes infor-mációs csomagját felrakja a HDFS-re. A TaskTracker sebessége nagyban függ attól, hogymekkora replikáció számot állítunk be a HDFS-en. Nagyon sokszor a replikációk számátmagasra állítják, így minden TaskTracker gyorsan hozzáférhet az HDFS-en tárolt adatok-hoz. A következ® lépés a submit vagyis a kliens szól a JobTrackernek, hogy induljon el eza job. A HDFS-en megvan minden információ ami a job-ot leírja, ez tipikusan egy XMLvagy egy JAR fájl stb.

3.2. ábra. A JobTracker m¶ködése Hadoop esetén

Amikor a JobTracker megkapja ezt a submit-ot megnézi, hogy a leíró helyes illetve azadatot is leírja amin le kell futtatni ezt a job-ot. Így ki tudja számolni hogy melyik fájlhány blokkból áll illetve hány Map és hány Reduce folyamat lesz. Rendelkezésre kell álljonminden olyan információ ami a feladatok kiosztását és elkezdését lehet®vé teszi. Nagyonfontos dolog, hogy nem a JobTracker fog kapcsolatot létesíteni a TaskTrackerek-kel, ha-nem várja, hogy a TaskTracker-ek bejelentkezzenek (HeartBeat)és elküldjék mennyi üresslot-juk van illetve az egyes taskok, hogy állnak náluk. A JobTracker tudja, hogy az egyes

15


adatblokkok hol helyezkednek el és melyik gépen vannak HDFS-en, továbbá tud arról,hogy milyen aktív jobok vannak és melyek azok amelyek nem futnak sehol és erre válaszulad egy task-ot a TaskTrackernek amiben benne van, hogy a HDFS-r®l hol tudja elérni an-nak a task-nak az információját. A JobTracker kiadja a task-ot a TaskTracker begy¶jti azinformációkat, hol érhet® el a Map függvény illetve a különböz® Partícionáló függvényeketés ezeket a szükséges adatokat a HDFS-r®l betölti. Így m¶ködik minden HDFS esetén,amíg vannak szabad Taskok amiket végre kell hajtani, addig mindegyik bejelentkezésnélmeg fogják kapni a feladatokat. Ha pedig végeznek küldenek egy HeartBeatet, hogy ez atask készen van. Adott esetben egy Map task szól hogy ® készen van és amikor a Reduceezt kiolvasta akkor lesz befejezettnek tekintve a Map-nek a feladata.

3.1.5. Meghibásodások

Ha meghal egy task akkor nincs semmi baj mert újraindítja azt a taskot a TaskTracker.Sajnos a JobTracker nem tudhatja, hogy egy-egy task azért halt meg mert rossz a fel-használó kódja, elment az áram, elromlott egy switch stb. Ilyenkor van egy limit, hogyhányszor lehet újraindítani azt a taskot. Igyekszik egy másik Node-on újraindítani az el-halt taskot a JobTracker. Létezik egy spekulatív futtatás nev¶ eljárás, miszerint ugyanazta taskot több TaskTrackeren is futtatja. Ennek az a célja, hogy ha bármikor van egy olyannode ami túl lassú, akkor az ne blokkolja az egész rendszert ezért több példányon elindulés ha valami befejez®dött a másikat eldobja (ezt leginkább az utolsó task-ok esetén szoktacsinálni a JobTracker). Ez abban az esetben jó, ha viszonylag kihasználatlan a cluster ésvan szabad er®forrás. Ha egy TaskTracker kiesik akkor nem fog jönni t®le több HeartBeatilyenkor a JobTracker azt látja, hogy az összes Task ami ott futott elhalt és újraindítjamáshol. Ha a JobTracker áll meg, akkor köztes állapotban maradnak a Nodeok és ha újraelindul akkor elölr®l indulnak az adott task-ok. Erre megoldás a redundancia alkalmazása,létezik egy High Availability kon�guráció ahol két JobTracker van.

16

4. el®adás

MapReduce programozási minták,

Streaming

4.1. 1. feladat

Adott egy adathalmaz, amely h®mérsékleti értékeket tárol. Határozzuk meg egy városátlagh®mérsékletét egy adott hónapban.

Adat1: év, hónap, nap, óra, perc, város, h®mérsékletEredmény: város, hónap, átlagh®mérséklet

Map: (sorID, sor) −→ ((város + hónap), h®mérséklet)Reduce: ((város + hónap), list(h®mérséklet)) −→ ((város + hónap), avg(h®mérséklet))

A szövegfájloknál a bemeneti kulcs-érték szinte mindig (sor, sorID) lesz, amikor valamilyenaggregálást végzünk. Ha SQL lekérdezést készítenénk erre a feladatra, akkor a Mapkimenetének a kulcsa az lesz, amit a GROUP BY mögé írnánk, ami szerint aggregálunk.Ezért lesz a Map kimenetének kulcsa a (város + hónap). A keretrendszer automatikusanezen kulcs alapján csinál egy listát, amely a Reduce bemenete lesz majd, így egy kulcshoztartozó értékek egy Reducehoz kerülnek. A Reduce pedig kiszámolja az egy kulcshoz,azaz a (város + hónap)-hoz tartozó átlagh®mérsékletet.

4.2. 2. feladat

Adott egy adathalmaz, amely egy weblog adatait tárolja. Határozzuk meg hogy melyiknap hány oldalletöltés volt.

Adat2: dátum, id®, sessionID, urlEredmény: dátom, oldalletöltések száma

Ha ez egy strukturált SQL tábla lenne, akkor a következ® lekérdezéssel lehetne a választmegadni:SELECT date, COUNT(*) FROM table GROUP BY date

A szövegfájloknál a bemeneti kulcs-érték szinte mindig (sor, sorID) lesz, amikor valamilyenaggregálást végzünk. A GROUP BY mögött a dátum van, ezért a Map kimeneti kulcsa a

17

EL�ADÁS 4. MAPREDUCE PROGRAMOZÁSI MINTÁK, STREAMING

Map: (sorID, sor) −→ (dátum, 1)Reduce: (dátum, list(1)) −→ (dátum, cnt(1))

dátum lesz, és csak meg kell számolni, hogy abból hány darab van. A Reduce-nak márcsak ezeket az 1-eseket kell megszámolnia.

4.3. 3. feladat

Az adathalmaz ugyanaz, mint az el®bb, de most azt szeretnénk megtudni, hogy hányegyedi látogató volt az oldalon egy napon. Egyedi látogatás alatt az egy sessionID-hoztartozó lekéréseket értjük.

Adat2: dátum, id®, sessionID, urlEredmény: dátum, egyedi látogatószám

Ha ez egy strukturált SQL tábla lenne, akkor a következ® lekérdezéssel lehetne a választmegadni:SELECT date, COUNT (DISTINCT(sessionID)) FROM table GROUP BY date

Map: (sorID, sor) −→ (dátum, sessionID)

Reduce: (dátum, list(sessionID))unique−−−→ (dátum, cnt(distinct(session)))

A szövegfájloknál a bemeneti kulcs-érték szinte mindig (sor, sorID) lesz, amikor valamilyenaggregálást végzünk. A Map kimeneti kulcsa a dátum lesz és a Reduce fogja az egyediségetgarantálni (unique). Az egy Reduce folyamatnak kell az egy dátumhoz tartozó összeskérést a memóriában tartani és ez sz¶k keresztmetszet lehet, ha egy napon nagyon sokadat keletkezett, akkor a folyamatunk nem tud skálázódni. Ezért érdemesebb szétbontaniezt két külön MapReduce folyamatra:

Map 1: (sorID, sor) −→ ((dátum + sessionID), 1)Reduce 1: ((dátum + sessionID), list(1)) −→ ((dátum + sessionID), 1)

Map 2: ((dátum + sessionID), 1) −→ (dátum, 1)Reduce 2: (dátum, list(1)) −→ (dátum, cnt(1))

Az els® MapReduce folyamat kimeneti kulcsa a (dátum + sessionID), így minden naphozegy sessionID csak egyszer tartozhat. A második folyamatban már csak meg kell számol-nunk, hogy az adott dátumhoz hány bejegyzés található. Ezzel módszerrel skálázhatóvátettük a megoldást még akkor is, ha egy naphoz nagyon sok adat tartozik, mert nem kellegy Reduce folyamatnak a memóriában tartani az egy naphoz tartozó összes adatot.

4.4. 4. feladat

Az adathalmazunk az el®bb már megismert weblog adatai, amihez felveszünk még egykapcsolótáblát, amely megmondja, hogy melyik sessionID melyik felhasználóhoz tartozik.Gyakori feladat, hogy a két táblát össze kell illeszteni (join).

18


Adat2: dátum, id®, sessionID, url - LEFTAdat3: sessionID, userID - RIGHT

Map: (sorID, sor) −→ (sessionID, (L/R + sor))Reduce: (sessionID, list(L/R + sor) −→ list(sessionID, (sorR + sorL))

Erre az egyik lehet®ség a REDUCE-SIDE join:Az Adat2 halmazt nevezzük el baloldali táblának, az Adat3 halmazt pedig nevezzük eljobb oldali táblának. A Map bemenete a mindkét tábla soraiból adódik, de tudnia kell,hogy melyik táblából érkezett az adat. Ha SQL lekérdezést készítenénk erre a feladatra,akkor a Map kimenetének a kulcsa az lesz, ami alapján végeznénk a join m¶veletet. Ezérta Map kimenetén a kulcs a sessionID lesz, az érték a sor tartalma és hogy melyik táblábólszármazik (L/R). A Reduce folymat a sessionID-hoz tartozó értékeket a memóriábantartja és úgy végzi el az összeillesztést (például egy for ciklussal összeilleszt mindenkitmindenkivel). Ez akkor okozhat problémát, ha az összeilleszt® elemhez (jelen esetben asessionID-hoz) nagyon sok adat tartozik, amely nem fér el a Reducer memóriájában. Amásik hibája ennek a megoldásnak, hogy lehet olyan sessionID, amir®l nincs rekordunk amásik táblában. Ekkor ezt feleslegesen küldjük át és generálunk vele nagy adatforgalmat.(Sok esetben el®fordul, hogy a felhasználó nem lép be az adott oldalra, így csak sessionID-ttudunk hozzá társítani, de userID-t nem.)Ez a probléma egy másfajta joinnal elkerülhet®. A Map kimenetén nem adjuk ki márazokat az elemeket, amikhez nem lehet másik táblából adatokat társítani, ez lesz aMAP-SIDE (broadcast) join:

Map: (sorID, sorL) −→ (sorID, (sorL + sorR))Reduce: -

A joinok nagy része olyan szokott lenni, hogy van egy nagy táblánk és van egy kisebbtáblánk, például minden felhasználóhoz egy rekord. Ha ez a kisebb tábla elfér a memó-riában, akkor el®ször minden Mapnek elküldjük ezt a táblát, hogy csináljon bel®le egysessionID-userID struktúrát a memóriában. Eztán a másik táblából átküldjük a sorokatés megnézzük, hogy melyiket kell ehhez hozzáilleszteni. Így a Map bemenete csak a sorIDés a bal oldali tábla sorai lesznek, míg a jobb oldali tábla a Map memóriájában van. Azösszeillesztés már a Map lépésben megtörténik, tehát nincs szükség Reduce lépésre.Általában ez a két join típus használatos, mindkett®nek megvannak a saját korlátai, de havan valamilyen plusz információnk az adatok szerkezetér®l vagy rendezettségér®l, akkorgyorsabb és jobban skálázódó join függvényeket is tudunk készíteni.

További MapReduce példák az A. függelékben találhatóak.

4.5. Streaming

Java-ban MapReduce kódot írni nehézkes, mert meglehet®sen sok kódot kell írni, ezértvalós igény az, hogy ne csak Hadoop-Java API-val írhassunk kódot. Erre van egy olyanmegoldás, aminek a neve Hadoop-streaming: bármilyen nyelvben meg lehet írni MapRe-duce függvényeket, amelyek a standard bemenetr®l (stdin) tudnak olvasni és standardkimenetre (stdout) tudnak írni. A keretrendszer a standard bemenetre fogja küldeni az

19


adatot és a standard kimeneten fogja várni a függvény eredményét. A kulcs-érték párokszeparálása soronként tabbal történik.A következ® példán keresztül nézzük meg, hogy ezt hogyan lehet megvalósítani pythonban.

Bemenet: dátum, h®mérsékletKimenet: adott évi maximum h®mérséklet

Ennek a MapReduce megoldása:

Map: (sorID, sor) −→ (év, h®mérséklet)Reduce: (év, list(h®mérséklet) ) −→ (év, maxh®mérséklet)

A Map és a Reduce függvények megvalósítása pythonban:

1 for line in sys.stdin:

2 vals = line.split(",")

3 print vals [0] \t vals [1]

4.1. Kódrészlet. map.py

1 last_key = None

2 max_val = -9999

3

4 for line in sys.stdin:

5 (key , value) = line.split("\t")

6 if key == last_key:

7 if max_val < value:

8 max_val = value

9 else:

10 print last_key max

11 max_val = -9999

12 last_key = key

4.2. Kódrészlet. reduce.py

4.6. Adattömörítés

Általános felhasználás mellett a Hadoop keretrendszer inkább tárhely, mintsem processzor-igényes. Nagyon nagy adathalmazokat kell tárolnunk, illetve egy Map és egy Reduce lépésközött nagyon sok adatot kell mozgatnunk. Ezért ezeket a lépéseket érdemes optimalizál-ni, amelynek az els®dleges módja az adattömörítés.Adattovábbítás a hálózaton Snappy tömörítéssel történhet, mivel nagyon kicsi a CPUoverheadje. Nem olyan hatékony tömörít® algoritmus, mint például a gzip, de streamkénttud tömöríteni és így elég sokat tud spórolni az adatátvitelen (20-30 %-os teljesítmény-nyereség).A másik lehet®ség a tömörített fájlok használata. A rendszer automatikusan felismeri atömörített fájlokat és kitömöríti a különböz® feladatok el®tt. A merevlemezen történ®tároláshoz a következ® tömörítéseket szokták alkalmazni:

20


� gzip: Tegyük fel hogy van egy 1 GB-os fájlunk ami 16 blokkból áll és tömörítvevan. A blokkméret 64 MB, így ekkora részekre van vágva a tárolónkon. Ha csakegy rész kell a fájlból, akkor is ki kell ki kell tömöríteni az egészet, hogy ki tudjukolvasni bel®le az adatot. Egy Map folyamat el®tt mindenhova el kellene juttatni ateljes fájlt, hogy az adott blokkot a Map fel tudja dolgozni. Ezért a gzip esetén afájlokat úgy érdemes szervezni, hogy a fájlok a blokkmérettel azonosak legyenek.

� bzip2: Olyan tömörítési eljárás, amelyet ha bárhol elkezdünk olvasni, akkor is kilehet olvasni a fájl tartalmát, de ezt nem annyira használják, mert eléggé lassú ésnem annyira hatékony.

� lzo: Az ezzel a tömörített fájlt sem lehet bárhonnan olvasni alapesetben anélkül,hogy ki kellene az egész fájlt tömöríteni, de emellé kitaláltak egy metaadat fájlt,amely tartalmazza a Map folyamat számára, hogy mely blokkot kell kitömöríteni.

A legegyszer¶bb eset, ha nyers adatokkal dolgozunk, de nagyon nagy fájlméretek ese-tén már szükségessé válik a tömörítés, akkor ha lehetséges a gzip-es tömörítést érdemesalkalmazni a blokkmérettel azonos nagyságú fájlokkal. Ezen kívül sok kicsi fájl összevoná-sára még a SequenceFile formátum is használatos, ami egy Hadoop speci�kus formátum,leginkább a tar formátumra hasonlít.

21

5. el®adás

Hadoop csomagok, SQL for Hadoop:

Hive

5.1. Hadoop csomagok

Minden csomag vagy projekt opensource, Apache oldalán megtalálható a megfelel® alol-dalon forráskóddal és dokumentációval együtt.

5.1.1. Flume

Logok tárolása és gy¶jtése a szerepe, képes HDFS-en tárolni a logokat. Egy általánosuse-case, hogy van egy webes cég ahol kiszolgálják felhasználókat. Minden webszerverenindítanak egy Flume ágenst aminek van valami bemeneti pontja, és bármilyen üzenetetkap onnantól az ® feladat az, hogy továbbítsa ezt az üzenetet. Ez egy megbízható logo-lási rendszer. Fontos, hogy a logok megmaradjanak ugyanis kés®bb ezek alapján lehetelemezni a program m¶ködését és a felhasználói élményt. Megkönnyíti, hogy bármilyenszámítógépt®l logokat gy¶jtsünk és nem kell a webalkalmazásnak azzal foglalkoznia, hogya logokat elküldje, a logszerver megkapja, hanem mindezt átveszi a Flume. Nem egyspeciális Hadoop csomag de a Hadoophoz nagyon sokan használják. Fontos megjegyezni,hogy ez egy egyirányú adat közvetítés.

5.1.2. Sqoop

Különböz® SQL alapú adatbázisokkal tud adatot cserélni. Valamilyen JDBC kapcsolatonkeresztül elér egy adatbázist és képes arra, hogy ha valahol van egy 10 gépb®l álló MySQLcluster akkor a sqoop, ezt a táblát át tudja másolni a HDFS-re. Ilyenkor több Mapetelindít és elosztottan tud másolni adatbázisok és Hadoop között. Ez természetesen oda-vissza m¶ködik és az a nagy el®nye, hogy habár ezt bármilyen adatbázissal meg tudnácsinálni, képes arra, hogy párhuzamosítsa ezt feladatot így sokkal gyorsabb. A folyamatlényegében az, hogy indul egy MapReduce job a JDBC connection kiépül és jönnek azadatok.

5.1.3. Hive

Ez a csomag már az elemzési réteghez tartozik míg a korábbiak az adatelérési rétegbennyújtanak szolgáltatásokat. Tulajdonképpen egy SQL lekérdez® nyelvet nyújt Hadoop

22

EL�ADÁS 5. HADOOP CSOMAGOK, SQL FOR HADOOP: HIVE

felé. A Hive-nak az a feladata, hogy SQL lekérdezéseket lehet vele végrehajtani. Az SQLlekérdezésb®l csinál egy MapReduce job-ot és ezt lefuttatja a clusteren majd visszaadjastrukturált táblázatos formában az eredményeket. Ez kényelmes mivel csak SQL kifejezé-seket kell írni és nem kell gondolkozni a Map és a Reduce függvényeken. Sok mindenbenkülönbözik egy hagyományos adatbázisnak az SQL lekéréseit®l, sokkal több id®be telikegy lekérdezés, ezért tipikusan analitikus elemzésekhez használják.

5.1.4. Pig

Ez egy szkript nyelv ami céljában hasonlít az SQL-hez. A feladata lényegében ugyanaz,MapReduce job-okat csinál a szkriptb®l. Nagyon rugalmasan kezeli a sorok feldolgozásátbármit megeszik. Preziben szinte kizárólag piget használnak, viszonylag könnyen tanul-ható és hasonló szerepe van mint a Hive-nak, hogy helyetted MapReduce jobokat hozzonlétre.

5.1.5. HBase

Minden amir®l eddig szó volt az HDFS és MapReduce alapokon m¶ködött. Az HBaseegy specialitása, hogy nem indít MapReduce jobot mivel az HBase az egy kulcs-értékadatbázis mely megvalósítja a NoSQL paradigmát. A NoSQL (egyes értelmezések szerintNot only SQL, azaz nem csak SQL, más értelmezés szerint egyszer¶en csak nem SQL)adatbázis szoftverek gy¶jt®neve. A NoSQL adatbázisok els®sorban nem táblázatokbantárolják az adatokat és általában nem használnak SQL nyelvet lekérdezésre. Ez egy kulcs-érték adatbázis amelynek hatalmas el®nye az, hogy nem MapReduce alapokon dolgozik,hanem közvetlen hozzáférése van a HDFS-hez. Így képes milliszekundumos lekérésekvégrehajtására (sokkal gyorsabb mint a Hive).

5.1.6. Mahout

Ez egy szintén népszer¶ csomag, statisztikai gépi tanulási algoritmusokat tartalmaz, osz-tályozó algoritmusok, gyakori mintakeres®, szöveg osztályozásra használják sokan.

5.1.7. Zookeeper

Létezik egy állatgondozó nev¶ csomag (Zookeeper). Minden egyéb Hadoop csomag fel-használja ennek a szolgáltatásait, mivel egy elosztott rendszerben elég nehéz a konkurensdolgoknak a kezelése. Ha két kliens ugyanazt a HDFS blokkot akarja írni vagy ugyan-azt a táblát akarják írni, ezek nem triviális problémák. Ezeket a szervezési koordinációsdolgokat valósítja meg a Zookeeper.

23


5.1. ábra. A Hadoop csomagok felépítéseforrás: http://www.colfax-intl.com/nd/clusters/hadoop.aspx

5.2. SQL for Hadoop: Hive

A Hadoop most már lassan 10 éves, de kezdetben eléggé üres volt és kevés volt hozzáaz eszköz. Szükség volt valami egyszer¶ felületre amit tömegesen tudnak használni azemberek. A Facebook hozta létre, kellett egy SQL alapú csomag mert a JAVA MapReduceprogramozás nem igazán m¶ködött és eléggé nehéz volt. Elkezdték a HIVE fejlesztésétami egy SQL interface a hadoopra (egy plusz réteg de nem tárház). Maga a Hadoopplatformot azért választották mert olcsó és jól skálázódik.

5.2.1. A Hive felépítése

5.2. ábra. A Hive m¶ködéseforrás: http://blog.octo.com/en/how-to-crunch-your-data-stored-in-hdfs/

Van egy Driver ami a fordításért felel és az SQL kifejezéseket fordítja MapReduce job-okra. A következ® lépcs® az optimalizálója, ezt ® kitalálja maga, hogy hogyan legyenhatékonyabb a lekérdezés. (minden SQL motorban található egy ilyen). Az Executor

24

http://www.colfax-intl.com/nd/clusters/hadoop.aspx

http://blog.octo.com/en/how-to-crunch-your-data-stored-in-hdfs/


pedig az aki operatívan ezt a futtatást elvégzi. Kommunikál a MapReduce-szal és elvégziennek a futtatását. Ezen kívül meg találhatók a következ® elemek még benne: CommandLine Interface (CLI), JDBC, ODBC kapcsolat távoli elérésekhez. Létezik továbbá egyMetaStore nev¶ komponens is amelyben olyan bejegyzések vannak, hogy milyen tábláinkvannak, milyen a fájlok formátuma, mi a szeparátor karakter, milyen típusú adatok illetvemez®k vannak (ez írja le, hogy lehet a szöveges fájlokat adatbázis táblaként értelmezni).Az esetek túlnyomó többségében ez egy MySQL adatbázis amely általában kis méret¶,egy gépen futó SQL adatbázis. Amikor err®l a számítógépen elindítanak egy lekérést ak-kor ez végig megy az összes említett komponensen és a végén megkapjuk az eredményeket.Furcsa lehet azonban, hogy adatot feltöltünk és utólag valami sémát de�niálunk rá, ez azeddigi tudásunkkal pont ellentétesen m¶ködik. Ezt a folyamatot úgy hívják, hogy scheme-on-write. Amikor bekerül az adat akkor ellen®rzöm a sémát (amikor a táblába betöltöm)és onnantól tudom, hogy jó az adat ami bekerül a táblába. A scheme-on-read pedig kiol-vasáskor ellen®rzi a sémát, ha rossz az adat azokon a helyeken null-t fogunk visszakapninem hibát. További különbségek az SQL és a Hive között: nincs olyan hogy UPDATE.Egyszer¶en nincs rá szükség, logokat gy¶jtünk és miért akarnánk frissíteni a tegnapi ada-tokat (persze ha meg akarjuk hamisítani akkor lehet) de ráadásul az adatok is blokkokbanvannak tárolva és egy blokkban egy adatot módosítani nem éri meg. Indexeléssel vannakközepesen kiforrott próbálkozások, de alapvet®en adattáblák végig olvasására találták kiés nem arra, hogy egy felhasználó adataival m¶veleteket végezzünk, majd pedig ezeket azadatokat újra beleírjuk az adatbázisba.

25

6. el®adás

Pig programozás

6.1. Bevezetés

A Pig egy magas szint¶, az SQL nyelvhez hasonló szkript nyelv, amit az Apache Hadoophasznál MapReduce job-ok létrehozására. Lehet®vé teszi komplex adat transzformációkírását Java tudás nélkül.A nyelv eszközkészlete teljes, ezért mindenféle adatmanipulációs m¶veletet tudunk velevégrehajtani. A felhasználó által de�niált függvényeken keresztül (User De�ned Functions- UDF), pedig bármilyen kódot meghívhatunk különféle nyelvekb®l mint például: JRuby,Jython és Java. A scriptünket más nyelvekbe is beágyazhatjuk, ennek eredményeképpkomponensként használhatjuk, hogy nagyobb rendszereket készítsünk, és még komplexebbalkalmazásokat, amik releváns problémákra adnak megoldást.A Pig többféle forrásból származó adattal tud dolgozni, beleértve strukturált és struk-turálatlan adatokat, az eredményt pedig eltárolhatjuk a HDFS-en. A Pig szkripteketMapReduce job-okra fordítják, amik az Apache Hadoop klaszteren futnak. Ebben a fe-jezetben követve a Hortonworks leírását (Hogyan használjuk az alapvet® pig parancsokathttp://hortonworks.com/hadoop-tutorial/how-to-use-basic-pig-commands/), át-nézzük az alapvet® m¶veleteket, és a szkript nyelv használatát. A következ® területeketérintjük:

� Egy reláció készítése séma nélkül

� Egy új reláció készítése egy létez® relációból

� Két reláció illesztése (Join m¶velet)

� Adatok rendezése az ORDER BY használatával

� Az adatok sz¶rése és csoportosítása a GROUP BY használatával

A leírás a Hortonworks rendszeren lett elkészítve, de valószín¶ könnyedén átültethet®egyéb rendszerekre is.

6.2. A fájlok feltöltése

Els®ként szerezzük be a szükséges adatokat a feladat elvégzéséhez. Err®l a linkr®l letudjátok tölteni a szükséges adatokat, amik a New York Stock Exchange adatait tartal-mazzák 2000 és 2001-es évb®l. https://s3.amazonaws.com/hw-sandbox/tutorial1/

infochimps_dataset_4778_download_16677-csv.zip

26

http://hortonworks.com/hadoop-tutorial/how-to-use-basic-pig-commands/

https://s3.amazonaws.com/hw-sandbox/tutorial1/infochimps_dataset_4778_download_16677-csv.zip

https://s3.amazonaws.com/hw-sandbox/tutorial1/infochimps_dataset_4778_download_16677-csv.zip

EL�ADÁS 6. PIG PROGRAMOZÁS

Töltsük fel az adatokat a File Browser segítségével.

6.1. ábra. Adatok feltoltese

6.3. A script megírása

A Pig felhasználói felületét a Pig ikonra kattintással tudjuk el®hozni. A baloldali panelena szkriptjeink listáját láthatjuk, a jobb oldalon pedig a szerkeszt® felületet, a szkriptekírásához és módosításához. Egy speciális funkció az oldal alján található, mégpedig a Pighelper, ami templateket nyújt a Pig kifejezésekhez, függvényekhez, I/O m¶veletekhez,stb. Az oldal alján látható egy státusz felület, amikor futtatjuk a szkriptet itt láthatjukmajd az eredményeket és a log fájlokat. Adjunk egy nevet a szkriptnek és kezdjük el aszkript írását egy reláció létrehozásával.

6.2. ábra. Pig script szerkeszt® felülete

6.3.1. Reláció de�niálása

Ebben a lépésben beolvassuk az adatokat és létrehozunk egy relációt.

1 STOCK_A= LOAD 'nyse/NYSE_daily_prices_A.csv' using PigStorage(',');

2 DESCRIBE STOCK_A;

Az els® sorban de�niálunk egy relációt STOCK_A néven és beolvassuk a *.csv fájlunkat,a második sorban pedig kiírjuk a STOCK_A relációt. A "Save" gombbal elmenthetjük

27


a szkriptet az "Execute" gombbal pedig futtathatjuk. Ez a m¶velet egy, vagy több Ma-pReduce job-ot fog indítani. Egy kis id® múlva a script futni kezd, és az "Execute" gombegy "Kill" gombra fog változni. Ezzel megállíthatjuk a szkript futását. A Progress barmutatja, a folyamat el®rehaladását. Ha kék a színe, akkor a job fut. Ha piros a színe,akkor valami probléma, vagy hiba történt. Ha zöldre vált, a szkript helyesen lefutott. Azeredményt megtekinthetjük a zöld dobozban a Progress bar alatt, vagy el is menthetjük.Jelenleg a STOCK_A relációnak nem lesz sémája, mert nem de�niáltunk neki sémátmikor betöltöttük az adatot a STOCK_A relációba.

6.3. ábra. A séma kiírása

6.3.2. Reláció de�niálása sémával

Módosítsuk az el®z® szkriptünknek az els® sorát és adjuk hozzá a "AS" kifejezést, hogyegy sémát de�niáljunk az adatokra.

1 STOCK_A = LOAD 'NYSE_daily_prices_A.csv' using PigStorage(',') AS (

exchange:chararray , symbol:chararray , date:chararray , open:float

, high:float , low:float , close:float , volume:int , adj_close:

float);

2 DESCRIBE STOCK_A;

Mentsük el és futtassuk a szkriptet. A kimeneten látható lesz a séma, amit de�niáltunk.

6.4. ábra. A létez® séma kiírása

6.3.3. Reláció létrehozása egy másik relációból

Egy létez® relációból tudunk új relációkat létrehozni. Például szeretnénk egy B relációtkészíteni, ami a STOCK_A relációnak az els® 100 bejegyzését tartalmazza. Adjuk hozzáa szkriptünkhöz a következ® sort.

28


1 B = LIMIT STOCK_A 100; DESCRIBE B;

2 DESCRIBE B;

Mentsük el és futtassuk a szkriptünket. Láthatjuk, hogy a B relációnak ugyanaz a sémája,mint a STOCK_A relációnak, mivel egy részhalmaza a STOCK_A relációnak.

6.3.4. Adatok kiírása

Az adatok kiírásához használjuk a DUMP parancsot a Pig szkriptünkben. A szkriptünkvégéhez f¶zzük hozzá a következ® sort. Mentsük el és futtassuk újra a szkriptünket.

1 DUMP B;

6.3.5. Oszlop kiválasztása a relációból

Töröljük az eddig megírt szkriptet, mivel a következ®kben nem lesz rá szükségünk. Azegyik el®nye annak, hogy a Piget használjuk az adatok transzformációja. Új relációkattudunk létrehozni, a meglév® relációkban lév® mez®k kiválasztásával, a FOREACH parancshasználatával. De�niáljunk egy új relációt C néven, ami csak a symbol, adat és closemez®ket tartalmazza a B relációból. A teljes kód a következ®:




float);

2 B = LIMIT STOCK_A 100; C = FOREACH B GENERATE symbol , date , close;

3 DESCRIBE C;

Mentsük és futtassuk a szkriptünket, a kimeneten a következ® fogjuk látni.

6.3.6. Adatok írása a HDFS-re

Ebben a részben megnézzük, hogy hogyan tudunk írni a HDFS-re a szkriptünkb®l. Akövetkez® parancsot írjuk bele a szkriptünkbe:

1 STORE C INTO 'output/C';

Ezúttal is indulni fog egy MapReduce job, így várnunk kell egy kicsit az eredményre.Amikor a Job futása befejez®dik nyissuk meg a File Browsert, és keressük meg az újonnankészített könyvtárunkat, aminek a neve output. Ebben lesz egy alkönyvtár C néven,amiben találni fogunk egy part-r-00000 nev¶ fájlt. Ha rákattintunk láthatjuk a tartalmát.

6.3.7. Két reláció illesztése (Join m¶velet)

Készítsünk egy új Pig szkriptet Pig-Join néven, majd hozzunk létre egy új relációt DIV_Anéven. Ezután illesszük a két relációt A és B a symbol és dátum mez®k alapján, majd

29


6.5. ábra. Adatok kiírása a HDFS-re

írjuk ki az új reláció sémáját.




float);

2

3 DIV_A = LOAD 'NYSE_dividends_A.csv' using PigStorage(',') AS (

exchange:chararray , symbol:chararray , date:chararray , dividend:

float);

4

5 C = JOIN STOCK_A BY (symbol , date), DIV_A BY (symbol , date);

6 DESCRIBE C;

Ha meg�gyeljük a C reláció mind a két relációból tartalmazni fogja az összes mez®t. ADUMP paranccsal tudjuk kiírni a C reláció tartalmát.

6.3.8. Adatok rendezése

Az ORDER BY parancs segítségével tudjuk a relációt rendezni egy, vagy több mez®jére.Készítsünk egy új Pig szkriptet Pig-Sort néven, majd adjuk ki a következ® parancsokataz adatok rendezéséhez.



float); B = ORDER DIV_A BY symbol , date asc;

2 DUMP B;

6.3.9. Adatok sz¶rése és csoportosítása

A GROUP paranccsal tudjuk egy mez®re csoportosítani az adatokat, a FILTER paranccsalpedig sz¶rhetjük ®ket egy mintára. Készítsünk egy új Pig szkriptet Pig-group néven ésírjuk be a következ® parancsokat a szerkeszt® felületen.

30




float);

2 B = FILTER DIV_A BY symbol =='AZZ';

3 C = GROUP B BY dividend;

4 DESCRIBE C;

5 DUMP C;

6.4. További források

Az alapvet® parancsok átnézése után, ha szeretnél jobban elmélyedni a Pig szkriptekírásában, akkor remek elfoglaltság a Pig dokumentációjának az átolvasása, amelyet akövetkez® linken értek el. http://pig.apache.org/docs/r0.7.0/tutorial.html.

31

http://pig.apache.org/docs/r0.7.0/tutorial.html

7. el®adás

Hadoop klaszterek kon�gurációja és

üzemeltetése

Egy Hadoop cluster felállítása annyira nem is egyszer¶ feladat, mint ahogy azt gondol-nánk. Sok szempontot �gyelembe kell vennünk az elosztott rendszerek megtervezésekor.

7.1. Hardver

A cluster legfontosabb épít®elemei a számítógépeket (Node-okat) kiszolgáló hardverek.Minden Node-ként egy olyan hardverrel felszerelt gépet kell üzemeltetnünk, amely kell®ensok háttértárral rendelkezik, és a számítási feladatokhoz er®s CPU és jelent®s memória-mennyiség jellemzi.A hardverméretezést egy példán keresztül mutatjuk be. Tegyük fel, hogy egy cég átszeretne térni Hadoop cluster-es szerverparkra, amelyen naponta 100 GB új bejöv® adatotszeretnének tárolni. Ezt a mennyiséget egy évre levetítve ∼36 TB-ra becsülhet® a tárolnikívánt adat. Tudjuk, hogy a Hadoop cluster egy adatot 3 különböz® helyen tárol el areplikáció miatt, tehát ez a mennyiség ∼100 TB lesz. Az egyéb dolgok és elemzésekcéljából +25%-kal számolhatunk, tehát 125 TB-nál tartunk. A Hadoop rendszer elég sokmindenr®l készít log-ot, valamint emellett minden gépen kell operációs rendszernek futnia,tehát szükség van olyan adatok tárolására is, amik nem a HDFS-en belül találhatóak. Erre+10%-ot számolunk, tehát nagyjából ∼140 TB tárhelyre van szükségünk. Egy átlagosszervergépben 4-6 HDD található, ha 3 TB-os egységekben gondolkozunk, akkor ez 12-18TB. Ha a fentebbi adatmennyiséget nézzük, akkor ∼10 gépes cluster-t kell felállítanunk.Mivel tipikusan az IO a sz¶k keresztmetszet Hadoop esetén, ezért érdemesebb több kisebbHDD-t berakni, mint kevés extrém nagyot.Hozzá kell tennünk, hogy ez az adatmennyiség nem tömörített, tömörítéssel sokkal keve-sebb adatmennyiséggel is lehet számolni. Például egy olyan log esetében, ahol ugyanazaz érték sokszor szerepel, vagy ismétl®dik, ott gzip esetén akár 2-3-szoros tömörítési rátais elérhet®, ezzel rengeteg helyet tudunk spórolni.Memória tekintetében a master szerepeket birtokló gépek esetében az ajánlott mennyiség24 GB, a CPU-nak pedig érdemes 8 magost választani (2013-as adatok alapján). Emelletta fontos szerepeket kiszolgáló gépek esetében érdemes egy bizonyos védelmet is beiktatni(pl. RAID). Az egyszer¶ Data Node-ok esetében elég egy 4 magos CPU, és 8-24 GB me-mória. A Hortonworks által ajánlott hardverméretezésr®l a 7.1. táblázatban találhatunkrészletesebb bemutatást.

32

EL�ADÁS 7. HADOOP KLASZTEREK KONFIGURÁCIÓJA ÉS ÜZEMELTETÉSE

Machine Type Workload Pattern/ Cluster Type Storage Processor (# of Cores) Memory (GB) Network

SlavesBalanced workload Four to six 2 TB disks One Quad 24

1 GB Ethernet all-to-allHBase cluster Six 2 TB disks Dual Quad 48Masters Balanced and/or HBase cluster Four to six 2 TB disks Dual Quad 24

7.1. ábra. Hardver méretezés ajánlások 5-50 gépes cluster-ekhez1

7.2. Operációs rendszer

Az operációs rendszert tekintve az összes Hadoop disztribúció UNIX-os környezetbenhasználható, ezekre lett alapvet®en kialakítva. Legtöbbet használt Linux disztribúciókHadoop cluster-ekhez a RedHat, és a CentOS. Céges környezetben leginkább az el®bbiveltalálkozhatunk a legtöbbször, míg �otthoni� felhasználók körében az Ubuntu, és különbö-z® Debian verziók az elterjedtebbek. Mivel nincs nagy különbség Hadoop szempontjábóla különböz® operációs rendszerek között, ezért általános ajánlás, hogy a támogatási id®-intervallum és a rendszergazdák tapasztalata alapján érdemes OS-t választani.Létezik emellett egy Windows Server számítógépekre átalakított verzió is, amelyet újsze-r¶sége és kisebb közösségi támogatása miatt kockázatos lehet használni.

7.2. ábra. Hadoop futtatására alkalmas operációs rendszerek

7.3. Hálózat

A jó és alapos hálózati beállítások rendkívül fontosak, mivel ezek szokták okozni a legtöbbproblémát és furcsa hibajelenséget telepítés és üzemeltetés közben. Emiatt fontos, hogyminden számítógépnek tudnia kell a saját host nevét, IP címét. DNS és reverseDNS-nekhibátlanul kell m¶ködnie privát címek esetén is, mert léteznek olyan feladatok, ahol aNode-tól a rendszer megkérdezi a host nevét, és erre neki válaszolnia kell tudnia, hiszenegyéb esetben mondjuk nem tud az a feladat lefutni, és rengeteg hibát kaphatunk.A cluster általában bels® hálózaton van, és nincs küls® interfésze, tehát csak a bels® hálónérhet® el. Erre a bels® hálóra pl. VPN-el szokás bejelentkezni, és így használható acluster. Ennek az a célja, hogy a küls® támadásokat teljesen ki tudjuk sz¶rni, és csakakkor törhet® fel a rendszer, ha valaki a bels® hálóra be tudott jutni.

1http://hortonworks.com/ ajánlása

33

http://hortonworks.com/

EL�ADÁS 7. HADOOP KLASZTEREK KONFIGURÁCIÓJA ÉS ÜZEMELTETÉSE

7.4. Disztribúció

Mivel a Hadoop-nak sok cég által elkészített változata van, így ezek különböz® egyéb szol-gáltatásokkal vannak kiegészítve, és más-más feladatokra vagy akár platformokra vannakoptimalizálva.A legelterjedtebb a Cloudera (CDH) által készített verzió, amely egy olyan komplex se-gédszolgáltatásokat nyújtó programokkal, illetve webes felülettel rendelkezik, amelyekkelnagyon könny¶ kezelni az egyedi Node-okat, és a különböz® keretszolgáltatásokat, ame-lyek segítik a rendszer összhangban való m¶ködését. Ezen felül vannak az Intel, Amazon,Hortonworks által készített verziók is.Általában minden verzióból létezik �zet®s és ingyenes vagy akár nyílt forráskódú verzió is.A �zet®sök leginkább internetes támogatás meglétében és pár egyéb extra szolgáltatásbantérnek el az ingyenes verzióktól, és általában csak nagyvállalati környezetben használják®ket az áruk miatt.Érdemes megemlíteni még, hogy természetesen a Hadoop minden része letölthet® azApache oldaláról is, de azok egyesével történ® telepítése és kon�gurációja nagyságren-dekkel nagyobb szakértelmet és id®t igényelnek, mint egy disztribúció használata.

7.3. ábra. Hadoop disztribúciók

7.5. Feladatok ütemezése és kvóták használata

MapReduce feladat esetén a FIFO alapelv¶ feladatütemez® volt a legelterjedtebb, deez túl egyszer¶ volt, és egy kis slotigény¶ (slot - szabad kapacitás) feladatnak is várniakellett egy nagy slotigény¶re, ami igen sok várakozást eredményezett a lekérdezést futtatószámára. Ennek a kiküszöbölésére találták ki a Fair scheduler-t, amely lehet®séget ad arra,hogy a kisebb job-okat a nagyok közé be tudjuk szúrni, ezáltal csökken a várakozási id®.Léteznek slot pool-ok, amelyek lehet®vé teszik, hogy a slot-ok egy csoportját például akisebb job-oknak fenntartjuk, így a nagy job-ok a többi slot használatával helyet hagynaka kisebbek számára.Az üzemeltetés egy másik tipikus problémája, ha egy HDFS fájl mérete tévedésb®l hatal-masra n® (például két nagy fájl join-olása miatt), és elfoglalja a helyet minden más adatel®l. Ez ellen kvóták bevezetésével lehet védekezni.

34

8. el®adás

Hadoop 2.0 - YARN, Tez, Spark

8.1. Hadoop 2.0

8.1.1. Kialakulása

A Hadoop 2.0-ban rengeteg új lehet®séget és szolgáltatást vezettek be, amelyek sokkalkönnyebbé teszik az elosztott rendszerek használatát, azok kezelhet®ségét és feladatokfuttatását. A rendszer újragondolásánál az volt az els®dleges cél, hogy ne csak MapRe-duce job-okat lehessen indítani, hanem más típusú szolgáltatások és applikációk is gondnélkül fussanak. Emellett a régi rendszerben nem volt lehet®ség különböz® csoportoknakkülönböz® adathalmazokon dolgozni, elkülönített elemzéseket futtatni. Eddig a HDFS-enerre csak a különböz® jogosultságokkal való tárolás volt a lehetséges mód.

8.1.2. Különbségek

A Hadoop 1.0-ban JobTracker-nél volt minden szerep, ® felügyelte az er®forrásokat, osztot-ta ki a feladatokat a DataNode-ok számára MapReduce job-oknál, valamint monitoroztaa feladatok futását. Felismerték, hogy az er®forrás menedzsmentet és az alkalmazásokkezelését külön kell választani. Emiatt az új YARN architektúra került kialakításra (lásd8.1. ábra), ami gyakorlatilag egy új generációs MapReduce-t jelent. Az er®források ki-osztása és a feladatok ütemezése leválasztódik a JobTracker-r®l, és a JobTracker szerepfeldarabolódik. Így kerültek bevezetésre a ResourceManager az ApplicationMaster szere-pek.A régi TaskTracker-ek helyett NodeManager-ek vannak az egyes node-okon, amelyek fel-adata a programkód futtatása és a MapReduce kommunikációk felügyelete. A ResourceM-anager a job futtatása során kiválasztja, hogy melyik node-on helyezi el a feladat futtatá-sáért felel®s ApplicationMaster szerepet, amelyb®l minden feladathoz külön példány kerüllétrehozásra. Az ApplicationMaster a ResourceManager-t®l kapott információ alapján kel-l® mennyiség¶ ResourceContainer-t fog igényelni, amely egy er®forrás foglalás a Map ésReduce taskok számára. A ResourceContainer-ek kommunikálnak az ApplicationMaster-rel, és jelentik, hogy hol tartanak a feladat futtatásával. Az ApplicationMaster a jobfutása után megsz¶nik.A korábbi gyakorlattal ellentétben az er®forrás foglaláskor a NodeManager-ek - a régiTaskTracker-ek slot és progress információi helyett - szabad memória és CPU állapo-tot küldenek vissza. Az alkalmazás futásáért az ApplicationMaster a felel®s, tehát aResourceManager-nek nem kell a progress-t jelenteni.

35

EL�ADÁS 8. HADOOP 2.0 - YARN, TEZ, SPARK

Mivel a MapReduce job-ok mellett már alkalmazások is lehetnek, így az ApplicationMa-ster visszajelez, hogy melyik módban indult el a beküldött feladat. Például az HBaseszolgáltatás is a ResourceManager-en keresztül tudja elérni a cluster-t, így a különböz®folyamatok nem veszik el egymás el®l az er®forrásokat.

8.1. ábra. Az új YARN rétegforrás: http://hortonworks.com/hadoop/yarn/

8.1.3. YARN job futtatás

Az új YARN rendszerben jelent®sen megváltozott a rendszerben indítható feladatok fut-tatása. A 8.2. ábrán bemutatott módon futtatja a rendszer a beküldött feladatokat:

1. A kliens beküldi a feladatot a rendszernek az alkalmazás speci�kus ApplicationMa-ster indításához szükséges információkkal együtt.

2. A ResourceManager eldönti, hogy melyik node-ra delegálja az ApplicationMasterelindításával és futtatásával járó feladatkört.

3. Az ApplicationManager a létrejötte után bejelentkezik a ResourceManager-nél, akilehet®vé teszi a kliens számára a közvetlen kommunikációt az ApplicationMaster-rel.

4. A futás során az ApplicationMaster a resource-request protokoll segítségével meg-felel® ResourceContainer-eket foglal az alkalmazás futásához.

5. A sikeres er®forrás foglalás után az ApplicationManager a NodeManager számá-ra elküldi a megfelel® információkat és adatokat, így elindul a Container futta-tása. Ezek az információk tartalmazzák azt is, hogy a Container miként tud azApplicationManager-rel kommunikálni.

6. A Container elkezdni futtatni a programkódot, miközben az applikáció speci�kusprotokoll segítségével folyamatosan jelenti a feladat el®rehaladtát, állapotát.

7. Szintén az applikáció speci�kus protokoll segítségével a feladatot beküld® kliens azApplicationMaster-rel kommunikálva kérdezi le a feladat státuszát, illetve az azzalkapcsolatos egyéb információkat.

8. Amikor a feladat elkészült és minden szükséges háttérfolyamat lefutott, az Appli-cationMaster törli magát a ResourceManager-nél, és leáll. Ekkor a Container újrafelhasználható lesz.

36

http://hortonworks.com/hadoop/yarn/


8.2. ábra. YARN job futtatásforrás: http://hortonworks.com/hadoop/yarn/

8.2. Tez

A Tez projekt létrehozásának célja az volt, hogy az új YARN rendszerhez egy forra-dalmasított, gyorsabb, egyszer¶bb MapReduce megoldást nyújtsanak, amely csökkenti arendszer er®forrás használatát.A korábbi MapReduce-ok m¶ködési elve az volt, hogy minden Map és Reduce fázis közötta köztes adatok a HDFS-re íródtak ki (replikációval együtt), így jelent®s I/O kapacitásthasználtak el (különösen több MapReduce job egyszerre történ® futtatásával). Ezt a Tez-ben azzal küszöbölték ki, hogy nem feltétlen kell külön MapReduce job-okat létrehozni azadatok feldolgozása során, hanem lehet ezeket batch-esíteni (Map→ Reduce→ Reduce),így nem kell mindig közöttük HDFS-t használni, tehát spórolhatunk az I/O kapacitással.Ezen kialakítás els®dleges célja volt, hogy a Hive és a Pig-beli feladatokat egyetlen Ma-pReduce job-bal valósítsunk meg. A rendszer a feladatokból itt is egy DAG-ot (körmentesgráf) alakít ki, és készíti el a futtatás sorrendjét. Eltérés, hogy a Tez-ben a MapReduce-alellentétben nem kell ezt megadni, hogy hány Reduce feladatunk lesz, ezt a rendszer futásközben kioptimalizálja.

8.2.1. Eloszott rendezési példa Tez-ben

A 8.4. ábrán látható egy elosztott rendezési példa, amely módszerrel akár 10-szeresengyorsabb adatfeldolgozás érhet® el. A korábbi egy Reduce job-tól eltér®en, itt 3 részb®láll a folyamat.Az el®feldolgozó szakasz mintákat küld a Sampler-nek, amely az adatokat egyenletesenelosztja rendezett tartományokra osztja. Ezek a tartományok a partícionáló és aggregálófázisba kerülnek, ahol a megfelel® feldolgozók a saját tartományukat olvassák be, és el-végzik az adatok összef¶zését. Ez az adatfolyam egyetlen Tez feladat, amely elvégzi az

37

http://hortonworks.com/hadoop/yarn/


8.3. ábra. Tez és a YARN kapcsolataforrás: http://hortonworks.com/hadoop/tez/

egész számítást.

8.4. ábra. Tez elosztott rendezésforrás: http://hortonworks.com/hadoop/tez/

8.3. Impala

Az Impala egy Hive alternatívaként jött létre annak érdekében, hogy egy egyszer¶ lekér-dezésre egy kisebb táblán ne kelljen 5-10 sec-et várni. A megvalósítás tisztán C és C++alapú, és az adatokat is cache-eli, ezért jóval gyorsabb, mint a Hive. A cache-elés lényegeebben az esetben, hogy a már korábban kiszámolt vagy futtatott lekérdezések eredményétmemóriában tárolja, így azokat nem kell minden esetben újra a HDFS-r®l olvasni, hagyakran használjuk.

38

http://hortonworks.com/hadoop/tez/

http://hortonworks.com/hadoop/tez/


8.4. Spark

A Spark valójában egy memória alapú MapReduce keretrendszer, amelyet szintén aYARN-hoz fejlesztettek ki. Ez leginkább iteratív számításokhoz ideális (pl. logisztikusregresszió, neurális hálók). Bizonyos adatokról kódszinten meg lehet mondani, hogy le-gyen cache-elve, tehát akár az adathalmaz tárolható memóriában a futás idején, és csaka végeredményt írjuk HDFS-re.A Shark a Spark rendszerhez nagyon hasonlóan egy memória alapú megoldás, amelyet aHive futtatásához terveztek.

8.5. Storm

A Storm egy valósidej¶, nem batchelt feldolgozó rendszer, amelyben topológiába rend-szerezhetünk forrásokat és feldolgozó egységeket, amely folyam végén kerül csak az adatelmentésre a háttértárra vagy adatbázisba (lásd 8.5. ábra). Ez a leggyakrabban olyanfelhasználási módoknál jelent hatalmas el®nyt, ahol azonnali jelentéseket vagy valós idej¶analízist kell készíteni. A feldolgozó egységek lényege, hogy azonnali számolást végeznek,adattárolást egyáltalán nem. Felhasználási példák közé tartozik gyakori szavak, kulcs-szavak keresése sok bejöv® rövid üzenetben, amelyet azonnal kivezethetünk egy valósmegjelenít® felületre.Ezek mellett természetesen a tárolt adatokon kés®bb Tez-t vagy MapReduce-t is futtat-hatunk a korábbi gyakorlatnak megfelel®en.

8.5. ábra. Storm topológiaforrás: https://storm.incubator.apache.org/

39

https://storm.incubator.apache.org/

9. el®adás

Hadoop & NoSQL: HBase

9.1. Adatbázis-kezel® rendszerek

Az adatbázis-kezel® rendszereknek két nagy csoportját különböztetjük meg, amelyek össze-hasonlítása a 9.1. táblázatban látható.

OLTP(On-line Transaction Processing)

OLTP(On-line Analytical Processing)

Célja tranzakciókezelés adatelemzésFormája adatbázis adattárházM¶veletek gyors, kis m¶veletek: SELECT,

UPDATE, DELETE, INSERT

komplex SELECT típusú lekérdezé-sek

Tervezés normalizált forma (1NF, 2NF,3NF, BCNF)

nem normalizált, csillag séma:egy f® tábla és több hozzá f¶z®-d® kapcsolótábla

Technológiák standard SQL adatbázisok HBase, Accumulo, Cassandra

9.1. táblázat. OLTP vs. OLAP

Általában megpróbáljuk a kétféle adatbázis-kezel® rendszert elszeparálni akkor is, haugyanazzal az eszközökkel valósítottuk meg ®ket. Ennek legf®bb szerepe az er®forrásokkiosztásánál van, hiszen egy komolyabb elemzési m¶velettel nem szeretnénk a tranzakciósadatbázist lebénítani.

9.1.1. Elosztott adatbázis-kezel® rendszerek

Az adatbázis kezel® rendszerek egygépes környezetben viszonylag egyszer¶en elkészít-het®ek, de elosztott esetben számos problémába ütközhetünk, amelyhez kapcsolódik akövetkez® tétel:

CAP-tétel: egy-egy konkrét elosztott rendszer az alábbi három alapvet® képesség közüllegfeljebb kett®t tud megvalósítani:

� Consistency (konzisztencia): mindig ugyanazt olvassuk ki, mint amit beírtunk

� Availibility (rendelkezésre állás): mindig kapunk választ a kérdésre

� Parition tolerance (particionálás-t¶rés): mennyire viseli el a rendszer, ha valamilyenokból kifolyólag szétesik több különálló részre

40

EL�ADÁS 9. HADOOP & NOSQL: HBASE

A 9.1. ábrán látható a különböz® adatbázis-kezel® rendszereknek az összefoglalása aCAP-tétel alapján, hogy melyik két képességgel rendelkezik.

9.1. ábra. CAP-tételforrás: http://robertgreiner.com/2014/06/cap-theorem-explained/

9.2. NoSQL adatbázis-kezel® rendszerek

A NoSQL adatbázisok nem relációs adatmodellt használnak, hanem különféle megoldásokléteznek:

� dokumentum alapú: MongoDBEzek az adatbázis-kezel® rendszerek legf®képp az aggregátum számolásra, GROUPBY-jelleg¶ m¶veletekre vannak specializálva. Más m¶veletet vagy nem is tudnak,vagy nem hatékonyan tudnak elvégezni.

� gráf alapú: Neo4j

� oszlop alapú: HBase, Cassandra

� kulcs-érték alapú: DynamoDB, Riak

41

http://robertgreiner.com/2014/06/cap-theorem-explained/


9.3. HBase

A Google 2006-ban publikálta a BigTable nev¶ oszlop alapú adatbázis-kezel® rendsze-rét. Célja, hogy a Google által használt HDFS-hez hasonló fájlrendszeren skálázhatóantudjanak adatokat tárolni. Ennek mintájára készült az HBase, amelynek de�níciója akövetkez®:

� sparse: ritka, ugyanis az oszlopok értékét nem kötelez® mindig megadni és nem tárolkülönféle NULL értékeket, mint az SQL alapú adatbázisok

� consistant : konzisztens

� distributed : elosztott, mivel az adatok HDFS-en elhelyezett fájlokban találhatóak

� multidimensional : többdimenziós, azaz egy kulcshoz több oszlop (column) is tartoz-hat és ezek oszlopcsaládokba (columnfamily) vannak rendezve, tehát (columnfamily:column) alapján lehet értéket lekérni. Ezenfelül tárol még timestampet is, vagyisaz értékek verziózva vannak és mindig a legfrissebb kerül visszaadásra. (A konzisz-tenciának feltétele, hogy mindig legyen timestamp a beszúrt értékek mellett.)

� sorted : rendezett, tehát nem csak kulcs alapján kereshet®, hanem tartományt isegyszer¶en le lehet kérni

� map: kulcs-érték párok tárolása

A következ® m¶veleteket lehet elvégezni az HBase-ben:

� put(kulcs: {'cf:c': érték, 'cf:c': érték, ...}): egy elem beszúrása

� get(kulcs): egy kulcshoz tartozó értékek lekérése

� scan(kezd®érték, végérték): egy tartomány lekérése, illetve használható pre�xkeresésre

� delete(kulcs): egy elem törlése

A használatához vegyünk egy webkereséses példát, aminek a célja, hogy a különféle URL-ekhez adatokat mentsünk le. HBase-ben a kulcsot rowkey-nek szokták nevezni, amely jelenesetben az URL lesz. Mivel nagyon sok URL-hez kell adatot tárolni, ezért mindenképpenszükség van valamilyen elosztott infrastruktúrára. Az értékek pedig a MIME-type, nyelv,tartalmazott szöveg, stb. lesz, amely a oszlopok szabad felhasználhatóságából adódóanbármikor b®víthet® és szabadon kihagyható.Mivel az HBase-nek nagyon kicsi a késleltetése, ezért a különféle modulok (crawlerek)nagyon gyorsan tudnak lekérdezni. Minden változtatás atomi, tehát nem fogják blokkolniegymást és nem okoz problémát az sem, ha két különböz® modul ugyanazt a rowkey-takarja felülírni. Így kaptunk egy nagyon jól skálázódó, kis késleltetés¶ adatbázist, amelyet(cserébe) csak URL alapján tudunk elérni, de ehhez a felhasználáshoz ez pont elég.Egy columnfamily kerül egy HDFS fájlba, tehát ha egy rowkey-hez több columnfamilytartozik, akkor több fájlból kell az értékeket kiolvasni. Oszlop alapú adattömörítést hasz-nál az HBase, de használható a rendszer key-value adatbázis felfogásban, amelyb®l látszik,hogy nincs éles határ a két típusú adatbázis-kezel® rendszer között.

42


9.3.1. M¶ködése

HDFS fölött fut, de nem MapReduce alapokon, hiszen tudjuk, hogy a MapReduce-nakmásodperces nagyságrend¶ késleltetése van, míg a NoSQL rendszerek ms-os válaszid®veldolgoznak. Felépítésében hasonlít a HDFS és a MapReduce struktúrára, hiszen Master-Slave architektúrára épül ahogyan azt a 9.2. ábrán látható.

9.2. ábra. HBase felépítéseforrás: http://blog.xebia.fr/2009/11/18/devoxx-jour-1-nosql-avec-hbase/

Van egy HBase master és vannak különböz® régiószerverek. Ezek külön szolgáltatáskéntfutnak a Hadoop clusteren, tehát teljesen függetlenek a MapReduce keretrendszert®l. Mi-vel az adathalmazunk rendezett, ezért a régiószerverek a kulcs szerint vannak felosztva,tehát minden régiószervernek van egy kulcstartománya (start_key � stop_key), amit azkezel. Ha a kliens le akar kérni egy értéket kulcs szerint, akkor el®ször a master meg-mondja, hogy melyik régiószerverhez tartozik és utána attól a régiószervert®l fogja elkérniaz adott elemet és beírás is hasonlóan m¶ködik. Ahhoz, hogy a rendszer valóban ms-osnagyságrendben futhasson, a kliensek cash-elik, hogy a régiók hogyan oszlanak el. Ha eza felosztás valami miatt megváltozik, akkor az adott régiószerver válaszol, hogy ez a kulcsnem hozzá tartozik és akkor fordul újra a masterhez a kliens. A master elég kicsi szerepetkap a rendszerben, mivel csak a kezdeti kéréseket kell kiszolgálnia, illetve az újraszervezésifeladatokat kell neki elvégeznie. A nagy terhelés a régiószerverekre jut.A felépítésb®l már jól látszik, hogy a rendszer miért nem áll mindig rendelkezésre. Haegy régiószerver kiesik, akkor az ® tartománya aktuálisan kiszolgálatlan lesz addig, amíga master ezt észre nem veszi (nem érkezik heartbeat). Ezután kiosztja más régiószer-vereknek ezt a tartományt, aki meg fogja találni a HDFS-en az ehhez a régiószerverheztartozó fájlokat, de így vannak olyan átmeneti id®szakok, amely alatt bizonyos rekordoknem elérhet®ek. A particionálás-t¶rés viszont teljesülni fog, hiszen ha a cluster szétesiktöbb részre akkor is adott régiószerverek a hozzájuk tartozó kéréseket teljesíteni tudják.Így a rendszer továbbra is m¶ködni fog, természetesen a HDFS replikációt nem biztos,hogy végre tudja hajtani amíg a teljes cluster újra össze nem kapcsolódik.Ahhoz hogy a kérések minnél el®bb ki legyenek szolgálva a régiószerverek folyamatosannyitva tartják a HDFS fájlokat, amik hozzájuk tartoznak és általában replikákat is igyek-szik a rendszer úgy elhelyezni, hogy legyen a régiószerven egy lokális replika a hozzátartozó blokkokból. A régiószerver ezekbe a fájlokba nagyon gyorsan bele tud indexelniés visszaadni a megfelel® értéket. Ezen felül az adatok nagy részét memóriában tartják,tehát ezért fontos a sok memória az HBase-t kiszolgáló �zikai gépekbe. (Vessük össze

43

http://blog.xebia.fr/2009/11/18/devoxx-jour-1-nosql-avec-hbase/


a 7.1. ábrán található Slave-hez tartozó Balanced workload és HBase cluster értékeket.)

Az adatok beírásának folyamata

Az HBase írási folyamata a 9.3. ábrán látható szekvenciadiagram szerint történik.

9.3. ábra. HBase változtatás írási folyamataforrás: http://blog.cloudera.com/blog/2012/06/hbase-write-path/

Inicializáláskor a kliens megkérdezi a master-t, hogy melyik régiószerverhez kell fordulnia,ha ez még ezel®tt nem történt meg. Egy kulcsot és a hozzá tartozó értéke(ke)t szeretnéa kliens beszúrni vagy törölni (Ê). A régiószerver el®ször a változást beírja a commitlog-ba (Ë), ami a lokális diszken tárolódik, hogy adatvesztésünk ne legyen. Ezután kerülbe a memstore-ba, ahol a régiószerver tárolja a változásokat és követi azok verzióit (Ì).Amikor ez a memstore kezd betelni, akkor a commit log-nak egy rendezett formájátHDFS-re írja (Î). A commit log és a memstore írása nagyon gyors és utána visszatér aparancs (Í), míg a HDFS-re írás már aszinkron módon hajtódik végre. Így esetleges hibaesetén, ha visszatér a régiószerver, akkor a commit log-ból újra fel tudja építeni a hiányzómódosításokat. Ebb®l következik, ha régiószerver többet nem tér vissza, akkor azok aváltozások elvesznek, amik HDFS-re nem kerültek át.

9.3.2. HBase adatszervezési példa

A legf®bb kérdés: Hogyan válasszuk meg a kulcsokat? Ehhez el®ször is meg kell vizsgál-nunk, hogy milyen lekérdezéseket szeretnénk futtatni. Egy példán keresztül vizsgáljukmeg, hogy milyen szempontokra érdemes oda�gyelni.Tegyük fel, hogy id®járási adatokat gy¶jtünk. Vannak id®járás állomások, amelyekheztimestamp-et és mérési adatokat szeretnénk letárolni. A lekérdezéseinket arra szeretnénkoptimalizálni, hogy a leggyorsabban kapjuk vissza az adott id®járás állomáshoz tarto-zó legfrissebb mért adatokat. Ebben az esetben triviálisnak t¶nik, hogy válasszuk azállomás+timestamp-et kulcsnak. De ez ebben az esetben nem a legoptimálisabb megol-dást adja, ugyanis a keresésnél mindig végig kell nézni az összes adott állomáshoz tartozóadatot amíg elérjük az utolsót.Erre azt a megoldást szokták alkalmazni, hogy egy távoli jöv®beli id®pontból kivonjákaz aktuális timestamp-et, ezzel megfordítva annak növekv® voltát. Ha így futtatjuk le akeresést, akkor els® elemként az állomáshoz tartozó legfrissebb adatokat kapjuk meg.

44

http://blog.cloudera.com/blog/2012/06/hbase-write-path/

A. függelék

MapReduce Patterns, Algorithms, and

Use Cases

Source: http://highlyscalable.wordpress.com/2012/02/01/mapreduce-patterns/

In this article I digested a number of MapReduce patterns and algorithms to give a syste-matic view of the di�erent techniques that can be found on the web or scienti�c articles.Several practical case studies are also provided. All descriptions and code snippets use thestandard Hadoop's MapReduce model with Mappers, Reduces, Combiners, Partitioners,and sorting. This framework is depicted in the �gure below.

A.1. ábra. MapReduce Framework

45

http://highlyscalable.wordpress.com/2012/02/01/mapreduce-patterns/

FÜGGELÉK A. MAPREDUCE PATTERNS, ALGORITHMS, AND USE CASES

A.1. Basic MapReduce Patterns

A.1.1. Counting and Summing

Problem Statement: There is a number of documents where each document is a setof terms. It is required to calculate a total number of occurrences of each term in alldocuments. Alternatively, it can be an arbitrary function of the terms. For instance, thereis a log �le where each record contains a response time and it is required to calculate anaverage response time.Solution: Let start with something really simple. The code snippet below shows Mapperthat simply emit �1� for each term it processes and Reducer that goes through the listsof ones and sum them up:

1 class Mapper

2 method Map(docid id, doc d)

3 for all term t in doc d do

4 Emit(term t, count 1)

5

6 class Reducer

7 method Reduce(term t, counts [c1, c2 ,...])

8 sum = 0

9 for all count c in [c1, c2 ,...] do

10 sum = sum + c

11 Emit(term t, count sum)

The obvious disadvantage of this approach is a high amount of dummy counters emittedby the Mapper. The Mapper can decrease a number of counters via summing countersfor each document:

1 class Mapper


3 H = new AssociativeArray


5 H{t} = H{t} + 1

6 for all term t in H do

7 Emit(term t, count H{t})

In order to accumulate counters not only for one document, but for all documents pro-cessed by one Mapper node, it is possible to leverage Combiners:

1 class Mapper



4 Emit(term t, count 1)

5

6 class Combiner

7 method Combine(term t, [c1, c2 ,...])

8 sum = 0


46


10 sum = sum + c


12

13 class Reducer

14 method Reduce(term t, counts [c1, c2 ,...])

15 sum = 0


17 sum = sum + c


Applications: Log Analysis, Data Querying

A.1.2. Collating

Problem Statement: There is a set of items and some function of one item. It isrequired to save all items that have the same value of function into one �le or performsome other computation that requires all such items to be processed as a group. Themost typical example is building of inverted indexes.Solution: The solution is straightforward. Mapper computes a given function for eachitem and emits value of the function as a key and item itself as a value. Reducer obtainsall items grouped by function value and process or save them. In case of inverted indexes,items are terms (words) and function is a document ID where the term was found.Applications: Inverted Indexes, ETL

A.1.3. Filtering (�Grepping�), Parsing, and Validation

Problem Statement: There is a set of records and it is required to collect all recordsthat meet some condition or transform each record (independently from other records)into another representation. The later case includes such tasks as text parsing and valueextraction, conversion from one format to another.Solution: Solution is absolutely straightforward � Mapper takes records one by one andemits accepted items or their transformed versions.Applications: Log Analysis, Data Querying, ETL, Data Validation

A.1.4. Distributed Task Execution

Problem Statement: There is a large computational problem that can be divided intomultiple parts and results from all parts can be combined together to obtain a �nal result.Solution: Problem description is split in a set of speci�cations and speci�cations arestored as input data for Mappers. Each Mapper takes a speci�cation, performs corres-ponding computations and emits results. Reducer combines all emitted parts into the�nal result.

Case Study: Simulation of a Digital Communication System

There is a software simulator of a digital communication system like WiMAX that passessome volume of random data through the system model and computes error probabilityof throughput. Each Mapper runs simulation for speci�ed amount of data which is 1/Nthof the required sampling and emit error rate. Reducer computes average error rate.

47


Applications: Physical and Engineering Simulations, Numerical Analysis, PerformanceTesting

A.1.5. Sorting

Problem Statement: There is a set of records and it is required to sort these recordsby some rule or process these records in a certain order.Solution: Simple sorting is absolutely straightforward � Mappers just emit all items asvalues associated with the sorting keys that are assembled as function of items. Nevert-heless, in practice sorting is often used in a quite tricky way, that's why it is said to bea heart of MapReduce (and Hadoop). In particular, it is very common to use compositekeys to achieve secondary sorting and grouping. Sorting in MapReduce is originally in-tended for sorting of the emitted key-value pairs by key, but there exist techniques thatleverage Hadoop implementation speci�cs to achieve sorting by values. See this blog formore details. It is worth noting that if MapReduce is used for sorting of the original (notintermediate) data, it is often a good idea to continuously maintain data in sorted stateusing BigTable concepts. In other words, it can be more e�cient to sort data once duringinsertion than sort them for each MapReduce query.Applications: ETL, Data Analysis

A.2. Not-So-Basic MapReduce Patterns

A.2.1. Iterative Message Passing (Graph Processing)

Problem Statement: There is a network of entities and relationships between them. Itis required to calculate a state of each entity on the basis of properties of the other entitiesin its neighborhood. This state can represent a distance to other nodes, indication thatthere is a neighbor with the certain properties, characteristic of neighborhood density andso on.Solution: A network is stored as a set of nodes and each node contains a list of adjacentnode IDs. Conceptually, MapReduce jobs are performed in iterative way and at eachiteration each node sends messages to its neighbors. Each neighbor updates its state onthe basis of the received messages. Iterations are terminated by some condition like �xedmaximal number of iterations (say, network diameter) or negligible changes in statesbetween two consecutive iterations. From the technical point of view, Mapper emitsmessages for each node using ID of the adjacent node as a key. As result, all messages aregrouped by the incoming node and reducer is able to recompute state and rewrite nodewith the new state. This algorithm is shown in the �gure below:

1 class Mapper

2 method Map(id n, object N)

3 Emit(id n, object N)

4 for all id m in N.OutgoingRelations do

5 Emit(id m, message getMessage(N))

6

7 class Reducer

8 method Reduce(id m, [s1, s2 ,...])

9 M = null

48


10 messages = []

11 for all s in [s1, s2 ,...] do

12 if IsObject(s) then

13 M = s

14 else // s is a message

15 messages.add(s)

16 M.State = calculateState(messages)

17 Emit(id m, item M)

It should be emphasized that state of one node rapidly propagates across all the networkof network is not too sparse because all nodes that were �infected� by this state start to�infect� all their neighbors. This process is illustrated in the �gure below:

Case Study: Availability Propagation Through The Tree of Categories

Problem Statement: This problem is inspired by real life eCommerce task. There isa tree of categories that branches out from large categories (like Men, Women, Kids)to smaller ones (like Men Jeans or Women Dresses), and eventually to small end-of-line categories (like Men Blue Jeans). End-of-line category is either available (containsproducts) or not. Some high level category is available if there is at least one availableend-of-line category in its subtree. The goal is to calculate availabilities for all categoriesif availabilities of end-of-line categories are know.Solution: This problem can be solved using the framework that was described in theprevious section. We de�ne getMessage and calculateState methods as follows:

1 class N

2 State in {True = 2, False = 1, null = 0},

49


3 initialized 1 or 2 for end -of-line categories , 0 otherwise

4

5 method getMessage(object N)

6 return N.State

7

8 method calculateState(state s, data [d1, d2 ,...])

9 return max( [d1, d2 ,...] )

Case Study: Breadth-First Search

Problem Statement: There is a graph and it is required to calculate distance (a numberof hops) from one source node to all other nodes in the graph.Solution: Source node emits 0 to all its neighbors and these neighbors propagate thiscounter incrementing it by 1 during each hope:

1 class N

2 State is distance ,

3 initialized 0 for source node , INFINITY for all other nodes

4

5 method getMessage(N)

6 return N.State + 1

7


9 min( [d1, d2 ,...] )

Case Study: PageRank and Mapper-Side Data Aggregation

This algorithm was suggested by Google to calculate relevance of a web page as a functionof authoritativeness (PageRank) of pages that have links to this page. The real algorithmis quite complex, but in its core it is just a propagation of weights between nodes whereeach node calculates its weight as a mean of the incoming weights:

1 class N

2 State is PageRank

3

4 method getMessage(object N)

5 return N.State / N.OutgoingRelations.size()

6


8 return ( sum([d1, d2 ,...]) )

It is worth mentioning that the schema we use is too generic and doesn't take advantageof the fact that state is a numerical value. In most of practical cases, we can performaggregation of values on the Mapper side due to virtue of this fact. This optimization isillustrated in the code snippet below (for the PageRank algorithm):

1 class Mapper

50


2 method Initialize

3 H = new AssociativeArray

4 method Map(id n, object N)

5 p = N.PageRank / N.OutgoingRelations.size()

6 Emit(id n, object N)

7 for all id m in N.OutgoingRelations do

8 H{m} = H{m} + p

9 method Close

10 for all id n in H do

11 Emit(id n, value H{n})

12

13 class Reducer

14 method Reduce(id m, [s1, s2 ,...])

15 M = null

16 p = 0

17 for all s in [s1, s2 ,...] do

18 if IsObject(s) then

19 M = s

20 else

21 p = p + s

22 M.PageRank = p

23 Emit(id m, item M)

Applications: Graph Analysis, Web Indexing

A.2.2. Distinct Values (Unique Items Counting)

Problem Statement: There is a set of records that contain �elds F and G. Count thetotal number of unique values of �led F for each subset of records that have the same G(grouped by G).The problem can be a little bit generalized and formulated in terms of faceted search:Problem Statement: There is a set of records. Each record has �eld F and arbitrarynumber of category labels G = {G1, G2, . . . }. Count the total number of unique values of�led F for each subset of records for each value of any label. Example:

1 Record 1: F=1, G={a, b}

2 Record 2: F=2, G={a, d, e}

3 Record 3: F=1, G={b}

4 Record 4: F=3, G={a, b}

5

6 Result:

7 a -> 3 // F=1, F=2, F=3

8 b -> 2 // F=1, F=3

9 d -> 1 // F=2

10 e -> 1 // F=2

51


Solution I:

The �rst approach is to solve the problem in two stages. At the �rst stage Mapperemits dummy counters for each pair of F and G; Reducer calculates a total number ofoccurrences for each such pair. The main goal of this phase is to guarantee uniqueness ofF values. At the second phase pairs are grouped by G and the total number of items ineach group is calculated.Phase I:

1 class Mapper

2 method Map(null , record [value f, categories [g1, g2 ,...]])

3 for all category g in [g1, g2 ,...]

4 Emit(record [g, f], count 1)

5

6 class Reducer

7 method Reduce(record [g, f], counts [n1, n2, ...])

8 Emit(record [g, f], null )

Phase II:

1 class Mapper

2 method Map(record [f, g], null)

3 Emit(value g, count 1)

4

5 class Reducer

6 method Reduce(value g, counts [n1, n2 ,...])

7 Emit(value g, sum( [n1, n2 ,...] ) )

A.2.3. Solution II:

The second solution requires only one MapReduce job, but it is not really scalable andits applicability is limited. The algorithm is simple � Mapper emits values and categori-es, Reducer excludes duplicates from the list of categories for each value and incrementcounters for each category. The �nal step is to sum all counter emitted by Reducer. Thisapproach is applicable if th number of record with the same f value is not very high andtotal number of categories is also limited. For instance, this approach is applicable forprocessing of web logs and classi�cation of users � total number of users is high, butnumber of events for one user is limited, as well as a number of categories to classify by.It worth noting that Combiners can be used in this schema to exclude duplicates fromcategory lists before data will be transmitted to Reducer.

1 class Mapper

2 method Map(null , record [value f, categories [g1, g2 ,...] )


4 Emit(value f, category g)

5

6 class Reducer

7 method Initialize

52


8 H = new AssociativeArray : category -> count

9 method Reduce(value f, categories [g1, g2 ,...])

10 [g1, g2 ,..] = ExcludeDuplicates( [g1, g2 ,..] )


12 H{g} = H{g} + 1

13 method Close

14 for all category g in H do

15 Emit(category g, count H{g})

Applications: Log Analysis, Unique Users Counting

A.2.4. Cross-Correlation

Problem Statement: There is a set of tuples of items. For each possible pair of itemscalculate a number of tuples where these items co-occur. If the total number of items isN then N*N values should be reported. This problem appears in text analysis (say, itemsare words and tuples are sentences), market analysis (customers who buy this tend toalso buy that). If N*N is quite small and such a matrix can �t in the memory of a singlemachine, then implementation is straightforward.Pairs Approach: The �rst approach is to emit all pairs and dummy counters fromMappers and sum these counters on Reducer. The shortcomings are:

� The bene�t from combiners is limited, as it is likely that all pair are distinct

� There is no in-memory accumulations

1 class Mapper

2 method Map(null , items [i1, i2 ,...] )

3 for all item i in [i1, i2 ,...]

4 for all item j in [i1, i2 ,...]

5 Emit(pair [i j], count 1)

6

7 class Reducer

8 method Reduce(pair [i j], counts [c1, c2 ,...])

9 s = sum([c1, c2 ,...])

10 Emit(pair[i j], count s)

Stripes Approach: The second approach is to group data by the �rst item in pairand maintain an associative array (�stripe�) where counters for all adjacent items areaccumulated. Reducer receives all stripes for leading item i, merges them, and emits thesame result as in the Pairs approach.

� Generates fewer intermediate keys. Hence the framework has less sorting to do.

� Greately bene�ts from combiners.

� Performs in-memory accumulation. This can lead to problems, if not properly imp-lemented.

� More complex implementation.

53


� In general, �stripes� is faster than �pairs�

1 class Mapper

2 method Map(null , items [i1, i2 ,...] )

3 for all item i in [i1, i2 ,...]

4 H = new AssociativeArray : item -> counter

5 for all item j in [i1, i2 ,...]

6 H{j} = H{j} + 1

7 Emit(item i, stripe H)

8

9 class Reducer

10 method Reduce(item i, stripes [H1, H2 ,...])

11 H = new AssociativeArray : item -> counter

12 H = merge -sum( [H1, H2 ,...] )

13 for all item j in H.keys()

14 Emit(pair [i j], H{j})

Applications: Text Analysis, Market AnalysisReferences: Lin J. Dyer C. Hirst G. Data Intensive Processing MapReduce

A.3. Relational MapReduce Patterns

In this section we go though the main relational operators and discuss how these operatorscan implemented in MapReduce terms.

A.3.1. Selection

1 class Mapper

2 method Map(rowkey key , tuple t)

3 if t satisfies the predicate

4 Emit(tuple t, null)

A.3.2. Projection

Projection is just a little bit more complex than selection, but we should use a Reducerin this case to eliminate possible duplicates.

1 class Mapper


3 tuple g = project(t) // extract required fields to tuple g

4 Emit(tuple g, null)

5

6 class Reducer

7 method Reduce(tuple t, array n) // n is an array of nulls


54


A.3.3. Union

Mappers are fed by all records of two sets to be united. Reducer is used to eliminateduplicates.

1 class Mapper



4

5 class Reducer

6 // n is an array of one or two nulls

7 method Reduce(tuple t, array n)


A.3.4. Intersection

Mappers are fed by all records of two sets to be intersected. Reducer emits only recordsthat occurred twice. It is possible only if both sets contain this record because recordincludes primary key and can occur in one set only once.

1 class Mapper



4

5 class Reducer

6 // n is an array of one or two nulls


8 if n.size() = 2


A.3.5. Di�erence

Let's we have two sets of records � R and S. We want to compute di�erence R � S. Mapperemits all tuples and tag which is a name of the set this record came from. Reducer emitsonly records that came from R but not from S.

1 class Mapper


3 // t.SetName is either 'R' or 'S'

4 Emit(tuple t, string t.SetName)

5

6 class Reducer

7 // array n can be ['R'], ['S'], ['R' 'S'], or ['S', 'R']


9 if n.size() = 1 and n[1] = 'R'


55


A.3.6. GroupBy and Aggregation

Grouping and aggregation can be performed in one MapReduce job as follows. Mapperextract from each tuple values to group by and aggregate and emits them. Reducerreceives values to be aggregated already grouped and calculates an aggregation function.Typical aggregation functions like sum or max can be calculated in a streaming fashion,hence don't require to handle all values simultaneously. Nevertheless, in some cases twophase MapReduce job may be required � see pattern Distinct Values as an example.

1 class Mapper

2 method Map(null , tuple [value GroupBy , value AggregateBy ,

3 value ...])

4 Emit(value GroupBy , value AggregateBy)

5 class Reducer

6 method Reduce(value GroupBy , [v1, v2 ,...])

7 // aggregate () : sum(), max() ,...

8 Emit(value GroupBy , aggregate( [v1, v2 ,...] ) )

A.3.7. Joining

Joins are perfectly possible in MapReduce framework, but there exist a number of tech-niques that di�er in e�ciency and data volumes they are oriented for. In this section westudy some basic approaches. The references section contains links to detailed studies ofjoin techniques.

Repartition Join (Reduce Join, Sort-Merge Join)

This algorithm joins of two sets R and L on some key k. Mapper goes through all tuplesfrom R and L, extracts key k from the tuples, marks tuple with a tag that indicates aset this tuple came from (`R' or `L'), and emits tagged tuple using k as a key. Reducerreceives all tuples for a particular key k and put them into two buckets � for R and for L.When two buckets are �lled, Reducer runs nested loop over them and emits a cross joinof the buckets. Each emitted tuple is a concatenation R-tuple, L-tuple, and key k. Thisapproach has the following disadvantages:

� Mapper emits absolutely all data, even for keys that occur only in one set and haveno pair in the other.

� Reducer should hold all data for one key in the memory. If data doesn't �t thememory, its Reducer's responsibility to handle this by some kind of swap.

Nevertheless, Repartition Join is a most generic technique that can be successfully usedwhen other optimized techniques are not applicable.

1 class Mapper

2 method Map(null , tuple [join_key k, value v1, value v2 ,...])

3 Emit(join_key k, tagged_tuple [set_name tag ,

4 values [v1, v2, ...] ] )

5

56


6 class Reducer

7 method Reduce(join_key k, tagged_tuples [t1, t2 ,...])

8 H = new AssociativeArray : set_name -> values

9 // separate values into 2 arrays

10 for all tagged_tuple t in [t1, t2 ,...]

11 H{t.tag}.add(t.values)

12 // produce a cross -join of the two arrays

13 for all values r in H{'R'}

14 for all values l in H{'L'}

15 Emit(null , [k r l] )

Replicated Join (Map Join, Hash Join)

In practice, it is typical to join a small set with a large one (say, a list of users with a listof log records). Let's assume that we join two sets � R and L, R is relative small. If so,R can be distributed to all Mappers and each Mapper can load it and index by the joinkey. The most common and e�cient indexing technique here is a hash table. After this,Mapper goes through tuples of the set L and joins them with the corresponding tuplesfrom R that are stored in the hash table. This approach is very e�ective because thereis no need in sorting or transmission of the set L over the network, but set R should bequite small to be distributed to the all Mappers.

1 class Mapper

2 method Initialize

3 H = new AssociativeArray : join_key -> tuple from R

4 R = loadR()

5 for all [ join_key k, tuple [r1, r2 ,...] ] in R

6 H{k} = H{k}. append( [r1, r2 ,...] )

7

8 method Map(join_key k, tuple l)

9 for all tuple r in H{k}

10 Emit(null , tuple [k r l] )

References: Join Algorithms using Map/Reduce, Optimizing Joins in a MapReduceEnvironment

57

cseh gábor kócsó balázs váradi szabolcs -...

Documents