dbt：数据转换

为什么需要 dbt：SQL 脚本失控 → 把转换层工程化

传统数据转换工作的痛点很明确。业务分析团队通常维护着几十到几百条 SQL 脚本，散落在 Navicat、DataGrip、Jupyter 甚至聊天记录里，没有版本控制，更谈不上 Code Review。脚本之间通过物理表名字符串相互引用，一旦上游表改名或字段口径调整，下游报表在凌晨跑数时才会静默报错。另一个痛点是重复劳动：每个项目都要重写“去重、类型转换、枚举映射”这类样板 SQL，且没有任何数据质量保障手段——唯一性假设、非空假设全靠人工抽查。

dbt 将上述流程工程化。你把每条转换逻辑写成一个 .sql 模型文件放进项目，通过 ref() 和 source() 声明模型间依赖，dbt 静态解析后自动生成血缘 DAG，并保证按拓扑序执行。它内置 unique、not_null、accepted_values、relationships 四类开箱即用的数据测试，也支持用 SQL 写自定义测试；dbt docs 自动生成数据字典和血缘图。增量物化（incremental）和大表快照（snapshot）能力让全量重算成为过去式。相对于同类工具，dbt 的气质是“专一且克制”——它只做 T，不做数据抽取，也不做任务调度，这把学习门槛压得很低，分析师一天就能上手，同时与 Airflow 等调度器天然互补。

安装与环境配置：3 步就绪

步骤一：准备 Python 3.8+ 虚拟环境。 dbt Core 是 Python 包，建议在虚拟环境中安装，避免污染系统 Python。

步骤二：安装数据库适配器。 dbt 1.8 起核心与适配器分离安装——你不需要单独装 dbt-core，安装适配器时会自动拉取匹配的核心版本。选择与你数仓对应的适配器即可。

步骤三：配置 profiles.yml 并验证。 dbt 通过 ~/.dbt/profiles.yml 文件读取数据库连接信息，配置好之后用 dbt debug 验证连通性。

# 1) 创建并激活虚拟环境python3 -m venv .venvsource .venv/bin/activate # 2) 安装数据库适配器（Snowflake 用 dbt-snowflake，BigQuery 用 dbt-bigquery）pip install dbt-postgres # 3) 验证安装dbt --version # 4) 编辑 ~/.dbt/profiles.yml，添加目标数据库连接cat >> ~/.dbt/profiles.yml << 'EOF'my_project:  target: dev  outputs:    dev:      type: postgres      host: localhost      port: 5432      user: postgres      password: secret      dbname: analytics      schema: public      threads: 4EOF # 5) 验证数据库连接dbt debug

快速上手：10 分钟跑通官方示例

最快路径是使用 dbt Labs 官方的 jaffle_shop 示例项目——一个模拟电商销售数据的入门项目，包含种子数据、模型、测试和文档。克隆到本地、配置好 profiles.yml 后，按顺序执行四条命令即可看到完整效果。该项目的 dbt build 会依次完成：加载 CSV 种子 → 构建全部模型 → 运行全部测试，一步到位。

1. 克隆仓库：git clone https://github.com/dbt-labs/jaffle_shop.git

2. 进入项目目录，确认 profiles.yml 已按上文配置好目标数据库

3. 运行 dbt debug 验证连接（出现 "All checks passed!" 说明成功）

4. 运行 dbt build，观察控制台输出的模型构建顺序与测试结果

5. 运行 dbt docs generate && dbt docs serve，浏览器打开本地 8080 端口，查看自动生成的血缘 DAG 与数据字典

进阶技巧：在 dbt build --select stg_customers+ 中，+ 运算符表示“包含该模型及其所有下游模型”，只构建受影响的子图，这是日常迭代最常用的选择语法。

git clone https://github.com/dbt-labs/jaffle_shop.gitcd jaffle_shopdbt debug        # 验证数据库连接dbt build        # 一次完成 seed + model + testdbt docs generate && dbt docs serve   # 启动本地文档服务

核心能力详解：5 大支柱

支柱一：模型与依赖管理（ref / source）。 模型是 dbt 的基本单元，一个 .sql 文件就是一个模型。ref('model_name') 引用项目内其他模型，source('schema', 'table') 声明对数据仓库中原始表的依赖。dbt 静态解析这些函数调用，自动构建 DAG 并决定执行顺序，彻底告别手工排序。

