数据工程 · 阅读约 10 分钟
何时需要将 CDC 纳入系统现代化改造
面向生产的 CDC 检查清单，涵盖快照、顺序、删除、数据结构变更、恢复、核对、监控及责任归属。
CDC 演示容易，稳定运行却不简单
当企业对变更数据捕获（CDC）的要求超出传输新增和更新数据时，就需要从系统现代化的角度重新规划。 用于生产环境的 CDC 服务，需要建立正确的初始状态、保留必要的变更顺序、同步删除操作，并支持重启和数据结构变更。还要能监控延迟、核对源端与目标端、保护源系统，并明确运维责任。
CDC 可缩短运营变更与下游使用之间的时间，但不会自动提供同步复制、业务事件约定、全局顺序，或从源端到使用方的恰好一次处理。
如果团队无法解释管道如何重启、核对及处理破坏性数据结构变更，它仍只是数据流，尚未成为生产数据产品。
什么时候值得使用 CDC
| 适合场景 | 效益 | 不适合或警示情况 |
|---|---|---|
| 低停机数据库或平台迁移 | 在变更持续发生时复制基线，再于切换前处理完积压并核对 | 业务需要同步写入路径，或无法接受任何一致性窗口 |
| 数据更新更及时的分析与运营报表 | 减少反复全量提取，让已提交的变更更早可用 | 每日批处理已能满足要求，不值得额外承担 CDC 的运行成本 |
| 搜索索引、缓存与读取模型 | 在可接受最终一致性时，持续更新下游数据视图 | 记录缺乏可用于更新与删除的稳定标识 |
| 范围明确的下游自动化 | 由已提交的变更触发可重放处理 | 自动化需要的业务意图无法从原始表变动中表达 |
| 现代化过程中的分阶段并行运行 | 在使用方分批迁移时持续向目标端供数 | 两个系统都可写入，但责任归属与冲突模型未经测试 |
只有设定了可衡量的数据时效目标，才应使用“近实时”这一说法。延迟取决于源系统负载、事务大小、网络、连接器处理能力、目标端写入能力及故障中断。目标应具体，例如源端提交到下游可用的延迟第 95 百分位（p95），而不是一个没有阈值的标签。
让初始加载与变更流在同一位置衔接
初始复制与增量流共同构成一个恢复协议。安全的概念性步骤为：
- 记录或建立原生源日志位置。
- 从该位置开始保留或捕获变更。
- 执行一致性快照或全量加载。
- 应用加载期间捕获的变更。
- 从准确的交接位置继续增量捕获。
- 核对基线及后续增量。
- 只有延迟与差异达到发布标准后，才宣布进入稳定状态。
若没有受保护的共同位置，不要先批量复制再开启 CDC，否则间隙内提交的变更可能永久遗漏。各产品交接语义不同，应在代表性负载下测试快照冲突、长事务、重启行为及流处理切换。
团队常遗漏的五个设计问题
1. 必须保留什么顺序？
顺序通常只在源键或流分区内得到保证，而非整个数据库。使用稳定业务键或源键，保留源位置及事务元数据，并确保目标并行处理不会打乱同一记录的变更顺序。不要根据使用方收到事件的时间推断全局提交顺序。
2. 删除对下游意味着什么？
明确硬删除、软删除、键变更、清空及保留策略如何表示与应用。忽略删除事件的目标端会悄悄出错，即使插入与更新指标看起来正常。
3. 如何安全地变更数据结构？
对变更事件约定进行版本管理，优先采用兼容的新增变更，并与使用方测试类型变化、重命名、键变更、精度变化及删除字段。不要假设每条源 DDL 都会在所有数据库引擎组合间正确传播。
4. 系统如何恢复？
将偏移量保存在临时工作进程之外，避免进程退出时丢失。源日志保留期应覆盖合理预估的最长中断时间及修复时间。按故障后可能重放事件来设计，使目标端重复写入同一事件时不会产生额外影响（幂等性），或验证端到端的交付保证及其适用范围。还应演练工作进程丢失、目标端中断、源端故障转移、日志位置过期、积压处理及重新生成快照。
5. 如何证明正确性？
消息送达不代表目标状态正确。按表或业务日期核对数量、插入／更新／删除量、稳定分块校验和、重要汇总、数据时效、检查点连续性及抽样记录。每项重大差异都需要负责人和修复路径。
监控不应只看“作业运行中”
连接器即使显示正常，也可能存在数据更新滞后、不完整或故障后无法恢复的问题。生产监控应涵盖：
- 端到端数据时效，以及分别统计的捕获延迟和目标端应用变更的延迟；
- 管道进出变更量、积压、队列压力及磁盘溢写；
- 低业务量源的最后事件或心跳距今时长；
- 连接器状态、重启次数、偏移失败及死信量；
- 源事务日志保留期、最早所需位置及可用存储；
- 目标端应用变更失败，以及数据结构不兼容问题；
- 核对差异及未解决异常的积压时长。
根据业务数据时效目标与已测试高峰特征设定阈值，而非使用厂商仪表板默认值。
保护源系统与数据路径
基于日志的捕获仍有生产成本。快照读取表，验证执行查询，连接器保留并解码日志，中断则造成积压。衡量源 CPU、读取 I/O、日志生成与保留、存储、网络、锁及应用延迟。执行大型快照或验证前，限制并发并定义停止条件。
为数据捕获设置专用身份，只授予必要权限；使用加密连接和统一管理的凭据，限制对偏移量及数据结构历史记录的访问，并只捕获所需数据。数据保留与脱敏规则应覆盖事件日志、错误记录、备份和死信记录，而不只是目标表。
实用的应做与避免事项
| 应做 | 避免 |
|---|---|
| 定义可衡量的数据时效与恢复目标 | 没有经测试的延迟上限却称管道为实时 |
| 在已记录的源位置衔接全量加载与 CDC | 在批量复制与捕获之间留下无保护间隙 |
| 建模更新、删除、键变更及重放 | 将 CDC 当作仅追加插入的数据流 |
| 对数据结构做版本管理并协调 DDL | 未检查兼容性就让源变更破坏使用方 |
| 监控延迟、积压、日志保留、错误与差异 | 只监控进程是否存活 |
| 持续核对并演练恢复 | 假设送达就代表目标正确 |
CDC 如何创造可衡量的效益
先建立当前流程基线，再在具有代表性的运营期间后报告变化。可用指标包括源端到使用方的数据时效百分位、实际切换停机时间、周期性提取所减少的源负载、经测试的恢复时间、差异率与处理时间、管道可用性及人工干预次数。
没有项目证据，不应公布泛泛的改善百分比。可信结果应说明测量目标及条件，例如符合条件的变更在约定的 p95 数据时效阈值内到达经过治理的报表层，同时源端影响、核对异常及恢复均处于批准范围内。