Hadoop框架自身集成了很多第三方的JAR包库。Hadoop框架自身启动或者在运行用户的MapReduce等应用程序时,会优先查找Hadoop预置的JAR包。这样的话,当用户的应用程序使用的第三方库已经存在于Hadoop框架的预置目录,但是两者的版本不同时,Hadoop会优先为应用程序加载Hadoop自身预置的JAR包,这种情况的结果是往往会导致应用程序无法正常运行。
下面从我们在实践中遇到的一个实际问题出发,剖析Hadoop on YARN 环境下,MapReduce程序运行时JAR包查找的相关原理,并给出解决JAR包冲突的思路和方法。
一、一个JAR包冲突的实例
我的一个MR程序需要使用jackson库1.9.13版本的新接口:
![](https://img-blog.csdn.net/20160302165359455?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
图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个最核心组件的功能及职责,以及它们之间的相互关系等等。
![](https://img-blog.csdn.net/20160302165525971?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
图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,内容如下(可以通过配置文件进行配置,从略):
![](https://img-blog.csdn.net/20160302165704753?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
图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():
![](https://img-blog.csdn.net/20160302165746645?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
首先,会判断userClassesTakesPrecedence,如果设置了这个Flag,那么就不会去调用MRApps.setMRFrameworkClasspath(environment, conf)这个方法。也就是说,如果设置了这个Flag的话,需要用户设置所有的JAR包的CLASSPATH。
下面看setMRFrameworkClasspath()方法:
![](https://img-blog.csdn.net/20160302165813067?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
其中,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这种非以盈利为目的的开源框架。而开源的好处就是,在你困惑的时候,你可以求助源码,自己找到问题的答案。这正如侯捷老师所说的: “源码面前,了无秘密”。