CEP, Actors, Reactive, and More †
現代の分散ストリーム処理フレームワーク（Kafka Streams、Samza、Storm、Spark Streaming、Flink）は、主に、複数のマシン間での処理のスケーリング方法、クラスタへのジョブのデプロイ方法、障害の処理方法 、マシン障害、ネットワーク停止）、マルチテナント環境で信頼性の高いパフォーマンスを達成する方法について説明する。 それらが提供するAPIは、かなり低いレベル（例: すべてのメッセージに対して呼び出されるコールバック）も含まれる。これらはMapReduce?に似ており、データベースのようなものではないが、ストリーミングSQLなどの高水準のクエリ言語を提供する作業が進行中である。
図1-30. ストリームクエリフレームワークは、ストリーム処理フレームワークよりも高いレベルの抽象化を提供する
ストリーム処理のための高水準クエリ言語には既存のものがいくつかあり、特にCEPについて言及する必要がある（図1-30）。 これは、1990年代のイベント駆動型シミュレーションの研究に由来している。 多くのCEP製品は商用で高価なエンタープライズソフトウェアだが、Esperにはオープンソース版がある。 （Esperは、分散ストリーム処理フレームワーク内で実行できるライブラリだが、分散クエリの実行は提供していない）。
CEPでは、イベントの特定のパターンに一致するクエリまたはルールを作成する。これは（データベースから返す結果を記述する）SQLクエリに相当するが、CEPエンジンは、クエリに一致する一連のイベントを連続してストリームから検索し、一致が見つかると通知する。 これは、例えば不正検出やビジネスプロセスの監視に役立つ。
CEPクエリ言語の観点から簡単に記述できるユースケースの場合、このような高水準言語は低レベルイベント処理APIよりはるかに便利である。 一方低レベルのAPIでは、より自由度が増しクエリ言語よりも幅広いことが可能になる。 また、スケーラビリティとフォールトトレランスに注力することで、ストリーム処理フレームワークはクエリー言語を構築するための強固な基盤を提供する。
高レベルのクエリのもう一つのアイデアは、ストリームでフルテキスト検索を行うことである。検索クエリを事前に登録しておき、イベントがクエリに一致すると通知される。 例えば、Elasticsearch Percolatorはこれをサービスとして提供し、Luwakは埋め込み可能なライブラリとしてストリーム上でのフルテキスト検索を実装している。
図1-31. 多くの人々は、イベントが良いアイデアだと思っている。
最後に、イベントストリームに関連する他のアイデアがたくさんある（図1-31）。 以下に簡単な要約を記載する。
- Akka、Orleans、Erlang OTPなどの分散アクターフレームワークも、イミュータブルなイベント/メッセージのストリームに基づいている。 しかし、主に並行システムをプログラミングするためのメカニズムであり、データ管理の仕組みはない。 原理上は、アクターの上に分散ストリーム処理フレームワークを構築することもできるが、これらのシステムの耐障害性の保証と失敗モードを慎重に検討する必要がある。例えば、多くは耐久性を提供していない。SEDAのアーキテクチャはアクターといくつかの点で類似している。
- 「リアクティブ」周りが最近大きく話題になっており、非常にゆるいアイデアが飛び交っているようにみえる。私は、ユーザーインターフェイスにイベントストリームをもたらす（例: データが変更されたらユーザーインターフェイスが更新される）ReactiveXやFunctional Reactive Programming（FRP）の
ようなデータフロー言語が上手く機能しているのではないかと思っている。 これは、データバックエンドのイベントストリームと同等である（第5章で触れている）。
- 最後に、CDC（Change Data Capture）はおなじみのやり方で既存のデータベースを使用することを意味し、任意の挿入、更新、削除を抽出して他のアプリケーションが使用できるデータ変更イベントのストリームに渡す。これについては、第3章で詳しく説明する。
この章でストリーム処理の多くの面を理解することができれば幸いだ。 第2章では、ストリームを実装する良い方法である「ログ」の考え方について詳しく説明する。
担当者のつぶやき †
みんなの突っ込み †
