什么是变更数据捕获（CDC）？新手指南

变更数据捕获（CDC）通过仅捕获插入、更新和删除操作，而非重新加载整个数据集，来保持数据管道的高效性。这能降低处理时间和系统负载。

CDC 也是实时数据流中的关键组件，可与 Apache Kafka 等平台集成，支持事件驱动架构。

让我们深入了解 CDC，以及它如何改进您的数据项目！

什么是变更数据捕获（CDC）？

变更数据捕获是一种方法，它仅检测、捕获并将源系统中被修改的数据转发到下游系统，例如数据仓库、仪表盘或流式应用。

CDC 不再重新处理整个数据集，而是专注于增量变更，确保目标系统始终能够获取到最新可用的数据。

在一次实时分析项目中，我因批处理更新而遭遇严重的报表延迟。通过切换到基于日志的 CDC 方案，我将数据新鲜度的滞后从数小时大幅降至数秒，使分析仪表盘真正实现了实时。

基于这段亲身经历所凸显的 CDC 实用价值，接下来我们来看一下实现 CDC 的不同方法。

实现变更数据捕获的方法

在深入具体技术前，需要认识到没有一种方法适用于所有场景。下面是四种常见的 CDC 方法，它们各有优劣与权衡。

基于日志的 CDC

基于日志的 CDC 读取数据库的事务日志（通常称为预写日志，WAL），以在变更发生时即时识别。这种方法效率很高，因为它在较低层面运行，以最小的对生产系统干扰来捕获变更。

优点：系统开销低、近实时性能强，适合高吞吐环境。
缺点：需要对事务日志的特权访问，并依赖于正确的日志保留设置。

例如，在 PostgreSQL 中，您可以设置逻辑复制以从 WAL 捕获变更：

-- Enable logical replication
ALTER SYSTEM SET wal_level = logical;

-- Create a logical replication slot to capture changes
SELECT pg_create_logical_replication_slot('cdc_slot', 'pgoutput');

-- Fetch recent changes from the WAL
SELECT * FROM pg_logical_slot_get_changes('cdc_slot', NULL, NULL);技术支持

这种方式允许 CDC 工具（如我们稍后将探讨的 Debezium 或 AWS DMS）持续将数据库变更流式传输到下游系统，而无需依赖定时查询。

基于触发器的 CDC

基于触发器的 CDC 使用附加在源表事件（插入、更新或删除）上的数据库触发器，在变更发生时自动记录。这种方法对于支持触发器的数据库而言实现简单，并能即时捕获变更；但如果管理不当，可能会增加数据库负载，并使架构变更变得复杂。

优点：对于支持触发器的数据库，实现简单，并可立即捕获变更。
缺点：可能增加数据库额外负载，且在管理不当时会使架构变更更复杂。

基于触发器的 CDC 具有即时性，但可能带来额外开销，因此最适合事务量适中的环境。

在 PostgreSQL 中，您可以创建一个触发器，将 customers 表的变更记录到单独的 customers_audit 表：

-- Create an audit table to store changes
CREATE TABLE customers_audit (
    audit_id SERIAL PRIMARY KEY,
    operation_type TEXT,
    customer_id INT,
    customer_name TEXT,
    modified_at TIMESTAMP DEFAULT now()
);

-- Create a function to insert change records
CREATE OR REPLACE FUNCTION capture_customer_changes()
RETURNS TRIGGER AS $
BEGIN
    IF TG_OP = 'INSERT' THEN
        INSERT INTO customers_audit (operation_type, customer_id, customer_name)
        VALUES ('INSERT', NEW.id, NEW.name);
    ELSIF TG_OP = 'UPDATE' THEN
        INSERT INTO customers_audit (operation_type, customer_id, customer_name)
        VALUES ('UPDATE', NEW.id, NEW.name);
    ELSIF TG_OP = 'DELETE' THEN
        INSERT INTO customers_audit (operation_type, customer_id, customer_name)
        VALUES ('DELETE', OLD.id, OLD.name);
    END IF;
    RETURN NULL; -- No need to modify original table data
END;
$ LANGUAGE plpgsql;

-- Attach the trigger to the customers table
CREATE TRIGGER customer_changes_trigger
AFTER INSERT OR UPDATE OR DELETE ON customers
FOR EACH ROW EXECUTE FUNCTION capture_customer_changes();技术支持

该触发器确保对 customers 表的每次 INSERT、UPDATE 或 DELETE 都会实时记录到 customers_audit 中。

