首页/数据/数仓建模速查/ODS 同步方式对照:全量/增量/CDC
分层与规范64 条

ODS 同步方式对照:全量/增量/CDC

三种同步方式按表特征选择:小表全量快照、带更新时间的大表按时间戳增量、要求删除感知与低延迟的走 CDC;下表给出适用与风险。

数仓建模速查数据更新于 2026-10-13

三种同步方式

ODS 的数据同步方式决定成本、延迟与数据完整性,常见三种:全量快照(每次把源表整表拉一遍)、时间戳增量(只拉 update_time 落在区间内的行)、CDC 日志(解析数据库变更日志,捕获包括删除在内的每一次变更)。选择依据是表的大小与业务特征:小表适合全量,大表且更新不频繁适合时间戳增量,要求删除感知与低延迟的才上 CDC。

基本信息

全量快照每次抽整表,实现最简单
时间戳增量按 update_time 区间抽取,成本低
CDC 日志解析变更日志,可捕获删除
选择依据表大小、延迟要求、是否需要删除感知

典型使用场景

  • 小表与维表:每天全量覆盖,简单可靠,不怕源端改字段
  • 带 update_time 的大表:按时间戳区间增量,单日只扫当天变更
  • 需要感知物理删除的表:CDC 解析变更日志,删除也作为事件落进 ODS
  • 低延迟场景:CDC 准实时同步,直接供实时链路消费
  • 对源库压力敏感:CDC 从从库日志读取,几乎不增加业务库查询压力

同步方式对照

方式适用主要风险
全量快照小表、维度表大表 IO 与耗时长,挤占抽数窗口
时间戳增量带可靠 update_time 的表漏掉物理删除,时钟漂移导致漏抽或重复
CDC 日志大表、需删除感知、低延迟运维复杂,日志超保留期会丢变更

增量抽取条件

增量抽取条件
SELECT *
FROM src_order
WHERE update_time >= '2026-10-13 00:00:00'   -- 左闭右开,避免边界重复
  AND update_time <  '2026-10-14 00:00:00';
-- 对照:小表照整抽,简单但成本随表增长
INSERT OVERWRITE TABLE ods_order_snap PARTITION (dt='2026-10-13')
SELECT * FROM src_order;
时间戳增量抓不到物理删除:源端删掉一行,ODS 里那行会一直留着,日积月累口径偏大。要么在源端维护删除表或删除标记,要么改用 CDC 补齐。
左闭右开的时间区间(大于等于起点、小于终点)是避免边界重复或漏抽的常见做法。跨零点运行的作业还要留意调度延迟,宁可留出轻微重叠区间,再在 DWD 层按主键去重。

易错点

  • 用 create_time 当增量字段:历史数据的更新全部丢失,只有新增能被同步
  • 时间区间两头都闭:边界时刻的数据被抽两次,只能靠下游去重兜底
  • CDC 不关注日志保留期:日志被清理后变更永久丢失,只能重做一次全量对齐
  • 用全量快照抽大表:抽数窗口被拉长,下游全部任务的产出时间跟着后移
  • 既不做删除感知也不定期对账:源端删除的行长期残留在 ODS,指标持续偏大

数据来源与参考

  • 阿里《大数据之路:阿里巴巴大数据实践》
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