ストリーム処理は、データが到着するたびに継続的に処理します。データをバッチ処理して一定間隔で処理するのではなく、ストリームプロセッサはシステム内を流れる各イベントを分析します。クレジットカード取引はミリ秒単位で不正の有無が評価されます。センサーの読み取り値が閾値を超えるとアラートが発せられます。クリックストリームは、レコメンデーションモデルをリアルタイムで更新します。処理は静止状態ではなく、動作中に実行されます。

アーキテクチャはバッチ処理とは異なります。データは Kafka や Kinesis などのメッセージキューを介して到着します。Flink、Spark Streaming、Kafka Streams などのストリームプロセッサがイベントを消費し、変換を適用して結果を出力します。システムは、遅れて到着するイベント、順不同のデータ、および厳密に 1 回のみの処理を処理する必要があります。これらは難しい問題です。遅れて到着するイベントには、時間ウィンドウが完了したかどうかを判断するためのウォーターマークが必要です。順不同のイベントには、バッファリングと再順序付けが必要です。厳密に 1 回のみの処理には、ソース、プロセッサ、シンク間の調整が必要です。これらを正しく行うのは複雑です。これらが間違っていると、結果が矛盾したり、重複したりします。ストリーム処理は、即時の洞察が必要なユースケースには強力です。夜間レポートには過剰です。バッチ処理とストリーム処理の選択は、レイテンシの要件によって異なります。数分または数時間のレイテンシが許容できる場合は、バッチ処理の方がシンプルで安価です。秒単位のレイテンシが重要な場合は、ストリーム処理が唯一の選択肢です。

ストリーム処理特性

• 継続的 — イベントが発生するとすぐに処理する
• 低遅延 — ミリ秒から秒
• ステートフル — イベント間で状態を維持する
• 複雑 — 遅延データや順不同データを処理する
• スケーラブル — 多数のノードに分散

ストリーム処理は、バッチ処理を逆転させたものだ。データが蓄積されるのを待つのではなく、発生するイベントごとに処理を実行する。