データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理

11章ストリーム処理

うまく動作する複雑なシステムは例外なく、うまく動作するシンプルなシステムから進化してきたものだ。この逆の命題も正しいように思われる。すなわち、最初から複雑に設計されたシステムがうまく動作することはなく、うまく動作するようにすることもできない。

――John Gall, “Systemantics”（1975）

10章では、一連のファイルを入力として読み取り、新しく一連の出力ファイルを生成する手法であるバッチ処理について論じました。この出力は、導出データの一種です。すなわちこのデータセットは、必要であれば同じバッチ処理を実行して再生成できます。この単純ながら強力な概念を用い、検索インデックス、レコメンデーションシステム、分析などができることを見てきました。

しかし、10章では全体を通じて大きな前提が置かれていました。それは、入力が有限であること、すなわちサイズが既知であり限られていることで、そのためバッチ処理には入力を読み取り終えたことが分かります。たとえばMapReduceの中心であるソートの処理は、出力を生成しはじめる前に入力を完全に読み終えていなければなりません。まさに最後の入力レコードが最も値の小さなキーを持っていたら、出力する際はそれは先頭のレコードになっていなければならず、早い段階で出力を開始することができないのです。

実際には、多くのデータは時間の経過に伴って徐々にやってくるので、有限ではありません。ユーザーは昨日も今日もデータを生成し、明日にはもっと多くのデータを生成し続けるでしょう。ビジネスを止めてしまわないかぎりこのプロセスは終わらないので、意味のある形でデータセットが「完成」することはないのです[1]。したがって、バッチ処理では人為的にデータを固定期間ごとのチャンクに分割します。たとえば1日分のデータを日の終わりに処理したり、1時間分のデータを毎時間の終わりに処理したりするわけです。 ...