spark on yarn作业运行的jar包缓存优化

最新推荐文章于 2025-05-14 09:04:13 发布

转载最新推荐文章于 2025-05-14 09:04:13 发布 · 1.7k 阅读

文章标签：

#spark #hadoop #缓存 #yarn #jar

Spark学习之路专栏收录该内容

13 篇文章

订阅专栏

本文探讨了Spark on YARN环境下Jar包的缓存及清理问题，包括HDFS上和NodeManager节点上的处理方法。通过对Spark配置和YARN参数的调整，实现了自动清理遗留的Jar包。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

原文地址

参考自下文

这几天一直在追查spark on yarn的作业运行中的jar包分发，以及执行后的jar包删除的问题。从一开始的毫无头绪，到后来逐渐清晰，到后来通过hadoop的两个很简单的参数配置解决了问题。不得不说，虽然问题不大，对某些大牛们来说也真是小case，但是追查问题，定位问题到最终解决问题的过程，对我来说真是很不错的体验和学习过程。下面详细描述一下遇到的问题，以及解决的过程，给后面的同学一点参考。
BTW，很多时候定位问题，查清楚问题的原因，比解决这个”问题“要更重要。

问题描述

Spark版本是1.0.2，运行在cdh5.1.0-hadoop2.3.0版本的yarn上面。在每次提交作业执行之后，在我的HDFS的${yarn.app.mapreduce.am.staging-dir}/${username}/.sparkStaging下面，就会产生两个jar包，一个是spark-assembly-*.jar，另一个是提交执行的jar包。同时，在这个作业对应的executor的节点上，${yarn.nodemanager.local-dirs}目录下，也会有这两个jar包。而且不会被删除。

光spark-assembly*.jar就有一百多M，每次执行完都会留下这么多jar包，虽然不大，但可想而知，日积月累，可是个很麻烦的事情。所以，要搞清楚为啥会出现这个情况。

这个问题可以拆分成两个sub-task，一个是HDFS上的jar包为啥不会自动删除，一个是nodemanager节点上的jar包的自动删除。下面分别排查和解决：

HDFS上的jar包缓存

网上貌似很少有相关资料，就是找到了一个介绍如何配置spark.yarn.jar的文章，说是可以解决HDFS上的jar包缓存的问题。照着配置了一下，不起作用，又看作者说，要spark1.1.0以上的版本，所以重新编译了spark1.1.0，把集群的spark1.0.2升级到1.1.0。重新配置spark.yarn.jar，发现问题解决了。HDFS上仍然在每次提交作业时都会被上传两个jar包，但是用完后会自动删除。

配置方法

（1）首先需要确保spark在1.1.0以上的版本。

（2）在HDFS上建立一个公共lib库，比如/system/spark-lib/，设置权限为755。把spark-assembly-*.jar上传到公共lib库中。

（3）在spark-env.sh中配置:

spark.yarn.jar                          hdfs://yarncluster/system/spark_lib/spark-assembly-1.1.0-hadoop2.3.0-cdh5.1.0.jar  
spark.yarn.preserve.staging.files       false

spark.yarn.jar配置成HDFS上的公共lib库中的jar包。这个配置项会使提交job时，不是从本地上传spark-assembly*.jar包，而是从HDFS的一个目录复制到另一个目录（不确定HDFS上的复制是怎么操作的），总的来说节省了一点时间。（网上有的文章里说，这里的配置，会节省掉上传jar包的步骤，其实是不对的，只是把从本地上传的步骤改成了在HDFS上的复制操作。）
spark.yarn.preserve.staging.files：这个配置项配置成false，表示在执行结束后，不保留staging
files，也就是两个jar包。然后HDFS上的.sparkStaging下的两个jar包在作业执行完成后就会被删除。如果配置成true，执行完后HDFS上的.sparkStaging下两个jar包都会保存下来。

然后再运行，发现HDFS上.sparkStaging目录下不会再保留jar包。

问题定位

按道理来说，因为spark.yarn.preserve.staging.files默认是false，所以HDFS上的jar包是不会被保留的。但是在spark1.0.2中，却没有删除。我看了下1.0.2的代码，删除的机制是存在的：

//yarn/alpha/src/main/Scala/org/apache/spark/deploy/yarn/ApplicationMaster.scala 
/** 
   * Clean up the staging directory. 
   */  
  private def cleanupStagingDir() {  
    var stagingDirPath: Path = null  
    try {  
      val preserveFiles = sparkConf.get("spark.yarn.preserve.staging.files", "false").toBoolean  
      if (!preserveFiles) {  
        stagingDirPath = new Path(System.getenv("SPARK_YARN_STAGING_DIR"))  
        if (stagingDirPath == null) {  
          logError("Staging directory is null")  
          return  
        }  
        logInfo("Deleting staging directory " + stagingDirPath)  
        fs.delete(stagingDirPath, true)  
      }  
    } catch {  
      case ioe: IOException =>  
        logError("Failed to cleanup staging dir " + stagingDirPath, ioe)  
    }  
  }

