SCD Type 2表源端删除记录的最优处理方案咨询

结论 #

数据仓库领域主流最佳实践优先选择方案2的处理逻辑，该方案完全符合SCD Type 2保留全量历史变化的设计初衷，兼顾查询便捷性和异常场景兼容性。

三个方案的优劣对比 #

方案1：直接更新现有开放行的删除标识 #

该方案本质是在SCD Type 2表上执行SCD Type 1的原地更新，完全破坏了历史轨迹的完整性：

• 无法区分「2021-10-02至2021-10-03记录正常有效」和「2021-10-03之后记录被删除」两个状态
• 所有历史快照查询都需要额外叠加删除标识的时间判断逻辑，出错概率极高
• 属于不符合SCD Type 2设计规范的错误用法，不推荐使用

方案3：直接闭合开放行不留当前版本 #

该方案属于轻量简化处理，仅适用非常窄的特定场景：源端删除是极低概率事件、业务不需要区分「记录从未存在」和「记录曾存在后被删除」两种状态、也不需要追溯删除发生的时间。
它的通用场景缺陷非常明显：

• 违反SCD Type 2「每个业务键对应一条开放状态当前版本」的通用约定，当前有效数据查询需要额外排除无开放行的业务键，逻辑复杂度高
• 误删恢复时会产生无意义的版本断层，无法直观体现删除恢复的过程，容易被统计逻辑判定为全新记录

方案2：将删除作为属性变化新增版本 #

该方案完全遵循SCD Type 2的标准处理流程，把「源端是否删除」作为记录的普通属性处理，属性变化就闭合旧版本、新增新版本，优势非常突出：

• 全量历史轨迹100%完整，任意时间点的快照查询可以直接用标准SCD Type 2语法：WHERE 快照日期 >= START_DT AND 快照日期 < END_DT，不需要额外叠加删除标识判断，查询逻辑统一、出错率极低
• 误删恢复处理逻辑简单，仅需要检测到当前开放行的删除标识和源端状态不一致，就闭合当前版本、新增恢复后的新版本即可
• 你提到的重复行问题不属于设计缺陷：SCD Type 2本身允许不同版本的非日期属性重复，只要时间线连续无重叠就是完全合规的。如果业务确实不需要保留删除的历史轨迹，也可以选择小范围优化：恢复时直接将删除版本的END_DT改为恢复日期，重新开放之前的有效版本即可，不过会小幅提升ETL逻辑复杂度。

内容的提问来源于stack exchange，提问作者Ankit Srivastava