dbt-core 调研：从 Python 到 Rust，9K+ stars 的 ELT 转换引擎正在自我重写

68次阅读
dbt-core 调研：从 Python 到 Rust，9K+ stars 的 ELT 转换引擎正在自我重写

数据工程师用 SQL 写 select，dbt 把它变成可追溯、可测试、可版本化的 ” 数据模型生产线 ”——而现在 main 分支已经从 Python 切到 Rust，主角是 Apache 2.0 的 dbt-core v2.0 alpha（Fusion 引擎基础）。

写在前面

2016 年 Fishtown Analytics（现 dbt Labs）做 dbt 的时候，目标是让数据分析师像软件工程师一样工作：写 select、用 Jinja 模板、做版本控制、跑测试、生成文档。9 年过去，dbt 已经成为 ELT 时代 ”T” 环节的事实标准——100K+ 社区成员、dbt Cloud 年化数亿美元 ARR、所有云数仓（Snowflake / BigQuery / Databricks / Redshift）官方支持。

但 Python 实现的 dbt Core v1.x 越来越力不从心：大项目 parse 慢到分钟级、Jinja 模板表达力有上限、Python 依赖地狱让 CI 痛苦。

2025 年 5 月 28 日，dbt Labs 在 dbt-labs/dbt-fusion 开源了 dbt Fusion 引擎——一个 用 Rust 完整重写 的 dbt 执行引擎。2026 年 7 月，dbt-core 的 main 分支正式切到 v2.0 alpha，Python 实现被搬到 1.latest 分支继续维护。

这是一次 ” 自上而下 ” 的破旧立新：项目本身没改名、协议没改、YML 格式没改，但底层执行引擎换了语言、换了架构、换了产物格式（JSON → Parquet）。

对于正在选型数据转换工具的团队，这是一个绕不开的节点。

一、它解决什么问题

dbt（Data Build Tool）填补的是 ELT 流程里 “T”（Transform）的空白。在 dbt 之前，”T” 通常意味着 Airflow 调 Python 脚本或一堆手写 SQL 文件——没测试、没血缘、没文档、没法回滚。

一句话卖点：用 SQL select + Jinja + YAML，定义可测试、可版本化、有血缘的数据模型，dbt 帮你把它们编译成下游数仓（DWH）里的表和视图。

基本信息

字段 值
项目名 dbt-core（main 分支已切到 v2.0 alpha）
仓库 dbt-labs/dbt-core
协议 Apache License 2.0
语言 Python（v1.10-） / Rust（v2.0 alpha，main 分支）
commits 10,682（main 分支，包含 v2.0 alpha 工作）
商业实体 dbt Labs（前身 Fishtown Analytics，2016 创立）
商业产品 dbt Cloud（dbt Fusion + 调度 /CI/ 文档托管 / 告警）
社区 100,000+ members（dbt Community Slack）
1.latest 分支 仍在维护 Python v1.x 实现

二、核心能力：dbt 能做什么

dbt-core 不是一个数据库，不是一个 ETL 工具，是一个 数据转换的 ” 框架 + 执行引擎 ”。它跑在已有的数仓之上。

1. 四类核心对象

  • Models（模型）：放在 models/ 目录的 .sql 文件，每个文件一个 select，编译成下游数仓的一张表 / 视图
  • Seeds（种子）：放在 seeds/ 目录的 CSV 小文件，dbt 帮你导入成表（用于查表类维表）
  • Tests（测试）：YAML 里挂 unique / not_null / relationships / 自定义 SQL，dbt 跑完模型后校验
  • Macros（宏）：Jinja 模板的复用片段，dbt 自带 100+ macro 抹平不同数仓的 SQL 方言差异

2. 四种物化方式

每张模型表要选 ” 怎么生成 ”：

物化 行为 适用场景
view 每次跑 create view 轻量、不占存储、查时算
table 每次跑 create table as 慢但简单
incremental 只插新数据（merge / insert + 唯一键） 大表、每日增量
ephemeral 编译成 CTE，不落表 中间复用片段，不占资源

3. 三件工程化武器

  • Ref 函数 + DAG 血缘：{{ref('stg_orders') }} 让 dbt 自动解析依赖，生成 DAG，文档里直接可视化
  • state:modified 增量构建：v1.1+ 支持，CI 上只跑 PR 改过的模型 + 下游
  • dbt docs + manifest.json：dbt docs generate 输出静态站点，含 DAG、列级血缘、所有 model / test / macro 文档

4. 包管理

dbt deps 装 hub.getdbt.com 上的官方 / 社区包，标准做法是写 packages.yml：

