dbt v2 交卷，"要不要 dbt"该有答案了

一个工具重写了自己，另一个工具被反复追问"你是不是多余的"——这两件事同时发生，恰恰说明数据转换层走到了必须想清楚的十字路口。

dbt v2 落地：适配器打包进核心、解析速度提升、文档体验不再依赖那个巨大的 manifest.json。而另一边，"既然有了 Dagster，为什么还要用 dbt？"这个问题常年挂在相关话题 Google 搜索结果的第二位——排在上面的不是什么官方文档，而是一个 Reddit 帖子。搜索引擎用排名告诉你：这个困惑是真实的、普遍的、值得认真回答的。

我的判断是：这两个信号指向同一件事——SQL 转换层和编排层的边界正在重新划定，而 dbt v2 就是这次划定中最重要的一笔。

📌 一个 Reddit 提问，戳中行业的隐痛

先说那个著名的场景。任何在数据团队待过的人，大概率都经历过这样的会议：老板看着账单问，我们既有 Dagster 又有 dbt，这两个东西都画血缘图、都按计划跑、都能跑测试——是不是花了双份钱？

这个问题在 Reddit 上被反复讨论，以至于成了该话题的 Google 第二大搜索结果。这不是新手的无知，而是一个结构性困惑：两个工具在"中间地带"确实重叠了，而重叠之处正是困惑的栖息地。

但答案是：他们并没有付双份钱——"quite"。dbt 是一个 SQL 转换框架，Dagster 是一个编排器。前者管"数据怎么变"，后者管"活儿什么时候跑、跑失败了怎么办"。两者职能边界清晰，只是各自的产出物——血缘图、测试结果——长得太像了，让不了解内情的观察者产生了"功能重复"的错觉。

产业逻辑层面，这个困惑本身就是一个信号：声明式建模、血缘可视化、内置数据测试，已经成了现代数据工具的"标配三件套"。任何新工具都自带这三样，于是任何两个工具放在一起看，都像是竞品。真正的区分维度从来不是"有没有血缘图"，而是"血缘图覆盖的范围有多大、服务的是哪一层抽象"。

⚙️ 先把话说明白：两者到底各干什么

金句先行：dbt 决定数据长什么样，Dagster 决定这一切什么时候发生。

拆开看。dbt 的工作对象是一个装满 SELECT 语句（带 Jinja 模板）的文件夹。它根据 ref() 调用自动推断模型的执行顺序，把 SQL 编译成目标数仓的方言，把它们物化为表或视图，然后对结果跑测试——not_null、unique、自定义 SQL 断言。注意最后一点：dbt 不会调度自己。总得有什么东西去调用 dbt build。

那个"什么东西"，通常就是 Dagster。Dagster 决定什么时候运行、记录每次运行产出了什么、失败时重试、追踪分区、并运行任意 Python 代码。它有自己的一套数据质量检查（asset checks），也有自己的血缘图——从你声明的依赖关系构建而来。

这张表的最后一行是关键分野：dbt 的血缘图只覆盖一个数仓里的 SQL 模型，Dagster 的血缘图覆盖一切——包括把数据搬进来的那部分 Python。

用一张图表示两者的典型协作方式：

产业判断：这不是二选一的关系，而是管道的上下两段。问"要不要两个都要"，就像问"要不要既有发动机又有方向盘"。

🚀 dbt v2 的三刀：打包、提速、换掉 manifest

看懂了职责边界，再看 dbt v2 改了什么，才能看懂它为什么这么改。v2 的核心变化有三处，每一处都砍在了真实的痛点上。

第一刀，适配器打包。 此前，连接不同数仓的适配器是分散维护的独立包，版本错配是社区里最常见的翻车原因之一。v2 把共享适配器层内置进来，用户少了一层"版本矩阵地狱"。这是框架走向成熟的标志动作：把本不该由用户操心的事情收归平台。

