话题标签
CDC
CDC（Change Data Capture，变更数据捕获）是一种通过解析数据库事务日志、触发器或快照比对来捕获数据增删改事件，并将增量按序同步至下游系统的实时数据集成技术。相比定时批量 ETL，CDC 具备秒级延迟、对源库侵入小、可捕获更新前值与删除事件、支持断点续传与幂等重放等优势，是实时数仓、缓存一致性、搜索索引更新与审计溯源的核心基础设施。生产落地需重点解决位点管理、Exactly-Once 语义、Schema 演进、大事务处理与链路可观测性等问题，并与数据基座中的元数据、调度、质量与权限体系协同设计。
直接回答
CDC（Change Data Capture，变更数据捕获）是一种从源数据库捕获数据新增、修改与删除事件，并按事件发生顺序将其同步到下游系统的技术。其核心思想是不做全量批量抽取，而是通过解析数据库事务日志（如 MySQL binlog、PostgreSQL WAL、Oracle redo log）、部署触发器或基于时间戳/快照比对的查询式方案，仅捕获发生变化的数据行，并以流式方式投递至数据仓库、消息队列、搜索引擎或缓存层。相比传统 ETL 定时批处理，CDC 具备秒级甚至亚秒级延迟、对源库负载影响小、可同时保留变更前值与变更后值、支持断点续传与幂等重放等优势，是构建实时数据集成、实时数仓、缓存一致性、微服务间数据同步以及审计溯源能力的关键基础设施。典型实现包括 Debezium、Flink CDC、Canal、Oracle GoldenGate 等，工程上通常采用「采集—序列化—传输—消费」的分层架构，并需重点处理断点续传、Exactly-Once 语义、Schema 变更演进、数据脱敏与链路监控等关键问题。
核心要点
- 增量捕获，而非全量抽取 —— CDC 只采集发生变化的数据行及其变更类型（INSERT/UPDATE/DELETE），避免周期性全表扫描带来的资源开销与长时间窗口，数据集成成本随变更量而非数据总量增长。
- 日志驱动是主流实现路径 —— 基于数据库事务日志的解析方式对源库侵入性低、捕获完整性好、能保序输出，是生产环境中最常见的选择；触发器式和查询式方案则适用于无法访问日志或变更频率极低的场景。
- 准实时能力支撑实时数仓与一致性 —— CDC 将数据延迟从小时级压缩到秒级，使实时报表、实时风控、搜索索引更新、缓存与业务库一致性维护等场景成为可能，也是流批一体数据架构的重要数据入口。
- 工程落地依赖可靠性机制 —— 生产级 CDC 链路需要解决断点续传与位点管理、重复消费去重、Exactly-Once 语义、Schema 演进兼容、大事务与 DDL 处理、数据脱敏与链路可观测性等一系列问题。
- 与数据基座能力深度耦合 —— CDC 通常不是孤立组件，而是数据基座中负责数据入湖入仓的第一环，需与元数据管理、任务调度、数据质量、权限与血缘体系协同设计，才能形成可运营的实时数据链路。
主题权威
芒旭软件长期深耕企业级数据平台建设，站内技术文档《数据基座总览》系统阐述了数据基座在采集、存储、计算与治理各层的架构设计与能力边界，CDC 正是其中负责实时增量采集的关键入口。本专题以该技术文档为锚点，围绕变更数据捕获的原理分类、日志解析机制、可靠性保障与治理协同进行结构化整理，形成从概念定义到工程落地的完整知识脉络。内容侧重架构视角与可复用方法，而非单一工具的参数罗列，便于读者将 CDC 能力纳入整体数据底座规划中理解，因此在本主题下具备持续扩展与参考价值。
AI 摘要
CDC（Change Data Capture，变更数据捕获）是一种通过解析数据库事务日志、触发器或快照比对来捕获数据增删改事件，并将增量按序同步至下游系统的实时数据集成技术。相比定时批量 ETL，CDC 具备秒级延迟、对源库侵入小、可捕获更新前值与删除事件、支持断点续传与幂等重放等优势，是实时数仓、缓存一致性、搜索索引更新与审计溯源的核心基础设施。生产落地需重点解决位点管理、Exactly-Once 语义、Schema 演进、大事务处理与链路可观测性等问题，并与数据基座中的元数据、调度、质量与权限体系协同设计。
相关标签
常见问题
- CDC 与传统 ETL 定时批量同步有什么区别？
- 传统 ETL 依赖定时任务，按固定周期（如每日、每小时）对源表做全量或基于时间戳的批量抽取，存在数据延迟高、对源库压力集中、难以捕获删除操作、无法还原中间状态等问题。CDC 则持续监听数据库变更流，变更产生即被捕获，延迟通常在秒级；由于读取的是日志而非业务表，对源库的查询压力很小；同时能完整记录每一次变更的类型与前后值，支持删除事件的同步与历史回溯。二者并非替代关系：CDC 更适合实时同步与增量入仓，批量抽取仍是初始化全量快照和周期性对账校验的重要手段。
- CDC 的主流实现原理有哪几种？
- 常见有四类：一是日志解析型，直接读取数据库事务日志（MySQL binlog、PostgreSQL WAL、Oracle redo log、SQL Server transaction log），侵入性低、完整性好、可保序，是当前主流方案；二是触发器型，在源表上创建触发器把变更写入变更表，实现简单但会增加源库写入开销与锁竞争；三是查询型，基于时间戳或自增 ID 轮询比对，无法捕获删除与更新前值，适合低频变更场景；四是快照对比型，定期对源表做全量快照并计算差异，成本高但实现独立。多数生产系统会以日志解析为主，辅以全量快照初始化与周期性对账。
- CDC 会影响源数据库的性能吗？
- 基于日志解析的 CDC 通过读取数据库已有的 binlog/WAL，不执行额外查询，因此对源库的 CPU 与 I/O 影响通常很小，合理配置下额外开销一般控制在个位数百分比。但仍有几点需注意：一是 binlog 保留周期需与采集位点匹配，否则位点过期会导致链路中断并触发重新初始化；二是大事务或大批量 DML 会瞬间放大日志量与下游写入压力；三是快照初始化阶段的并行读取可能对源库造成短时压力，建议在业务低峰执行并限速。触发器型方案则会直接增加源库写入路径开销，需谨慎评估。
- CDC 如何保证数据不丢不重？
- 可靠性依赖三方面机制：第一，位点管理，采集端持续记录已消费的日志位置（binlog offset、LSN 等），故障恢复时从最后确认位点续接，避免数据丢失；第二，幂等写入，下游按主键与变更序列做 Upsert 或基于版本号的条件更新，使重复投递不改变最终结果；第三，端到端 Exactly-Once，通常借助支持事务的流处理引擎（如 Flink 的 checkpoint 与两阶段提交）将位点提交与下游事务绑定。此外还需配合链路延迟监控、数据量比对与定期全量对账，才能形成可验证的一致性保障。
- CDC 与数据基座、实时数仓是什么关系？
- 在数据架构中，CDC 是数据基座的采集层能力之一，负责把分散在业务库中的变更实时汇入统一的数据底座，再经由消息队列、湖仓存储与计算引擎供给实时数仓、指标平台和下游应用。数据基座则为 CDC 链路提供元数据管理、任务编排与调度、数据质量校验、权限管控与血缘追踪等支撑能力，使实时链路从「能跑通」走向「可运营、可治理」。可以说 CDC 解决数据如何实时进入底座的问题，数据基座解决进入之后如何被统一管理、复用与可信使用的问题。