第5回Asakusaソースコードリーディングのメモ

はい、Asakusaソースコードリーディング第5回のメモです。→Togetter

今回はYAESSとWindGate。
AsakusaFW0.2.2（9月末）でWindGate、0.2.3（11月中旬）でYAESSとThunderGateのキャッシュ機能がリリースされたらしいけど、自分はまだ0.2.1の頃の機能しか試してない…！orz

0.2.4は現在開発中で、WindGateCSVが入ったり、ドキュメントが整備されたりするらしい。年内リリースを目標に準備中とのこと。

---

YAESSはバッチを実行するコマンドラインツール（運用ツールではない。例えば障害を検知してリランするような機能は無い）。

AsakusaFWのバッチの中身はフロー→ジョブ→フェーズで構成されていて、YAESSはバッチの実行はもちろん、フェーズを指定して実行することも出来る。また、バッチ構造をJSON形式でダンプできる。

YAESSは、
・AsakusaFWの実行計画詳細を隠蔽する
・バッチ実行の環境構成を隠蔽する
・個々のジョブの起動方法を隠蔽する
・外部のジョブ運用ツールと連携できる

YAESSを構成するコンポーネントのひとつにJobSchedulerがある。これはリソースの利用状況に応じて多重度を調整したりするものらしいが、Hadoop0.23のResourceManagerでも似たような話を聞いたような＾＾；

AsakusaDSLからコンパイラプラグインでYAESSの構造を生成する。
また、MinGWとの連携も出来たらしい。（自分はCygwinしか使ったことないや…）

---

WindGateはデータソース（RDBやローカルファイル）のデータをHDFSに書き込んだり、逆にHDFSから読み込んでデータソースに書き込める、ポータブルなツール。
（例えばOracle11gからJDBC/TCPで読み込み、SSH（標準入出力でデータ転送）経由でHDFSに書き込める）
データの投入・取得・保全を一番簡単な方法で実現したもの。なので、パフォーマンス優位性は低い。
データソースはプラグインで色々対応できる。

個人的に一番気になっていて今回分かったのが、使い方。
AsakusaFWのDMDL（データモデル定義）にアノテーションを付ける。@windgate.jdbc.table(テーブル名)（RDBのテーブル用）とか、@windgate.csv（CSVファイル用）といった形。
そして、ジョブフローに指定するImporterやExporterにWindGateImporterDescriptionやWindGateExporterDescriptionを指定する。
自分は今までCSVファイル（テキストファイル）を扱う為にFileImporterDescriptionを継承して色々やってステップ数が増えて面倒だ～と思ってたけど、これで楽になりそう！
（というか、FileImporterDescriptoinはアンドキュメント（非公開）だったらしい(汗)）

あと、外部からファイル名を渡すことも出来るようになるらしい。これも欲しかった機能！
ImporterDescriptionのファイル名指定部分で「"$なんちゃら"」という形で指定できるらしい。
（ついでに後から聞いた話だけど、Operatorクラスの中でconfにアクセスするAPIもあるそうで。experimental.shでconfのプロパティーを渡せそうだという事は調べがついてたんだけど、それをOperatorで取得する方法が分からなかったんだよねー）

ますます便利になってきますね！

---

最後に、最後の方で話題に上がったAsakusaFWのシーケンスファイルの内容を見られるツールについて。
面白そうだからという理由で作ってた（作りかけの）ツールだけど、ちょっとシーケンスファイルの中身を確認したいというだけなら（自分でもそのつもりで追加した機能なので）うってつけです(笑)

Scalaで作ったからScala2.9.1が入ってないと使えないんですが、Scalaをインストールしていない人はこの際だからScala使いになりましょうｗ

shr.shを実行してScalaを起動した後、「:load shr.scala」でスクリプトファイルを実行。
その後、「Path("/user/hdfs").ls」と入れてHDFS上のファイル一覧が表示されればひとまずOK。「Path("/user/hdfs").view」とやると、Swingで作ったテキトーなウィンドウが起動します＾＾；
後はなんとなく分かると思います。ツリーからディレクトリーを選んで、右側のファイル一覧の番号部分をダブルクリックすると幸せになれるかも？（ずっこけるかも？ｗ）

