Hadoop之MapReduce的两种任务模式

qq78707

　　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;