ストリーミング vs バッチの再定義: Flink・RisingWave・Materialize、CDC、Streaming SQL、リアルタイムの実用主義 (2025)

Season 5 Ep 2 — Ep 1 が「データはどこに保存されるのか」だったとすれば、Ep 2 は「データはどれだけ速く流れるのか」。2020–2023 のリアルタイム狂騒から、2024–2025 の実用主義へ戻る。

Prologue — 「リアルタイムは基本ではなくオプションだ」
第1章 · 鮮度階層（Freshness Tiers）
第2章 · Lambda・Kappa アーキテクチャの2025年版
第3章 · ストリーミングエンジン4大比較
第4章 · CDC (Change Data Capture)
第5章 · Iceberg v3 とリアルタイム Upsert
第6章 · Streaming SQL の台頭
第7章 · コストとレイテンシのトレードオフ
第8章 · オブザーバビリティとデバッグ
第9章 · 障害・復旧・SLA
第10章 · ストリーミング + Lakehouse の実践パターン
第11章 · 実践ケース3選
第12章 · 韓国企業のストリーミング
第13章 · アンチパターン10選
第14章 · チェックリスト — ストリーミングのローンチ前12項目
第15章 · 次回予告 — Season 5 Ep 3:「OLAP エンジン 2025 比較」

Prologue — 「リアルタイムは基本ではなくオプションだ」

2019–2022年のデータカンファレンスのキーノートはどれも「すべてのデータはリアルタイムになるべきだ」だった。2025年の現実は違う:

リアルタイムパイプラインはバッチ比で 3–10倍高い
ほとんどの BI ダッシュボードは15分–1時間の遅延でも誰も文句を言わない
本当にリアルタイムが必要なのは全データの 5–15%

2025年の正解:

「データごと・指標ごとの SLA を基準に鮮度階層を分け、各階層に合ったツールを使う」

この記事では、その階層とツール選定を具体化する。

第1章 · 鮮度階層（Freshness Tiers）

1.1 5階層のフレームワーク

階層	レイテンシ	例	ツール
Real-time	ms–秒	取引モニタリング・異常検知・fraud	Flink, Kafka Streams
Near-real-time	1–5分	運用ダッシュボード・alert	Flink, RisingWave, Materialize
Fresh	5–60分	在庫・広告最適化	Streaming append + rollup
Daily	24時間	BI, レポート	Spark, dbt, SQL warehouse
Historical	週/月	分析・ML 学習	Batch 年/月

1.2 各指標・テーブルを階層にマッピング

在庫指標: Fresh
ログインの異常検知: Real-time
月別売上: Daily
モデル学習用の特徴量: Fresh + Daily の混在

1.3 意思決定の原則

ビジネスの問い: 「指標が1時間遅れたら何が起きるのか？」
答えが「何も起きない」→ Daily または Fresh
答えが「10万ウォンの損失」→ Near-real-time
答えが「人が怪我をする/法的問題になる」→ Real-time

第2章 · Lambda・Kappa アーキテクチャの2025年版

2.1 Lambda (2014)

Batch layer + Speed layer + Serving layer
同じロジックを2回実装 → 維持の負担
2015–2020 に支配的

2.2 Kappa (2014, Jay Kreps)

ストリーミングログ（Kafka）ひとつに統一
再処理もストリーミングで
理論的な単純さ、実務的な難しさ

2.3 2025年: Unified on Lakehouse

Iceberg/Delta テーブルの上にバッチとストリーミングが同時に書き込む
Flink + Iceberg, Spark Structured Streaming + Delta
Serving は OLAP エンジンまたは materialized view

2.4「Streaming + Materialized」パターン

ソース → ストリーミングパイプライン → Lakehouse
よく使うクエリは Materialized view でプリコンピュート
ad-hoc は OLAP エンジンが直接クエリ

第3章 · ストリーミングエンジン4大比較

3.1 Apache Flink

本物のイベント時間（Event time）ベース、watermark、exactly-once
状態（Keyed state）が豊富、大規模プロダクションで検証済み
学習曲線が急、運用が複雑
2024–2025 で Flink CDC 2.x、Flink SQL が成熟

3.2 Spark Structured Streaming

