データフローDSL考

ニコニコ超会議 2012の超エンジニアミーティングのScalaユーザーグループのコマで「Scalaでプログラムを作りました」のセッションを行いました。昨日の「Scalaへのアプローチ」はそのまとめです。このセッションの主張の一つがScalaの最も重要な用途がDSLであるということです。

3月に要求開発アライアンスでオブジェクト指向モデリングと関数型の関係を検討したセッション『Object-Functional Analysis and Design: 次世代モデリングパラダイムへの道標』を行いました。その内容のまとめは「Object-Functional Analysis and Designまとめのまとめ」となります。ここでは、OOADと関数型の接点としてデータフローが重要というのが結論でした。データフローの実装技術についても「データフローの実装技術」として考察しました。

この2つのセッションで共通に使用しているスライドが以下の「SparkとScalding」です。

オブジェクト指向、関数型、クラウド・コンピューティングの交差する技術領域では、データフローをいかにテキストDSLで記述していくのかという点が、非常に重要な論点になっていると考えます。

SparkやScaldingは、関数型言語の普通の記法でそのままHadoopなどの大規模並列分散計算基盤上で動作するフレームワークAPIを提供しています。これはかなり強力で、もしかして決定版かも、と思わせます。

この点について考える前に、この分野の定番技術であるデータフロー図についてみてみましょう。

データフロー図

OOADでは、主流からフェードアウトしてしまったデータフロー図ですが、クラウド・コンピューティングの登場によって、再び第一級のモデルになってきそうです。

古(いにしえ)の基幹システムはバッチ処理の集りなので、バッチ処理をデータフローでモデル化したものをシステム全体の機能モデルとして扱っても十分に機能していました。

当初OOADにおいてもデータフロー図は、機能モデルを記述する目的を期待されていましたが、インタラクション、コラボレーションをうまく記述することはできないので、システム全体の機能モデルを記述するのには力不足で、最終的にはユースケース・モデルに取ってかわられたという成り行きだったと思います。

とはいえ、バッチで実行するような複雑なデータ処理演算のモデル記述するのにはデータフロー図は引き続き有効です。(ただ、最近は基幹系でもデータフロー図がロストテクノロジーになっているという噂も聞きます。)

クラウド・プラットフォームによって大規模データ、大規模演算が可能になったことによって、扱う計算過程も複雑になってきます。データフロー図は、システム全体の機能モデルを記述するには向きませんが、こういった計算過程を記述するのには有力な候補になります。そういう意味で、大規模データ、大規模演算の分野での第一級モデルとして再評価されることになるのではないかと思います。

簡単な例

まず、シンプルなデータフロー図は以下のようになります。

ここでは、外部実体としてメインのRDBMSに格納されているエンティティ、データストアとして中間データの格納庫(カラム指向のNoSQLでの運用をイメージ)、という運用を想定しています。

このように一直線のパイプラインの場合、前述のSparkやScaldingによる関数型プログラミング的な記法がぴったりはまります。

複雑な例

しかし、現実のバッチ処理はもっと複雑です。たとえば、以下のようなデータフロー図は普通にありそうです。

この図のモデルに対して、テキストDSL化のポイントとなりそうな点に注釈を入れたものが以下の図です。

この図では以下の問題を挙げています。

• 複数エンティティの入力
• 複数エンティティへの出力
• データフロー中からの入力
• データフロー中からの出力
• データフローの分岐
• データフローの合流
• データストアの使い回し(メモ化)

関数型プログラミングでは:

• (SparkやScaldingの例で挙げた)パイプライン的な記述
• 引数N個の関数の入れ子

の2つの選択肢があります。

「パイプライン的な記述」は、データフローが「簡単な例」にあるようなシンプルな場合はよいのですが、「複雑な例」にあるような込み入った物なってくると記述できなくなるのは明らかです。

DSLとしてはちょっと煩雑な記述になりますが「引数N個の関数の入れ子」方式では、入力側を枝、出力側を根にした木構造を持つデータフローを記述することができます。さらに出力側にタプルを用いることで出力側を木構造に開いていくことも不可能ではありません。

しかし、この方式は「データフローの合流」が登場してモデルが木構造の範疇を超えて、グラフ構造になってくると記述ができなくなってしまいます。

つまり、データフローをテキストDSLで記述する方式もなかなか簡単にはいかないわけですね。この対策について、次回考えてみたいと思います。