AI 开发带来的算力需求增长正在影响 Apache Spark 数据处理管道的可用性。当特定机器族（如 N2 或 N2D）在目标可用区或区域的需求超过可用容量时，会出现计算资源短缺，可能导致集群创建延迟、任务执行失败以及业务 SLA 受损。
据 Google Cloud 介绍，其托管 Apache Spark 服务（Managed Service for Apache Spark）通过引入灵活虚拟机（Flexible VMs）机制来应对这一问题。
灵活虚拟机的核心能力
灵活虚拟机改变了托管 Spark 集群请求计算资源的方式。团队不再将集群绑定到单一实例类型，而是可以为主节点、主要工作节点和次要工作节点分别设定可接受机器族的优先级列表。
该机制支持多机器族混合配置，能够在同一配置中将第二代机器族（如 N2、N2D）与第四代机器族（如 N4、C4）组合使用。存储选项也可根据底层主机族支持的磁盘类型动态调整。这些灵活规则可覆盖主要工作节点、次要（抢占式/Spot）工作节点及主节点。
在实际配置中，Google Cloud 建议最高优先级（Rank 0）列表中至少包含两个机器族。例如，对于标准化使用 n2d-standard-16 规格的生产管道，可将 n2d-standard-16 与 n2-standard-16 同列为首选并搭配标准本地 SSD 或 PD 存储；后续梯队依次纳入 N4、C4 及 E2 系列，并相应切换至 Hyperdisk Balanced 或标准 PD 存储。对于仍在使用旧版 n1 系列的工作负载，也提供了向更新架构过渡的分级策略。
存储与成本考量
充分发挥灵活虚拟机的可用性通常需要采用现代存储架构。较新的实例如 N4 和 C4 依赖 Hyperdisk 在不同 VM 规格下提供可预测的性能。对于大多数分布式 Spark 作业，从默认 IOPS 和吞吐量设置起步通常可提供可靠基线。
采用该机制需要评估几项架构与财务因素：
- 资源配额：企业需确保为灵活虚拟机列表中定义的所有机器类型和磁盘（包括 Hyperdisk）分配了充足的计算与磁盘配额，而非仅关注单一机器族。
- 承诺使用折扣：传统基于资源的承诺使用折扣（CUDs）绑定于特定机器族，限制了灵活性。Compute Flexible CUDs 可将节省额度应用于多个 VM 族和区域。
- 性能差异：不同机器代际之间，以及本地 SSD 与 Hyperdisk 之间的性能表现存在差异。实际结果取决于具体工作负载，需要针对自身 Spark 作业进行测试以评估对 SLA 的影响。
其他可用性优化策略
除灵活虚拟机外，Google Cloud 还提出了多项提升资源可用性与工作负载稳定性的架构和调度策略：
- AutoZone：启用自动可用区路由，让托管 Spark 根据当前容量自动选择最适合执行作业的可用区。
- 较小机器规格：避免使用需求极高的大核心数规格，将工作负载和 YARN 容器设计为利用 4、8 或 16 核等较小规格，这类规格更容易从 GCE 按需池中获取。
- 自动扩缩容：部署集群自动扩缩容并设置合理的 maxInstances，以应对突发或不可预测的工作负载，无需依赖大规模的预先配置。
- 部分集群创建：配置可接受的最小主要工作节点数量，使集群能在资源受限时启动执行，随后由自动扩缩容动态补充剩余节点。
- 区域回退：针对 us-central1 等高需求区域，建立其他区域的回退机制以降低容量短缺风险。