【Yarn】Yarn资源调度系统

Yarn的基本架构

Yarn的基本思想是将JobTracker的资源管理和作业的调度/监控两大主要职能拆分为两个独立的进程：一个全局的Resource Manager和每个应用对应的Application Master（AM）。Resource Manager和每个节点上的Node Manager（NM）组成了全新的通用操作系统，以分布式的方式管理应用程序。

Resource Manager拥有为系统中所有应用分配资源的决定权。与之相关的是应用程序的Application Master，负责与Resource Manager协商资源，并于Node Manager协同工作来执行和监控任务。

Resource Manager有一个可插拔的调度器组件Scheduler，它负责为运行中的各种应用分配资源，分配时会受到容量、队列以及其他因素的制约。Scheduler是一个纯粹的调度器，不负责应用程序的监控和状态跟踪，也不保证在应用程序失败或者硬件失败的情况下对Task的重启。Scheduler基于应用程序的资源的需求来指定其调度功能，使用了成为资源Contrainer的抽象概念，其中包括了多种资源维度，例如内存、CPU、磁盘以及网络。

Node Manager是与每台机器对应的从属进程（Slave），负责启动应用程序的Container，监控它们的资源使用情况（CPU、内存、磁盘和网络）,并且报告给Resource Manager。

每个应用程序的Application Master负责与Scheduler协商合适的Container，跟踪应用程序的状态，以及监控它们的进度。从系统的角度看，Application Master也是以一个普通Container的身份运行的。

Yarn的各个组件

1. Resource Manager

Yarn Resource Manager是一个纯粹的调度器，它负责整个系统的资源管理和分配。它本身主要由两个组件构成：调度器（Scheduler）和应用程序管理器（Applications Manager: ASM）

• Resource Manager是一个全局的资源管理器，集群只有一个active的对外提供服务

  1. 负责整个系统的资源管理和分配
  2. 包括处理客户端请求
  3. 启动/监控 Application Master
  4. 监控 NodeManager、资源的分配与调度

• 调度器(Scheduler)

  1. 调度器根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个正在运行的应用程序。
  2. 需要注意的是，该调度器是一个“纯调度器”
     1. 它不从事任何与具体应用程序相关的工作，比如不负责监控或者跟踪应用的执行状态等，也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务，这些均交由应用程序相关的ApplicationMaster完成。
     2. 调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位用一个抽象概念“资源容器”（Resource Container，简称Container）表示，Container是一个动态资源分配单位，它将内存、CPU、磁盘、网络等资源封装在一起，从而限定每个任务使用的资源量。
  3. 调度器是一个可插拔的组件，用户可以根据自己的需要设计新的调度器，Yarn提供了多种直接可用的调度器，比如公平调度器（Fair Scheduler）和容量调度器（Capacity Scheduler）

• 应用程序管理器(Applications Manager，ASM)

  1. 应用程序管理器主要负责管理整个系统中所有应用程序
  2. 接收job的提交请求
  3. 为应用分配第一个 Container来运行 Application Master
     1. 包括应用程序提交
     2. 与调度器Scheduler协商资源以启动 Application Master
     3. 监控 Application Master运行状态并在失败时重新启动它等

2. Application Master

Yarn的另一个重要概念就是Application Master。 Application Master实际上是特定框架库的一个实例，负责与Resource Manager协商资源，并和Resource Manager协同工作来执行和监控Container，以及它们的资源小号。它有责任与Resource Manager协商并获取合适的资源Container，跟踪它们的状态，以及监控其进展。

Application Master和应用是相互对应的，它主要的职责有：

• 与调度器协商资源；
• 与Node Manager合作，在合适的Container中运行对应的组件Task，并监控这些task执行；
• 如果Container出现故障，Application Master会重新向调度器申请其他资源；
• 计算应用程序所需的资源量，并转化成调度器可识别的协议信息包；
• 在Application Master出现故障后，应用管理器会负责重启它，但由Application Master自己从之前保存的应用程序执行状态中恢复应用程序。

