dbt中schema tests的价值是什么？与SQL schema约束适用场景有何区别？

四类dbt schema测试对应的可替代原生SQL约束如下：

• unique：对应SQL UNIQUE 约束
• not_null：对应SQL NOT NULL 约束
• accepted_values：对应关联查找表的SQL FOREIGN KEY 约束
• relationships：对应关联其他业务表的SQL FOREIGN KEY 约束

即便数据库支持上述原生约束，以下场景优先选择dbt schema测试更合适：

• 增量模型的阶段性校验场景：增量加载的表在中间处理环节可能暂时存在重复、空值等不符合约束的内容，后续步骤会完成数据修正。原生SQL约束会直接阻断数据写入，导致流程中断；dbt测试可以配置在全量数据处理完成后执行，不阻断中间流程，还能输出异常明细方便定位问题。
• 非强制阻断的软校验场景：部分非核心业务字段允许少量不符合预期的值存在，不会影响核心下游业务运行。原生约束会直接拒绝所有不符合规则的行写入，dbt测试可以仅输出告警，你可以选择先推进下游流程，后续再修复数据异常，灵活度更高。
• 跨库/跨实例的关联校验场景：原生外键、唯一等约束仅支持同一数据库实例、同一schema下的表校验，如果你需要校验的关联表分散在不同库、甚至不同的数仓产品中，原生约束完全无法实现，dbt的relationships类测试可以跨数据源拉取数据完成校验。
• 需要自定义容错阈值的场景：原生约束是100%严格的，不允许任何不符合规则的数据存在，而业务上往往允许非核心字段存在小比例的异常值（比如允许0.1%的空值存在），dbt测试可以通过warn_if/fail_if参数自定义校验阈值，适配业务的容忍度。
• 全链路规则统一管理场景：如果你的整个数仓构建流程都基于dbt调度，将校验规则和模型定义放在同一个yml文件中，和模型代码一起做版本管理，不需要单独登录数据库修改约束配置，规则迭代、历史版本回溯都更方便，也可以实现开发、测试、生产多环境的规则统一复用。
• 适配无生效原生约束的OLAP引擎场景：部分面向分析的数仓引擎（如部分版本的ClickHouse、BigQuery）的外键等约束仅为逻辑注释，不会实际生效，这种情况下使用dbt schema测试才能真正落地数据校验逻辑。

内容的提问来源于stack exchange，提问作者A Poor