数据集成实战：从数据库到数仓，全量增量、CDC与任务编排

去年一个客户，每天把业务数据库的全量数据拷贝到数仓。刚开始数据量小，没问题。一年后，单表过亿，全量导出要2小时，导入又要2小时。业务方等不及，因为报表要等数据同步完才能跑。

他们问我：“是不是该换更快的数仓？”

我说：“你这不是数仓慢，是同步方式不对。天天搬全量，数据量只会越来越大。”

这是数据集成最常见的误区：数据量小时，全量同步很简单；数据量大了，还在用全量，就是灾难。

今天聊聊数据集成。不是那种“ETL很重要”的入门课，而是帮你理清楚：全量、增量、CDC怎么选？ETL还是ELT？任务怎么编排？

01 三种同步方式

方式一：全量同步

每次把源表全部数据拷贝到目标。

• 优点：简单，不用识别变更，适合首次加载或小表

• 缺点：数据量大时慢，消耗源库IO，目标表可能有短暂数据不一致

• 适合：首次全量加载、维度表、小表

方式二：增量同步

只同步上次同步后变化的数据。需要源表有时间戳字段（如updated_at）或版本号。

• 优点：数据量小，速度快

• 缺点：依赖源表有可靠的变更标记；物理删除的行无法捕获

• 适合：大部分业务表的日常同步

方式三：CDC（变更数据捕获）

直接从数据库日志（binlog、WAL）捕获变更，实时或准实时。

• 优点：实时性高，能捕获删除操作，对源表无侵入

• 缺点：需要开启数据库日志，有一定性能开销；配置复杂

• 适合：实时同步、数据量极大、需要捕获删除的场景

那家客户每天全量同步，10亿行表，导出2小时，导入2小时。改增量同步后，只同步过去24小时变化的数据，每次10-20分钟。

02 CDC不是银弹

CDC很强大，但有几个坑。

坑一：日志保留时间

CDC读取binlog，如果同步任务停了几天，binlog可能已被清理，需要重新全量同步。

解法：监控同步延迟，延迟超过阈值告警。合理设置binlog保留时间（如3天）。

坑二：DDL变更

源表改了结构（加列、删列），CDC任务可能报错。需要同步任务能处理Schema变更，或提前协调变更窗口。

坑三：无主键表

CDC需要唯一标识行，无主键表不好处理。尽量给表加主键。

那家客户用CDC同步订单表，效果很好。但有一次DBA加列没通知，CDC任务挂了半天。后来加了Schema变更告警，变更前自动暂停任务。

03 ETL vs ELT

数据处理有两种模式。

ETL（抽取-转换-加载）：在同步过程中转换数据，然后加载到目标。

• 适合：数据清洗逻辑复杂、目标数仓计算能力弱（如传统数仓）、需要减少数据量

• 工具：Glue、DataX、Informatica

ELT（抽取-加载-转换）：先同步原始数据到目标，在数仓内转换。

• 适合：目标数仓计算能力强（如BigQuery、Snowflake）、转换逻辑可能变化、希望保留原始数据

• 工具：DMS + dbt、Airbyte + SQL

那家客户用ELT：先用DTS把数据同步到数仓的原始层（Staging），再用dbt在数仓内转换。数仓是Snowflake，计算能力强，转换速度快。不需要在同步过程中做复杂转换。

04 任务编排：不止是定时跑

数据集成任务不是“设个cron”就行。要考虑依赖、重试、告警。

依赖管理：ODS层同步完，才能跑DWD层；DWD层跑完，才能跑DWS层。用DAG（有向无环图）表达依赖。

重试机制：临时网络故障、源库抖动，自动重试。指数退避，不要死循环。

数据质量检查：同步后检查行数是否符合预期、主键是否唯一、关键字段是否有空值。不通过则告警或暂停下游。

告警与可观测性：同步延迟告警、失败告警、数据量波动告警。

工具：Airflow、DolphinScheduler、AWS Glue Workflow、Azure Data Factory

那家客户用Airflow编排：

• DAG定义：MySQL → ODS → DWD → DWS → 报表

• 重试3次，间隔5分钟

• 行数校验：ODS行数与源库差异<5%

• 失败时发钉钉告警，自动暂停下游

05 选型决策表

06 一个真实案例：从全量到CDC

一个金融客户，每天同步交易流水表。数据量从几百万涨到几亿，全量同步从30分钟涨到4小时。报表延迟越来越严重。

改造方案：

• 日常同步：改CDC，延迟秒级。交易流水表开启binlog，Debezium + Kafka + ClickHouse

• 维度表：增量同步（有updated_at字段）

• ETL改ELT：原始数据同步到ODS层，dbt在数仓内转换

• Airflow编排：CDC任务实时运行，下游任务等待数据就绪（感知分区）

改造后，交易流水从产生到可在报表查询，延迟从4小时降到5分钟。业务方说：“以前看昨天数据，现在看5分钟前数据。”

写在最后

数据集成不是“数据搬过去就行”。同步方式选错，数据量大了会崩；转换模式选错，开发效率低；编排没做好，任务挂了没人知道。

那家客户的运维负责人后来总结：“全量增量看数据量，实时程度选CDC，转换后置ELT更灵活，编排不牢地动山摇。”

你的数据管道，是搬过去就行，还是需要好好设计？