「業務DBの変更を、もっと早くデータ基盤に反映したい」。日次バッチで取り込んでいた頃は問題なかったのに、リアルタイムなダッシュボードやデータプロダクトを作り始めると、この遅延がボトルネックになります。解決の中心技術がCDC（Change Data Capture）です。
「DBの変更を、トランザクションログ単位で捕まえてストリームに流す」のがCDCの基本動作です。代表的な選択肢が、Debezium＋Kafkaの組み合わせ、Snowflake内のStreams、PostgreSQL論理レプリケーション。3つを軸に整理します。
CDCの2つの方式
| 方式 | 動作 | 遅延 | 負荷 |
|---|---|---|---|
| ログベース（推奨） | DBのトランザクションログを読む | 秒〜サブ秒 | DB側ほぼ無負荷 |
| クエリベース | 定期的にWHERE updated_at > …で取得 | 分〜時間 | クエリ負荷あり |
本格的なCDCはログベースが定石です。クエリベースは「ログにアクセスできない」「監査要件で必要」など、限定的な場面で選ぶ妥協策です。
3つの選択肢の位置づけ
| Debezium + Kafka | Snowflake Streams | PostgreSQL 論理レプリケーション | |
|---|---|---|---|
| 対象 | MySQL、PostgreSQL、Oracle、SQL Server等 | Snowflake内のテーブル | PostgreSQL（送信側）→ PostgreSQL/他 |
| 方式 | ログベース（binlog/WAL） | Snowflake内部変更追跡 | 論理デコーディング |
| 用途 | 外部DB→データ基盤の流通 | Snowflake内部の増分処理 | Postgres↔Postgresのレプリ |
| 運用負荷 | 中（Kafka環境次第） | 低 | 中 |
3者はカテゴリーが違います。Debezium＋Kafkaは「外部DBからデータ基盤へ」、Snowflake StreamsはSnowflake内部の増分処理、PostgreSQL論理レプリケーションはPostgreSQL中心の構成と、用途で使い分ける。
Debezium + Kafka：外部DBからの流通
もっとも汎用的なCDC構成です。Debeziumが各種DBのログを読み、Kafkaに変更イベントを流します。下流はFlink・Materialize・dbtなどで処理します。詳細はDebezium とはで扱います。
Snowflake Streams：DWH内の増分処理
SnowflakeのStreamsは「テーブルの変更を追跡するメタデータビュー」です。「最後にチェックポイントしてから、どの行が変わったか」がストリームから取れる。dbt incremental処理と組み合わせやすく、Snowflake内部の増分パイプラインに向く。詳細はSnowflake Streams CDCで扱っている。
PostgreSQL論理レプリケーション
PostgreSQL 10以降に組み込まれた論理レプリケーション機能は、WALを論理的にデコードして他のPostgreSQLに流せる。Publisher / Subscriberモデルで、シンプルなCDC実装だ。SaaS化されたAurora・Cloud SQL等でも利用できる。詳細はPostgreSQL論理レプリケーションで扱っている。
選定の判断軸
| 状況 | 選び方 |
|---|---|
| 業務DB（MySQL/Postgres等）→ DWHに数秒で反映 | Debezium + Kafka |
| SaaSコネクタで間に合う | Fivetran/Airbyte（EL vs ETLとデータ取り込みツール選定） |
| Snowflake内のテーブル間の増分処理 | Snowflake Streams |
| PostgreSQL ↔ PostgreSQL | 論理レプリケーション |
| 運用負担を最小化したい | マネージドCDC（AWS DMS、Striim、HVR等） |
CDCの典型アーキテクチャ
| 段階 | 役割 | 使われる技術 |
|---|---|---|
| キャプチャ | 変更を取り出す | Debezium（外部DB）／Streams（Snowflake） |
| 配信 | 変更を流通させる | Kafka（Kafkaとは） |
| 処理 | 変更を集計・変換 | Flink・Materialize（バッチ vs ストリーミングの選び方） |
| 永続化 | テーブルに反映 | Iceberg/Delta/Hudi（レイクハウステーブルフォーマット比較） |
「DB→Debezium→Kafka→Flink→Iceberg」のような構成が、本格的なCDCパイプラインの典型像です。中小規模では「DB→Debezium→Kafka→Snowflake Sink」のようにシンプル化できます。
よくあるハマりどころ
- WAL/binlogの保持期間：DB側のログ保持が短いと、Debezium側でラグが出たときに復旧できない。保持期間を十分に取る。
- スキーマ変更の伝播：DBのALTER TABLEが下流に正しく伝わらず、パイプラインが壊れる。Schema Registryでスキーマ進化を制御。
- 初回スナップショット：CDCを始める前の既存データの取り込みが大量で重い。Debeziumのスナップショット戦略を選ぶ。
- 削除の扱い：論理削除と物理削除の区別、削除イベントの下流での扱いを明示的に設計しないと、データの整合性が崩れる。
マネージドCDCの選択肢
- AWS DMS：AWSのマネージドDB移行・CDCサービス
- Striim：エンタープライズ向けCDCプラットフォーム
- HVR（Fivetran傘下）：リアルタイムCDCに強い商用
- Confluent Cloud + Debezium：Confluentのマネージドにより自社運用負担を下げる
自社運用のDebezium+Kafkaは重い。本格運用前にマネージドの試算を取るのが現実的だ。
まとめ
- CDCはログベースが定石。クエリベースは限定的な妥協策。
- 外部DB→データ基盤の標準はDebezium+Kafka、Snowflake内増分はStreams、PostgreSQL中心は論理レプリケーション。
- 典型アーキテクチャはキャプチャ→配信（Kafka）→処理（Flink/Materialize）→永続化（Iceberg等）。
- 初回スナップショット、スキーマ進化、削除の扱いがハマりどころ。
- 自社運用は重く、マネージドCDC（DMS・Striim・HVR等）も現実的選択肢。
各要素の詳細はDebezium とは・Snowflake Streams CDC・PostgreSQL論理レプリケーションにまとめている。CDC設計の壁打ちは、DE-STKの初回相談（30分・無料）も利用できる。
よくある質問（FAQ）
Q. FivetranのCDCで足りませんか？
A. シンプルな業務DB→DWHならFivetranで十分です。Fivetranもログベースのコネクタを持ち、マネージドで運用できます。Debezium+Kafkaを選ぶのは「Fivetran費用が高い」「下流で複雑なストリーム処理がしたい」「複数の下流に同じイベントを配信したい」場面です。マネージドの楽さを取るならFivetran、自由度と費用コントロールを取るならDebezium、と分かれます。
Q. exactly-onceは保証されますか？
A. 単純なログベースCDCでは「at-least-once」が基本で、下流で重複が出る可能性があります。exactly-onceを保証するには、KafkaのトランザクションAPI、下流の冪等性保証、エンド・ツー・エンドの設計が要ります。多くの実装では、下流で冪等な処理を組むことで実質的にexactly-onceに近づけます。
Q. CDCで業務DBが重くなりませんか？
A. ログベースCDCはDB本体の負荷ほぼゼロです。WAL/binlogを「読むだけ」なので、書き込み性能には影響しません。ただしWAL/binlogの保持期間は伸ばす必要があり、ストレージ消費は増えます。クエリベースCDCはDB負荷が大きいので、本番稼働中のDBに対しては避けます。
Q. CDC + データレイクハウスはどう組み合わせる？
A. Hudiは特にCDCとの親和性が高く、Debezium→Kafka→Hudi DeltaStreamer→Hudi のパイプラインが典型です。Iceberg・Deltaでも可能で、Spark/Flinkを介して書き込みます。テーブルフォーマット選定はレイクハウステーブルフォーマット比較を参照してください。