第2章：核心机制——编译、DAG 与物化
第 2 章 · 核心机制：编译、DAG 与物化
章节摘要：本章钻进 dbt 的机器房，回答三个环环相扣的问题：一段带模板语法的 SQL 是如何被编译成纯 SQL 的；几十上百个模型之间的执行顺序是怎么算出来的；同一个模型的逻辑为什么可以落成视图、表、增量表三种完全不同的物理形态。最后用增量模型与快照这对「双子机制」收尾——一个管「新数据怎么进来」，一个管「旧状态怎么留底」。这一章是全册的技术地基，后面所有工程化话题都建立在它的概念之上。
学习目标
阅读完本章，你应当能够：
- 手工推演一段含 ref 引用与简单 Jinja 语法的 SQL 的编译结果，说出编译期与执行期各自的职责；
- 给定一张模型依赖图，指出 dbt 的拓扑排序会产生哪几个执行批次、哪些模型可以并行；
- 为一个具体模型选择物化策略，并说出选择依据（查询频率、数据量、构建成本、延迟要求四要素）；
- 写出一个带唯一键与增量条件的增量模型，并解释它比全量重建省在哪里、风险在哪里；
- 判断一个「追踪状态变化」的需求应该用增量模型还是快照，说出两者的本质区别。
本章知识点清单
- ref 与 source 两个引用函数的语义差异：模型间引用与对原始表的引用；
- Jinja 编译的三个阶段与目标 SQL 的生成过程；
- DAG 的构建规则：有向、无环、拓扑排序、同层并行；
- 五种物化形态：视图、表、增量、临时、实体化视图各自的物理含义；
- 增量模型的 unique_key 与增量条件判定；
- 快照的变更捕获方式：时间戳法与比对法的适用场景；
- 「延迟换成本」这条物化选型的主线权衡。
核心概念速览
本章三个主题构成一条「从代码到数据」的流水线：编译把人写的模板 SQL 变成机器能跑的纯 SQL；DAG 把所有模型的依赖关系变成一张可排序、可并行的执行计划；物化决定每个模型在仓库里以什么物理形态存在。三者依次接力，缺一环构建就不成立。
一句话锚点：编译解决「SQL 从哪来」，DAG 解决「先跑谁后跑谁」，物化解决「数据以什么形态住进仓库」——一章讲完 dbt 的全部核心机制。
本章的三个易混概念先扫清
动手前把三组常被混淆的概念区分开，本章的理解成本会降一半：
- 编译与执行的区分：编译发生在你的机器上（文本到文本），执行发生在仓库里（SQL 到数据）。报错信息里凡是「找不到模型」「循环依赖」都属于编译期，凡是「语法错误」「超时」都属于执行期——先分阶段再排查，效率翻倍。
- 依赖与顺序的区分：依赖是模型间的引用关系（静态、声明式），顺序是某次构建里的执行安排（动态、计算所得）。你声明的是依赖，工具算出的是顺序——想改顺序，别去碰调度，去改依赖。
- 物化与增量的区分：物化是「以什么形态存在」（视图、表），增量是「每次构建算多少」（全量、只算新增）。增量是表物化的一种优化形态，不是一个独立于物化的概念。
子章节导航
2.1 编译与执行引擎：从 Jinja 到 DAG —— 拆解编译的完整过程：模板语法如何被渲染、引用如何被替换成真实表名、依赖图如何在编译期成形。读完这节，「dbt 到底帮我做了什么」就不再是黑盒。
2.2 物化策略：五种物化的取舍 —— 同一段模型逻辑，可以落成视图（每次现算）、表（整表重写）、增量表（只算新增）、临时结构（不落库）等多种形态。这节给出五种物化的机理对比和一个四要素选型法。
2.3 增量模型与快照：状态保留的两条路径 —— 增量模型解决「数据太多不能每次全算」，快照解决「上游改了历史我还想知道原来长什么样」。两者经常被混为一谈，这节用一对实验把它们的行为差异钉死。
子章节之间的逻辑关系
三节是「编译 → 排序 → 落地」的工序顺序，前一节的输出是后一节的输入：编译产出纯 SQL 与依赖图，依赖图喂给执行计划，执行计划决定每个模型用什么物化方式写进仓库。
2.1 编译引擎 2.2 物化策略 2.3 增量与快照 模板SQL + 引用 --> 每个模型选形态 --> 两种高级形态深钻 | | | v v v 纯SQL + DAG 视图/表/增量/临时 省算力/留历史
前置知识与后续延伸
前置知识：第一章的定位与架构常识（尤其 1.2 节那条「一条命令的旅程」）；SQL 的基础读写能力。本章会用到少量 Jinja 模板语法，但只用到引用与条件两种，现场即学即会。
往后的延伸：第三章把本章的机制用到真实项目里——分层规范是物化策略的组织化应用，测试体系挂在 DAG 的每个节点上；第四章的性能调优本质上是本章物化选择的精细化。如果时间只够精读一章，就是本章。