Yarn 详解

2019-07-24 14:40:09 浏览数 (1)

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应用提交过程
  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 公平调度器

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

0 人点赞