从 ETL 到 CDC：数据集成模式的演进

如果把现代数据架构的发展拉成一条时间线，“ETL → ELT → CDC”几乎就是过去二十多年里企业对数据需求不断升级的缩影。

早期企业的数据同步主要为了报表与审计，因此批处理就足够；后来云平台扩张，数据量指数级增长，业务需要更快的反馈；直到如今，“实时”成了默认期待，数据必须在变化的瞬间发挥价值。

这种变化让传统 ETL 不再充裕，也让 ELT 的“依赖云仓库批处理”开始感到吃力。企业需要一种能够持续输送数据、延迟极低、同时能够面对复杂异构系统的方式，于是 CDC 成为了数据集成模式演进的终点，也可能是新的起点。

为什么数据集成模式必须不断演进？

驱动力其实只有一个：业务需要的速度越来越快。

在系统规模较小时，每天夜间跑一次同步、清晨做分析完全够用。但当系统数量从几个变成几十甚至上百，数据更新频率从分钟级变为秒级，批处理的窗口开始被压缩，越来越多企业发现：

• 昨天的数据已经无法支撑今天的决策；

• 风控、监控、推荐这些场景根本等不了批处理结果；

• 复杂的调度脚本越来越难维护，也越来越脆弱。

于是企业不得不从“数据随时间推动”转向“数据随事件推动”，也就是从批处理走向实时。这正是 ETL → ELT → CDC 的核心逻辑。

ETL：为批处理时代而生的模式

ETL（Extract → Transform → Load）是最经典的数据集成方式，它设计之初就是为了解决“把数据批量搬到仓库里、做结构化处理”这件事。

在这个模式里，所有事情都围绕批处理展开：

• 数据先被抽取到中间层；

• 在进入仓库之前，清洗、转换、规范全部完成；

• 最后以大批量方式整体写入数据仓库。

这种模式的优势在于逻辑清晰，也非常成熟，几乎所有企业在早期都有 ETL 体系。但正是因为它“先转换再加载”，也意味着它完全依赖 固定调度窗口，无法实时更新数据。

当数据规模小、变化慢时 ETL 很好用；当数据规模大、变化快时，它就很吃力。

尤其是：

• 大表抽取耗时不断增加；

• 转换逻辑复杂且难以复用；

• 一旦批处理超时，次日业务分析都会受到影响。

对大量依赖实时数据的现代业务来说，ETL 已不再是主力工具。

ELT：云时代对 ETL 的一次“降本增效”

ELT（Extract → Load → Transform）是云数据仓库时代的产物。Snowflake、BigQuery、Redshift 等产品的高弹性算力，让企业可以把转换逻辑放在目标端执行。

与 ETL 相比，ELT 的变化很明显：

• 抽取更快：无需中间层转换，直接加载；

• 转换更强：借力云仓库算力处理复杂逻辑；

• 数据更新更灵活：可随时重跑转换逻辑。

ELT 的确让批处理变得更高效，但它并没有解决一个关键问题：它仍然是批处理。

换句话说，它提升了效率，却没有改变本质。

对于希望捕获“业务瞬时变化”的企业来说，ELT 仍然无法支撑真正实时的数据流转。

CDC：实时数据集成模式的核心技术

CDC（Change Data Capture）是数据集成模式演进中最重要的一步。它代表着从“搬运整批数据”转向“捕获每次变化”。当数据库发生 Insert、Update、Delete 时，CDC 能在几乎同一时刻捕获这些事件并传递给下游系统。

它解决了过去十多年里 ETL/ELT 一直无法解决的问题：持续、低延迟、非侵入的数据流转。

CDC 之所以能成为现代数据集成模式的主流，是因为它具备三点核心能力：

1. 延迟极低

CDC 不需要等到整批数据准备好，它捕获的是“事件”。业务完成写入，日志立即记录，CDC 立即捕获和传输。这种模式适合监控、推荐、精准营销、支付风控等秒级业务场景。

2. 对源库影响极小

日志解析不需要扫描整表、不需要触发器，也不依赖更新字段。无论是百亿级大表，还是高并发 OLTP 系统，都能稳定运行。

3. 能跨库跨类型表达数据变化

Oracle、MySQL、SQL Server、PostgreSQL、MongoDB 的日志结构差异极大，但 CDC 可以在解析后统一转换为标准事件，写入任意目标系统。这让企业真正具备了“异构系统实时打通”的能力。

三种模式的真正差异：不是速度，而是思维方式

很多人以为 ETL、ELT、CDC 的区别主要是延迟，但其实背后是三种完全不同的数据哲学。

• ETL：数据是静态的

    每天处理一次，数据像“批发货物”。

• ELT：数据是仓库里的资源

    数据提前放进仓库内部，再由仓库进行处理。

• CDC：数据是实时流动的事件

    变化就是事件，事件随时流入下游系统。

企业从 ETL 走向 CDC，不只是换工具，而是换思维：数据不再被动等待，而是主动流动。

CDC 如何与实时计算与实时服务层衔接

在 TapData 的实时数据平台中，CDC 不是终点，而是起点。

一个典型的 TapData 实时链路通常包含五个步骤：

1. 日志级 CDC 捕获

毫秒/秒级读取源库变化，无需扫描、无需改表。

2. 实时数据转换

清洗、映射、过滤、结构调整——全部流式处理。

3. 实时聚合（增量物化视图）

变化数据不仅同步，还能实时被聚合、预计算。

4. 多类型实时写入

写入 PostgreSQL、Doris、MongoDB、ES、Kafka 等任意目标。

5. API 服务化

最新数据通过 API 提供给业务系统，真正实现“数据即服务”。

相比只捕获变化的单纯 CDC 工具，TapData 提供的是 从捕获 → 计算 → 服务化的一体化链路。

结语：CDC 是未来数据集成模式的基础设施

回头看 ETL、ELT、CDC 的演进路径，可以发现一个非常显著的趋势——业务对数据的依赖越来越直接、越来越实时。

ETL 解决的是“昨天的问题”，ELT 解决的是“今天的问题”，而 CDC 解决的是“此刻的问题”。当一个企业开始依赖实时监控、实时风控、实时洞察、实时客户视图时，数据不再是“辅助分析”的工具，而是系统行为的一部分。

在这种情况下，CDC 不只是一个技术术语，而是企业实时化能力的底座。在新的时代里，CDC 已从“数据同步方式”升级为“数据基础设施”。

>>> 申请试用

【相关阅读】

• Change Data Capture（CDC）是什么？主流实现方式对比

• 日志解析在异构数据库数据集成中的作用

• 实时数据集成 vs 批处理：为什么“近实时”还不够

• 从 ETL 到 CDC：数据集成模式的演进

• 从“组件堆叠”到 Operational Data Hub：实时集成的新形态