Asakusaでの設計・実装の方法についてのドキュメント
Asakusaのドキュメントを大幅に見直し+追加しました。自分の担当は設計関連の部分だったので、その辺の“あとがき”的なものを以下。自分で書いて気になったところもまとめて置く感じで。
http://www.asakusafw.com/techinfo/methodology.html
1.設計手法について
理論的な背景はともかく、業務バッチ処理をどのように設計するか、ということについての一つの「やり方」を書きました。これは完全に経験則と過去の方法論の掘り起こしによるものです。基幹バッチ処理をデータフローで、ゼロから設計するという手法は、周りを見るところ、ほぼ完全なロスト・テクノロジーになってしまっていて、ちょっと見当たらないです。（調査が足りないという話もありますが）
データフローベースの、（有り体にいうとCOBOLライクな環境での）バッチの作成は、現状では、メンテナンスで既存に手をいれるか、既存プログラムのストレートコンバージョンまたは改変での作成ぐらいしか機会がありません。つまり、「素から業務バッチを設計する」という経験は、実はそれほど転がっているものではなく、しかも、これがまた資料や書籍もありません。通常はSQLベースで苦労している、というケースがほとんどです。この場合は集合演算で、連続的に処理していくちょっとしたパズルになる上、実際の物理データの実装と離れてしまうことが多く、なかなか直感的に記述することが難しいです。
バッチやオンライン云々という話題からは離れて、「データフローベースで一連の処理を連続的行って結果を取得する、これを効率的に設計する」という技能は、個人的には、SEであれば持っていた方が良いと思っています。このドキュメントが正解だとは思わないけれど、今後のそのようなことをやらなければならない時に何かの一助になればと。
それで中身は？の詳細は内容を見てもらうしかないのですが、種を明かすと、基本的な流れはジャクソン法に、STS分割＋CRUD記法を加えて、オブジェクト指向の話をヒントにしたという内容になっています。一昔前の構造化手法をかなり援用しているので、キャリアのある人が見ると、「まぁパクリというか、言われてることをまとめただけという側面もあるね」という風にもみえると思います。
正直言ってHadoopへの依存度はゼロに近い、というかゼロですね。なお、AsakusaDSLがベースになっているので、そのまま他の言語でということではそれなりハードルはあると思います。が、一般的なデータフロー言語であれば、実装ができるように設計手法をまとめている（つもり）です。
また実装手法においては、より具体的に演算子の使い方を解説しています。よりクックブックに近い書き方を選択しました。実際に処理を記述するときに、利用しやすいように記述した（つもり）です。特に、Asakusaでは、実装時点でどの演算子を選ぶか？ということは、かなりパフォーマンスに影響します。困ったときの一択でCoGroupを選択することが多いと、コンパイラの最適化が効きにくく割と残念な結果になることも多いです。そうならないように、このような場合はこうすると良いという指針を書いたつもりです。
2.ケーススタディについて
ケースは「POSデータの集計バッチ処理」をあげています。といってもBIではありません。「売上の確定処理のバッチ処理」の概略をサンプル的に入れています。実際のバッチはこれほど簡単ではなく、この十数倍は面倒です。ただ、業務バッチのエッセンスは伝わるようには、気を配っている（つもり）です。データをクレンジングして、エラーデータを弾いて、集計処理＋伝票イメージの作成になっています。処理の半分がデータクレンジングになっているのは、実際の業務バッチが大抵はそうなっているからです。こうすれば使えます的なケースではなく、「本当に実際に使うにはどうしたらいいか」と言う点にケースの記述のポイントを置いています。消費税の内税剥がし計算とか客数distinctとか分散カテゴリー集計とか、かなり「それなりのケース」になっています。いきなりの初心者にハードルはあるとは思います。が、業務バッチは遊びではないので、そのあたりは理解して欲しいなと。割とくどい位、エラー処理については、設計でも実装でもケースでも書いたつもりです。尚、指摘があるとすれば、マスターデータのモデルだと思いますが、これについては次で述べます。
後書き
以下、自分で書いていて補足した方がいいな、とは思ったけど公式には書けなかったことを書いておきます。
3.データモデル
特にケーススタディを見ればわかりますが、マスターデータのモデルがかなり貧相です。現実のマスターはこれほど内容がないことはありません。場合によっては数百近いフィールドが並ぶことが通常でしょう。ケースでは、これは思い切って取捨しており、必要なフィールドだけをモデリングしています。これはTXデータモデルをまずはちゃんと理解する、ということが肝要だという考えになっています。
あと現実的には、現在のAsakusaがComplexDataTypeをサポートしていないこともあります。（擬似的につくればできますが、それはサポートしているとは言わないでしょう。）この部分は今年の近々解消する予定です。
https://github.com/asakusafw/asakusafw/issues/39
そもそも、現状のHadoopやらKVS系の並列処理は構造化データに、疎い部分が常にあります。非構造化データを取り扱うことが多いということが原因でしょう。これはPig/Hiveでも弱い。ただ、非構造データといっても一定のスキーマが与えられた瞬間に「構造化」データになるわけで、純粋に非構造な状態は最初のエントリーの状態だけのはずですが・・・今後の課題の一つにはなるとは思います。KVS系のDBが今ひとつ普及に弾みがつかないのは、このあたりも原因でしょう。構造化データと非構造化データのやり取りや、あり方については、実は汎用機時代からもあることはあるし、過去のいろいろな考察や実践があるので、車輪の再発明をするよりも温故知新的に埋もれたノウハウをいろいろ勉強できるといいな、と個人的には思っています。
マスターデータについては過度に構造化する必要はないと思いますが、最低限の構造化の手法は必要だと思っています。どの程度までデータタイプを考慮する必要があるかは検討の必要があると思いますが、ArrayedList的なものはないとまずいとは思っています。
4.集計処理
ケースの集計処理や、実装手法の演算子の利用法も見てわかるとおり、集計の方法として分散集計処理を行っています。ここが分散処理の「華」の部分になっています。
補足します。えっとまずツリー構造の集計手法は並列処理では大きくは2パターンあります。
4-1.幅優先探査を利用する方法
最下層から層単位で、並列処理を行い、階層をあがる度に集計していく方法。一種の王道で、教科書的な扱いになります。・・・ただし、MapReduceよりもおそらくBSPやMPIの方がもっと高速に処理できると思います。このあたりは、後述するようにデータ量と通信コストに依存します。
この方法については以前にも書いている幅優先で並列的にノードを辿る方法になります。以前にかいているパターンの代表例の一つでしょう。
http://d.hatena.ne.jp/okachimachiorz/20110611/1307760564
4-2.集計すべきキーを一度にばらしてしまい、木構造をフラット化して、冗長性をかまわずに一気に分散集計する方法
ケーススタディはこの方式を利用しています。データ量がメモリーに乗り切るような場合&&通信コストが高い場合はこちらの方が速いです。ただし事前のキーの展開に時間がかからないことが重要です。大抵の場合キー自体が重いことはないので、BOMのような場合は、いわゆるフラットBOMに展開し直して分散集計した方がよいです。あとは集計データが可能な限り単ノードに集約されることがポイントになるので、データ量が大きい場合は、効率は良くはないですね。ケーススタディではデイリーの処理を想定していますので、それほど大きなデータは想定していませんが、数年分をまとめて処理する場合は戦略は変えた方がよいでしょう。
図で書くとこんな感じですね。
フラット処理は完全に冗長な処理になります。最上位の計算は最下層の構成要素を全部一気に集計する形になります。
5 結論みたいなもの
やはり業務系の集計処理やマッチングで特にバッチ系のものには並列処理は向いていると思います。今後は、実装手法は勿論、設計手法をさまざまに検討されるでしょう。ケーススタディの集計の手法も、データ量とを勘案して、BSPやらMPIといった処理が現実的になれば、実際に5分以内で処理を終了するということも可能になると思います。BOMあたりの計算も現在、数時間が普通というものを多いですが、数分という単位になることも夢ではないと思います。
あと、設計手法については、可能な限りエンドユーザーの人が見てもわかるようには書きました。というか、特にユーザーの人には「こんな処理がHadoopで走りますよ」わかって欲しいということもありまして。
