CDC 变更流到 SCD 的落地
用 CDC 捕获源库变更（常见是数据库日志解析）后，拿到的是变更时机与前后镜像，但保留策略仍要由 SCD 类型决定：CDC 只解决『什么时候变了』，SCD 解决『历史要不要留、怎么留』。落地时把变更事件按自然键合并，与当前版本比对后走对应的处理逻辑。物理删除事件要特别处理，通常转换为失效标记或状态列，而不是从维表里物理删除行，否则历史事实会失去关联对象。
基本信息
| CDC 提供 | 变更时机、前后镜像、操作类型 |
|---|---|
| SCD 决定 | 保留策略：覆盖、插版本或只留标记 |
| 合并键 | 按自然键排序合并，同键同批次只取最新 |
| 删除处理 | 转失效标记，不物理删除维表行 |
| 乱序风险 | 并发下事件可能乱序，需按变更时间排序去重 |
典型使用场景
- 用户主数据同步：源库变更经 CDC 实时推到数仓，按类型 2 落版本
- 商品上下架：下架事件转为失效标记，历史订单仍能关联到该商品
- 准实时维表：分钟级延迟要求下用 CDC 替代每日批量全量比对
- 多源冲突合并：同一实体在两个系统被修改时按变更时间裁决顺序
- 审计留痕：保留变更前后镜像，可回答谁在什么时候改了什么
变更事件处理流程
变更事件处理流程
CDC 事件（含 before/after 镜像与操作类型） # 输入
-> 按自然键聚合，取变更时间最新的一条 # 同批去重，防一次插多版本
-> 计算 hashdiff，与维表当前版本比对 # 无变化则跳过
-> 按 SCD 类型分流：
类型 1：直接覆盖属性列 # 不保留历史，实现最简单
类型 2：关闭旧版本 + 插入新版本 # 保留完整历史
-> 删除事件：转为失效标记或状态列 # 不物理删除维表行
-> 质量校验：当前版本唯一、区间不重叠 # 每批次收尾必跑事件类型与处理
| 事件类型 | 推荐处理 | 说明 |
|---|---|---|
| INSERT | 插入首个版本 | start_date 取业务变更时间 |
| UPDATE | 按 SCD 类型覆盖或插版本 | 先算 hashdiff 判断是否真变化 |
| DELETE | 落失效标记 | 物理删除会使历史事实断链 |
| 乱序到达 | 按变更时间排序后合并 | 直接按到达顺序处理会得到错误终态 |
CDC 事件在并发变更下可能乱序到达，因此合并前必须按变更时间排序并去重。按到达顺序直接覆盖的做法，在流量高峰时段会稳定出错。
CDC 日志解析工具通常能提供事务提交时间与序号，用它做排序比用写入时间更可靠；具体字段名随工具与数据库版本不同，落地前需以官方文档为准。