Spark エコシステムの micro-batch ストリーミング
Databricks の標準
レイテンシ目標は 1–60秒以上、本物の ms 級ではない
SQL/Python が簡単

3.3 Kafka Streams / ksqlDB

Kafka 内蔵ライブラリ、JVM ベース
軽量、Kafka のデータに集中するときに最適
分散運用は自前で実装

3.4 RisingWave

2022年オープンソース、Streaming SQL に特化
Postgres 互換 SQL + Materialized view
状態は別ストレージ（S3）— 運用が簡単
Flink の代替として急浮上

3.5 Materialize

Streaming + Incremental view maintenance
複雑なジョイン・集計を自動で最新化
エンタープライズ SaaS 中心

3.6 比較表

エンジン	レイテンシ	複雑度	SQL	韓国での利用	特徴
Flink	ms–秒	高い	O	多い	業界標準、状態管理が強い
Spark SS	秒–分	中	O	非常に多い	Databricks と親和的
Kafka Streams	秒	中	ksqlDB	普通	Kafka 内蔵
RisingWave	秒	低い	Postgres	増加中	運用が簡単、SaaS/OSS
Materialize	秒	中	O	稀	Incremental view が強み

3.7 選定ガイド

イベント時間・複雑な状態: Flink
Databricks エコシステム: Spark SS
Kafka 中心・単純なロジック: Kafka Streams / ksqlDB
SQL だけでストリーミングアプリ: RisingWave または Materialize

第4章 · CDC (Change Data Capture)

4.1 なぜ CDC が核心なのか

運用 DB（Postgres/MySQL）の変更を分析システムへリアルタイム複製
バッチダンプに比べて遅延・負荷が大幅に減少
Lakehouse の Silver レイヤーを自動的に維持

4.2 実装方式

Log-based: Postgres WAL, MySQL binlog — 最も効率的
Trigger-based: DB トリガーで変更イベントを生成 — DB 負荷が大きい
Query-based: updated_at カラムベースの polling — 簡単だが削除を捉えられない

4.3 ツール

Debezium (OSS): Postgres/MySQL/SQL Server/Oracle/Mongo → Kafka
Fivetran, Airbyte: マネージド ELT、数百のソースコネクタ
Striim, HVR: エンタープライズ CDC
Flink CDC: Debezium の上に Flink を統合

4.4 CDC → Iceberg パターン

Postgres → Debezium → Kafka → Flink → Iceberg

Kafka でイベントを保管 → 再処理が可能
Flink が MERGE INTO で Iceberg に upsert
Iceberg v2/v3 の row-level delete を活用

4.5 実務の落とし穴

Schema change の処理（カラムの追加・削除・型変更）
初期スナップショット + 増分（Incremental snapshot）の調和
Exactly-once の保証（重複・欠落の両方を防ぐ）
バックフィル・再処理の戦略

第5章 · Iceberg v3 とリアルタイム Upsert

5.1 Iceberg バージョンの歴史

v1: Append-only
v2: Row-level delete（position/equality）、MERGE INTO
v3 (2024–2025): Deletion vectors, row lineage, V3 partition transforms

5.2 Row-level delete の2方式

Position delete: 行のファイル・位置を指す削除ファイル
Equality delete: 条件ベースの削除（UPDATE の実装に有用）

5.3 リアルタイム Upsert のワークフロー

Flink が CDC イベントを読む
PK ベースで Equality delete + insert を生成
Iceberg がスナップショットに反映
定期的な compaction で delete ファイルを整理

5.4 性能上の注意

Delete ファイルが溜まると読み取り性能が低下
Compaction の周期が重要（分–時間単位）
Copy-on-Write へ変換するバックグラウンド job の併用を推奨

第6章 · Streaming SQL の台頭

6.1 なぜ SQL なのか

Flink Java API は学ぶのが大変
データエンジニア + アナリストが一緒に扱える共通言語
dbt・Dagster のようなツールとの統合が容易

6.2 Flink SQL

2023–2024 に安定化
イベント時間・ウィンドウ・状態のすべてを SQL で
UDF・UDAF が可能

6.3 ksqlDB

Kafka の上の Streaming SQL
Table と Stream の概念が明確
単純な ETL・集計に適する

6.4 RisingWave の Postgres 互換

