引言

在使用Apache Spark进行大规模数据处理时，性能问题常常是开发者和运维人员关注的重点。最近，我们在处理Spark聚合作业时遇到了一个性能瓶颈：预计5分钟内完成的作业实际需要30到40分钟。这篇博客将详细探讨我们遇到的问题、诊断过程以及最终解决方案。

问题描述

我们的Spark聚合作业在Google Cloud的Dataproc集群上运行，日志显示作业在尝试扫描中间完成目录（intermediate done dir），导致执行时间大大延长。即使Spark UI显示作业本身执行较快，但总体时间却被延迟了。

诊断过程

首先，我们检查了Spark UI和Dataproc的云日志，发现作业确实是在等待某些操作完成。以下是我们的诊断步骤：

1. 查看YARN日志：

   yarn logs -applicationId application_1700468925211_1632269
   

   然而，在YARN日志中没有找到与云日志中相同的错误信息。

2. 分析JobHistory Server：
   通过阅读相关文章和JIRA，我们发现这个问题可能与JobHistory Server有关，它在循环扫描目录，导致性能下降。

3. 检查配置文件：
   我们查看了mapred-site.xml文件，找到了以下与GCS桶位置相关的属性：

   <property>
       <name>mapreduce.jobhistory.done-dir</name>
       <value>gs://your-bucket/path/to/done-dir</value>
   </property>
   <property>
       <name>mapreduce.jobhistory.intermediate-done-dir</name>
       <value>gs://your-bucket/path/to/intermediate-done-dir</value>
   </property>
   

4. 特别注意的配置：

   <property>
       <name>mapreduce.jobhistory.always-scan-user-dir</name>
       <value>true</value>
       <description>Enable history server to always scan user dir.</description>
   </property>
   <property>
       <name>mapreduce.jobhistory.recovery.enable</name>
       <value>true</value>
       <description>Enable history server to recover server state on startup.</description>
   </property>
   

解决方案

经过讨论和实验，我们决定尝试修改配置文件中的mapreduce.jobhistory.always-scan-user-dir属性：

1. 登录到主节点：

   ssh your-username@your-master-node
   

2. 修改配置文件：

   cd /etc/hadoop/conf/
   sudo vi mapred-site.xml
   

   将mapreduce.jobhistory.always-scan-user-dir的值从true改为false。

3. 重启Dataproc集群：
   取消所有正在运行的作业，然后停止并重启Dataproc集群。

结果

修改后，我们再次运行了相同的Spark作业，执行时间显著缩短，符合预期的5分钟内完成。此次调整虽然解决了问题，但我们仍然对问题的根本原因和是否适用于其他集群持保留态度。

结论

通过调整JobHistory Server的配置，我们成功解决了Spark聚合作业的性能问题。然而，这只是一个特定的解决方案，在实际生产环境中，需要更多地了解每个集群的具体配置和需求。建议在进行类似修改时，首先在测试环境中进行验证，确保不会对生产环境造成不必要的影响。