0588-6.1.0-命令行动态指定MapReduce运行参数无效的问题分析
这期内容当中小编将会给大家带来有关0588-6.1.0-命令行动态指定MapReduce运行参数无效的问题分析，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
1
文档编写目的
在本地完成MapReduce程序的开发后，打包提交到服务器上，然后在命令行使用hadoop jar命令运行，并在运行时动态的指定参数（如：Map和Reduce的内、资源池等参数）。通过在命令行添加"-D mapreduce.job.queuename=资源池名"的方式来指定。本篇文章Fayson主要讲述动态指定MapReduce作业参数无效问题分析。
2
问题描述
Cloudera Manager上资源池放置规则如下：放置规则第一条指定的池不存在时，则自动创建。
在命令行执行如下命令，指定作业到root.test资源池下：
hadoop jar xxx.jar -D mapreduce.job.queuename=root.test
通过上图可以看到，MapReduce作业并未运行在指定的资源池。
3
问题分析
在同一用户下，执行了Hadoop自带的jar，使用同样的方式动态指定资源池，发现任务跑在了指定的资源池下
经上述测试推测可能是自己开发的MapReduce代码的问题，通过对比Hadoop自带的示例代码发现，Hadoop的示例代码中继承了Configured类并实现了Tool接口。而自己写的MapReduce代码如下未继承和实现Hadoop的类。
4
问题解决
在MapReduce代码中添加Configured类的继承并实现了Tool接口。修改后的代码如下：
修改启动类后，再将程序重新打包，运行时指定参数如下：
发现任务成功运行在指定的资源池下：
关于ToolRunner接口的说明：
为什么实现Tool后，动态参数就能生效呢？说到Tool，就不得不提到一个类GenericOptionsParser。该类是Hadoop框架中解析命令行参数的基本类。它能够解析命令行参数，让程序运行时能够动态的指定一些资源上的配置。在上面的代码中可以看到，在main方法中调用了ToolRunner类的run方法。ToolRunner类中的run方法内使用了GenericOptionsParser类来解析命令行参数，最终ToolRunner类的run方法里调用的还是MrDriver类中重写的run方法。见下图源码：
ToolRunner.run方法的参数中看到，传入的tool参数就是我们自己编写的MrDriver类，所以ToolRunner类最终调用了我们自己重写的run方法，并且通过GenericOptionsParser解析命令行参数后将解析的参数Set到Configuration对象中，最终调用MrDriver.run方法实现作业运行参数的动态指定。
5
总结
1.在写MapReduce程序时，应继承Configured类并实现Tool接口，这样在运行jar包时可以动态的指定参数，比在代码中硬编码要灵活很多。
2.当有的参数需要修改时，也不用重新对代码进行打包、编译、部署等操作。
3.不单是资源池相关参数的指定，实现Tool后，配置文件中的其他参数也可以在命令行动态的指定，但一定要注意配置参数不能写错否则不生效。
上述就是小编为大家分享的0588-6.1.0-命令行动态指定MapReduce运行参数无效的问题分析了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注行业资讯频道。
