dbt Core 2022 路线图解读：从 v1.2 到 v1.5+ 的版本演进、Python 模型与多项目愿景-育师

dbt Core 2022 路线图解读：从 v1.2 到 v1.5+ 的版本演进、Python 模型与多项目愿景

【免费下载链接】dbtdbt enables data analysts and engineers to transform their data using the same practices that software engineers use to build applications.项目地址: https://gitcode.com/GitHub_Trending/db/dbt

导读

本文以 dbt Core 官方路线图文档 docs/roadmap/2022-08-back-for-more.md 为主体，梳理 dbt Core 在 2022 年 8 月的时间节点上发布的版本计划与产品思考：从已落地的 v1.1/v1.2，到即将发布的 v1.3（Python 模型、Jinja3、Semantic Layer），再到 v1.4 的 API + CLI 重构与结构化日志，以及面向 v1.5+ 的多项目部署与外部编排愿景。读完本文，你将掌握每个版本的核心能力清单、dbt 团队当时的路线图决策逻辑，并能结合本仓库源码（Rust 版 dbt v2.0）理解这些规划最终如何落地为工程现实。

版本总览：一张表看懂 2022 下半年路线图

该路线图文档开篇即给出了一张"版本—时间—命名—内容—置信度"的总览表，这是理解全文的骨架，原样保留如下：

Version	When	Namesake	Stuff	Confidence
1.1 ✅	April	Gloria Casarez	Testing framework for dbt-core + adapters. Tools and processes for sustainable OSS maintenance.	100%
1.2 ✅	July	Henry George	Built-in support for grants. Migrate cross-db macros into dbt-core / adapters. Improvements to metrics.	100%
1.3 🌀	October	Python models in dbt. More improvements to metrics. (Other things, too—but those are the main events.)	95%
1.4 ⚒️	Jan 2023	Behind-the-scenes improvements to technical interfaces. A real, documented Python API/library, with an improved CLI to wrap it. Further investments in structured logging.	80%
1.5+ 💡	Next year	Multi-project deployments: split up the monolith. The same DAG, more active: external orchestration. Python in dbt: next steps. Start imagining dbt Core v2.	50%

文档中的三条脚注对这张表做了必要限定，它们是理解这张表的"使用说明书"：

命名（Namesake）：每个版本都以一位费城名人命名（"Always a phamous Philadelphian"），v1.1 的 Gloria Casarez 与 v1.2 的 Henry George 均在此列，后续版本的名字会征求社区建议。
置信度（Confidence）：dbt Core 越来越像一个"标准制定者"，其路线图会真实影响数据团队的规划和生态中其他工具的路线，因此团队选择提前数月公开想法，但同时"保留转向的权利"，置信度就是这种不确定性的量化表达。
版本节奏（Footnote c）：团队计划在可预见的未来保持每季度一个 minor 版本的节奏；对于 6 个月之后的规划，团队更关心"做什么、为什么做"，而非"何时做"；并且这些想法"不是确定的承诺"。

需要说明的是，文档同时给出updated_at: 2022-08-31的时间戳，意味着这是一份季度更新性质的路线图快照，与其前后两篇 2022-05-dbt-a-core-story.md 与 2023-02-back-to-basics.md 构成了一条连续的公开路线图叙事线。

团队变化：两名全职产品经理加入

在介绍具体版本之前，文档宣布了一个组织层面的消息：两名新的产品经理全职投入到 dbt Core 的产品规划中——Cody（GitHub 账号 @lostmygithubaccount，此前专注 MLOps，负责把机器学习系统产品化）与 Florian（GitHub 账号 @fleid，资深 SQL 开发者出身，负责接棒 adapters 积压的 issue 与 PR 治理）。

这一变化的信号意义在于：随着 dbt Core 进入稳定期（v1.0 已于 2021 年 12 月发布），团队认为"是时候重新追问一些大问题了"——其中最核心的是"dbt 究竟是什么？"（what is dbt,really?）。作者坦言，过去凭直觉给出的答案有"固化成受限愿景"的风险，甚至一条 2019 年的 GitHub issue 评论都可能被当成"有约束力的先例"。引入新的产品视角，是为了让这些假设重新接受审视。

v1.3（2022 年 10 月）：Python 模型成为主角

v1.3 是整个路线图文档着墨最多的版本，其核心事件是Python 模型的正式支持（当时以 beta 文档形式发布）。文档针对社区最关心的三个问题逐一作答，本节完整继承并展开：

三个 FAQ：Python 模型带来的疑虑与回答

Q1：使用 dbt 是否必须会 Python？完全不必。文档明确："Not at all." 同时，如果不会 Python 且想学，社区的开源 Python 数据生态是一个强大但也常常令人不知所措的领域，团队会创建资源、推荐社区指南与实战教程来铺路。

