Databricks 是做什么用的？一份通俗易懂的指南

Databricks 用来把企业的数据集中到一处，加以清洗，再变成报表、预测和 AI 应用。用业务语言来说，它是一个平台：来自 ERP、工厂、CRM 和各类文件的数据在这里经过工程处理，变成人和模型都能信任的东西。

更完整的回答取决于您要解决什么问题，因为 Databricks 覆盖面很广。它包括数据管道、SQL 数据仓库、BI 仪表板、机器学习、AI 智能体，现在还有一个 Postgres 数据库。很少有企业在第一天就需要全部这些。

我在制造业和国防领域的数据平台项目中使用过 Databricks。本指南写给正在判断它是否应该进入自身架构的 CIO、CFO 或数据负责人。

Databricks 的官方平台概述列出了一长串它能做的工作。在实践中，我看到的是五类。

1. 数据工程与 ETL。 从源系统抽取数据，清洗后加载到表中。这是最主要的用例，通常也是大部分支出所在。对应的产品系列是 Lakeflow。Lakeflow Connect 负责数据接入，Lakeflow pipelines（原 Delta Live Tables）负责转换。Lakeflow Designer 是可视化数据准备工具，Lakeflow Jobs 负责编排。
2. 用 Databricks SQL 做数据仓库。 Databricks SQL 是它的云数据仓库，运行在 SQL warehouses 上。分析师直接对工程师构建的同一批表写 SQL，不需要在另一个数据仓库里再复制一份。
3. BI 与自助分析。 AI/BI 仪表板就在平台内部，这些表也可以供给 Power BI、Tableau 或您业务部门已经在用的任何工具。Genie 让业务用户可以用自然语言对受治理的数据提问。
4. 机器学习。 需求预测、预测性维护、质量预测、定价。MLflow 跟踪实验和模型，模型服务（model serving）将其投入生产。
5. 生成式 AI 与智能体。 Agent Bricks 是目前在您的数据上构建和治理 AI 智能体的地方。Genie One 于 2026 年 6 月正式发布（GA），是面向业务用户的前端。较早的资料把这类 AI 工具大多称为 Mosaic AI；目前的产品页面则以 Agent Bricks 和 Genie 为主。

有两个较新的组件对部分买家很重要。Lakebase 是平台内的托管 Postgres 数据库，适用于需要在分析数据旁边进行快速事务性读写的应用。

Databricks 于 2026 年初宣布 Lakebase 正式发布。Databricks Apps 自 2025 年 5 月起正式发布，让团队可以在平台上构建和托管内部的数据与 AI 应用。

还有一点命名上的说明，因为它会让搜索结果变得混乱。Databricks 花了两年时间推广“Data Intelligence Platform”。现在它的产品页面写的是“Databricks Data + AI Platform”。

是同一个平台。另外，Databricks One 已更名为 Genie One。

在 Databricks 出现之前，大多数企业运行两套系统。数据湖存放廉价的原始文件，包括传感器日志、文档和图像，供数据科学家使用。

数据仓库存放干净的结构化表，供财务和 BI 使用。数据在两者之间复制，两份副本逐渐不一致。

湖仓是 Databricks 给出的答案：以开放格式只保留一份数据（存放在您云存储上的 Delta Lake 表），在上面同时运行 BI 和 AI。Unity Catalog 位于最上层，管控谁能看到什么、跟踪数据血缘并记录访问日志。正是这一治理层，把一堆文件变成了审计人员能够接受的东西。

大多数团队用奖章架构来组织湖仓。共三层，每一层都比上一层更干净。

数据如何在奖章分层中流动

1. 01

   源系统

   ERP、MES、历史数据库、CRM、电子表格和文档。

2. 02

   青铜层

   原始数据按到达时的样子落地。保留用于审计和重新处理。

3. 03

   白银层

   经过清洗、去重和校验。每条记录只有一个可信版本。

4. 04

   黄金层

   按业务需要建模：按产品的利润率、按产线的停机时间、按供应商的支出。

5. 05

   使用方

   仪表板、财务报表、机器学习模型、AI 智能体和应用。

给业务负责人的版本：青铜层是证据，白银层是清洗后的记录，黄金层是业务问题的答案。您的 CFO 只应该看到黄金层。您的数据科学家大部分时间会花在白银层。