在真实环境下，每一个应用都有自己的Application Master实例，然而，为一组应用提供一个Application Master是完全可行的，比如Pig或者是Hive的Application Master。

Application Master 与 Resource Manager 之间的通信

• 是整个 Yarn 应用从提交到运行的最核心部分，是 Yarn 对整个集群进行动态资源管理的根本步骤；
• Application Master周期性的向Resource Manager发送心跳，让Resource Manager确认Application Master的健康;
• Yarn的动态性，就是来源于多个Application的Application Master动态地和Resource Manager进行沟通，不断地申请、释放、再申请、再释放资源的过程。

3. Node Manager

Node Manager是每个节点的框架代理。它负责启动应用的Container，监控Container的资源使用（包括CPU、内存、硬盘和网络带宽等），并把这些用信息汇报给调度器。应用对应的Application Master负责通过协商从调度器处获取Container，并跟踪这些Container的资源状态和应用执行情况。集群每个节点上都有一个Node Manager，它主要负责：

• 为应用启动调度器，以分配给应用的Container；
• 已启用的Container不会使用超过分配的资源量；
• 为Task构建Container环境，包括二进制可执行文件.jars等
• 为所在的节点提供一个管理本地存储资源的简单服务。

应用程序可以继续使用本地存储资源，即使它没有从Resource Manager处申请，例如，MapReduce可以利用这个服务存储Map Task的中间输出结果，并将其Shuffle给Reduce Task。

Yarn的应用资源模型是一个通用的设计，一个应用（通过Application Master）可以请求非常具体的资源，包括：

• 资源名称（包括主机名称、机架名称、以及可能的复杂的网络拓扑）
• 内存量
• CPU（核数/类型）
• 其他资源，例如Disk、Network、I/O、GPU等
  
• Node Manager 是YARN中的 slave角色
• Node Manager ：
  • 当一个节点启动时，它会向 Resource Manager进行注册并告知Resource Manager自己有多少资源可用。
  • 每个计算节点，运行一个Node Manager进程，通过心跳（每秒 yarn.resourcemanager.nodemanagers.heartbeat-interval-ms ）上报节点的资源状态(磁盘，内存，cpu等使用信息)
• 功能：
  • 接收及处理来自 Resource Manager 的命令请求，分配 Container 给应用的某个任务；
  • Node Manager 监控本节点上的资源使用情况和各个 Container 的运行状态（cpu和内存等资源）
  • 负责监控并报告 Container 使用信息给 Resource Manager。
  • 定时地向RM汇报以确保整个集群平稳运行，RM 通过收集每个 Node Manager 的报告信息来追踪整个集群健康状态的，而 Node Manager 负责监控自身的健康状态；
  • 处理来自 Application Master 的请求；
  • 管理着所在节点每个 Container 的生命周期；
• 管理每个节点上的日志；
  • 在运行期，通过 Node Manager 和 Resource Manager 协同工作，这些信息会不断被更新并保障整个集群发挥出最佳状态。
  • Node Manager 只负责管理自身的 Container，它并不知道运行在它上面应用的信息。负责管理应用信息的组件是 Application Master

4. Resource Request和Container

Yarn被设计成可以允许应用程序（通过Application Master）以共享的、安全的，以及多用户租户的方式使用集群的资源，它也会感知集群的网络拓扑，以便可以有效地调度以及优化数据网文（即尽可能地为应用减少数据移动）。

位于Resource Manager内的中心调度器保存了应用程序的资源请求信息，以帮助它为集群中的所有应用做出更优的调度决策。

本质上，一个应用程序可以通过Application Master请求特定的资源需求来满足它的资源需要。调度器会分配一个Container来响应资源需求，用于满足由Application Master在Resource Request中提出的需求。

Resource Request的形式如下：

<资源名称，优先级，资源需求，Container数>

其中：

