Hadoop on docker 後編
前回は既存のコードからHadoopのコンテナを動かすところまで書きましたが、今回はそれに手を加えて複数ノードで動くようにしました。
少し試行錯誤してたので、ソースだけ置いて要点だけ書いて行きます。
showyou/hadoop-docker at multinode · GitHub
まずDockerのパッケージを作るのは、Dockerfileになります。なのでいつも共通の設定とか初期設定はここに書いて行きます。bootstrap.shは毎回起動する度に呼ばれるファイルになっています(ただしbootstrap.shは今回指定して読んでいるだけで、dockerの決まりでは無いと思います)。また今回はNameNode/ResourceManager側とDataNode/NodeManager側でディレクトリを分けました。
作っていった手順ですが、まずsequenceiq/hadoop-dockerイメージを複数立ち上げて、そこで環境をいじって複数ノードで立ち上がるようにしました。次にdockerのソースに戻って同じように動くように変えて行きました。今回はgithubで公開するためこんな回りくどいことをしています。しかし手元の環境で使う場合は、動作した環境に対しdocker commitコマンドを実行することでdockerイメージが作成できます。dockerイメージは差分管理されるのでVMのスナップショットよりも容量が少なくて済むようです。
細かい変更点としてはここ(https://github.com/showyou/hadoop-docker/compare/multinode)を見てもらえればわかります。
core-site.xml, yarn-site.xml, hdfs-site.xmlにNameNode / ResourceManagerを指す設定を付け加えています。擬似分散では自動的にlocalhostを見ればよいですが、完全分散では明示する必要があります。またstart-dfs.sh / start-yarn.shはNameNodeマシンから(恐らく)slavesファイルを通して呼ばれるので、DataNode側から呼ばないようにしています。先ほどのxmlファイルをDataNode等が立ち上がる前にばら撒く必要もあります。
DataNodeは複数立てられます。詳しくはgithubリポジトリのReadmeに拙い英語で手順を書いているので読んで貰えればと思います。わからなければ日本語で書きます。
以上、車輪の再開発を泥臭くやっていきました。ここで言いたいのは、Hadoopのインストール作業は(パラメータチューニングは別途あるものの)この程度で出来るものであり、とても難しいソフトウェアとか神聖視とか構えないで欲しいということです。YARNの挙動管理は大変かもしれませんが・・
今年嬉しかったこととして、これまでデータ分析や大量のデータに興味がなかった方たちが取り組み始めたということがあります。今後彼らを引き上げていく役目になれれば嬉しいと考えています。
あと日本はまだその兆しが無いですが、少しずつHadoop/Sparkシステム(俗に言うデータレイクシステム)単体だけでなく、Hadoopの構成管理の方にまで注目が移ってきてきています。前回の最後に上げたPivotal HD for Pivotal Cloud Foundryなどもそうですが、他にもHortonworks + Openstackとか(HortonworkもCloudFoundryの一員ですね)もあります。また私が紹介することなのか、って感じもしますが、巨人も少しずつ動きつつあります(
IBM Big SQL Benchmark vs. Cloudera Impala and Hortonworks Hive/Tez | Sheffield View , オマケでPivotal HAWQ vs Cloudera Impala も置いときます)。
Hadoop on docker 前編
後半書きました( Hadoop on docker 後編 - White scenery @showyou, hatena )
書き忘れていましたが、この記事
Spark, SQL on Hadoop etc. Advent Calendar 2014 - Qiita の23日目になります。
はじめはPivotal社の商用SQL on HadoopであるHAWQの話でもしようかと思いましたが、先日掲載したスライドに大体書いているので読んで頂ければと思います。
今回はHadoop on Dockerについてでも話します。
最近はHadoopを動かすのにdockerを使う動きが出ています。
dockerで組み上げるメリットとしては、
1. VMに比べると速度が速い(と考えられる)
2. 各社配布しているVMと違いDockerfile辺りを見れば何やってるか理解できる
3. imageを管理すれば独自カスタマイズしたノードを容易に複製できる
等のメリットがあります。
実際日本ではあまり話が出てこないですが、sequenceiq(*1)(*2)とかferry(*3)とかプロジェクトが出てきています。
(*1)http://blog.sequenceiq.com/blog/2014/04/04/hadoop-docker-introduction/
(*2)http://blog.sequenceiq.com/blog/2014/12/02/hadoop-2-6-0-docker/
(*3)http://ferry.opencore.io/en/latest/
もちろんベアメタルにガチガチで作るのに比べると速度は多少低下します。随時Hadoop基盤を置いて共有ストレージとして使ってる環境には向かないと考えています。ただし一時的に大規模な計算ノードが必要になった場合には威力を発揮するでしょう。
ここでは最近出たHadoop 2.6のイメージをビルドする話をしていきます。
まずdockerコンテナのソースを入手して、ビルドします。
ここでgitdirはgitのソースを置くリポジトリとします。別に任意の名前で構いません。
gitdir$ git clone https://github.com/sequenceiq/hadoop-docker.git
gitdir$ cd hadoop-docker
gitdir/hadoop-docker$ docker build -t showyou/hadoop-docker:2.6.0 .$ docker build -t showyou/hadoop-docker:2.6.0 .
Uploading context 214 kB
Uploading context
Step 0 : FROM sequenceiq/pam:centos-6.5
Pulling repository sequenceiq/pam
7b5528f018cf: Download complete
89b52f216c6c: Download complete
0dd5f7a357f5: Download complete
ae2537991743: Download complete
b38f87063c35: Download complete
36bf8ea12ad2: Download complete
c605a0ffb1d4: Download complete
0bd9464ce7fd: Download complete
---> 7b5528f018cf
Step 1 : MAINTAINER SequenceIQ
---> Using cache
---> 461f4086bb21
Step 2 : USER root
---> Running in fd63870d472f
---> e8c116080601
Step 3 : RUN yum install -y curl which tar sudo openssh-server openssh-clients rsync
---> Running in aab6affb5030
Loaded plugins: fastestmirror, keys, protect-packages, protectbase
Determining fastest mirrors
* base: ftp.tsukuba.wide.ad.jp
* extras: ftp.tsukuba.wide.ad.jp
* updates: ftp.tsukuba.wide.ad.jp
0 packages excluded due to repository protections
Setting up Install Process
Package 2:tar-1.23-11.el6.x86_64 already installed and latest version
Resolving Dependencies
--> Running transaction check
---> Package curl.x86_64 0:7.19.7-37.el6_4 will be updated
(以下省略)
勝手にrpmとか落としてインストールしてくれます。中で何やってるかはDockerfileを見て貰えればわかるかと。
また、次のコマンドでhadoop コンテナを立ち上げます。
docker run -i -t showyou/hadoop-docker:2.6.0 /etc/bootstrap.sh -bash
/hadoop-docker$ docker run -i -t showyou/hadoop-docker:2.6.0 /etc/bootstrap.sh -bashStarting sshd: [ OK ]
Starting namenodes on [2e6612174160]
2e6612174160: starting namenode, logging to /usr/local/hadoop/logs/hadoop-root-namenode-2e6612174160.out
localhost: starting datanode, logging to /usr/local/hadoop/logs/hadoop-root-datanode-2e6612174160.out
Starting secondary namenodes [0.0.0.0]
0.0.0.0: starting secondarynamenode, logging to /usr/local/hadoop/logs/hadoop-root-secondarynamenode-2e6612174160.out
starting yarn daemons
starting resourcemanager, logging to /usr/local/hadoop/logs/yarn--resourcemanager-2e6612174160.out
localhost: starting nodemanager, logging to /usr/local/hadoop/logs/yarn-root-nodemanager-2e6612174160.out
bash-4.1#
更にHadoopのサンプルjarファイルを実行して動かしてみます。
bash-4.1# cd $HADOOP_PREFIX
bash-4.1# bin/hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-examples-2.6.0.jar grep input output 'dfs[a-z.]+'
14/12/20 18:26:04 INFO client.RMProxy: Connecting to ResourceManager at /0.0.0.0:8032
14/12/20 18:26:04 WARN mapreduce.JobSubmitter: No job jar file set. User classes may not be found. See Job or Job#setJar(String).
14/12/20 18:26:04 INFO input.FileInputFormat: Total input paths to process : 31
14/12/20 18:26:05 INFO mapreduce.JobSubmitter: number of splits:31
14/12/20 18:26:05 INFO mapreduce.JobSubmitter: Submitting tokens for job: job_1419117382790_0001
14/12/20 18:26:05 INFO mapred.YARNRunner: Job jar is not present. Not adding any jar to the list of resources.
14/12/20 18:26:05 INFO impl.YarnClientImpl: Submitted application application_1419117382790_0001
14/12/20 18:26:06 INFO mapreduce.Job: The url to track the job: http://2e6612174160:8088/proxy/application_1419117382790_0001/
14/12/20 18:26:06 INFO mapreduce.Job: Running job: job_1419117382790_0001
14/12/20 18:26:11 INFO mapreduce.Job: Job job_1419117382790_0001 running in uber mode : false
14/12/20 18:26:11 INFO mapreduce.Job: map 0% reduce 0%
14/12/20 18:26:18 INFO mapreduce.Job: map 10% reduce 0%
...bash-4.1# bin/hdfs dfs -cat output/*
6 dfs.audit.logger
4 dfs.class
3 dfs.server.namenode.
2 dfs.period
2 dfs.audit.log.maxfilesize
2 dfs.audit.log.maxbackupindex
1 dfsmetrics.log
1 dfsadmin
1 dfs.servers
1 dfs.replication
1 dfs.file$ bin/hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-examples-2.6.0.jar pi 4 100
Number of Maps = 4
Samples per Map = 100
Wrote input for Map #0
Wrote input for Map #1
Wrote input for Map #2
Wrote input for Map #3
Starting Job
14/12/20 18:30:43 INFO client.RMProxy: Connecting to ResourceManager at /0.0.0.0:8032
14/12/20 18:30:43 INFO input.FileInputFormat: Total input paths to process : 4
(中略)
WRONG_MAP=0
WRONG_REDUCE=0
File Input Format Counters
Bytes Read=472
File Output Format Counters
Bytes Written=97
Job Finished in 16.146 seconds
Estimated value of Pi is 3.17000000000000000000
ctrl+Dとかでbashを抜けるとcontainerも自動的に止まります。戻る場合はdocker ps -aしてdocker start <ID>でも実行してください。
containerを消したくなったら、
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
2e6612174160 showyou/hadoop-docker:2.6.0 /etc/bootstrap.sh -b 47 minutes ago Exited (0) 18 seconds ago compassionate_bohr
...
$ docker rm 2e6612174160
で消えます。
次にferryを使ってみます。
なんか2014/12/23時点のferryはdockerの1.2.0以降が必要で、Ubuntu 14.04だとアウトなのでdocker社の最新入れます。https://docs.docker.com/installation/ubuntulinux/の「Docker-maintained Package Installation」に書かれてるものを実行してください。
ferryはpythonのパッケージ管理システムpipをインストールしておく必要があります。
sudo apt-get install python-pip(Ubuntu)なりsudo yum install python-pip(CentOS)なり実行しておいてください。Ubuntu14.04のpipはバグがあった気もするので、その場合はeasy_install経由で入れてみてください。
まずferryを入れます。
$ sudo pip install -U ferry
$ sudo ferry install
$ sudo ferry server
いろいろdocker イメージを落としてくるので容量を食うので注意して下さい。
インストールし終えたら、セットアップ用のyamlを作ります。
backend:
- storage:
personality: "hadoop"
instances: 2
layers:
- "hive"connectors:
- personality: "hadoop-client"
これで
$ ferry start hadoop
とやるとhadoopクラスタが起動するはずです。"はず"って書いてるのは手元の環境では"com error, trying again..."とか出ている為です。
今回は他のところにあるdockerイメージをビルドして使うのにとどまりました。
後半は初めに使ったsequenceiq/hadoop-dockerをいじって、2nodeにインストールすることを考えます。
ここでは
1. Namenode / Resourcemanager
2. Datanode / Nodemanager
くらいに分けます。
この構成で2のイメージを複数箇所でボンボン立てれば、性能はともかく大量のHadoopノードを作ることができます。NamenodeHA化しろよって感じですが、それは省くんで誰かやってください。
また、この辺りを作るのもダルい、Hadoopを社内サービス化として管理できないか？ ・・といった話に対しては、Pivotal Cloud Foundry + Pivotal HD on PCFをお使いください(宣伝)。
Cloud Foundry Foundationが設立されました
40社あまりが創立に参加しCloud Foundry Foundationを立ち上げ…Linuxからも積極賛助へ - TechCrunch
Cloud Foundryっていう、乱暴に言ってしまうとHerokuみたいなのを自社環境に立てられるツールがあります。元々vmware->Pivotal社で作っていて、それをOSSにしてIBM(Bluemix), HP, SAP, NTT(Cloudn),楽天(RPaaS), docker等が参画していました。それが今回のFoundation立ち上げにより、
が表明されました。
2ですが、日本でもかなりインパクトが大きいでしょう。憶測ベースになりますが、東芝、富士通はご存知大手電機メーカーですが、彼らもPaaSを中心にして新しい開発体制を築いていくのでしょう。HortonworksはHadoopのオープン部分を作っている最も重要な会社の一つで(http://d.hatena.ne.jp/hamano3/20131218)、YahooのHadoop開発部隊が独立して作った会社です*1。
来年のPaaSは今年よりも大幅に盛り上がって行きそうです。
Japan.R参加報告と質問への解答
先週土曜日、Japan.Rでパネルディスカッションの一人として参加しました。割とトークグダグダでしたが、みなさんから山ほどの反応を頂いて感謝しております。
japan.R始まったばかりの頃は学術系もしくは広告系の人が多かった気がしますが、今回は思いの外エンジニアが多くてびっくりしました。もうちょい"私はR使いだし、pythonに乗り換える理由なんてない"とかDisってもらってもよかったのですが。
いくつか面白い質問を頂きましたが、時間の都合答えられなかった部分もあるのでここで答えます。
Q: 今Rエンジニアだが、今後他の言語覚えていかないと食えなくなると思っている。どの言語を覚えていけばよいか？
その場ではpigとかhiveとか答えましたが、実際はその都度必要になった言語覚えればいいと思います。ビッグデータ処理基盤ならJava*1とかScala*2とかpython*3とか、高速に大量のリクエスト処理したければgo*4とか、単体で高速に計算したければjuliaとかFortranとかGPGPU(CUDA, OpenCL)とか・・
逆に言うと、残念ながら何か覚えとけば安泰ってもんでも無い気がします。
あと全然関係ないですがどこかの偉い人がプログラミング言語は5つの違うパラダイムのものを覚えるべきと言っていました。すなわち手続き型1つ、関数型1つ、等を覚えろと言っています。
そこまでいくのも辛いと思うので、一つ言語極めて、いくつか周囲の言語を軽く触ってみるのはいかがでしょうか。それとコメントしたとおり、身近に詳しい人がいると覚えやすいです。
あと英語は覚えたら得するでしょう。ドキュメントは英語で書かれてること多いので。
Q: SparkもApache Stormもオンメモリで処理するものだが、リアルタイム解析はどちらが向いてるか？
この辺より詳しい方が答えて頂ければと思いますが、Sparkはメモリ上で高速バッチ処理、Stormは常駐して逐次処理を行うものです。ただしSparkもSpark Streamingとかいう超高速応答を返すものを持ってるので区別するのは難しいです。
なお追加の質問で「どっちがRedisに近いか？」というのも受けましたが、自分ならGemfire(商用インメモリKVS.永続化対応。SQLやHDFSが扱えるものもある)を推すかなぁ。。(手前味噌
Q: HBaseとCassandraの違いはなにか？
どちらも列志向型KVSですが、前者はHadoopの1部品であるのに対し、後者は独立しています。詳しくはこちらhttp://www.slideshare.net/yutuki/cassandrah-baseno-sql (ただしこの資料のHBaseで書かれているHDFSのSPoFは、今は存在しません)
Q: これからHadoopを始めたいが、コンポーネントが多すぎる。どこから手をつければいいか？
基本的にHDFS(Namenode, Datanode), YARN(ResourceManager, NodeManager, HistoryServer)くらいあればいいかと。HDFSはファイルの管理に使うもの、YARNはアプリケーションの実行に使うものです。個別にアプリケーションを書くのも辛いんで、あとはhiveとMapReduceでも入れてhiveSQL回しとけばいいと思います(投げやり)。もしくはSparkをスタンドアロンかEC2の上で回すといいでしょう。この辺はやまかつさん(@yamakatu)が詳しいと思います。もし具体的に聞きたいようであれば、@showyouにでも連絡してください。仕事なんでじっくり答えます。
Q: MapReduceはオワコン(でこれからはBigQueryの時代)と言われていたが本当なのか？
半分本当で、半分ウソです。
まず現行のHadoopはMapReduceを中心に動いてるのではなく、YARNと呼ばれるジョブリソース管理エンジンによって動いています。MapReduceはYARNで動く1アプリケーションになっています。
そしてhiveはMapReduceで動いていますが、それに取って代わりSQL on HadoopというYARNの上で動くものが台頭してきています。これやBigQueryの発想の根底にあるのは(恐らく)GoogleのDremelあたりの論文がベースになっています。
そういう意味では本当なのですが、YARNはYARNでアプリケーションを書くのが難しかったりするので、MapReduceのままでいい！って人もいます。
#ingadv2014 ingress 散歩部について
この記事は #ingadv2014 6日目のエントリーです。
showyouです。ingressアカウントもshowyouで、Enlighted(緑)のA14です。
(余談ですがingressアカウントと他のネットアカウントを一致させるのは好ましくありません。日頃のingress位置情報とネット上の活動から活動を推測されます。ちなみに私はあとで名前を変更しようとしましたが、拒否されました・・)
一時期は周辺地域を緑化して回っていましたが、敵味方が相当増えて一日で何回も色が反転するようになったため、諦めました。最初4人で立てた地元コミュニティも数十人を超えています。
一方で、ingressで比較的達成されていない実績でも目指そうかと思いました。それがUPV(Unique Potal Visit, ポータルを訪れた個所数)です。
ここで、いい加減ですが散歩部とかいうものを提唱してみようかと思います。
散歩部の活動としては、
- 新しいとこに行く
- ハックする
これだけです。たまに余裕があれば破壊＆ビルドもします。
散歩部のメリットとしては以下の事が挙げられます。
- ただハックするだけなんでレベルに関係無くできますし、インベントリ不足に悩まされることもありません(xm切れでハックできなくなるのだけ注意。リサイクルすればいいんですが)
- 緑とか青とかのしがらみから開放されます(ただハックするだけなんで)
- ingressをしに行くのではなく、旅行をするついでにハックするんであとで「オレ、何やってたんだろう・・」という無気力から逃れることができます
デメリットとしては、特定の場所を回るわけではないのでポータルキーが不足し、CFを作りにくくなります。まあもともとすぐ壊されるのでいいのですが。。あと当たり前ですが旅費がかかります。
UPVは、今(2014年12月)時点ではもう少し増えてるかと思いますが、少し前はA16のエージェントでも2000程度でした。私は5000強です。恐らく日本の人でUPV10000ってのもそうそういないと思うので、10000目指したいと思います。
あと最近は各地にポータル立ってるので密集地狙っていく必要もないかと思いますが、たまにポータルが固まって存在する地点があります。ingress.com/intelで探すとたまに固まってるとこ見つかりますし、コミュニティで聞くと教えてくれることもあるでしょう。東京は数が多すぎて紹介できないですが、京都とか名古屋とか台北は人工の割に密集してた感じです。
明日のingress advent calendarはsoheiさんによる「痩せないingress」のようです。ちなみに私も痩せてません。。
今月の活動
DB Tech Showcaseでの発表
Pivotal 社員が発表していました。
[db tech showcase Tokyo 2014] D36: 次世代分析基盤 "Data Lake" を支えるPivotalのインメモリ+SQL on Hadoopテクノロジー by Pivotalジャパン株式会社 市村友寛 & 宵勇樹 from Insight Technology, Inc.
なおHAWQの性能に関しては次のページにあるようです(SIGMODという学会に提出した物になります)
http://www.pivotal.io/sites/default/files/SIGMODMay2014HAWQAdvantages.pdf
Pydata Tokyo #2
http://pydatatokyo.connpass.com/event/9923/
初回は別の用事が前後にあったので断念し、今回はじめて参加しました。
前回はDeeplearningの実用編だったらしく結構敷居が高かったようですが、今回はAmazon Kinesisの話とPydata NYCの参加レポートだったので特にむずくはなかったと思います。マサカリ(ツッコミ)は激しかったですが(笑)
予告
今週末のJapan.Rで言語ディスカッションのパネラーとして参加します。
Python, Hadoopと書いてますが、Hadoopは時間の都合上別のイベントに回すかここでの公開になりそうです。
既に満員キャンセル待ちとなっていますが、学生の方には補助席を用意しているようなのでよければどうぞ。
DBのコミュティが盛り上がらないというか、ITで考えることが減ってるんじゃ
日本のデータベース系のコミュニティ、なぜイマイチ盛り上がらないのか - kuenishi's blog
uenishiさんが書いた記事が、個人的にも結構納得できる内容だったので、自分の意見も書いておく。ただし自分はコンピュータ周りの知識は独学で、どっちかというと機械学習とかHadoopとかの方が好きなんで意見の方向は違うかもしれません。
基盤の中心になる要素が弱いってのは確かにあって、例えばHadoopにおいても自分たちでパッチ投げまくったり実装してるのも数社しかみかけません*1。あまり大手SIerさんで独自改良してる話を聞きません。そもそもHadoop触ってないってとこも多そうですが・・
この辺データサイエンティストが少なめなのも含めて、同じとこに理由がある気もします。
理由としては、仕事をする上で、技術的・科学的に考えずにやってしまうことが多いのではないでしょうか。勘と経験と度胸ってやつで。DB=ブラックボックスと考えて、内部の挙動まであまり考慮しない。データサイエンス系で言うと科学的に分析せず、過去良かったからいいだろうとしか見ない。
一つ対処方法としては、アカデミックと現場で人を行き来させることでしょうか。一部自分の観測範囲での先生が社会人を呼んで講演しているようですが、そんな感じで。あとまあ箱を用意する段階とかきれいな研究室環境とかと、実運用するときの環境は汚さがぜんぜん違うよねー、大学と職場で共同で検討できるといいよねーとか感じます。