第二刀，解析提速。 dbt 项目一旦长大，几百个模型互相 ref，每次执行前的解析阶段就开始变得漫长。对一个每天跑几十次的转换层来说，解析时间是纯开销。v2 在解析性能上下功夫，省下来的是每一次构建的固定成本——乘以运行频次，这笔账不小。

第三刀，也是最耐人寻味的一刀：文档体验跳过了那个巨大的 manifest.json，取而代之的是更小、可查询的文件。

从这张定位图能看出，dbt 和 Dagster 都处在高门槛高价值区，且高度互补而非互斥。而 v2 的三刀，本质上是在巩固 dbt 在"SQL 转换"这一单点上的纵深——不抢编排层的地盘，而是把转换层做到没有对手。

用一张韦恩图收束两者的关系：

🤖 manifest.json 之死，其实是给 AI 让路

真正值得单独拿出来说的，是 v2 官方对文档新体验的那句描述：更小、可查询的文件，服务于 "人和 AI"（people and AI）。

这六个字信息量很大。过去，dbt 的编译产物是一个巨型 manifest.json——所有模型、依赖、测试、列级别的元数据全塞在一个文件里。对人来说，它太大、太慢、没法直接查询；对 AI 来说，它更是灾难：一个想把数据平台元数据当作上下文喂给智能体的工具，面对几百 MB 的 JSON，要么截断、要么烧 token。

拆成更小、可查询的文件之后，局面完全不同。血缘查询、模型文档、列级描述，都可以按需取用。人读文档更快了，AI 检索元数据也变成了一次精准查询而不是一次暴力加载。

这就是我判断这轮升级最重要的意义所在：数据平台的元数据接口，正在成为 AI 时代的第一等公民 API。当越来越多的团队让智能体来理解数据血缘、生成转换逻辑、诊断测试失败时，元数据能不能被机器高效消费，直接决定了 AI 能在数据平台上走多远。

据多位关注 dbt 社区动向的人士观察，v2 对文档产物的重构并不是孤立的锦上添花，而是把"让机器读懂数据平台"写进了架构设计。这个方向上，dbt 和 Dagster 这类以声明式资产为核心的工具，反而站在了同一条起跑线上——它们都在把平台的运行时状态，变成可查询、可被 AI 调用的结构化知识。

换句话说：manifest.json 的退场，不是文档功能的迭代，而是数据平台向 AI 开放的一张入场券。

🧭 那么，什么时候可以不用 dbt

最后回答那个 Reddit 问题本身。有一个很有说服力的参照：素材中那位长期在一线的实践者，自己的生产管道跑在 Dagster 上，完全没有用 dbt——而且他认为，在某些场景下跳过 dbt 就是正确选择。

什么场景？答案藏在前面的职责划分里。如果你的转换逻辑大部分是 Python——复杂的业务计算、机器学习特征、非 SQL 的数据处理——dbt 的 SQL + Jinja 框架帮不上什么忙，强行套用只会多一层抽象税。Dagster 的 asset checks 又能覆盖基本的数据质量需求，血缘图也天然包含你的 Python 代码。这时，只用 Dagster，架构更简单。

反过来，如果你的核心工作是数仓内的 SQL 建模——分层的维表、事实表、指标口径——dbt 的 ref() 依赖管理、测试体系和文档生成几乎是不可替代的。最佳实践是两者并用：dbt 负责仓库内的 SQL 转换，Dagster 负责调度它、重试它、并把它的血缘接入全管道视图。

决策路径可以简化成一句判断：看你团队的转换工作量，SQL 占大头还是 Python 占大头。SQL 为主，dbt v2 值得升级；Python 为主，别为了"行业标准"硬加一层。

结语

dbt v2 的三刀——打包适配器、提速解析、换掉 manifest.json——表面是工程优化，实质是在两件事上押注：把 SQL 转换层做薄做快，以及让平台元数据对 AI 可查询。而"要不要 dbt"这个常年霸榜的搜索问题，答案从来不在工具对比表里，而在你自己管道的语言构成里。下一个值得盯的问题：当 AI 开始直接消费这些可查询的元数据时，转换层和编排层会不会再次重新划界。大概率会，而且比这次更快。