• 资源名称是资源期望所在的主机名、机架名，用*表示没有特殊要求。
• 优先级是应用程序内部请求的优先级（而不是多个应用程序之间），优先级会调整应用程序内部各个Resource Request的次序。
• 资源需求是需要的资源量，如内存大小和CPU时间
• Container数表示需要这样的Container的数量，它限制了使用该Resource Request指定的Container的总数。

本质上，Container是一种资源分配形式，是Resource Manager为Resource Request成功分配资源的结果。Container为应用程序授予在特定主机上使用资源（如内存、CPU等）的权利。

Application Master必须取走Container，并交给Node Manager，Node Manager会利用相应的资源来启动Container的任务进程。出于安全考虑，Container的分配要以一种安全的方式进行验证，来保证Application Master不能伪造集群中的应用。Container只有使用服务器（Node Manager）上指定资源的权利，Application Master必须想Node Manager提供更多信息来启动Container。
总之，

• Container 是 YARN 中的资源抽象
  • YARN以Container为单位分配资源
  • 它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等
  • 当 Application Master向 Resource Manager申请资源时，Resource Manager为 Application Master 返回的资源便是用 Container 表示的
• YARN 会为每个任务分配一个 Container，且该任务只能使用该 Container 中指定数量的资源。
• Container 和集群Node Manager节点的关系是：
  • 一个Node Manager节点可运行多个Container
  • 但一个 Container 不会跨节点。
  • 任何一个 job 或 application 必须运行在一个或多个Container 中
  • 在 Yarn 框架中，Resource Manager只负责告诉 Application Master 哪些 Containers 可以用
  • Application Master 还需要去找 Node Manager 请求分配具体的 Container。
• 需要注意的是
  • Container 是一个动态资源划分单位，是根据应用程序的需求动态生成的
  • 目前为止，YARN 仅支持 CPU 和内存两种资源，且使用了轻量级资源隔离机制 Cgroups 进行资源隔离。
• 功能：
  • 对task环境的抽象；
  • 描述一系列信息；
  • 任务运行资源的集合（cpu、内存、io等）；
  • 任务运行环境

5. Job History Server

Job History Server，即作业历史服务。记录在Yarn中调度的作业历史运行情况情况，可以通过历史任务日志服务器来查看hadoop的历史任务，出现错误都应该第一时间来查看日志。

1. 在mapred-site.xml中添加如下配置：

<property>
    <name>mapreduce.jobhistory.address</name>
    <value>node01:10020</value>
</property>

<property>
    <name>mapreduce.jobhistory.webapp.address</name>
    <value>node01:19888</value>
</property>

2. 在yarn-site.xml中添加如下配置：

<!-- 开启日志聚合 -->
<property>
    <name>yarn.log-aggregation-enable</name>
    <value>true</value>
</property>
<!-- 多长时间聚合删除一次日志 -->
<property>
    <name>yarn.log-aggregation.retain-seconds</name>
    <value>2592000</value><!--30 day-->
</property>
<!-- 时间在几秒钟内保留用户日志。只适用于如果日志聚合是禁用的 -->
<property>
    <name>yarn.nodemanager.log.retain-seconds</name>
    <value>604800</value><!-- 7 day -->
</property>
<!-- 指定文件压缩类型用于压缩汇总日志 -->
<property>
    <name>yarn.nodemanager.log-aggregation.compression-type</name>
    <value>gz</value>
</property>
<!-- nodemanager本地文件存储目录  -->
<property>
    <name>yarn.nodemanager.local-dirs</name>
    <value>/bigdata/install/hadoop-2.6.0-cdh5.14.2/hadoopDatas/yarn/local</value>
</property>
<!--  resourceManager保存最大的任务完成个数 -->
<property>
    <name>yarn.resourcemanager.max-completed-applications</name>
    <value>1000</value>
</property>

3. 将上述配置同步到集群的其他节点上，启动job history服务

sbin/start-yarn.sh
sbin/mr-jobhistory-daemon.sh start historyserver

6. Timeline Server

