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.3Python 模型、Jinja3、Semantic Layer再到 v1.4 的 API CLI 重构与结构化日志以及面向 v1.5 的多项目部署与外部编排愿景。读完本文你将掌握每个版本的核心能力清单、dbt 团队当时的路线图决策逻辑并能结合本仓库源码Rust 版 dbt v2.0理解这些规划最终如何落地为工程现实。版本总览一张表看懂 2022 下半年路线图该路线图文档开篇即给出了一张版本—时间—命名—内容—置信度的总览表这是理解全文的骨架原样保留如下VersionWhenNamesakeStuffConfidence1.1 ✅AprilGloria CasarezTesting framework for dbt-core adapters. Tools and processes for sustainable OSS maintenance.100%1.2 ✅JulyHenry GeorgeBuilt-in support for grants. Migrate cross-db macros into dbt-core / adapters. Improvements to metrics.100%1.3 OctoberPython models in dbt. More improvements to metrics. (Other things, too—but those are the main events.)95%1.4 ⚒️Jan 2023Behind-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 yearMulti-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 Philadelphianv1.1 的 Gloria Casarez 与 v1.2 的 Henry George 均在此列后续版本的名字会征求社区建议。置信度Confidencedbt 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 的产品规划中——CodyGitHub 账号 lostmygithubaccount此前专注 MLOps负责把机器学习系统产品化与 FlorianGitHub 账号 fleid资深 SQL 开发者出身负责接棒 adapters 积压的 issue 与 PR 治理。这一变化的信号意义在于随着 dbt Core 进入稳定期v1.0 已于 2021 年 12 月发布团队认为是时候重新追问一些大问题了——其中最核心的是dbt 究竟是什么what is dbt,really?。作者坦言过去凭直觉给出的答案有固化成受限愿景的风险甚至一条 2019 年的 GitHub issue 评论都可能被当成有约束力的先例。引入新的产品视角是为了让这些假设重新接受审视。v1.32022 年 10 月Python 模型成为主角v1.3 是整个路线图文档着墨最多的版本其核心事件是Python 模型的正式支持当时以 beta 文档形式发布。文档针对社区最关心的三个问题逐一作答本节完整继承并展开三个 FAQPython 模型带来的疑虑与回答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 澄清了团队对多语言 dbtmultilingual dbt的思考。dbt 的真正价值不在于 Jinja 模板化的 SQLAnyone can build that in a weekend而在于框架本身——环境感知的工作流、DAG、集成的测试与文档。这些能力比想象中更与语言无关。同时每种语言各有优势有些事在 Python 里能做、在 Jinja-SQL 里做不了反之亦然。不止于 Pythonv1.3 的其他亮点文档特别强调Python 是主角但并非唯一新特性每个版本都包含大量社区贡献v1.3 包含一项被期待已久的特性文档链接指向自定义节点颜色docs配置版本 1.3Metrics 的改进正在为dbt Semantic Layer的发布铺路——这是一项酝酿已久的巨大计划。v1.42023 年 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 CloudCore 提供稳定合理的接口是 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 deploymentsref一个来自他人项目的最终模型——无论它部署在哪里都不需要先运行它。文档给出了具体的应用场景把包含 5000 个模型的单体项目拆成 10 个各 500 个模型的项目按团队和领域分组。文档明确指出这不仅仅是命名空间namespacing要真正解决这个问题还需要解决**版本化versioning与契约contracts**问题并支持多种部署机制。相关的 GitHub discussion 编号为 #5244。仓库佐证这一设想在后续演进中形成了 dbt Mesh 与 cross-projectref并在当前仓库中以dbt-defercratecrates/dbt-defer/src/lib.rs等形式沉淀下来。愿景二外部编排External orchestration同一个 dbt DAG扮演更主动的角色。文档强调这不会引入新的节点类型而是升级现有节点类型——sources、models 和 exposuresSources可以触发自身的摄取ingestExposures可以触发下游数据消费者同步、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 重写的 dbtCHANGELOG-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 契约、结构化可观测性、多项目与跨项目引用、单一引擎愿景的起点。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考