1. CDC 基础概念：从“数据搬家”到“数据同步”
做数据这行这么多年，我见过太多团队在数据同步上栽跟头。要么全量跑一次要几个小时，要么增量漏数据没人知道。说白了，CDC 就是来解决这些问题的。
什么是 CDC？
CDC，全称 Change Data Capture，中文叫“变更数据捕获”。它的核心思想很简单——只捕获数据源中发生变化的部分，而不是每次都把整个数据集搬一遍。
举个例子。你有个订单表，每天新增 10 万条记录。如果用传统方式同步，每次都要把全表 1 亿条数据扫一遍。CDC 呢？它只盯着那 10 万条新数据。效率差距，你自己想想看。
CDC 的本质： 监听数据源的变更事件，实时或准实时地将变更记录捕获、解析、传输到目标系统。
常见的 CDC 实现方式有三种：
- 基于日志的 CDC —— 解析数据库的事务日志（如 MySQL 的 binlog、PostgreSQL 的 WAL）。性能最好，对源库影响最小。我个人最推荐这种方式。
- 基于触发器的 CDC —— 在源表上建触发器，记录变更到一张影子表。实现简单，但会拖慢源库写入性能。
- 基于时间戳/版本号的 CDC —— 靠业务字段（如 update_time）来识别变更。最轻量，但无法捕获删除操作，延迟也高。
我的建议： 生产环境优先选基于日志的 CDC。我在项目中遇到过用触发器方案导致核心库写入延迟飙升的情况，从那以后我就把“日志优先”写进了团队的技术规范。
CDC 的核心价值
CDC 为什么这么火？说白了，它解决了数据同步领域的三个核心痛点：
- 低延迟 —— 秒级甚至毫秒级捕获变更，满足实时数仓、实时风控等场景。
- 低侵入 —— 基于日志的方案对源库几乎零影响，不需要改表结构、不需要加字段。
- 高一致性 —— 保证变更顺序不丢不乱，Exactly-Once 语义可落地。
我记得有一次帮一家电商公司做数据迁移。他们之前用定时任务每小时全量同步一次，结果大促期间数据延迟导致库存超卖。换成 CDC 后，延迟降到 3 秒以内，库存扣减和同步几乎同时完成。嗯，这就是 CDC 的价值。
CDC 与 ETL 的区别
很多人把 CDC 和 ETL 混为一谈。其实它们不是替代关系，而是互补关系。
| 维度 | CDC | ETL |
|---|---|---|
| 数据范围 | 只捕获增量变更 | 通常处理全量数据 |
| 处理频率 | 实时/准实时（秒级） | 批量（分钟/小时/天级） |
| 对源库影响 | 极小（日志解析） | 较大（全表扫描） |
| 数据转换 | 轻量（格式适配） | 重量（清洗、聚合、建模） |
| 典型工具 | Debezium、Canal、Maxwell | Informatica、DataStage、Kettle |
你想想看，ETL 更像是一个“搬运工+装修队”，把数据从 A 搬到 B，还要重新装修一遍。CDC 则像一个“快递员”，只负责把包裹（变更）快速送到。实际项目中，我经常把 CDC 作为 ETL 的前置环节——CDC 负责实时捕获，ETL 负责后续的清洗和建模。
避坑指南： 我曾经见过一个团队用 CDC 替代了所有 ETL 流程，结果下游系统收到的是“脏数据”——因为 CDC 只负责搬，不负责洗。记住，CDC 不是 ETL 的替代品，而是 ETL 的加速器。
CDC 的常见应用场景
CDC 的应用场景比你想象的更广。我简单列几个最常见的：
- 实时数仓 —— 业务库 → CDC → Kafka → 实时数仓（如 ClickHouse、Doris）。这是目前最主流的用法。
- 缓存同步 —— 数据库变更 → CDC → 更新 Redis/Elasticsearch。保证缓存与数据库的一致性。
- 微服务间数据同步 —— 一个服务的数据库变更，通过 CDC 广播给其他服务。避免服务间直接调用数据库。
- 异地多活/数据灾备 —— 主库变更实时同步到备库或异地机房。延迟控制在秒级。
- 审计与溯源 —— 记录所有数据变更历史，用于合规审计或问题排查。
我参与过一个金融项目，监管要求所有交易数据的变更必须可追溯。我们用 CDC 把 binlog 变更全部写入 Kafka，再落地到 HDFS 做永久存储。每次审计都能精确查到“谁在什么时间改了哪条数据”。这就是 CDC 在审计场景下的典型应用。
CDC 核心知识体系
下面这张图帮你梳理了 CDC 的基础知识结构。建议你保存下来，后面几章的内容都会围绕这个框架展开。
好了，这一章我们先把 CDC 的“地基”打牢。后面的章节会深入讲 CDC 与权限管控的结合，以及各种实战中的坑和技巧。嗯，做好准备，后面才是硬菜。