• 用来写日志服务数据 , 一般来写与第三方结合的日志服务数据(比如spark等)
• 它是对job history server功能的有效补充，job history server只能对mapreduce类型的作业信息进行记录
• 它记录除了job history server能够对作业运行过程中信息进行记录之外，还记录更细粒度的信息，比如任务在哪个队列中运行，运行任务时设置的用户是哪个用户。
• 根据官网的解释job history server只能记录mapreduce应用程序的记录，timeline server功能更强大,但不是替代job history两者是功能间的互补关系
  

Yarn的工作流程

经典的MapReduce(MapReduce v1)的最顶层包含4个独立的实体，分别是客户端、JobTracker、TaskTracker，以及分布式文件系统。Yarn将JobTracker的职能划分为多个独立的实体，从而改善经典MapReduce面临的扩展瓶颈问题。JobTracker负责作业调度和任务进度监视、追踪任务、重启失败或过慢的任务及进行任务登记，例如维护计数器总数。

YARN将这两种角色划分为两个独立的守护进程：管理集群上资源使用的资源管理器(Resource Manager)和管理集群上运行任务生命周期的应用管理器(Application master)。
基本思路是：应用服务器与资源管理器协商集群的计算资源：容器(containers，每个容器都有特定的内存上限)，在这些容器上运行特定应用程序的进程。容器由集群节点上运行的节点管理器(NodeManager)监视，以确保应用程序使用的资源不会超过分配给它的资源。

与jobtracker不同，应用的每个实例(一个MapReduce作业)有一个特定的应用Master，它运行在应用的存续期间。

YARN上的MapReduce比经典的MapReduce包括更多的实体，总体上，Yarn的工作流程包括5个步骤：

1. 客户端提交MapReduce作业
2. YARN资源管理器(Resource Manager)负责协调集群上计算资源的分配
3. YARN节点管理器(NodeManager)负责启动和监视集群中机器上的计算容器(container)
4. MapReduce应用程序Master负责协调运行MapReduce作业的任务。它和MapReduce任务在容器中运行，这些容器由资源管理器分配并由节点管理器进行管理
5. 分布式文件系统(一般为HDFS)，用来与其他实体间共享作业文件
   
6. 客户端程序向ResourceManager提交应用并请求一个ApplicationMaster实例，ResourceManager在应答中给出一个applicationID以及有助于客户端请求资源的资源容量信息。
7. ResourceManager找到可以运行一个Container的NodeManager，并在这个Container中启动ApplicationMaster实例
   Application Submission Context发出响应，其中包含有：ApplicationID，用户名，队列以及其他启动ApplicationMaster的信息，
   Container Launch Context（CLC）也会发给ResourceManager，CLC提供了资源的需求，作业文件，安全令牌以及在节点启动ApplicationMaster所需要的其他信息。
   当ResourceManager接收到客户端提交的上下文，就会给ApplicationMaster调度一个可用的container（通常称为container0）。然后ResourceManager就会联系NodeManager启动ApplicationMaster，并建立ApplicationMaster的RPC端口和用于跟踪的URL，用来监控应用程序的状态。
8. ApplicationMaster向ResourceManager进行注册，注册之后客户端就可以查询ResourceManager获得自己ApplicationMaster的详细信息，以后就可以和自己的ApplicationMaster直接交互了。在注册响应中，ResourceManager会发送关于集群最大和最小容量信息，
9. 在平常的操作过程中，ApplicationMaster根据resource-request协议向ResourceManager发送resource-request请求，ResourceManager会根据调度策略尽可能最优的为ApplicationMaster分配container资源，作为资源请求的应答发个ApplicationMaster
10. 当Container被成功分配之后，ApplicationMaster通过向NodeManager发送container-launch-specification信息来启动Container， container-launch-specification信息包含了能够让Container和ApplicationMaster交流所需要的资料，一旦container启动成功之后，ApplicationMaster就可以检查他们的状态，Resource Manager不在参与程序的执行，只处理调度和监控其他资源，Resource Manager可以命令NodeManager杀死container，
11. 应用程序的代码在启动的Container中运行，并把运行的进度、状态等信息通过application-specific协议发送给ApplicationMaster，随着作业的执行，ApplicationMaster将心跳和进度信息发给ResourceManager，在这些心跳信息中，ApplicationMaster还可以请求和释放一些container。
12. 在应用程序运行期间，提交应用的客户端主动和ApplicationMaster交流获得应用的运行状态、进度更新等信息，交流的协议也是application-specific协议
13. 一但应用程序执行完成并且所有相关工作也已经完成，ApplicationMaster向ResourceManager取消注册然后关闭，用到所有的Container也归还给系统，当container被杀死或者回收，ResourceManager都会通知NodeManager聚合日志并清理container专用的文件。

