第 10 部分. dbt 的 Staging 模型
Staging 将原始事实转化为稳定的技术模型。这里不是复杂业务逻辑的位置,而是为清晰的类型、命名、主键和最小规范化提供场所。良好的 staging 使下游 SQL 变得平淡且可预测。
staging 中允许的内容
- 将字段名调整为项目约定；
- 转换类型（
date、integer、decimal）； - 显式处理空值和
null的语义； - 保留源键；
- 标记 PII 字段,但若无理由不隐藏它们。
示例：
try_cast(nullif(cast(revoked_at as varchar), '') as date) as revoked_at这一行本身并不解决产品问题。它在技术上将空值转化为 null,而"revoked_at 为 null = 同意有效"的含义应在规范和 mart 中体现。
staging 中禁止的内容
- 对客户进行聚合；
- 计算风险评分；
- 选择最终的事实表 grain；
- 为了"美观"删除行；
- 隐藏契约漂移。
如果 staging 开始回答消费者的问题,这一层就变得过于智能了。
dbt 测试
最低要求：
- 对源键使用
not_null和unique； - 对必需的金额和日期使用
not_null； - 在域较小时使用
accepted_values； - 对复杂约束使用 singular 测试。
staging 中的测试应捕捉源的技术问题,但不能取代数据产品的验证。
给读者的解读
Staging 是数据开始使用平台语言的第一层。这里出现稳定的列名、明确的类型、清晰的空值处理和基础键。但 staging 不应成为小型业务事实表。它的任务是使源数据适用于后续工作,而不去承担属于产品规范的决策。
良好的 staging 模型是平淡的：选择字段、转换类型、显式处理空值和 null、保留合成标识符、不更改 grain。这里的平淡是有益的。如果 staging 中出现复杂的聚合、"仅活跃"过滤器、风险分类或业务指标计算,评审者应当质疑为何在模型规范之前就已做出该决策。
空值处理是一个很好的教学示例。空的 revoked_at 可能导致类型转换失败。可以快速将其替换为 null 并遗忘。但 SDD 方法要求更多：记录空值出现在 raw 中的事实；解释为何在 staging 中它变为 null；验证 mart 一致地计算活跃和已撤销的同意。如此,技术修正就转变为有文档记录的决策。
Staging 同时也为智能体设定了 SQL 风格。模型应小巧、自上而下阅读,并在合适处使用 ref()/source()。如果 staging 难以阅读,下游模型将更糟。如果 staging 清晰,评审者可快速将技术规范化与产品含义区分开来。
实践
选择一个 staging 模型,为每个转换打上标签：重命名、类型转换、null 处理或业务逻辑。如果发现业务逻辑,请检查是否存在其规范。
Qwen 查询
阅读 Schema Manifest 和 raw 源。
创建或检查 staging 模型。
不要添加业务聚合。对每个类型转换,解释其所基于的源事实。最低产出
完成本章后：
- 主要源存在 staging 模型；
- 键由 dbt 测试覆盖；
- 关于空值和
null的决策已记录； - PII 仅在演示策略所需的位置保持可见。
典型错误
将业务逻辑隐藏在 staging 中。例如,case when amount_rub > 100000 then 1 else 0 end as risk_event 仅在规则已记录于规范或源清单中时才可接受。否则智能体就会自行编造风险策略。
检查问题
- staging 可以在未经批准的情况下做出哪些决策？
- 为何 PII 有时保留在 staging 中？
- staging 测试与 mart 验证事实有何区别？