dbt 是什么？数仓开发为什么越来越多人用它？
面试怎么回答
dbt 只负责 ELT 里的转换，计算交给数仓引擎。每个模型就是一个 SELECT，DDL 和 DML 由它生成；模型之间用 ref 引用，dbt 自动推出 DAG 按顺序执行，不用手工配依赖；物化方式可以选视图、表、增量；在 YAML 里声明 unique、not_null、relationships 等测试，每次跑完自动校验；用 Jinja 宏复用公共逻辑，还能自动生成文档和血缘。它让 SQL 开发进了 Git，有代码评审、CI 和多环境，数仓开发工程化。局限是不管调度和采集，要配合 Airflow 之类的调度器，复杂的非 SQL 处理也不擅长。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
在国外，dbt 几乎是数仓开发的标配；国内用 Doris、StarRocks、Spark SQL 的团队也越来越多地在用。面试官问 dbt，其实是在问：你们的 SQL 开发有没有工程化？
没有 dbt 时的数仓开发
- 几百个 SQL 脚本散落在调度平台里，表之间的依赖靠人手工配，漏配了就出现下游先跑、读到旧数据；
- 同一段清洗逻辑在十几个脚本里复制粘贴，改口径要改十几处；
- 数据测试基本没有，主键重复、关联键为空，往往是业务发现报表不对才知道；
- 文档和血缘靠人维护，很快就过时。
dbt 怎么做
dbt（data build tool）只负责 ELT 里的 T（转换），计算还是交给数仓引擎：
- 每个模型就是一个 SELECT：你只写「这张表的数据怎么来」，建表、插入、覆盖的 DDL/DML 由 dbt 生成；
- 用
ref()引用上游模型：select ... from {{ ref('dwd_order') }}，dbt 据此自动推出依赖关系图（DAG），按顺序执行，再也不用手配依赖； - 物化方式可配置：view、table、incremental（增量，只处理新数据）、ephemeral（不落表，内联到下游）；
- 内置数据测试：在 YAML 里声明
unique、not_null、relationships、accepted_values，每次跑完自动校验，也能写自定义测试； - 宏和复用：用 Jinja 宏封装公共逻辑，比如统一的日期处理、脱敏函数；
- 文档和血缘自动生成：根据模型和描述生成文档站点，带完整的表级血缘。
为什么越来越多人用
- SQL 进了 Git：代码评审、版本管理、CI 流程都能套上，数仓开发变得像软件开发；
- 多环境：开发、测试、生产用不同的 target，开发时只在自己的 schema 里跑，不影响线上；
- 门槛低：会 SQL 就能上手，分析师也能参与建模。
局限
- 它只做转换，不负责调度（要配 Airflow、DolphinScheduler 等触发）、不负责数据采集；
- 复杂的非 SQL 处理（机器学习、复杂的 Python 逻辑）不是它的强项；
- 模型多了以后，增量模型的设计、全量重跑的成本要认真管理。