2. Databricks计费维度解析
理解 Databricks 的成本，第一步不是看账单总额，而是把账单拆成可解释的计费维度。Databricks 的账单通常由几类彼此独立、又相互叠加的费用构成：DBU 费用、云虚拟机费用、存储费用、网络费用，以及 Serverless 场景下被合并计价的资源费用。只有先分清“谁在计费、按什么单位计费、由谁承担”，后续的成本归因、优化和预算控制才有落点。
一、DBU：Databricks 自身的计价单位
DBU（Databricks Unit）是 Databricks 平台侧的计费单位，代表对计算资源的标准化消耗。它并不等同于虚拟机核数或内存，而是一个按“SKU + 计算类型 + 运行时长”计价的抽象单位。账单中常见的字段包括：usage_unit=DBU、sku_name（如 STANDARD_ALL_PURPOSE_COMPUTE、PREMIUM_JOBS_COMPUTE、SERVERLESS_SQL_COMPUTE）、usage_quantity（消耗的 DBU 数量）以及 rate（每 DBU 单价）。
关键点是：DBU 单价随 SKU 和云厂商不同而变化。例如同一区域下，All-Purpose 计算通常比 Jobs 计算单价更高，Serverless SQL 又有独立费率。因此，即使两个作业消耗的虚拟机时长相同，只要 SKU 不同，DBU 费用就可能相差数倍。
二、虚拟机费用：云侧的真实算力成本
经典集群（Classic Cluster）模式下，Databricks 运行在客户云账号的虚拟机上，虚拟机费用由云厂商直接向客户收取，不包含在 DBU 费用中。这部分费用取决于实例类型、数量、运行时长和计费方式（按需、Spot、预留实例）。
因此，一个经典集群作业的总成本可近似表示为：
总成本 ≈ DBU费用 + 虚拟机费用 + 存储费用 + 网络费用
DBU费用 = Σ(usage_quantity × rate)
虚拟机费用 = Σ(实例单价 × 实例数 × 运行小时数)这意味着，优化经典集群成本时，既要关注 DBU 消耗，也要关注虚拟机是否被浪费。例如集群空转、自动伸缩不及时、实例规格过大，都会同时推高两项费用。
三、存储与网络：容易被忽略的隐性成本
存储费用主要来自 DBFS、云对象存储（如 S3、ADLS、GCS）以及 Delta 表数据。它按存储容量、请求次数和 API 调用计费。频繁的小文件写入、未清理的旧版本数据、过度的 OPTIMIZE/VACUUM 操作，都会增加存储和请求成本。
网络费用则发生在跨区域、跨可用区、跨云服务的数据传输中。例如集群节点与存储不在同一区域、Shuffle 数据跨节点传输、外部系统频繁拉取结果，都会产生网络费用。在 Serverless 模式下，这部分费用通常被合并进 Serverless 单价，不再单独列出，但成本依然存在。
四、Serverless 与经典集群的计费差异
Serverless 计算的最大变化是：DBU 费用与底层虚拟机、部分存储和网络费用被合并为一个 Serverless 单价。用户不再直接管理虚拟机，也不需要为闲置资源单独付费，计费粒度更细，通常按秒或按实际使用量计费。
经典集群则相反：DBU 和虚拟机费用分离，用户对实例类型、数量、运行时长有完全控制权，成本透明度更高，但也更容易因配置不当产生浪费。两者的核心差异可以概括为：
- 经典集群：DBU + 虚拟机 + 存储 + 网络，分项计费，控制粒度细，适合稳定、可预测、需要精细调优的负载。
- Serverless：合并计价，按使用量付费，免运维，适合突发、短时、交互式或难以预估的负载。
五、用一张图看清计费维度与流向
下面的 SVG 展示了经典集群与 Serverless 两种模式下，DBU、虚拟机、存储、网络四类费用如何产生、由谁承担，以及最终如何汇总到账单。图中同时标出了“客户云账号”与“Databricks 平台”两个计费主体，便于理解费用归属。
六、实际归因时的判断依据
在真实账单中，判断一笔费用属于哪个维度，可以按以下顺序检查：先看 usage_unit 是 DBU 还是云资源单位；再看 sku_name 确定是 All-Purpose、Jobs 还是 Serverless；然后看 cluster_id 或 warehouse_id 关联到具体计算资源；最后结合云厂商账单中的实例、存储和网络条目做交叉核对。