packages:
  - package: dbt-labs/dbt_utils
    version: [">=1.0.0", "<2.0.0"]

生态包覆盖：审计（dbt-audit-helper）、日期维度（dbt_date）、SQL 片段（dbt_utils）、方言扩展（dbt-bigquery / dbt-snowflake / dbt-redshift / dbt-databricks / dbt-postgres 等）。

三、v2.0 重头戏：Rust 写的 Fusion 引擎到底变了什么

这是 2025-2026 年 dbt 最值得讲的事。v2.0 alpha 已经在 main 分支上，v1.x 留在 1.latest 分支维护。

1. 性能：parse / compile 快到 ” 你愿意开 watch 模式 ”

v1.x 的 Python 解析在大项目（1000+ model）上常常分钟级。Fusion 引擎 README 原话：”parse and compile times are dramatically improved, especially on the largest dbt projects.” 实际经验反馈：5-30 倍提升——大项目从 ” 跑一次 dbt parse 喝杯咖啡 ” 变成 ” 秒级 ”。

2. 严格性：从 ” 跑通就行 ” 到 ”parse 时就报错 ”

v1.x 对 YAML 配置基本不做校验，写错字段也能跑（只是无效）。Fusion 引擎使用 机器生成的 JSON schema（dbt-schemas crate）严格校验，配错直接报错在 parse 阶段。

3. 产物升级：JSON → Parquet

v2.0 引入 Parquet artifacts（manifest.parquet 等），比 JSON 小一个量级、可以直接 SQL 查询。想做 ” 项目元数据分析 ”（比如 ” 所有 model 的平均行数趋势 ”）的团队，SQL 查 Parquet 就行，不用再解析 JSON。

4. 安装：单二进制，零依赖

v1.x 是 pip install dbt-core dbt-bigquery，要 Python 环境、要解决 adapter 依赖冲突。v2.0 是 单文件二进制，无 Python、无 JVM、随用随下：

curl -fsSL https://public.cdn.getdbt.com/fs/install/install.sh | sh -s -- --update

5. ADBC 驱动（Arrow Database Connector）

v1.x 走各 adapter 自己的数据库驱动（psycopg2 / snowflake-connector-python 等），性能瓶颈在行式协议。Fusion 引擎统一用 Arrow 列式协议 + ADBC，数据传输效率上一个台阶。

6. Language Server + VS Code 扩展

Fusion 引擎自带 LSP（Language Server Protocol）实现，VS Code / Cursor 装扩展后能拿到：

  • model 内跨文件跳转（ref() go-to-definition）
  • 列级补全（知道 stg_orders 有哪些字段）
  • 实时校验（写错 macro 当场红线）

v1.x 也有 dbt Power User 这类第三方扩展，但都是 hack SQL parser；Fusion 是官方一等公民。

7. 平台支持矩阵

OS x86-64 ARM
macOS 🟢 🟢
Linux 🟢 🟢
Windows 🟢 🟡

截至 2026 年 8 月，Windows ARM 还不支持。

四、生态与时间线：Fusion 引擎的发布节奏

dbt-fusion 仓库 2025-05-28 首次公开，2,723 commits，按组件分批开源：

目标日期 里程碑 说明
2025-05-28 首次发布 parser + schemas + dbt-jinja + Snowflake ADBC
2025-06-09 Databricks adapter Databricks ADBC + Fusion adapter
2025-06-30 BigQuery adapter BigQuery ADBC + Fusion adapter
2025-07-31 Redshift adapter Redshift ADBC + Fusion adapter
2025-09-30 OSS adapters Adapter 组件以 Apache 2.0 协议发布
TBD ANTLR grammars SQL 方言语法（Snowflake / Databricks / BigQuery / Redshift）

核心商业逻辑：Fusion 引擎的 ” 代码 ” 和 ” 语言服务 ” 开源，dbt Cloud 的 ” 调度 + CI/CD + 文档托管 + 告警 + 监控 ” 商业化——标准开源核心 + SaaS 变现。

v1.x (Python) 不会突然死：1.latest 分支继续修 bug，dbt Labs 明确 ”v1 is still maintained as dbt Core v1.x”。

五、对比：dbt vs sqlmesh vs Airflow vs Great Expectations

dbt 不在真空里。最常被放在一起比的是：

工具 核心定位 跟 dbt 关系
sqlmesh 同赛道（SQL 转换 + DAG + 测试），新兴竞品（Tobiko Data） 强调 ” 虚拟环境 ” 和 ”plan/apply” 工作流，UI 更现代；生态小
Apache Airflow 通用编排（DAG + task 调度） 不是替代，是 上游：Airflow 调度 dbt run（BashOperator 调 dbt CLI）
Great Expectations 数据质量（expectation suite） 互补：GE 验证数据契约，dbt 转换数据；可同项目配合
dbt-core SQL 转换的事实标准 自身

