Spark推测任务配置对流式作业性能影响及使用最佳实践咨询

你这套推测执行参数配置偏激进，直接用在Kafka Source + repartition产生200个任务的流式场景下，大概率会带来负面性能影响，极端情况会导致集群资源打满、作业延迟飙升，具体影响分正反两方面：

• 负面冲击是主要的：
  • 你设置的spark.speculation.interval=1000也就是每1秒就扫描一次全量运行中任务判断是否需要拉起备份副本，这个频率对于流式作业来说太高了。Driver本身要处理Kafka位点提交、任务调度、状态元数据管理、shuffle元数据同步等核心逻辑，每秒一次的全量任务扫描会额外消耗Driver的CPU和内存，很容易先把Driver打成瓶颈。
  • 你当前设的spark.speculation.quantile=0.75+spark.speculation.multiplier=2阈值太敏感：只要同批次75%的任务跑完，剩下任务耗时达到已完成任务中位数的2倍就会触发推测。但流式作业里绝大多数慢任务不是节点硬件故障导致的，只是单批次某分区数据量稍高、节点临时GC、磁盘IO偶发波动，这种场景下拉起的备份任务会和原任务抢CPU、网络、磁盘IO资源，本来原任务可能等几秒就跑完，结果两个任务抢资源反而把整体批次处理时间拉长，还会额外产生重复的shuffle读写、Kafka拉取开销。
  • 额外提一句非性能但影响业务的问题：如果你的下游写入没做幂等、没开事务，推测任务和原任务同时计算写入，会直接导致下游数据重复。
• 正向收益只在特定场景存在：如果你的集群经常出现节点磁盘掉盘、网络闪断、个别Executor僵死导致任务长时间卡死的情况，合理配置的推测执行确实能避免单个任务拖垮整个批次SLA，不会出现单任务卡几十分钟导致全量数据积压的问题。

推测执行本质是个兜底机制，不是性能优化手段，用的时候要遵循几个原则，别上来就套默认配置：

• 先查根因再开，不要靠推测执行掩盖逻辑问题：如果慢任务是数据倾斜、shuffle分区数设置不合理、代码存在计算热点、Executor内存不足频繁Full GC导致的，先把这些问题解决了再考虑开推测。推测执行只能解决「硬件/资源临时波动、个别任务异常卡死」的问题，解决不了代码和资源配置本身的缺陷。像你用repartition()产生200个任务的场景，本身repartition是轮询发数据，正常情况下每个任务数据量差不了太多，如果频繁出慢任务，先查是不是上游数据倾斜太严重，导致个别repartition后的任务分到的数据量是其他任务的好几倍，这种情况开推测纯浪费资源。
• 流式场景不要用激进参数，优先走保守配置，稳定性比你现在的参数高很多：

  .set("spark.speculation", "true")
  .set("spark.speculation.interval", "10000") // 检查间隔拉长到10秒，降低Driver额外开销
  .set("spark.speculation.multiplier", "3") // 慢任务阈值提到中位数耗时的3倍，减少误判
  .set("spark.speculation.quantile", "0.9") // 等90%的任务完成后再判定慢任务，不要75%就触发
  .set("spark.speculation.minTaskRuntime", "30000") // 补充这个参数，运行不足30秒的短任务不触发推测，避免任务刚启动就被判定为慢
  

• 留足资源冗余：开推测执行的作业，给Executor预留20%-30%的CPU、内存冗余，不要把集群资源占满。不然拉起的推测任务没资源可调度，排队等资源的过程中根本起不到兜底作用，反而会挤占其他正常任务的资源。
• 做好数据一致性兜底：只要开推测执行，下游写入必须支持幂等（比如靠业务主键去重、覆盖写），或者开启Structured Streaming/Spark Streaming的事务写入机制，避免原任务和推测任务同时写导致重复数据。
• 配套监控动态调整：重点盯两个核心指标，一是推测启动的任务数占总任务数的比例，如果这个比例长期高于5%，说明不是节点波动的问题，是作业本身存在逻辑瓶颈，赶紧回头查代码和资源配置；二是推测任务的成功率，如果绝大多数推测任务都比原任务晚完成，说明参数设的太敏感，白耗资源，要往保守方向调。
• 这些场景直接别开：如果作业是单Executor部署、集群整体资源利用率长期在90%以上没冗余、下游不支持幂等/事务写入，直接关推测，收益远小于风险。

内容的提问来源于stack exchange，提问作者Shane