LESSON 30分

ストリーミング基礎

田中VPoE「バッチ処理のパイプラインは完成した。しかし、NetShop社のビジネスはリアルタイム性を求めている。不正検知やリアルタイムレコメンドは、日次バッチでは間に合わない。」

あなた「ストリーミング処理ですね。イベントが発生したらすぐに処理する仕組みが必要なんですか？」

田中VPoE「その通り。バッチとストリーミングの違い、使い分けを理解することが第一歩だ。」

バッチ処理 vs ストリーミング処理

項目バッチ処理ストリーミング処理
処理タイミング定期的（時間/日次）リアルタイム（秒〜分）
データ量大量データを一括処理1件ずつまたは小バッチ
レイテンシ高（分〜時間）低（ミリ秒〜秒）
再処理容易（全データ再処理）困難（状態管理が必要）
複雑さ低高
ユースケースレポート、ETL不正検知、リアルタイム推薦

ストリーミングの基本概念

イベント駆動アーキテクチャ

[Producer] → [Message Broker] → [Consumer]
 注文イベント    Kafka等        処理ロジック

主要な概念

概念説明
イベント何かが発生したことを表すデータ（注文、クリック等）
プロデューサーイベントを生成・送信する側
コンシューマーイベントを受信・処理する側
トピックイベントのカテゴリ（注文トピック、クリックトピック等）
オフセットトピック内のイベントの位置（読み取り位置管理）

メッセージ配信保証

保証レベル説明ユースケース
At-most-once最大1回配信（ロスト可能）ログ収集、メトリクス
At-least-once最低1回配信（重複可能）一般的なイベント処理
Exactly-once正確に1回配信決済、在庫管理

ウィンドウ処理

ストリーミングデータを集計するには、時間ウィンドウを定義します。

ウィンドウの種類

種類説明例
タンブリング固定長・重複なし5分ごとの注文数カウント
スライディング固定長・重複あり直近10分間の移動平均（1分スライド）
セッション非活動期間で区切るユーザーセッションごとの行動集計
タンブリングウィンドウ:
|---W1---|---W2---|---W3---|
0       5       10      15 (分)

スライディングウィンドウ (size=10, slide=5):
|----W1----|
     |----W2----|
          |----W3----|
0    5    10   15   20 (分)

セッションウィンドウ (gap=5分):
|--S1--|     |---S2---|   |S3|
活動   非活動  活動   非活動  活動

ストリーミング処理フレームワーク

フレームワーク特徴ユースケース
Apache Kafka StreamsKafkaネイティブ、軽量Kafkaエコシステム内の処理
Apache Flink低レイテンシ、状態管理が強力大規模ストリーム処理
Apache Spark Structured Streamingバッチとの統一APIバッチ+ストリーム統合
Amazon KinesisAWSマネージドAWSエコシステム

まとめ

項目ポイント
バッチ vs ストリーミングレイテンシ要件とユースケースで使い分け
基本概念イベント、プロデューサー/コンシューマー、トピック、オフセット
配信保証at-most-once、at-least-once、exactly-onceの3レベル
ウィンドウタンブリング、スライディング、セッションの3種類

チェックリスト

  • バッチ処理とストリーミング処理の違いと使い分けを説明できる
  • イベント駆動アーキテクチャの基本概念を説明できる
  • メッセージ配信保証の3つのレベルを説明できる
  • 3種類のウィンドウ処理の違いを説明できる

次のステップへ

ストリーミング処理の基礎を理解しました。次はApache Kafkaの詳細を学びましょう。

推定読了時間：30分