#hcj13w 午後5.Asakusa Framework

Hadoop Conference Japan 2013 Winterの午後5（会場：1B）『AsakusaによるHadoopでの業務系バッチ処理の課題と解決』のメモです。
講演者はノーチラス・テクノロジーズの神林 飛志さん。（→資料は非公開だそうです）
なんだけど、資料の内容は社内でダメ出しをくらったらしく、ノーチラス・テクノロジーズの見解でなく神林さん個人の意見ということでの発表だった＾＾；
Hadoop Conferenceはお祭りだからということで、ポジショントークも無しで、神林節全開という感じｗ
のっけから、自己紹介しませんとか、Asakusa Frameworkを知っている前提で話しますとか！（第三者として聞いている分には楽しいんだけど(汗)）
AsakusaFWは裏トラックとか言ってるし。（お金が…とか言っていたのは、会場1AのTwitterのリアルタイム解析の話らしい。Twitter社からツイートを買うのにすごくお金がかかっているらしい）

えー、気を取り直して＾＾；

Asakusa Frameworkの事例で新しいものは出せないけれど、水面下で進んでいるものはあるがNDA（秘密保持契約）があるので表には出せない。夏か秋には出てくるかも。
小規模なものも大規模なものもある。実証はだいたい完了し、本番系への歩みが始まっている。

---

そして問題も顕在化している。

１．スモールデータとショートバッチの問題
実際の大規模な業務バッチのフローの一部のスライドが出ていた。あれでも一部だそうだが。
そういうフローが1500段くらいあるバッチ（Hiveでは無理でしょう）が、AsakusaFWでは書き切れる。その為にこの問題が顕在化した。すなわち、データ量が少なくて実行時間が短いジョブが多くなってしまう。
挙げられていた表は、左の方が実行時間が短いジョブ（一番左は1分以下）で、右の方が長いジョブ（10分くらい）。各列の棒グラフはジョブ数を表している。
右の方はHadoopでなければもっと時間がかかるものなので、それ以上は短くならない。それにジョブ数も少ない。
問題は一番左のジョブで、1つは1分以内だけど7000個もある。これらを合算すると、トータルとしてバッチ全体の実行時間があまり短くならない、ということになってしまう。
短いジョブの個数が少ないなら目をつぶることも考えられるが、往々にして99:1にもなってしまう。 

理想としては、短いジョブにはHadoopを使わないようにすればよい。小さいデータならRDBMSを使う従来のバッチの方が速い。
が、開発中にどの部分が小さいかを予測するのは困難（意識する人は少ない）だし、後から変わっていくこともある。
また、プロダクトを2種類扱うのも敷居が上がってしまう。（AsakusaFWのみで開発したい） 

２．データ転送
データ転送のボトルネックの話。
BIや集計系のバッチでは出力データが減るが、業務バッチでは減らない（むしろ増える）ことがある。
1500段もあると、失敗したときに最初からやり直せばいいという単純なことにはならない。

３．運用ツール
リラン等のやりやすさ。

---

●解決策１．（スモールデータとショートバッチの問題）
小さなジョブはRDBMSで処理すればよい。それを透過的に扱って（自動的に判断して）欲しい。
という訳で、次世代AsakusaFWでは新しくAsakusa実行エンジンというものが出来る。（コードネームはFireworks（花火））
RDBを使って実行するRDB Controllerと、今まで通りHadoopで実行するMapReduce Controllerができ、mediator（調停者）が振り分ける。
（作っている人の名前から、ueshional engine（うえしょなるエンジン）と呼ばれていたこともあるｗ（ちなみに@ueshinさんと言えばHBase。つまりRDB以外にHBaseも対応される可能性が…？！ｗ））
（まぁHBaseはともかく、）他にも速い基盤が出てくれば、それに対応することは考えられる。

これはつまり、実行時最適化を行うということになる。
・トランザクション処理の方式が変更になる
・インポートデータの再利用
・データの先読みも可能

また、Asakusa DSLの中間表現が導入される。
DSLと実行計画が分離されるので、自分用のDSLが作れるようになる（中間表現を出力すればよい）。

Asakusa DSLそのものにも拡張が入る。
・レンジ結合（BETWEENで結合）
・定数表の導入（マスターデータのような感じの固定データをフローの入力とせずに使用できる？）
・任意の演算子で結合処理が可能（今は結合用の演算子が準備されている）

これにより、Hadoopをかなり隠蔽することになる。

●解決策２．（転送ボトルネック）
RDBMS→Hadoopについては、fluentdとか使えばいい。（同時間帯に7階で発表されていたｗ）
問題はHadoop→RDBMSで、RDBがボトルネックになる。Sqoopを使うとかバルクロードとかインメモリーDBを使うとか、総力戦。
（Sqoopは、PostgreSQL用のdirectモードのパッチをNTTデータの方が作っていましたし）
ただ、これらはAsakusaFWは関係ない。

AsakusaFWとしては、データ転送順序の変更で対応する。（解決策１の実行計画に関連）
空いているI/Oがあればそこを使う。（ジョブが始まる前でも（トランザクション等に問題が無ければ）先読みするとか）

また、EAIツールとの連携も考えられる。
・データスパイダー
・アステリア

その他に、共有ストレージを使う。（東芝のは良いらしい。他のは自粛ということで、ここでは書きません＾＾；）
CDHよりMapRの方が速いとか。

●解決策３．（運用ツール）
ジョブ管理基盤を作成中。コードネーム：Nakamise
「なんとか変更履歴のブログを書いている人」とか言って誰にも通じてなくて滑ってたけど、さもありなんｗ（ueshional engineの人とは知名度が違うのでｗ）
ちなみに「UIが得意な人」は、JavaFX関連でTwitterを見ていると見つかるかも？ｗ
で、Nakamiseは、Asakusaアプリを実行・停止したり再開させたりするもの。（YAESSは実行のみ）
JP1/A-AUTO/Senjuと連携する。

---

後は与太話とのことで、AsakusaFWとは関係ない話。
だけど、どこまで書いていいのかなぁ＾＾；　えーと、無難そうなところだけ書きます。。

RDBMSの逆襲が始まる（ただしそのままでは来ない）。
・transaction制御
・logとrecoveryの応用
・query optimization

Impalaは「リアルタイム」ではない。Hiveと比べると速いがRDBMSと比べると遅い。「リアルタイム」という言葉を不用意に使うと色めき立つ人達がいる＾＾；
エンドユーザーの3秒ルールというものがある。（ユーザーは3分以上だと壊れたと思う、30分経つと席を立つ）

AWS
ほぼ一年間使ったが、致命的な問題は無し。キックでこけることがあって、それは自分で何とかする必要がある。