多数据源CDC实时融合与集成平台 - 第1节

1.1 什么是CDC？从一次“数据搬家”说起

CDC，全称是Change Data Capture，中文叫“变更数据捕获”。

说白了，就是实时监控数据库里的数据变化——哪条记录被插入了、哪条被更新了、哪条被删除了——然后把这些变化抓取出来，同步到其他地方去。

我记得刚入行那会儿，有个项目需要把Oracle里的订单数据同步到Hadoop做分析。当时团队的做法是每天凌晨跑一个全量抽取脚本，抽一次要跑4个多小时。业务方天天抱怨数据滞后，说“你们的数据是昨天的，我们怎么给客户做实时推荐？”

后来我换了个思路：为什么不只抓变化的部分呢？

这就是CDC的核心理念——只捕获增量变化，不重复搬运全量数据。

CDC的典型工作流程是这样的：

1. 源数据库产生变更（INSERT/UPDATE/DELETE）
2. CDC工具读取事务日志，解析变更事件
3. 将变更事件序列化为统一格式（如JSON、Avro）
4. 推送到消息队列或直接写入目标系统
5. 目标系统应用变更，保持数据同步

你可能会问：为什么不直接查数据库的变更时间戳？嗯，这里有个坑——很多业务表根本没有时间戳字段，就算有，你也抓不到DELETE操作。CDC直接从日志层面捕获，任何变更都逃不掉。

1.2 CDC vs ETL/ELT：三种数据搬运工

很多初学者会把CDC和ETL、ELT搞混。我习惯用一个比喻来解释：

• ETL 像是搬家公司的“整箱搬运”——把所有东西打包好，一次性运到新家，再拆箱整理。
• ELT 像是“先搬过去再说”——把所有东西原封不动运到新家，到了再慢慢分类。
• CDC 像是“快递员”——每次只送一件新买的东西，实时送达。

下面这张表可以更清楚地对比三者的差异：

维度	ETL	ELT	CDC
数据搬运方式	批量抽取-转换-加载	批量抽取-加载-转换	实时增量捕获
延迟	分钟~小时级	分钟~小时级	秒级~毫秒级
对源库影响	高（全表扫描）	高（全表扫描）	低（读取日志）
捕获DELETE	困难	困难	原生支持
适用场景	数据仓库批量加载	数据湖、大数据平台	实时同步、流处理
典型工具	Informatica、Kettle	Spark、Flink	Debezium、Canal、Maxwell

我曾经在一个金融项目中做过对比测试：同样同步100万条订单数据，ETL方式耗时23分钟，CDC方式只用了47秒——而且CDC在同步过程中，源库的CPU负载几乎没有波动。

1.3 CDC在实时数仓中的核心价值

实时数仓这个概念，这几年被炒得很热。但说实话，很多所谓的“实时数仓”其实只是把批处理周期从一天缩短到一小时。真正的实时数仓，数据延迟应该在秒级以内。

CDC在其中扮演了什么角色？我总结了四个核心价值：

价值一：零侵入的数据采集

传统的数据采集需要在业务表上加触发器、时间戳字段，甚至修改业务代码。CDC直接从数据库日志读取，对业务系统完全无侵入。我在一个银行项目中，就因为不能动核心交易系统的表结构，才选择了CDC方案。

价值二：毫秒级实时同步

CDC工具可以做到秒级甚至毫秒级的延迟。以MySQL的binlog为例，Debezium在低负载下延迟可以控制在100ms以内。这意味着你的数仓数据几乎和业务系统同步。

价值三：完整的数据变更历史

CDC捕获的不仅是数据的最新状态，还包括每次变更的前镜像和后镜像。你可以知道一条记录从创建到删除的完整生命周期。这在数据审计、回滚溯源场景中非常有用。

价值四：解耦数据管道

CDC将数据生产者和消费者解耦。源库只需要写日志，CDC工具负责读取和分发，下游的实时计算、数据仓库、搜索引擎各取所需。这种架构扩展性极好。

下面这张图展示了CDC在实时数仓中的典型位置：

总结一下：CDC的价值在于用最小的代价，实现最快的数据同步。它让实时数仓从“伪实时”变成了“真实时”。我个人认为，在未来的数据架构中，CDC会像ETL一样成为标配——甚至更普及，因为实时性已经成为业务的基本要求，而不是加分项。