ストリーム処理とは？OSSエンジンの紹介

Tags:

ストリーム処理とは？

例えば、ベルトコンベアを流れるTシャツをセンサーで読み取り、色ごとに仕分けして段ボールに梱包するケースを考えてみよう。

この場合、「ストリーミングデータ」と「ストリーム処理」はそれぞれ次のようになる。

  • ストリーミングデータ: センサーが送信するTシャツの画像
  • ストリーム処理: センサーから受信したTシャツ画像をもとに、AIがリアルタイムで色を判定する処理

ストリーム処理 vs バッチ処理

ここではストリーム処理とバッチ処理を比較し、ストリーム処理の特徴を理解する。

ストリーム処理とバッチ処理の違いは、時間軸の違いである。

ストリーム処理 バッチ処理
目的 リアルタイム性を重視 スループットを重視
処理するタイミング ストリーミングデータが発生したとき ハードウェアリソースに余裕があるとき
処理にかかる時間 数ミリ秒から数秒 数分から数時間
ユースケース クレジットカード不正利用検知
ゲームのリアルタイム世界ランキング
IoTデバイスデータ分析		 夜間バッチ
店舗の月次処理

ユースケースから分かるように、ストリーム処理は時間の経過とともに無限に発生するデータをリアルタイムに処理する必要がある場合に使われる。

例えば、クレジットカードの不正利用は1秒でも早く検知し、利用を停止しなければならない。翌月まで処理を待つような対応では遅すぎる。

ストリーミングデータとは？

ストリーミングデータは「イベントストリーム」や「データストリーム」とも呼ばれる。

ストリーミングデータは無限であることに加えて、次の3つの特徴を持つ。

  • 順序がある
  • 不変のデータレコード
  • 再生可能であること（あると望ましい特徴）

順序がある

イベント、つまりストリーミングデータの各レコードには順序がある。

例えば、イベント1「給与200万ウォンを振り込む」とイベント2「50万ウォンを引き出す」には順序がある。残高0ウォンの口座でイベント2が先に処理されると、残高不足が発生してしまう。

不変のデータレコード

イベントは一度発生すると、削除したり変更したりできない。

例えば、「50万ウォンを引き出す」というイベントを後から削除したり変更したりすることはできない。このイベントを取り消すには、「50万ウォンを入金する」という新しいイベントを実行する。

再生可能

順序があり、不変のデータレコードで構成されているため、ストリーミングデータは再現できる。

例えば、次のイベント一覧から現在の残高を求めることはもちろん、任意の時点の残高を求めることもできる。

  1. イベント1: 残高0ウォンで口座を開設
  2. イベント2: 50万ウォンを入金
  3. イベント3: 100万ウォンを入金
  4. イベント4: 50万ウォンを引き出し
  5. イベント5: 50万ウォンを入金
  6. イベント6: 100万ウォンを引き出し

また、イベントリストから過去の状態を持つデータを再現することを**マテリアライズ（Materialize、具体化）**という。イベント4が終了した時点の「残高データ」を具体化すると「100万ウォン」になる。

ストリーム処理における時間の概念

ストリーム処理では時間を基準にストリーミングデータを処理できるため、正確な時間概念を定義することが重要である。ストリーム処理では次の3つの時間概念を使用する。

  • イベント時間（Event Time）
  • 収集時間（Ingest Time）
  • 処理時間（Processing Time）

ストリーム処理時間

イベント時間（Event Time）

イベント時間はストリーミングデータの分析に使われる。

  • Webサイトへのアクセスがピークになる時間帯
  • 時間ごとに売上が増加する商品の種類

収集時間（Ingest Time）

ストリーム処理はリアルタイムに行われるため、通常は「イベント時間」と「収集時間」はほぼ同じである。

ネットワーク障害などによってデータの到着が遅れた場合、「イベント時間」と「収集時間」の間に差が生じる。

処理時間（Processing Time）

「処理時間」と「収集時間」の間に大きな差がある場合、アプリケーション側のストリーム処理が追いついていない可能性がある。

タイムウィンドウ（Time Window）

ストリーム処理では、ストリーミングデータに対して時間範囲によるウィンドウ操作を行うことができる。

タイムウィンドウでは、時間を基準にウィンドウサイズを決定する。例えば、10秒ごとに蓄積されたレコードを処理する、といった形である。

タイムウィンドウの種類は、ウィンドウの移動頻度、つまり前進間隔によって主に次の3つに分けられる。

ウィンドウの移動頻度（前進間隔） 処理の重複
タンブリングウィンドウ（Tumbling window） ウィンドウサイズと同じ。 しない。
ホッピングウィンドウ（Hopping window） ウィンドウサイズより小さい。 する。
スライディングウィンドウ（Sliding window） ウィンドウ内のイベントが変化するたび。 発生する場合がある。

タンブリングウィンドウ（Tumbling window）

「移動頻度」と「ウィンドウサイズ」が同じウィンドウタイプである。

イベントに対する処理が重複しないという特徴がある。

タンブリングウィンドウ

ホッピングウィンドウ（Hopping window）

「移動頻度」より「ウィンドウサイズ」が大きいウィンドウタイプである。

イベントに対する処理が重複するという特徴がある。

ホッピングウィンドウ

スライディングウィンドウ（Sliding window）

ウィンドウ内のイベントが変化するたびに移動するウィンドウタイプである。

ウィンドウ内のイベントが変更されない場合は何も処理しない。SQLクエリの場合、結果を出力しない。

スライディングウィンドウ

ストリーム処理に使うOSSとサービス

ストリーム処理は、次の2つを使って実行できる。

  • 分散ストリーミングデータソース（イベントをキューイングするデータソース）
  • 分散ストリーム処理アプリケーション（キュー内のイベントに対してストリーム処理を実行する）

分散ストリーミングデータソース

分散ストリーミングデータソースでは、主に次のPub/Subメッセージングキューを使用する。

  • Apache Kafka
  • Amazon Kinesis Data Streams

分散ストリーム処理アプリケーションで使うエンジン

分散ストリーム処理アプリケーションでは、主に次の分散処理エンジンを使用する。

  • Kafka Streams（Apache KafkaのStreams API）
  • Kinesis Data Analytics
  • Apache Flink
  • Apache Spark Streaming
  • Apache Storm
  • Apache Samza

apache-streaming-technologies
https://databaseline.tech/an-overview-of-apache-streaming-technologies/

企業におけるストリーム処理の事例

ストリーム処理（Apache Kafka + Kafka Streams）を企業で使用した事例は次のとおりである。