CDC 是什么
CDC（Change Data Capture，变更数据捕获）指持续从数据源抽出增量变更，而不是周期性把整表重拉一遍。它不记录「表现在有什么」，而是记录「表发生了什么变化」——每条记录带操作类型与变更前后的值，因此能让下游以近似实时的速度跟随上游。
开荒阶段怎么做
接入新表必须同时解决两件事：一是初始快照，把存量数据搬过去；二是增量衔接，快照之后继续追变更且中间不留缺口。常见做法是先记录快照开始位置，再导数据，再从该位置持续消费，并保证快照期间产生的那部分变更会被补齐。
基本信息
| 中文名 | 变更数据捕获（Change Data Capture） |
|---|---|
| 输入 | 数据库日志、触发器记录、时间戳轮询或全量比对 |
| 输出 | 按主键排序的增删改事件流 |
| 常见工具 | Canal、Debezium、Flink CDC、Maxwell，云厂商 DTS 类服务 |
| 与本包关系 | 本组聚焦日志解析型 CDC 及其同步落地 |
典型实现方式
| 方式 | 原理 | 优点 | 局限 |
|---|---|---|---|
| 日志解析 | 读 binlog / redo / WAL 等数据库日志 | 对源库侵入小、延迟低 | 需要日志权限与配套工具 |
| 触发器 | 在表上建触发器记录变更 | 实现直接、不依赖日志 | 增加写入开销、维护对象多 |
| 时间戳轮询 | 按 updated_at 字段增量查询 | 实现简单、无需日志 | 捕获不到删除、精度受字段维护影响 |
| 全量对比 | 周期性全量比对差异 | 不依赖日志 | 开销大、延迟高，适合兜底校验 |
典型使用场景
- 业务库实时同步到数仓，缩短从产生到可分析的时间间隔
- 缓存一致性：变更事件触发缓存失效或刷新，避免应用侧双写
- 搜索索引更新：把库表变更同步到检索引擎
- 微服务数据共享：一个服务的库变更广播给多个消费者
- 审计与合规留痕：完整记录每条记录的变更时间与内容
一条典型链路
一条典型链路
# 源端：数据库日志开启并配置为行级格式（MySQL 需 binlog_format=ROW）
MySQL binlog
# 解析层：CDC 工具以从库身份接入，持续拉取并解析为结构化事件
→ Canal / Debezium / Flink CDC
# 传输层：变更事件按表投递到主题，下游可各自订阅
→ Kafka 主题（一表一主题）
# 消费层：按 op 类型决定 upsert 或 delete，写入数仓 ODS / 检索 / 缓存 / 归档
→ 下游存储CDC 不是「不需要全量」：新表接入仍需初始快照，只是快照之后靠增量跟随。省略快照会让历史数据永久缺失，而遗漏快照与增量的衔接点会造成一段无法补齐的数据缺口。
触发器方案在高写入场景会显著拖慢源库：每次写入都要额外执行触发器逻辑，选型前用真实写入压力做压测，不要在核心交易库上先试后评估。