基于作业大小因素，MRAppMaster提供了三种作业运行方式：本地Local模式、Uber模式、Non-Uber模式。其中，

1、本地Local模式：通常用于调试；

2、Uber模式：为降低小作业延迟而设计的一种模式，所有任务，不管是Map Task，还是Reduce Task，均在同一个Container中顺序执行，这个Container其实也是MRAppMaster所在Container；

3、Non-Uber模式：对于运行时间较长的大作业，先为Map Task申请资源，当Map Task运行完成数目达到一定比例后再为Reduce Task申请资源。

在Yarn中，作业运行的资源，统一被抽象为容器Container，在MRAppMaster中关于作业运行时需要的资源的分配与加载代码中，容器分配申请服务、容器分配完成后加载服务中，都有关于Uber模式和Non-Uber模式的处理，如下：

1、容器分配申请路由服务

容器分配申请路由服务ContainerAllocatorRouter继承自AbstractService，是Hadoop中一个典型的服务，其正常提供服务需要经历初始化init、启动start等过程，而在服务启动的serviceStart()方法中，存在以下关于Uber模式和Non-Uber模式的处理：

  1. // 如果Job在Uber模式下运行，启动构造容器分配器LocalContainerAllocator实例
  2. if (job.isUber()) {
  3. MRApps.setupDistributedCacheLocal(getConfig());
  4. this.containerAllocator = new LocalContainerAllocator(
  5. this.clientService, this.context, nmHost, nmPort, nmHttpPort
  6. , containerID);
  7. } else {
  8. / 否则构造RM容器分配器RMContainerAllocator实例
  9. this.containerAllocator = new RMContainerAllocator(
  10. this.clientService, this.context);
  11. }

可见，如果Job在Uber模式下运行，启动构造容器分配器LocalContainerAllocator实例，否则构造RM容器分配器RMContainerAllocator实例。而LocalContainerAllocator代表的是本地容器分配器，其构造过程中传入的containerID为MRAppMaster的成员变量containerID，什么意思呢？不就正好说明LocalContainerAllocator所使用的容器，也就是Uber模式下所使用的容器，就是MRAppMaster所在Container，与上面所介绍的Uber模式正好一致，而Non-Uber模式下则需要使用Yarn的RMContainerAllocator，通过与ResourceManager进行通信来申请容器的分配，总的原则就是：先为Map Task申请资源，当Map Task运行完成数目达到一定比例后再为Reduce Task申请资源。

2、容器加载路由服务

容器加载路由服务ContainerLauncherRouter同样继承自AbstractService，也是Hadoop中一个典型的服务，我们同样看下服务启动serviceStart()方法，如下：

  1. // 如果Job在Uber模式下运行，启动构造本地容器加载器LocalContainerLauncher实例
  2. if (job.isUber()) {
  3. this.containerLauncher = new LocalContainerLauncher(context,
  4. (TaskUmbilicalProtocol) taskAttemptListener);
  5. } else {
  6. / 否则，构造容器加载器ContainerLauncherImpl实例
  7. this.containerLauncher = new ContainerLauncherImpl(context);
  8. }

也是针对Uber模式和Non-Uber模式分别处理，如果Job在Uber模式下运行，启动构造本地容器加载器LocalContainerLauncher实例；否则，构造容器加载器ContainerLauncherImpl实例。

另外，由于Uber模式下不管是Map Task，还是Reduce Task，均在同一个Container中顺序执行，所以MapReduce的推测执行机制对于Uber模式是不适用的，故在MRAppMaster服务启动的serviceStart()方法中，对于Uber模式，会禁用推测执行机制，相关代码如下：

  1. if (job.isUber()) {
  2. / Uber模式下禁用推测执行机制，即Disable Speculation
  3. speculatorEventDispatcher.disableSpeculation();
  4. LOG.info("MRAppMaster uberizing job " + job.getID()
  5. + " in local container (\"uber-AM\") on node "
  6. + nmHost + ":" + nmPort + ".");
  7. } else {
  8. // send init to speculator only for non-uber jobs.
  9. // This won't yet start as dispatcher isn't started yet.
  10. / Non-Uber模式下发送SpeculatorEvent事件，初始化speculator
  11. dispatcher.getEventHandler().handle(
  12. new SpeculatorEvent(job.getID(), clock.getTime()));
  13. LOG.info("MRAppMaster launching normal, non-uberized, multi-container "
  14. + "job " + job.getID() + ".");
  15. }

