1. dbt数据建模工程导论

在数据仓库与数据湖仓的建设中，SQL 从来不是稀缺品，稀缺的是可维护、可测试、可追溯、可协作的 SQL 资产。dbt（data build tool）正是为解决这一矛盾而生的工具：它把原本散落在脚本、调度任务和口头约定中的转换逻辑，收敛成一套以 SQL 为核心、以工程规范为约束的建模体系。理解 dbt，关键不在于记住多少命令，而在于理解它把“写 SQL”升级成了“管理数据模型工程”。

dbt 的定位：转换层的工程化工具

dbt 不负责抽取数据，也不负责存储数据，它专注于 ELT 中的 T（Transform）。数据先由 Fivetran、Airbyte、Kafka 或自研同步工具加载到仓库（如 Snowflake、BigQuery、Databricks、PostgreSQL），再由 dbt 在仓库内部完成清洗、关联、聚合与指标构建。dbt 本身不搬运数据，它把模型编译成 CREATE TABLE AS、CREATE VIEW AS、MERGE、INSERT 等语句，交给仓库执行。

因此 dbt 的定位可以概括为三句话：它是面向分析工程师的转换编排器，是数据模型的版本化与依赖管理器，也是数据质量的声明式测试框架。它让数据团队像软件团队一样，用 Git 管理模型、用 CI 验证变更、用文档沉淀口径。

核心价值：从“能跑”到“可信”

dbt 的价值体现在四个层面。第一是依赖管理：通过 ref() 函数声明模型之间的引用关系，dbt 自动构建 DAG（有向无环图），决定执行顺序，避免手工维护调度依赖。第二是可测试性：内置 unique、not_null、accepted_values、relationships 等通用测试，也支持自定义 SQL 测试，把数据质量从“事后发现”前移到“构建时拦截”。第三是可文档化：模型描述、字段说明、血缘关系自动生成文档站点，让口径可查、责任可追。第四是环境隔离：通过 target 区分 dev、test、prod，同一套模型代码在不同环境生成不同 schema 的对象，降低上线风险。

-- models/marts/dim_customer.sql
{{ config(materialized='table') }}

with customers as (
    select customer_id, name, city, created_at
    from {{ ref('stg_customers') }}
),
orders as (
    select customer_id, count(*) as order_cnt, sum(amount) as total_amount
    from {{ ref('stg_orders') }}
    group by customer_id
)
select
    c.customer_id,
    c.name,
    c.city,
    coalesce(o.order_cnt, 0) as order_cnt,
    coalesce(o.total_amount, 0) as total_amount
from customers c
left join orders o on c.customer_id = o.customer_id

这段代码里，ref() 是 dbt 的“连接器”，它既表达依赖，又负责在编译时替换为正确的库表名。config(materialized='table') 决定物化方式。模型文件本身不包含调度时间、不包含连接串，这些由 profiles.yml 和调度器负责，职责边界清晰。

数据建模工程化思维

dbt 带来的不只是工具，更是一种思维方式。传统 SQL 开发常以“任务”为单位：今天写一个报表 SQL，明天改一个口径，脚本越堆越多，血缘靠人脑记忆。工程化思维则要求以“模型”为单位：每个模型有明确粒度、明确主键、明确上游依赖、明确测试断言。模型之间通过分层组织，常见分层为 staging（清洗与标准化）、intermediate（中间逻辑复用）、marts（面向主题的宽表与指标）。

这种分层不是形式主义，它解决的是复用与变更成本问题。当源表字段改名时，只需修改 staging 层；当业务口径调整时，只需修改 marts 层。每一层都有契约：staging 层保持与源表同粒度，marts 层面向分析场景。工程化思维还强调幂等性——同一模型重复执行结果一致；强调可回滚——通过 Git 分支与 CI 验证控制变更；强调可观测——通过测试结果、运行日志和文档站点掌握模型健康度。

课程项目背景与整体学习路径

本课程围绕一个贯穿始终的示例项目展开：某零售电商的订单与客户分析平台。源系统包含订单表 orders、客户表 customers、商品表 products 和支付流水表 payments。项目目标是构建从 staging 到 marts 的完整模型链路，最终产出客户维度表 dim_customer、订单事实表 fct_orders 以及日销售汇总表 mart_daily_sales，并配套测试、文档与增量策略。

学习路径按能力递进组织。基础篇先建立 dbt 项目骨架，理解 dbt_project.yml、profiles.yml、模型文件与 dbt run、dbt test、dbt docs generate 的基本用法。建模篇深入分层规范、维度建模与事实表设计，讨论粒度选择、代理键与自然键、缓慢变化维的处理方式。质量篇聚焦测试策略、文档编写与数据质量监控，把断言嵌入到日常构建流程。进阶篇覆盖增量模型、Jinja 宏、包管理与 CI/CD 部署。最后以完整项目实战收束，把各篇能力串成一条可交付的工程链路。

需要强调的是，dbt 不是银弹。它不解决源数据质量问题，不替代调度系统，也不自动生成业务口径。它提供的是一套工程约束和协作契约，真正决定数据资产质量的，仍然是建模者对业务粒度的理解、对分层边界的判断以及对测试覆盖的取舍。本课程的目标，正是帮助你把这种判断力转化为可复用的工程实践。