2. Databricks机器学习工作负载剖析

在 Databricks 上做机器学习性能与成本优化，第一步不是调参数，而是把工作负载拆开看清楚。一个完整的 ML 流水线通常由四类任务组成：特征工程、模型训练、超参数调参、批量推理。它们在计算形态、资源瓶颈、失败代价和计费方式上差异极大，如果混在一起看总账单，几乎无法定位优化点。本节按任务类型逐一剖析其资源消耗特征，并给出成本构成的拆解方法。

四类任务的资源消耗画像

特征工程本质是分布式数据处理，主要消耗 CPU、内存和 I/O，通常对 GPU 无需求。它的瓶颈往往在 shuffle、数据倾斜和 UDF 上。例如用 PySpark 对 2 亿行用户行为日志做窗口聚合，若按 user_id 分区而少数头部用户行为量极大，就会产生长尾 task，集群大部分 executor 空转等待。这类任务的成本几乎全部来自 DBU 与云实例的按秒计费，优化方向是减少 shuffle、用 Photon 加速、把 Python UDF 换成内置函数或 pandas UDF。

模型训练是资源最密集、也最昂贵的环节。它同时吃 CPU（数据加载、预处理）、GPU（前向反向计算）、内存和网络（分布式梯度同步）。训练任务的关键特征是：单次运行时间长、失败重跑代价高、GPU 利用率容易偏低。常见浪费是 GPU 等数据——DataLoader 的 worker 数不足或数据未做缓存，导致昂贵的 GPU 长时间空闲。训练成本 = GPU 实例单价 × 时长 + DBU，因此缩短时长和提升 GPU 利用率是两条主线。

超参数调参是训练的放大版。它把一次训练复制成几十上百次并行或串行试验，成本随试验数线性增长。调参的资源特征与训练相同，但多了调度开销和结果记录开销。若用 Hyperopt 配合 SparkTrials，还要考虑并行度与集群容量的匹配：并行度过高会让每个 trial 分到的资源变少、单次变慢，反而拉长总时长。调参的优化重点是搜索空间设计、早停策略和并行度控制，而不是单纯堆机器。

批量推理通常是四类中最便宜、最容易被忽视的。它多为一次性或周期性的大规模打分，资源消耗以 CPU 和内存为主，GPU 仅在深度模型推理时使用。它的成本特征是短时突发，若用常驻集群跑，空闲时间也在计费。优化方向是使用作业集群、按需拉起、推理完即释放，以及用 Pandas UDF 做向量化批量预测。

成本构成的拆解方法

Databricks 的账单主要由三块组成：DBU 费用、云实例费用（含 GPU）、存储与网络费用。要定位成本，建议按作业维度打标签，把每个 notebook 或 job 的 cluster_id、运行时长、实例类型记录下来，再乘以对应单价。一个实用的做法是在作业配置中统一打上 cost_center 和 task_type 标签，后续用系统表 system.billing.usage 按标签聚合，就能得到每类任务的真实花费。

下面是一份可直接参考的成本归集表结构，字段按 Databricks 计费口径设计，示例数值为合理假设，用于说明填写方式：

从这张表能立刻看出：调参和训练占了绝大部分成本，而特征工程和推理相对便宜。因此优化优先级应放在 GPU 侧，而不是花大量精力去抠 CPU 任务的零头。

资源消耗的三个关键判断指标

要判断一个任务是否浪费，不能只看总时长，而要看三个指标。第一是GPU 利用率，训练期间若长期低于 60%，说明数据供给或 batch 配置有问题。第二是任务长尾比，即最慢 task 耗时与中位数 task 耗时的比值，超过 3 倍通常意味着数据倾斜。第三是有效计算占比，即真正用于前向反向或数据转换的时间占总 wall-clock 时间的比例，其余是启动、shuffle、等待和重试。

按任务类型制定优化策略

特征工程优先做分区键重设计、开启 Photon、用 Delta 的 Z-Order 减少扫描量；训练优先做数据缓存、增大 DataLoader worker、启用混合精度和梯度累积；调参优先做搜索空间收敛、启用早停、把并行度设为集群可容纳 trial 数的整数倍；推理优先改用作业集群、按需拉起、用向量化 UDF 替代逐行预测。四类任务的优化手段不同，但判断依据一致：先量化资源消耗，再定位瓶颈，最后用成本表验证优化效果。