Grunt

der dokumentarischen vollständigkeit halber:

hatte im rahmen von dem semibigdata-kurs der university of washington auf coursera gestern und heute das erste mal handkontakt mit ec2 resp. elastic mapreduce (amazon’s infrastruktur für mapreduce/hadoop).

—

vorbereitend muss man

(a) ein account anlegen, da beginnt man hier und klickt sich durch (man kann ein bestehendes amazon account verwenden, man muss aber auch für den free tier eine kreditkarte angeben und eine telefonnummer via pin verifizieren).

(b) für jede aws-zone, die man verwenden möchte, ein key pair für ssh generieren. den privaten key bewahrt man als keyname.pem lokal irgendwo auf.

zum anlegen eines clusters für elastic mapreduce

(1) geht man dann zur management console,
(2) klickt auf ‘create cluster’ und ändert dort ggf. die defaults (wenn man nicht weiß, was man tut, lässt man sie am besten wie sie sind)
(3) definiert unter ‘hardware configuration’ die art und anzahl an ec2 instanzen, die man gerne hätte (einen master node + x core oder task nodes)
(4) verbindet unter ‘security and access’ den oben generierten key
(5) klickt nochmal auf ‘create cluster’ und wartet, bis sich auf der nächsten seite der status von ‘starting’ in ‘running’ ändert. dort sieht man neben ‘master public dns’ dann auch die adresse vom cluster (in richtung ec2-xxx-xxx-xxx-xxx.yyy.compute.amazonaws.com).

und 5 minuten später hat man einen laufenden cluster mit bis zu 20 nodes. mit

ssh -o "ServerAliveInterval 10" -i keyname.pem ec2-xxx-xxx-xxx-xxx.yyy.compute.amazonaws.com

kann man dann ein terminal zum cluster öffnen, mit

ssh -L 9100:localhost:9100 -L 9101:localhost:9101 -i keyname.pem hadoop@ec2-xxx-xxx-xxx-xxx.yyy.compute.amazonaws.com

kann man den cluster und die laufenden hadoop jobs im lokalen browser der wahl monitoren.

mit dem ‘terminate’ button in der ‘management console’ kann man den cluster dann wieder terminieren, abgerechnet wird nach angebrochener stunde der eingesetzten instanzen, siehe die preisliste (nur als ballpark: mit 5-10 euro kann man schon einen cluster mit grösserer hardware starten und locker ein TB prozessieren, einen 10-node cluster mit kleinsten maschinen kann man schon für 15c/h betreiben).

unterm strich schon irre, wie leicht es also auch für administrative dummies ist, die finger auf rechenkapazitäten zu bekommen, vor allem wenn man die daten schon irgendwie in S3 hat, die scheinen mir der grösste flaschenhals zu sein; das terminal muss man allerdings wohl trotzdem gesehen haben und an pig als abstraktion für hadoop muss man sich wohl heranarbeiten.

—

nts ein paar gängige commands rund um hadoop/pig:

hadoop fs -mkdir /user/hadoop

legt auf dem cluster das verzeichnis für das HDFS file system an.

hadoop fs -getmerge /user/hadoop/job1 job1

merg’t und kopiert das ergebnis eines mapreduce jobs ins lokale verzeichnis des clusters.

scp -o "ServerAliveInterval 10" -i keyname.pem hadoop@ec2-xxx-xxx-xxx-xxx.yyy.compute.amazonaws.com:/home/hadoop/job1 .

kopiert dieses file dann auf den eigenen rechner.

pig
grunt>

mit pig kommt man ins pig prompt grunt.

grunt> raw = LOAD 's3n://uw-cse-344-oregon.aws.amazon.com/btc-2010-chunk-000' USING TextLoader as (line:chararray);

^ die zu prozessierenden daten kann man zb direkt aus S3 laden

wget http://uw-cse-344-oregon.aws.amazon.com.s3.amazonaws.com/btc-2010-chunk-000
hadoop fs -copyFromLocal btc-2010-chunk-000 /user/hadoop/btc-2010-chunk-000
pig
grunt> raw = LOAD '/user/hadoop/btc-2010-chunk-000' USING TextLoader as (line:chararray);

^ oder man importiert sie zuerst ins HDFS.

grunt> store hadoop_object into '/user/hadoop/job1' using PigStorage();

speichert das ergebnis im HDFS.

wenn man auf S3 ein bucket angelegt hat, kann man das ergebnis des hadoop jobs auch direkt in S3 schreiben (was natürlich nützlich ist, wenn man cluster nach bedarf startet und stoppt):

grunt> store hadoop_object into 's3n://bucketname/job1';