Uber和Non-Uber模式介绍

一  背景

按照作业大小不同，MRAppMaster提供了三种作业运行模式。

本地模式，Uber模式，Non-Uber模式.

对于小作业，为了降低其延迟，可采用Uber模式，该模式下所有Map 任务和 Task 任务都会在同一个Container中启动，然后顺序执行。不会分别分配一个Container。

对于大作业，则采用Non-Uber模式，MRAppMaster先为MapTask申请资源，当MapTask运行完成数目达到一定比例再为ReduceTask申请资源。

 

二 Uber模式

YARN对小作业进行了优化，MRAppMaster无需再为MapTask 和 ReudceTask分别申请container资源。而是为MapTask申请Container资源后，不在为Reduce重新申请，而是重用之前MapTask的资源。

 

那什么作业属于小作业呢？

#Map Task数目不超过mapreduce.job.ubertask.maxmaps，默认是9个

#Reduce Task数目不超过mapreduce.job.ubertask.maxreduces， 默认是1个。

#文件大小不大于mapreduce.job.ubertask.maxbytes,默认是一个block的大小（128M）

#Map Task 和 ReduceTask 需要的资源量不超过MRAppMaster可使用的资源量，即现在MRAppMaster可使用内存200M,但是MapTask 和 ReduceTask需要1G,那么这个也不属于小作业。

#链式作业也不允许运行在Uber模式

 

三 Non-Uber模式

MRAppMaster将大作业的Task分为四种状态：

#pending: 刚启动但是尚未向RM发送资源申请

#scheduled: 已经向RM发送资源申请，但是RM还尚未分配到资源

#assigned: 已经分配到了资源，且正在运行

#completed: 已经运行完成

对于MapTask，只有三种状态：

Scheduled=> Assigned => Completed

对于ReduceTask有四种状态：

Pending=> Scheduled => Assigned => Completed

原因在于：ReduceTask依赖MapTask的输出结果，因此，为避免ReduceTask过早启动造成资源利用率低下，MRAppMaster让刚启动ReduceTask处于pending状态，以便能够根据MapTask运行情况是否对其调度

 

ReduceTask启动时机

#mapreduce.job.reduce.slowstart.completedmaps: 当Map Task完成的比例达到该值之后，才会为ReduceTask申请资源，默认是0.05

#yarn.app.mapreduce.am.job.reduce.rampup.limit: 在Map Task完成前最多启动的ReduceTask比例，默认为0.5

#yarn.app.mapreduce.am.job.reduce.preemption.limit: 当MapTask需要资源，但是暂时无法获取资源时，为了保证至少一个MapTask可以得到资源，最多可以抢占的ReduceTask比例，默认为0.5