YARN环境中应用程序JAR包冲突问题的分析及解决

Hadoop框架自身集成了不少第三方的JAR包库。Hadoop框架自身启动或者在运行用户的MapReduce等应用程序时，会优先查找Hadoop预置的JAR包。这样的话，当用户的应用程序使用的第三方库已经存在于Hadoop框架的预置目录，可是二者的版本不一样时，Hadoop会优先为应用程序加载Hadoop自身预置的JAR包，这种状况的结果是每每会致使应用程序没法正常运行。

 

下面从咱们在实践中遇到的一个实际问题出发，剖析Hadoop on YARN 环境下，MapReduce程序运行时JAR包查找的相关原理，并给出解决JAR包冲突的思路和方法。

1、一个JAR包冲突的实例

个人一个MR程序须要使用jackson库1.9.13版本的新接口：

图1：MR的pom.xml，依赖jackson的1.9.13

可是个人Hadoop集群(CDH版本的hadoop-2.3.0-cdh5.1.0)预置的jackson版本是1.8.8的，位于Hadoop安装目录下的share/hadoop/mapreduce2/lib/下。

使用以下命令运行个人MR程序时：

hadoop jar mypackage-0.0.1-jar-with-dependencies.jar com.umeng.dp.MainClass --input=../input.pb.lzo --output=/tmp/cuiyang/output/

因为MR程序中使用的JsonNode.asText()方法，是1.9.13版本新加入的，在1.8.8版本中没有，因此报错以下：

…

15/11/13 18:14:33 INFO mapreduce.Job:  map 0% reduce 0%

15/11/13 18:14:40 INFO mapreduce.Job: Task Id : attempt_1444449356029_0022_m_000000_0, Status : FAILED

Error: org.codehaus.jackson.JsonNode.asText()Ljava/lang/String;

…

2、搞清YARN框架执行应用程序的过程

在继续分析如何解决JAR包冲突问题前，咱们须要先搞明白一个很重要的问题，就是用户的MR程序是如何在NodeManager上运行起来的？这是咱们找出JAR包冲突问题的解决方法的关键。

本篇文章不是一篇介绍YARN框架的文章，一些基本的YARN的知识假定你们都已经知道，如ResourceManager(下面简称RM)，NodeManager(下面简称NM)，AppMaster(下面简称AM)，Client，Container这5个最核心组件的功能及职责，以及它们之间的相互关系等等。

 

图2：YARN架构图

 

若是你对YARN的原理不是很了解也没有关系，不会影响下面文章的理解。我对后面的文章会用到的几个关键点知识作一个扼要的总结，明白这些关键点就能够了：

1. 从逻辑角度来讲，Container能够简单地理解为是一个运行Map Task或者Reduce Task的进程(固然了，AM其实也是一个Container，是由RM命令NM运行的)，YARN为了抽象化不一样的框架应用，设计了Container这个通用的概念；

2. Container是由AM向NM发送命令进行启动的；

3. Container实际上是一个由Shell脚本启动的进程，脚本里面会执行Java程序，来运行Map Task或者Reduce Task。

好了，让咱们开始讲解MR程序在NM上运行的过程。

上面说到，Map Task或者Reduce Task是由AM发送到指定NM上，并命令NM运行的。NM收到AM的命令后，会为每一个Container创建一个本地目录，将程序文件及资源文件下载到NM的这个目录中，而后准备运行Task，其实就是准备启动一个Container。NM会为这个Container动态生成一个名字为launch_container.sh的脚本文件，而后执行这个脚本文件。这个文件就是让咱们看清Container究竟是如何运行的关键所在！

脚本内容中和本次问题相关的两行以下：

export CLASSPATH="$HADOOP_CONF_DIR:$HADOOP_COMMON_HOME/share/hadoop/common/*:(...省略…):$PWD/*"

exec /bin/bash -c "$JAVA_HOME/bin/java -D(各类Java参数) org.apache.hadoop.mapred.YarnChild 127.0.0.1 58888 (其余应用参数)"

先看第2行。原来，在YARN运行MapReduce时，每一个Container就是一个普通的Java程序，Main程序入口类是：org.apache.hadoop.mapred.YarnChild。

咱们知道，JVM加载类的时候，会依据CLASSPATH中路径的声明顺序，依次寻找指定的类路径，直到找到第一个目标类即会返回，而不会再继续查找下去。也就是说，若是两个JAR包都有相同的类，那么谁声明在CLASSPATH前面，就会加载谁。这就是咱们解决JAR包冲突的关键！

再看第1行，正好是定义JVM运行时须要的CLASSPATH变量。能够看到，YARN将Hadoop预置JAR包的目录都写在了CLASSPATH的最前面。这样，只要是Hadoop预置的JAR包中包含的类，就都会优先于应用的JAR包中具备相同类路径的类进行加载！

那对于应用中独有的类(即Hadoop没有预置的类)，JVM是如何加载到的呢？看CLASSPATH变量定义的结尾部分："/*:$PWD/*"。也就是说，若是Java类在其余地方都找不到的话，最后会在当前目录查找。