支柱二：数据质量测试。 在 models/schema.yml 中声明测试，dbt 会为每条断言生成 SQL 去验证数据。内置测试之外，你还可以用 SQL 编写自定义单一测试（singular tests），或在宏中封装带参数的通用测试。

支柱三：文档与血缘（Lineage）。 dbt docs generate 会解析所有模型、测试和 source，生成包含列级描述和模型间依赖关系的 catalog 文件；dbt docs serve 在本地启动浏览器界面，展示可交互的血缘 DAG，并支持按模型名搜索定位。

支柱四：增量物化与快照。 将模型配置为 materialized='incremental' 并配合 is_incremental() 条件，后续运行只处理新增数据；快照（snapshot）则在表上实现 Type 2 渐变维度，每次源数据变化自动新增一行，并用 dbt_valid_from / dbt_valid_to 记录有效时间范围。

支柱五：宏、包与语义层。 Jinja 模板让 SQL 具备编程能力——写一次宏，全项目复用；packages.yml 可安装 dbt 社区的数千个开源包（如 dbt_utils、dbt_expectations）；dbt 1.6 起引入语义层（Semantic Layer），用声明式方式定义指标，统一指标口径供下游 BI 工具消费。

-- models/staging/stg_customers.sqlSELECT    id AS customer_id,    first_name,    last_nameFROM {{ source('raw', 'customers') }} -- models/marts/dim_customers.sqlSELECT    customer_id,    first_name || ' ' || last_name AS full_nameFROM {{ ref('stg_customers') }}

# models/schema.ymlversion: 2 sources:  - name: raw    schema: raw_data    tables:      - name: customers models:  - name: stg_customers    columns:      - name: customer_id        tests:          - unique          - not_null

生产部署与监控：从上线到运维

方式一：dbt Cloud 托管。 官方 SaaS 方案，免去基础设施维护。在 Cloud 中配置仓库连接后，可创建定时作业（每小时/每天）或在 PR 时触发 CI 作业，CI 中对变更模型运行 dbt build --select state:modified+，只构建受影响的子图。Cloud 自带 Run History、日志检索、失败告警（Slack/Email）和环境变量管理，适合不想自建调度或缺乏运维团队的团队。

方式二：dbt Core + 外部调度器自建。 主流的开源组合是 dbt Core + Airflow/Dagster。你需要在调度器中定义每日任务，通过 bash_command 或对应 Operator 调用 dbt build，并处理依赖失败重试。自建方案的灵活性最高，但需要自己实现 CI/CD、日志留存和告警。

可观测性。 每次运行后，dbt 会生成 target/manifest.json（项目元数据）和 target/run_results.json（运行详情），可解析后写入元数据表实现“模型血缘 + 运行历史 + 测试结果”的可视化看板。生产环境应关注三类指标：模型运行时长与失败率、测试通过率、增量模型的数据量变化。建议在 CI 流水线中对每个 PR 强制运行 dbt test --select state:modified+，把数据质量问题拦截在合并之前。

<p class="para-label">避坑清单：</p>

<ul class="dash-list"><li>把 dbt 当 EL 工具用：dbt 只做 T（转换），抽取和加载要交给 Fivetran/Airbyte 等上游工具或自建同步任务，不要在模型里写爬虫或 API 调用逻辑。</li><li>增量模型不配 is_incremental() 和 unique_key：增量物化要求你显式设计增量策略，否则每次运行都会全量扫描重建，既慢又容易产生重复数据。</li><li>硬编码表名绕过 ref()：直接写 schema.table 会让 dbt 丢失血缘和依赖信息，换环境时必然报错；一切引用都应通过 ref() 或 source()。</li><li>把权限控制寄托在 dbt 上：dbt 是 SQL 转换器，不提供行级权限和字段级脱敏，安全策略必须由数仓（如 Snowflake 的行访问策略、BigQuery 的列级 IAM）实现。</li></ul>

版本迭代

dbt 自 1.0 起采用季度级语义化版本发布，主线是从“纯 SQL 转换工具”演进为“分析工程平台”——1.3 引入 Python 模型打破 SQL 边界，1.5 推出 dbt Mesh 支持多项目协作，1.6 加入语义层统一指标口径，1.8 打通本地 CLI 与云平台，1.9 强化项目元数据浏览。核心 API 在 1.0 后保持稳定，升级成本较低。

AI 应用场景

常见误区

面试题

参考来源

• webpagedbt-core GitHub 仓库源码、Issue 讨论与贡献指南