管道基础52 条

dbt 转换模型基础

dbt 用 SQL + 配置管理数仓内转换:模型之间用 ref() 表达依赖,dbt 负责编译、按依赖顺序执行、跑测试与生成文档;调度仍交给外部调度器。

dbt 是什么

dbt 用「SQL 加配置」的方式管理数仓内的转换:models 目录下每个 .sql 文件就是一个模型,文件里写一条 SELECT,其余交给 dbt。模型之间用 ref() 引用上游,dbt 据此自动推导依赖图并按顺序执行,还能顺带跑数据测试、生成文档。它解决的是「一堆 SQL 脚本谁先跑、谁依赖谁」的问题,但不负责调度和告警——生产上仍由外部调度器调用 dbt 命令。

基本信息

模型models/ 下每个 .sql 文件是一个模型,SELECT 即定义
依赖表达{{ ref('upstream_model') }} 自动推导 DAG
常用命令dbt run / dbt test / dbt build / dbt docs generate
物化方式view、table、incremental、ephemeral
跨源引用用 source() 声明原始表,用 ref() 引用模型
调度由 Airflow、DolphinScheduler 等外部调度器触发

增量模型示例

增量模型示例
{{ config(materialized='incremental', unique_key='order_id') }}
SELECT order_id, amount, updated_at
FROM {{ ref('ods_orders') }}
{% if is_incremental() %}
WHERE updated_at > (SELECT max(updated_at) FROM {{ this }})
{% endif %}

执行与测试

执行与测试
dbt run --select dwd_orders+      # 该模型及其下游
dbt test --select dwd_orders
dbt build --select +ads_sales_daily   # 上游 + 自身(含测试)
dbt docs generate && dbt docs serve

典型使用场景

  • 分层建表:ODS 到 DWD 到 ADS 每层若干模型,依赖由 ref 自动串起
  • 增量更新:按 unique_key 合并,避免每天整表重算
  • 质量卡口:为模型配置唯一性、非空、取值范围测试,跑完即校验
  • 文档沉淀:从模型描述与注释生成数据字典,减少口头约定
  • 回归比对:改动模型后按选择器只跑受影响分支,快速验证
  • 按标签分组调度:把夜间全量、白天增量用 tag 区分,各自触发
  • 源表契约:用 source() 声明上游表并加新鲜度校验,上游延迟时提前失败

选择器读法

写法含义用途
dwd_orders单个模型只跑指定模型
dwd_orders+自身及所有下游改口径后重刷下游
+dwd_orders自身及所有上游首次构建依赖链
+dwd_orders+上下游全部全链路重建
tag:nightly按标签选择分组调度
dbt 管转换质量,不含调度与告警;生产上通常由 Airflow/DolphinScheduler 调用 dbt 命令并串联上下游。
增量模型的关键在过滤条件与 unique_key 的组合:过滤越宽重复处理越多,unique_key 选错则同一条业务记录会被写成多行。
dbt 的选择器让补数变得可控:改动一个模型后可以用 + 或 + 前后缀精确指定重跑的上下游范围,不必整仓重建。

易错点

  • is_incremental() 在首次全量时不生效,逻辑要能同时适配首跑与增量
  • 模型依赖跨库引用要用 source()/ref() 声明,直接写物理库名会绕过依赖图
  • 增量模型的过滤条件依赖上游字段更新,上游不更新该字段时会漏数
  • 把 dbt 当调度器用,缺少失败重试与依赖告警
  • 所有模型都声明成 table 物化,每天整表重算把资源吃满

数据来源与参考

  • dbt 官方文档:Models、Incremental Models、ref 函数
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