什么是变更数据捕获？

变更数据捕获（CDC）是一种数据同步模式，可以近乎实时地将日志或数据库变更（如插入、更新和删除操作）发送到其他系统。CDC 适用于流式传输数据管道、日志记录以及事务性数据库操作。CDC 旨在帮助节省带宽和时间，同时保持跨系统的数据一致性。

许多现代数据技术栈都依赖源系统提供的一致性数据传输。如果每次源系统更新时都传输完整数据集，将会消耗大量的网络带宽。全表扫描还会影响数据库性能，从而降低这些数据系统的整体效率。

变更数据捕获通过增量捕获源系统内的更新来解决这些问题。它有助于实现实时数据可用性，因为您无需依赖预定的批处理作业，同时还能保持数据的一致性并减轻源系统的负载。

CDC 常用于向流式传输系统输送事件以及在松耦合微服务架构中应用，因为它可以简化跨环境的数据复制过程。随着实时数据传输在数据基础设施领域日益普及，CDC 已成为实现可靠且可扩展数据流的常用方法。

使用变更数据捕获具有多项优势，这使其成为企业可采用的一项实用策略。

实时数据可用性

通过近乎实时地同步源系统数据，CDC 能够为分析平台等下游系统提供最新信息。该过程无需轮询，这使其称为一个更具可扩展性且负载压力更小的数据同步系统。

降低源数据库负载

变更数据捕获仅传输发生变更的数据行，而无需进行全量复制。此外，它采用迭代式持续传输，而非定期的批量加载。这两者协同作用，可以有效降低源数据库的整体负载。

支持事件驱动型架构

CDC 将数据库变更转化为事件流，供多个服务使用。这有助于实现系统解耦，从而更轻松地扩展应用程序或引入新的数据消费者，而无需重构源系统，尤其是在事件驱动型架构中。

可靠的审计跟踪

变更数据捕获提供有序的变更序列，便于记录更新、删除或插入操作。在审计或调试过程中，CDC 可支持合规性流程，并简化证据整理工作。

简化数据同步

通过向多个消费者进行流式传输，CDC 使得数据仓库、数据湖、副本或其他互联系统能够轻松保持同步。您无需构建和运行脆弱的 ETL 脚本，而是可以依靠 CDC 技术实现简化的数据同步。

变更数据捕获的工作原理是：监控源系统中的变更，将这些变更转换为事件，然后将其发布到数据管道中。随后，任何下游系统（如数据仓库或分析平台）都可以使用这些事件，并应用其中包含的变更以保持数据一致性。

在此过程中发生的具体内部操作取决于所实施的 CDC 类型。以下是实施 CDC 的最常见方法。

基于日志的 CDC

基于日志的 CDC 直接读取数据库事务日志。根据系统的不同，这些日志可能是 PostgreSQL 中的 WAL（预写式日志）、MySQL 中的二进制日志（binlog）或 Oracle 中的重做日志。基于日志的 CDC 方法对源数据库的影响极小，且系统开销远低于其他方案。由于它在数据库引擎层面运行，因此不会产生应用层机制那样的开销，同时还能确保按变更发生的实际顺序捕获变更。

基于触发器的 CDC

基于触发器的 CDC 利用一系列数据库触发器，这些触发器会在数据操作发生时执行。任何插入、更新或删除操作都会触发将相应记录写入单独的表中。这些备用表被称为审计表或影子表。系统利用这些表来跟踪源系统中的变更。

由于涉及额外的步骤和基础设施组件，这种形式的 CDC 需要更多的开销。此外，它还会导致应用程序逻辑与数据捕获机制之间产生更紧密的耦合。

基于时间戳的 CDC

基于时间戳的 CDC 使用特定的时间戳来限定在指定时间之后发生变更的记录。这是一种简单的 CDC 形式，但它要求具备可靠的时间戳列，且可能会遗漏删除操作。此外，如果时钟未同步，或者更新操作发生在预期模式之外，可能会导致数据不一致。尽管这种方法简单，但容易出现偏差（漂移），因此并不常用。

基于差异（快照）的 CDC

基于差异的 CDC 通过比较整表或整个数据库的快照来明确识别是否发生了变更。基于差异的方法资源消耗较大，因为它们需要对源环境进行全量扫描，从而产生高昂的资源成本。这种系统在生产流处理场景中很少使用，但在批处理提取、转换、加载（ETL）管道中却很常见。