基于轮询的 CDC

基于轮询的 CDC 会定期查询源数据库，根据时间戳或版本号列检查变更。此方法无需直接访问事务日志或触发器，但可能引入延迟，因为变更仅在固定间隔被检测到。

优点：当无法访问日志或不支持触发器时，易于实现。
缺点：可能延迟变更捕获；若轮询过于频繁，会增加负载。

当无法实时访问日志时，此方法很有效，但代价是检测变更会有轻微延迟。

设想一个带有 version_number 列（每次更新都会递增）的 products 表：

SELECT *
FROM products
WHERE version_number > 1050
ORDER BY version_number ASC;技术支持

这里的 1050 是上一次轮询周期处理的最后一个版本号。这样可以在不依赖时间戳的情况下仅抓取新变更，当系统时钟不可靠时更具鲁棒性。

基于时间戳的 CDC

基于时间戳的 CDC 依赖一个专用列记录每条记录的最后修改时间。通过比较这些时间戳，系统可识别自上次检查以来发生变更的记录。

该方法与基于轮询的 CDC 类似，但更为结构化，因为它需要显式的变更跟踪机制：

基于轮询的 CDC 是更广义的方法，定期通过任何可识别模式（时间戳、版本号或其他指示器）查询变更。
基于时间戳的 CDC 依赖源数据库中准确维护的时间戳列。

当数据库能自动更新时间戳时实现起来很容易，但它依赖系统时钟的一致性以及时间戳更新的可靠性。

优点：当系统可自动更新时间戳时，方法简单。
缺点：准确性取决于时钟同步的一致性和时间戳更新的可靠性。

假设我们有一个带有 last_modified 列（每当插入或修改行都会更新）的 orders 表。以下 SQL 查询会获取自上次检查以来的所有变更：

SELECT *
FROM orders
WHERE last_modified > '2025-02-25 12:00:00'
ORDER BY last_modified ASC;技术支持

当数据库在修改时能自动更新时间戳（例如使用触发器或 PostgreSQL 的 DEFAULT now()、MySQL 的 ON UPDATE CURRENT_TIMESTAMP 等机制）时，该方法表现良好。

CDC 方法对比表

下方是一个对比表，突出展示四种变更数据捕获（CDC）方法之间的关键差异：

特性	基于日志的 CDC	基于触发器的 CDC	基于轮询的 CDC	基于时间戳的 CDC
工作原理	读取数据库事务日志（WAL、binlog 等），实时捕获变更。	使用数据库触发器将变更记录到审计表。	定期基于版本号或其他条件查询变更。	比较列中的时间戳以检测变更。
延迟	近实时（低延迟）。	即时（触发器即时执行）。	按计划间隔（可能引入延迟）。	取决于轮询频率（低到中等延迟）。
系统开销	低（无需查询表）。	高（每次变更都运行触发器）。	中等（取决于轮询频率）。	低到中等（依赖时间戳）。
实现复杂度	高（需要访问事务日志并正确设置保留）。	中高（需要创建触发器并维护审计表）。	低（依赖简单 SQL 查询）。	低（若时间戳自动管理则更简单）。
访问要求	对事务日志的特权访问。	需要 DDL 权限以创建触发器。	无需特殊访问（标准 SQL）。	无需特殊访问（标准 SQL）。
是否支持删除？	支持（从日志中捕获）。	支持（若在审计表中记录）。	需要额外跟踪（如单独的删除表）。	仅在使用软删除（deleted_at）时支持。
最佳用例	高吞吐、实时复制，对数据库负载要求极低的场景。	需要即时捕获变更的小型到中型工作负载。	当无法使用基于日志的 CDC 和触发器，但可接受定期更新时。	当时间戳可自动更新且可进行较频繁轮询时。
常用工具	Debezium、AWS DMS、StreamSets、Striim、HVR	数据库原生触发器（PostgreSQL、MySQL、SQL Server、Oracle）	Apache Airflow、ETL 脚本（Python、SQL）	ETL 作业、批处理数据管道

变更数据捕获的使用场景

理解方法只是其中一半，同样重要的是了解 CDC 在真实场景中如何创造可见价值。

实时数据仓库

CDC 通过仅传播变更而非重载完整数据集，实现对数据仓库的持续增量更新。这样可确保商业智能工具和仪表盘显示最实时的数据。

例如，零售公司可以近实时地更新销售仪表盘，快速洞察新出现的趋势与见解。

数据复制