按照这个逻辑，默认在AM关闭的时候，是会删除HDFS上的jar包的。不过没有正常删除。推测这应该是一个1.0.2里面的bug，而在1.1.0里面已经修复。

nodemanager节点上的jar包缓存

升级到1.1.0版本后，HDFS上的jar包问题就解决了。但是nodemanager节点上的jar包还是会保留。这个问题的定位很纠结，不过结果却出乎意料的简单。不说了，上结果吧。

配置方法

（1）配置yarn-site.xml:

<property>
    <name>yarn.nodemanager.local-dirs</name>
    <value>local-dir1, local-dir2,local-dir3</value>
</property>
<property>
    <name>yarn.nodemanager.localizer.cache.target-size-mb</name>
    <value>1024</value>
</property>
<property>
    <name>yarn.nodemanager.localizer.cache.cleanup.interval-ms</name>
    <value>1800000</value>
</property>

yarn.nodemanager.local-dirs:
这个目录是nodemanager上的作业中间数据存放路径。推荐配置多个盘上的多个路径，从而分散作业执行中的磁盘IO压力。
yarn.nodemanager.localizer.cache.target-size-mb：配置nodemanager上的缓存目录的最大限度。nodemanager上有一个deletion
server服务，会定期检测，如果yarn.nodemanager.local-dirs中配置的目录大小（如果配置了多个，则计算多个目录的总大小）是否超过了这里设置的最大限度值。如果超过了，就删除一些已经执行完的Container的缓存数据。
yarn.nodemanager.localizer.cache.cleanup.interval-ms: deletion
server多长时间做一次检测，并且清除缓存目录直到目录大小低于target-size-mb的配置。

因为spark提交作业后遗留在nodemanager上的jar包就在yarn.nodemanager.local-dirs下面，所以只要这里配置合适的大小值。那么nodemanager上的deletion server是会自动检测并保证目录总大小的。所以只要配置了这个量，我们就不需要再担心nodemanager上的jar包缓存问题了，交给yarn就好了！很简单啊有木有，可就这么个问题，居然花了我一个星期的时间去定位。

通过上面这三个量的配置，nodemanager会确保本地的缓存数据总量在target-size-mb之下，也就是超过了的话，之前的spark的jar包就会被删除。所以我们就不需要再担心nodemanager节点上的spark jar包缓存问题了。不过target-size-mb的默认值是10G，这个值当然可以根据你的实际情况进行调整。

问题定位

为什么mapreduce提交的任务在执行完后，会自动删除nodemanager上的所有中间文件，而spark却不会呢？

查看了下Hadoop的源码（相关代码就不贴出来了），MapReduce提交作业的时候，中间数据是以application file对象的方式被处理的，也就是在nodemanager上是存放在username/appcache/目录下的，而按照yarn的处理机制，application file是专门存放中间数据的对象，所以MapReduce作业的所有中间数据在作业执行完后会被yarn删除。

而spark on yarn的任务提交后，两个jar包却是以yarn的分布式缓存（distributed cache）的方式存放和处理的。Distributed Cache是yarn提供给用户用来分发和管理作业执行中用到的extra file的处理机制。spark没有调用yarn的application file对象，却提交成distributed cache类型，不知道为什么。不过这就是jar包最终没有被自动删除的原因。

下面是MapReduce任务提交后nm上分发中间文件的日志：

这里写图片描述

可以看到中间文件都被下载到appcache的目录下。

再看看spark任务提交后nm上分发jar包的日志：
这里写图片描述

很明显jar包被存放在filecache目录下。也就是它是作为distributed cache的方式分发到nm上的。不知道为什么spark采用这样的设计方式。file cache在作业结束后，是不会主动被删除的。

就是这样了，这个问题其实根本也算不上一个问题。也就是一个深入学习spark on yarn的架构和解惑的过程。

更新：

spark采用file cache而不是application cache的原因，是因为spark在每个NM上启动的是一个executor，每个task作为executor里的一个线程在运行。而只需要在executor启动时，在这个节点上用file cache机制分发一次jar包，然后在每个task执行时，能共享到通过file cache传过来的jar包。所以采用file cache机制的原因，是要在task之间共享jar包。