2. 平台资源规划与成本性能权衡

在 Azure 数据与 AI 平台上，资源规划的核心不是“把配置调到最高”，而是在明确工作负载特征之后，找到性能与成本之间的最优平衡点。同一套 Spark 作业、同一套推理服务，放在不同 SKU、不同缩放策略和不同计费模式下，月成本可能相差数倍，而性能差异却未必同样显著。本章围绕四个相互关联的决策展开：SKU 选型、自动缩放配置、预留实例与 Spot 实例策略，并给出可落地的判断依据与配置示例。

一、先识别工作负载特征，再谈选型

SKU 选型的起点是工作负载画像，而不是价格表。可以从四个维度刻画：

• 计算形态：是 CPU 密集（如数据清洗、ETL）、内存密集（如大表 Join、特征工程），还是 GPU 密集（如模型训练、批量推理）。
• 时延要求：交互式查询要求秒级响应，批处理可容忍分钟级甚至小时级。
• 运行模式：是 7×24 常驻服务，还是每天固定时段运行的批作业，或是突发性任务。
• 可中断性：任务被中断后能否从检查点恢复，决定了能否使用 Spot 实例。

以 Azure Databricks 为例，内存密集型的 Spark 作业通常选择 E 系列（内存优化），CPU 密集型 ETL 选择 D 系列（通用），GPU 训练选择 NC/ND 系列。选型时优先看每 vCPU 内存比和本地 SSD 吞吐，而不是单纯比较核数。一个常见误区是：为提升性能盲目增加节点数，但作业瓶颈其实在单节点内存不足导致的频繁溢写（spill），此时升级 SKU 比横向扩容更有效。

二、自动缩放：让容量跟随负载而非峰值

自动缩放的价值在于削峰填谷。以 Databricks 集群为例，配置 min_workers 与 max_workers 时，应让 min 覆盖基线负载，max 覆盖可接受的峰值，而不是把 max 设成理论最大值。缩放策略需要关注两个参数：扩容触发条件和缩容延迟。缩容过快会导致任务抖动，过慢则浪费成本。

# Databricks 集群自动缩放配置示例（教学示例参数）
autoscale:
  min_workers: 2
  max_workers: 12
  target_workers: 6          # 期望稳定运行节点数
  scale_up_cooldown: 120s    # 扩容冷却，避免频繁抖动
  scale_down_cooldown: 300s  # 缩容冷却，给任务留出完成窗口
node_type_id: Standard_E8s_v3  # 内存优化，适合大表 Join

判断自动缩放是否合理，可以观察三个信号：集群利用率长期低于 30% 说明 min 偏高；频繁触达 max 且任务排队说明 max 偏低或 SKU 不足；节点数在短时间内反复上下波动，说明冷却时间设置过短。自动缩放不是“设完就不管”，需要结合监控指标持续调优。

三、预留实例与 Spot 实例：用确定性换折扣

预留实例（Reserved Instance）适合长期稳定运行的基线负载，通常可节省 30%～60% 的成本，代价是承诺 1 年或 3 年。Spot 实例适合可中断、可重试的批处理任务，折扣可达 60%～90%，但可能随时被回收。两者不是互斥的，而是分层使用：

• 基线层：用预留实例覆盖 7×24 常驻服务或每日固定批作业的稳定部分。
• 弹性层：用按需实例应对不可预测的峰值。
• 容错层：用 Spot 实例运行可重试的 Spark 任务、批量推理、数据回填。

使用 Spot 实例的前提是任务具备检查点与重试机制。例如 Spark 作业开启 spark.speculation 并配置合理的重试次数，被回收后能从最近检查点恢复。对于不允许中断的在线推理服务，不应使用 Spot。

四、成本性能权衡的决策路径

把上述决策串起来，可以形成一条清晰的判断路径：先判断工作负载是否可中断，再判断运行时长是否稳定，最后结合时延要求选择 SKU 与缩放策略。下图展示了这一决策关系与各分支对应的成本优化手段。

五、用监控指标验证权衡是否成立

决策之后必须验证。建议持续跟踪以下指标：集群利用率（低于 30% 考虑缩容或降配）、任务排队时长（持续增长说明容量不足）、Spot 回收率（过高说明任务不适合 Spot）、单位任务成本（总成本 ÷ 成功任务数）。其中单位任务成本是最能反映“性能与成本平衡”的复合指标：如果升级 SKU 后单任务耗时下降 40%，而成本只上升 20%，那么这次选型调整就是划算的。

资源规划不是一次性动作，而是一个“画像—选型—配置—监控—调优”的循环。工作负载会随业务变化，SKU 和计费策略也需要定期复核。把单位任务成本作为核心指标，结合利用率与排队时长，才能在性能与成本之间保持可持续的平衡。