CDC 进数仓是什么
CDC 进数仓有两条常见路径：一是在 ODS 建 append-only 的变更日志表，保留全部变更（可重放、可审计），由 DWD 负责去重、清洗与维度关联；二是直接按主键 upsert 成贴源镜像表，查询即用。直投镜像表省存储、省加工，但丢失变更全历史，事后需要重放时只能回到源端——因此选择哪条路径，本质是在「追溯能力」与「存储与加工成本」之间做权衡。
基本信息
| 路径一 | ODS 变更日志表：追加写入，保留 op、位点、事件时间等列 |
|---|---|
| 路径二 | ODS 贴源镜像表：按主键 upsert，与源表结构接近 |
| 位点列 | 建议保留源端文件名与偏移，或 GTID，便于对账与续传 |
| 去重位置 | 日志表到 DWD 的加工环节按主键与位点去重 |
| 分区与生命周期 | 日志表按天分区并设定保留期，否则存储增长不可控 |
| 下游加工 | DWD 负责清洗与维度退化，DWS 与 ADS 面向指标 |
典型使用场景
- 审计与追溯要求高的场景：需要还原任意历史时点的数据状态
- 口径变更需重算：有完整变更日志才能按新逻辑回刷历史
- 实时看板支撑：镜像表可直接读，省去加工层延迟
- 对账排障：日志表里的位点与操作类型可用于定位差异来源
- 多下游复用：一份日志表同时支撑明细重算与实时镜像两条链路
分层落地示意
分层落地示意
# 变更流从源端一路向下
binlog -> CDC -> Kafka（变更流）
-> ODS：变更日志表（追加 + 位点列）或贴源镜像表（upsert）
-> DWD：去重 / 清洗 / 维度关联
-> DWS / ADS：聚合与指标日志表落库与去重加工
日志表落库与去重加工
-- ODS 变更日志表：只追加，保留位点与事件时间，不覆盖历史
INSERT INTO ods_trade_order_change_log
SELECT order_id, op, before_json, after_json,
source_file, source_pos, ts_ms, etl_time
FROM cdc_stage WHERE dt = '2026-10-11';
-- DWD 加工：按主键与位点去重，剔除删除事件
INSERT OVERWRITE TABLE dwd_trade_order_di PARTITION (dt = '2026-10-11')
SELECT order_id, user_id, pay_amount, status
FROM (
SELECT after_json.order_id AS order_id, after_json.user_id AS user_id,
after_json.pay_amount AS pay_amount, after_json.status AS status,
ROW_NUMBER() OVER (PARTITION BY order_id, source_file, source_pos ORDER BY ts_ms DESC) AS rn
FROM ods_trade_order_change_log
WHERE dt = '2026-10-11' AND op <> 'd'
) t WHERE t.rn = 1;两条路径对照
| 对比项 | 变更日志表 | 贴源镜像表 |
|---|---|---|
| 内容 | 全部变更，含删除 | 仅最新状态 |
| 可重放 | 可以，任意区间重算 | 不可以，需回源端 |
| 存储成本 | 高，随变更量增长 | 低，约等于源表规模 |
| 查询便利 | 需加工才能用 | 可直接查询 |
| 适用判断 | 追溯与重算需求强 | 只关心当前状态 |
只落镜像表不落日志表，事后需要重放变更时没有原始素材，只能回到源端重新抽取，窗口与风险都大得多。
变更日志表必须配分区与生命周期策略：不做归档与清理，存储成本会随业务量持续上升，最终挤压其他表的预算。