BigData_-_Eloadasjegyzet

Budapesti Mszaki s Gazdasgtudomnyi Egyetem

Big Data elemzsi eszkzk nylt

forrskd platformokon eladsjegyzet

Ksztette:

Cseh Gbor

Kcs Balzs

Vradi Szabolcs

Elad: Prekopcsk Zoltn

Lektorlta: Holczer Tams, Prekopcsk Zoltn

BMEVITMAV15

Budapest, 2014

L

A

T

E

X

Tartalomjegyzk

1. Bevezets 4

2. Elosztott rendszerek, Hadoop, HDFS 6

2.1. Elosztott rendszerek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1. Elosztott fjlrendszerek . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2. Hadoop trtnete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3. Hadoop HDFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4. Hadoop szerver szerepek . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4.1. Name Node (NN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4.2. Secondary Name Node (SNN) . . . . . . . . . . . . . . . . . . . . . 10

2.4.3. Data Node (DN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5. Adatmveletek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5.1. Olvass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5.2. rs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3. MapReduce 12

3.1. Az ltalnos MapReduce modell . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.1. 1. Feladat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.2. 2. Feladat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.3. Hadoop MapReduce felptse . . . . . . . . . . . . . . . . . . . . . 14

3.1.4. Hadoop Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.5. Meghibsodsok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4. MapReduce programozsi mintk, Streaming 17

4.1. 1. feladat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2. 2. feladat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.3. 3. feladat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.4. 4. feladat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.5. Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.6. Adattmrts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5. Hadoop csomagok, SQL for Hadoop: Hive 22

5.1. Hadoop csomagok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.1.1. Flume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.1.2. Sqoop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.1.3. Hive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.1.4. Pig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.5. HBase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.6. Mahout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1

TARTALOMJEGYZK

5.1.7. Zookeeper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.2. SQL for Hadoop: Hive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.2.1. A Hive felptse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6. Pig programozs 26

6.1. Bevezets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.2. A fjlok feltltse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.3. A script megrsa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.3.1. Relci denilsa . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.3.2. Relci denilsa smval . . . . . . . . . . . . . . . . . . . . . . . 28

6.3.3. Relci ltrehozsa egy msik relcibl . . . . . . . . . . . . . . . 28

6.3.4. Adatok kirsa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.3.5. Oszlop kivlasztsa a relcibl . . . . . . . . . . . . . . . . . . . . 29

6.3.6. Adatok rsa a HDFS-re . . . . . . . . . . . . . . . . . . . . . . . . 29

6.3.7. Kt relci illesztse (Join mvelet) . . . . . . . . . . . . . . . . . . 29

6.3.8. Adatok rendezse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.3.9. Adatok szrse s csoportostsa . . . . . . . . . . . . . . . . . . . . 30

6.4. Tovbbi forrsok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

7. Hadoop klaszterek kongurcija s zemeltetse 32

7.1. Hardver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

7.2. Opercis rendszer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

7.3. Hlzat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

7.4. Disztribci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

7.5. Feladatok temezse s kvtk hasznlata . . . . . . . . . . . . . . . . . . 34

8. Hadoop 2.0 - YARN, Tez, Spark 35

8.1. Hadoop 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

8.1.1. Kialakulsa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

8.1.2. Klnbsgek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

8.1.3. YARN job futtats . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

8.2. Tez . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

8.2.1. Eloszott rendezsi plda Tez-ben . . . . . . . . . . . . . . . . . . . 37

8.3. Impala . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

8.4. Spark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

8.5. Storm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

9. Hadoop & NoSQL: HBase 40

9.1. Adatbzis-kezel rendszerek . . . . . . . . . . . . . . . . . . . . . . . . . . 40

9.1.1. Elosztott adatbzis-kezel rendszerek . . . . . . . . . . . . . . . . . 40

9.2. NoSQL adatbzis-kezel rendszerek . . . . . . . . . . . . . . . . . . . . . . 41

9.3. HBase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

9.3.1. Mkdse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

9.3.2. HBase adatszervezsi plda . . . . . . . . . . . . . . . . . . . . . . 44

A. MapReduce Patterns, Algorithms, and Use Cases 45

A.1. Basic MapReduce Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

A.1.1. Counting and Summing . . . . . . . . . . . . . . . . . . . . . . . . 46

A.1.2. Collating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2

TARTALOMJEGYZK

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

A.1.4. Distributed Task Execution . . . . . . . . . . . . . . . . . . . . . . 47

A.1.5. Sorting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

A.2. Not-So-Basic MapReduce Patterns . . . . . . . . . . . . . . . . . . . . . . 48

A.2.1. Iterative Message Passing (Graph Processing) . . . . . . . . . . . . 48

A.2.2. Distinct Values (Unique Items Counting) . . . . . . . . . . . . . . . 51

A.2.3. Solution II: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

A.2.4. Cross-Correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

A.3. Relational MapReduce Patterns . . . . . . . . . . . . . . . . . . . . . . . . 54

A.3.1. Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

A.3.2. Projection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

A.3.3. Union . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

A.3.4. Intersection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

A.3.5. Dierence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

A.3.6. GroupBy and Aggregation . . . . . . . . . . . . . . . . . . . . . . . 56

A.3.7. Joining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3

1. elads

Bevezets

BigData dencija: Olyan nagy s komplex adathalmaz, amelyet mr a szoksos al-

kalmazsainkkal nem tudunk kezelni.

Ez nem egy tl pontosan rtelmezhet denci, ezrt ez felhasznlsi terletenknt vl-

tozik (1.1. bra). Ha a felhasznlsi terlet

az Excel, akkor 1 milli sor, ha

valamilyen memria alap feldolgozeszkz, akkor amennyi memrink van,

azaz 4-8 GB, ha

valamilyen adatbzis pl. MySQl, akkor 50-100 GB, ha

az ltalunk ksztett hatkony diszket jl hasznl programok, akkor 1 TB

fltt szmt BigData-nak. Nagy ltalnossgban azt lehet mondani, hogy 50-100 GB

alatt nem szmt az adat BigData-nak, mert egy nagy memrival rendelkez felh szol-

gltatssal ezek az adatok mg nagyon jl kezelhetek.

1.1. bra. A BigData rtelmezse a felhasznlsi terlet fggvnyben

4

ELADS 1. BEVEZETS

Ettl nagyobb adatmennyisg esetn mr csak valamilyen elosztott rendszerrel tudjuk

hatkonyan kezelni az adatainkat, ilyen elosztott rendszer a Hadoop. A scale up felfogs

szerint, ha egy gpen szeretnnk minl nagyobb szmtsi kapacitst, akkor csak egysze-

ren felsklzzuk (azaz tbb memrit s ersebb processzort tesznk bele), mg a scale

out szerint teljesen hagyomnyos PC-ken elosztott rendszerben gondolkodunk.

Egy msik felfogs szerint onnantl beszlnk BigData problmkrl, amikor az adat

olyan nagy, hogy az mr rszv vlik a problmnak, pldul amikor mr nem frnk a

memriba, vagy amikor mr egy szmtgpen napokig fut az adott feladat. sszefog-

lalva brmilyen problma, amely abbl szrmazik, hogy tl sok adatot kell kezelni. Ezek

legtbbszr valamilyen hardver korltbl addnak (1.2. bra), amelyek egy norml PC

esetn

12-24 TB mret merevlemezt,

32-64 GB mret memrit

jelent. Ezen fell jelents problma az is, ha egy tlagos 2 TB mret merevlemezrl

le akarjuk olvasni a teljes tartalmt, akkor az 6 rba tellene a merevlemez tereszt

kpessge miatt.

1.2. bra. A hardver korltok egy tlagos PC esetn

5

2. elads

Elosztott rendszerek, Hadoop, HDFS

2.1. Elosztott rendszerek

Az elosztott rendszerek lehetv teszik azt, hogy brmilyen mveletet tbb szmtgp

kztt elosztottan hajtsunk vgre, ezltal megnvelve annak sebessgt, kapacitst, ren-

delkezsre llst. Egy elosztott rendszer rengeteg szmtgpbl llhat, melyek egy kzs

cl rdekben egytt tudnak dolgozni, s mkdni. Ezek a szmtgpek egy hlzaton

(vagy akr az interneten) keresztl vannak egymssal sszektve, gy tudnak kommuni-

klni.

Fontos megemlteni, hogy a meghibsods tnye teljesen ms, mint egy egyedlll sz-

mtgp esetben. Az elosztott rendszerek ezt rugalmasan tudjk kezelni, folytatdik a

rendszer futsa szinte szrevehetetlenl. Egyedlll gp esetben termszetesen ez nem

lehetsges (a hiba tpustl fggen). Ez a fajta rugalmassg azrt is fontos, mert egy

tbb tz vagy szz gpbl ll hlzat esetn a meghibsods egy napi vagy heti rendsze-

ressggel elfordul esemny, s nagyon fontos, hogy 1-2 gp kiesse esetn a tbbi gond

nlkl tovbb mkdjn, st lehetleg a feladatok futsa se szakadjon meg.

Tbbfle clra is hasznljk ezeket a rendszereket:

Elosztott adattrol kzpontok: Ezeket a rendszereket kifejezetten nagy mennyi-

sg adatok trolsra talltk ki. Mivel egy adathordozn s szmtgpen megle-

hetsen limitlt a trolhat adatmennyisg, gy ezt tbb szmtgpen tbb adat-

hordozn tudjuk trolni. Tbbnyire az adatok megfelelen vannak repliklva is, gy

az adatveszts kockzata jelentsen lecskken.

Elosztott szmtsi kapacits: A msik nagy felhasznls, amikor az elosztott

rendszereket a teljestmnyk miatt kapcsoljk ssze egy nagy szmtsi felhv.

Ilyenkor egy bizonyos nagy szmtsigny feladatot nagyon gyorsan s hatkonyan

vgre lehet hajtani, mg ez egy nll szmtgpen tbb vig eltarthatna (pl. gene-

tikai mintk elemzse). Az ilyen tpus rendszerek lehetnek elre kongurltak, s

teleptettek, de lehetnek akr nkntesek is, ahova egyszer felhasznli szmtg-

peket az interneten keresztl kapcsolnak be a rendszerbe, s hasznljk az erforr-

saikat. (Ezek lehetnek a GRID computing, HPC, Volunteer computing, Distributed

programming, MPI. Ezek mindegyike szmts- s nem adatignyes feladatokra van-

nak optimalizlva.)

6

ELADS 2. ELOSZTOTT RENDSZEREK, HADOOP, HDFS

2.1.1. Elosztott fjlrendszerek

Rgen egy 1 GB-os merevlemezt krlbell 4 MB/s sebessggel tudtunk olvasni. Mra

a technolgia sokat javult a trolhat adatmennyisg tern, de az olvassi sebessg nve-

kedse nem a vrt rtkeket mutatja. Egy ma kaphat 2 TB-os merevlemezt 100 MB/s

sebessggel tudunk olvasni, ami mg gy is lassnak mondhat abban az esetben, ha a

teljes lemeztartalmat szekvencilisan vgig szeretnnk olvasni (kb. 5,5 ra). Ha ezt az

adatmennyisget elosztva 100 db merevlemezen trolnnk, akkor az adatokat ugyanilyen

olvassi sebessg mellett szinte nhny perc alatt fel tudnnk dolgozni. Emellett a sta-

tisztikk szerint 100 db merevlemezbl 5 hibsodik meg vente. Ezen okok miatt kezdtk

el ltrehozni az elosztott fjlrendszereket.

Az elosztott fjlrendszerek lnyege, hogy a fjljainkat egy kliens-szerver architektra se-

gtsgvel trolhatjuk illetve rhetjk el. Egy elosztott fjlrendszerben egy vagy tbb

kzponti szerver tallhat, amelyek troljk az alapvet informcikat a tbbi szerverrl,

melyek szma elmletben korltlan lehet. Ezek a kitntetett szerepkrrel rendelkez szer-

verek troljk a fjlstruktra hierarchikus felptst, a metaadatokat, s a fjlok konkrt

szerveren val helyt. A gyakorlatban legalbb kett kzponti szervert hasznlnak annak

rdekben, hogy redundancia biztostott legyen.

Ha egy elosztott fjlrendszerbeli fjlt egy kliens gppel szeretnnk elrni, akkor gyakor-

latilag semmilyen klnbsget nem vesznk szre, teht teljesen olyan, mintha az adott

fjlt egy darab szerveren troltuk volna, vagyis a trol Node-ok struktrja elfedsre

kerl. Errl az elfedsrl az elosztott rendszer gondoskodik. Az elosztott rendszerek ers-

sge abban rejlik, hogy ltaluk knnyen elrhetek tbb kliens szmra is ugyanazok az

adatok, s gyakorlatilag egy kzponti trolegysgrl beszlnk, a kliensek nem trolnak

loklisan olyan fjlokat, amelyek ms kliensek szmra is fontosak lehetnek.

2.2. Hadoop trtnete

A 2.1. brn lthat a Hadoop rendszer fejldstrtnete. Eredetileg a Hadoop egy elosz-

tott fjlrendszerknt indult, amelyet a Google kezdett el fejleszteni Google File System

nven. Ezutn tbben megprbltk ezt reproduklni, s elkszteni Open Source projekt

keretein bell.

2.1. bra. Hadoop kialakulsnak trtnete

Ezek utn a Yahoo is elkezdte ugyanezt a rendszert sajt maga elkszteni. A prblko-

zsoknak s a fejlesztseknek ksznheten egyre tbben elkezdtk hasznlni a Hadoop

rendszert (pl. Facebook, Last.FM), s ennek kvetkeztben az Apache felkarolta, s egy

7


dediklt Open Source fejlesztsi projekt keretein bell a mai napig k foglalkoznak a t-

mval. Tbb nagy cg zleti szolgltatsknt is elindtotta a sajt tovbbfejlesztett s

kiegsztett verzijt. A 2.2. brn lthat, hogy 2012-ben a Hadoop rendszert cges kr-

nyezetben 1 ven bell nagyon sokan tervezik bevezetni, teht jelents nvekeds vrhat

a piacon.

2.2. bra. Bevezetni kvnt technolgik cges krnyezetben

2.3. Hadoop HDFS

A Hadoop rendszer egy teljesen sajt, egyedlll elosztott fjlrendszert hasznl, a Ha-

doop Distributed File System-et (HDFS). Ez a fjlrendszer arra lett tervezve, hogy kife-

jezetten nagy mret fjlokat troljunk rajta, mivel a rendszerben nagy adathalmazokon

tudunk valamilyen lekrdezst, vagy mveletet egyszeren vgrehajtani. Pldul log-ok

esetn rdemes nagyobb egysgekben trolni az adatokat, gy nagy fjlmret rhet el.

Az adatokat ltalban egyszer letroljuk, s tbbszr teljesen vgig kell olvasnunk ket

(full scan).

A Hadoop fjlrendszer arra lett tervezve, hogy tlagos otthoni PC-kre vagy tlagos szer-

verekre is telepthet legyen, ezzel is azt sztnzve, hogy kltsghatkonyabban tudjunk

egy elosztott rendszert kialaktani (ez nagy mrtkben klnbzik a SAN szemllettl).

A HDFS egy blokkalap fjlrendszer (tipikusan 64-256 MB egy blokkmret), teht a nagy

fjlok (tipikusan a GB-os nagysgrendben) ilyen mret blokkokra daraboldnak szt, s

a blokkok egymstl fggetlenl trolhatk ms-ms erforrsokon, s szmtgpeken.

A blokkmretet az elrsi id miatt kell nagyobbra venni, mint egy tlagos fjlrendszer

esetben. A fentebb emltett 64-256 MB blokkmretnl nagyobbat mr nem rdemes

vlasztani, mert ezzel elvesztennk a prhuzamosts lehetsgt, mivel a szmtsi fel-

adatok esetben a blokkok betltdnek a memriba, teht gy tbb is befr egyszerre,

nem kell llandan cserlgetni ket a szmts sorn. Ez a gyakorlatban azt jelenti, hogy

egy 1 GB-os fjl esetben, 1 MB-os blokkok esetn az olvass sorn a merevlemez fejnek

8


mozgatsa 1000 10ms keressi idt jelent. Nagyobb blokkmret esetn ez a ksleltetsjval cskken.

Ezen kvl nagyon fontos, hogy minden blokk replikldik legalbb egy - de ltalban

tbb (2-3) - msik szmtgpen is, teht ezzel elkerlhet az adatveszts (Hadoop esetn

az alaprtelmezett replikcis faktor a 3, ez azt jelenti, hogy minden blokk 3 klnbz

helyen van eltrolva). Ha kiesik egy szmtgp, azt egyszeren kivehetjk a rendszer-

bl, s egy jat tehetnk a helybe. Ezltal a rendszer nagyon jl sklzhat, rendkvl

jl mkdik risi gppark esetn is. A blokkok helynek meghatrozst egy komplex

terhelseloszt algoritmus hatrozza meg, ami tbbek kztt gyelembe veszi az egyes

gpek terhelst, a repliklsbl szrmaz adatforgalom minimalizlst, illetve a minl

nagyobb megbzhatsgot (ennek rdekben lehetleg tbb rack illetve adatpark kztt is

megosztja a replikkat).

2.4. Hadoop szerver szerepek

A fjlrendszerben tbb kitntetett szereppel rendelkez gpnek kell lennie ahhoz, hogy az

egsz rendszer megfelelen tudjon mkdni (2.3. bra).

2.3. bra. Hadoop szerver szerepek

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

2.4.1. Name Node (NN)

Ebbl ltalban egy van egy Hadoop rendszerben, feladata a metaadatok trolsa s

karbantartsa. Gyakorlatilag tudja azt, hogy milyen mappk, milyen fjlok tallhatak

a fjlrendszeren. Ezt kt fjl segtsgvel tudja trolni:

Namespace image: Ez egy lenyomat a fjlokrl, mappkrl.

Edit log: A legutbbi namespace image-hez kpest trtnt vltoztatsokat rja le,

ezltal nem kell mindig azt az image-t frissteni, ami jelents erforrsignnyel jrna.

Ennek ellenre ezt a log-ot egy id utn bele kell fznnk a namespace image-be,

mert feleslegesen nagy mretv vlna.

9


Fontos megemlteni, hogy a Data Node-ok rendszeresen jelentik a nluk lv blokkok

listjt a Name Node-nak, amit termszetesen nyilvn is tart. gy ha egy kliens a Name

Node-hoz fordul egy fjlrt, akkor ebbl a naplbl tudja, hogy melyik blokkok kellenek,

s a jelentsekbl el tudja irnytani a klienst a megfelel Data Node-hoz, ugyanis ezen

jelentsek nlkl a Name Node nem tudn, hogy milyen blokkok tallhatak a Data Node-

okon (amelyek nem kerltek mentsre mg a namespace image-be).

A metaadatok trolsnak htrnya, hogyha a Name Node kiesik, s a metaadatokrl

nincs biztonsgi msolatunk, akkor minden adatunk elveszik annak ellenre, hogy zi-

kailag az adatblokkok megmaradnak a Data Node-okon. Ennek kikszblsre RAID

s/vagy NFS (Network File System) technolgikat hasznlnak, gy mind helyileg, mind

hlzaton is tudjuk ezeket trolni.

Ltezik egy Name Node High Avaibility megolds, amely szerint tbb Name Node van a

rendszerben. gy mindegyik folyamatosan trolja az informcikat s kzlk valamelyik

aktv, a tbbi pedig passzv, a kliensek pedig mindig az aktvhoz fordulnak. Az aktv

kiesse esetn ekkor brmelyik passzv rgtn tveheti az aktv szerept. Ez a megolds

termszetesen jelentsen nagyobb terhet r a Name Node-ra, hiszen biztostani kell a

konzisztencit az aktv s passzv Name Node-ok kztt.

2.4.2. Secondary Name Node (SNN)

Ez a szerepkr ahogy elsre gondolnnk nem egy msodlagos Name Node, teht az el-

nevezse megtveszt lehet. Feladata az, hogy segtsen a NameNode-nak az ltala trolt

adatok kezelsben, s a namespace image karbantartsban. gondoskodik arrl, hogy

a fentebb emltett Edit log-ot belefzze a Namespace image-be, s ezeket jra tadja az

elsdleges Name Node-nak.

2.4.3. Data Node (DN)

Ezek a szmtgpek troljk gyakorlatilag a fentebb emltett adatblokkokat. k jelent-

keznek be a Name Node-nak egy fjl keresse sorn, hogy annak a fjlnak egy blokkja

nluk tallhat meg (reporting). A reporting folyamatosan megy, gy szerez tudomst a

Name Node a tl s alul repliklt blokkokrl, illetve gy tudja a klienst a megfelel Data

Node-hoz irnytani.

2.5. Adatmveletek

2.5.1. Olvass

Az olvasst egy pldn keresztl mutatjuk be. A 2.4. brn lthatjuk, hogy a kliens el-

szr a Name Node-dal veszi fel a kapcsolatot (), akinek megmondja, hogy a Results.txt

llomnyt szeretn olvasni. A Name Node az ltala trolt metaadatok alapjn megmondja

a kliensnek, hogy ennek a fjlnak hrom blokkja ltezik, s a blokkok kln-kln melyik

Data Node-okon vannak trolva (). Ezutn a kliens egyesvel kzvetlenl az adatblokko-

kat tartalmaz valamelyik Data Node-hoz fordul, s letlti azokat () (minden adatblokk

esetben az azt tartalmaz valamelyik Data Node-hoz).

10


2.4. bra. HDFS olvass

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

2.5.2. rs

Az rs hasonl mdon trtnik, mint az olvass. A 2.5. brn lthat, hogy a kliens

elszr felveszi a kapcsolatot a Name Node-al (), hogy egy File.txt-t szeretne trolni,

amelyet 3 blokkra tudott felbontani. A Name Node visszakld annyi Data Node cmet,

amennyi blokk szksges (). A kliens ezutn kzvetlenl a Data Node-oknak elkldi az

egyes blokkokat (). Ha ez kszen van, akkor a Data Node-ok replikljk az j blokkokat

(), s jelentik ezt a Name Node-nak ().

2.5. bra. HDFS rs

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

11

3. elads

MapReduce

A MapReduce nem egy programnyelv hanem programozsi modell, egy programozsi

keretrendszer, amely megadja, hogy hogyan hozzunk ltre elosztott programokat. Kife-

jezetten alkalmas arra, hogy nagy adathalmazon dolgozzon elosztott mdon, sok adat

prhuzamos feldolgozsra van kitallva. Mivel nem egy programnyelv, ezrt van megva-

lstsa tbbfle programozsi nyelv esetn is, pldul Java, Python, R stb. A MapReduce

nem csak Hadoop specikus, ms adattrhzakat is lehet MapReduce-ban programozni,

ilyen pldul a MongoDB.

3.1. Az ltalnos MapReduce modell

Egy pldn keresztl nzzk meg az ltalnos MapReduce modell mkdst. Adott

egy adathalmaz, amely hmrskleti rtkeket trol. Hatrozzuk meg az vi maximum

hmrskletet.

Adat: v, hnap, nap, ra, perc, vros, hmrsklet (nagy adathalmaz)

Eredmmy: v, maximum hmrsklet (kis adathalmaz)

Ha egy gpen szeretnnk leprogramozni ezt a feladatot, akkor egy sima maximum ki-

vlasztst kell valamilyen nyelven implementlnunk, gy nem kell memriban tartani az

adatot, egyszeri vgig olvasssal meg tudjuk mondani a krdsre a vlaszt. Ha viszont mr

annyi adatunk van, hogy egy gpen ezt nem tudjuk trolni, akkor valamilyen elosztott

rendszeren kell az adott problmt megoldani. Ez viszont nem egyszer, ezrt talltk

ki a MapReduce keretrendszert, amely elfedi a programoztl a prhuzamosts feladatt

(pl.: nem kell foglalkozni a gpek kztti kommunikcival, klnbz hibk s kiessek

kezelsvel, erforrs kiozstssal stb). A keretrendszer alapveten kulcs-rtk prokon

dolgozik, egy szveges tartalom esetn a kulcs az, hogy a fjl hanyadik sora, s az rtk

pedig a sor tartalma szvegknt. A MapReduce a nevbl addan kt lpsbl ll egy

Map-bl s egy Reduce-bl.

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

A Map lpsben kulcs-rtk pr jn bemenetknt s egy jfajta kulcs-rtk prt, listt

fog kiadni a kimenetn. A Reduce lps a Map kimenetn lv kulcs-rtk prokat kapja

meg, olyan formban, hogy az azonos kulcsokhoz tartoz sszes rtk egy listba kerl.

12

ELADS 3. MAPREDUCE

Errl a lpsrl a keretrendszer gondoskodik. Vgl a Reduce kimenetn jabb kulcs rtk

prokat fogunk kapni. Nzzk meg ez alapjn az elbbi pldt:

Map: (sorID, sor) (v, hmrsklet)Reduce: (v, list(hmrsklet)) (v, max(hmrsklet))

A Map bemenetn kulcs-rtk prokat kapunk, ami jelen esetben sorazonost-sor prokat

jelent. rdemes kiadnunk minden sorbl, hogy melyik vrl szl az a sor s mi volt az

ottani hmrsklet. Ezzel lnyegben a Map lpsben ebbl az adatbl kiszrjk azt

amire szksgnk van, s minden sorra kiadjuk ezt a prost gy, hogy az v lesz a kulcs.

A Reduce bemenetn megjelenik az v mint kulcs s az sszes abban az vben mrt

hmrsklet. A Reduce-bl pedig kiadjuk az vet s a maximum hmrskletet.

A MapReduce keretrendszerben megrt program esetn a programoznak annyi a fel-

adata, hogy logikailag megrjon egy Map s egy Reduce fggvnyt majd a keretrendszer

gondoskodik rla, hogy elossza ezt a feladatot. A Map fggvny bemenete lehet blokk,

fjl de akr sor is s a bemeneten egymstl fggetlenl soronknt hajtdik vgre. Teht

a Map lps trivilisan prhuzamosthat. A Reduce lps is, hogyha megkapja az egy

kulcshoz tartoz sszes elemet akkor az is egyszeren prhuzamosthat. A keretrend-

szer azt biztostja szmunkra, hogy amikor kijnnek ezek a kulcs rtk prok akkor ez

biztosan megrkezzen egy Reduce fggvny bemenetre gy, hogy az sszegyjts mr

tulajdonkppen megtrtnt. Ha kt gprl beszlnk akkor gy lehet elkpzelni, hogy

meg van rva egy Map fggvny, (hogy hogyan lehet kiszedni az vet s a hmrskleteket

az adatokbl) s itt a Map fggvnynek meg van adva az, hogy pros vszm adatokat

az egyikhez a pratlan vszm adatokat a msik gphez kldi. A Reduce gpen trtnik

ezeknek a listba rendezse, kulcs alapjn a berkez adatokat rendezi s utna knnyedn

ltre tudja hozni ezeket a listkat. Hadoop esetn az MapReduce keretrendszer gyel a

lokalits elvre is, teht minden adatot lehetleg ott dolgoz fel, ahol az rendelkezsre ll,

gy nagyban cskkentve a hlzati kommunikcit, s nvelve a sebessget.

3.1.1. 1. Feladat

Vannak dokumentumaink vagy valamilyen szveges fjlok amik soronknt tetszleges sz-

veget tartalmaznak, az elvrt eredmny az, hogy minden szra mondjuk meg, hogy hny-

szor szerepel.

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

Ahogy ltunk egy szt, azt rgtn kiadjuk a Map oldalon, mg a Reduce oldalon egy sima

szmllt kell megvalstani. Ennek egy varicija, ha a Map oldalon megszmlljuk az

egyforma szavakat a sorban, s a szavak szmt adjuk meg a konstans 1 helyett. Az utbbi

megolds nagyobb terhet rak a Map oldalra, viszont cskkenti a hlzati kommunikcit

s a Reduce oldal terhelst.

3.1.2. 2. Feladat

Krem az sszes sort amiben szerepel a BME sz.

A feladatot Map oldalon lehet a legegyszerbben megoldani. A kiadott kulcs brmi lehet.

A Reduce egyszeren megismtli a kimenetn a bemenett.

13

ELADS 3. MAPREDUCE

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

3.1.3. Hadoop MapReduce felptse

3.1. bra. A MapReduce mkdse Hadoop esetn

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

Vannak HDFS blokkjaink, a Hadoopban az esetek jelents rszben egy Map task egy

HDFS blokkon dolgozik (egy HDFS blokk egy szmtgpet jelent). A Map feladat so-

ronknt egymstl fggetlen, ltalban JAVA-ban megrt program rszletrl beszlnk,

indul egy JVM s az soronknt elkezdi feldolgozni. A kimenett pedig megfelelen irny-

tani kell a Reduce-ok fel. Az a feladata, hogy a megfelel kulcs elemeket a megfelel

Reduce-hoz juttassa el. A Map utn ltezik mg egy Partitioning fggvny ami kap egy

kulcsot s megmondja, hogy melyik Reduce folyamathoz tartozik, lnyegben ez egy hash

fggvny. A Particioning-et mr a Map gpen vgezzk. Tudunk csinlni egy Combi-

ner fggvnyt is ami egy adatblokkon a Partitioning utn lefuttat egy msik fggvnyt is.

Tudunk rni sajt particionl fggvnyt is de alaprtelmezetten egy egyenletes hash fgg-

vny, amely csak nagyon egyenetlen adateloszls esetn nem mkdik jl. Ahhoz, hogy

majd a Reduce-nl ssze tudjuk gyjteni a kulcshoz tartoz sszes rtket egy nagy Sor-

tolst kell vgrehajtani, trtnik egy loklis sort gy lesznek kisebb eredmnyhalmazaink

amik mr rendezettek s ezt kldik el a Reducer-nek. A kisebb eredmnyhalmazain-

kat egy sszefslses rendezssel rdemes sszefzni (termszetesen errl a keretrendszer

gondoskodik). A Reduce a kimenett egy HDFS fjlba szokta tipikusan kirni. Ahogy az

architektrbl ltszik egy MapReduce feladat indtsnak van egy elg nagy overhead-je

(ez akr perces nagysgrendbe is eshet), teht csak kellen nagy feladatok esetn rdemes

hasznlni, s interaktv feladatokra nem igazn alkalmas.

3.1.4. Hadoop Cluster

Vannak hasonl szerepek mint a fjlrendszer esetben. Master szerep: JobTraceker, felel

azrt, hogy egy teljes job vgrehajtsra kerljn. A TaskTraceker pedig a vgrehajtsrt

14

ELADS 3. MAPREDUCE

felels, vannak neki szabad kapacitsai, Map illetve Reduce slot-ja (mennyi az kapa-

citsa) s a JobTraceker ezzel gazdlkodik, egyszeren odaadja neki a feladatokat, hogy

melyik Map fggvnyt melyik Reduce fggvnnyel futassa le. A TaskTrackernek semmi

informcija nincs arrl, hogy a tbbiek hogy llnak, nha visszaszl a JobTracekernek,

hol tart a feladatval (HeartBeat). Lnyegben minden szervezsi logika itt is a Master-

ben (JobTrackerben) sszpontosul. A 3.2. bra az rs s olvass mkdst szemllteti.

Mi trtnik amikor egy szmtsi feladatot szeretnnk vgrehajtani. Van egy kliensnk,

egy JobTrackernk illetve tbb TaskTracker. Illetve van egy HFDS (kzs fjlrendszer)

amivel mindenki tud kommuniklni. Az els lps az az, hogy a kliens bejelentkezik a

JobTrackerhez, hogy szeretne egy feladatot vgrehajtani. Erre vlaszul kap egy azonostt

s egy jogosultsgot, hogy onnantl kezdve azzal a job-al foglalkozzon. Klnbz szk-

sges dolgokat a HDFS-re msolja a kliens (Map s Reduce kdja illetve a elre megrt

library-k amiket ezek a fggvnyek felhasznlnak) lnyegben a job-nak egy teljes infor-

mcis csomagjt felrakja a HDFS-re. A TaskTracker sebessge nagyban fgg attl, hogy

mekkora replikci szmot lltunk be a HDFS-en. Nagyon sokszor a replikcik szmt

magasra lltjk, gy minden TaskTracker gyorsan hozzfrhet az HDFS-en trolt adatok-

hoz. A kvetkez lps a submit vagyis a kliens szl a JobTrackernek, hogy induljon el ez

a job. A HDFS-en megvan minden informci ami a job-ot lerja, ez tipikusan egy XML

vagy egy JAR fjl stb.

3.2. bra. A JobTracker mkdse Hadoop esetn

Amikor a JobTracker megkapja ezt a submit-ot megnzi, hogy a ler helyes illetve az

adatot is lerja amin le kell futtatni ezt a job-ot. gy ki tudja szmolni hogy melyik fjl

hny blokkbl ll illetve hny Map s hny Reduce folyamat lesz. Rendelkezsre kell lljon

minden olyan informci ami a feladatok kiosztst s elkezdst lehetv teszi. Nagyon

fontos dolog, hogy nem a JobTracker fog kapcsolatot ltesteni a TaskTrackerek-kel, ha-

nem vrja, hogy a TaskTracker-ek bejelentkezzenek (HeartBeat)s elkldjk mennyi res

slot-juk van illetve az egyes taskok, hogy llnak nluk. A JobTracker tudja, hogy az egyes

15

ELADS 3. MAPREDUCE

adatblokkok hol helyezkednek el s melyik gpen vannak HDFS-en, tovbb tud arrl,

hogy milyen aktv jobok vannak s melyek azok amelyek nem futnak sehol s erre vlaszul

ad egy task-ot a TaskTrackernek amiben benne van, hogy a HDFS-rl hol tudja elrni an-

nak a task-nak az informcijt. A JobTracker kiadja a task-ot a TaskTracker begyjti az

informcikat, hol rhet el a Map fggvny illetve a klnbz Partcionl fggvnyeket

s ezeket a szksges adatokat a HDFS-rl betlti. gy mkdik minden HDFS esetn,

amg vannak szabad Taskok amiket vgre kell hajtani, addig mindegyik bejelentkezsnl

meg fogjk kapni a feladatokat. Ha pedig vgeznek kldenek egy HeartBeatet, hogy ez a

task kszen van. Adott esetben egy Map task szl hogy kszen van s amikor a Reduce

ezt kiolvasta akkor lesz befejezettnek tekintve a Map-nek a feladata.

3.1.5. Meghibsodsok

Ha meghal egy task akkor nincs semmi baj mert jraindtja azt a taskot a TaskTracker.

Sajnos a JobTracker nem tudhatja, hogy egy-egy task azrt halt meg mert rossz a fel-

hasznl kdja, elment az ram, elromlott egy switch stb. Ilyenkor van egy limit, hogy

hnyszor lehet jraindtani azt a taskot. Igyekszik egy msik Node-on jraindtani az el-

halt taskot a JobTracker. Ltezik egy spekulatv futtats nev eljrs, miszerint ugyanazt

a taskot tbb TaskTrackeren is futtatja. Ennek az a clja, hogy ha brmikor van egy olyan

node ami tl lass, akkor az ne blokkolja az egsz rendszert ezrt tbb pldnyon elindul

s ha valami befejezdtt a msikat eldobja (ezt leginkbb az utols task-ok esetn szokta

csinlni a JobTracker). Ez abban az esetben j, ha viszonylag kihasznlatlan a cluster s

van szabad erforrs. Ha egy TaskTracker kiesik akkor nem fog jnni tle tbb HeartBeat

ilyenkor a JobTracker azt ltja, hogy az sszes Task ami ott futott elhalt s jraindtja

mshol. Ha a JobTracker ll meg, akkor kztes llapotban maradnak a Nodeok s ha jra

elindul akkor ellrl indulnak az adott task-ok. Erre megolds a redundancia alkalmazsa,

ltezik egy High Availability kongurci ahol kt JobTracker van.

16

4. elads

MapReduce programozsi mintk,

Streaming

4.1. 1. feladat

Adott egy adathalmaz, amely hmrskleti rtkeket trol. Hatrozzuk meg egy vros

tlaghmrsklett egy adott hnapban.

Adat1: v, hnap, nap, ra, perc, vros, hmrsklet

Eredmny: vros, hnap, tlaghmrsklet

Map: (sorID, sor) ((vros + hnap), hmrsklet)Reduce: ((vros + hnap), list(hmrsklet)) ((vros + hnap), avg(hmrsklet))

A szvegfjloknl a bemeneti kulcs-rtk szinte mindig (sor, sorID) lesz, amikor valamilyen

aggreglst vgznk. Ha SQL lekrdezst ksztennk erre a feladatra, akkor a Map

kimenetnek a kulcsa az lesz, amit a GROUP BY mg rnnk, ami szerint aggreglunk.

Ezrt lesz a Map kimenetnek kulcsa a (vros + hnap). A keretrendszer automatikusan

ezen kulcs alapjn csinl egy listt, amely a Reduce bemenete lesz majd, gy egy kulcshoz

tartoz rtkek egy Reducehoz kerlnek. A Reduce pedig kiszmolja az egy kulcshoz,

azaz a (vros + hnap)-hoz tartoz tlaghmrskletet.

4.2. 2. feladat

Adott egy adathalmaz, amely egy weblog adatait trolja. Hatrozzuk meg hogy melyik

nap hny oldalletlts volt.

Adat2: dtum, id, sessionID, url

Eredmny: dtom, oldalletltsek szma

Ha ez egy strukturlt SQL tbla lenne, akkor a kvetkez lekrdezssel lehetne a vlaszt

megadni:

SELECT date, COUNT(*) FROM table GROUP BY date


aggreglst vgznk. A GROUP BY mgtt a dtum van, ezrt a Map kimeneti kulcsa a

17

ELADS 4. MAPREDUCE PROGRAMOZSI MINTK, STREAMING

Map: (sorID, sor) (dtum, 1)Reduce: (dtum, list(1)) (dtum, cnt(1))

dtum lesz, s csak meg kell szmolni, hogy abbl hny darab van. A Reduce-nak mr

csak ezeket az 1-eseket kell megszmolnia.

4.3. 3. feladat

Az adathalmaz ugyanaz, mint az elbb, de most azt szeretnnk megtudni, hogy hny

egyedi ltogat volt az oldalon egy napon. Egyedi ltogats alatt az egy sessionID-hoz

tartoz lekrseket rtjk.

Adat2: dtum, id, sessionID, url

Eredmny: dtum, egyedi ltogatszm

Ha ez egy strukturlt SQL tbla lenne, akkor a kvetkez lekrdezssel lehetne a vlaszt

megadni:

SELECT date, COUNT (DISTINCT(sessionID)) FROM table GROUP BY date

Map: (sorID, sor) (dtum, sessionID)Reduce: (dtum, list(sessionID))

unique (dtum, cnt(distinct(session)))


aggreglst vgznk. A Map kimeneti kulcsa a dtum lesz s a Reduce fogja az egyedisget

garantlni (unique). Az egy Reduce folyamatnak kell az egy dtumhoz tartoz sszes

krst a memriban tartani s ez szk keresztmetszet lehet, ha egy napon nagyon sok

adat keletkezett, akkor a folyamatunk nem tud sklzdni. Ezrt rdemesebb sztbontani

ezt kt kln MapReduce folyamatra:

Map 1: (sorID, sor) ((dtum + sessionID), 1)Reduce 1: ((dtum + sessionID), list(1)) ((dtum + sessionID), 1)

Map 2: ((dtum + sessionID), 1) (dtum, 1)Reduce 2: (dtum, list(1)) (dtum, cnt(1))

Az els MapReduce folyamat kimeneti kulcsa a (dtum + sessionID), gy minden naphoz

egy sessionID csak egyszer tartozhat. A msodik folyamatban mr csak meg kell szmol-

nunk, hogy az adott dtumhoz hny bejegyzs tallhat. Ezzel mdszerrel sklzhatv

tettk a megoldst mg akkor is, ha egy naphoz nagyon sok adat tartozik, mert nem kell

egy Reduce folyamatnak a memriban tartani az egy naphoz tartoz sszes adatot.

4.4. 4. feladat

Az adathalmazunk az elbb mr megismert weblog adatai, amihez felvesznk mg egy

kapcsoltblt, amely megmondja, hogy melyik sessionID melyik felhasznlhoz tartozik.

Gyakori feladat, hogy a kt tblt ssze kell illeszteni (join).

18


Adat2: dtum, id, sessionID, url - LEFT

Adat3: sessionID, userID - RIGHT

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

Erre az egyik lehetsg a REDUCE-SIDE join:

Az Adat2 halmazt nevezzk el baloldali tblnak, az Adat3 halmazt pedig nevezzk el

jobb oldali tblnak. A Map bemenete a mindkt tbla soraibl addik, de tudnia kell,

hogy melyik tblbl rkezett az adat. Ha SQL lekrdezst ksztennk erre a feladatra,

akkor a Map kimenetnek a kulcsa az lesz, ami alapjn vgeznnk a join mveletet. Ezrt

a Map kimenetn a kulcs a sessionID lesz, az rtk a sor tartalma s hogy melyik tblbl

szrmazik (L/R). A Reduce folymat a sessionID-hoz tartoz rtkeket a memriban

tartja s gy vgzi el az sszeillesztst (pldul egy for ciklussal sszeilleszt mindenkit

mindenkivel). Ez akkor okozhat problmt, ha az sszeilleszt elemhez (jelen esetben a

sessionID-hoz) nagyon sok adat tartozik, amely nem fr el a Reducer memrijban. A

msik hibja ennek a megoldsnak, hogy lehet olyan sessionID, amirl nincs rekordunk a

msik tblban. Ekkor ezt feleslegesen kldjk t s generlunk vele nagy adatforgalmat.

(Sok esetben elfordul, hogy a felhasznl nem lp be az adott oldalra, gy csak sessionID-t

tudunk hozz trstani, de userID-t nem.)

Ez a problma egy msfajta joinnal elkerlhet. A Map kimenetn nem adjuk ki mr

azokat az elemeket, amikhez nem lehet msik tblbl adatokat trstani, ez lesz aMAP-

SIDE (broadcast) join:

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

A joinok nagy rsze olyan szokott lenni, hogy van egy nagy tblnk s van egy kisebb

tblnk, pldul minden felhasznlhoz egy rekord. Ha ez a kisebb tbla elfr a mem-

riban, akkor elszr minden Mapnek elkldjk ezt a tblt, hogy csinljon belle egy

sessionID-userID struktrt a memriban. Eztn a msik tblbl tkldjk a sorokat

s megnzzk, hogy melyiket kell ehhez hozzilleszteni. gy a Map bemenete csak a sorID

s a bal oldali tbla sorai lesznek, mg a jobb oldali tbla a Map memrijban van. Az

sszeilleszts mr a Map lpsben megtrtnik, teht nincs szksg Reduce lpsre.

ltalban ez a kt join tpus hasznlatos, mindkettnek megvannak a sajt korltai, de ha

van valamilyen plusz informcink az adatok szerkezetrl vagy rendezettsgrl, akkor

gyorsabb s jobban sklzd join fggvnyeket is tudunk kszteni.

Tovbbi MapReduce pldk az A. fggelkben tallhatak.

4.5. Streaming

Java-ban MapReduce kdot rni nehzkes, mert meglehetsen sok kdot kell rni, ezrt

vals igny az, hogy ne csak Hadoop-Java API-val rhassunk kdot. Erre van egy olyan

megolds, aminek a neve Hadoop-streaming: brmilyen nyelvben meg lehet rni MapRe-

duce fggvnyeket, amelyek a standard bemenetrl (stdin) tudnak olvasni s standard

kimenetre (stdout) tudnak rni. A keretrendszer a standard bemenetre fogja kldeni az

19


adatot s a standard kimeneten fogja vrni a fggvny eredmnyt. A kulcs-rtk prok

szeparlsa soronknt tabbal trtnik.

A kvetkez pldn keresztl nzzk meg, hogy ezt hogyan lehet megvalstani pythonban.

Bemenet: dtum, hmrsklet

Kimenet: adott vi maximum hmrsklet

Ennek a MapReduce megoldsa:

Map: (sorID, sor) (v, hmrsklet)Reduce: (v, list(hmrsklet) ) (v, maxhmrsklet)

A Map s a Reduce fggvnyek megvalstsa pythonban:

1 for line in sys.stdin:

2 vals = line.split(",")

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

4.1. Kdrszlet. 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. Kdrszlet. reduce.py

4.6. Adattmrts

ltalnos felhasznls mellett a Hadoop keretrendszer inkbb trhely, mintsem processzor-

ignyes. Nagyon nagy adathalmazokat kell trolnunk, illetve egy Map s egy Reduce lps

kztt nagyon sok adatot kell mozgatnunk. Ezrt ezeket a lpseket rdemes optimalizl-

ni, amelynek az elsdleges mdja az adattmrts.

Adattovbbts a hlzaton Snappy tmrtssel trtnhet, mivel nagyon kicsi a CPU

overheadje. Nem olyan hatkony tmrt algoritmus, mint pldul a gzip, de streamknt

tud tmrteni s gy elg sokat tud sprolni az adattvitelen (20-30 %-os teljestmny-

nyeresg).

A msik lehetsg a tmrtett fjlok hasznlata. A rendszer automatikusan felismeri a

tmrtett fjlokat s kitmrti a klnbz feladatok eltt. A merevlemezen trtn

trolshoz a kvetkez tmrtseket szoktk alkalmazni:

20


gzip: Tegyk fel hogy van egy 1 GB-os fjlunk ami 16 blokkbl ll s tmrtve

van. A blokkmret 64 MB, gy ekkora rszekre van vgva a trolnkon. Ha csak

egy rsz kell a fjlbl, akkor is ki kell ki kell tmrteni az egszet, hogy ki tudjuk

olvasni belle az adatot. Egy Map folyamat eltt mindenhova el kellene juttatni a

teljes fjlt, hogy az adott blokkot a Map fel tudja dolgozni. Ezrt a gzip esetn a

fjlokat gy rdemes szervezni, hogy a fjlok a blokkmrettel azonosak legyenek.

bzip2: Olyan tmrtsi eljrs, amelyet ha brhol elkezdnk olvasni, akkor is ki

lehet olvasni a fjl tartalmt, de ezt nem annyira hasznljk, mert elgg lass s

nem annyira hatkony.

lzo: Az ezzel a tmrtett fjlt sem lehet brhonnan olvasni alapesetben anlkl,

hogy ki kellene az egsz fjlt tmrteni, de emell kitalltak egy metaadat fjlt,

amely tartalmazza a Map folyamat szmra, hogy mely blokkot kell kitmrteni.

A legegyszerbb eset, ha nyers adatokkal dolgozunk, de nagyon nagy fjlmretek ese-

tn mr szksgess vlik a tmrts, akkor ha lehetsges a gzip-es tmrtst rdemes

alkalmazni a blokkmrettel azonos nagysg fjlokkal. Ezen kvl sok kicsi fjl sszevon-

sra mg a SequenceFile formtum is hasznlatos, ami egy Hadoop specikus formtum,

leginkbb a tar formtumra hasonlt.

21

5. elads

Hadoop csomagok, SQL for Hadoop:

Hive

5.1. Hadoop csomagok

Minden csomag vagy projekt opensource, Apache oldaln megtallhat a megfelel alol-

dalon forrskddal s dokumentcival egytt.

5.1.1. Flume

Logok trolsa s gyjtse a szerepe, kpes HDFS-en trolni a logokat. Egy ltalnos

use-case, hogy van egy webes cg ahol kiszolgljk felhasznlkat. Minden webszerveren

indtanak egy Flume genst aminek van valami bemeneti pontja, s brmilyen zenetet

kap onnantl az feladat az, hogy tovbbtsa ezt az zenetet. Ez egy megbzhat logo-

lsi rendszer. Fontos, hogy a logok megmaradjanak ugyanis ksbb ezek alapjn lehet

elemezni a program mkdst s a felhasznli lmnyt. Megknnyti, hogy brmilyen

szmtgptl logokat gyjtsnk s nem kell a webalkalmazsnak azzal foglalkoznia, hogy

a logokat elkldje, a logszerver megkapja, hanem mindezt tveszi a Flume. Nem egy

specilis Hadoop csomag de a Hadoophoz nagyon sokan hasznljk. Fontos megjegyezni,

hogy ez egy egyirny adat kzvetts.

5.1.2. Sqoop

Klnbz SQL alap adatbzisokkal tud adatot cserlni. Valamilyen JDBC kapcsolaton

keresztl elr egy adatbzist s kpes arra, hogy ha valahol van egy 10 gpbl ll MySQL

cluster akkor a sqoop, ezt a tblt t tudja msolni a HDFS-re. Ilyenkor tbb Mapet

elindt s elosztottan tud msolni adatbzisok s Hadoop kztt. Ez termszetesen oda-

vissza mkdik s az a nagy elnye, hogy habr ezt brmilyen adatbzissal meg tudn

csinlni, kpes arra, hogy prhuzamostsa ezt feladatot gy sokkal gyorsabb. A folyamat

lnyegben az, hogy indul egy MapReduce job a JDBC connection kipl s jnnek az

adatok.

5.1.3. Hive

Ez a csomag mr az elemzsi rteghez tartozik mg a korbbiak az adatelrsi rtegben

nyjtanak szolgltatsokat. Tulajdonkppen egy SQL lekrdez nyelvet nyjt Hadoop

22

ELADS 5. HADOOP CSOMAGOK, SQL FOR HADOOP: HIVE

fel. A Hive-nak az a feladata, hogy SQL lekrdezseket lehet vele vgrehajtani. Az SQL

lekrdezsbl csinl egy MapReduce job-ot s ezt lefuttatja a clusteren majd visszaadja

strukturlt tblzatos formban az eredmnyeket. Ez knyelmes mivel csak SQL kifejez-

seket kell rni s nem kell gondolkozni a Map s a Reduce fggvnyeken. Sok mindenben

klnbzik egy hagyomnyos adatbzisnak az SQL lekrseitl, sokkal tbb idbe telik

egy lekrdezs, ezrt tipikusan analitikus elemzsekhez hasznljk.

5.1.4. Pig

Ez egy szkript nyelv ami cljban hasonlt az SQL-hez. A feladata lnyegben ugyanaz,

MapReduce job-okat csinl a szkriptbl. Nagyon rugalmasan kezeli a sorok feldolgozst

brmit megeszik. Preziben szinte kizrlag piget hasznlnak, viszonylag knnyen tanul-

hat s hasonl szerepe van mint a Hive-nak, hogy helyetted MapReduce jobokat hozzon

ltre.

5.1.5. HBase

Minden amirl eddig sz volt az HDFS s MapReduce alapokon mkdtt. Az HBase

egy specialitsa, hogy nem indt MapReduce jobot mivel az HBase az egy kulcs-rtk

adatbzis mely megvalstja a NoSQL paradigmt. A NoSQL (egyes rtelmezsek szerint

Not only SQL, azaz nem csak SQL, ms rtelmezs szerint egyszeren csak nem SQL)

adatbzis szoftverek gyjtneve. A NoSQL adatbzisok elssorban nem tblzatokban

troljk az adatokat s ltalban nem hasznlnak SQL nyelvet lekrdezsre. Ez egy kulcs-

rtk adatbzis amelynek hatalmas elnye az, hogy nem MapReduce alapokon dolgozik,

hanem kzvetlen hozzfrse van a HDFS-hez. gy kpes milliszekundumos lekrsek

vgrehajtsra (sokkal gyorsabb mint a Hive).

5.1.6. Mahout

Ez egy szintn npszer csomag, statisztikai gpi tanulsi algoritmusokat tartalmaz, osz-

tlyoz algoritmusok, gyakori mintakeres, szveg osztlyozsra hasznljk sokan.

5.1.7. Zookeeper

Ltezik egy llatgondoz nev csomag (Zookeeper). Minden egyb Hadoop csomag fel-

hasznlja ennek a szolgltatsait, mivel egy elosztott rendszerben elg nehz a konkurens

dolgoknak a kezelse. Ha kt kliens ugyanazt a HDFS blokkot akarja rni vagy ugyan-

azt a tblt akarjk rni, ezek nem trivilis problmk. Ezeket a szervezsi koordincis

dolgokat valstja meg a Zookeeper.

23


5.1. bra. A Hadoop csomagok felptse

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

5.2. SQL for Hadoop: Hive

A Hadoop most mr lassan 10 ves, de kezdetben elgg res volt s kevs volt hozz

az eszkz. Szksg volt valami egyszer felletre amit tmegesen tudnak hasznlni az

emberek. A Facebook hozta ltre, kellett egy SQL alap csomag mert a JAVA MapReduce

programozs nem igazn mkdtt s elgg nehz volt. Elkezdtk a HIVE fejlesztst

ami egy SQL interface a hadoopra (egy plusz rteg de nem trhz). Maga a Hadoop

platformot azrt vlasztottk mert olcs s jl sklzdik.

5.2.1. A Hive felptse

5.2. bra. A Hive mkdse

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

Van egy Driver ami a fordtsrt felel s az SQL kifejezseket fordtja MapReduce job-

okra. A kvetkez lpcs az optimalizlja, ezt kitallja maga, hogy hogyan legyen

hatkonyabb a lekrdezs. (minden SQL motorban tallhat egy ilyen). Az Executor

24


pedig az aki operatvan ezt a futtatst elvgzi. Kommunikl a MapReduce-szal s elvgzi

ennek a futtatst. Ezen kvl meg tallhatk a kvetkez elemek mg benne: Command

Line Interface (CLI), JDBC, ODBC kapcsolat tvoli elrsekhez. Ltezik tovbb egy

MetaStore nev komponens is amelyben olyan bejegyzsek vannak, hogy milyen tblink

vannak, milyen a fjlok formtuma, mi a szepartor karakter, milyen tpus adatok illetve

mezk vannak (ez rja le, hogy lehet a szveges fjlokat adatbzis tblaknt rtelmezni).

Az esetek tlnyom tbbsgben ez egy MySQL adatbzis amely ltalban kis mret,

egy gpen fut SQL adatbzis. Amikor errl a szmtgpen elindtanak egy lekrst ak-

kor ez vgig megy az sszes emltett komponensen s a vgn megkapjuk az eredmnyeket.

Furcsa lehet azonban, hogy adatot feltltnk s utlag valami smt denilunk r, ez az

eddigi tudsunkkal pont ellenttesen mkdik. Ezt a folyamatot gy hvjk, hogy scheme-

on-write. Amikor bekerl az adat akkor ellenrzm a smt (amikor a tblba betltm)

s onnantl tudom, hogy j az adat ami bekerl a tblba. A scheme-on-read pedig kiol-

vasskor ellenrzi a smt, ha rossz az adat azokon a helyeken null-t fogunk visszakapni

nem hibt. Tovbbi klnbsgek az SQL s a Hive kztt: nincs olyan hogy UPDATE.

Egyszeren nincs r szksg, logokat gyjtnk s mirt akarnnk frissteni a tegnapi ada-

tokat (persze ha meg akarjuk hamistani akkor lehet) de radsul az adatok is blokkokban

vannak trolva s egy blokkban egy adatot mdostani nem ri meg. Indexelssel vannak

kzepesen kiforrott prblkozsok, de alapveten adattblk vgig olvassra talltk ki

s nem arra, hogy egy felhasznl adataival mveleteket vgezznk, majd pedig ezeket az

adatokat jra belerjuk az adatbzisba.

25

6. elads

Pig programozs

6.1. Bevezets

A Pig egy magas szint, az SQL nyelvhez hasonl szkript nyelv, amit az Apache Hadoop

hasznl MapReduce job-ok ltrehozsra. Lehetv teszi komplex adat transzformcik

rst Java tuds nlkl.

A nyelv eszkzkszlete teljes, ezrt mindenfle adatmanipulcis mveletet tudunk vele

vgrehajtani. A felhasznl ltal denilt fggvnyeken keresztl (User Dened Functions

- UDF), pedig brmilyen kdot meghvhatunk klnfle nyelvekbl mint pldul: JRuby,

Jython s Java. A scriptnket ms nyelvekbe is begyazhatjuk, ennek eredmnyekpp

komponensknt hasznlhatjuk, hogy nagyobb rendszereket ksztsnk, s mg komplexebb

alkalmazsokat, amik relevns problmkra adnak megoldst.

A Pig tbbfle forrsbl szrmaz adattal tud dolgozni, belertve strukturlt s struk-

turlatlan adatokat, az eredmnyt pedig eltrolhatjuk a HDFS-en. A Pig szkripteket

MapReduce job-okra fordtjk, amik az Apache Hadoop klaszteren futnak. Ebben a fe-

jezetben kvetve a Hortonworks lerst (Hogyan hasznljuk az alapvet pig parancsokat

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

nzzk az alapvet mveleteket, s a szkript nyelv hasznlatt. A kvetkez terleteket

rintjk:

Egy relci ksztse sma nlkl

Egy j relci ksztse egy ltez relcibl

Kt relci illesztse (Join mvelet)

Adatok rendezse az ORDER BY hasznlatval

Az adatok szrse s csoportostsa a GROUP BY hasznlatval

A lers a Hortonworks rendszeren lett elksztve, de valszn knnyedn tltethet

egyb rendszerekre is.

6.2. A fjlok feltltse

Elsknt szerezzk be a szksges adatokat a feladat elvgzshez. Errl a linkrl le

tudjtok tlteni a szksges adatokat, amik a New York Stock Exchange adatait tartal-

mazzk 2000 s 2001-es vbl. https://s3.amazonaws.com/hw-sandbox/tutorial1/

infochimps_dataset_4778_download_16677-csv.zip

26

ELADS 6. PIG PROGRAMOZS

Tltsk fel az adatokat a File Browser segtsgvel.

6.1. bra. Adatok feltoltese

6.3. A script megrsa

A Pig felhasznli fellett a Pig ikonra kattintssal tudjuk elhozni. A baloldali panelen

a szkriptjeink listjt lthatjuk, a jobb oldalon pedig a szerkeszt felletet, a szkriptek

rshoz s mdostshoz. Egy specilis funkci az oldal aljn tallhat, mgpedig a Pig

helper, ami templateket nyjt a Pig kifejezsekhez, fggvnyekhez, I/O mveletekhez,

stb. Az oldal aljn lthat egy sttusz fellet, amikor futtatjuk a szkriptet itt lthatjuk

majd az eredmnyeket s a log fjlokat. Adjunk egy nevet a szkriptnek s kezdjk el a

szkript rst egy relci ltrehozsval.

6.2. bra. Pig script szerkeszt fellete

6.3.1. Relci denilsa

Ebben a lpsben beolvassuk az adatokat s ltrehozunk egy relcit.

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

2 DESCRIBE STOCK_A;

Az els sorban denilunk egy relcit STOCK_A nven s beolvassuk a *.csv fjlunkat,

a msodik sorban pedig kirjuk a STOCK_A relcit. A "Save" gombbal elmenthetjk

27


a szkriptet az "Execute" gombbal pedig futtathatjuk. Ez a mvelet egy, vagy tbb Ma-

pReduce job-ot fog indtani. Egy kis id mlva a script futni kezd, s az "Execute" gomb

egy "Kill" gombra fog vltozni. Ezzel megllthatjuk a szkript futst. A Progress bar

mutatja, a folyamat elrehaladst. Ha kk a szne, akkor a job fut. Ha piros a szne,

akkor valami problma, vagy hiba trtnt. Ha zldre vlt, a szkript helyesen lefutott. Az

eredmnyt megtekinthetjk a zld dobozban a Progress bar alatt, vagy el is menthetjk.

Jelenleg a STOCK_A relcinak nem lesz smja, mert nem deniltunk neki smt

mikor betltttk az adatot a STOCK_A relciba.

6.3. bra. A sma kirsa

6.3.2. Relci denilsa smval

Mdostsuk az elz szkriptnknek az els sort s adjuk hozz a "AS" kifejezst, hogy

egy smt deniljunk 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;

Mentsk el s futtassuk a szkriptet. A kimeneten lthat lesz a sma, amit deniltunk.

6.4. bra. A ltez sma kirsa

6.3.3. Relci ltrehozsa egy msik relcibl

Egy ltez relcibl tudunk j relcikat ltrehozni. Pldul szeretnnk egy B relcit

kszteni, ami a STOCK_A relcinak az els 100 bejegyzst tartalmazza. Adjuk hozz

a szkriptnkhz a kvetkez sort.

28


1 B = LIMIT STOCK_A 100; DESCRIBE B;

2 DESCRIBE B;

Mentsk el s futtassuk a szkriptnket. Lthatjuk, hogy a B relcinak ugyanaz a smja,

mint a STOCK_A relcinak, mivel egy rszhalmaza a STOCK_A relcinak.

6.3.4. Adatok kirsa

Az adatok kirshoz hasznljuk a DUMP parancsot a Pig szkriptnkben. A szkriptnk

vghez fzzk hozz a kvetkez sort. Mentsk el s futtassuk jra a szkriptnket.

1 DUMP B;

6.3.5. Oszlop kivlasztsa a relcibl

Trljk az eddig megrt szkriptet, mivel a kvetkezkben nem lesz r szksgnk. Az

egyik elnye annak, hogy a Piget hasznljuk az adatok transzformcija. j relcikat

tudunk ltrehozni, a meglv relcikban lv mezk kivlasztsval, a FOREACH parancs

hasznlatval. Deniljunk egy j relcit C nven, ami csak a symbol, adat s close

mezket tartalmazza a B relcibl. A teljes kd a kvetkez:




float);

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

3 DESCRIBE C;

Mentsk s futtassuk a szkriptnket, a kimeneten a kvetkez fogjuk ltni.

6.3.6. Adatok rsa a HDFS-re

Ebben a rszben megnzzk, hogy hogyan tudunk rni a HDFS-re a szkriptnkbl. A

kvetkez parancsot rjuk bele a szkriptnkbe:

1 STORE C INTO 'output/C';

Ezttal is indulni fog egy MapReduce job, gy vrnunk kell egy kicsit az eredmnyre.

Amikor a Job futsa befejezdik nyissuk meg a File Browsert, s keressk meg az jonnan

ksztett knyvtrunkat, aminek a neve output. Ebben lesz egy alknyvtr C nven,

amiben tallni fogunk egy part-r-00000 nev fjlt. Ha rkattintunk lthatjuk a tartalmt.

6.3.7. Kt relci illesztse (Join mvelet)

Ksztsnk egy j Pig szkriptet Pig-Join nven, majd hozzunk ltre egy j relcit DIV_A

nven. Ezutn illesszk a kt relcit A s B a symbol s dtum mezk alapjn, majd

29


6.5. bra. Adatok kirsa a HDFS-re

rjuk ki az j relci smjt.




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 meggyeljk a C relci mind a kt relcibl tartalmazni fogja az sszes mezt. A

DUMP paranccsal tudjuk kirni a C relci tartalmt.

6.3.8. Adatok rendezse

Az ORDER BY parancs segtsgvel tudjuk a relcit rendezni egy, vagy tbb mezjre.

Ksztsnk egy j Pig szkriptet Pig-Sort nven, majd adjuk ki a kvetkez parancsokat

az adatok rendezshez.



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

2 DUMP B;

6.3.9. Adatok szrse s csoportostsa

A GROUP paranccsal tudjuk egy mezre csoportostani az adatokat, a FILTER paranccsal

pedig szrhetjk ket egy mintra. Ksztsnk egy j Pig szkriptet Pig-group nven s

rjuk be a kvetkez parancsokat a szerkeszt felleten.

30




float);

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

3 C = GROUP B BY dividend;

4 DESCRIBE C;

5 DUMP C;

6.4. Tovbbi forrsok

Az alapvet parancsok tnzse utn, ha szeretnl jobban elmlyedni a Pig szkriptek

rsban, akkor remek elfoglaltsg a Pig dokumentcijnak az tolvassa, amelyet a

kvetkez linken rtek el. http://pig.apache.org/docs/r0.7.0/tutorial.html.

31

7. elads

Hadoop klaszterek kongurcija s

zemeltetse

Egy Hadoop cluster fellltsa annyira nem is egyszer feladat, mint ahogy azt gondol-

nnk. Sok szempontot gyelembe kell vennnk az elosztott rendszerek megtervezsekor.

7.1. Hardver

A cluster legfontosabb ptelemei a szmtgpeket (Node-okat) kiszolgl hardverek.

Minden Node-knt egy olyan hardverrel felszerelt gpet kell zemeltetnnk, amely kellen

sok httrtrral rendelkezik, s a szmtsi feladatokhoz ers CPU s jelents memria-

mennyisg jellemzi.

A hardvermretezst egy pldn keresztl mutatjuk be. Tegyk fel, hogy egy cg t

szeretne trni Hadoop cluster-es szerverparkra, amelyen naponta 100 GB j bejv adatot

szeretnnek trolni. Ezt a mennyisget egy vre levettve 36 TB-ra becslhet a trolnikvnt adat. Tudjuk, hogy a Hadoop cluster egy adatot 3 klnbz helyen trol el a

replikci miatt, teht ez a mennyisg 100 TB lesz. Az egyb dolgok s elemzsekcljbl +25%-kal szmolhatunk, teht 125 TB-nl tartunk. A Hadoop rendszer elg sok

mindenrl kszt log-ot, valamint emellett minden gpen kell opercis rendszernek futnia,

teht szksg van olyan adatok trolsra is, amik nem a HDFS-en bell tallhatak. Erre

+10%-ot szmolunk, teht nagyjbl 140 TB trhelyre van szksgnk. Egy tlagosszervergpben 4-6 HDD tallhat, ha 3 TB-os egysgekben gondolkozunk, akkor ez 12-18

TB. Ha a fentebbi adatmennyisget nzzk, akkor 10 gpes cluster-t kell fellltanunk.Mivel tipikusan az IO a szk keresztmetszet Hadoop esetn, ezrt rdemesebb tbb kisebb

HDD-t berakni, mint kevs extrm nagyot.

Hozz kell tennnk, hogy ez az adatmennyisg nem tmrtett, tmrtssel sokkal keve-

sebb adatmennyisggel is lehet szmolni. Pldul egy olyan log esetben, ahol ugyanaz

az rtk sokszor szerepel, vagy ismtldik, ott gzip esetn akr 2-3-szoros tmrtsi rta

is elrhet, ezzel rengeteg helyet tudunk sprolni.

Memria tekintetben a master szerepeket birtokl gpek esetben az ajnlott mennyisg

24 GB, a CPU-nak pedig rdemes 8 magost vlasztani (2013-as adatok alapjn). Emellett

a fontos szerepeket kiszolgl gpek esetben rdemes egy bizonyos vdelmet is beiktatni

(pl. RAID). Az egyszer Data Node-ok esetben elg egy 4 magos CPU, s 8-24 GB me-

mria. A Hortonworks ltal ajnlott hardvermretezsrl a 7.1. tblzatban tallhatunk

rszletesebb bemutatst.

32

ELADS 7. HADOOP KLASZTEREK KONFIGURCIJA S ZEMELTETSE

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

Slaves

Balanced workload Four to six 2 TB disks One Quad 24

1 GB Ethernet all-to-allHBase cluster Six 2 TB disks Dual Quad 48

Masters Balanced and/or HBase cluster Four to six 2 TB disks Dual Quad 24

7.1. bra. Hardver mretezs ajnlsok 5-50 gpes cluster-ekhez

1

7.2. Opercis rendszer

Az opercis rendszert tekintve az sszes Hadoop disztribci UNIX-os krnyezetben

hasznlhat, ezekre lett alapveten kialaktva. Legtbbet hasznlt Linux disztribcik

Hadoop cluster-ekhez a RedHat, s a CentOS. Cges krnyezetben leginkbb az elbbivel

tallkozhatunk a legtbbszr, mg otthoni felhasznlk krben az Ubuntu, s klnb-

z Debian verzik az elterjedtebbek. Mivel nincs nagy klnbsg Hadoop szempontjbl

a klnbz opercis rendszerek kztt, ezrt ltalnos ajnls, hogy a tmogatsi id-

intervallum s a rendszergazdk tapasztalata alapjn rdemes OS-t vlasztani.

Ltezik emellett egy Windows Server szmtgpekre talaktott verzi is, amelyet jsze-

rsge s kisebb kzssgi tmogatsa miatt kockzatos lehet hasznlni.

7.2. bra. Hadoop futtatsra alkalmas opercis rendszerek

7.3. Hlzat

A j s alapos hlzati belltsok rendkvl fontosak, mivel ezek szoktk okozni a legtbb

problmt s furcsa hibajelensget telepts s zemeltets kzben. Emiatt fontos, hogy

minden szmtgpnek tudnia kell a sajt host nevt, IP cmt. DNS s reverseDNS-nek

hibtlanul kell mkdnie privt cmek esetn is, mert lteznek olyan feladatok, ahol a

Node-tl a rendszer megkrdezi a host nevt, s erre neki vlaszolnia kell tudnia, hiszen

egyb esetben mondjuk nem tud az a feladat lefutni, s rengeteg hibt kaphatunk.

A cluster ltalban bels hlzaton van, s nincs kls interfsze, teht csak a bels hln

rhet el. Erre a bels hlra pl. VPN-el szoks bejelentkezni, s gy hasznlhat a

cluster. Ennek az a clja, hogy a kls tmadsokat teljesen ki tudjuk szrni, s csak

akkor trhet fel a rendszer, ha valaki a bels hlra be tudott jutni.

1

http://hortonworks.com/ ajnlsa

33

ELADS 7. HADOOP KLASZTEREK KONFIGURCIJA S ZEMELTETSE

7.4. Disztribci

Mivel a Hadoop-nak sok cg ltal elksztett vltozata van, gy ezek klnbz egyb szol-

gltatsokkal vannak kiegsztve, s ms-ms feladatokra vagy akr platformokra vannak

optimalizlva.

A legelterjedtebb a Cloudera (CDH) ltal ksztett verzi, amely egy olyan komplex se-

gdszolgltatsokat nyjt programokkal, illetve webes fellettel rendelkezik, amelyekkel

nagyon knny kezelni az egyedi Node-okat, s a klnbz keretszolgltatsokat, ame-

lyek segtik a rendszer sszhangban val mkdst. Ezen fell vannak az Intel, Amazon,

Hortonworks ltal ksztett verzik is.

ltalban minden verzibl ltezik zets s ingyenes vagy akr nylt forrskd verzi is.

A zetsk leginkbb internetes tmogats megltben s pr egyb extra szolgltatsban

trnek el az ingyenes verziktl, s ltalban csak nagyvllalati krnyezetben hasznljk

ket az ruk miatt.

rdemes megemlteni mg, hogy termszetesen a Hadoop minden rsze letlthet az

Apache oldalrl is, de azok egyesvel trtn teleptse s kongurcija nagysgren-

dekkel nagyobb szakrtelmet s idt ignyelnek, mint egy disztribci hasznlata.

7.3. bra. Hadoop disztribcik

7.5. Feladatok temezse s kvtk hasznlata

MapReduce feladat esetn a FIFO alapelv feladattemez volt a legelterjedtebb, de

ez tl egyszer volt, s egy kis slotigny (slot - szabad kapacits) feladatnak is vrnia

kellett egy nagy slotignyre, ami igen sok vrakozst eredmnyezett a lekrdezst futtat

szmra. Ennek a kikszblsre talltk ki a Fair scheduler-t, amely lehetsget ad arra,

hogy a kisebb job-okat a nagyok kz be tudjuk szrni, ezltal cskken a vrakozsi id.

Lteznek slot pool-ok, amelyek lehetv teszik, hogy a slot-ok egy csoportjt pldul a

kisebb job-oknak fenntartjuk, gy a nagy job-ok a tbbi slot hasznlatval helyet hagynak

a kisebbek szmra.

Az zemeltets egy msik tipikus problmja, ha egy HDFS fjl mrete tvedsbl hatal-

masra n (pldul kt nagy fjl join-olsa miatt), s elfoglalja a helyet minden ms adat

ell. Ez ellen kvtk bevezetsvel lehet vdekezni.

34

8. elads

Hadoop 2.0 - YARN, Tez, Spark

8.1. Hadoop 2.0

8.1.1. Kialakulsa

A Hadoop 2.0-ban rengeteg j lehetsget s szolgltatst vezettek be, amelyek sokkal

knnyebb teszik az elosztott rendszerek hasznlatt, azok kezelhetsgt s feladatok

futtatst. A rendszer jragondolsnl az volt az elsdleges cl, hogy ne csak MapRe-

duce job-okat lehessen indtani, hanem ms tpus szolgltatsok s applikcik is gond

nlkl fussanak. Emellett a rgi rendszerben nem volt lehetsg klnbz csoportoknak

klnbz adathalmazokon dolgozni, elklntett elemzseket futtatni. Eddig a HDFS-en

erre csak a klnbz jogosultsgokkal val trols volt a lehetsges md.

8.1.2. Klnbsgek

A Hadoop 1.0-ban JobTracker-nl volt minden szerep, felgyelte az erforrsokat, osztot-

ta ki a feladatokat a DataNode-ok szmra MapReduce job-oknl, valamint monitorozta

a feladatok futst. Felismertk, hogy az erforrs menedzsmentet s az alkalmazsok

kezelst kln kell vlasztani. Emiatt az j YARN architektra kerlt kialaktsra (lsd

8.1. bra), ami gyakorlatilag egy j genercis MapReduce-t jelent. Az erforrsok ki-

osztsa s a feladatok temezse levlasztdik a JobTracker-rl, s a JobTracker szerep

feldaraboldik. gy kerltek bevezetsre a ResourceManager az ApplicationMaster szere-

pek.

A rgi TaskTracker-ek helyett NodeManager-ek vannak az egyes node-okon, amelyek fel-

adata a programkd futtatsa s a MapReduce kommunikcik felgyelete. A ResourceM-

anager a job futtatsa sorn kivlasztja, hogy melyik node-on helyezi el a feladat futtat-

srt felels ApplicationMaster szerepet, amelybl minden feladathoz kln pldny kerl

ltrehozsra. Az ApplicationMaster a ResourceManager-tl kapott informci alapjn kel-

l mennyisg ResourceContainer-t fog ignyelni, amely egy erforrs foglals a Map s

Reduce taskok szmra. A ResourceContainer-ek kommuniklnak az ApplicationMaster-

rel, s jelentik, hogy hol tartanak a feladat futtatsval. Az ApplicationMaster a job

futsa utn megsznik.

A korbbi gyakorlattal ellenttben az erforrs foglalskor a NodeManager-ek - a rgi

TaskTracker-ek slot s progress informcii helyett - szabad memria s CPU llapo-

tot kldenek vissza. Az alkalmazs futsrt az ApplicationMaster a felels, teht a

ResourceManager-nek nem kell a progress-t jelenteni.

35

ELADS 8. HADOOP 2.0 - YARN, TEZ, SPARK

Mivel a MapReduce job-ok mellett mr alkalmazsok is lehetnek, gy az ApplicationMa-

ster visszajelez, hogy melyik mdban indult el a bekldtt feladat. Pldul az HBase

szolgltats is a ResourceManager-en keresztl tudja elrni a cluster-t, gy a klnbz

folyamatok nem veszik el egyms ell az erforrsokat.

8.1. bra. Az j YARN rteg

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

8.1.3. YARN job futtats

Az j YARN rendszerben jelentsen megvltozott a rendszerben indthat feladatok fut-

tatsa. A 8.2. brn bemutatott mdon futtatja a rendszer a bekldtt feladatokat:

1. A kliens bekldi a feladatot a rendszernek az alkalmazs specikus ApplicationMa-

ster indtshoz szksges informcikkal egytt.

2. A ResourceManager eldnti, hogy melyik node-ra deleglja az ApplicationMaster

elindtsval s futtatsval jr feladatkrt.

3. Az ApplicationManager a ltrejtte utn bejelentkezik a ResourceManager-nl, aki

lehetv teszi a kliens szmra a kzvetlen kommunikcit az ApplicationMaster-rel.

4. A futs sorn az ApplicationMaster a resource-request protokoll segtsgvel meg-

felel ResourceContainer-eket foglal az alkalmazs futshoz.

5. A sikeres erforrs foglals utn az ApplicationManager a NodeManager szm-

ra elkldi a megfelel informcikat s adatokat, gy elindul a Container futta-

tsa. Ezek az informcik tartalmazzk azt is, hogy a Container miknt tud az

ApplicationManager-rel kommuniklni.

6. A Container elkezdni futtatni a programkdot, mikzben az applikci specikus

protokoll segtsgvel folyamatosan jelenti a feladat elrehaladtt, llapott.

7. Szintn az applikci specikus protokoll segtsgvel a feladatot bekld kliens az

ApplicationMaster-rel kommuniklva krdezi le a feladat sttuszt, illetve az azzal

kapcsolatos egyb informcikat.

8. Amikor a feladat elkszlt s minden szksges httrfolyamat lefutott, az Appli-

cationMaster trli magt a ResourceManager-nl, s lell. Ekkor a Container jra

felhasznlhat lesz.

36


8.2. bra. YARN job futtats

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

8.2. Tez

A Tez projekt ltrehozsnak clja az volt, hogy az j YARN rendszerhez egy forra-

dalmastott, gyorsabb, egyszerbb MapReduce megoldst nyjtsanak, amely cskkenti a

rendszer erforrs hasznlatt.

A korbbi MapReduce-ok mkdsi elve az volt, hogy minden Map s Reduce fzis kztt

a kztes adatok a HDFS-re rdtak ki (replikcival egytt), gy jelents I/O kapacitst

hasznltak el (klnsen tbb MapReduce job egyszerre trtn futtatsval). Ezt a Tez-

ben azzal kszbltk ki, hogy nem felttlen kell kln MapReduce job-okat ltrehozni az

adatok feldolgozsa sorn, hanem lehet ezeket batch-esteni (Map Reduce Reduce),gy nem kell mindig kzttk HDFS-t hasznlni, teht sprolhatunk az I/O kapacitssal.

Ezen kialakts elsdleges clja volt, hogy a Hive s a Pig-beli feladatokat egyetlen Ma-

pReduce job-bal valstsunk meg. A rendszer a feladatokbl itt is egy DAG-ot (krmentes

grf) alakt ki, s kszti el a futtats sorrendjt. Eltrs, hogy a Tez-ben a MapReduce-al

ellenttben nem kell ezt megadni, hogy hny Reduce feladatunk lesz, ezt a rendszer futs

kzben kioptimalizlja.

8.2.1. Eloszott rendezsi plda Tez-ben

A 8.4. brn lthat egy elosztott rendezsi plda, amely mdszerrel akr 10-szeresen

gyorsabb adatfeldolgozs rhet el. A korbbi egy Reduce job-tl eltren, itt 3 rszbl

ll a folyamat.

Az elfeldolgoz szakasz mintkat kld a Sampler-nek, amely az adatokat egyenletesen

elosztja rendezett tartomnyokra osztja. Ezek a tartomnyok a partcionl s aggregl

fzisba kerlnek, ahol a megfelel feldolgozk a sajt tartomnyukat olvassk be, s el-

vgzik az adatok sszefzst. Ez az adatfolyam egyetlen Tez feladat, amely elvgzi az

37


8.3. bra. Tez s a YARN kapcsolata

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

egsz szmtst.

8.4. bra. Tez elosztott rendezs

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

8.3. Impala

Az Impala egy Hive alternatvaknt jtt ltre annak rdekben, hogy egy egyszer lekr-

dezsre egy kisebb tbln ne kelljen 5-10 sec-et vrni. A megvalsts tisztn C s C++

alap, s az adatokat is cache-eli, ezrt jval gyorsabb, mint a Hive. A cache-els lnyege

ebben az esetben, hogy a mr korbban kiszmolt vagy futtatott lekrdezsek eredmnyt

memriban trolja, gy azokat nem kell minden esetben jra a HDFS-rl olvasni, ha

gyakran hasznljuk.

38


8.4. Spark

A Spark valjban egy memria alap MapReduce keretrendszer, amelyet szintn a

YARN-hoz fejlesztettek ki. Ez leginkbb iteratv szmtsokhoz idelis (pl. logisztikus

regresszi, neurlis hlk). Bizonyos adatokrl kdszinten meg lehet mondani, hogy le-

gyen cache-elve, teht akr az adathalmaz trolhat memriban a futs idejn, s csak

a vgeredmnyt rjuk HDFS-re.

A Shark a Spark rendszerhez nagyon hasonlan egy memria alap megolds, amelyet a

Hive futtatshoz terveztek.

8.5. Storm

A Storm egy valsidej, nem batchelt feldolgoz rendszer, amelyben topolgiba rend-

szerezhetnk forrsokat s feldolgoz egysgeket, amely folyam vgn kerl csak az adat

elmentsre a httrtrra vagy adatbzisba (lsd 8.5. bra). Ez a leggyakrabban olyan

felhasznlsi mdoknl jelent hatalmas elnyt, ahol azonnali jelentseket vagy vals idej

analzist kell kszteni. A feldolgoz egysgek lnyege, hogy azonnali szmolst vgeznek,

adattrolst egyltaln nem. Felhasznlsi pldk kz tartozik gyakori szavak, kulcs-

szavak keresse sok bejv rvid zenetben, amelyet azonnal kivezethetnk egy vals

megjelent felletre.

Ezek mellett termszetesen a trolt adatokon ksbb Tez-t vagy MapReduce-t is futtat-

hatunk a korbbi gyakorlatnak megfelelen.

8.5. bra. Storm topolgia

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

39

9. elads

Hadoop & NoSQL: HBase

9.1. Adatbzis-kezel rendszerek

Az adatbzis-kezel rendszereknek kt nagy csoportjt klnbztetjk meg, amelyek ssze-

hasonltsa a 9.1. tblzatban lthat.

OLTP

(On-line Transaction Processing)

OLTP

(On-line Analytical Processing)

Clja tranzakcikezels adatelemzs

Formja adatbzis adattrhz

Mveletek gyors, kis mveletek: SELECT,

UPDATE, DELETE, INSERT

komplex SELECT tpus lekrdez-

sek

Tervezs normalizlt forma (1NF, 2NF,

3NF, BCNF)

nem normalizlt, csillag sma:

egy f tbla s tbb hozz fz-

d kapcsoltbla

Technolgik standard SQL adatbzisok HBase, Accumulo, Cassandra

9.1. tblzat. OLTP vs. OLAP

ltalban megprbljuk a ktfle adatbzis-kezel rendszert elszeparlni akkor is, ha

ugyanazzal az eszkzkkel valstottuk meg ket. Ennek legfbb szerepe az erforrsok

kiosztsnl van, hiszen egy komolyabb elemzsi mvelettel nem szeretnnk a tranzakcis

adatbzist lebntani.

9.1.1. Elosztott adatbzis-kezel rendszerek

Az adatbzis kezel rendszerek egygpes krnyezetben viszonylag egyszeren elkszt-

hetek, de elosztott esetben szmos problmba tkzhetnk, amelyhez kapcsoldik a

kvetkez ttel:

CAP-ttel: egy-egy konkrt elosztott rendszer az albbi hrom alapvet kpessg kzl

legfeljebb kettt tud megvalstani:

Consistency (konzisztencia): mindig ugyanazt olvassuk ki, mint amit bertunk

Availibility (rendelkezsre lls): mindig kapunk vlaszt a krdsre

Parition tolerance (particionls-trs): mennyire viseli el a rendszer, ha valamilyen

okbl kifolylag sztesik tbb klnll rszre

40

ELADS 9. HADOOP & NOSQL: HBASE

A 9.1. brn lthat a klnbz adatbzis-kezel rendszereknek az sszefoglalsa a

CAP-ttel alapjn, hogy melyik kt kpessggel rendelkezik.

9.1. bra. CAP-ttel

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

9.2. NoSQL adatbzis-kezel rendszerek

A NoSQL adatbzisok nem relcis adatmodellt hasznlnak, hanem klnfle megoldsok

lteznek:

dokumentum alap: MongoDB

Ezek az adatbzis-kezel rendszerek legfkpp az aggregtum szmolsra, GROUP

BY-jelleg mveletekre vannak specializlva. Ms mveletet vagy nem is tudnak,

vagy nem hatkonyan tudnak elvgezni.

grf alap: Neo4j

oszlop alap: HBase, Cassandra

kulcs-rtk alap: DynamoDB, Riak

41


9.3. HBase

A Google 2006-ban publiklta a BigTable nev oszlop alap adatbzis-kezel rendsze-

rt. Clja, hogy a Google ltal hasznlt HDFS-hez hasonl fjlrendszeren sklzhatan

tudjanak adatokat trolni. Ennek mintjra kszlt az HBase, amelynek dencija a

kvetkez:

sparse: ritka, ugyanis az oszlopok rtkt nem ktelez mindig megadni s nem trol

klnfle NULL rtkeket, mint az SQL alap adatbzisok

consistant : konzisztens

distributed : elosztott, mivel az adatok HDFS-en elhelyezett fjlokban tallhatak

multidimensional : tbbdimenzis, azaz egy kulcshoz tbb oszlop (column) is tartoz-

hat s ezek oszlopcsaldokba (columnfamily) vannak rendezve, teht (columnfamily:

column) alapjn lehet rtket lekrni. Ezenfell trol mg timestampet is, vagyis

az rtkek verzizva vannak s mindig a legfrissebb kerl visszaadsra. (A konzisz-

tencinak felttele, hogy mindig legyen timestamp a beszrt rtkek mellett.)

sorted : rendezett, teht nem csak kulcs alapjn kereshet, hanem tartomnyt is

egyszeren le lehet krni

map: kulcs-rtk prok trolsa

A kvetkez mveleteket lehet elvgezni az HBase-ben:

put(kulcs: {'cf:c': rtk, 'cf:c': rtk, ...}): egy elem beszrsa

get(kulcs): egy kulcshoz tartoz rtkek lekrse

scan(kezdrtk, vgrtk): egy tartomny lekrse, illetve hasznlhat prex

keressre

delete(kulcs): egy elem trlse

A hasznlathoz vegynk egy webkeresses pldt, aminek a clja, hogy a klnfle URL-

ekhez adatokat mentsnk le. HBase-ben a kulcsot rowkey-nek szoktk nevezni, amely jelen

esetben az URL lesz. Mivel nagyon sok URL-hez kell adatot trolni, ezrt mindenkppen

szksg van valamilyen elosztott infrastruktrra. Az rtkek pedig a MIME-type, nyelv,

tartalmazott szveg, stb. lesz, amely a oszlopok szabad felhasznlhatsgbl addan

brmikor bvthet s szabadon kihagyhat.

Mivel az HBase-nek nagyon kicsi a ksleltetse, ezrt a klnfle modulok (crawlerek)

nagyon gyorsan tudnak lekrdezni. Minden vltoztats atomi, teht nem fogjk blokkolni

egymst s nem okoz problmt az sem, ha kt klnbz modul ugyanazt a rowkey-t

akarja fellrni. gy kaptunk egy nagyon jl sklzd, kis ksleltets adatbzist, amelyet

(cserbe) csak URL alapjn tudunk elrni, de ehhez a felhasznlshoz ez pont elg.

Egy columnfamily kerl egy HDFS fjlba, teht ha egy rowkey-hez tbb columnfamily

tartozik, akkor tbb fjlbl kell az rtkeket kiolvasni. Oszlop alap adattmrtst hasz-

nl az HBase, de hasznlhat a rendszer key-value adatbzis felfogsban, amelybl ltszik,

hogy nincs les hatr a kt tpus adatbzis-kezel rendszer kztt.

42


9.3.1. Mkdse

HDFS fltt fut, de nem MapReduce alapokon, hiszen tudjuk, hogy a MapReduce-nak

msodperces nagysgrend ksleltetse van, mg a NoSQL rendszerek ms-os vlaszidveldolgoznak. Felptsben hasonlt a HDFS s a MapReduce struktrra, hiszen Master-

Slave architektrra pl ahogyan azt a 9.2. brn lthat.

9.2. bra. HBase felptse

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

Van egy HBase master s vannak klnbz rgiszerverek. Ezek kln szolgltatsknt

futnak a Hadoop clusteren, teht teljesen fggetlenek a MapReduce keretrendszertl. Mi-

vel az adathalmazunk rendezett, ezrt a rgiszerverek a kulcs szerint vannak felosztva,

teht minden rgiszervernek van egy kulcstartomnya (start_key stop_key), amit az

kezel. Ha a kliens le akar krni egy rtket kulcs szerint, akkor elszr a master meg-

mondja, hogy melyik rgiszerverhez tartozik s utna attl a rgiszervertl fogja elkrni

az adott elemet s bers is hasonlan mkdik. Ahhoz, hogy a rendszer valban ms-osnagysgrendben futhasson, a kliensek cash-elik, hogy a rgik hogyan oszlanak el. Ha ez

a feloszts valami miatt megvltozik, akkor az adott rgiszerver vlaszol, hogy ez a kulcs

nem hozz tartozik s akkor fordul jra a masterhez a kliens. A master elg kicsi szerepet

kap a rendszerben, mivel csak a kezdeti krseket kell kiszolglnia, illetve az jraszervezsi

feladatokat kell neki elvgeznie. A nagy terhels a rgiszerverekre jut.

A felptsbl mr jl ltszik, hogy a rendszer mirt nem ll mindig rendelkezsre. Ha

egy rgiszerver kiesik, akkor az tartomnya aktulisan kiszolglatlan lesz addig, amg

a master ezt szre nem veszi (nem rkezik heartbeat). Ezutn kiosztja ms rgiszer-

vereknek ezt a tartomnyt, aki meg fogja tallni a HDFS-en az ehhez a rgiszerverhez

tartoz fjlokat, de gy vannak olyan tmeneti idszakok, amely alatt bizonyos rekordok

nem elrhetek. A particionls-trs viszont teljeslni fog, hiszen ha a cluster sztesik

tbb rszre akkor is adott rgiszerverek a hozzjuk tartoz krseket teljesteni tudjk.

gy a rendszer tovbbra is mkdni fog, termszetesen a HDFS replikcit nem biztos,

hogy vgre tudja hajtani amg a teljes cluster jra ssze nem kapcsoldik.

Ahhoz hogy a krsek minnl elbb ki legyenek szolglva a rgiszerverek folyamatosan

nyitva tartjk a HDFS fjlokat, amik hozzjuk tartoznak s ltalban replikkat is igyek-

szik a rendszer gy elhelyezni, hogy legyen a rgiszerven egy loklis replika a hozz

tartoz blokkokbl. A rgiszerver ezekbe a fjlokba nagyon gyorsan bele tud indexelni

s visszaadni a megfelel rtket. Ezen fell az adatok nagy rszt memriban tartjk,

teht ezrt fontos a sok memria az HBase-t kiszolgl zikai gpekbe. (Vessk ssze

43


a 7.1. brn tallhat Slave-hez tartoz Balanced workload s HBase cluster rtkeket.)

Az adatok bersnak folyamata

Az HBase rsi folyamata a 9.3. brn lthat szekvenciadiagram szerint trtnik.

9.3. bra. HBase vltoztats rsi folyamata

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

Inicializlskor a kliens megkrdezi a master-t, hogy melyik rgiszerverhez kell fordulnia,

ha ez mg ezeltt nem trtnt meg. Egy kulcsot s a hozz tartoz rtke(ke)t szeretn

a kliens beszrni vagy trlni (). A rgiszerver elszr a vltozst berja a commit

log-ba (), ami a loklis diszken troldik, hogy adatvesztsnk ne legyen. Ezutn kerl

be a memstore-ba, ahol a rgiszerver trolja a vltozsokat s kveti azok verziit ().

Amikor ez a memstore kezd betelni, akkor a commit log-nak egy rendezett formjt

HDFS-re rja (). A commit log s a memstore rsa nagyon gyors s utna visszatr a

parancs (), mg a HDFS-re rs mr aszinkron mdon hajtdik vgre. gy esetleges hiba

esetn, ha visszatr a rgiszerver, akkor a commit log-bl jra fel tudja pteni a hinyz

mdostsokat. Ebbl kvetkezik, ha rgiszerver tbbet nem tr vissza, akkor azok a

vltozsok elvesznek, amik HDFS-re nem kerltek t.

9.3.2. HBase adatszervezsi plda

A legfbb krds: Hogyan vlasszuk meg a kulcsokat? Ehhez elszr is meg kell vizsgl-

nunk, hogy milyen lekrdezseket szeretnnk futtatni. Egy pldn keresztl vizsgljuk

meg, hogy milyen szempontokra rdemes odagyelni.

Tegyk fel, hogy idjrsi adatokat gyjtnk. Vannak idjrs llomsok, amelyekhez

timestamp-et s mrsi adatokat szeretnnk letrolni. A lekrdezseinket arra szeretnnk

optimalizlni, hogy a leggyorsabban kapjuk vissza az adott idjrs llomshoz tarto-

z legfrissebb mrt adatokat. Ebben az esetben trivilisnak tnik, hogy vlasszuk az

lloms+timestamp-et kulcsnak. De ez ebben az esetben nem a legoptimlisabb megol-

dst adja, ugyanis a keressnl mindig vgig kell nzni az sszes adott llomshoz tartoz

adatot amg elrjk az utolst.

Erre azt a megoldst szoktk alkalmazni, hogy egy tvoli jvbeli idpontbl kivonjk

az aktulis timestamp-et, ezzel megfordtva annak nvekv voltt. Ha gy futtatjuk le a

keresst, akkor els elemknt az llomshoz tartoz legfrissebb adatokat kapjuk meg.

44

A. fggelk

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 dierent techniques that can be found on the web or scientic articles.

Several practical case studies are also provided. All descriptions and code snippets use the

standard 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

FGGELK 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 set

of terms. It is required to calculate a total number of occurrences of each term in all

documents. Alternatively, it can be an arbitrary function of the terms. For instance, there

is a log le where each record contains a response time and it is required to calculate an

average response time.

Solution: Let start with something really simple. The code snippet below shows Mapper

that simply emit 1 for each term it processes and Reducer that goes through the lists

of 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 emitted

by the Mapper. The Mapper can decrease a number of counters via summing counters

for 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

FGGELK A. MAPREDUCE PATTERNS, ALGORITHMS, AND USE CASES

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 is

required to save all items that have the same value of function into one le or perform

some other computation that requires all such items to be processed as a group. The

most typical example is building of inverted indexes.

Solution: The solution is straightforward. Mapper computes a given function for each

item and emits value of the function as a key and item itself as a value. Reducer obtains

all 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 records

that meet some condition or transform each record (independently

Documents

BigData_-_Eloadasjegyzet