Asakusa Frameworkのススメ

f:id:teppei-studio:20131112202621j:plain

先週のCloudera World Tokyo 2013
講演させていただいた際に、Asakusa Frameworkの紹介をさせていただきましたが、マネージャー視点によっていたところがあるので、開発者視点の紹介を改めてしたいと思います。

尚、このブログでの記載は私が所属する会社とは何も関係なく、あくまでも個人の立場で書いているブログであり、会社を代表する発言ではありません。

Asakusa Framework とは

Hadoop上でバッチアプリケーションを開発するためのフレームワークです。一定規模のバッチアプリケーションをHadoop上で開発するのであれば、現時点では他に選択肢は無いと言えると思います。

業務基幹バッチの置き換えに!みたいな文脈で語られることが多いですが、分析のための前処理といったロジックの更新頻度がある程度低くて、一定程度に大規模なバッチアプリケーションであれば広く適用できると思います。

メリット

1.テスト機能が充実している

兎にも角にも、この点につきます。Asakusa Frameworkで実装する全てに、奇麗にテストを実装することができます。このテスト機能が無ければ一定規模以上のバッチアプリケーションは実質実装できません。開発していて、一番感動するのはこのテスト機能です。「あぁ、Asakusaのこの大きな胸に身を任せていればいいのね...!」みたいな気分になります。

2.MapReduce機能の最適化処理が高度

MapReduceのバッチ処理の性能に効いてくるのは、MapReduceの数を少なくすることです。ひとつのMapReduceが終わって、次のMapReduceが開始するまでに、HDFSへ一時書き込みが発生するので、それなりのオーバーヘッドがあります。

AsakusaFrameworkでは、DSLで書いたロジックが、内部的に自動でMapReduceに変換されます。ここで、ひとつのMapReduceに集約できる処理かどうかが自動判断されます。ここで動く最適化処理が思った以上に高度で、これを自前で考えて設計するとなると結構大変だと思います。これを自動でやってくれるのは非常に助かりますし、最適化処理の高度さにはなかなか驚かされます。

3.周辺機能が充実している

開発したMapReduceプログラムをJarのまま呼び出すのは、なかなか面倒です。パスのことを考えたり、変数をどう渡すかということを考えたりしなければなりません。AsakusaFrameworkではYaessというバッチ機構が用意されていて、そのあたりの煩わしさが解消されています。JP1やHinemosといったJOB管理機能から呼ばれることを想定した、バッチアプリケーションを稼働させるためのAPIが用意されています。

また、上記でMapReduceプログラムが自動生成されると記載しましたが、どう生成されたかを図示したデータも合わせて自動生成されます。これはデバッグの際に無くてはならない情報になります。

あと、稼働時に出力されるログも情報が充実しています。Asakusaで実装した設計の情報に沿って情報が出力されるので助かります。

デメリット

何でもそうですが、良いことばかりではありません。

OSSとしてコミュニティが活発化していない

これが一番悲しいですね。ネット上に全然情報がありません。
本家のドキュメントはそこそこ充実しているのですが、読み方にちょっと慣れが必要です。それに、そういうドキュメントはそれはそれとして、いろいろなケースに応じた情報がいろいろな人から出てくるのがやっぱり望ましいです。と、文句を言っていても仕方ないので、まずはブログで情報を挙げていくべく、立ち上がりたいと思います。この記事は、その始まりです。

DSL仕様が直観的でないところが多い

そうなんです。「そりゃわかんねーよ」ってところが結構あります。今後改善されることも期待できますが、ここはいろいろなケーススタディの情報を増やしていくしかないと思っています。次々回の記事からいろいろ紹介していきたいと思います。

サポート対象のHadoopバージョンが少ない

CDHだと3系、Apache Hadoopとしては、v0.20.2あたりですかね。が、正式サポートです。まぁこれはエンタープライズとして利用した場合、ということですけどね。

【2014/1/4 追記】
0.5.3で改善されました

次回予告

てことで、おススメ理由についてざっと紹介してみました。とはいえ、こんな概念的な話をされても仕方ないと思うので、次回以降、具体的にAsakusaを解説していきたいと思います。