1、CDC概念与场景：什么是CDC、为什么需要CDC、CDC与ETL的区别、常见应用场景

大家好，我是这次课程的主讲。做了十几年数据工程，我见过太多系统在数据同步上栽跟头。今天咱们先聊聊CDC——这个听起来高大上、实际上非常接地气的技术。

什么是CDC？说白了就是“监听数据库的变更”

CDC，全称Change Data Capture，中文叫“变更数据捕获”。它的核心思想很简单：实时监听数据库里的数据变化，然后把变化抓取出来，交给下游系统处理。

举个例子。你在电商平台下单，订单表里多了一条记录。传统做法是定时跑批任务，每隔几分钟或几小时去查一次表，看看有没有新数据。CDC的做法是——数据库一提交这条记录，CDC工具立刻就能感知到，并把这条变更事件推出去。

我个人习惯把CDC理解成“数据库的日志订阅者”。它不直接查表，而是读取数据库的变更日志（比如MySQL的binlog、PostgreSQL的WAL）。这样做的好处是：对源库几乎零侵入，不会增加查询压力。

为什么需要CDC？我踩过的坑告诉你

你可能会问：我直接用ETL全量同步不行吗？嗯，我以前也这么想，直到被现实教育了。

几年前我负责一个金融项目，需要把核心交易库的数据实时同步到分析库。最开始用的就是定时全量同步，每5分钟跑一次。结果呢？

• 高峰期数据库CPU飙到90%——全量查询太吃资源了
• 数据延迟5-10分钟——业务方投诉说报表不准
• 增量数据难以识别——全量对比才能知道哪些是新增或修改的

后来换成CDC方案，延迟降到秒级，源库负载几乎没变化。为什么？因为CDC只读日志，不碰数据表。

总结一下，CDC的核心价值在于：

1. 低延迟：秒级甚至毫秒级捕获变更
2. 低侵入：不增加源库查询压力
3. 精确增量：只传输变化的数据，不浪费带宽和计算
4. 事件驱动：天然适合流式处理架构

CDC与ETL的区别：不是替代，是进化

很多人把CDC和ETL对立起来，其实没必要。我更喜欢把CDC看作是ETL在实时场景下的进化版。

咱们直接看对比：

维度	传统ETL	CDC
数据获取方式	全量查询或基于时间戳的增量查询	读取数据库事务日志
对源库影响	高（频繁查询消耗CPU/IO）	极低（日志读取几乎无影响）
数据延迟	分钟级到小时级	秒级到毫秒级
数据精度	可能丢失中间状态（如多次更新只看到最终值）	完整记录每次变更（包括插入、更新、删除）
适用场景	离线数仓、批量报表	实时数仓、缓存同步、微服务事件驱动

说白了，ETL适合“今天看昨天的数据”，CDC适合“现在看现在的数据”。两者不是非此即彼的关系——我现在的项目里，经常是CDC做实时增量，ETL做离线全量，配合使用。

常见应用场景：CDC到底能干什么？

我挑三个最典型的场景讲讲，这些都是我在项目中实际用过的。

1. 数据同步：跨库复制

最直接的应用。比如把MySQL的业务数据实时同步到Elasticsearch做搜索，或者同步到ClickHouse做分析。我以前做过一个电商搜索系统，订单数据从MySQL通过CDC同步到ES，延迟控制在3秒以内，用户下单后几乎立刻就能在搜索结果里看到。

2. 实时数仓：流式入仓

传统数仓是T+1，今天跑昨天的数据。实时数仓要求数据入仓延迟在分钟级甚至秒级。CDC在这里扮演“数据管道”的角色——从业务库捕获变更，直接推送到Kafka，然后由Flink消费写入数仓。我参与的一个实时大屏项目，就是用CDC + Kafka + Flink，做到了秒级刷新GMV数据。

3. 缓存更新：保持一致性

这是很多互联网公司的标配。业务数据在MySQL里，缓存用Redis。怎么保证缓存和数据库一致？我以前见过不少方案——先更新数据库，再删除缓存，或者用消息队列异步同步。但这些方案要么有延迟，要么可能丢消息。CDC方案是：数据库变更后，CDC捕获到变更事件，直接触发缓存更新或失效。这样缓存和数据库的最终一致性有了可靠保障。

下面这张图展示了CDC在典型数据架构中的位置：

从这张图你能看到，CDC在整个数据链路中扮演的是“桥梁”角色。它不负责数据怎么用，只负责把变化“搬”到正确的地方。