← データエンジニアリング 一覧

🎓 レベル：基礎　|　重要度：A（必須）

📎 前提：データエンジニアリングとは・役割　|　関連：現代データスタックの地図・ストリーム処理

要点（BLUF）

• バッチ＝データを一定量／一定時間ためてから、まとめて処理する。ストリーム＝イベントが来た端から、ほぼリアルタイムに処理する。
• 選択軸は 鮮度（どれだけ新しい結果が要るか）と、複雑さ・コストのトレードオフ。秒・分単位の鮮度が要らないなら、ほとんどの場合バッチで十分。
• 「とりあえずストリーム」は事故のもと。まずバッチで作り、鮮度要件がバッチで満たせないと分かってからストリームにするのが定石。

概念 ── 「ためて処理」か「流して処理」か

バッチ処理は、1日分・1時間分のデータをためて、定時に一括変換します（夜間バッチが典型）。ストリーム処理は、1件のイベント（注文・クリック・センサー値）が発生するたびに、数秒以内に処理します。

要するに違いは「処理の単位」です。バッチは「ファイル／テーブルの塊」、ストリームは「1イベント（あるいは小さなマイクロバッチ）」。この単位の違いが、鮮度・コスト・実装の難しさをすべて左右します。

flowchart LR
    subgraph B["バッチ"]
      direction LR
      B1["ためる（1日分）"] --> B2["定時に一括処理"] --> B3["結果テーブル更新"]
    end
    subgraph S["ストリーム"]
      direction LR
      S1["イベント発生"] --> S2["即時処理（数秒）"] --> S3["逐次更新"]
    end

設計の勘所 ── トレードオフ表

ストリームの難しさの核心は「時間」です。イベントが発生した時刻（イベント時間）と処理した時刻（処理時間）がずれ、ネットワーク遅延で順序も狂います。この「遅延データ」「ウィンドウ集計」の扱いは ストリーム処理 で詳述します。

なぜそうするか ── まずバッチ、が定石

なぜ「とりあえずストリーム」が危ういのか。ストリームは常時稼働・状態管理・順不同/遅延データの処理を要求し、運用負荷とコストがバッチの数倍になります。一方で多くの業務（日次売上、月次レポート、ML学習データ）は鮮度が分〜日で十分。

定石は次の順です。(1) 鮮度要件を数値で確認（「何分遅れまで許せるか」）→ (2) バッチ（必要なら頻度を上げる：マイクロバッチ）で満たせるか試す → (3) どうしても秒単位が要る部分だけストリーム化。鮮度は「あれば嬉しい」ではなく「いくら払う価値があるか」で決めます。

なお、近年は micro-batch（数分間隔の小バッチ）が両者の中間として実用的で、「ほぼリアルタイム」の要件をバッチ寄りの簡単さで満たせることが多いです。

⚠️ よくある落とし穴

• 「リアルタイム＝速くて偉い」と短絡する → 鮮度には運用コストとバグ余地が比例する。要件のない鮮度は負債。
• バッチの“1日”を固定で考える → 頻度は要件次第。15分バッチ・1時間バッチで足りることが多い。
• ストリームで「正確に1回（exactly-once）」を素朴に期待する → 分散環境では難しく、べき等設計（→ べき等性と再実行）で「重複が来ても結果が壊れない」ように作るのが現実解。

対応ラボ

なし（概念回）。ストリームの実装的な側面は第7章で扱う。

関連

• 両方式を実装するツールの地図は 現代データスタックの地図 へ
• ストリームの時間・ウィンドウ・遅延データの詳細は ストリーム処理、その土台のログ基盤は メッセージキューとイベントストリーミング
• 「重複が来ても壊れない」設計は べき等性と再実行 に繋がる

← 第1章 データエンジニアリングの全体像 目次