Databricks处理数据，dbt定义数据含义

当Databricks在2025年5月宣布收购Neon时，它公布了一个来自Neon自身遥测的数据：平台上超过80%的数据库是由AI代理而非人类创建的。这个数字是关于Neon的。它背后的疑问适用于每个平台，包括Databricks。当代理编写你的收入模型时，仍需要有人拥有定义。当你的CFO询问上一季度的数字是如何产生的时，答案必须存在于你能接触到的地方。

这是写给那些数据领导者的，他们的团队已经在Databricks上运行，并且正在被问到dbt是否仍然值得其开销。

简短的回答是：Databricks是一个优秀的平台，我们是合作伙伴。dbt-databricks适配器由Databricks团队维护。如果你运行ML管道、构建湖仓一体，或进行严肃的AI特征工程，它属于你的技术栈。成千上万的数据团队在生产中运行dbt和Databricks。

我想要挑战的是一个不同的假设：选择Databricks作为你的计算平台和选择Databricks来拥有你的转换逻辑是同一个决定。大多数公司同时做出这两个决定而没有注意到。它们不是同一个决定。

Databricks很好，但这并不是重点

湖仓一体计算、Delta表、协作笔记本、ML管道。这些是提供真正价值的真实能力。

Databricks也在构建位于转换层的产品：用于管道编排的Lakeflow声明式管道（原Delta Live Tables）、用于查询和分析工作的Databricks SQL、用于治理和血缘的Unity Catalog。每个单独来看都是合理的。它们共同代表了一组关于你的转换逻辑将驻留在何处的决策。

选择Databricks进行计算是一个基础设施决策。选择Databricks来拥有你的转换逻辑是对你的数据团队的制度性知识将驻留在何处的战略押注。大多数高管签署第一个，却没有意识到他们也做了第二个。

拥有转换层实际上意味着什么

完全整合的风险不是理论上的。当你第一次尝试离开、审计或解释时，它们就变得具体了。

从可移植性开始。如果你的转换逻辑存在于Lakeflow管道和Databricks笔记本中，移动它意味着重写它。这种退出成本不会出现在今天的合同谈判中。它将以一个你没有预算的多月工程项目的形式出现，由定价变化或你签署时看似遥远的战略转向触发。

然后是审计性。当你的CFO询问为什么第三季度收入被修订时，追溯答案需要Databricks平台访问权限，而不是git差异。转换逻辑的版本控制依赖于平台，这意味着它依赖于供应商的访问控制和定价层级。

还有时机。当一切顺利时，企业不会感到供应商锁定。当定价变化、他们想要在其他地方运行工作负载，或平台转向时，他们才会感受到。到那时，转换层已经是承重基础设施了。

Databricks会反驳说Unity Catalog提供了血缘和治理。这是真的。但专有目录中的血缘只是发生了什么事的记录。开放、版本控制的SQL中的转换逻辑让你能够改变发生的事情，并且独立地在任何地方做到这一点。

dbt给你什么，Databricks无法取代

dbt解决的问题与Lakeflow声明式管道不同。它将转换逻辑放在开放、版本控制的SQL中，任何工程师都可以读取、测试和运行，无论底层是什么。

dbt能给你而Lakeflow管道不能的五件事。

一个项目，任何仓库。 同一个dbt项目可以在Databricks、Snowflake、BigQuery、DuckDB以及越来越多的兼容平台上运行。转换逻辑是你的。当你的仓库战略转变时，你移植逻辑而不是重写管道。

开放标准，以及它们之上的层。 2026年6月1日，dbt Labs将dbt Fusion引擎运行时开源，作为dbt Core v2.0的alpha版本，在Apache 2.0许可证下发布。Databricks也在这方面做出了自己的开源举措，在2025年将其声明式管道框架捐赠给Apache Spark。区别在于上面是什么。开放运行时只是入场筹码。你的团队真正需要拥有的是它上面的层：测试、契约、指标定义，以及解释一个数字意味着什么并证明它没有悄悄改变的血缘。

一个可移植的语义层。 dbt语义层中的指标定义是设计上平台无关的。定义一次收入，无论查询落在Databricks还是其他地方，该定义都成立。

一个围绕标准组织的社区。超过100,000个数据团队基于dbt构建。该社区围绕一个共享的、开放的转换标准而非单一供应商的路线图凝聚，当你决定你的团队的制度性知识将驻留在何处时，这值得权衡。

不依赖于平台的成本控制。 dbt State作为你管道的缓存层工作：它构建已更改的内容，跳过未更改的内容。团队看到仓库计算量下降30%或更多。它运行在dbt Core 1.7+上，作为插件或在dbt平台中开箱即用，因此节省不取决于将你的转换层整合到任何特定地方。这是整个论点的缩影。效率来自引擎理解你的项目，而不是平台拥有它。

高管在整合前应该问的五个问题

1. 如果我们需要在90天内将30%的数据工作负载从Databricks移走，那将需要什么？
2. 我们能否在无需Databricks访问权限的情况下，为产生上一季度收入数字的每个转换生成完整的审计跟踪？
3. 我们的指标定义是在代码中，还是在Databricks笔记本中？
4. 我们的数据团队是否拥有转换逻辑，还是它存在于供应商产品内部？
5. 如果明年我们的转换工具定价发生变化，我们的备选方案是什么？

这些情况都描述了组织已经大规模面临过的情形。最终陷入困境的高管们并不天真。他们同时做出了这两个决定，却没有意识到它们是分开的。

正确的边界：每一层拥有什么

“dbt 对比 Databricks”是错误的框架。我们是合作伙伴，这种组合在生产环境中已被验证。风险出现在公司模糊两者边界时。

这是站得住脚的边界。

层

拥有什么

Databricks

计算、基于 Delta 的存储、ML 管道、AI 特征工程、协作笔记本

dbt

转换逻辑、语义层、数据契约、代码中的沿袭、测试

Databricks 处理你的数据。dbt 定义数据的意义。这是两个不同的工作，混淆它们正是风险来源。

那些后悔完全整合的高管，是在一切正常运作时批准了整合，之后才需要向董事会解释数字、迁移工作负载，或看着数据团队的制度知识随着 Databricks 笔记本一起流失。

dbt 是组织保持独立于任何单一供应商、理解自身数据能力的方式。

了解 dbt 和 Databricks 如何协同工作。 探索集成