Asakusa Frameworkとは（2015版）

Asakusa Framework Advent Calendar 2015の1日目です。

アドベントカレンダーの初日ということで、2015年時点のAsakusa Frameworkの紹介を書いておきたいと思います。

---

Asakusa Frameworkは、分散バッチアプリケーションを開発・実行する為のフレームワークです。
実行基盤にはHadoopを使うのが基本でしたが、今年の7月から、Sparkを使うことも出来るようになりました（ただし、まだexperimentalですが）。
（ちなみに、去年の目玉はスモールジョブ実行エンジンでした）

AsakusaFWは、公開された当初（2011年）から「実行基盤としてHadoopを使っている」と言っていました。つまり、実行基盤としてHadoopの他に良いものが出てくれば、それで動くようにするかもしれないというスタンスでした。
その一環として去年はスモールジョブ実行エンジンが動くようになったわけですが、これはHadoopの代わりとなって動くものであり、基本的にMapReduceであることは変わりませんでした。
そして今年はSpark上で動くようになり、完全にMapReduceとは違う実行基盤に対応したことになります。
（スモールジョブ実行エンジンは実行時に自動的に切り替わるものでしたが）Spark版は、Asakusaアプリケーションのコンパイルを行うことでSpark用実行バイナリー（jarファイル等）を生成します。
実行時のHadoop版とSpark版の切り替えは、YAESSの引数によって行います。（もちろん、HadoopクラスターにSparkをインストールしておく必要はあります）

$ $ASAKUSA_HOME/bin/yaess-batch.sh HogeBatch
$ $ASAKUSA_HOME/bin/yaess-batch.sh spark.HogeBatch

大抵はSpark版の方が早い（実行時間が短い。だいたい、3～5倍くらい）ようですが、比べてみるのは簡単に出来るので、早い方を採用すればいいわけです。

Asakusaアプリケーションのコーディング方法は基本的に公開された当初から変わっていないので（後方互換性を維持しているので）、昔からあるAsakusaアプリケーションも、AsakusaFWのバージョンさえ上げれば（あと、HadoopクラスターでSparkを使えるようにすれば）Spark版で実行することは出来ると思います。
つまり、以前からAsakusaFWを使ってきた人にとってメリットがあると思います。

逆に、これからAsakusaFWを使ってみるか？という人にもメリットがあると思います。
異なる実行基盤で動くことが実証されたので、今後も新しい実行基盤が出てくればそれに対応するかもしれないという話が現実味を帯びてきたわけですから。

---

AsakusaFWは後方互換性を考慮しているので、昔からコーディング方法（Asakusa DSL）は特に変わっていません。（インストール方法やコンパイル方法等は変わってきましたが）

が、AsakusaFW0.7.3等で新しい機能がだいぶ追加になっています。（「追加」なので、今までの機能はそのまま使えます）

• Direct I/Oのデータフィルター・パスフィルター
• core.emptyやextend等でasを使った書き方が出来るようになった
• Direct I/O API（Operatorのメソッドの中から自由にファイルが読める）
• @directio.line（Direct I/Oで1行ずつ読む）

それから、スモールジョブ実行エンジンを使ってWindows上でフローのテストを行う方法が正式になったのも今年になってからでしたね。当たり前になっていてすっかり忘れていました＾＾；

それから、AsakusaFWの公式ドキュメントのURLが「http://docs.asakusafw.com」になったんですよね。まぁ、大抵はググって探すのであまり関係ないかもしれませんが(爆)

JJUG CCC Fall 2015の感想

JJUG CCC Fall 2015（2015/11/28）に行ってきました。（→chiheisenさんの資料一覧）
と言っても、今回縁あって登壇させていただくことになったので、自分が登壇する前後の講演を見てきただけといった感じです＾＾；
JJUG CCCとなると大規模で、丸1日がかりですからねぇ…体力が(爆)
（というのと、資料の大筋は今月頭には出来ていたけど、今月末締め切りの仕事が忙しく、前の週の3連休まで全て休日出勤になってしまい、ブラッシュアップするのが直前になってしまったのが痛い（という言い訳＞＜））
という訳で午後の途中からの参加だったので、cero_tさんやうらがみさんやirofさんが見られなかったのは残念です。まぁ、この人達ならまた機会はありそうですし…。

で、自分の登壇のは別のブログとして（アドベントカレンダーのネタとしてｗ）書くとして、参加した講演について簡単に感想を書いておきたいと思います。

---