MapReduce On Yarn

1. 提交作业

• ①程序打成jar包，在客户端运行hadoop jar命令，提交job到集群运行
• job.waitForCompletion(true)中调用Job的submit()，此方法中调用JobSubmitter的submitJobInternal()方法；
  • ②submitClient.getNewJobID()向resourcemanager请求一个MR作业id
  • 检查输出目录：如果没有指定输出目录或者目录已经存在，则报错
  • 计算作业分片；若无法计算分片，也会报错
  • ③运行作业的相关资源，如作业的jar包、配置文件、输入分片，被上传到HDFS上一个以作业ID命名的目录（jar包副本默认为10，运行作业的任务，如map任务、reduce任务时，可从这10个副本读取jar包）
  • ④调用resourcemanager的submitApplication()提交作业
• 客户端每秒查询一下作业的进度（map 50% reduce 0%），进度如有变化，则在控制台打印进度报告；
• 作业如果成功执行完成，则打印相关的计数器
• 但如果失败，在控制台打印导致作业失败的原因（要学会查看日志，定位问题，分析问题，解决问题）

2.初始化作业

• 当ResourceManager(一下简称RM)收到了submitApplication()方法的调用通知后，请求传递给RM的scheduler（调度器）；调度器分配container（容器）
• ⑤a RM与指定的NodeManager通信，通知NodeManager启动容器；NodeManager收到通知后，创建占据特定资源的container；
• ⑤b 然后在container中运行MRAppMaster进程
• ⑥MRAppMaster需要接受任务（各map任务、reduce任务的）的进度、完成报告，所以appMaster需要创建多个簿记对象，记录这些信息
• ⑦从HDFS获得client计算出的输入分片split
  • 每个分片split创建一个map任务
  • 通过 mapreduce.job.reduces 属性值(编程时，jog.setNumReduceTasks()指定)，知道当前MR要创建多少个reduce任务
  • 每个任务(map、reduce)有task id

3.Task 任务分配

• 如果小作业，App Master会以uberized的方式运行此MR作业；App Master会决定在它的JVM中顺序执行此MR的任务；
  • 原因是，若每个任务运行在一个单独的JVM时，都需要单独启动JVM，分配资源（内存、CPU），需要时间；多个JVM中的任务再在各自的JVM中并行运行
  • 若将所有任务在appMaster的JVM中顺序执行的话，更高效，那么appMaster就会这么做 ，任务作为uber任务运行
  • 小作业判断依据：①小于10个map任务；②只有一个reduce任务；③MR输入大小小于一个HDFS块大小
  • 如何开启uber? 设置属性 mapreduce.job.ubertask.enable 值为true
  • 在运行任何task之前，appMaster调用setupJob()方法，创建OutputCommitter，创建作业的最终输出目录（一般为HDFS上的目录）及任务输出的临时目录（如map任务的中间结果输出目录）

configuration.set("mapreduce.job.ubertask.enable", "true");