CREATE MATERIALIZED VIEW → リアルタイムに維持
Postgres のツール（Grafana, Superset など）をそのまま利用
運用の複雑さが低い → 2025年に急成長

6.5 Materialize

Incremental View Maintenance (IVM) の研究がベース
複雑なジョインも自動で最新化
SaaS + セルフホストのオプション

第7章 · コストとレイテンシのトレードオフ

7.1 コストの構成

コンピュート（ストリーミングクラスタ 24/7）
状態の保存（RocksDB/S3）
Kafka/MSK の運用
ネットワーク（リージョン間）

7.2 代表的なコスト比較（月額、中規模基準）

オプション	月額コスト	レイテンシ
バッチ（Airflow + Spark、日次）	低い（$1–5k）	24時間
Micro-batch（5分）	中（$3–10k）	5分
Structured Streaming	中–高（$5–20k）	秒–分
Flink クラスタ	高（$10–30k+）	ms–秒
Managed（RisingWave/Confluent）	中–高（$7–25k）	秒

7.3 削減テクニック

リアルタイム層を薄く（核心指標のみ）
Near-real-time 層で代替できないか検討
閑散期のスケールダウン
状態は S3（RisingWave 式）vs ローカル RocksDB（Flink）のトレードオフ

7.4 レイテンシ目標別の推奨アーキテクチャ

100ms 未満: In-memory stream processor + Redis/RocksDB
秒単位: Flink/RisingWave + Kafka
分単位: Spark Structured Streaming + Delta/Iceberg
時間単位: Micro-batch Airflow + dbt
日単位: Batch Spark

第8章 · オブザーバビリティとデバッグ

8.1 主要指標

End-to-end latency（イベント発生 → 結果への反映）
Lag（Kafka consumer lag, Flink checkpoint lag）
Throughput（eps, rps）
Back-pressure（Flink task ごと）
状態サイズ（RocksDB size, checkpoint size）

8.2 観測ツール

Flink UI + Prometheus + Grafana
Kafka Lag Exporter, Burrow, Conduktor
OpenLineage でストリーミングパイプラインの系譜
Datadog/NewRelic APM + ストリーミング extensions

8.3 デバッグ

チェックポイント・セーブポイントベースの再処理
CEP（Complex Event Processing）ルールのデバッグ
サンプリングログでイベントを追跡
テストは MiniCluster + embedded Kafka

8.4 アラート

Lag > しきい値 → Slack/PagerDuty
End-to-end の遅延 SLO 違反
チェックポイント失敗の連続発生

第9章 · 障害・復旧・SLA

9.1 SLA 設計

Availability: 99.9% = 月43分のダウンを許容
Freshness: イベント発生後 X 秒以内にクエリ可能
Correctness: 最終的な正確性（eventual）vs exactly-once

9.2 復旧戦略

Flink: チェックポイント（定期）、セーブポイント（手動）
Kafka: Replication factor 3, min.insync.replicas 2
Iceberg: スナップショット + ブランチでロールバック

9.3 再処理

Kafka retention を再処理期間の分だけ確保（7–30日が一般的）
または Iceberg の原本 → ストリーミング job を再実行
再処理中の重複防止（冪等性の設計）

9.4 Multi-region

Kafka MirrorMaker 2 / Confluent Cluster Linking
Iceberg はストレージ複製（S3 Cross-region）
ストリーミングジョブは Active-Passive が一般的

第10章 · ストリーミング + Lakehouse の実践パターン

10.1 Medallion 上のストリーミング

Bronze: 原本イベントを append
Silver: 整形・重複排除・ジョインの upsert
Gold: 集計・指標

10.2 CDC → Silver

DB の変更イベント → Flink → Iceberg Silver に upsert
Silver は運用 DB の「コピー + 過去」の役割
Gold は dbt/Spark のバッチで生成

10.3 イベントソーシング

ドメインイベントを Kafka に永久保管
状態はイベントの再生で再構成
Iceberg Bronze に長期保管

10.4 リアルタイム Feature Store

Feast/Tecton + Kafka + Iceberg
Online feature（Redis）+ Offline feature（Iceberg）
Online-offline skew のモニタリング

10.5 Streaming ETL パイプライン

ソース → Bronze（append）→ Silver（整形）→ Gold（集計）
各段階を Flink/Spark SS のジョブで実装
再処理はアップストリームの offset だけリセット

