纯粹的资源管理调度框架YARN整体剖析（课本知识复习）

1. MapReduce1.0框架的设计缺陷

MapReduce1.0采用 Master/Slave（一主多从） 框架设计，包括一个JobTracker和多个TaskTracker，前者负责作业的调度和资源的管理，勾着负责执行JobTracker指派的具体任务。这ob个架构设计有一些缺点，如下：

1. 存在单点故障。由一个JobTracker负责所有MapReduce作业的调度，而系统中整个对外活跃的只有一个JobTracker，因此存在单点故障的问题。
2. JobTracker负责整个的作业调度和资源的管理，导致任务过重，需要消耗大量的资源，也潜在的增加了JobTracker失败的风险，为了保证任务完整正确的执行，存在JobTracker处理任务的个数的上线，导致了性能的瓶颈。
3. 容易出现内存溢出。在TaskTracker端，资源的分配并不考虑CPU、内存的实际使用情况，而是根据MapReduce任务的个数来分配资源，当两个具有较大内存消耗的任务被分配到同一个TaskTracker上时，容易造成资源的溢出。
4. 资源划分不合理。资源（CPU，内存）被强制等量划分为多个 “槽”（Slot） ，槽又被进一步划分为Map槽和Reduce槽，分别供Map任务和Reduce任务使用，彼此之间不能使用分配给对方的槽，也就是说，当Map任务已用完Map槽之后，即使系统中有大量剩余的Reduce槽，也不能拿来运行Map任务。这也就意味着，当系统中只存在单一Map任务或Reduce任务时，会造成资源浪费。
5. 只有当全部MapTask完成后，ReduceTask才能开始。

体系结构图：

2. YARN的设计思路

• YARN整体的设计思路就是放权，就是帮JobTracker减轻压力，把原先JobTracker的三大功能（资源管理，任务调度，任务监控），分别交给不同的新的组件去处理。
• 重新设计后的YARN包括ResourceManager，ApplicationMaster和NodeManager，其中ResourceManager负责管理资源，ApplicationMaster负责任务的调度和监控，NodeManager负责执行原来TaskTracker的任务。
• 放权的设计思路，大大降低了TaskTracker的负担，提升了系统运行的效率和稳定性。
• MapReduce1.0中的资源管理调度功能被单独的分离出来形成了YARN，一个纯粹的资源管理调度框架。

3. YARN体系结构

3.1 结构组件总览

三大组件：ResourceManager，ApplicationMaster，NodeManager

3.2 三大组件的功能

• ResourceManager。处理客户端请求；启动/监控 ApplicationMaster；监控NodeManager；资源分配与调度
• ApplicationMaster。为应用程序申请资源，并分配给内部任务；任务调度，监控与容错
• NodeManager。单个节点上的资源管理；处理来自ResourceManager的命令；处理来自ApplicationMaster的命令

3.2.1 组件功能详解

1. ResourceManager功能

• ResourceManager是一个全局的资源管理器，负责整个系统的资源管理和分配，主要包括两个组件：调度器（Scheduler） 和应用程序管理器（ApplicationManager）。
• 调度器主要负责资源管理和分配
• ApplicationManager负责跟踪和监控应用程序的执行状态，负责执行和恢复。
• 调度器接受来自ApplicationMaster的应用程序资源请求，并根据容量，队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），把集群中的资源以“容器”的形式（每个容器中都封装了一定数量的CPU、内存、磁盘等资源）分配给提出申请的应用程序，容器的选择通常会考虑应用程序要处理的数据的位置，进行就近选择，从而实现“计算向数据靠拢”。
• 调度器被设置为一个可插拔的组件，YARN不仅自身提供了许多种可以直接使用的调度器，也允许用户根据自己的需求要求重新设计调度器。
• 应用程序管理器负责系统中所有应用程序的管理工作，主要包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动等。

2. ApplicationMaster功能

首先明确用户的应用程序是以作业（Job）的形式提交的，然后一个作业会被分解成多个任务（包括Map任务和Reduce任务）进行分布式执行。ResourceManager接收用户提交的作业，按照作业的上下文信息以及从NodeManager收集来的容器的状态信息，启动调度过程，为用户启动一个ApplicationMaster。它的功能如下：

1. 当用户作业提交时，ApplicationMaster和ResourceManager协商获取资源，ResourceManager会以容器的形式为ApplicationMaster分配资源。
2. 把获得的资源进一步分配给内部的各个任务（Map任务和Reduce任务），实现资源的二次分配。
3. 与NodeManager保持交互通信进行应用程序的启动、运行、监控和停止，监控申请到资源的使用情况，对所有任务的执行进度和状态进行监控，并在任务失败时执行失败恢复（重新申请资源重启任务）。
4. 定时向ResourceManager发送“心跳”消息，报告资源使用的消息和任务的进展信息。
5. 作业完成时，向ResourceManager注销容器，任务完成。

3. NodeManager功能

NodeManager是驻留在一个YARN集群中每一个节点上的代理，主要负责容器生命周期的管理，监控每个容器的资源（CPU、内存等）使用情况，跟踪节点的健康状态，并以“心跳”的方式与ResourceManager保持通信，向ResourceManager汇报作业资源的使用情况和每个容器运行的状态，同时，它主要还接受来自ApplicationMaster的启动/停止容器的各种请求。

只处理关于容器相关的问题，而不负责具体的每个任务自身状态的管理。

3.3 集群部署

YARN的各个组件是和Hadoop集群中的其他组件进行统一部署的。

ResourceManager组件和名称节点（NameNode）部署在一个节点上。

ApplicationMaster，NodeManager是和数据节点（DataNode）部署在一起的。

YARN中的容器代表了CPU、内存、网络等计算资源，也是和数据节点在一起的。

3.4 YARN的工作流程

YARN的框架中执行一个MapReduce程序时，从提交到完成的步骤：

1. 用户编写客户端应用程序，向YARN提交应用程序，提交的内容包括ApplicationMaster程序，启动ApplicationMaster的命令，用户程序等。
2. YARN中ResourceManager负责接收和处理来自用户端的请求。接收到用户端应用程序的请求后，ResourceManager里面的调度器会为应用程序分配一个容器，同时，ResourceManager的应用程序管理器会与该容器所在的NodeManager通信，为该应用程序在该容器中启动一个ApplicationMaster。
3. ApplicationMaster被创建后首先向ResourceManager注册，从而使得用户可以通过ResourceManager来直接查看应用程序的运行状态。
4. ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请资源。
5. ResourceManager以“容器”的形式向提出申请的ApplicationMaster分配资源，一旦ApplicationMaster申请到资源后，就会与该容器所在的NodeManager通信，要求它启动任务。
6. 当ApplicationMaster要求容器启动任务时，它会为任务设置好与运行环境（包括环境变量，JAR包，二进制程序等），然后将任务启动命令写入一个脚本当中，最后通过在容器中运行该脚本来启动任务。
7. 各个任务通过RPC协议向ResourceManager汇报自己的状态和进度，让ApplicationMaster可以随时掌握各个任务的运行状态，从而可以在任务失败的时候重启任务。
8. 应用程序完成后，ApplicationMaster向ResourceManager的应用程序管理器注销并关闭自己。若ApplicationMaster因故失败，ResourceManager中的应用程序管理器会检测到失败的情形，然后将其重新启动，直到所有的任务都执行完毕。

理论知识虽然枯燥，但不得不先从学习理论知识开始，不知己知彼，怎么能百战百胜呢，虽然不知道书中的YARN和现在实际应用中的YARN差别有多大，但最起码自己知道了解并理解了整个YARN的基础知识。