核心判断：

  • 如果团队已经在用 Snowflake / BigQuery / Databricks / Redshift 做 ELT 的 ”T” 环节，dbt 仍然是最稳的选择——生态最大、招聘最容易、问题答案最多
  • 如果团队想要 ”plan/apply” 工作流（像 Terraform 那样）或者 M1/M2 极致性能，可以看 sqlmesh
  • 如果团队连调度都没有，dbt 解决不了；上 Airflow + dbt 才是完整 ELT

dbt + 100K 社区 + Apache 2.0 + dbt Labs 持续重金投入——短期不会被颠覆。

六、实战：3 步跑通 dbt-core（v1.x Python 版）

走 v1.10 是因为稳定；v2.0 alpha 等 GA 再上生产。

# 1. 建项目 + 装 dbt + adapter（以 BigQuery 为例）pip install dbt-core dbt-bigquery
dbt init my_project
cd my_project

# 2. 配置 profiles.yml（~/.dbt/profiles.yml）my_project:
  target: dev
  outputs:
    dev:
      type: bigquery
      project: my-gcp-project
      dataset: dbt_dev
      keyfile: /path/to/service-account.json

# 3. 写第一个 model + 跑 + 测
echo "SELECT 1 AS id, 'hello' AS msg" > models/hello.sql
dbt run                  # 编译 + 物化
dbt test                 # 跑所有 test
dbt docs generate && dbt docs serve  # 看文档站

跑通后打开 http://localhost:8080，能看到 DAG、血缘、列级血缘、所有 model 文档。

fusion 版 对比：

# 装 VS Code 扩展（推荐）→ 一键装 fusion CLI + language server
# 或者直接装 CLI
curl -fsSL https://public.cdn.getdbt.com/fs/install/install.sh | sh -s -- --update
dbt --version  # 应该看到 dbt-core v2.x

七、风险与坑

  1. v2.0 还是 alpha：main 分支明确写 ”Behavior, APIs, and on-disk formats may change before the stable release.” 生产项目锁定 v1.10，等 v2.0 GA
  2. adapter 锁定：v1.x 的 dbt-bigquery 和 v1.10 绑死，升 v1.x 小版本要同步升 adapter；Fusion 引擎现在只支持 Snowflake / Databricks / BigQuery / Redshift 四家
  3. Python 依赖：v1.x 装 adapter 一堆 native 依赖（ODBC driver / Snowflake connector），CI 容器镜像要小心
  4. YAML 校验宽松 ：v1.x 写错字段不报错，排查时间多花在 ” 为什么我的 config 没生效 ”——Fusion 引擎的 JSON schema 严格校验是 升级 v2 的最大动力之一
  5. 没有调度：dbt 不调度，需要 Airflow / Dagster / Prefect / dbt Cloud 配合
  6. 大项目性能：v1.x 在 1000+ model 上确实慢，Fusion 引擎的 ”5-30 倍 ” 提升很关键
  7. 大表全量重建：误用 materialized='table' 会触发全量重建；大表必须用 incremental + 配合 unique_key

八、总结

3 个最值得装 / 等的理由：

  1. ELT 的 ”T” 环节事实标准：100K+ 社区 + 所有云数仓官方支持 + 招聘市场最大——团队不会选错
  2. Apache 2.0 永久开源：v1.x 和 v2.0 核心都是 Apache 2.0，不会被 ” 商业化卡脖子 ”
  3. Fusion 引擎值得期待：Rust 重写 + ADBC + Parquet artifacts + Language Server + 单二进制——v1.x 的所有痛点都在被解决

一句话建议：

新项目先用 v1.10 跑起来；v2.0 GA 后（看 dbt Labs 公告，预计 2026 年底到 2027 年初）做 POC 验证后切换；不要在 alpha 阶段上生产。

参考

  1. dbt-labs/dbt-core · GitHub — v2.0 alpha main 分支，v1.x 在 1.latest
  2. dbt-labs/dbt-fusion · GitHub — Fusion 引擎源码（Rust，2,723 commits）
  3. The dbt Viewpoint — dbt Labs 的官方方法论
  4. Fusion Engine: Path to GA — v2.0 路线图
  5. What is dbt? — dbt Docs — 入门
  6. SQLMesh 文档 — 同赛道新兴竞品
  7. dbt Community Slack — 100K+ 成员主社区
  8. Apache 2.0 License — 协议全文
正文完
发表至： 技术
2026-08-07
 

近期文章

近期评论