『Asakusa Framework 勉強会 2015 冬』に行ってきました。今回で1年経過ですか＾＾
最初は恒例、土佐さんのはじめの一歩。
今回は前回と違ってDMDL EditorXとかで「出来なかった」という話が無かったので、安堵(笑)
そして、はじめの一歩に続いて、土佐さんから『Asakusa の実装面での苦手なトコ』。
2014/11/28にOSSコンソーシアムのAsakusa Framework部会主催の「2014 Asakusa Framework Day」でAsakusaFWの課題等について話されたそうですが（→資料）、今日はそこでは話さなかった実装面の課題とのことでした。
AsakusaFWで全部やりたいけれども、以下のような処理は難しいということで。
●全件ソート
（キー毎のソートではなく）全件のソートを行って上位N件を取得するような処理のことだそうです。
この為に、データモデルに同一の値を入れる項目を追加し、GroupSortでその項目でグルーピングしたとのことでした。
◇これは、GroupSortのグルーピング項目を空にすると全件ソートになります。
@GroupSort
public void sort(@Key(group={}, order={ "ソート項目" }) input, ～) {
という感じです。（ただし分散しないので、大量データでは注意）
Javaのアノテーションの知識になりますが、@KeyのgroupやorderはStringの配列として定義されているので、group="name"という記述はgroup={ "name" }の略なのです。
したがって、複数の項目を指定したければgroup={ "name1", "name2" }という書き方が出来ます。
で、項目をひとつも指定しない場合は全件が処理対象になるということになっています。
ただ、こういったことはAsakusaFWのドキュメントには書かれていないので、書いてあった方がいいかもしれませんね＾＾；
●インクリメント
一意のIDを付与（採番）する処理のことだそうです。
（Sparkではzip関数（zipWithIndexやzipWithUniqueId）で可能）
◇これはAsakusaFW開発側では昔から話題に挙がっている機能ですが、汎用的な方法（仕様）が決定できないので実現できていないようです。
全件ソートと同じロジックを使えば1スレーブで全データを処理できるのでIDを振ることは出来ますが、分散しないですね…orz
●小リストの活用
処理の途中で小さなリストを参照したいそうです。
（Sparkではブロードキャストで実現できる）
◇CoGroupで結合キーを空にすると、処理対象本体と小リストを共に全件読み込むことは出来ますが、分散しません…orz
これもAsakusaFW開発側では定数表という名称で呼ばれている機能ですが、後回しになってるような…。
Hadoopにはサイドデータ（分散キャッシュ）の機能もあるので、出来なくはない気はします。が、DSLの拡張は必要そうな気がします。
こうやって問題提起があると、どんな機能が欲しいかという参考になって良いですね。
次は、才所さんのAsakusa Framework（やHadoop）の動作検証や性能検証について。
才所さんはAsakusaFWの新バージョンが出る度に調査や検証をしているそうです。（異なるOSやHadoopディストリビューションやバージョンでの検証）
で、検証用プログラム（AsakusaFWのサンプルアプリケーションを拡張したもの）や検証データ作成用のスクリプトを自作しているそうです。
検証データは置いておくと大きくて大変なので、毎回作成し直しているとか。
VagrantとかChefを使って環境を構築しており、スクリプトの実行のデモが行われました。
この検証用ツールとかスクリプトはまだ個人的に作成中の段階だそうですが、既にGitHubで公開しているようです。
https://github.com/hsaisho/git-test
https://github.com/hsaisho/vg-test
正式にはOSSコンソーシアムのAsakusa Framework部会の成果物として公開する予定だそうです。
最後は、ノーチラステクノロジーズの川口さん。→資料
0.7.1で導入されたスモールジョブ実行エンジン、0.7.2のWindows対応の話でした。
（他にも、0.7.2ではHDPに対応したり、Hive0.14のParquetの新しいデータ型にも対応した模様）
Hadoopはギガとかテラとかの大きいデータが対象ですが、AsakusaFWではそんなに大きくならない場合があり、そういうときにスモールジョブ実行エンジンが有効。
目安としては、入力データが100MB未満、Hadoopジョブが40秒未満といったところ。
Asakusaアプリケーションでは昔からスモールジョブが問題になっていました。
バッチアプリケーションなので、補助データやエラーデータといった小さなデータが出てきてしまう訳です。
（AsakusaFWの思想として、例えば結合に失敗したデータもアプリケーションが対処する。SQLだと結合できなかったものは出力されないが）
スモールジョブ実行エンジンの特徴は、高速である・実行時に自動的に選択される・設定がシンプルである。
また、スモールジョブ実行エンジンを開発時のテストに利用することが出来ます。
サンプルアプリケーションの実行時間も46.2秒が5.5秒になったとか！
テストで使うためにはbuild.gradleを修正する必要がありますが、0.7.2では、Shafuを使ってスモールジョブ実行エンジンを有効にすることが出来るそうです。
（Shafuの場合はbuild.gradleの修正は不要だが、Eclipseでしか使用できない）
Shafuもバージョンが0.4.0になって、色々な機能が増えたそうです。
スモールジョブ実行エンジンを使うことでWindowsでもテストが実行できるようになるので、Windowsでコマンドプロンプトを使わなくても済むようにShafuの機能を増やしているようです。
Eclipseのみで環境が構築できるので、UNIX用のインストーラーであるJinrikishaを使うより楽かもしれないそうです。
ただ、WindowsではYAESSを使ったバッチの実行やHive連携の確認等は出来ません。
テスト用にバッチを実行する方法としては、バッチテストランナーというものが用意されているそうです。（知らんかった＾＾；）
あと、質疑応答として、スモールジョブ実行エンジンを拡張して大量データに対応する予定があるかという質問がありましたが、スモールジョブ実行エンジンは小さいデータに特化した実装になっている（らしい）こともあり、そういう予定は無いそうです。
他にもいろいろな質問があり、勉強会らしい勉強会でした(笑)
