YARN环境中应用程序JAR包冲突问题的分析及解决
Hadoop框架自身集成了很多第三方的JAR包库。Hadoop框架自身启动或者在运行用户的MapReduce等应用程序时，会优先查找Hadoop预置的JAR包。这样的话，当用户的应用程序使用的第三方库已经存在于Hadoop框架的预置目录，但是两者的版本不同时，Hadoop会优先为应用程序加载Hadoop自身预置的JAR包，这种情况的结果是往往会导致应用程序无法正常运行。
下面从我们在实践中遇到的一个实际问题出发，剖析Hadoop on YARN 环境下，MapReduce程序运行时JAR包查找的相关原理，并给出解决JAR包冲突的思路和方法。
一、一个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;
…
二、搞清YARN框架执行应用程序的过程
在继续分析如何解决JAR包冲突问题前，我们需要先搞明白一个很重要的问题，就是用户的MR程序是如何在NodeManager上运行起来的？这是我们找出JAR包冲突问题的解决方法的关键。
本篇文章不是一篇介绍YARN框架的文章，一些基本的YARN的知识假定大家都已经知道，如ResourceManager(下面简称RM)，NodeManager(下面简称NM)，AppMaster(下面简称AM)，Client，Container这5个最核心组件的功能及职责，以及它们之间的相互关系等等。
图2：YARN架构图
如果你对YARN的原理不是很了解也没有关系，不会影响下面文章的理解。我对后面的文章会用到的几个关键点知识做一个扼要的总结，明白这些关键点就可以了：
-
从逻辑角度来说，Container可以简单地理解为是一个运行Map Task或者Reduce Task的进程(当然了，AM其实也是一个Container，是由RM命令NM运行的)，YARN为了抽象化不同的框架应用，设计了Container这个通用的概念；
-
Container是由AM向NM发送命令进行启动的；
-
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的最前面。
三、阅读源码, 解决问题
追溯源码，让我们深入其中，透彻一切。
首先想到，虽然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/
四、结语
本文中，我们通过分析Hadoop的源代码，解决了我们遇到的一个JAR包冲突问题。
即使再成熟再完善的文档手册，也不可能涵盖其产品所有的细节以解答用户所有的问题，更何况是Hadoop这种非以盈利为目的的开源框架。而开源的好处就是，在你困惑的时候，你可以求助源码，自己找到问题的答案。这正如侯捷老师所说的: “源码面前，了无秘密”。