CDC 管道包含多个协同工作的组件，用于将更改从源系统准确传输到目标消费者。

源连接器

源连接器是负责与源系统交互并捕获其任何更改的组件。通常，这会采用读取事务日志或监控触发器等策略，具体取决于所使用的 CDC 管道类型。

更改事件流

更改事件流是负责接收源数据库中检测到的更改并进行传输的传输层。大多数情况下，该组件由 Apache Kafka 等分布式消息系统或托管流式传输服务来实现。

架构注册表

架构注册表负责跟踪版本并强制执行架构规则，从而帮助管理源系统中的架构演变。您需要架构注册表来确保生产者系统与消费者系统之间的数据保持兼容。

接收端连接器/消费者系统

接收端连接器（Sink connector）通过将更改事件写入消费者系统，将其交付给该系统。这是 CDC 流程的最后一步，即更新消费者系统中的记录，使其与源数据库保持一致。

以下是 CDC 用于实时数据移动和一致性的一些常见用例。

数据库复制与同步

您可以利用 CDC 跨多个数据库一致地复制和同步数据。通过在变更发生时将其传播到多个目标，您可以使多个数据库保持同步。

实时分析和数据仓库

实时分析系统和仪表板依赖最新且及时的数据。CDC 持续将操作数据集成到这些系统中，确保数据保持最新，而无需等待批处理作业运行。

事件驱动型微服务

CDC 通过将数据库中的变更转化为事件来帮助实现事件驱动型架构；微服务能够实时响应这些事件，而无需与源系统直接耦合。这样可以在不增加架构负担的情况下实现敏捷性和及时性。

缓存失效

CDC 可以提高缓存失效处理（即在源数据发生变更时，从缓存中移除陈旧数据）的效率。每当插入、更新或删除数据时，CDC 都会生成相应的事件，从而允许下游系统使缓存失效或利用新值更新缓存。系统无需依赖定期的缓存刷新即可实现低延迟访问。

审核日志文件和合规性

在审计数据处理流程时，CDC 非常有用，因为它能记录随时间推移对数据所做的所有更改。特别是在监管严格的环境中，这种包含更改内容、发生时间及操作人员的详尽记录，能让审计工作更加简单明了。

CDC 将每一次插入、删除和更新操作都捕获为独立事件，从而自然地支持审计与合规流程。您可以查看这些事件的历史记录，从而清晰地了解所有更改。

零停机数据库迁移

在将数据从一个系统迁移到另一个系统时，您可以利用 CDC 在整个迁移过程中持续将更改从源系统复制到目标系统。您可以先复制一份数据快照并将其关联到目标系统，然后通过流式传输源系统的任何更改来保持目标系统同步。

这样，您就可以在切换到新数据库之前实现系统间的完全同步，且无需停机或造成业务中断。

CDC 和 ETL 都能将数据从一处传输到另一处。但是，它们采用的方法不同，各自的优势也不同，并且主要应用于不同的场景。

CDC 在变更发生时即刻捕获并将其传播至下游系统，从而提供了一种低延迟的数据传输方式。ETL 系统则按批次间隔进行处理；这种方式虽然会引入延迟，但在进行大规模批量转换和处理时效率更高。

CDC 通过流式传输增量更新来均匀分配负载，而 ETL 由于需要同时处理大量任务，往往会造成周期性的负载高峰。由于 CDC 需要持续传输信息，其集成过程通常更为复杂；而 ETL 无需流式传输基础设施，实现起来相对简单直接。

AWS 提供一系列服务来帮助您大规模实施 CDC 管道。根据您的使用场景选择托管解决方案：

• Amazon Athena 是一项无服务器交互式查询服务，可简化数据分析，并且与 CDC 兼容，可实现近乎实时的查询。
• Amazon Kinesis Data Streams 每天从应用程序和服务日志、点击流数据、传感器数据以及应用内用户事件中摄取和收集数 TB 的数据，从而支持实时仪表板、生成指标并将数据传输到数据湖。
• Amazon Managed Streaming for Apache Kafka（Amazon MSK）是一项流式传输数据服务，可以管理 Apache Kafka 基础设施和运营，能够让开发人员和 DevOps 经理更轻松地在 AWS 上运行 Apache Kafka 应用程序和 Apache Kafka Connect 连接器。

立即创建免费账户，开始在 AWS 上实施变更数据捕获。