Hadoop之MapReduce的两种任务模式

MapReduce按照任务大小和设置的不同，提供了两种任务模式：

客户端通过org.apache.hadoop.mapreduce.protocol.ClientProtocol与服务端通信，ClientProtocol的继承关系：

老一些的版本还有一个JobTracker的实现类，即：classic。用于和MapReduce1.X兼容用的，高一些的版本已经没有这个实现类了。

一，本地模式（LocalJobRunner实现）

mapreduce.framework.name设置为local，则不会使用YARN集群来分配资源，在本地节点执行。在本地模式运行的任务，无法发挥集群的优势。注：在web UI是查看不到本地模式运行的任务。

二，Yarn模式（YARNRunner实现）

mapreduce.framework.name设置为yarn，当客户端配置mapreduce.framework.name为yarn时, 客户端会使用YARNRunner与服务端通信, 而YARNRunner真正的实现是通过ClientRMProtocol与RM交互, 包括提交Application, 查询状态等功能。但是根据任务的特性，分为两种方式执行任务：

         1，uber mode：

         Uber模式是Hadoop2.0针对MR小作业的优化机制。通过mapreduce.job.ubertask.enable来设置是否开启小作业优化，默认为false。

        如果用Job足够小，则串行在的一个JVM完成该JOB，即MRAppMaster进程中，这样比为每一个任务分配Container性能更好。

        那么什么才是足够小的Job呢？下面我们看看一些的参数（mapred-site.xml）：

• mapreduce.job.ubertask.maxmaps 最大的map数。默认值9
• mapreduce.job.ubertask.maxreduces 最大的reduce数，默认为1
• mapreduce.job.ubertask.maxbytes 最大的字节数，如果没有指定，默认和dfs.block.size一样。
  

        应用程序的其他配置也会影响到对“小”的定义，yarn.app.mapreduce.am.resource.mb必须大于mapreduce.map.memory.mb和mapreduce.reduce.memory.mb，还有yarn.app.mapreduce.am.resource.cpu-vcores必须大于mapreduce.map.cpu.vcores 和 mapreduce.reduce.cpu.vcores，以下是这个配置的说明：

• yarn.app.mapreduce.am.resource.mb   MR AppMaster需要的内存数，默认为1536
  
• mapreduce.map.memory.mb  从调度器（scheduler）为每个Map Task请求的内存数，默认1024
  
• mapreduce.reduce.memory.mb  从调度器（scheduler）为每个Reduce Task请求的内存数，默认1024
• yarn.app.mapreduce.am.resource.cpu-vcores MR AppMaster需要的虚拟CPU核数，默认为1536
  
• mapreduce.map.cpu.vcores 从调度器（scheduler）为每个Map Task请求的虚拟CPU核数，默认1
  
• mapreduce.reduce.cpu.vcores  为每个Map Reduce请求的虚拟CPU核数，默认1

        链式Job也不能使用Uber模式执行，即使满足了上面的情况也不能。因为链式作业会并发执行不同资源需求的map task和reduce task。链式Job是指集成了org.apache.hadoop.mapreduce.lib.chain.ChainReducer和org.apache.hadoop.mapreduce.lib.chain.ChainMapper类的用户Map或Reduce程序。

        yarn.app.mapreduce.am.resource.mb和yarn.app.mapreduce.am.resource.cpu-vcores是在yarn框架的级别，其他四个关于内存和CPU的配置是和具体每个Mapreduce任务有关，如果Mapreduce所需的资源大于Yarn框架定义的资源数量，则不能当成“小”Job使用uber mode执行了。

       2，Non-Uber mode：

       Uber只能执行一小部门的任务，在大数据环境下，大部分任务仍然运行在Non-Uber模式下，MRAppMaster将一个作业的map task和reduce task分为四种状态：

              pending：刚启动但尚未向ResourceManager发送资源请求
              scheduled：已经向ResourceManager发送资源请求，但尚未分配到资源
              assigned：已经分配到了资源且正在运行
              completed：已经运行完成。

      MRAppMaster初始化之后，会产生一系列的Map Task和Reduce Task。

            Map Task的生命周期是：

scheduled->assigned->completed

            Reduce Task的生命周期是：

pending->scheduled->assigned->completed

上面我们可以看到，Reduce Task比Map Task多一个pending的状态，主要是因为Reduce Task需要依赖Map Task的输出，为了防止Reduce Task启动过早造成资源浪费，MRAppMaster让刚启动的Reduce Task处于pending状态，这样可以根据Map Task的运行情况和具体的配置来调整Reduce Task状态（pengding到scheduled中相互转移），以下几个参数是有来配置Reduce Task的启动时机的：

• mapreduce.job.reduce.slowstart.completedmaps     map task完整了多少比率才开始为reduce task生成资源
• yarn.app.mapreduce.am.job.reduce.rampup.limit     在maps task已经完成，启动reduce task的比率。默认为0.5
  

  org.apache.hadoop.mapreduce.MRJobConfig:

 /**
   * Limit reduces starting until a certain percentage of maps have finished.
   *  Percentage between 0.0 and 1.0
   */
  public static final String MR_AM_JOB_REDUCE_RAMPUP_UP_LIMIT = 
    MR_AM_PREFIX  + "job.reduce.rampup.limit";
  public static final float DEFAULT_MR_AM_JOB_REDUCE_RAMP_UP_LIMIT = 0.5f;

• yarn.app.mapreduce.am.job.reduce.preemption.limit      当map task不能申请资源时，map task最多可以抢占reduce task资源的比率。默认为0.5
  

  org.apache.hadoop.mapreduce.MRJobConfig:
  /** 
   * Limit on the number of reducers that can be preempted to ensure that at
   *  least one map task can run if it needs to. Percentage between 0.0 and 1.0
   */
  public static final String MR_AM_JOB_REDUCE_PREEMPTION_LIMIT = 
    MR_AM_PREFIX  + "job.reduce.preemption.limit";
  public static final float DEFAULT_MR_AM_JOB_REDUCE_PREEMPTION_LIMIT = 0.5f;