2012/2/8のHadoopソースコードリーディング第8回に行ってきました！
（→Togetter、他の人のメモ：johtaniさん、taro_xさん）
今回の最初は、@muddydixonさんの『オレオレMultipleInputを作る方法』（→資料）。
MongoDBからデータを読み込むMongoMultipleInputsを作ったという話。
「Mongoパス（URL）と読み込む条件とそれを処理するMapperクラス」を複数指定し、別々のMapTaskとして同時に処理できるということのようだ。
ただ、現状ではMongoDBのチャンク（分散場所の情報かな？）を見ているわけではないので、ネットワークの負荷はかかりそうな感じ。
キーと値にはBSONWritableが指定できる。
ソースコードも見せてもらって、「ソースコードリーディング」らしかった(笑)
あと、TaggedInputSplitがprivateクラスなので直接扱えないという話があった。
自分も昔AntのCopyTaskを拡張したかったときにprivateだったりfinalだったりにやられたことがあるので、残念な気持ちは分かる。
オブジェクト指向には反するけど、privateやfinalを使うのはやめて欲しいな（←暴言）
次は、リクルートさん…の前に、急遽EMCの草薙さんからMapRの説明。
製品名が最近『Greenplum MR』（このMRはMapRのこと？）に変わったが、「MapR M5 Edition」と同じ。
MapR社が約2年間ステルスモードで開発し、2011年5月に発表。EMC社は分散DBをやっていたので、MapRと協業することになったらしい。
MapRはOSSではない。HDFSをMapR FSに置き換えた。
MapReduceは100％互換で、Javaのプログラムがそのまま動く。
MapR1.2はHadoop0.20.2にパッチを当てたもので、CDH3u2に近いらしい。
（「近い」ということは「同じではない」ということなので、本番環境がMapRで開発環境がApache HadoopやCDHというのは、やめた方がいいだろうなぁ）
で、@tf0054さん・@tatakabaさん・@tsubo0423さん達のMapR検証結果報告。（→資料）
まずは性能検証ということで、中古車サイトで実際に使われているデータを使って検証。スレーブは4台。
言語は、リクルートさんの中で一番使われているHive。（MapR自体はPigもサポートしているらしい）
「パーティション・ビルトイン圧縮」でCDH3の1.3倍、「非パーティション・非圧縮」で1.76倍。MapRはHDFSの2～5倍と宣伝していたと思うけど、そこまでは行かなかったとのこと。まぁ、環境・対象データ・アプリケーションが違えば差も変わるよね＾＾；
（MapRの推奨構成では、1台当たりのディスク数が多いらしい）
次いで、マルチテナント検証。
つまり複数のユーザーで1つのクラスターを共有して、セキュリティーや運用コスト（余剰リソースの有効活用）が大丈夫かという話。
しかしMapRのユーザーはLinuxユーザー準拠で、特にMapR独自のユーザー体系は無く、データアクセス権はApache Hadoopと同じらしい。
パーミッションはクラスターパーミッション・ボリュームパーミッション。
ボリュームのポリシーはユーザー毎の使用量やレプリケーション数、トポロジー制限（ラック指定）が出来る。
ファイルのパーミッションについてはhadoop fsコマンドで指定するらしい。
結論として、思ったほどセキュリティーが強いわけではなかったとのこと。
MapRのスケジューラーは、FairScheduler。
複数のプールを持つジョブスケジューラーらしい。
プール毎に設定された（タスク実行のスロット数の）MIN/MAXの遵守を基本とした上で、プール毎の割当量を平等に保とうとする。
割り当てられたスロット数に応じて課金するとか考えられるんじゃないかとのこと。
MapRのサーバー構成では、HDFSのようなMaster/Slaveは意識する必要が無いらしい。
全体を管理しているCLDBは3台まで同時に稼動できる（マニュアルを無視して11台全部に入れても動いたらしいが、サポート対象外となる）。
JobTrackerは1台だけで稼動し、2台はスタンバイしている。
（CLDBやJobTrackerの情報など、Hadoopならローカル（temp）に置くようなデータでも、MapRは全てMapR FS上の専用のボリュームに持つ）
フェイルオーバーすると、Job実行中のものは引き継いで再実行してくれる。
JobTracker障害の検知まで30秒、次のJobTrackerを決めるまで1分、引継ぎが完了する（次のジョブが受け付けられるようになる）まで5分、ジョブが再開するまで15分くらいだったそうだ。（いずれの時間も、最初の障害発生からの経過時間）
（そういえば、HDFSのNameNodeはDRBDやHeartbeat（Pacemaker）で冗長化するという話があるが、これの切り替えはどれくらいの時間がかかるものなんだろうな？）
速度が速いことで注目を集めているNFSマウントは、NFSゲートウェイをサーバー側に置く方法とクライアント側に置く方法の2種類がある。
クライアントが1台しか無いと差はあまり無いが、クライアント3台から同時に200MBのファイルを500個転送したら、サーバー側だと18分、クライアント側だと9分。
サーバー側だとNIC（ネットワークカード）が1つしか使われないのに対し、クライアント側だとNICが全部使われるし、データを圧縮してから転送するのでネットワークの効率が良いらしい。
ただしクライアント側にもMapRをインストールする必要があるので、その分のライセンスは必要だとか＾＾；
最後に、（MapRとは関係ないと思うけど）Mesosの環境も作ってみたそうだ。
まさかここでMesosの名前を聞くとは思わなかった！日本語の情報がほとんど無いので、どういうものか知りたかったんだよね～。
MesosはApache Incubatorのプロジェクト（Apacheのトップレベルプロジェクトではない）で、リソース共有機能を持つクラスターマネージャー。C++で書かれている。
Mesos上で動く対象は、Hadoop、MPI、Spark、Hypertable。
（Hypertableと言えば、GoogleのBigTableを模したNoSQLだったような。HBaseもBigTableがモデルだけど、HypertableはC++で書かれていたはず）
（Sparkは、Scalaで分散処理を記述できるライブラリー（フレームワーク）。単独環境ではMesosは不要だが、実際に分散させるにはMesosが必要）
Mesosはmaster/slave/application（framework）という3つの役割の構成で、マスターがリソースを管理する。アプリがマスターに問い合わせ、スレーブで動かすという感じだろうか。
MesosをダウンロードするとHadoopも入っているそうで、Mesos上でHadoopが動く。
MesosマスターがJobTrackerの代わりとして動き、TaskTrackerはMesosから指示されて起動するんだそうだ。
（通常のHadoopのJobTracker・TaskTrackerの動作と違うから、Apache Hadoopそのものとは思えないんだけど、どうなんだろう？あ、confのxmlファイルでMesos独自のクラスを指定しているということかな？）
この仕組みを利用して、Mesos上でHadoopインスタンスを2つ実行させてみたそうだ。（Sparkとも共存できるらしい）
ユーザー管理はMapRと同じくOSユーザーを使用する。
お互いのHadoopインスタンスにはアクセスできないので、セキュリティー的にはOK。
ただしsudoを使ったりconfを切り替えたりすると見えてしまう…。
また、CPUやメモリーの使用率に制限をかけることは出来ない。
結論として、リクルートさんの評価は、性能や運用面ではMapRが良いが、サポート・将来性・ドキュメントではCDH。
やはり大企業で使う場合、サポート体制を重視する人が居るものらしい(苦笑)
CDH（Cloudera）はNTTDさんがサポートについているしね～。と持ち上げられて、@hamakenさんも困惑気味だったけど＾＾；
そういえば、質疑ではClouderaの@shiumachiさんがいつもより盛んに質問していた。やっぱり興味あるんだろうな(笑)
また、何かの書籍の執筆も進んでいる模様。
CDH3u3でHDFSが速くなった、という要因にも触れられているとかで、楽しみ＾＾
何はともあれ、思っていた以上に面白かったです。ありがとうございました。