CDC 通过确保源系统中的任何变更都能立即在目标数据库中镜像，实现跨系统复制。这在数据迁移项目中，或在混合环境中维护备份与副本时尤为有用。

例如，将本地系统的数据复制到 AWS RDS 或 Snowflake 等云数据库，可确保跨平台一致性。

数据同步

在分布式系统（如涉及微服务或多个应用）中，CDC 通过实时同步变更，确保每个组件都使用最新数据。

例如，在各个平台间同步客户信息，可以保持一致的用户体验。

数据审计与监控

最后，CDC 提供详尽的变更日志，对于审计至关重要。通过追踪是谁在何时进行了变更，团队能够满足合规要求、排查问题并开展深入的取证分析。

例如，金融机构依赖全面的 CDC 日志来审计客户数据改动，确保遵守严格的数据治理政策。

实现变更数据捕获的工具

在了解了方法与应用场景之后，让我们看看一些常用的 CDC 实施工具。正确的选择取决于您的用例——无论您需要实时流处理、云迁移，还是企业级 ETL 方案。

AWS Database Migration Service（DMS）

AWS DMS 使用基于日志的 CDC，将本地系统的数据持续复制到 AWS 云，且停机时间最小，非常适合迁移。如果您的目标是稳定地将数据迁移到云端，AWS DMS 是一个稳健的选择。

最适合：云迁移与基于 AWS 的架构。

AWS DMS 架构。图片来源：AWS

Debezium

Debezium 是一个开源 CDC 平台，可将数据库变更捕获并流式传输到 Apache Kafka 等系统。

就我个人而言，我发现 Debezium 在将数据库变更流入 Kafka 时非常实用，尤其在多个服务依赖实时更新的分布式环境中。其可扩展性与集成能力使其脱颖而出。

最适合：实时数据流与事件驱动架构。

使用 Kafka Connect 与 Debezium 的数据流架构。图片来源：Debezium

Apache Kafka

Apache Kafka 本身不是 CDC 工具，但与 Debezium 等工具配合时，是处理 CDC 事件的骨干平台。 Kafka 支持可靠的事件驱动管道、实时分析以及跨多个消费者的数据同步。

最适合：将 CDC 数据流入事件驱动架构。

为说明如何将 CDC 事件发送到 Kafka，来看下面的 Python 代码片段。该代码初始化一个 Kafka 生产者，并将一个 CDC 事件（表示对 orders 表的更新操作）发送到名为 cdc-topic 的 Kafka 主题：

from kafka import KafkaProducer
import json

# Initialize the Kafka producer with bootstrap servers and a JSON serializer for values.
producer = KafkaProducer(
    bootstrap_servers='localhost:9092',
    value_serializer=lambda v: json.dumps(v).encode('utf-8')
)

# Define a CDC event that includes details of the operation.
cdc_event = {
    "table": "orders",
    "operation": "update",
    "data": {"order_id": 123, "status": "shipped"}
}

# Send the CDC event to the 'cdc-topic' and flush to ensure transmission.
producer.send('cdc-topic', cdc_event)
producer.flush()
print("CDC event sent successfully!")技术支持

Talend 和 Informatica

Talend 与 Informatica 是综合性的 ETL 平台，提供内置 CDC 功能以捕获和处理数据变更，减少手动配置。在复杂的数据转换场景中，它们尤为有利，集成式方案可以简化运维。

最适合：带内置 CDC 的企业级 ETL 方案。

数据库原生 CDC 方案

多种关系型数据库提供原生 CDC 功能，减少对外部工具的依赖：

PostgreSQL 逻辑复制：从 WAL 捕获变更并将其流式传输给订阅者。
SQL Server Change Data Capture（CDC）：使用事务日志自动跟踪变更。
MySQL 二进制日志（binlog）复制：记录变更以实现复制。

最适合：尽量减少对外部 CDC 工具的依赖。

Google Datastream 与 Azure Data Factory

云服务商也为其生态提供 CDC 方案：

Google Datastream：面向 Google Cloud 用户的全托管 CDC 与复制服务。
Azure Data Factory CDC：为 Azure SQL、CosmosDB 和 Synapse Analytics 启用变更跟踪与复制。

最适合：在 Google Cloud 或 Microsoft Azure 环境内实施 CDC。

CDC 的挑战与局限

尽管 CDC 具有显著优势，但要实现可靠落地也需应对一系列挑战。

处理数据完整性问题

