第1章：认识 dbt——从手工 SQL 到建模工程
第 1 章 · 认识 dbt：从手工 SQL 到建模工程
章节摘要：本章解决一个入门期最常见的困惑——dbt 到底是个什么东西，它和「写 SQL 建视图」「调度系统跑脚本」这些老办法比，究竟多了什么、少了什么。我们先把 dbt 的定义和适用边界说清楚，再拆开看它的三块组成：本地运行的核心、对接各种数仓的适配器、以及托管的协作平台；最后用一张对比表把手工 SQL、视图分层与 dbt 三种做法摆在一起量。读完本章，你应当能判断自己的团队适不适合引入 dbt，以及引入后它替你管什么、不替你管什么。
学习目标
阅读完本章，你应当能够：
- 用一两句话向没有接触过 dbt 的同事讲清它的定位，并说出它管什么、不管什么；
- 说出 dbt Core、适配器、dbt Cloud 三者各自的职责边界，以及一个命令从敲下到落库中间经过哪几步；
- 判断某个具体需求（例如实时同步、存储过程迁移、指标口径统一）是否属于 dbt 的能力范围；
- 对照手工 SQL、视图分层、dbt 三种方案，从依赖管理、测试、文档、复用四个维度给出选型理由；
- 在本地把 dbt 装起来并跑通第一条命令，为第二章的机制学习准备好环境。
本章知识点清单
- dbt 的定位：仓库内的转换层工具，ELT 中的那个 T；
- 项目（project）与模型（model）两个核心名词的含义；
- Core、适配器、Cloud 的三层结构与适配器模式的意义；
- 编译期依赖解析与运行期执行的两阶段划分；
- 手工 SQL 方案在依赖、测试、文档上的三个结构性缺陷；
- 选型判断：什么场景该用 dbt，什么场景不该。
核心概念速览
下面这张全景图把 dbt 在整条数据链路里的位置画了出来：上游的抽取加载工具把数据搬进仓库的贴源区，dbt 接手贴源区之后的所有转换，把干净、成体系的表交给下游的 BI 与应用。dbt 自己不搬数据、不存数据，它只做一件事——把你写的 SQL 按正确的顺序、以正确的方式跑进仓库。
一句话锚点：dbt 不搬运数据，它管的是「数据进来之后、出去之前」的那段转换逻辑——把 SQL 从脚本变成工程。
子章节导航
1.1 dbt 是什么：定义、价值与边界 —— 给出准确定义，讲清它凭什么把散落的 SQL 变成可管理的工程资产，也把它的能力边界划出来：不做抽取加载、不做实时流、不替你设计业务口径。
1.2 核心架构：Core、适配器与 Cloud —— 拆开 dbt 的机体看三个部件：Core 负责编译与执行，适配器负责把一套统一的操作翻译成各家数仓的方言，Cloud 把协作、调度、文档托管起来。理解这一节，后面遇到「为什么换个仓库语法不一样」「这条命令到底干了什么」就不会慌。
1.3 手工 SQL、视图分层与 dbt 的方案对比 —— 把三种常见的转换组织方式放在同一张桌子上比较：依赖靠人记还是靠工具算、口径改错了能不能被自动拦住、新人接手要翻多少文档。对比的结论会解释为什么近年大量团队选择迁移。
子章节之间的逻辑关系
三节的推进关系是一条「从整体到局部再到对照」的线：先建立整体认知（1.1），再拆解内部结构（1.2），最后拿老方案当参照系，把 dbt 的价值落到实处（1.3）。
1.1 是什么（定位与边界） | v 1.2 由什么组成（Core + 适配器 + Cloud） | v 1.3 和老方案比好在哪（依赖 / 测试 / 文档 / 复用 四维对比）
进入本章前的两个常见疑问
「dbt 会不会很快被别的工具取代，现在学值得吗」——这个问题值得正面回答。dbt 的核心贡献不是某个界面或某个命令，而是「转换逻辑即代码」这套范式：依赖声明、分层规范、测试即验收、文档随代码。这套范式是行业共识的沉淀，工具形态会变，范式本身的生命周期远长于任何单一产品。学的重心放在范式上，具体命令的兴衰对你影响有限。
「我是分析师，不是工程师，学这个有用吗」——恰恰是分析师受益最大。dbt 的工作语言是 SQL，这正是分析师的母语；它把分析师从「提需求、等排期」的管道里解放出来，自己就能把加工逻辑做成有测试、有文档的正式资产。第五章之前的所有内容，一个熟 SQL 的分析师完全可以独立消化。
前置知识与后续延伸
前置知识只需要两样：能读懂基础的 SELECT、JOIN、GROUP BY 语句；知道数据仓库和业务数据库大致的分工差别。不需要任何编程语言基础，dbt 的主体工作语言就是 SQL。
往后续接的是第二章：既然 dbt 的本事是「把 SQL 组织起来」，那它内部是怎么把一段带模板的 SQL 编译、排依赖、再执行的？第二章钻进机器房看这套机制，物化策略与增量快照也在那一章展开。如果你急着动手，可以先跳到第三章的分层规范部分，但建议至少先读完 1.2 节——不懂编译与执行的边界，后面调物化参数时会知其然不知其所以然。