Asakusa on Sparkのコンパイル

Asakusa Framework Advent Calendar 2015およびApache Spark Advent Calendar 2015の4日目です。

2015/11/28のJJUG CCC Fall 2015でAsakusaFWと比較する為にSparkの概要を説明したら、「Spark良さそう」という感想を持たれた方もいらっしゃったようです。（→Togetter）
自分もScalaを使っていいならSpark使いたいです(笑) SparkはScalaの延長でコーディングできるので、ちょっとしたものは楽にコーディングできます。
（AsakusaFWだと、実は最小限を試すにも若干色々コーディングしないといけなくて、Sparkより大変ですorz）

ところで、Spark界隈の人が知っているかどうか分かりませんが、AsakusaFWはSpark上で動かすことが出来るのです！

AsakusaFWは分散バッチアプリケーションを作成する為のフレームワークで、Javaをホスト言語とするDSLで記述します（要するにJavaアプリケーションです）。
そして、AsakusaFWは実行基盤としてHadoopを使っていました。つまり、Asakusaアプリケーション（Javaで記述したもの）をコンパイルするとHadoopのMapReduce（jarファイル等）が生成されます。
が、今年、実行基盤としてSparkを使うことも出来るようになりました。（→Asakusa on Spark）
つまり、Asakusaアプリケーションをコンパイルすることにより、Sparkアプリケーション（jarファイル等）が生成され、Spark上で動かすことが出来る、ということです。
Spark版バッチはHadoop版バッチに比べて大抵のケースで3倍くらい速く、とても驚いています(笑)

ちなみにHadoopの方が速い例は、シンプルなキー毎の集計処理（1つのMapReduceだけで済む）で、かつ、キーの種類が非常に多い場合です。元々Hadoopはそういった用途のものなので、問題なく処理できます。
が、Sparkはキー毎の集計はHashMapを使ってメモリー上で行うらしく、キーの種類が多いと大量のメモリーが必要になるので不利なんだそうです。 

---

AsakusaFWのSpark版バッチの生成方法はちょっと驚きです。

MapReduceアプリケーションの生成は、Javaソースを生成してjavacでコンパイルする仕組みになっているのですが、
Sparkアプリケーションの生成は、Scalaソースを生成してscalacでコンパイルするのではなく、バイトコードを出力して直接classファイルを作っているらしいです。したがって、Scalaのコンパイルは必要ありません。なんて変態的な＾＾；

しかしそのせいで、生成されたクラス内で例外が発生すると、スタックトレース上にソースファイル名が表示されません（Unknown Sourceになる）。
ただ、Spark版とHadoop版は別々にコンパイルしてjarファイルを生成できるので、Spark版バッチの代わりにHadoop版バッチで実行するという事が出来ます。これで同様の例外が発生すれば、Hadoop版の方はJavaソースファイル名がスタックトレースに表示されるので、問題箇所を探すことが出来ます。