在我参与过的制造业项目中，真正的工作量都在白银层。各工厂之间不一致的物料编号。对不上的计量单位。

按当地时间记录的传感器时间戳，对应的却是按 UTC 记录的 ERP 过账。这些都不是 Databricks 的问题，但最终您都要在 Databricks 里解决它们。

Databricks 并不取代 SAP S/4HANA、Oracle Fusion Cloud ERP 或 Microsoft Dynamics 365。ERP 仍然是订单、库存、发票和总账的记录系统。Databricks 获取这些数据的副本，把它们与 ERP 从未接触过的数据结合起来，提供分析和 AI 服务。

ERP 数据通常通过三条路径之一进入：

1. 原生或合作伙伴连接器。 Lakeflow Connect 以及第三方复制工具，从 ERP 数据库或其 API 抽取表或变更数据。
2. 从 ERP 自身数据层导出。 从 SAP、Oracle 或 Dynamics 的分析与数据服务导出数据，落地到青铜层。
3. ERP 厂商的数据产品。 对 SAP 用户来说，SAP Business Data Cloud 是一个选项。它包含 SAP Databricks，即 SAP 产品内的托管 Databricks 服务，Databricks 已宣布其正式发布。此外还有一条从 Business Data Cloud 到现有 Databricks 环境的零复制共享路径。

哪条路径合适，取决于许可、数据量以及非 ERP 数据有多重要。难点从来不在抽取本身。

难点在于业务含义：哪个工厂、哪本账、哪个版本的客户。如果这些还没有理清，我关于数据迁移为什么失败的文章讲的是同样的根本原因。

制造业。 最有说服力的用例是把 ERP 数据与工厂数据结合起来。来自历史数据库和物联网平台的设备与传感器读数、制造执行系统（MES）记录、质检结果和维护日志。这些数据与 ERP 的订单、物料和成本结合后，能回答财务和运营都关心的问题：各产线的报废成本、故障发生前的维护、供应商质量与采购价格的对比。

传感器数据量大而且杂乱。湖仓处理这类数据比传统数据仓库更好。在我的制造业工作中，第一个让平台回本的用例是成本核算：把原材料成本和人工成本汇总起来，得出标准成本。

财务本来就对这个数字负责，所以价值一目了然。如果您还在选择底层的 ERP，请参阅我对制造业 ERP 的比较。

国防。 问题不一样。数据实际存放在哪里？谁来运营这个平台？

涉密数据和非涉密数据能否分开，并且在审计中证明访问控制？项目一做就是几十年，所以平台选择必须经得起好几轮技术周期。

在我的国防工作中，把涉密和非涉密数据分开，比任何其他因素都更影响设计。在设计第一条数据管道之前，先把这种隔离定下来。

架构在这里很重要。在 Databricks 中，控制平面运行在 Databricks 的账户里。经典计算运行在您自己的云账户中。

无服务器计算运行在 Databricks 的账户里，位于同一区域。对国防数据负责人来说，这个区别是第一场对话的内容，要放在任何功能演示之前。针对美国政府项目，另有 Databricks on AWS GovCloud 部署。

在美国以外，入围之前请对照您的数据驻留和出口管制规定（包括 ITAR 类义务）核实区域和主权云的可用性。我发现，Unity Catalog 的细粒度访问控制和审计日志在这类审查中分量很重。

很容易为了错误的工作而购买 Databricks。

1. 它不是 ERP，也不是记录系统。 不要用它处理交易或总账。Lakebase 处理的是应用数据，不是您的总账。
2. 它不是快速做仪表板的工具。 如果目标是基于干净 ERP 数据做二十个财务仪表板，Databricks 是一条很重的路。
3. 它解决不了数据归属不清的问题。 如果客户主数据没有人负责，Databricks 只会更快地处理这团乱麻。
4. 它不会自己运转。 您需要会写 SQL 和 Python 的数据工程师，还需要有人盯着成本。费用按使用量计量，写得不好的作业会直接体现在账单上。
5. 商业使用不免费。 Free Edition 用于学习和实验。Databricks 的 Free Edition 限制说明写明它不得用于商业目的。

我听到最多的问题是：我们需要 Databricks，还是一个更简单的数据仓库就可以？我是这样判断的。

