1. 课程导入与协同工程全景

在传统数据仓库时代，数据团队常常陷入一种割裂的工作模式：数据工程师用 SQL 脚本或存储过程在数仓里建表、写调度，分析师则拿着另一套 SQL 在 BI 工具里重复计算指标。同一份业务口径，在 ETL 脚本、报表 SQL、指标文档里各写一遍，改一处就要追着改三处。dbt（data build tool）与云数仓的协同工程，正是为了解决这种"逻辑散落、口径漂移、变更失控"的问题而出现的。

要理解这套协同模式，先要看清 dbt 与云数仓各自扮演的角色。云数仓（如 Snowflake、BigQuery、Redshift、Databricks SQL Warehouse）提供的是算力与存储底座：它负责执行 SQL、管理数据文件、处理并发与权限。dbt 则是一个转换层的工程化框架：它不搬运数据、不存储数据，而是把"如何从原始表加工出目标表"这件事，用可版本控制、可测试、可文档化的方式管理起来。dbt 把每条转换逻辑编译成一条 CREATE TABLE AS 或 INSERT OVERWRITE 语句，交给云数仓执行。换句话说，云数仓是发动机，dbt 是变速箱和仪表盘——发动机提供动力，变速箱决定动力如何有序传递到车轮。

这种协同带来的核心价值，可以归纳为三条主线。第一条是逻辑集中：所有转换逻辑以模型文件形式存放在 Git 仓库中，一个指标只定义一次，下游模型通过 ref() 函数引用上游，形成可追溯的依赖关系。第二条是质量内建：dbt 允许在模型上声明测试（唯一性、非空、外键关系、枚举值范围），每次运行自动校验，把数据质量问题拦截在发布之前。第三条是变更可控：借助依赖图，dbt 能识别某个模型改动后受影响的下游范围，配合 dbt build --select state:modified+ 只重建必要部分，避免全量重跑。

下面这张图展示了 dbt 与云数仓协同工程的典型架构与数据流向。左侧是数据源，中间是 dbt 管理的转换层（分层建模），右侧是消费端，底部是贯穿全程的元数据与测试反馈回路。

理解了架构，接下来要明确学习路径。本课程围绕"能建、能测、能调、能优"四个能力层次展开，共 30 章。前段打基础：环境搭建、项目结构、模型分层、ref() 与 source() 的使用；中段进入工程化：测试、文档、增量模型、快照、宏与包管理；后段聚焦协同与性能：CI/CD 集成、调度编排、物化策略选择、查询优化与成本控制。每一章都配有可运行的示例，最终汇聚为一个完整的实战项目。

实战项目设定为"电商订单分析平台"。数据源包括订单表、订单明细表、用户表、商品表和支付流水表，模拟每日增量到达云数仓的原始层。项目要求交付：一套分层清晰的 dbt 模型（staging → intermediate → marts），覆盖订单宽表、用户维度、商品维度、每日销售汇总四类核心产出；一套数据质量测试，至少包含主键唯一性、金额非负、订单与明细的引用完整性；一份自动生成的文档与血缘图；以及一条可被调度器触发的运行命令。示例参数设定为：原始层每日新增订单约 5 万行，明细约 15 万行，目标 marts 层订单宽表保留最近 24 个月分区。