3. 数据加载策略：全量加载、增量加载、CDC 与流式加载

数据加载，说白了就是决定「怎么把数据从源端搬到目标端」。这个选择直接影响你的管道延迟、存储成本和运维复杂度。我见过不少团队，一上来就全量跑，跑着跑着就跑不动了——嗯，今天我们就来把这几种策略掰开揉碎讲清楚。

3.1 全量加载（Full Load）

全量加载，就是每次把源表的所有数据全部复制到目标端。简单粗暴，但代价也高。

适用场景：

• 数据量小（百万级以内）
• 源表没有时间戳或变更标记
• 初次加载或数据重建
• 维度表等低频变更表

我踩过的坑：有一次，客户说「表不大，全量就行」。结果跑了半年，表从 50 万行涨到 2 亿行，全量加载从 3 分钟变成 3 小时。嗯，这就是典型的「初期偷懒，后期还债」。

3.2 增量加载（Incremental Load）

增量加载只处理「新增」或「修改」的数据。核心依赖一个可靠的增量标记字段。

常见的增量标记方式：

方式	原理	优点	缺点
时间戳	根据 update_time 或 create_time 过滤	实现简单	依赖系统时钟，可能漏数据
自增 ID	记录上次最大 ID，取大于该值的数据	性能好	只能处理新增，无法捕获修改
版本号	数据行带版本字段，递增	可追踪变更	业务改造成本高
状态标记	数据行有「已同步」标记	可控性强	需要业务配合修改

我个人习惯：能用时间戳就用时间戳。但要注意——如果源库的时间戳精度不够（比如只到秒），同一秒内的并发写入就可能漏掉。我曾经因为这个原因，凌晨三点被电话叫醒……

3.3 CDC（变更数据捕获）机制

CDC 是增量加载的「进阶版」。它不依赖业务字段，而是直接从数据库的事务日志（如 MySQL 的 binlog、PostgreSQL 的 WAL）中捕获变更。

CDC 的三种主流实现：

1. 基于日志的 CDC：解析 binlog/WAL，实时性高，对源库无侵入。我推荐这个方案。
2. 基于触发器的 CDC：在源表上建触发器，记录变更到审计表。性能开销大，不推荐。
3. 基于时间戳的 CDC：其实就是增量加载，只是叫法不同。

CDC 的典型架构：

CDC 的优缺点：

• 优点：实时性高、对源库无侵入、能捕获删除操作
• 缺点：架构复杂、需要维护 CDC 组件、binlog 保留期有限

3.4 批量加载 vs 流式加载

这两个概念经常被放在一起比较。其实它们解决的是不同维度的需求。

维度	批量加载（Batch）	流式加载（Streaming）
触发方式	定时调度（每小时/每天）	事件驱动（数据一到就处理）
延迟	分钟级到小时级	秒级到毫秒级
吞吐量	高，适合大批量数据	中等，适合持续小批量
容错	容易重试，幂等性好	需要处理乱序和重复
典型工具	Airflow、dbt、Spark	Kafka、Flink、Kinesis

我的建议：不要为了「实时」而实时。很多业务场景，T+1 的批量加载完全够用。你想想看，一个月度报表，需要秒级延迟吗？

但有些场景，流式加载是刚需：

• 风控系统：需要实时识别异常交易
• 监控告警：延迟超过 10 秒就可能造成损失
• 实时大屏：领导要看「此时此刻」的数据

3.5 如何选择？一张决策表

最后，我整理了一张决策表，帮你快速判断该用哪种策略：

场景	推荐策略	理由
小表（<100万行），低频变更	全量加载	简单，维护成本低
大表，有更新时间戳	增量加载（时间戳）	性能好，实现简单
大表，需要捕获删除	CDC	日志级捕获，不丢数据
实时报表/风控	流式加载	秒级延迟，事件驱动
数据湖批量入仓	批量加载	高吞吐，适合大规模
既有实时需求，又要全量对账	批流一体	兼顾实时与一致性

嗯，数据加载策略就讲到这里。记住一句话：没有最好的策略，只有最合适的策略。选型的时候，多问问自己——我的业务真的需要实时吗？我的数据量真的撑不住全量吗？想清楚了再动手。