您的情况	适合 Databricks	更简单的选项很可能就够了
数据来源	ERP 加传感器、MES、文档、外部数据源	主要是 ERP 和 CRM 表
数据量与变化	大数据量、流式或近实时	每日批处理，数据量适中
主要用户	数据工程师、数据科学家和分析师	财务和业务分析师
AI 与机器学习计划	有资金、有负责人的用例	尚无发起人的想法
团队技能	内部或外包的 SQL 和 Python 工程师	主要是 BI 和 Excel 技能
治理需求	跨多个数据源的细粒度访问、血缘和审计	标准的基于角色的访问

如果您的大部分答案落在右侧一栏，就从 ERP 厂商的分析工具或托管数据仓库开始。如需更细的比较，请阅读同系列的 Snowflake 与 Databricks 对比和 Databricks 与 Microsoft Fabric 对比。

关于成本，请参阅 Databricks 定价详解。Databricks 以 Databricks Units（DBU）计费计算资源，可选按需付费或承诺用量条款，云存储和网络费用另计。

决策清单

1. 如果数据平台运转良好，您能说出三个会因此改变的业务决策吗？如果不能，先停下来把它们找出来。
2. 除了 ERP，您还需要哪些数据来源，规模有多大？
3. 客户、物料、供应商和科目表的主数据由谁负责？
4. 您在数据驻留、数据主权和出口管制方面有哪些约束？
5. 您是否有，或者是否愿意长期出资组建，一支数据工程团队？
6. 哪个 BI 工具会保留，它会从 Databricks SQL 读取数据吗？
7. 谁对每月的平台支出负责，什么样的告警会触发复盘？
8. 上线后您会关停什么？如果答案是什么都不关，那您是在增加成本，而不是在整合。

选一个有明确业务负责人、并且涉及真金白银的用例。在制造业，这通常是报废、停机或库存。从第一张表开始就启用 Unity Catalog 治理，按青铜、白银、黄金三层把它建起来。

衡量结果和运行成本。然后再决定是否扩大规模。

我不会从全企业范围的迁移或 AI 智能体开始。治理应该放在第一次构建中，而不是留到后续阶段；我的 AI 治理框架指南解释了原因。

如果您正在把 Databricks 与其他平台做比较，或者在研究它如何与 SAP、Oracle 或 Dynamics 365 并存，我可以就这类决策提供独立建议。您可以在这里联系我。

用简单的话说，Databricks 是什么？

Databricks 是一个云平台，企业在上面存储、清洗和分析大量数据，并在此基础上构建机器学习和 AI。它运行在 AWS、Microsoft Azure 和 Google Cloud 上。可以把它看作位于源系统与报表、模型和 AI 工具之间的工程车间。

Databricks 是数据库还是数据仓库？

部分来说两者都是。Databricks SQL 是建立在湖仓之上的云数据仓库，Lakebase 是面向应用的托管 Postgres 数据库。在底层，数据以开放格式的表存放在云存储上。它不是像 ERP 那样的事务型记录系统。

Databricks 和 Snowflake 有什么区别？

两者都在云数据上运行 SQL 分析。Databricks 起步于基于开放格式的数据工程和机器学习。Snowflake 起步于托管的 SQL 数据仓库。如今两者高度重叠。正确的选择取决于您的数据类型、团队技能和 AI 计划。我的 Snowflake 与 Databricks 对比有详细说明。

Databricks 会取代 SAP 或其他 ERP 系统吗？

不会。ERP 仍然是交易和总账的记录系统。Databricks 获取 ERP 数据的副本，与工厂和传感器数据等其他来源结合，提供分析和 AI 服务。SAP 客户也可以在 SAP Business Data Cloud 中使用 SAP Databricks。

Databricks 中的奖章架构是什么？

这是一种把数据分为三层来组织的方法。青铜层保存按到达时原样存放的原始数据。白银层保存经过清洗和校验的记录。黄金层保存可直接用于报表、机器学习和 AI 的业务表。每一层都比上一层更精炼，业务用户只应使用黄金层。

Databricks 可以免费使用吗？

Databricks Free Edition 可免费用于学习和实验，有配额和功能限制，并且不得用于商业目的。商业使用按 DBU 消耗计费，可以按需付费，也可以签订承诺用量合同，云存储和网络费用另计。