dbt-core中快照功能hard_deletes与check策略的兼容性问题分析

问题背景

在数据仓库建设中，dbt-core的快照(snapshot)功能是一个非常重要的特性，它允许我们跟踪数据随时间的变化情况。在dbt-core 1.9版本中，引入了一个新特性：当配置hard_deletes='new_record'时，可以捕获被物理移除的记录。然而，当这个配置与strategy='check'一起使用时，出现了功能异常。

问题现象

具体表现为：当使用strategy='check'和hard_deletes='new_record'配置时：

1. 首次运行快照会正确复制监控表中的所有记录
2. 当监控表中的记录被移除后再次运行快照，会正确创建被移除记录的新条目(标记为dbt_is_deleted='True')
3. 但当这些被移除的记录又被恢复时，快照表不会重新插入恢复后的记录

技术分析

快照策略的工作原理

dbt-core提供了两种主要的快照策略：

1. 时间戳策略(timestamp)：基于记录的最后更新时间来判断变化
2. 检查策略(check)：基于指定列的数值变化来判断记录是否发生变化

hard_deletes='new_record'的设计初衷是当记录被物理移除时，在快照表中保留一条标记为移除的记录，而不是完全删除它。

问题根源

通过分析源代码和用户反馈，可以确定问题主要出现在使用check策略时：

1. 快照逻辑没有正确处理记录从"已移除"状态恢复的情况
2. 当记录被恢复时，系统没有创建新的快照条目
3. 已标记为移除的记录保持dbt_is_deleted='True'状态，即使源记录已恢复

影响范围

这个问题会影响所有使用以下配置组合的用户：

• strategy='check'
• hard_deletes='new_record'

解决方案建议

根据社区讨论，一个可行的修复方案是修改生成临时表的SQL逻辑，在检测移除记录时增加对dbt_is_deleted状态的检查：

where 
    source_data.dbt_unique_key is null
    and coalesce(snapshotted_data.dbt_is_deleted, 'False') = 'False'

这个修改可以：

1. 防止为已经标记为移除的记录重复创建移除条目
2. 允许系统正确处理记录恢复的情况
3. 保持向后兼容性(使用COALESCE处理可能为NULL的情况)

最佳实践建议

在问题修复前，建议用户：

1. 如果需要跟踪记录移除和恢复，暂时使用strategy='timestamp'
2. 如果必须使用check策略，可以考虑自定义快照逻辑
3. 定期检查快照表中的dbt_is_deleted标记，确保数据一致性

总结

dbt-core的快照功能是一个强大的数据历史跟踪工具，但在特定配置组合下存在功能缺陷。理解这些限制有助于我们更好地设计数据管道，并在问题修复后及时升级。对于依赖记录移除和恢复跟踪的场景，建议密切关注此问题的修复进展。