• ⑧若作业不以uber任务方式运行，那么appMaster会为作业中的每一个任务（map任务、reduce任务）向RM请求container

  • 由于reduce任务在进入排序阶段之前，所有的map任务必须执行完成；所以，为map任务申请容器要优先于为reduce任务申请容器
  • 5%的map任务执行完成后，才开始为reduce任务申请容器
  • 为map任务申请容器时，遵循数据本地化，调度器尽量将容器调度在map任务的输入分片所在的节点上（移动计算，不移动数据）
  • reduce任务能在集群任意计算节点运行
  • 默认情况下，为每个map任务、reduce任务分配1G内存、1个虚拟内核，由属性决定mapreduce.map.memory.mb、mapreduce.reduce.memory.mb、mapreduce.map.cpu.vcores、mapreduce.reduce.reduce.cpu.vcores

• 内存的分配方式不同于MapReduce1，MapReduce1中Task trackers有在集群配置时设置的固定数量的槽，每个任务在一个槽上运行。槽有最大内存分配限制，这对集群是固定的，导致当任务使用较少内存时无法充分利用内存(因为其他等待的任务不能使用这些未使用的内存)以及由于任务不能获取足够内存而导致作业失败。

• 在YARN中，资源分为更细的粒度，所以可以避免上述问题。

  • 应用程序可以请求最小到最大限制范围的任意最小值倍数的内存容量。默认的内存分配容量是调度器特定的，对于容量调度器，它的默认值最小值是1024MB（由yarn.scheduler.capacity.minimum-allocation-mb设置），默认的最大值是10240MB(由yarn.scheduler.capacity.maximum-allocation-mb设置)。
  • 任务可以通过适当设置mapreduce.map.memory.mb和mapreduce.reduce.memory.mb来请求1GB到10GB间的任意1GB倍数的内存容量（调度器在需要的时候使用最接近的倍数）

4. Task 任务执行

• 当调度器为当前任务分配了一个NodeManager（暂且称之为NM01）的容器，并将此信息传递给appMaster后；appMaster与NM01通信，告知NM01启动一个容器，并此容器占据特定的资源量（内存、CPU）
• NM01收到消息后，启动容器，此容器占据指定的资源量
• 容器中运行YarnChild，由YarnChild运行当前任务（map、reduce）
• ⑩在容器中运行任务之前，先将运行任务需要的资源拉取到本地，如作业的JAR文件、配置文件、分布式缓存中的文件
• 运行map任务和reduce任务

5. 作业运行进度与状态更新

• 作业job以及它的每个task都有状态（running、successfully completed、failed），当前任务的运行进度、作业计数器
• 任务在运行期间，每隔3秒向appMaster汇报执行进度、状态（包括计数器）
• appMaster汇总目前运行的所有任务的上报的结果
• 客户端每隔1秒，轮询访问appMaster获得作业执行的最新状态，若有改变，则在控制台打印出来

6.完成作业

• appMaster收到最后一个任务完成的报告后，将作业状态设置为成功
• 客户端轮每5秒钟还通过调用Job的waitForCompletion来检查作业是否完成，发现作业执行成功，程序从waitForCompletion()退出
• 作业的所有统计信息打印在控制台
• appMaster及运行任务的容器，清理中间的输出结果，释放资源，OutputCommiter的作业清理方法会被调用
• 作业信息被历史服务器保存，留待以后需要时查询

Yarn应用的生命周期

• RM: Resource Manager
• AM: Application Master
• NM: Node Manager

1. Client向RM提交应用，包括AM程序及启动AM的命令。
2. RM为AM分配第一个容器，并与对应的NM通信，令其在容器上启动应用的AM。
3. AM启动时向RM注册，允许Client向RM获取AM信息然后直接和AM通信。
4. AM通过资源请求协议，为应用协商容器资源。
5. 如容器分配成功，AM要求NM在容器中启动应用，应用启动后可以和AM独立通信。
6. 应用程序在容器中执行，并向AM汇报。
7. 在应用执行期间，Client和AM通信获取应用状态。
8. 应用执行完成，AM向RM注销并关闭，释放资源。

申请资源->启动appMaster->申请运行任务的container->分发Task->运行Task->Task结束->回收container