第3回と第4回では、Asakusaを使ったバッチ処理アプリケーションの設計方法について解説する。Asakusaでは、Batch DSLで記述する「バッチ」、Flow DSLで記述する「ジョブフロー」と「フロー部品」、Operator DSLで記述する「演算子」という三つの階層で、アプリケーションを構成する。
なお今回解説する設計技法は、Hadoopへの依存度を極力なくすことを意図している。Hadoopへの依存度が高いと、設計者がHadoopをマスターする必要があり、開発規模を拡大する足かせになるからである。以降は「クラウド時代の非同期処理設計の一般技法」と捉えてもらっても差し支えない。
有向非循環グラフ「DAG」を使って開発する
Asakusaでの設計では、DAG（Directed Acyclic Graph）を用いる。DAGは、図1に示したような有向非循環グラフのことである。処理を表す頂点を、データを表す辺でつなぐ極めて一般的な記述方式だ。ただし循環しないこと、辺には単方向の向きがあることという制約が付く。
必要なDAGを設計すれば、「何も考えずにそのまま」DSLに展開できる。これがAsakusaの大きな特徴である。DAGは、従来の設計手法で言えば、DFD（Data Flow Diagram）の記法に近い。データの流れが辺にあたり、データの処理を表す部分が頂点にあたる。データの流れが単方向であることも同じである。ただしDAGでは、基本的に循環は許さない点と、頂点として物理データを表すことがない点、データストアを明示的に記述しない点が異なる。これらの点に注意すれば、DAGとDFDの表記は、ほぼ同じだと思ってよい。
なおDAGで表現できた内容は、そのまま行列表現やリンク付きリストで表現することが可能であり、数学的な操作ができることが広く知られている。
DAGを使った設計の流れは次のようになる。DAGによる設計は、業務分析から始まる。以降、徐々に処理を細分化し、詳細設計にまで落としていくことになる。この手順をアジャイル風に実施するか、ウォーターフォール方式で行うかはプロジェクトの進め方に依存する。一般に基幹バッチ処理の場合、開発に参加する人数の多さや、そもそもの仕様の堅さから見て、ウォーターフォール方式が有効である。
