1. CDC与Schema治理概述
大家好，我是老张。做数据架构十几年了，今天咱们聊聊CDC和Schema治理。
CDC，全称Change Data Capture，中文叫变更数据捕获。说白了，就是实时监听数据库的变化——谁插入了新数据、谁改了字段、谁删了记录，CDC都能抓到。
但问题来了：数据在变，数据的结构也在变。今天加个字段，明天改个类型，后天删个索引。这些Schema变化，在CDC场景下会引发一连串的麻烦。
嗯，这就是咱们这门课要解决的核心问题。
1.1 CDC技术原理
CDC的实现方式，我简单梳理一下。常见的方案有四种：
| 方案 | 原理 | 典型工具 | 延迟 |
|---|---|---|---|
| 基于日志 | 解析数据库事务日志（如MySQL binlog、PostgreSQL WAL） | Debezium、Canal | 毫秒级 |
| 基于触发器 | 在源表上创建触发器，捕获DML操作 | 自制方案 | 秒级 |
| 基于时间戳 | 轮询表中更新时间戳字段 | 自制方案 | 分钟级 |
| 基于快照 | 定期对比全表快照差异 | 自制方案 | 小时级 |
我个人最推荐基于日志的方案。为什么？因为它对源库几乎无侵入，性能损耗最小。
我记得有一次帮客户做金融系统的实时同步，他们之前用触发器方案，结果生产库的TPS直接掉了30%。换成Debezium读binlog后，影响几乎为零。
1.2 Schema演进的挑战
CDC本身不复杂，复杂的是Schema变化。
你想想看，源库的Schema不是一成不变的。业务迭代、字段废弃、类型调整，这些都是家常便饭。但在CDC场景下，每一次Schema变化都可能引发数据管道断裂。
我遇到过最典型的几个坑：
- 字段新增：下游消费端没及时更新映射，新字段数据直接丢失
- 字段类型变更：比如int变varchar，序列化/反序列化直接报错
- 字段删除：下游还在引用已删除的字段，管道直接挂掉
- 表名变更：CDC监听器找不到原表，数据流中断
这些问题的本质是什么？是数据生产者和消费者之间的契约不一致。
源库改了Schema，但下游的消费逻辑还是老一套。两边对不上，数据就乱了。
1.3 为什么需要Schema治理
好，问题摆在这了。怎么解决？
答案就是Schema治理。
Schema治理，说白了就是对数据结构的全生命周期管理。包括Schema的定义、注册、版本控制、兼容性检查、变更通知等等。
它的核心价值有三点：
- 保证数据管道稳定性：Schema变化时，系统能自动检测兼容性，避免断裂
- 提升数据质量：统一的数据格式，减少解析错误
- 降低运维成本：Schema变更可追溯、可回滚，出了问题能快速定位
我举个例子。在Kafka生态里，Schema Registry就是做这个的。它维护了每个Topic的Schema版本，生产者和消费者都通过它来协商数据格式。
当源库新增一个字段时，Schema Registry会检查这个变化是否兼容。如果兼容，自动升级版本；如果不兼容，直接拒绝变更，避免下游崩溃。
下面这张图，展示了CDC与Schema治理的整体关系：
从这张图能看出来，Schema Registry是整个CDC管道的中枢神经。它连接了源库、CDC捕获层和下游消费端，确保Schema变化能被有序管理。
我个人习惯把Schema治理分成三个层次：
- 基础层：Schema定义和版本管理，保证每个Schema都有唯一标识
- 控制层：兼容性策略和变更审批，控制Schema变化的节奏
- 观测层：Schema变更审计和监控，出了问题能快速回溯
这三个层次缺一不可。我在实际项目中见过不少团队，只做了基础层，结果Schema变化还是乱套。为什么？因为没有控制层和观测层，变化来了没人管、没人看。
好了，这一章咱们把CDC和Schema治理的基本概念理清了。下一章开始，我会带你深入Schema Registry的具体实现，包括怎么注册Schema、怎么配置兼容性策略、怎么处理常见的Schema冲突。
嗯，内容不少，咱们慢慢来。