在面对网络中断、延迟事务或系统故障时，维护数据完整性可能具有挑战。健壮的错误处理机制与定期对账对于防止源与目标系统之间出现不一致至关重要。及早解决这些问题有助于维持可靠的数据管道。

性能开销

某些 CDC 方法——尤其依赖触发器或高频轮询的方法——会给源数据库带来额外负载。在追求近实时更新与生产系统性能约束之间取得平衡，是平稳运行的关键。

管理复杂的数据转换

虽然 CDC 能高效捕获原始变更，但下游可能仍需进行数据清洗或转换等处理。将转换逻辑整合进来、同时不延迟交付或引入错误，会增加实现复杂度，因此需要周密规划。

实施 CDC 的最佳实践

将理论落地需要遵循最佳实践。以下是我在构建稳健 CDC 管道时行之有效的可操作建议。

选择合适的实现方法

选择与您的数据量、延迟要求及系统架构相契合的 CDC 方法。对于高事务环境，基于日志的 CDC 通常更优；而基于触发器或轮询的方法可能更适合小规模应用。前期充分评估需求可节省后续的时间与资源。

监控作业

使用实时仪表盘与自动告警实现全面监控。定期审查日志与进行健康检查，确保每次变更被准确捕获，并能及时处理任何问题。

我曾在一个项目中因基于日志的 CDC 轻微配置错误而数日未被察觉，导致下游分析出现静默数据丢失。引入 Grafana 告警后，能够即时发现缺失更新，避免了代价高昂的错误。

确保数据质量

在 CDC 管道内集成数据验证检查，确保仅传播准确且一致的变更。

根据我的经验，在 CDC 管道中设置自动化验证检查，为我节省了大量因错误数据传播而产生的调试时间。dbt 与 Apache Airflow 等工具对于在多个下游系统间强制执行一致性非常关键。

上线前充分测试

在将 CDC 方案迁入生产前，请在预发布环境进行全面测试。模拟真实负载与故障场景，并验证回滚与时光回溯等功能，确保系统在各种条件下都能按预期运行。严格的测试对顺利上线非常重要。

策略性地处理架构演进

随着数据集演进，您的 CDC 系统必须能在不造成中断的情况下适配架构变化。使用支持自动架构演进的工具，并做好版本控制，以便平滑整合新字段。这种策略性做法可在数据结构变化时避免意外错误与停机。

结论

通过精准捕获仅被修改的数据，CDC 将系统负载降至最低，并支持实时分析与流式应用的有效运行。无论您是在实施数据复制、同步，还是审计日志，选择合适的 CDC 方法并遵循最佳实践，都是构建可靠高效数据管道的关键。

若您希望进一步深入了解，建议探索以下 DataCamp 课程：

Introduction to Data Engineering – 学习构建稳健数据管道与整合多种数据源的基础技术。
Big Data Fundamentals with PySpark – 动手实践 Apache Spark 与 PySpark，处理并分析海量数据集。
Data Engineer in Python – 使用 Python 构建端到端数据管道，实践使用 Apache Kafka 等工具进行流式数据集成。

祝您编码顺利——也祝您构建出坚韧可靠的实时数据系统！

FAQs

CDC 如何增强现代数据架构中的实时分析？

CDC 仅从源数据库捕获增量变更，从而减少对批量 ETL 作业的依赖。这确保分析仪表盘和流式应用始终可访问最新数据，降低延迟与系统负载。

在全面上线前，测试 CDC 实施的实用步骤有哪些？

搭建预发布环境以模拟生产负载；监控数据完整性、延迟与错误处理；若可用，利用时光回溯功能执行回滚测试，以验证恢复流程。

使用 CDC 时如何处理架构演进？

在 CDC 管道中纳入架构版本控制与自动验证步骤。在受控环境中测试架构变更以确保向后兼容，并使用支持自动架构演进的 CDC 工具。

您推荐哪些 CDC 管道的监控工具或实践？

集成仪表盘（如使用 Grafana）与告警系统来跟踪 CDC 执行指标。定期审查日志与自动健康检查有助于及早发现性能瓶颈或数据质量问题。

在高吞吐、低延迟的环境中应选择哪种 CDC 方法？

对于此类环境，基于日志的 CDC 通常是最佳选择，因为它直接读取数据库事务日志（WAL），将对生产负载的影响降至最低，并提供近实时更新。

作者

Khalid Abdelaty

我是一名数据工程师兼社区建设者，专注于数据管道、云端与 AI 工具链，同时为 DataCamp 和新兴开发者撰写实用且高影响力的教程。

主题

数据工程数据分析