「リアルタイムでデータを見たい」と業務側から要望が出ると、データエンジニア側はまずバッチ運用との差を考えます。1日1回の集計で十分なのか、1時間ごとに減らせばいいのか、本当に「リアルタイム」が要るのか。要件と技術選定がずれると、ストリーミング基盤を組んだものの、業務側は結局1時間遅れのダッシュボードしか見ていない、という事態が起きます。
ストリーミング処理は強力ですが、運用負荷も別格です。Kafka・Flink・Materializeを軸に、「いつバッチで足りるか」「いつストリーミングに踏み込むべきか」「どの組み合わせが現実的か」を整理します。
バッチとストリーミングの違い
| バッチ | マイクロバッチ | ストリーミング | |
|---|---|---|---|
| 遅延 | 数時間〜1日 | 数分〜1時間 | 秒〜サブ秒 |
| 処理単位 | 大きな塊 | 小さな塊 | 1イベントごと |
| 運用負荷 | 低 | 中 | 高 |
| 典型ツール | dbt、Airflow | dbt頻度up、Snowpipe | Kafka+Flink、Materialize |
| 失敗時の再処理 | 容易 | 容易 | 難しい |
「遅延」だけで考えるとストリーミングに惹かれますが、運用負荷と再処理の難しさを直視すると、多くの要件はマイクロバッチで足ります。10分遅延のダッシュボードで業務が動くなら、ストリーミングは過剰投資です。dbtでincremental運用する基本はincremental models設計を参照してください。
ストリーミングが本当に必要な場面
- 不正検知・リスク監視：取引や行動を秒単位で評価し、ブロックや警告を出す
- パーソナライズドアプリ：ユーザー行動を即座に反映してレコメンドや表示を変える
- IoT・センサーデータの監視：機器の異常を即時に検知して保全対応
- 運用ダッシュボード：システムの健全性をリアルタイム監視（DevOps系）
- ライブイベント：金融市場・スポーツ・選挙のような瞬時性が価値そのものの場面
これらに該当しなければ、まずバッチ・マイクロバッチで運用し、要件が出てから検討するのが現実的です。「将来必要かも」でストリーミング基盤を先に組むのは常に失敗します。
3つのツールの位置づけ
| Apache Kafka | Apache Flink | Materialize | |
|---|---|---|---|
| 役割 | イベントストリームの「土管」 | 分散ストリーム処理エンジン | ストリーミング対応の関係DB |
| 提供形態 | OSS＋商用（Confluent） | OSS＋商用（Ververica等） | 商用SaaS（OSS版は限定的） |
| 主な使い方 | イベントを集めて配信 | 複雑なストリーム処理 | SQLでリアルタイムビュー |
| 学習コスト | 中 | 高 | 低（SQLが書けるなら） |
| 得意領域 | 大規模イベント配信 | 状態管理が必要な複雑処理 | シンプルなリアルタイム集計 |
3者はカテゴリーが違います。Kafkaは「イベントの流通路」、Flinkは「処理エンジン」、Materializeは「ストリーミング対応のSQLデータベース」です。多くの現場で「Kafkaがイベント源、Flink/Materializeが処理」という組み合わせになります。
それぞれの強みと弱み
Apache Kafka
分散イベントストリーミングのデファクトです。LinkedIn発のOSSで、いまや「データ基盤の血管」と呼ばれるほど普及しました。発生したイベント（注文・閲覧・更新等）をまずKafkaに書き、複数の処理側がそれぞれ読む、というアーキテクチャの土台になります。詳細はKafka とはで扱います。
Apache Flink
本格的なストリーム処理エンジンです。「状態」を持つ複雑な処理（時間窓ごとの集計、イベントの相関分析、複雑なジョイン）を高速・低遅延で実行できます。エンジニアリングの難易度は高いものの、本格的なリアルタイム処理ではFlinkが第一選択です。詳細はFlink とはで扱います。
Materialize
SQLで定義したマテリアライズドビューを、ストリームの変更に応じてリアルタイムで更新し続ける、ユニークなデータベースです。「ストリーミング処理をSQLで書く」体験を提供し、Flinkのような専門的なスキルを要しません。詳細はMaterialize とはで扱います。
CDCとの組み合わせ
ストリーミングの最大のユースケースのひとつが、CDC（Change Data Capture）です。データベースの変更（INSERT/UPDATE/DELETE）をリアルタイムにキャプチャし、データ基盤に流す技術で、DebeziumとKafkaの組み合わせが標準パターンです。
| 構成要素 | 役割 |
|---|---|
| Debezium | DBのbinlog/WALを読み、変更イベント化 |
| Kafka | 変更イベントの配信ハブ |
| Flink / Materialize | イベントを変換・集計 |
| テーブルフォーマット（Iceberg/Delta/Hudi） | 処理結果の永続化 |
CDC・Hudiでの実装はApache Hudi とはでも触れています。「業務DBの変更を、数秒遅れでデータ基盤に届ける」のがCDCストリーミングの典型像です。
選定の判断軸
| 判断軸 | 選び方 |
|---|---|
| とりあえずイベントを流す土管がほしい | Kafka（事実上の標準） |
| 複雑な状態管理つきリアルタイム処理が必要 | Flink |
| SQLでサクッとリアルタイムビューを作りたい | Materialize |
| 運用負担を最小化したい | マネージド（Confluent Cloud、AWS MSK、Materialize Cloud） |
| 本当に必要か迷っている | まずdbt incremental＋マイクロバッチで試す |
マネージドの選択肢
- Confluent Cloud：Kafka本家のマネージドSaaS
- AWS MSK：AWSのマネージドKafka
- Google Cloud Pub/Sub：Kafka互換ではないが、用途は近い
- Ververica Platform：Flink本家のマネージド
- Decodable：Flink SQL中心のマネージドストリーム処理
- Materialize Cloud：Materializeのマネージド
OSSの自社運用は、ストリーミング基盤では重いです。専任SREが1名以上いない組織は、マネージドで始めるのが現実的です。
どこから始めるか
- ステップ1：本当に「秒単位の遅延」が必要か、業務側と要件を詰める
- ステップ2：dbt incrementalを高頻度（10〜30分）で動かして、マイクロバッチで足りないかを試す
- ステップ3：それでも足りない場面（不正検知等）だけ、Kafka＋Materializeなど軽量から始める
- ステップ4：状態管理つきの本格処理が必要になったら、Flinkに踏み込む
「ストリーミング基盤を組んでから使い道を考える」は失敗パターンです。「この業務にこの遅延が必要」を起点に、最小限の構成から段階的に積むのが原則です。
まとめ
- 「リアルタイム」要望の多くは、マイクロバッチで足りる。ストリーミングは運用負荷が別格。
- Kafka＝イベントの土管、Flink＝本格処理エンジン、Materialize＝SQLでリアルタイムビュー。
- CDC（Debezium＋Kafka）が典型ユースケース。Hudi等のテーブルフォーマットと組み合わせる。
- 選定は「土管／本格処理／SQL」の役割と、自社の運用力で決まる。
- OSS自社運用は重い。マネージド前提で始めるのが現実的。
各ツールの詳細はKafka とは・Flink とは・Materialize とはにまとめています。ストリーミング基盤の設計や採否の壁打ちは、DE-STKの初回相談（30分・無料）もご利用ください。
よくある質問（FAQ）
Q. dbt incrementalを5分間隔で回せば、ストリーミングは要らないですか？
A. ユースケースによります。「5分遅れで集計が出ればよい」ダッシュボードなら、それで十分です。ただし、Snowflake等のクラウドDWHは5分間隔の頻繁な実行でクレジット消費が膨らみます。コストと遅延の天秤で、10〜30分間隔のマイクロバッチに落ち着くことが多いです。秒単位の遅延が要件なら、別アーキテクチャ（Kafka＋Materialize等）を検討します。
Q. Kafkaは「中規模でも要る」と言われますが本当ですか？
A. データソースが10を超え、複数の下流システム（DWH、検索、通知、ML）に同じイベントを配信する規模なら、Kafkaの価値が出ます。小規模で「業務DBからDWHに1日1回」だけならFivetran/Airbyteで足り、Kafkaは過剰です。Kafkaは「イベントを一度書いて多くの場所が読む」アーキテクチャに移行するときに効きます。データ取り込みの選定はEL vs ETLとデータ取り込みツール選定を参照してください。
Q. FlinkとSpark Streamingはどう違いますか？
A. Flinkは「真のストリーミング」（イベント単位処理）で設計されており、低遅延と複雑な状態管理に強いです。Spark Streamingはマイクロバッチを高速化した方式で、Sparkバッチ運用に近い使い心地です。複雑な低遅延処理がいるならFlink、Sparkでバッチを書き慣れているチームが軽い準リアルタイム処理を始めるならSpark Streaming、と分かれます。
Q. MaterializeとSnowflake Streamsはどう違う？
A. どちらもストリーミング指向ですが、特性が違います。Snowflake StreamsはSnowflake内のテーブルの変更を追跡する仕組みで、増分処理を効率化します。Materializeは独立した「ストリーミング向けに最適化された関係DB」で、外部イベント源からのデータをリアルタイムに集計し続けます。Snowflake内で完結する増分処理はStreams、外部イベントをSQLでリアルタイム集計したいならMaterialize、と覚えてください。Snowflakeの詳細はSnowflakeとはを参照してください。