Yarn 详解

Yarn各个组件、资源请求以及资源调度

1. YARN 的组件以及架构

1.1 Container

Container是Yarn框架的计算单元，是具体执行应用task（如map task、reduce task）的基本单位。Container和集群节点的关系是：一个节点会运行多个Container，但一个Container不会跨节点。

任何一个job或application必须运行在一个或多个Container中，在Yarn框架中，ResourceManager只负责告诉ApplicationMaster哪些Containers可以用，ApplicationMaster还需要去找NodeManager请求分配具体的Container。

1.2 NodeManager

NodeManager 运行在集群的节点上，每个节点都有自己的NodeManager。他负责接受ResourceManager的资源分配请求，分配给具体的Container应用。同时负责将自身的检测信息传输给ResourceManager。通过和ResourceManager配合，NodeManager负责整个Hadoop集群中的资源分配工作。

ResourceManager是一个全局的进程，而NodeManager只是每个节点上的进程，管理这个节点上的资源分配和监控运行节点的健康状态。

当一个节点启动时，它会向ResourceManager进行注册并告知ResourceManager自己有多少资源可用。在运行期，通过NodeManager和ResourceManager协同工作，这些信息会不断被更新并保障整个集群发挥出最佳状态。

NodeManager只是负责监控Container，并不知道里面运行着什么

• 接收ResourceManager的请求，分配Container给应用的某个任务
• 和ResourceManager交换信息以确保整个集群平稳运行。ResourceManager就是通过收集每个NodeManager的报告信息来追踪整个集群健康状态的，而NodeManager负责监控自身的健康状态。
• 管理每个Container的生命周期
• 管理每个节点上的日志
• 执行Yarn上面应用的一些额外的服务，比如MapReduce的shuffle过程

1.3 ResourceManager

ResourceManager的主要主件有两个：Scheduler，ApplicationManager

• Scheduler：资源调度器，主要协调集群中个资源的分配，保证整个集群运行效率。Scheduler只是一个调度器，只是负责分配Container，并不会监控以及管理Container的状态以及运行的任务。同样，也不会处理任务失败硬件错误等等；
• ApplicationManager：主要负责任务的提交，为应用分配一个Container用来运行ApplicationMaster，同时负责监控ApplicationMaster，在任务失败时会重启ApplicationMaster；

1.4 ApplicationMaster

ApplicationMaster负责向ResourceManager申请资源并和NodeManager协同工作来运行各个应用，同时跟踪他们的状态以及每个任务的运行，遇到失败后负责重启他们

在MR1中，JobTracker即负责资源请求调度，同时还负责对Job的监控。在MR2中对任务的监控交给了ApplicationMaster。

yarn相对与MR1来说优势有哪些呢？

• 这个设计大大减小了 ResourceManager 的资源消耗，并且让监测每一个 Job 子任务 (tasks) 状态的程序分布式化了，更安全、更优美。
• 在新的 Yarn 中，ApplicationMaster 是一个可变更的部分，用户可以对不同的编程模型写自己的 AppMst，让更多类型的编程模型能够跑在 Hadoop 集群中，可以参考 hadoop Yarn 官方配置模板中的 mapred-site.xml 配置。
• 对于资源的表示以内存为单位 ( 在目前版本的 Yarn 中，没有考虑 cpu 的占用 )，比之前以剩余 slot 数目更合理。
• 老的框架中，JobTracker 一个很大的负担就是监控 job 下的 tasks 的运行状况，现在，这个部分就扔给 ApplicationMaster 做了，而 ResourceManager 中有一个模块叫做 ApplicationsManager，它是监测 ApplicationMaster 的运行状况，如果出问题，会将其在其他机器上重启。
• Container 是 Yarn 为了将来作资源隔离而提出的一个框架。这一点应该借鉴了 Mesos 的工作，目前是一个框架，仅仅提供 java 虚拟机内存的隔离 ,hadoop 团队的设计思路应该后续能支持更多的资源调度和控制 , 既然资源表示成内存量，那就没有了之前的 map slot/reduce slot 分开造成集群资源闲置的尴尬情况。

2. Yarn中的资源请求

2.1应用提交过程

mark