改めて書いておきますが、作りかけなので、デザインが変だったり手抜きに見えるのは現在のところ仕様です(爆)

Hadoop0.23のYARNでMapReduceを動かす

Hadoop0.23をインストールしたときに稼動確認としてWordCountや円周率算出サンプル（つまりMapReduceプログラム）を動かしたけど、そのときはリソースマネージャーやノードマネージャーを起動していなかった。つまりYARNの環境では動いていなかった。
やはりそれはローカルモードで動いていたようだ。という訳で、MapReduceプログラムをYARN環境で動かす方法を発見した。

ついでにYARN環境でMapReduceプログラムを動かしているクラスを少しだけ追ってみた。
JobTrackerに相当するアプリケーションマスターはMRAppMasterクラス、コンテナープログラム（MapタスクやReduceタスクを実行する）はYarnChildというクラスのようだ。
（今まで自分の説明が間違っていたような気がするが、タスクを起動するTaskTrackerに相当するのは、コンテナーを起動するNodeManagerのようだ）

YarnChildのmain()の引数にホスト名やポート番号を渡して通信に使っているようなので、アプリマスターを自作する場合、アプリマスターとコンテナーとの通信はやはり自前で行う必要があるようだ(苦笑)

Hadoopソースコードリーディング第7回の感想

Hadoopソースコードリーディング第7回に参加しましたので、感想をば。
今回の主なテーマは11/8～9にニューヨークで開催されたHadoop World NYC 2011の報告。→Togetter
（他の人のメモ→落合さん（発表者）、johtaniさん、akanumaさん、マッキーさん、snuffkinさん）

---

最初はNTTデータの下垣さんから。
今年は1400人くらい参加があったが、内75.7％が初参加、でも71.9％がHadoop利用者（36.8％が1年未満）だったそうで。平均ノード数は120。
アメリカでもまだこれから使うって人が多いんだねぇ。それと、ノード数多いな＾＾；

変わった話では、Big Dataのファンドが登場したとか。ビッグデータを生成する企業に投資するんだそうで。へえ、そんなものが…！

HadoopとRDBMSを組み合わせるといった観点から、RDBMSが改めて活気付くという予想もあるとか。

あと、ウォルトディズニー（のインターネットビジネス）がHadoop使ってるなんて話は初めて聞いた。
2009年から利用開始というならそこそこ前からだけど、40台って、会社の規模から想像すると、なんだか少ないような＾＾；

全体の傾向としてはHBaseの利用が増えているとか（最近HBaseの話題を聞いてなかったような気がするけど、向こうでは増えてるんだ…）、大手ベンダーの参加が目立っているとか。
たいていのベンダーはハードウェアとかBIツールとか、自分の力を生かした分野で参入しているけど、Oracleだけはほぼ全分野に進出しているみたいで、すごいなーｗ

---

次にNTTデータの政谷さん。

NYCで日本からNTTデータ（政谷さん自身）とNTTコミュニケーションズさんが発表したらしく、その内容。

PostgreSQLとの連携の紹介で、各Mapタスクの中でバルクロードするっていう仕組みが興味深かった。RDBMS側もボトルネックにならないよう分散させるようにするみたい。

それから、富士通と提携して作った、HDFS APIを使ってアクセスできるストレージとか。
MapRに似ているらしい。

---

ここで話が変わってClouderaの嶋内さん。Hadoopの設定のお話。

設定ミスはClouderaへの問い合わせ（チケット）の2％だそうで。一般的なソフトウェアは単純ミスが大半だから、2％というのは珍しいんだとか。
しかしHadoopは設定をミスっても影響がすぐ出るとは限らず、ログをちょっと調べたくらいじゃ分からん、と。

という訳で、よく見られるエラーメッセージとその対策について。ここら辺は細かい話だったけど有益な情報が多かったので、ぜひ資料を公開して欲しいです。（公開されました→資料）
ちなみに「Too Many Fetch-Failures」はまさにこの前見かけたよ＾＾；

---

最後はAcroquest Technologyの阪本さん・落合さんからの報告。

R言語とHadoopの融合。R言語とは、統計解析向けプログラミング言語らしい。すみません、それは初めて知りましたorz
R言語からHadoopを使えるようにしたらしい。世の中そういうもの多いねｗ ScalaからHadoopなんてものもあるし。ただ、R言語は統計的な分析なら上手く書けるらしい。

