dbt Transformation Patterns & Testing

dbt 项目常见的工程债

数据团队引入 dbt 后，典型痛点包括：模型层次模糊导致复用困难、质量检查散落代码中、增量表策略混乱、文档与代码脱节。随着模型量增长，这些问题会放大成维护成本——新人需要花数小时理清依赖关系，生产事故常源于未被捕获的孤儿表或异常空值。

分层与测试的落地范式

该技能通过以下模式解决上述问题：

• 分层治理：采用 medallion 架构，用 stg_/int_/dim+fct_ 前缀明确模型定位（如 stg_stripe__payments 对应原始清洗层）
• 测试内嵌：在模型层直接编写 not_null、unique、relationships 等测试，形成质量护栏
• 文档自动化：通过 model 和 column 描述字段语义，配合 lineage 生成可视化血缘图
• 增量优化：针对 >1M 行的大表提供增量策略，避免全表扫描性能损耗
• 变量控制：用 {{ var('start_date') }} 替代硬编码时间，支持环境切换

适用边界与安全底线

该技能明确不涉及：自动安装依赖、生产环境部署、外部系统写入操作。使用时应遵循：

1. 禁止跳过 staging 层直接构建 mart（如 raw → dim_customers）
2. 测试仅运行在 dev target，避免污染生产数据
3. 重复逻辑（如时间窗口计算）必须抽象为宏
4. 监控 source freshness 而非仅关注模型运行状态

涉及支付、删除、部署等外部操作时，技能会先展示目标与影响范围，并等待用户显式确认。