Spark 资源优化为什么不能只看成功率？从执行遥测到分阶段验证
Salesforce Engineering 公开了 Data 360 每日约 800 万次 Spark 工作负载的资源优化方法：在统一提交层采集执行遥测，用完整、可比的运行记录区分闲置资源与可靠性问题，再对单一变量进行分阶段生产验证。该案例说明，成功完成只能证明配置可运行，不能证明资源有效。
事实摘要
- Salesforce 称 Data 360 每天运行约 800 万次 Apache Spark 工作负载，覆盖短任务和处理 TB 级数据的长任务。
- 团队在统一提交网关注入基于 DataFlint 扩展的 Spark 插件，通过监听器采集遥测，经 Kafka 写入集中式 Iceberg 分析层，并把采集失败与客户计算隔离。
- 分析层区分完整运行、重试、缺失测量和工作负载环境，并把驱动与全部执行器 Pod 成本纳入单次 Spark 应用比较。
- 公开案例称，目标工作负载经过分阶段调整后，在匹配的前后四周窗口中每周计算成本运行率下降 31%；Salesforce 明确说明这不是受控实验，其他变化也可能产生影响。
向量纪元分析
- 向量纪元判断：资源优化应先回答指标统计了什么、包含哪些运行、遗漏了什么，再谈缩容；低 CPU 利用率可能来自闲置，也可能来自 Shuffle 或可靠性瓶颈。
- 向量纪元判断：可解释的优化建议必须附 SQL、公式、比较边界和假设，Agent 可以辅助分析，但不能省略工程师对证据的复核。
- 实施建议：选一个昂贵且重复的任务，只改一个资源参数，并连续观察 p95 运行时间、重试、OOM、溢写、失败、Pod/节点压力和成本；公开降本比例不能直接外推到其他环境。
以上为文章中的企业影响判断与实施建议，应用到具体项目时仍需结合现场条件验证。