Hadoopを使った衛星画像解析。タスクの中からC言語のライブラリーを呼ぶようにしたらしい。既存資産をJavaで書き直すことなく使えるようにした例。

VMwareの、Hadoopをクラウドに展開する話。クラウドというか、仮想化の事らしいが。
一般的にHadoopと仮想化は相性が悪いと言われていて、まぁ普通はSANやNASでディスクを共有するから。しかしHadoopはローカルディスクを使う（仮想化（物理配置を気にしない）に矛盾する）。
という話の解決策として、ハイブリッドストレージというのを出してきたらしい。

全般的に、Hadoopをインフラとして使う（Hadoopと他の言語やフレームワーク・ライブラリーを組み合わせて使う）傾向が感じられたとのこと。

---

あ、最後に。扇子とピザとジュースご馳走様でした。あとお土産にバッジ1個いただきました(笑)
（今回はアフリカの動物も酔うという実から作られたお酒が強烈だったようで＾＾；）

Hadoop0.23 YARN コンテナー呼び出し

Hadoop0.23のYARNの実験の続き。前回はコンテナー呼び出しまで行かなかったが、今回は呼び出してみた。
…呼び出しただけで、結果の取得はやれてない(爆)

クライアントとアプリケーションマスター間は進捗状況を伝えたり完了あるいは失敗を伝えたりする仕組みが用意されているけど、
末端のコンテナーはJavaプログラムである必要すら無いので、逆にアプリケーションマスターと通信しあうような仕組みは特に無いっぽい（今のところ見つけていない）。

それにしてもYARNは一から実装するんで大変だけど、大部分は定型的なコーディングになりそうではある。
Javaのアプリマスターを呼び出す場合、クライアント側はかなりの部分が共通化できそう。
→参考ソース（共通部分：YarnClient、独自部分：Sample2Client）

コンテナープログラムはmain()から呼ばれる普通のプログラムなので特に問題は無い。（アプリマスターに何か渡そうとしない限り）

アプリマスターはコンテナー呼び出しと結果の取得や失敗時のリランまでやらないといけないので、やはり一番大変。

Hadoop0.23 YARNの最小限サンプルを書いてみた

Hadoop0.23.0が出たので、噂のMapReduce2.0であるYARNの最小限サンプルを書いてみた。

いやー、しかしYARNを甘く見てた＾＾；
YARNはもうMapReduceとは（直接は）関係ないので、MapReduce2.0とは呼ばない方がいいね。

従来のHadoopなら、「MapReduceのプログラムを書くよ」と言ったら、MapperやReducerを実装するのをイメージすると思う。
そして、JobTrackerやTaskTrackerが自動的にタスク分割して実行してくれる。障害が発生したら別ノードで再実行してくれるし。

しかし「YARNのプログラムを書くよ」というのは、JobTrackerやTaskTrackerや障害対応をコーディングする事に相当する！
今回作ってみたのが“最小限”サンプルなのも、JobTracker相当（ApplicationMaster）の実行までしか出来ず、TaskTracker相当（Container）まで辿り着けなかったからだし(爆)
まぁそこまででもコーディングしてみたことによって、アプリケーションの実行方法は理解できたけど。

タスク分割や障害対応を自前でコーディングしなければならないとすると、じゃあHadoopさんは何をやってくれるのかという話になるが。
リソースの空き状態に応じてどのノードで実行するかを決めるのと、そのノード上でのアプリケーションの起動まではやってくれる。また、進捗状況の通知・監視の仕組みは用意されている。
okachimachiorzさんが分散リソース管理OSと言っていたのはこういう意味だったんだなぁと実感。

今までのHadoopでも、直接MapReduceをプログラミングするのは大変なのでラッパーのツールを使おうという流れだったけど、YARNはなおさら普通の人がコーディングするものじゃないなぁ。
これはまさしく分散フレームワークを作る人向け。MapReduce以外のアルゴリズムでも何でも対応できるのは確かなので、色々なアルゴリズムのYARNラッパー（フレームワーク）が作られることになると思う。
普通の人は、自分がやりたい処理に一番向いているフレームワークを選択して、（今までのMapReduceの様に）部分的なプログラミングをするだけになる…かな？