1. Client向Resource Manager提交任务并请求创建一个ApplicationMaster
2. ResourceManager会找到一个可以运行Container的NodeManager创建一个Container并运行ApplicationMaster
3. ApplicationMaster创建完成以后会向ResourceManager进行注册，注册完成后Client就可以查询ResourceManager来获取ApplicationMaster的详细信息，以及和ApplicationMaster进行交互
4. 运行起来后做些什么依赖程序本身，可能进行一个简单的计算后返回给客户端，或者向ResourceManager请求更多的Container用于分布式计算。以下是请求更多资源的流程
   • Yarn允许程序指定依照本地化对Node Manager进行限制
5. 当Container被成功分配之后，ApplicationMaster通过向NodeManager发送container-launch-specification信息来启动Container， container-launch-specification信息包含了能够让Container和ApplicationMaster交流所需要的资料
6. 应用程序的代码在启动的Container中运行，并把运行的进度、状态等信息通过application-specific协议发送给ApplicationMaster
7. 在应用程序运行期间，提交应用的客户端主动和ApplicationMaster交流获得应用的运行状态、进度更新等信息，交流的协议也是application-specific协议
8. 一但应用程序执行完成并且所有相关工作也已经完成，ApplicationMaster向ResourceManager取消注册然后关闭，用到所有的Container也归还给系统

2.2 Resource Request和Container

Yarn的设计目标就是允许我们的各种应用以共享、安全、多租户的形式使用整个集群。并且，为了保证集群资源调度和数据访问的高效性，Yarn还必须能够感知整个集群拓扑结构。为了实现这些目标，ResourceManager的调度器Scheduler为应用程序的资源请求定义了一些灵活的协议，通过它就可以对运行在集群中的各个应用做更好的调度，因此，这就诞生了Resource Request和Container。

具体来讲，一个应用先向ApplicationMaster发送一个满足自己需求的资源请求，然后ApplicationMaster把这个资源请求以resource-request的形式发送给ResourceManager的Scheduler，Scheduler再在这个原始的resource-request中返回分配到的资源描述Container。每个ResourceRequest可看做一个可序列化Java对象，包含的字段信息如下：

• resource-name：资源名称，现阶段指的是资源所在的host和rack，后期可能还会支持虚拟机或者更复杂的网络结构
• priority：资源的优先级
• resource-requirement：资源的具体需求，现阶段指内存和cpu需求的数量
• number-of-containers：满足需求的Container的集合

number-of-containers中的Containers就是ResourceManager给ApplicationMaster分配资源的结果。Container就是授权给应用程序可以使用某个节点机器上CPU和内存的数量。

2.3 各组件之间心跳信号

ApplicationMaser && ResourceManager

• AM -> RM
  • 对Container资源请求和优先级
  • 已完成的Container
• RM ->AM
  • 新申请到的Container信息

ApplicationMaster && NodeManager

• AM -> NM
  • 启动Container请求
• NM -> AM
  • Container状态

NodeManager && ResourceManager

• NM -> RM
  • NodeManager上所有Container状态
• RM -> NM
  • 已删除和等待清理的Container列表

3. Yarn中的资源调度

• FIFO
• Capacity Scheduler
• Fair Scheduler

FIFO 调度器

FIFO调度器将所有的应用放置到一个队列当中，然后采用先进先出的顺序运行应用。首先第一个应用进来请求资源，直到请求资源被全部满足以后再进行对下一个任务的资源调度

优点

• 简单易懂
• 方便配置

缺点

• 资源利用率不高
• 不允许资源抢占
• 不适合在共享集群上使用

Capacity Scheduler 容量调度器

允许多个组织共享一个Hadoop集群，每个组织分配到全部集群的一部分。每个组织有一个专门的队列，每个队列被配置为一定的集群资源。队列可以进一步划分，这样每个队列中的不用用户可以共享队列中所分配的资源。

• 保证每个任务都有最低资源保证
• 当队列空闲时，其他资源允许分配给其他队列使用
• 单个队列内部支持FIFO
• 综合考虑多方面因素，防止单个作业、用户或者队列占领全部资源
• 支持内存资源和CPU资源的调度

Fair Scheduler 公平调度器

根据队列数量对资源进行公平分配