Q2：现在是否该开始尝试高级统计处理、预测分析？"Maybe! Or maybe not." 文档给出的建议是：先打好基础的数据模型地基——深入理解你的数据，用它支撑可靠的分析报表；无论你决定何时迈出下一步，dbt 都会让这一步成为可能。

Q3：引入 Python 是否会从根本上改变 dbt Core 的性质？文档的回答是"既会也不会（yes and no）"：

不会：对于你已经在用 SQL 编写且运行良好的转换逻辑，应该继续保持。SQL 仍是编写大多数数据转换最直接、最易上手的方式，团队不会停止投资 SQL 支持与 Jinja 模板引擎——v1.3 还包含一次期待已久的Jinja3 升级，以帮助用户与其它基于 Jinja 的工具共存。
会：支持 Python 澄清了团队对"多语言 dbt（multilingual dbt）"的思考。dbt 的真正价值不在于 Jinja 模板化的 SQL（"Anyone can build that in a weekend"），而在于框架本身——环境感知的工作流、DAG、集成的测试与文档。这些能力比想象中更与语言无关。同时每种语言各有优势，"有些事在 Python 里能做、在 Jinja-SQL 里做不了，反之亦然"。

不止于 Python：v1.3 的其他亮点

文档特别强调，Python 是主角但并非唯一新特性：

每个版本都包含大量社区贡献，v1.3 包含一项被期待已久的特性（文档链接指向自定义节点颜色docs配置，版本 1.3）；
Metrics 的改进正在为dbt Semantic Layer的发布铺路——这是一项"酝酿已久的巨大计划"。

v1.4（2023 年 1 月）：为 dbt Core 的"技术地基"投资

Coalesce 大会之后，团队将 11 月至次年 1 月的时间专门投入到 dbt Core 的技术基础建设（technical foundations）。文档将这项工作概括为两大倡议：

1. API + CLI：文档化的 Python API 与重构后的 CLI

改善并文档化 dbt Core 的内部 Python API，并围绕它构建一个结构更合理的新 CLI。文档强调：新 CLI 将支持与今天完全相同的命令、flag 和参数（"this CLI will support all the same commands, flags, and arguments as it does today"）。

这项工作的动机分层清晰：

如果你是 dbt Core CLI 用户：命令与选项的数量和复杂度在持续增长，这项工作能让"所有正确的 flag 和选项在正确的命令上得到支持"、更新帮助文本，并自动协调文档更新（此前文档依赖人工维护）。
如果你构建围绕 dbt-core 的工具：一个稳定、文档化的内部 API 的价值不言而喻。这是一项长期工程，期间会破坏一些未文档化的内部方法（文档提前致歉）。
如果你使用 dbt Cloud：Core 提供稳定合理的接口，是 dbt Cloud 未来实现差异化能力的重要前提。
只要你在用 dbt：这项工作能让团队明年更快地构建更多功能，也让更多社区成员愿意加入贡献——"一个欢迎新人的代码库"。

2. 事件 + 日志接口：类型安全、语言无关的结构化日志

支持以类型安全、语言无关的方式摄取 dbt Core 产生的结构化日志。这将让其他工具（dbt 官方与社区的）能够提供围绕 dbt 运行的可靠可观测性，以及更易消化、更接近实时的元数据；长期来看，还将在日志事件中补充当前缺失的信息。

源码佐证：这两项规划在 Rust 版 dbt v2.0 中均有清晰对应物。仓库中的 crates/dbt-python-core/src/lib.rs 正是"文档化 Python API + 稳定 CLI"的现代实现——它通过DbtRunner类提供进程内调用能力（invoke接收["run", "--select", "my_model"]这样的参数列表，在释放 GIL 后于 Rust 引擎内执行，再通过 msgpack 将manifest、list、sources、run_results等 artifact 回传给 Python 侧 dataclass），并提供run_cli控制台入口；其模块注释明确写着"每个 dbt 发行版的 Python 扩展模块共享的引擎胶水层"。结构化日志方面，crates/dbt-tracing/README.md 描述了一个基于tracing构建的类型化 span/event 属性、遥测记录信封、中间件、消费者、过滤、序列化导出的通用库，且明确"这不是匿名的产品使用遥测，也不是产品分析客户端"——与文档中"类型安全、语言无关的结构化日志接口"的设想一致。

v1.5+（次年）：两大长期愿景

文档强调，这一节列出的主题"既不是确定的承诺，也不是明年要做的事情的全集"，而是团队"一直在讨论、已经在构思代码"的两组想法：

愿景一：多项目部署（Multi-project deployments）

ref一个来自他人项目的最终模型——无论它部署在哪里，都不需要先运行它。文档给出了具体的应用场景：

