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

根本の違い：有界データと無界データ

バッチ処理とストリーム処理を「速いか遅いか」で語ると本質を外します。両者を分けるのは扱うデータの性質です。

• バッチ処理は有界データ（bounded data） を扱う。「2026年6月分のログ」のように、開始と終端が確定した有限の塊です。処理系はデータ全体を見渡してから計算を始められる。
• ストリーム処理は無界データ（unbounded data） を扱う。イベントが際限なく到着し続け、「これで全部」という終端が原理的に来ない。

この差が計算モデルを根本から変えます。合計・平均・件数・結合といった集約はデータ全体を見て初めて確定します。有界データなら全体が存在するので単純ですが、無界データには「全体」が存在しません。無限に届き続けるイベントの合計は、待ち続ける限り永遠に確定しない。そこでストリーム処理は時間や件数でデータを区切る「ウィンドウ」 を導入し、「9:00〜9:05に届いた分の合計」のように有限の断片へ切り出して確定させます。ウィンドウはストリーム処理に後付けされた便利機能ではなく、無界データを有限の答えに落とすための必然の仕組みです。

レイテンシとスループットのトレードオフ

なぜ両方式が併存するのか。答えはレイテンシ（1件が到着してから結果に反映されるまでの遅延） とスループット（単位時間あたりの処理量） のトレードオフにあります。

バッチは大量データを一括で処理するため、ディスクI/Oやネットワーク転送をまとめて効率化でき、スループットあたりの単価が低い。反面、次のバッチ実行まで結果は更新されず、レイテンシは実行間隔（時間〜日）に縛られます。ストリームは1件ごと（または小さなマイクロバッチごと）に処理するのでレイテンシは秒〜ミリ秒に下がりますが、1件あたりの固定オーバーヘッドが効いてスループット効率では不利になりがちです。

重要なのはステートフル性の差です。バッチは実行のたびに入力全体から計算し直せる（ステートレスに近い）ので冪等で再現しやすい。ストリームは無界データを一度きりしか通せないため、途中集計や各ウィンドウの状態を永続的に保持し続ける必要があります。この状態こそがストリーム処理の難所で、障害復旧・重複排除・遅延データの扱いはすべてこの状態管理に帰着します。

イベント時刻と処理時刻、そしてウォーターマーク

ストリーム処理の正確性を左右する最大の論点が2つの時刻の区別です。

• イベント時刻（event time）：そのイベントが実世界で起きた時刻。センサーが計測した瞬間、ユーザーがクリックした瞬間。
• 処理時刻（processing time）：そのイベントが処理系に届き計算された時刻。

理想的には両者は一致しますが、現実にはネットワーク遅延、モバイル端末のオフライン、再送、パーティション間の追い越しによりイベントは順不同かつ遅れて到着します。9:04に起きたイベントが9:07に届くことは日常茶飯事です。すると「9:00〜9:05のウィンドウ」を処理時刻で閉じると、9:07に来た9:04のイベントを取りこぼす。かといって遅刻を無限に待てば、そのウィンドウは永遠に確定できません。

この「いつウィンドウを閉じて結果を確定するか」を決める仕組みがウォーターマーク（watermark） です。ウォーターマークは「このイベント時刻より前のデータはもう概ね出揃った」という処理系の見積もりで、ウォーターマークがウィンドウ終端を越えた瞬間にそのウィンドウを確定・発火させます。

擬似コード：イベント時刻ウィンドウとウォーターマーク

for each event(value, event_time) arriving:
    w = assign_window(event_time)      # 例: 5分ごとの固定ウィンドウ
    state[w] += value                  # ウィンドウ状態を更新（ステートフル）

    watermark = max_seen_event_time - allowed_lateness
    for each window w' where w'.end <= watermark:   # w'.end が閾値以下
        emit(w', state[w'])            # 確定して発火
        drop(state[w'])                # 状態を解放

ここに完全性とレイテンシの本質的なトレードオフが現れます。allowed_lateness（許容遅延）を小さくすればウォーターマークが早く進み低遅延ですが、遅刻データの取りこぼしが増えて結果が不正確になる。大きくすれば正確ですが、ウィンドウを長く開けておくぶんレイテンシが増え、保持する状態量も膨らみます。CDCや分散ログの順序保証と同様、これは万能解のない設計選択です（分散システムの一貫性は /devops/ が詳しい）。

系統と分岐：Lambda から Kappa、そして統一へ

「正確なバッチ」と「低遅延なストリーム」をどう組み合わせるか。この問いに対する代表的アーキテクチャは、年代を追って次のように分岐しました。

• 2011年ごろ：Lambdaアーキテクチャ（Nathan Marz が提唱）。同じ入力をバッチ層とスピード層（ストリーム）に二重供給する。バッチ層は全データから正確な結果を定期再計算し、スピード層は直近ぶんを低遅延で近似的に埋める。両者をサービング層で統合して読ませる。狙いは正確性と低遅延の両立です。
• 2014年ごろ：Kappaアーキテクチャ（Jay Kreps が提唱）。Lambdaの弱点は同じ集計ロジックをバッチ用とストリーム用に二重実装する運用負荷でした。Kappaはバッチ層を廃しストリーム処理一本に統一する。過去分の再計算が必要なら、永続化したイベントログを先頭から再生（reprocess） して新しいストリームジョブに通す。バッチはログ再生で代替できる、という発想です。
• 近年：統一処理エンジン。同一APIで有界・無界の両方を扱えるエンジン（Apache Flink や Apache Beam のモデルなど）が普及し、「バッチは有界ストリームの特殊例」という冒頭の原理を実装レベルで体現します。バッチとストリームの二項対立そのものを吸収する方向です。

三者の関係を整理します。

Kappaが成立する鍵は、イベントログが再生可能な永続記録であることです。分散ログ（Kafka系）のように過去のイベントを保持し先頭から読み直せるなら、「バッチ＝有限区間のログ再生」「ストリーム＝末尾を追い続けるログ購読」として同じコードで扱える。ログを単一の真実の源（source of truth） に据える設計が、Kappaと統一エンジンの共通基盤です。

まとめ

• バッチとストリームの本質差は速度ではなくデータの性質。バッチは有界データを全体を見て処理し、ストリームは終端の来ない無界データを扱うため、時間で区切るウィンドウが必然になる。
• 併存の理由はレイテンシとスループットのトレードオフ。バッチはまとめて効率化しスループット単価が低い代わり高レイテンシ、ストリームは低レイテンシの代わり1件の固定費を負う。
• ストリームの正確性はイベント時刻と処理時刻の分離と、遅刻をどこで諦めるかを決めるウォーターマークに集約される。許容遅延を縮めれば低遅延・不正確、伸ばせば正確・高遅延で状態も増える。
• アーキテクチャはLambda（二重層）→ Kappa（ストリーム一本＋ログ再生）→ 統一エンジンと分岐。「バッチは有界ストリームの特殊例」という原理が、二項対立を吸収する方向に働いている。
• 選定はレイテンシ要件から。秒単位が不要ならバッチ、必要ならストリーム、両立が要るなら単一ロジックの統一エンジンに寄せ、Lambdaは既存資産がある場合の現実解とする。