ストリーミングパイプラインとは？継続的なイベント処理を解説

ストリーミングパイプラインは、scheduleされたbatchを待つのではなく、個々のイベントが到着するたびにデータを継続的に処理し、低レイテンシで結果を届けます。

ストリーミングパイプラインは、動いているデータを扱います。夜間のbatchを待つのではなく、各イベントが発生するたびに - クリック、支払い、センサーの読み取り - 反応し、ほぼリアルタイムで結果を更新します。これが不正検知、ライブダッシュボード、即時レコメンデーションを支えます。

ストリーミングパイプラインとは何か

ストリーミングパイプラインは、無限のイベントstreamを消費し、到着するたびに各イベント(またはそれらの小さなウィンドウ)を処理します。イベントはApache KafkaやAWS Kinesisのようなメッセージシステムを流れ、stream processorがそれらを継続的に変換、集約、ルーティングします。

ウィンドウと状態

streamは決して終わらないため、集約はウィンドウ - たとえば5分のtumblingウィンドウ - に対して動作します。processorは状態(実行中のカウント、最近のイベント)を保持し、遅延したデータや順序が乱れたデータを扱う必要があり、これがstreamingをbatchより複雑にします。

ツール

一般的なstream processorには、Apache Flink、Spark Structured Streaming、Kafka Streamsがあります。これらはウィンドウ処理、状態管理、exactly-onceまたはat-least-onceの配信保証を提供し、失敗があっても結果が正しく保たれるようにします。

CIでのストリーミングパイプライン

ストリーミングロジックはコードであり、既知のイベントのシーケンスをprocessorに流して出力を検証することで、多くの場合埋め込みのbrokerに対してCIでテストされます。

steps:
  - run: docker compose up -d kafka   # service container
  - run: pytest tests/streaming       # replay events, assert output

Latchkeyノート

ストリーミングのテストは、しばしばbrokerをservice containerとして起動します。Latchkeyでは、brokerイメージと依存関係をcacheすることでこれらのjobが高速化し、auto-retryがテストが接続する前にbrokerコンテナを立ち上げる際の一時的な不安定さをカバーします。

重要なポイント

• ストリーミングパイプラインは、低レイテンシの結果のために、イベントが到着するたびに継続的に処理する。
• ウィンドウと維持される状態を使い、遅延したイベントや順序が乱れたイベントを扱う必要がある。
• ストリーミングロジックは、既知のイベントをprocessorに再生させて出力を検証することでCIでテストされる。

関連ガイド