MapReduce作业可以细分为map task和reduce task，而MRAppMaster又将map task和reduce task分为四种状态：

　　1、pending：刚启动但尚未向resourcemanager发送资源请求；

　　2、scheduled：已经向resourceManager发送资源请求，但尚未分配到资源；

　　3、assigned：已经分配到了资源且正在运行；

　　4、completed：已经运行完成。

　　map task的生命周期为：scheduled -> assigned -> completed
　　reduce task 生命周期：pending -> scheduled -> assigned -> completed。

　　由于reduce task的执行需要依赖于map task的输出结果，因此，为避免reduce task过早启动造成资源利用率底下，MRAppMaster让刚启动的reduce处于pending状态，以便能够根据map task的运行情况决定是否对其进行调度。

　　那么如何确定reduce task启动时机呢？因为YARN没有Hadoop 1.x里面的map slot和reduce slot概念，且ResourceManager也不知道map task和reduce task之间的依赖关系，因此MRAppMaster自己需要设计资源申请策略以防止因reduce task过早启动照成资源利用率低下和map task因分配不到资源而饿死。MRAppMaster在MRv1原有策略（map task完成数目达到一定比例后才允许启动reduce task）基础上添加了更为严格的资源控制策略和抢占策略，这里主要涉及到以下三个参数：

　　mapreduce.job.reduce.slowstart.completedmaps：其英文含义是：Fraction of the number of maps in the job which should be complete before reduces are scheduled for the job。当map task完成的比例达到该值后才会为reduce task申请资源，默认是0.05。

　　yarn.app.mapreduce.am.job.reduce.rampup.limit：在map task完成之前，最多启动reduce task比例，默认是0.5

　　yarn.app.mapreduce.am.job.reduce.preemption.limit：当map task需要资源但暂时无法获取资源（比如reduce task运行过程中，部分map task因结果丢失需重算）时，为了保证至少一个map task可以得到资源，最多可以抢占reduce task比例，默认是0.5

　　如果上面三个参数设置的不合理可能会出现提交的job出现大量的reduce被kill掉，这个问题其实是reduce 任务启动时机的问题，由于yarn中没有map slot和reduce slot的概念，且ResourceManager也不知道map task和reduce task之间的依赖关系，因此MRAppMaster自己需要设计资源申请策略以防止因reduce task过早启动照成资源利用率低下和map task因分配不到资源而饿死，然后通过抢占机制，大量reduce任务被kill掉。可以合理调节上面三个配置参数来消除这种情况。