データフローの実装技術

要求開発アライアンスのセッション『Object-Functional Analysis and Design: 次世代モデリングパラダイムへの道標』で使用するスライドについて背景説明を行っています。

• 関数型言語の技術マップ
• オブジェクト・モデリングのボトルネック
• 代数的構造デザインパターン
• 圏論デザインパターン
• オブジェクトと関数の連携(1)
• オブジェクトと関数の連携(2)
• オブジェクトと関数の連携(3)

今回は背景説明第8弾として、「データフローの実装技術」として用意した以下の図を説明します。

オブジェクトと関数の連携(3)では、オブジェクト・モデリングと関数型の連携ではデータフロー・モデルが重要な位置付けにあることを説明しました。

そこで重要になってくるのが、データフロー・モデルを関数型言語の世界でどのように実現してくのかという実装技術です。

このスライドでは、その具体例としてボクが注目している3つの技術を挙げています。

A Unifiying Framework for Structured Analysis and Design Models

A Unifiying Framework for Structured Analysis and Design Modelsは、SA/SDの代表的な技術であるYourdon法、DeMarco法、Jackson法でのデータフロー記述Structured Chart、Data Flow Diagram、Structure TextをInitial algebraという代数で記述して、圏論の枠組みで統一的に操作する試みです。

代数、圏論ベースの形式的な記述を行うので、関数型との相性はよいと思われます。

この書籍が当該研究分野でどのような評価を受けているのかはボクは知らないのですが、関数型とクラウドコンピューティングの接点として重要な位置付けになるのではないかと考えているデータフロー・モデルと、関数型をつなげる理論的なバックグラウンドとして面白そうなので、ぼちぼちチェックしているところです。

SA/SDのデータフロー図を関数型言語に変換したり、関数型言語でデータフローを記述するためのベースにしたり、といった方向に延ばせるのではないかと考えています。

AsakusaFW

• http://www.asakusafw.com/

データフロー的なモデルを専用Java DSLで記述してHadoop上で実行するためのバッチ実行フレームワークです。基幹業務で用いられてきたCOBOLバッチ的なバッチ処理をクラウドプラットフォーム上で超高速に実行します。ジョブ管理などバッチ処理のインフラがフルセットで揃っていることが特徴です。

データフロー的なモデル(AsakusaFWではDAGと呼んでいます)の詳細は「Asakusa DSL設計手法」が、データフローをベースにしたバッチ処理の実現技術は「Asakusa DSL詳細設計および実装技術」が参考になります。

現在はJava DSLベースですが、Spark的なアプローチで関数型のプログラミングモデルと統合するのも面白そうです。

Spark

• http://www.spark-project.org/

SparkはApache Mesos上で動作するクラスタ計算システムです。Scala言語に統合されているのが特徴です。

具体的にどう統合されているのかというと、以下のプログラムを見れば一目瞭然です。これはHadoopでも例題によく用いられているワードカウントのプログラムですが、通常の関数型プログラミングの範疇で簡潔に記述できています。

val file = spark.textFile("hdfs://...")
 
file.flatMap(line => line.split(" "))
    .map(word => (word, 1))
    .reduceByKey(_ + _)

Sparkの並行処理計算インフラをモナドの計算文脈の裏側に隠蔽して、プログラマには、通常のMonadicプログラミングでの記述を可能にしているのです。クラウドコンピューティングにおいて関数型言語に期待されている機能をぴったり実現しているので、かなり有力なのではないかと思います。

Sparkの記述力はこれから調査する予定ですが、「A Unifiying Framework for Structured Analysis and Design Models」での代数で記述したデータフロー・モデル、ScalaのMonadic演算の記述力、Sparkでの実現方式を付き合わせることで、クラウド・コンピューティングにおけるデータフロー・モデルと関数型プログラミングの接点が見えてくるのではないかと考えています。

Hadoopの置き場所

土曜日に書いたアーキテクチャは、Hadoop座談会で得られたインスピレーションによるものでしたが、肝心のHadoopの置き場所を考えるのを忘れていました。
そこで、考えてみたのが以下の図です。

アーキテクチャ的には、MapReduceやその実装としてのHadoopだけでなく、より汎用的な概念の導入が有効ではないかということでBackground Computingとしています。
さらに細かく考えていくと、Background ComputingもBatchとRealtime(Streaming)に分けることができそうですが、これはいずれ。

ボクは、クラウドアプリケーションとは、非同期に発生するイベントを連続して受け取りながら、イベント受信をうけて内部状態を刻一刻と遷移させていくオブジェクトと考えています。右の図はこのあたりをJJUG CCC 2010 Fallでお話した時に使ったものです。
この中で、インデクサとしているものが、上の図のBackground Computingに相当します。
クラウドアプリケーション自身はイベント駆動で動作しますが、その応答性能や結果精度を向上させるために、必要な情報をバックグラウンドで常に作り続けているのも、クラウドアプリケーションのもうひとつの側面になります。
この部分の実現機構として、MapReduce/Hadoopが重要な選択肢というわけですね。

Hadoopを組み合わせるということで具体的に考えてみると、HBaseはカラム指向データベースということに思い至りました。アーキテクチャ素案では、ドメインサービスのメインデータベースはインメモリデータベースで、このバックアップとしてカラム指向データベースを併用しています。このバックアップデータベースをHBaseとすることで、Hadoopとの連携をシームレスに行う事ができるようになります。

Background Computingの結果は、バックアップデータベースに直接戻すケースと、イベントとして通常のデータ更新ルートに載せるケースの両方が必要でしょう。
そのあたりを図に追加しています。