1, YARN 概述
YARN 是“ Yet Another Resource Negotiator”的简称。在进一步了解 YARN 框架之前我们需要知道，相比较而言， MapReduce 则是 YARN 的一个特例。 YARN 则是 MapReduce 的一个更加通用和高级的框架形式，并在其上增加了更多的功能。例如通过加载分布式执行脚本可以在集群节点上执行独立的脚本任务，并且更多功能正在被追加中。所以我们可以看到，YARN 可以直接运行在 MapReduce 运行的框架上而不会造成更多的干扰，并且会为集群的运算带来更多的好处。更一步的开发显示了 YARN 会允许开发者根据自己的需求运行不同版本的 MapReduce 在集群中，这将为开发者提供更为便捷的服务。
普遍认为，云计算包括以下几个层次的服务: IaaS、PaaS和SaaS。这里所谓的层次，是分层体系架构意义上的“层次”。laas. Paas、 Saas分别实现在基础设施层、软件开放运行平台层、应用软件层。
IaaS(Infrastructure-as-a-Service):基础设施即服务。消费者通过Internet可以从完善的计算机基础设施获得服务。laas 通过网络向用户提供计算机(物理机和虚拟机)、存储空间、网络连接、负载均衡和防火墙等基本计算资源;用户在此基础上部署和运行各种软件，包括操作系统和应用程序等。
PaaS(Platform-as-a-Service):平台即服务。PaaS 是将软件研发的平台作为一种服务，以SaaS的模式提交给用户。平台通常包括操作系统、编程语言的运行环境、数据库和Web服务器等，用户可以在平台上部署和运行自己的应用。通常而言，用户不能管理和控制底层的基础设施，只能控制自已部署的应用。
SaaS(Software-as-a-Service):软件即服务。它是一种通过Internet提供软件的模式，用户无需购买软件，而是向提供商租用基于Web的软件，来管理企业经营活动。云提供商在云端安装和运行应用软件，云用户通过云客户端(比如Web浏览器)使用软件。
从云计算分层概念上讲，YARN可看做PAAS层，它能够为不同类型的应用程序提供统一的管理和调度。
关于上图架构 ,主要包括以下几种角色
ResourceManager(RM)：主要接收客户端任务请求，接收和监控NodeManager(NM)的资源情况汇报，负责资源的分配与调度，启动和监控ApplicationMaster(AM)。
NodeManager：主要是节点上的资源管理，启动Container运行task计算，上报资源、container情况给RM和任务处理情况给AM。
ApplicationMaster：主要是单个Application(Job)的task管理和调度，向RM进行资源的申请，向NM发出launch Container指令，接收NM的task处理状态信息。
ResourceManager是Yarn的核心, 负责调度Application master, 来给每个NodeManager分配资源, 资源储存在Container中, 此处的资源包括JVM,内存等, 然后将程序copy到container中运行, container还需要回报状态给App master, 再有app master汇报给Resource manager, nodeManager也要按时汇报ResourceManager当前节点的资源使用情况.
下面简单介绍以下提交一个job的处理过程
1、client submit一个job到RM，进入RM中的Scheduler队列供调度(Scheduler负责申请资源)
2、RM根据NM汇报的资源情况(NM会定时汇报资源和container使用情况)，请求一个合适的NM launch container，以启动运行AM
3、AM启动后，注册到RM上，以使client可以查到AM的信息，便于client直接和AM通信
4、AM启动后，根据Job 相关的split的task情况，会和RM协商申请container资源
5、RM分配给AM container资源后，根据container的信息，向对应的NM 请求launch container
6、NM启动container运行task，运行过程中向AM汇报进度状态信息，类似于MRv1中 task的汇报；同时NM也会定时的向RM汇报container的使用情况。
7、在application(job)执行过程中，client可以和AM通信，获取application相关的进度和状态信息。
8、在application(job)完成后，AM通知RM clear自己的相关信息，并关闭，释放自己占用的container。
yarn分为一级调度管理和二级调度管理
一级调度管理(更近底层,更接近于操作资源, 更偏向于应用层和底层结合)
计算资源管理(cpu,内存等,计算复杂消耗的cpu多)
App生命周期管理
二级调度管理(自己代码的算法等, 更偏向于应用层)
App内部的计算模型管理
多样化的计算模型
全局的资源管理器，整个集群只有一个，负责集群资源的统一管理和调度分配。
功能: 处理客户端请求
启动/监控ApplicationMaster
监控NodeManager
资源分配与调度
管理一个在YARN 内运行的应用程序的每个实例
功能
数据切分
为应用程序申请资源，并进一步分配给内部任务
任务监控与容错
负责协调来自ResourceManager的资源，幵通过NodeManager监视容器的执行和资源使用（CPU、内存等的资源分配）。
整个集群有多个，负责单节点资源管理和使用
功能
单个节点上的资源管理和任务管理
处理来自ResourceManager的命令
处理来自ApplicationMaster的命令
NodeManager管理抽象容器，这些容器代表着可供一个特定应用程序使用的针对每个节点的资源。
定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态。
YARN中的资源抽象，封装某个节点上多维度资源，如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM向AM返回的资源便是用Container表示的。YARN 会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。
功能
对任务运行环境的抽象
描述一系列信息
任务运行资源（节点、内存、CPU）
任务启动命令
任务运行环境
其他组件还包括
作业历史服务,记录历史情况 , 通过mr-jobhistory-daemon.sh start historyserver 来启动, 启动成功会出现JobHistoryServer进程 , 并且可以从19888端口进行查看日志详细信息
用来写日志服务数据 , 一般来写与第三方结合的日志服务数据(比如spark等)
YARN利用异步模型对MapReduce框架的一些关键逻辑结构（如JobInprogress、TaskInProgress等）进行了重写，相比于MRv1，具有更快地计算速度。
YARN不再是一个单纯的计算框架，而是一个框架管理器，用户可以将各种各样的计算框架移植到YARN之上。
在YARN中，各种计算框架不再是作为一个服务部署到集群的各个节点上（比如MapReduce框架，不再需要部署JobTracler、TaskTracker等服务），而是被封装成一个用户程序库（lib）存放在客户端，当需要对计算框架进行升级时，只需升级用户程序库即可。
RPC协议是连接各个组件的“大动脉”，了解不同组件之间的RPC协议有助于我们更深人地学习YARN框架。在YARN中，任何两个需相互通信的组件之间仅有一个RPC协议，面对于任何一个RPC协议，通信双方有一端是Client, 另一端为Server, 且Client总是主动连接 Server的，因此，YARN实际上采用的是拉式(ull-based) 通信模型。如下图所示，箭头指向的组件是RPC Server, 而箭头尾部的组件是RPC Client, YARN主要由以下几个RPC协议组成:
(1)JobClient(作业提交客户端)与RM之间的协议---ApplicationClientProtocol :
JobClient通过该RPC协议提交应用程序、查询应用程序状态等。
(2)Admin(管理员)与RM之间的通信协议----ResourceManagerAdministrationProtocol:
Admin通过该RPC协议更新系统配置文件，比如节点黑白名单、用户队列权限等。
(3)AM与RM之间的协议一ApplicationMasterProtocol: AM通过该RPC协议向RM注册和撒销自己，并为各个任务申请资源。
(4)AM与NM之间的协议一-ContainerManagementProtocol: AM通过该RPC要求NM启动或者停止Container,获取各个Container的使用状态等信息。
(5)NM与RM之间的协议一-ResuceTracker: NM通过该RPC协议向RM注册，并定时发送心跳信息汇报当前节点的资源使用情况和Container运行情况。
资源调度和资源隔离是YARN作为一个资源管理系统，最重要和最基础的两个功能。资源调度由ResourceManager完成，而资源隔离由各个NM实现。
ResourceManager将某个NodeManager上资源分配给任务（这就是所谓的“资源调度”）后，NodeManager需按照要求为任务提供相应的资源，甚至保证这些资源应具有独占性，为任务运行提供基础的保证，这就是所谓的资源隔离。
当谈及到资源时，我们通常指内存，CPU和IO三种资源。Hadoop YARN同时支持内存和CPU两种资源的调度。
内存资源的多少会会决定任务的生死，如果内存不够，任务可能会运行失败；相比之下，CPU资源则不同，它只会决定任务运行的快慢，不会对生死产生影响。
YARN允许用户配置每个节点上可用的物理内存资源，注意，这里是“可用的”，因为一个节点上的内存会被若干个服务共享，比如一部分给YARN，一部分给HDFS，一部分给HBase等，YARN配置的只是自己可以使用的，配置参数如下：
(1) yarn.nodemanager.resource.memory-mb
表示该节点上YARN可使用的物理内存总重，默认是8192(MB)，注意，如果你的节点内存资源不够8CB,则懦要调减这个值，而YARN不会智能的探测节点的物理内存总里。
(2) yarn.nodemanager.vmem-pmem-ratio
任务每使用1MB物理内存，最多可使用虚拟内存里，默认是2.1.
(3) yarn.nodemanager.pmem-check-enabled
是否启动一个线程检查每个任务正使用的物理内存里，如果任务超出分配值，则直接将其杀掉，默认是true
(4) yarn.nodemanager.vmem-check-enabled
是否启动一个线程检查每个任务正使用的虚拟内存里，如果任务超出分配值，则直接将其杀掉，默认是true
(5) yarn.scheduler.minimum-allocation-mb
单个任务可申请的最少物理内存里，默认是1024(MB)，如果一个任务申请的物理内存重少于该值，则该对应的值改这个数。
(6) yarn.scheduler.maximum-allocation-mb
单个任务可申请的最多物理内存里，默认是8192(MB)。
默认情况下，YARN采用了线程监控的方法判断任务是否超量使用内存，一旦发现超量，则直接将其杀死。由于Cgroups对内存的控制缺乏灵活性（即任务任何时刻不能超过内存上限，如果超过，则直接将其杀死或者报OOM），而Java进程在创建瞬间内存将翻倍，之后骤降到正常值，这种情况下，采用线程监控的方式更加灵活（当发现进程树内存瞬间翻倍超过设定值时，可认为是正常现象，不会将任务杀死），因此YARN未提供Cgroups内存隔离机制。
目前的CPU被划分成虚拟CPU（CPU virtual Core），这里的虚拟CPU是YARN自己引入的概念，初衷是，考虑到不同节点的CPU性能可能不同，每个CPU具有的计算能力也是不一样的，比如某个物理CPU的计算能力可能是另外一个物理CPU的2倍，这时候，你可以通过为第一个物理CPU多配置几个虚拟CPU弥补这种差异。用户提交作业时，可以指定每个任务需要的虚拟CPU个数。在YARN中，CPU相关配置参数如下：
(1) yarn.nodemanager.resource.cpu-vcores
表示该节点上YARN可使用的虚拟CPU个数, 默认是8.注意.目前推荐将该值设为与物理CPU核数数目相同,如果你的节点CPU核数不8个,则懦要调小这个值,而YARN不会智能的探测点物理CPU总数.
(2) yarn.scheduler.minimum-allocation-vcores
单个任务可申请的最小虚拟cpu个数默认是1, 如果一个任务申请的CPU个数少于该数.则该对应的值改为这个数.
(3) yarn.scheduler.maximum-allocation-vcores
单个任务可申请的最多虚拟CPU个数,默认是32。
用户向YARN ResourceManager提交应用程序，RM收到提交申请后，先向资源调度器申请用以启动AM 的资源，待申请到资源后，再由ApplicationMasterLauncher与对应的NodeManager通信，从而启动应用程序的ApplicationMaster。
ApplicationMaster启动完成后，ApplicationMasterLaucher会通过事件的形式，将刚刚启动的Application Master注册到AMLiveMonitor，以启动心跳监控。
ApplicationMaster启动后，先向ApplicatinMaterService注册，并将自己所在host、端口号等信息汇报给它。
AM运行过程中，周期性地向ApplicationMaserService回报心跳信息（信息中包含想要申请的资源描述）。
ApplicationMasterService每次收到ApplicationMaster心跳信息好后，将通知AMLivelinessMonitor更新应用程序的最新回报心跳的时间。
应用程序运行完成后，AM向AMService发送请求，注销自己。
AMService收到注销请求后，标注应用程序运行状态完成，同时通知AMLivelinessMonitor移除对它的心跳监控。