那当前目录到底是什么目录呢？上面提到过，NM在运行Container前，会为Container创建一个单独的目录，而后会将所须要的资源放入这个目录，而后运行程序。这个目录就是存放Container全部相关资源、程序文件的目录，也就是launch_container.sh脚本运行时的当前目录。若是你执行程序的时候，传入了-libjars参数，那么指定的JAR文件，也会被拷贝到这个目录下。这样，JVM就能够经过CLASSPATH变量，查找当前目录下的全部JAR包，因而就能够加载用户自引用的JAR包了。

在个人电脑中运行一次应用时，该目录位于/Users/umeng/worktools/hadoop-2.3.0-cdh5.1.0/ops/tmp/hadoop-umeng/nm-local-dir/usercache/umeng/appcache/application_1444449356029_0023，内容以下(能够经过配置文件进行配置，从略)：

图3：NM中Job运行时的目录 

好了，咱们如今已经知道了为什么YARN老是加载Hadoop预置的class及JAR包，那咱们如何解决这个问题呢？方法就是：看源码！找到动态生成launch_container.sh的地方，看是否能够调整CLASSPATH变量的生成顺序，将Job运行时的当前目录，调整到CLASSPATH的最前面。

3、阅读源码, 解决问题

追溯源码，让咱们深刻其中，透彻一切。

首先想到，虽然launch_container.sh脚本文件是由NM生成的，可是NM只是运行Task的载体，而真正精确控制Container如何运行的，应该是程序的大脑：AppMaster。查看源码，果真验证了咱们的想法：Container的CLASSPATH，是由MRApps(MapReduce的AM)传给NodeManager的，NodeManager再写到sh脚本中。

MRApps中的TaskAttemptImpl::createCommonContainerLaunchContext()方法会建立一个Container，以后这个Container会被序列化后直接传递给NM；这个方法的实现中，调用关系为：createContainerLaunchContext() -> getInitialClasspath()-> MRApps.setClasspath(env, conf)。首先，咱们来看setClasspath()：

首先，会判断userClassesTakesPrecedence，若是设置了这个Flag，那么就不会去调用MRApps.setMRFrameworkClasspath(environment, conf)这个方法。也就是说，若是设置了这个Flag的话，须要用户设置全部的JAR包的CLASSPATH。

下面看setMRFrameworkClasspath()方法：

其中，DEFAULT_YARN_APPLICATION_CLASSPATH里放入了全部Hadoop预置JAR包的目录。可以看到，框架会先用YarnConfiguration.YARN_APPLICATION_CLASSPATH设置的CLASSPATH，若是没有设置，则会使用DEFAULT_YARN_APPLICATION_CLASSPATH。

而后由conf.getStrings()把配置字符串按逗号分隔转化为一个字符串数组；Hadoop遍历该数组，依次调用MRApps.addToEnvironment(environment, Environment.CLASSPATH.name(), c.trim(), conf)设置CLASSPATH。

看到这里，咱们看到了一线曙光：默认状况下，MRApps会使用DEFAULT_YARN_APPLICATION_CLASSPATH做为Task的默认CLASSPATH。若是咱们想改变CLASSPATH，那么看来咱们就须要修改YARN_APPLICATION_CLASSPATH，让这个变量不为空。

因而，咱们在应用程序中加入了以下语句：

String[] classpathArray = config.getStrings(YarnConfiguration.YARN_APPLICATION_CLASSPATH, YarnConfiguration.DEFAULT_YARN_APPLICATION_CLASSPATH);
String cp = "$PWD/*:" +  StringUtils.join(":", classpathArray);
config.set(YarnConfiguration.YARN_APPLICATION_CLASSPATH, cp);

上面的语句意思是：先得到YARN默认的设置DEFAULT_YARN_APPLICATION_CLASSPATH，而后在开头加上Task程序运行的当前目录，而后一块儿设置给YARN_APPLICATION_CLASSPATH变量。这样，MRApps在建立Container时，就会将咱们修改过的、程序当前目录优先的CLASSPATH，做为Container运行时的CLASSPATH。

最后一步，咱们须要将咱们的应用依赖的JAR包，放入到Task运行的目录中，这样加载类的时候，才能加载到咱们真正须要的类。那如何作到呢？对，就是使用-libjars这个参数，这个前面也已经解释过了。这样，运行程序的命令就改成以下：

hadoop jar ./target/mypackage-0.0.1-SNAPSHOT-jar-with-dependencies.jar com.umeng.dp.MainClass-libjars jackson-mapper-asl-1.9.13.jar,jackson-core-asl-1.9.13.jar --input=../input.pb.lzo --output=/tmp/cuiyang/output/

4、结语

本文中，咱们经过分析Hadoop的源代码，解决了咱们遇到的一个JAR包冲突问题。

即便再成熟再完善的文档手册，也不可能涵盖其产品全部的细节以解答用户全部的问题，更况且是Hadoop这种非以盈利为目的的开源框架。而开源的好处就是，在你困惑的时候，你能够求助源码，本身找到问题的答案。这正如侯捷老师所说的: “源码面前，了无秘密”。