可以看到，Uber模式下禁用推测执行机制，即Disable Speculation，Non-Uber模式下发送SpeculatorEvent事件，初始化speculator，因此，对于Uber模式，会禁用推测执行机制。

在作业的抽象实现JobImpl中，会针对Uber模式进行一些特定参数设置，如下：

  1. if (isUber) {
  2. LOG.info("Uberizing job " + jobId + ": " + numMapTasks + "m+"
  3. + numReduceTasks + "r tasks (" + dataInputLength
  4. + " input bytes) will run sequentially on single node.");
  5. // make sure reduces are scheduled only after all map are completed
  6. // mapreduce.job.reduce.slowstart.completedmaps参数设置为1，
  7. // 即全部Map任务完成后才会为Reduce任务分配资源
  8. conf.setFloat(MRJobConfig.COMPLETED_MAPS_FOR_REDUCE_SLOWSTART,
  9. 1.0f);
  10. // uber-subtask attempts all get launched on same node; if one fails,
  11. // probably should retry elsewhere, i.e., move entire uber-AM:  ergo,
  12. // limit attempts to 1 (or at most 2?  probably not...)
  13. // 参数mapreduce.map.maxattempts、mapreduce.reduce.maxattempts设置为1，即Map、Reduce任务的最大尝试次数均为1
  14. conf.setInt(MRJobConfig.MAP_MAX_ATTEMPTS, 1);
  15. conf.setInt(MRJobConfig.REDUCE_MAX_ATTEMPTS, 1);
  16. // disable speculation
  17. // 参数mapreduce.map.speculative、mapreduce.reduce.speculative设置为false，即禁用Map、Reduce任务的推测执行机制
  18. conf.setBoolean(MRJobConfig.MAP_SPECULATIVE, false);
  19. conf.setBoolean(MRJobConfig.REDUCE_SPECULATIVE, false);
  20. }

主要包括：

1、mapreduce.job.reduce.slowstart.completedmaps参数设置为1，即全部Map任务完成后才会为Reduce任务分配资源；

2、参数mapreduce.map.maxattempts、mapreduce.reduce.maxattempts设置为1，即Map、Reduce任务的最大尝试次数均为1；

3、参数mapreduce.map.speculative、mapreduce.reduce.speculative设置为false，即禁用Map、Reduce任务的推测执行机制；

最新文章

  1. EF Codefirst 多对多关系 操作中间表的 增删改查（CRUD）
  2. 一次 surface pro 3 的售后保修 黑色三月维权（HSD）
  3. iOS开发～CocoaPods使用详细说明【转】
  4. Google地图接口API之Google地图 API 参考手册(七)
  5. hdu 2528 Area
  6. 《算法导论》习题解答 Chapter 22.1-7（关联矩阵的性质）
  7. mysql快速上手3
  8. Qt5 FOR WINCE7, Visual Studio 2008环境的搭建
  9. UITableView 之 点击cell 实现两个自定义cell之间的切换
  10. HTTP与HTTPS介绍
  11. Mock8 moco框架如何返回一个cookie信息
  12. php编程 之php基础 表单
  13. Mac NVM 配置
  14. C++中的const成员函数（函数声明后加const，或称常量成员函数）用法详解
  15. JS两日期相减
  16. VMWare------安装时出现无法将值写入注册表项
  17. 在SSH框架中，如何得到POST请求的URL和参数列表
  18. cf 557D 二分图黑白染色
  19. 各种 Java Thread State【转载】
  20. 9th 学习博客：使用Codebloks实现C++的图形化界面

热门文章

  1. NOIP模拟赛[补档]
  2. Java高级架构师（一）第03节：多模块多Web应用合并War包
  3. ios 多线程之NSThread篇举例详解
  4. vue中的组件，Component元素，自定义路由，异步数据获取
  5. 怎么在windows7系统我的电脑中添加快捷方式
  6. python 未发现数据源名称并且未指定默认驱动程序
  7. HTTP——HTTP 1.1的详细介绍 Gunicorn不支持HTTP 1.1
  8. Linux——解决RedHat6/CentOS6系统中“弹出界面eth0:设备似乎不存在”的问题
  9. react 的死循环
  10. Grow heap (frag case) to 6.437MB for 1114126-byte allocation