2014/10/17『Asakusa Framework 勉強会 2014秋』に行ってきました。
今回の会場はサイトロックさん。
サイトロックさんはシステム運用をやっている会社で、噂には聞いていましたが、行ったのは初めてでした。食堂とかおしゃれな感じですね(笑)
最初は恒例の土佐さんの『Asakusa fwはじめの一歩 0.7.0』。
拙作DMDL EditorXですが、いくつか使用できない箇所があったようで＞＜
属性追加ウィザードの障害（issue42）は、自分の環境では再現しないんですよねぇ。
たぶんXtext内部の情報に不整合があるのだと思います。プロジェクトのクリーンをしたりdmdlファイルを保存し直したりすると直るかも？
フローのテストクラスの作成の障害（issue43）は修正済みです。
詳しいことはissueに書いておいたので、興味がある人は見てみて下さい。
テストクラスの作成と同時に出来るテストデータ用Excelファイルの雛形生成は最近の機能追加では一番の機能だったので、ぜひ試してみて欲しかったのですが＾＾；
これを使うと、AsakusaFW本体（Jinrikisha）のExcelファイルの雛形生成を経由せず、フロークラスで使用する各シートを1つのワークブックに収めたExcelファイルを生成します。
特に目次ページは便利だと思います！ LibreOffice Calcを使っていて不便だと思った箇所の改善に力を注ぎ込みました(笑)
あ。あと、Importer/Exporter作成ウィザードでモデル名と同名のファイルを作る際の指定は「${modelName}」（波括弧）ではなく「$(modelName)」（丸括弧）です。ちゃんと生成は出来ているようなので、単なる見間違いだと思いますがｗ
2番目は、MDIS武石さんの『Asakusa Framework 適用事例（業務系バッチ高速化）』。
実行時間が数日レベルの年次処理の一部をAsakusaバッチにした話でした。
Oracle10gで更新対象のテーブルが300くらいある内、85％は数秒～10分程度で終わるのでHadoop化せず、1時間以上かかる（最長4時間半の）更新処理10テーブルをAsakusaアプリで作ったそうです。FlowPartは処理対象テーブル毎に作ったが、Operatorはほとんど共通化したとのこと。
RDBとHadoopとの転送にはSqoopを使用しているそうで、Asakusa Frameworkが想定している形のひとつですね(笑)
それで、現行環境で270分だったのがHadoop環境で13分！
久しぶりにこういった時間短縮の話を聞きました(笑)
3番目は、@atsushi_nakataさんの『汎用機担当エンジニアだった私が体感したAsakusa Framework』。
汎用機を担当して4年目のエンジニアでJavaを全く知らないところから、44日間でAsakusaアプリを作るところまで行ったそうです。
44日の半分くらいはJava自体の勉強に使ったようなので、Javaを知っている人なら、1ヶ月もあればAsakusaアプリを作れるようになるという事ですかね(笑)
AsakusaFWのトレーニングを受講して、実行環境にはNode0 DBRを利用されたそうです。
実行の際にはHadoopクラスターのノード数を変えて試したりしたようで、Node0 DBRが想定している使い方な気がします。
これも5000万件（5GB）の処理が1時間16分だったのが7分になったそうで、速い！(笑)
拙作Toad Editorも使われたようで、ありがとうございます。
こういうエディターを作ってみた結果、GUIで図を描いて線でつなぐのは大変だと思ったんですが、演算子が数個というレベルなら大丈夫っぽいですね。
最後は、ノーチラス・テクノロジーズの川口さん。
前回の勉強会では「今後出る予定の0.7.0」の紹介でしたが、今回は「9月に出た0.7.0」をリリースノートやドキュメントを見ながらの紹介でした。
●Parquet/ORCFileというカラムナーフォーマット対応
データの加工はAsakusaアプリで行い、その結果をParquetやORCFileとして出力して、SQLで見られるといいんじゃないかという考え方のようです。
HDFSを対象にSQLを実行するツールはSQL on Hadoopと呼ばれており、今のところ代表的なのはImpala・Presto・Drillです。
Impala：Claudera。HDFS上のファイルを相手にクエリーを高速に実行するもの
Presto：Facebook。Amazon S3やRDBも併せたクエリーを実行できる
Drill：MapR。なんかまだまだらしい＾＾；
ParquetやORCFileは、同じカラムナーと言ってもやはり特徴が違うそうで。
ORCFile：Hive用としてHortonWorksが推している
Parquet：現時点のバージョンではDECIMALやTIMESTAMPが使えない
ImpalaはParquetにしか対応していない。Prestoは当初はORCFileのみ対応していた。Drillは両方とも対応している。
DMDLのDECIMALやTIMESTAMPを表現する都合上、@directio.hiveの属性が増えています。これはデータ型によって付けられるものが異なります。
DMDL EditorXでも入力補完機能では出せるようになっていますが、属性追加ウィザードでは条件判定は出来ないので、データ型に応じて自動的に切り替えることは出来ませんorz
また、ORCFileを作るのは、Pqrquetより少し時間がかかるそうです。
（重複データを排除するのでデータは小さくなる反面、重複データが少ないとディクショナリーを作るのにコストがかかる。
ただし将来のバージョンでは改善されるかもしれないし、マシンの性能によってはあまり影響が無いかもしれない）
ということで、AsakusaFWと直接関係無いながらも、勉強になる話でした。
●Hadoop2対応
代表的なHadoopディストリビューション（CDH4・MapR4・EMR AMI3）はHadoop2に対応してきており、Apache Hadoopも1系はもうあまり開発されていないそうです。
ただ、スタンドアローンではHadoop1系の方が速いので、AsakusaFWとしては、開発はHadoop1で行い、運用環境はHadoop2になるだろうという想定をしているようです。
という訳で、AsakusaFW0.7.0では切り替えが簡単に出来るようになったそうです。 →デプロイメントガイドの『Hadoop2系向けの構成』
他にも設定ファイルを同梱したり置換したりしてアーカイブを作る機能も加わったようです。これは後で要チェック！
●テストドライバーの改善
個人的には（アプリ開発としては）ここが一番大きいと思っていたところなんですが、時間が押していたので省略されました(爆)
●実行時パフォーマンスの改善
Hadoopジョブ間の中間ファイルを、今まではHadoopのシーケンスファイルを使っていたが、それをやめてシンプルなファイルにし、snappy圧縮もするようになったそうです。
（中間ファイルのデータサイズが大きいアプリケーションでは改善が見込める。しかしI/Oコストは減っているがCPUを使うようになったので、性能は一概には言えない）
それと、CoGroup演算子でESCAPE指定をした際の内部構造がチューニングされ、けっこう速くなったらしいです。（というか元が遅すぎたんだとか＾＾；）
●IntelliJ対応
IntelliJ IDEAに対応したそうです。
でもDMDL Editorは無いよ！(爆)