第11章 · 実践ケース3選

11.1 EC の注文パイプライン

注文イベント Kafka → Flink → 在庫更新 + 異常検知 + 分析
在庫: 秒単位のリアルタイム
売上指標: 5分の near-real-time
月次レポート: Daily batch

11.2 金融取引モニタリング

取引イベント Kafka → Flink CEP → Fraud score
遅延 100ms 未満を要求
状態: ユーザーごとの取引履歴（Flink keyed state）
結果: Redis + Iceberg に保存

11.3 ゲームテレメトリ

クライアントイベント Kinesis/Kafka → Flink/Spark SS
リアルタイム分析（同時接続者・DAU）は Near-real-time
詳細ログは Iceberg Bronze に蓄積して後で分析
A/B テスト: Gold の集計

第12章 · 韓国企業のストリーミング

12.1 伝統的なパターン

金融: Tibco EMS, IBM MQ, Kafka が混在
通信: Charging/Billing にリアルタイムストリーミング
ゲーム: Kafka + Flink または Kafka Streams
コマース: Kafka + Spark SS + ELK

12.2 最新動向

Confluent Cloud / MSK の導入が増加
Flink の採用が拡大（特にトス・クーパン・ネイバー・カカオ）
RisingWave・Materialize は 2024–2025 が導入初期

12.3 規制上の考慮

金融: 網分離環境で自前の Kafka クラスタ
個人情報: CDC イベントの PII マスキングが必須
監査ログ: 長期保管・不変性

12.4 難関

データエンジニアの人材不足 → マネージド志向が増加
レガシー DW との共存
24/7 オンコール文化が定着途上

第13章 · アンチパターン10選

13.1「すべてをリアルタイムに」

必要のないテーブルまでストリーミング → コスト・複雑度が激増。

13.2 Exactly-once の盲信

ソース・シンクの両側で E2E exactly-once を保証するのは容易ではない。冪等設計が必須。

13.3 CDC の初期スナップショットを省略

欠落が発生し、正確性が低下。

13.4 スキーマ変更の自動伝播がない

ダウンストリームのパイプラインが壊れる。

13.5 Kafka retention が短すぎる

再処理が不可能になる。

13.6 チェックポイントの周期が長すぎる

障害時の復旧コスト・再処理量が激増。

13.7 状態を無制限に保管

Flink keyed state が無限に増加 → OOM。

13.8 Delete ファイルの compaction がない

Iceberg の読み取り性能が低下。

13.9 メモリ・CPU の過少割り当て

Back-pressure の連鎖。

13.10 オブザーバビリティ・アラートの不在

事故を顧客が先に発見する。

第14章 · チェックリスト — ストリーミングのローンチ前12項目

第15章 · 次回予告 — Season 5 Ep 3:「OLAP エンジン 2025 比較」

ストリーミングとバッチがストレージを共有するようになったなら、次の問いは「その上で誰が最も速くクエリするのか」だ。

DuckDB: シングルノード OLAP の革命
ClickHouse: リアルタイム OLAP の標準
Snowflake / BigQuery / Redshift: マネージドの巨人たち
Databricks SQL / StarRocks / Doris / Pinot / Druid
Trino / Presto の連合クエリ
実際のベンチマークの罠
コスト vs レイテンシ vs 管理負担
MPP vs シングルノードの境界
韓国企業の選定ガイド
「適材適所」のエンジン配置パターン

「1つのエンジンがすべてをこなすわけではない」という 2025年の現実を認めたあとが、本当に面白い。

次回の記事で会おう。

まとめ: 2025年のストリーミングは「すべてリアルタイム」から「SLA ベースの鮮度階層」へ再定義された。Real-time / Near-real-time / Fresh / Daily / Historical の5階層に合わせて Flink・Spark SS・RisingWave・Materialize・ksqlDB を配置し、CDC で運用 DB の変化を Lakehouse へ流し、Iceberg v3 の row-level delete でリアルタイム upsert を処理する。Lambda/Kappa ではなく「Unified on Lakehouse」が支配的なパターンであり、コスト・レイテンシ・複雑度のトレードオフを意識的に設計する。「リアルタイムは基本ではなくオプション」— これが 2025年の実用主義だ。