8.3　MapReduce V2设计细节

上面介绍了MapReduce V2的主体设计思想和架构及其各个部分的主要职责，下面将详细介绍MapReduce V2中的一些设计细节，让大家更加深入地理解MapReduce V2。

1.资源协商

应用主体通过适当的资源需求描述来申请资源容器，可以包括一些指定的机器节点。应用主体还可以请求同一台机器上的多个资源容器。所有的资源请求受应用程序容量和队列容量等的限制。所以为了高效地分配集群的资源容器，应用主体需要计算应用的资源需求，并且把这些需求封装到调度器能够识别的协议信息包中，比如＜priority，（host, rack，*），memory，#containers＞。以MapReduce为例，应用主体分析input-splits并将其转化成以host为key的转置表发送给资源管理器，发送的信息中还包括在其执行期间随着执行的进度应用对资源容器需求的变化。调度器解析出应用主体的请求信息之后，会尽量分配请求的资源给应用主体。如果指定机器上的资源不可用，还可以将同一机器或者不同机器上的资源分配给给应用主体。在有些情况下，由于整个集群非常忙碌，应用主体获取的资源可能不是最合适的，此时它可以拒绝这些资源并请求重新分配。从上面介绍的资源协商的过程可以看出，MapReduce V2中的资源并不再是来自map池和reduce池，而是来自统一的资源容器，这样应用主体可以申请所需数量的资源，而不会因为资源并非所需类型而挂起。需要注意的是，调度器不允许应用主体无限制地申请资源，它会根据应用限制、用户限制、队列限制和资源限制等来控制应用主体申请到的资源规模，从而保证集群资源不被浪费。

2.调度

调度器收集所有正在运行应用程序的资源请求并构建一个全局的资源分配计划。调度器会根据应用程序相关的约束（如合适的机器）和全局约束（如队列资源总量，队列限制，用户限制等）分配资源。调度器使用与容量调度类似的概念，采用容量保证作为基本的策略在多个竞争关系的应用程序间分配资源。调度器的调度步骤如下：

1）选择系统中“最低服务”的队列。这个队列可以是等待时间最长的队列，或者等待时间与已分配资源之比最大的队列等。

2）从队列中选择拥有最高优先级的作业。

3）满足被选出的作业的资源请求。

MapReduce V2中只有一个接口用于应用主体向调度器请求资源。接口如下：

Response allocate（List＜ResourceRequest＞ask, List＜Container＞release）

应用主体使用这个接口中的ResourceRequest列表请求特定的资源，同时使用接口中的Container列表参数告诉调度器自己释放的资源容器。

调度器接收到应用主体的请求之后会根据自己的全局计划及各种限制返回对请求的回复。回复中主要包括三类信息：最新分配的资源容器列表、在应用主体和资源管理器上次交互之后完成任务的应用指定资源容器的状态、当前集群中应用程序可用的资源数量。应用主体可以收集完成容器的信息并对失败任务做出反应。可用资源量可以为应用主体接下来的资源申请提供参考，比如应用主体可以使用这些信息来合理分配Map和Reduce各自请求的资源数量，进而防止死锁（最明显的情况是Reduce请求占用所有的剩余可用资源）。

3.资源监控

调度器定期从节点管理器处收集已分配资源的使用信息。同时，调度器还会将已完成任务容器的状态设置为可用，以便有需求的应用申请使用。

4.应用提交

以下是应用提交的步骤。

1）用户提交作业到应用管理器。具体的步骤是在用户提交作业之后，MapReduce框架为用户分配一个新的应用ID，并将应用的定义打包上传到HDFS上用户的应用缓存目录中。最后提交此应用给应用管理器。

2）应用管理器接受应用提交。

3）应用管理器同调度器协商获取运行应用主体所需的第一个资源容器，并执行应用主体。

4）应用管理器将启动的应用主体细节信息发还给用户，以便其监督应用的进度。

5.应用管理器组件

应用管理器负责启动系统中所有应用的应用主体并管理其生命周期。在启动应用主体之后，应用管理器通过应用主体定期发送的“心跳”来监督应用主体，保证其可用性，如果应用主体失败，就需要将其重启。

为了完成上述任务，应用管理器包含以下组件：

图　8-3　MapReduce V2作业执行流程

1）调度协商组件，负责与调度器协商应用主体所需的资源容器。

2）应用主体容器管理组件，负责通过与节点管理器通信来启动或停止应用主体容器。

3）应用主体监控组件，负责监控应用主体的状态，保证其可用，并且在必要的情况下重启应用主体。

6.MapReduce V2作业执行流程

由于主要组件发生更改，MapReduce V2中的作业执行流程也有所变化。作业的执行流程图如图8-3所示（仅说明主要流程，一些反馈流程和心跳通信并未标注）。

步骤①：MapReduce框架接收用户提交的作业，并为其分配一个新的应用ID，并将应用的定义打包上传到HDFS上用户的应用缓存目录中，然后提交此应用给应用管理器。

步骤②：应用管理器同调度器协商获取运行应用主体所需的第一个资源容器。

步骤③：应用管理器在获取的资源容器上执行应用主体。

步骤④：应用主体计算应用所需资源，并发送资源请求到调度器。

步骤⑤：调度器根据自身统计的可用资源状态和应用主体的资源请求，分配合适的资源容器给应用主体。

步骤⑥：应用主体与所分配容器的节点管理器通信，提交作业情况和资源使用说明。

步骤⑦：节点管理器启用容器并运行任务。

步骤⑧：应用主体监控容器上任务的执行情况。

步骤⑨：应用主体反馈作业的执行状态信息和完成状态。

7.MapReduce V2系统可用性保证

系统可用性主要指MapReduce V2中各个组件的可用性，即保证能使其在失败之后迅速恢复并提供服务，比如保证资源管理器、应用主体等的可用性。首先介绍MapReduce V2如何保证MapReduce应用和应用主体的可用性。在之前已有介绍，资源管理器中的应用管理器负责监控MapReduce应用主体的执行情况。在应用主体发生失败之后，应用管理器仅重启应用主体，再由应用主体恢复某个特定的MapReduce作业。应用主体在恢复MapReduce作业时，有三种方式可供选择：完成重启MapReduce作业；重启未完成的Map和Reduce任务；向应用主体标明失败时正在运行的Map和Reudce任务，然后恢复作业执行。第一种方式的代价比较大，会重复工作；第二种方式效果较好，但仍有可能重复Reduce任务的部分工作；第三种方式最为理想，从失败点直接重新开始，没有任何重复工作，但这种方式对系统的要求过高。在MapReduce V2中选择了第二种恢复方式，具体实现方式是：应用管理器在监督MapReduce任务执行的同时记录日志，标明已完成的Map和Reduce任务；在恢复作业时，分析日志后重启未完成的任务即可。

接下来介绍MapReduce V2如何保证资源管理器的可用性。资源管理器在运行服务过程中，使用ZooKeeper保存资源管理的状态，包括应用管理器进程情况、队列定义、资源分配情况、节点管理器情况等信息。在资源管理器失败之后，由资源管理器根据自己的状态进行自我恢复。