2014/7/11『Asakusa Framework 勉強会 2014夏』に行ってきました。→Togetter
アンケートによると参加者はAsakusaFW経験者4割（Hadoop経験者は6割）という感じで、まだまだAsakusaFW初心者の人が参加して下さっているようで、嬉しいことです。
最初は恒例、土佐さんの『Asakusa Framework はじめの一歩（ver 0.6.2）』。現時点のAsakusaFWの最新版である0.6.2に合わせたものですね。
前回はライブコーディングによるAsakusaアプリケーションの作成手順の紹介でしたが、今回はスライドによる紙芝居でした。手順を再現していると結構時間ぎりぎりになってしまい、ライブコーディングだと突発的なトラブルがあったときに困りますからね＾＾；
土佐さんの資料のp.5からのAsakusaアプリケーション用プロジェクトの作成には、AsakusaFW本家のEclipseプラグインであるShafuの機能を使っています。
p.12以降は拙作のDMDL EditorXのウィザードが使われています。ありがとございますｗ
全くAsakusaFWを知らない人向けに少しだけ補足しておくと、AsakusaFWではバッチ（ジョブ）の入出力をImporter/Exporterで表します。これはファイルの場合はパス名・ファイル名、RDBの場合はテーブル名等を指定するものだと思えばいいでしょう。
データモデルはファイルレイアウト（テーブルレイアウト）を表すもので、DMDLという言語で記述することにより、Javaのクラスを生成します。
処理を記述する「演算子」では、DMDLから生成したクラスを入出力に使います。
また、2種類のデータモデルを結合（SQLのJOIN相当）したい場合、AsakusaFWでは「結合モデル」というデータモデルを記述します。p.30辺りですね。
p.24で結合キーを指定していますが、左側で2種類のデータモデルのキー項目を同時に選択してコピーすることでも定義できますし、addボタンを押して空の状態から選択することも出来ます。まぁ、いずれにしても言葉では説明しづらいのですが(汗)
p.30で既存モデルにプロパティー（項目）を追加したデータモデルを定義しています。
copyボタンで既存モデルの全プロパティーをコピーしていますが、referenceボタンでモデル名だけをコピーすることも出来ます。こうすると、「output_sales = joined_sales + { flg:TEXT; };」という形式のモデルを定義することが出来ます。
プロパティーの実体としては土佐さんの方法と同じものになりますが、元となるモデルに変更があった場合も追随してくれるという利点があります。
p.43からはImporterクラスを作っています。2つのImporterを別々に作っていますが、複数同時に作ることも出来ます。
ファイル名のところに「$(modelName).csv」と書いておけば、生成されたクラスのファイル名部分がモデル名に置換されます。
p.56からは拙作のAsakusa Toad Editorを使ってジョブフローを作っています。
p.67でImporterを配置していますが、既存のImporterクラスを配置したい場合は、左側のパッケージエクスプローラー上でImporterクラスをドラッグし、ジョブフローのエディター上にドロップすることも出来ます。
p.102でも同様に、バッチに既存ジョブフローを配置したい場合は、パッケージエクスプローラー上のジョブフローのtoadファイル（もしくはジョブフローのjavaソースファイル）をドラッグしてバッチのエディター上にドロップすることも出来ます。
p.116では、Shafuを使ってテストデータ記述用のExcelファイルを生成しています。
ちなみに最近のDMDL EditorXでは、Excelファイルの生成とp.121のテストクラスの作成までウィザードで行うことが出来ますｗ
こういったDMDL EditorXの（既にDMDLと関係ないし！と言われている）機能もどこかで紹介したいですね～。
2つ目はノーチラス・テクノロジーズ川口さんの『Asakusa Framework 歴史探訪 & ここ最近の新機能』。
AsakusaFWはDSLとテストを一体化して使うよう考慮されており、かつ外部連携も無いとシステムとしては役に立たないので、そこも考えられているとのことです（WindGateやDirect I/O）。
AsakusaFWはおおよそ2～3ヶ月ごとにリリースされてきましたが、DSLはほぼ変わっていないので、バージョンが上がってもマイグレーションは容易になるよう考慮されています。
（実際、バージョンを上げる際、設定ファイルをいじったりする必要はありますが、DSL（プログラム本体）を修正する必要は（たぶん今までは）無かったと思います）
最初はDMDLは無くてThunderGateのDDLからモデルを作っていたとか、聞いたことはあったような気はしますが、既に忘却の彼方でした＾＾；
比較的最近AsakusaFWを使い始めた方々にとっては、多少なりとも経緯が分かって面白かったのではないかと思います。
p.10に書かれているParallelJobSchedulerは、AsakusaFWのコンパイル結果である「stage」（Hadoopジョブに相当）を、可能であれば並列に実行するスケジューラーです。
これは実行環境のASAKUSA_HOME/yaess/conf/yaess.propertiesを書き換えることによって使えるようになります。
デフォルトではBasicJobScheduler（stage（Hadoopジョブ）を直列に実行する）が有効になっています。
p.11のDirect I/Oで「クラスター上のデータを使い回す（キャッシュ）」と書かれていますが、この意味は、「バッチ実行開始時に毎回WindGate等でRDBから取ってきてHDFS上にファイルを置く」のではなく、「（以前に）HDFS上に置かれた（キャッシュされた）ファイルをそのまま読み込む」というような意味だと思います。
p.18（AsakusaFW0.6.1）のエミュレーションモードは、フローのテスト実行時にOperatorクラス内でEclipseのブレークポイントを指定して止められる機能です。変数の中身が見られます。超便利ですｗ
p.13やp.19に出てくるスモールジョブは、Asakusaアプリケーションを書いているとちょくちょく遭遇する問題です。
なにせHadoopはタスク起動に時間がかかる（いわゆるHadoop税）ので、たとえ入力が少量であっても一定時間かかってしまうのです。Hadoop2になるとUberモードというのがあってけっこう速いらしいので、けっこう期待大です。
それと、近日公開予定のAsakusaFW0.7の紹介がありました。
Direct I/Oによる入出力ファイルに、HiveのORCFileやParquetという形式が使えるようになるそうです。（ほんと最近はHadoop上のSQLが流行ですね＾＾；）
3つ目は、OSSコンソーシアム Asakusa Framework部会の才所（さいしょ）さん。
2010年末（Hadoopが有名になりつつあった頃？）からビジネスになるものを考えて、AsakusaFWに注目したそうです。
AsakusaFWの利点として以下のような点を挙げていました。
- 教育サービスがある（いざ始めようとしたときになんとかなる（SIerとして嬉しい））
- 日本語で（日本の文化で）相談しやすい
- 日本のビジネス時間で進む（海外製だと、最終的には本国に問い合わせたりして時間がかかる）
ただ、やはりJavaによるAsakusa DSLの初期のとっつきにくさや分散処理固有の設計をしなければならないといった難点もある。開発者も1～2ヶ月で慣れた（壁を越えた）というものの、最初はやはり難しいようです。
Hadoopを知っている人（特にMapReduceで苦労した人）には高評価だそうですが、そうでないと…＾＾；
しかしバッチを高速化したいという場面は存在するので、ビジネスになるはずだと考えているそうです。
で、Asakusa Framework部会にはビジネスWG（Working Group？）（だったっけ？）と技術WGがあり、技術WGではCDHの基礎データを取ったりしてきたそうです。今後はMapRのデータを取ることもあるかも？
ここからは個人的な感想ですが、AsakusaFWはバッチアプリケーションを作るフレームワークなので、試すのにもちょっと敷居が高い。例えばウェブフレームワークだったら「個人的にちょっとサイトを作ってみるか」といった試し方も出来るでしょうが、「ちょっと個人的な分散処理バッチを作ってみようか」なんて、そうそう無いですよね＾＾；
そういう意味では、個人以外に、ビジネスWGのような形で企業として集まって色々検討していただけるのは向いているのではないかなーと思います。
4つ目はアクセンチュアの福垣内（ふくがうち）さん・広島県出身。
ウェブサイトの分散分析基盤をEMR＋AsakusaFWで作ったそうです。
もともとRDBで分析していたけれども数千万件ではそろそろ厳しい、高価なBIツールまでは不要、ということでHadoopは集計が得意なのでHadoopを使うことにしたそうです。
他にRedShiftやHANA・Oracleも検討し、リアルタイムで見たい場合は有利だけれども、初期導入費用が高い（RedShiftも1ヶ月で70万円とか！）ので、見送ったようです。
Hadoopシステムの構成としては、MySQL→S3→EMRで集計→S3→MySQLという、ある意味鉄板な構成でしたｗ
当初はWindGateでMySQLにアクセスしたようですが、遅かったのでDirect I/Oにしたそうです。（その参考にした資料がこれだとしたら、役に立って嬉しいのですがｗ）
1人が2週間くらいでこの環境を作れたそうです。
ちなみにオンプレミスでHDFS・HBase・Hive・Pigの環境を作るのには1ヶ月ほどかかり、今後のメンテナンス性を考えて現在の環境を選択したそうです。
（Eclipseは色々言われるけれども＾＾；）普通のプログラマーはやはりEclipseを使うので、その点も良かったようです。
AsakusaFWに関しては、やはりトレーニングを受けていないと用語や演算子・機能のとっかかりが難しいようです。
そういうのは個人のブログで説明したりするのも大変なので、難しいですねorz
今後はSparkとの使い分けなども考えていくそうです。
そういえば質問しそびれたんですが、よくある集計処理だとそれこそHiveでやっちゃったりしそうな気がするんですが、AsakusaFWを選んだ理由（あるいはAsakusaFWを選んでHiveより良かった点）は何だったんでしょうね？
次回は『2014秋』、の前に『真夏』をやるそうです。
そうきたか！ｗ