最初は、GH-4 伊藤博志さんのEclipse Collectionの話。（→資料）

途中から参加したんですが、「何度もGS Collectionと言い間違う」と言っていたので、GS Collectionから改名したんだなーということがよく分かりましたｗ
Stream APIはコレクションから変換する必要があるんですが、直接（Stream API的な）処理が出来るコレクションが用意され、メソッドも便利なものが増えている感じでとても良さそうでした。

ちなみに以前会社の同僚が、「Java8のラムダ式みたいなものは文法の変更が必要なのでJavaとして対応するのはいいけれども、Stream APIのようなライブラリーを標準に入れるのは反対だ、サードパーティーが作ればよい」てな感じの事を言っていたんですが、Eclipse Collectionはまさにそのライブラリーですね。
（自分は逆に、みんなが同じように使うものであれば、標準に入っていてもいいんじゃないか派です。ただしStream APIの場合、IntStreamといったプリミティブを扱うStreamの存在がちょっと…。特に将来Stream<int>が使えるようになったらIntStreamは無用の長物。かといって一度ライブラリーに入った以上、Java的にはなかなか削除できない。いきなり負の遺産になりかねない…）

ところで、filterNotの例で、filterメソッドのラムダ式の前に「!」が付いていた（s.filter(!person -> …)みたいな感じ）けれども、そうは書けないですよね？？

---

次はEF-5 きしだなおきさんのこれからのコンピューティングの変化の話。

GPUの話と、プロジェクトvalhalla・Panama？の話でした。
（自分の登壇資料にも将来のハードウェアの話をちょっと入れていたんだけど、きしださんの方が詳しくて「やべっ」って思ったorz）

プリミティブ型をジェネリクスに指定できるようにするという話は以前からちらほら聞いていたんですが、value type（value typeの配列だと、いちいちオブジェクトを持たなくする）やArrays 2.0は記憶にありませんでした。配列がインターフェースで表現できると良さそうですね。
Scalaの配列はSeq（JavaのListインターフェース相当）を継承しているので、リストと同様に扱えて便利なんですが、Javaでもそうなると良いなぁ(笑)

あと、バイトコードレベルで型に応じたaloadとかiloadとかの命令があるんですが、vloadといった統一的なものが出来るかもしれないとか、ほー！という話が聞けて面白かったです。

---

自分のは飛ばして（本当はAB-6のやんくさんの話を聞きたかった）、最後にGH-7 てらだよしおの赤裸々タイム(笑)

てらださんが前の会社を退職すると聞いたとき、自分はTwitterで「次はマイクロソフトだったら面白い」と書いた（つまり、マイクロソフトなわけはないだろうと思っていた）ら、本当にそうだったんでビックリしたんですが＾＾；
どうしてマイクロソフトなのか、という話もありました。

マイクロソフトは一強だった（Windows95～XPの時代の）イメージなんですが、今だと結構違うんですかねぇ。
まぁ、自分はもともとMSXからパソコンを始めたので、本来はマイクロソフトを毛嫌いする必要は無いはずなんですけどねｗ

そういえば、ニコニコ生放送について質問したのはみうみうさんだったんですね？！質問するとき名乗ってくれればよいものをｗ

---

以上、参加者の皆さん、スタッフの皆さん、お疲れ様でした＆ありがとうございました。

AsakusaFW0.7.5 directio.line

Asakusa Framework0.7.5がリリース。→リリースノート

まず、Direct I/Oで1行ずつ読み込む為のdirectio.lineが追加になった。sandboxの機能なので、directio.tsvと同じ扱い。
（一行ずつ読み込めるTextFormatを作ったことがあったけど、これで不要になった＾＾；）
改行を含まない1行ずつのJSONや、スペース+タブ区切りや、「#」 以降をコメントアウトしたいような不定形なファイルで使い道がありそう。
WordCountのサンプルもこれを使って直そうかなぁ。（今はdirectio.csvを使っているので、カンマが入ったデータには対応していない）
（というか、DMDL EditorXも対応しないとな）

それから、バッチクラスを指定して、1バッチだけのコンパイルが出来るようになった。
DMDL EditorXにも指定したバッチクラスだけをコンパイルする機能はあるんだけど、事前のcompileJavaが終わるのを待たず（待てず）に動いていしまうというバグがあって苦慮していたので、この新機能は有り難い。
（これもDMDL EditorXで対応しないとなー）

あと、API（Javadoc）の英語化。国際対応ですねー。