简介

1.0跟2.0的区别

在Yarn中我们把job的概念换成了application，因为在新的Hadoop2.x中，运行的应用不只是MapReduce了，还有可能是其它应用如一个DAG（有向无环图Directed Acyclic Graph，例如storm应用）。Yarn的另一个目标就是拓展Hadoop，使得它不仅仅可以支持MapReduce计算，还能很方便的管理诸如Hive、Hbase、Pig、Spark/Shark等应用。这种新的架构设计能够使得各种类型的应用运行在Hadoop上面，并通过Yarn从系统层面进行统一的管理，也就是说，有了Yarn，各种应用就可以互不干扰的运行在同一个Hadoop系统中，共享整个集群资源，如下图所示：

yarn

Yarn的特点

良好的扩展性,高可用
对多种,多版本类型应用进行统一管理和调度
自带了多种用户调度器(例如, FIFO, Faire公平调度),适合共享集群环境
相对比传统模式,提高了资源利用率,降低了运维成本和数据共享成本

Yarn的组件及架构

1.0与2.0比较.jpg

1. ResourceManager：Global（全局）的进程 
2. NodeManager：运行在每个节点上的进程
3. ApplicationMaster：Application-specific（应用级别）的进程
- *Scheduler：是ResourceManager的一个组件*
- *Container：节点上一组CPU和内存资源*

Yarn的工作流程

工作流程

1.客户端程序向ResourceManager提交应用并请求一个ApplicationMaster实例(一个任务对应一个ApplicationMaster实例)
2.ResourceManager找到可以运行一个Container的NodeManager，并在这个Container中启动ApplicationMaster实例(RM按照任务的上下文(context)信息,跟NodeManager的状态信息)
3.ApplicationMaster向ResourceManager进行注册(同时请求相对应的资源)，注册之后客户端就可以查询ResourceManager获得自己ApplicationMaster的详细信息，以后就可以和自己的ApplicationMaster直接交互了
4.在平常的操作过程中，ApplicationMaster根据resource-request协议向ResourceManager发送resource-request请求(实时的进行状态的汇报)
5.当Container被成功分配之后，ApplicationMaster通过向NodeManager发送container-launch-specification信息来启动Container， container-launch-specification信息包含了能够让Container和ApplicationMaster交流所需要的资料
6.应用程序的代码在启动的Container中运行，并把运行的进度、状态等信息通过application-specific协议发送给ApplicationMaster(通过RPC的模式汇报给AM)
7.在应用程序运行期间，提交应用的客户端主动和ApplicationMaster交流获得应用的运行状态、进度更新等信息，交流的协议也是application-specific协议
8.一但应用程序执行完成并且所有相关工作也已经完成，ApplicationMaster向ResourceManager取消注册然后关闭，用到所有的Container也归还给系统
当AM挂掉的时候,RM会重新生成一个AM
当Container挂掉,AM会重新申请一个Contatiner继续执行任务

Container(类似 1.0里面的 slot,但是slot是物理层,container是逻辑层)

Container是Yarn框架的计算单元，是具体执行应用task（如map task、reduce task）的基本单位。Container和集群节点的关系是：一个节点会运行多个Container，但一个Container不会跨节点。
Container只是使用NM上指定资源的权利
AM必须向NM提供更多的信息来启动Container
描述任务的运行资源(节点,内存,cpu),启动命令和运行环境
一个Container指的是具体节点上的计算资源，这就意味着Container中必定含有计算资源的位置信息：计算资源位于哪个机架的哪台机器上。所以我们在请求某个Container时，其实是向某台机器发起的请求，请求的是这台机器上的CPU和内存资源。
任何一个job或application必须运行在一个或多个Container中，在Yarn框架中，ResourceManager只负责告诉ApplicationMaster哪些Containers可以用，ApplicationMaster还需要去找NodeManager请求分配具体的Container。

ResourceManager