把包含 5000 个模型的单体项目拆成 10 个各 500 个模型的项目，按团队和领域分组。

文档明确指出这"不仅仅是命名空间（namespacing）"：要真正解决这个问题，还需要解决**版本化（versioning）与契约（contracts）**问题，并支持多种部署机制。相关的 GitHub discussion 编号为 #5244。

仓库佐证：这一设想在后续演进中形成了 dbt Mesh 与 cross-projectref，并在当前仓库中以dbt-defercrate（crates/dbt-defer/src/lib.rs）等形式沉淀下来。

愿景二：外部编排（External orchestration）

"同一个 dbt DAG，扮演更主动的角色"。文档强调这不会引入新的节点类型，而是升级现有节点类型——sources、models 和 exposures：

Sources：可以触发自身的摄取（ingest）；
Exposures：可以触发下游数据消费者（同步、sink 等）；
Models：可以在专用执行环境中定义并运行转换，从集中式存储读取并写回。

对每个外部集成，文档提出了实现原则："在可能的情况下用一个简单的请求，在合理的情况下用专门的插件"（a simple request where possible, and a dedicated plugin where justified）。相关讨论编号为 #5073。

持续演进：三个"仍要推进"的方向

除了上述大版本规划，文档还列举了团队打算持续投入的三条主线（同样是"非穷尽列表"）：

Python 模型，才刚刚开始：标准化的 DataFrame API 应该是什么样？dbt 是否应该在包管理、模型训练、artifacts 中扮演角色？最终是否形成完整的 "MLOps" 工作流？文档明确 v1.3 是"第一次尝试，而不是最终故事"，并预告 Cody 已开启新的 GitHub discussions（#5742）。
Adapters，还是 adapters：让在新数据库、查询引擎或运行时环境上构建、测试、验证 dbt 支持变得更容易；支持单次 dbt-core 调用中使用多个 adapter；持续打磨跨数据平台的缓存、cataloging 与增量处理性能；在 dbt Cloud 中提供更多 adapter。
想象 dbt Core v2：文档回顾了 2021 年 12 月 v1.0 发布时对 v2.0 的四条预言（当时预测 v2.0 会在 2023-2025 年间到来）：
- dbt-SQL：同样的能力，没有 Jinja（脚注：现在想想，答案或许是 Jinja-SQL 与 Python 只是 dbt Core 支持的众多语言中的两种——有些语言让单元测试、跨数据库转译、列级血缘推断变得轻而易举，另一些则能运行动态模板化转换逻辑的内省查询；挑战在于清楚且坚定地说明每种语言的长处与适用时机）；
- 文档永远就绪（脚注：即实时元数据）；
- 一次 dbt run 横跨多个数据库与查询引擎（脚注：即外部编排）；
- 为 dbt DAG 定义你自己的任务（脚注：作者自认"这个我不太确定"，核心任务仍然是"尽可能快地构建 DAG，只做需要的、在需要的时候做"，但在 dbt-core 拥有文档化、受契约约束的内部 API 的未来，程序化创建、操作和调用 DAG 的高级用例可能变得更可行——"高级玩法，不提供护栏"）。

作者对时间表的判断是：明年（2023）不会发布 v2.0 最终版，但会形成"v2 长什么样的清晰图景"——而梳理 v1 的粗糙边缘，本身就是通往 v2 的工作。

从 2022 路线图回望：规划如何变成今天的仓库

将 2022 年 8 月的这份路线图与当前仓库对照，可以清晰地看到"季度路线图—置信度—公共讨论"这套机制的实际效果：v1.3 的 Python 模型与 Jinja3、v1.4 的 API/CLI 与结构化日志、v1.5+ 的多项目与外部编排设想，逐步演化为今天 Rust 版 dbt v2.0 仓库中的具体能力（仓库根目录 README.md 明确说明main分支包含 dbt v2.0 的 Apache 2.0 源码，一个从零用 Rust 重写的 dbt；CHANGELOG-fusion.md 记录了两个引擎合并后的持续发布）。同期文档 docs/roadmap/2025-05-new-engine-same-language.md 与 docs/roadmap/2026-06-announcing-v2.md 则完整记录了"多引擎并存—合并为单一 v2.0"的后续故事——这正是 2022 年路线图中"开始想象 dbt Core v2"的最终答案。

对于今天的读者，这份文档的价值不在于预测的精确性，而在于它展示了一个被大规模依赖的开源项目如何在公共场域管理路线图预期：明确置信度、提前数年预告、保留转向权利、用"语言与引擎"的框架思考长期架构。理解这条路线，也是理解当前 dbt 仓库中诸多设计决策（稳定的 CLI/API 契约、结构化可观测性、多项目与跨项目引用、单一引擎愿景）的起点。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考