Dataproc Spark作业执行超时：中间完成目录扫描问题咨询

一、如何在Cloud Logging中找到对应日志 #

你可以通过Google Cloud Console的Cloud Logging界面，使用以下过滤规则定位JobHistory Server的扫描日志：

• 基础过滤条件：

  resource.type="cloud_dataproc_cluster" 
  AND resource.labels.cluster_name="你的集群名称" 
  AND logName="projects/你的项目ID/logs/dataproc.googleapis.com%2Fjob_history_server"
  

• 结合作业ID缩小范围，添加：

  AND jsonPayload.applicationId="application_1700468925211_1632269"
  

另外，也可以在Cloud Logging的日志浏览器中，选择对应的Dataproc集群资源，然后筛选日志来源为job_history_server，就能找到反复出现的目录扫描日志。

二、调整JobHistory Server配置能否解决问题？ #

配置调整的合理性 #

你提到的mapreduce.jobhistory.always-scan-user-dir和mapreduce.jobhistory.recovery.enable两个配置，正是触发JobHistory Server循环扫描目录的关键：

• mapreduce.jobhistory.always-scan-user-dir=true：会让JobHistory Server在启动或恢复时，扫描所有用户的作业完成目录，当GCS桶中存储的历史作业文件量很大时，这个扫描过程会持续很久。
• mapreduce.jobhistory.recovery.enable=true：开启后JobHistory Server会定期扫描中间完成目录，反复的扫描操作会占用大量资源，阻塞正常作业流程。

将这两个配置设为false，是针对这类目录扫描阻塞问题的直接修复方案，对应Apache社区记录的JobHistory Server扫描性能问题。

生产环境操作建议 #

由于无法在低环境复现，建议按以下步骤谨慎操作：

1. 备份当前配置：先导出集群的mapred-site.xml配置文件，留作回滚依据。
2. 分步调整测试：
   • 先仅修改mapreduce.jobhistory.always-scan-user-dir=false，这个配置仅在JobHistory Server启动时生效，影响范围较小。修改后重启JobHistory Server服务（执行sudo systemctl restart mapreduce-historyserver）。
   • 观察1-2个作业的执行耗时，同时检查Cloud Logging是否还有目录扫描的重复日志。如果耗时有所改善，再考虑修改mapreduce.jobhistory.recovery.enable=false。
3. 临时集群验证（可选）：如果有条件，创建一个与生产集群配置一致的临时集群，复制生产环境GCS桶中的作业历史数据，先在临时集群调整配置并测试，确认效果后再应用到生产。
4. 清理历史数据：无论是否调整配置，建议定期清理GCS桶中过期的作业历史文件，减少扫描的文件数量，从根源降低扫描耗时。

内容的提问来源于stack exchange，提问作者Vikrant Singh Rana