Hadoopアドベントカレンダー2012 #hadoopAC12jpの13日目です。
もう今年はアドベントカレンダーのネタが尽きたーと思っていたら、突如現れたCACさんのAZAREA-Cluster！（12日に公表されました。）HadoopアプリケーションをGUIで開発できるとな？！
OSSではないので実際に試してみることは出来ないものの、ドキュメントが公開されていたので読んでみました。
（『機能と動作環境』の開発ガイドのリンクからpdfファイルがダウンロードできる）
まず目を引くのはやはりGUI部分ですね。
Eclipseのプラグインとしてフローを描けるようです。ファイルの結合とかはこういう図だと分かり易いですね。
ここからJavaのソースが生成されます。
データはエンティティと呼ばれるクラスで扱います。
Asakusa FrameworkだとDMDLという独自の簡易言語からクラスを生成しますが、AZAREAではExcelもしくはXMLで記述してそこからクラスを生成します。（そういえば、AsakusaFW用にExcelからDMDLを生成するマクロは作ってみたことがあるｗ）
生成されたクラスの各フィールドはpublicで、サンプルではセッターゲッターメソッドを介さずアクセスしていました。
（Scalaもコーディング上はフィールドに直接アクセスという形なので、似たようなもの？ｗ）
フローから生成されたJavaソースは、なんとなくCascadingに似ています。
CascadingはEachやEvery・GroupByといった処理内容を表すクラスに、自分でコーディングしたFunction・FilterやAggregaterオブジェクトを渡す形式になっています。
AZAREAもConversionやGroup・Joinといった処理内容を表すクラスがあって、それをオーバーライドしてメソッドの中を自分でコーディングします。で、雛形となるソースはフローから生成されるので、コーディングするのはメソッド内だけで良いわけです。
（WordCountの例がp.110に掲載されています）
処理を表すクラスはConversion・Group・Sort・GroupSort・Join・UniqueJoinの6種類だけ。非常にシンプルです。
Conversionは素のMapReduceのMapper#map()に近いです。扱うデータはキー/バリューではなくエンティティクラスですが、別のエンティティクラスを作って出力できますし、出力件数も0件から複数件まで可能です。Scalaで例えるとflatMapですね。出力ファイルを2種類以上にする事も出来ようなので、Mapperより高機能ですが。
GroupがReducer相当ですかね。集計を行う処理であり、AsakusaFWのFold演算子に当たるものになります。
CascadingやAsakusaFWだと（PigやHiveも）、SQLのSUMやCOUNTに当たるものはデフォルトで用意されているのですが、AZAREAではそういうものは無く、自分で必ずコーディングしなければならないようです。まぁfoldを記述するのは簡単ですし関数型プログラミングに慣れている人にとっては分かり易いですけど。
複数ファイルを扱う部分は一ファイルの時とちょっと違うコーディングとなりますが、その辺りはきっと自動生成されるので戸惑いは少なくなるのでしょう。
AZAREAはテスト用にシミュレータが用意されているのも特徴です。
フローの処理全体を普通のJavaアプリとして実行し、Eclipse上でブレークポイントを設定してデバッグすることが出来ます。（Hadoopのタスクをイメージしてデータ分割して実行するよう考慮されてるようです（マルチスレッドではありません））
これはAsakusaFWのFlow DSLのテストに当たる部分ですが、AsakusaFWだと実際にHadoopを起動するので、ブレークポイントで止めるのは面倒なんですよね…。
一方、AsakusaFWでは複雑なロジックを書く部分であるOperatorは普通のJavaのクラスなので、JUnitで単体テストすることが出来ますが、AZAREAは一メソッド内の匿名クラスとしてソースが生成されるので、その部分だけの単体テストは困難です。
Hadoopクラスターへのリリース時には1つのjarファイルにまとめ、「hadoop jar」コマンドで普通に実行します。
複数のフローをまとめて連続して実行させることも出来るし、クラス名を指定すれば特定のフローだけを実行することも出来るようです。
ただ、入出力データの場所を-iおよび-oで指定するのですが、ディレクトリーでしか指定できないようなのが気になります。複数種類のファイルを扱う場合はどうするんでしょう？
（ディレクトリーは全部同じで、ファイル名だけで区別する？）
まとめますと、
AZAREAはMapReduceをラップしてMapReduceを書き易くする方向性であるような印象を受けました。あるいはGUIのある上位Cascadingというか。
Javaソースの雛形を図から生成できるのは良いとして、その中でプログラマーがコーディングする内容が思ったよりも素のMapReduceに近かったです。
Huahin FrameworkもMapReduceをラップしているイメージですが、AZAREAはHuahinFWよりはMapReduceの隠蔽度合い（抽象度）が高いかもしれません。
一番抽象度が高くて重量級なのは依然としてAsakusaFWです。
AsakusaFWは複雑な基幹バッチを記述するという目的で設計されていて、AZAREAより処理内容を表すクラス（AsakusaFWでは演算子と呼ぶ）が多いし、直接MapperやReducerを意識することが無いようになっています。
（演算子にはプログラマーがコーディングできる内容を制限することで最適化しやすくなるという効果がある。反面、演算子の種類は増えてしまう。
AZAREAは演算子に当たるクラスの種類は絞られており、その代わり1つの演算子の中で色々なものをコーディングできる。
AsakusaFWでもCoGroupだけあれば何でも記述できるが、それをすると最適化が妨げられ、著しく実行効率が下がる可能性があるので、なるべくCoGroupは使わないよう推奨されている）
HuahinFWはPig/HiveとAsakusaFWの中間が欲しかったから作られたらしいですが、AZAREAもその辺りの位置付けなのでしょうか。
あとはやっぱり実際に使ってみないと分からないですよねぇ。
特にEclipseプラグインということで、動作の軽快さは気になります。
昔、画面フローを描いてソースを生成するEclipseプラグインのあるフレームワークを使ったことがありますが、貧弱なPCでは重すぎて何度もPCを再起動する羽目になり、生産性もモチベーションもだだ下がりという悪循環でした(苦笑)
AZAREAの場合は、MapReduceのラッパーという位置付けなのであれば、そんなに複雑なフローは対象ではないのかもしれませんが。
それと、図を修正してソースを生成し直した場合に、プログラマーが手で記述したソースがちゃんと残るかどうかですね。
ソース上にマークが付いている訳でもないので、プログラマーが記述した部分を認識できるのかどうか…？
（追記）あと、図を保存する際のデータ形式も気になります。テキストなら差分を確認したり手で直したり（一括置換したり）することも出来ますし、バージョン管理ツール（SubversionとかGitとか）とも相性が良い（マージすることも容易な）のですが。
評価版のダウンロードの申込フォームでは、会社名が必須になってるんですよね～。
「個人」とか書いて受け付けてもらえないかなぁ？