ResourceManager有点类似于JobTracker，它有两个主要的组件:调度器(Scheduler)和应用程序管理器(ApplicationManager)
RM拥有为系统中所有应用资源分配的决定权是中心服务,做的事情就是调度,启动每一个job所属的Application,另外监控Application的存在情况
与运行在每个节点上的NM进程交互,通过心跳通信,达到监控NM的目的
Scheduler是一个资源调度器，它主要负责协调集群中各个应用的资源分配，保障整个集群的运行效率。Scheduler的角色是一个纯调度器，它只负责调度Containers，不会关心应用程序监控及其运行状态等信息。同样，它也不能重启因应用失败或者硬件错误而运行失败的任务
Scheduler是一个可插拔的插件，它可以调度集群中的各种队列、应用等。在Hadoop的MapReduce框架中主要有两种Scheduler：Capacity Scheduler和Fair Scheduler，关于这两个调度器后面会详细介绍。
另一个组件ApplicationManager主要负责接收job的提交请求，为应用分配第一个Container来运行ApplicationMaster，还有就是负责监控和状态跟踪ApplicationMaster，在遇到失败时重启ApplicationMaster运行的Container。

Application Master

ApplicationMaster的主要作用是向ResourceManager申请资源并和NodeManager协同工作来运行应用的各个任务然后跟踪它们状态及监控各个任务的执行，遇到失败的任务还负责重启它。
每一个应用对应一个AM,在用户提交一个应用程序时,一个AM的轻量型进程实例会启动,AM协调应用程序内的所有任务的执行
与RM协商资源,与Scheduler协商合适的Container
与NM协同工作与Scheduler协商合适的Container进行Container的监控
是一个普通Container的身份运行

Node Manager

NodeManager类似于TaskTracker,它负责启动应用程序Container(类似于JVM)，监控Container的资源(cpu,内存，磁盘，网络等),并将信息上报给ResourceManager.调度器就是根据应用程序的Container进行调度的
NodeManager进程运行在集群中的节点上，每个节点都会有自己的NodeManager。NodeManager是一个slave服务：它负责接收ResourceManager的资源分配请求，分配具体的Container给应用。同时，它还负责监控并报告Container使用信息给ResourceManager。通过和ResourceManager配合，NodeManager负责整个Hadoop集群中的资源分配工作。ResourceManager是一个全局的进程，而NodeManager只是每个节点上的进程，管理这个节点上的资源分配和监控运行节点的健康状态。下面是NodeManager的具体任务列表：

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

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

NodeManager只负责管理自身的Container，它并不知道运行在它上面应用的信息。负责管理应用信息的组件是ApplicationMaster.

架构

Yarn最基本的设计思想是将JobTracker的两个主要功能,即资源管理和作业调度、监控分成两个独立的进程。
在该解决方案中包含两个组件:

全局的ResourceManager(RM)、
与每一个应用相关的ApplicationManager(AM)
这里，“应用”指的是一个单独的MapReduce 作业或DAG作业。RM与NM(NodeManager)共同组成整个计算框架。
RM是系统中将资源分配给各个应用的最终决策者
AM实际上是一个具体的框架库，它的任务是与RM协商获取应用所需资源和与NM合作,以完成执行和监控Task的任务

问题

1.0 跟 2.0的区别,优化了什么?
- 这个设计大大减小了 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 分开造成集群资源闲置的尴尬情况。
ClientRMProtocol协议?
ApplicationMaster的对比优势?
- 在MR1中，JobTracker即负责job的监控，又负责系统资源的分配。而在MR2中，资源的调度分配由ResourceManager专门进行管理，而每个job或应用的管理、监控交由相应的分布在集群中的ApplicationMaster，如果某个ApplicationMaster失败，ResourceManager还可以重启它，这大大提高了集群的拓展性。
- 在MR1中，Hadoop架构只支持MapReduce类型的job，所以它不是一个通用的框架，因为Hadoop的JobTracker和TaskTracker组件都是专门针对MapReduce开发的，它们之间是深度耦合的。Yarn的出现解决了这个问题，关于Job或应用的管理都是由ApplicationMaster进程负责的，Yarn允许我们自己开发ApplicationMaster，我们可以为自己的应用开发自己的ApplicationMaster。这样每一个类型的应用都会对应一个ApplicationMaster，一个ApplicationMaster其实就是一个类库。这里要区分ApplicationMaster类库和ApplicationMaster实例，一个ApplicationMaster类库何以对应多个实例，就行java语言中的类和类的实例关系一样。总结来说就是，每种类型的应用都会对应着一个ApplicationMaster，每个类型的应用都可以启动多个ApplicationMaster实例。所以，在yarn中，是每个job都会对应一个ApplicationMaster而不是每类。

Yarn(Hadoop2.0)学习笔记(一)

简介