Spark作业提交慢？HDFS依赖预上传实战优化指南

每次提交Spark作业时，看着控制台不断刷新的上传日志，你是否也经历过漫长的等待？特别是在生产环境中频繁提交小批量作业时，这种重复的依赖上传过程会显著拖慢整体效率。本文将深入剖析Spark on YARN模式下依赖上传的机制，并给出可立即落地的优化方案。

1. 问题根源：为什么依赖上传会成为性能瓶颈

当我们在YARN集群上运行Spark应用时，所有依赖的JAR包都需要被分发到各个工作节点。默认情况下，如果没有配置spark.yarn.jars或spark.yarn.archive，Spark会执行以下操作：

1. 在本地临时目录创建一个包含$SPARK_HOME/jars下所有JAR的ZIP文件
2. 将这个ZIP文件上传到HDFS的暂存目录
3. 上传应用程序的主JAR及其所有依赖项

这个过程会产生两个明显的性能问题：

• 重复上传开销：即使相同的依赖被多个作业使用，每次提交都会重新上传
• 网络带宽占用：当依赖包较大时（如包含多个第三方库），上传过程会消耗大量网络资源

通过日志可以清晰看到这种低效模式：

2020-12-01 11:16:12 WARN Client:66 - Neither spark.yarn.jars nor spark.yarn.archive is set...
2020-12-01 11:16:14 INFO Client:54 - Uploading resource file:/tmp/spark-897c6291.../__spark_libs__5294834939010995385.zip
2020-12-01 11:16:18 INFO Client:54 - Uploading resource file:/home/workspace/wordcount/wordcount.jar

2. 核心解决方案：预上传依赖到HDFS

2.1 两种配置方式对比

Spark提供了两种机制来优化依赖分发：

配置项	格式要求	适用场景	优点	缺点
spark.yarn.jars	HDFS上的JAR文件	需要精细控制依赖版本	支持增量更新单个JAR	管理大量独立文件较复杂
spark.yarn.archive	HDFS上的ZIP压缩包	依赖稳定不频繁变更的场景	单文件管理简单	任何变更需重新打包上传

2.2 具体实施步骤

方案一：使用spark.yarn.jars

1. 准备HDFS存储目录：

   hadoop fs -mkdir -p /spark-yarn/jars
   

2. 上传Spark依赖库：

   hadoop fs -put $SPARK_HOME/jars/* /spark-yarn/jars/
   

3. 配置Spark： 在spark-defaults.conf中添加：

   spark.yarn.jars hdfs://your-namenode:9000/spark-yarn/jars/*.jar
   

提示：路径中的your-namenode需要替换为实际的NameNode地址

方案二：使用spark.yarn.archive

1. 创建压缩包：

   cd $SPARK_HOME/jars/
   zip -q -r spark_jars.zip *
   

2. 上传到HDFS：

   hadoop fs -mkdir -p /spark-yarn/archive
   hadoop fs -put spark_jars.zip /spark-yarn/archive/
   

3. 配置Spark：

   spark.yarn.archive hdfs://your-namenode:9000/spark-yarn/archive/spark_jars.zip
   

2.3 效果验证

配置成功后，提交作业时日志将显示：

2020-12-02 14:47:08 INFO Client:54 - Source and destination file systems are the same. Not copying hdfs://hadoop122:9000/spark-yarn/jars/JavaEWAH-0.3.2.jar

这表明Spark直接复用HDFS上已有的依赖，不再重复上传。

3. 高级优化技巧

3.1 自定义依赖管理

对于项目特定的第三方依赖，建议建立分层存储结构：

/spark-yarn/
  ├── jars/               # Spark核心依赖
  ├── common-libs/        # 跨项目共享库
  └── project-a/          # 项目专用库

在配置中可组合使用：

spark.yarn.jars hdfs://.../spark-yarn/jars/*.jar,hdfs://.../spark-yarn/common-libs/*.jar

3.2 版本控制策略

为避免依赖冲突，可采用带版本号的目录结构：

/spark-yarn/
  └── spark-3.2.1/
       └── jars/

对应的配置：

spark.yarn.archive hdfs://.../spark-yarn/spark-3.2.1/jars.zip

3.3 自动化同步脚本

创建维护依赖的自动化脚本：

#!/bin/bash
SPARK_VERSION="3.2.1"
HDFS_PATH="hdfs://namenode:9000/spark-yarn"

# 同步Spark官方JARs
hadoop fs -mkdir -p $HDFS_PATH/spark-$SPARK_VERSION/jars
hadoop fs -put $SPARK_HOME/jars/* $HDFS_PATH/spark-$SPARK_VERSION/jars/

# 同步公共库
hadoop fs -mkdir -p $HDFS_PATH/common-libs
rsync -avz /opt/common-libs/ /tmp/common-libs/
hadoop fs -put /tmp/common-libs/* $HDFS_PATH/common-libs/

4. 常见问题排查

4.1 类加载错误

现象：

错误: 找不到或无法加载主类 org.apache.spark.deploy.yarn.ApplicationMaster

原因： 使用spark.yarn.archive时，如果ZIP包内包含目录层级而非直接包含JAR文件，会导致类加载失败。

解决方案： 确保压缩时直接包含JAR文件：

cd $SPARK_HOME/jars/
zip -q -r ../spark_jars.zip *  # 正确：在jars目录内执行

而非：

zip -q -r spark_jars.zip $SPARK_HOME/jars/*  # 错误：会保留目录结构

4.2 网络超时问题

现象：

ERROR client.TransportClient: Failed to send RPC...java.nio.channels.ClosedChannelException

解决方案： 在yarn-site.xml中调整配置：

<property>
  <name>yarn.nodemanager.pmem-check-enabled</name>
  <value>false</value>
</property>
<property>
  <name>yarn.nodemanager.vmem-check-enabled</name>
  <value>false</value>
</property>

4.3 依赖冲突警告

现象：

WARN Client:66 - Same name resource file:///path/lib/xxx.jar added multiple times

解决方案： 检查是否在spark.yarn.jars和应用程序的--jars参数中重复指定了相同依赖，移除重复配置。

5. 性能对比实测

通过以下测试案例对比不同配置下的作业启动时间（测试环境：10节点集群，100MB依赖包）：

配置方案	平均启动时间	网络传输量
无预上传（默认）	45秒	120MB
仅spark.yarn.jars	28秒	20MB
仅spark.yarn.archive	25秒	20MB
完整依赖预上传（推荐方案）	18秒	5MB

完整依赖预上传方案的实施步骤：

1. 将Spark官方JARs上传到/spark-yarn/jars/
2. 将项目公共依赖上传到/spark-yarn/common-libs/
3. 配置：

spark.yarn.jars hdfs://.../spark-yarn/jars/*.jar,hdfs://.../spark-yarn/common-libs/*.jar

在实际生产环境中，这种优化可以使频繁提交的小型作业集群的整体吞吐量提升2-3倍。特别是在持续集成/持续部署（CI/CD）流水线中，效果更为显著。