2. Databricks工作负载剖析

在 Databricks 上做性能优化与成本治理，第一步不是调参数，而是先搞清楚“钱花在了哪一类负载上”。同一个工作区里通常同时跑着四类差异极大的负载：Spark 作业、Delta Live Tables（DLT）、SQL Warehouse 和 ML 训练任务。它们的运行机制、资源占用形态、计费口径和优化抓手完全不同。如果把它们混在一起看总账单，几乎不可能定位问题。本节先建立这四类负载的“资源消耗画像”，为后续的调优和成本归因打基础。

四类负载的运行机制差异

Spark 作业是最基础的形态。它由 Driver 和一组 Executor 组成，Driver 负责 DAG 调度、任务分发和结果汇总，Executor 负责实际执行 Task。作业以 Job→Stage→Task 的层级展开，Stage 之间由 shuffle 边界切分。资源消耗的核心特征是：计算与存储分离，但 shuffle 会强制落盘。一个典型的 ETL 作业，瓶颈往往不在 CPU，而在 shuffle 读写和倾斜分区。它的计费按 DBU（Databricks Unit）乘以运行时长，集群类型（All-Purpose 还是 Job Cluster）直接决定单价，这也是为什么“用 All-Purpose 集群跑批”是常见的成本浪费。

Delta Live Tables 本质上是 Spark 之上的声明式编排层。用户只定义数据流（流式表、物化视图、视图），DLT 负责依赖解析、增量刷新和血缘。它的资源特征与普通 Spark 作业的关键区别在于：DLT 会持续维护一个常驻的 pipeline 集群，即使没有新数据，集群也可能处于待命状态；同时它引入了“更新（update）”这一调度单位，每次触发会重新计算受影响的下游表。因此 DLT 的成本不只是计算量，还包括“空转时间”。优化重点是合理设置触发模式（Triggered 还是 Continuous）、控制刷新范围，以及避免不必要的全量重算。

SQL Warehouse 面向 BI 和交互式查询，采用 MPP 架构，计算资源以“集群规格 × 集群数量”的形式提供，支持 Serverless 和 Classic 两种模式。它的资源消耗特征是按查询并发和扫描数据量波动：空闲时如果开启了自动停止，成本趋近于零；但一旦并发查询堆积，会触发自动扩缩容，成本随集群数量线性上升。SQL Warehouse 的优化核心是查询本身（分区裁剪、文件布局、缓存命中）和扩缩容策略，而不是像 Spark 那样调 Executor 内存。

ML 训练任务是四类中最“重”的。它通常以单节点多 GPU 或分布式训练的形式运行，资源消耗集中在 GPU 显存、GPU 利用率和节点间通信。与 Spark 的弹性伸缩不同，ML 训练往往需要长时间独占高配节点，且对中断敏感（checkpoint 丢失会导致重跑）。它的成本特征是“高单价 × 长时长”，优化抓手包括：选择合适的 GPU 型号、用 Spot 实例配合 checkpoint、控制数据加载的 I/O 瓶颈，以及避免用 All-Purpose 集群做长时训练。

资源消耗特征对比与计费口径

把四类负载放在同一张坐标里看，差异非常直观：SQL Warehouse 弹性最高、单价最低，但并发一上来成本会快速放大；Spark 作业弹性高、单价中等，成本主要由运行时长和 shuffle 量决定；DLT 弹性中等，但存在常驻集群带来的“基础成本”；ML 训练弹性最低、单价最高，一旦启动就是高成本长占用。理解这张图，就能在账单异常时快速判断“是哪一类负载在烧钱”。

从机制到优化：每类负载的观察点

要真正把成本治理落地，需要知道每类负载“看什么指标”。Spark 作业重点看 Spark UI 里的 shuffle read/write、task 倾斜和 GC 时间；DLT 重点看 pipeline 的 update 时长、待命时间和每次刷新涉及的表数量；SQL Warehouse 重点看 Query History 里的扫描行数、缓存命中率和集群扩容次数；ML 训练重点看 GPU 利用率、checkpoint 频率和节点间通信占比。这些指标是后续章节做归因和调优的输入。