1.Yarn简介
(1)经典Hadoop1.X问题
在Hadoop1.X版本时的资源调度是由一个主节点JobTracker和多个从节点TaskTracker来协同完成，可以看出它是一个主从架构。其中
- JobTracker负责 资源管理和作业调度
- TaskTracker负责汇报本节点的健康状况、资源使用、任务执行情况和执行JobTracker的命令，如启动、停止任务等。
最大的问题在资源管理策略：
资源过度消耗，又限制了集群的扩张。随着节点规模的增大，成为了集群的瓶颈。
②典型单点故障，发生故障集群都崩。
Map Task Slot和Reduce Task Slot两类， 并且TaskTracker仅仅把Task的数量看做资源，并没有考虑CPU、内存等实际资源。
④ 扩展性较差。因为JobTrackerHadoop1.X资源管理策略仅支持MapReduce计算框架 （Hadoop1.X中NameNode节点管理的元信息有限，而JobTracker只允许有一个，导致管理的节点有限)。
【补充：JobTracker和NameNode区别】
- NameNode主要用于管理元数据信息及DataNode运行管理，不涉及到具体存储数据和计算框架
- JobTracker站在计算框架的角度，一般计算分为资源管理和任务调度(哪个节点完成任务)。但JobTracker这一点做的不理想。
(2)Yarn设计目标
Yarn诞生就是为了解决 资源管理和任务调度。 YARN（Yet Another Resource Negotiator）分布式通用资源管理框架，它作为一个专门的资源管理框架从MapReduce中分离出来，聚焦资源管理，通用性极强，适用于各种计算框架，并且具有很强的扩展性，同时支持高可用。从图中可知：
原有Hadoop框架被分分解为资源管理(Yarn)、数据存储(HDFS、Hbase)、计算(MapReduce)
2.Yarn架构原理
(1)Master/Slave架构思想
①经典主从架构：有一个主节点ResourceManager和多个从节点NodeManager。
ResourceManager负责全局的资源管理和调度，ApplicationMaster作为一个进程运行在NodeManager节点上，负责单个应用的作业任务管理。
③集群资源容器Container：参考Docker容器和Kubernetes管理容器原理
(2)架构角色
①资源管理：ResourceManager（RM）
作为主节点和全局资源管理器，主要负责管理和调度集群的整体资源。
- 对Container的分配管理，将系统资源(内存、CPU)分配给各个在集群上运行的作业。首先确定作业需要多少资源，然后将资源分配给Container (作业和容器类似线程和进程的关系)，从而限定每个作业使用的资源量。
- 监控ApplicationMaster的运行状态并在失败时重新启动，跟踪已分配的Container的进度和状态等职责（通过 心跳机制接收NodeManager的资源上报信息）。
②容器管理：NodeManager（NM）
NodeManager是每个节点上的资源和任务管理器，他会定时的通过 心跳机制向ResourceManager汇报本节点上的 资源使用情况和各个Container的运行状态，同时 会接收并处理来自ApplicationMaster的各种Container启动、停止请求。
③应用管理：ApplicationMaster（AM）
用户向集群提交的每一个应用均包含一个ApplicationMaster， 它负责某一个作业的执行和监控。ApplicationMaster是应用框架，由用户提交，ApplicationMaster负责向ResourceManager协调资源，并且与NodeManager协同工作完成作业的执行和监控。YARN为MapReduce和Spark等计算框架提供了ApplicationMaster的实现。
【待补充思考：到底什么是应用？】
(3)工作机制
- 程序提交：用户通过主节点RM向YARN中提交一个作业，其中包括AM程序，AM启动命令，参数，用户程序等准确描述运行AM进程的信息。
- 启动AM：RM为该作业分配第一个Container，并与对应的NM通信，要求它在这个Container中启动AM。
- 注册AM申请资源：AM首先向RM注册（这样用户以后能在RM查看应用程序的运行状态），然后AM将切分作业并为多个任务向RM申请资源。
- 分配AM资源：RM收到AM的请求后为这些任务分配资源，但是RM并不会主动把申请到的资源交给AM，而是由AM通过心跳机制采用轮询的方式向RM领取已经分配的资源，并且这个过程是异步的（以MapReduce分步骤拿资源为例：AM会先拿到Map task所要用到的资源并进行执行之后，再去拿Reduce Task所要使用的资源）。
- 协调容器各任务资源：一旦AM拿到资源，便会与NM通信，要求它们创建Container并在Container中运行切分好的各个任务（以MapReduce为例，Container中运行的就是一个Map Task或者Reduce Task）。AM会定时监控这些任务的状态和运行进度，以让AM随时掌握各个任务的运行情况，NM也会定时向RM汇报自己所拥有Container的情况（如每个Spark任务运行时，我们可以看到DAG运行图）。
- 释放资源：当任务运行完成时，AM会向RM注销，并关闭自己。
3.Yarn高可用原理
(1)高可用架构
①与HDFS相同点：YARN的高可用依然是至少两台ResourceManager主节点：一台ActiveResourceManager一台StandbyResourceManager。 然后实现主节点间的自动切换。
②不同点：
- 也就是说Zookeeper在YARN的高可用实现中，除了负责Active节点的选举之外，还负责同步ResourceManager的状态信息，来满足主备节点切换时的状态信息一致性。
- ActiveStandbyElector去决定哪个ResourceManager应该是Active。当ActiveResourceManager宕机，另外一个ResourceManager将会自动被选举为Active，然后接手工作，并且这里不像HDFS高可用机制， 我们需要启动一个ZKFC的守护进程，因为内嵌的ActiveStandbyElector已经替代ZKFC，进行失败检测，和主备切换。
4.Yarn调度策略(核心)
(1)FIFO调度
- 默认调度器。
- 只有一个队列供所有用户共享，无法干涉资源的使用。按提交的顺序排成一个队列，在进行资源分配的时候，先给队列中最靠前的作业进行资源分配，之后的作业保持阻塞，以此类推。
①优点：实现容易。
缺点：资源利用率低，无法交叉运行作业。不够灵活，比如紧急的作业无法插队等，在一般生产环境中不推荐使用。
(2)Capacity Scheduler调度（重点技术）
支持层级化队列，这使得该调度器对集群资源的使用率极高。 每个队列都有队列的访问权限控制，并且集群内空闲的资源可以额外分配给任何需要的队列，但是每个队列都要预设资源的分配比例，并且 在每个队列的内部依然使用的是FIFO的调度策略，队列内不支持资源抢占。
【特点如图】
①优点：用于在共享或者多租户的集群环境中使用，在最大化吞吐量的前提下对多任务的运行尽可能的友好。
缺点：待补充。
(3)Fair Scheduler调度（“抢占式公平”）
- 核心思想： 尽可能的公平的调度，即资源占用量少的作业尽量优先完成。尽可能的使得每个应用都能够得到尽量相当的资源，并且使用无需预先设定资源的分配比例。
- Fair Schedule单一队列内部不再是FIFO策略，而是采用了公平调度策略（默认），支持抢占。这种策略使得 运行时间短的应用能够尽快结束，而不至于在等待资源时被饿死（短作业优先级更高）。
- 为队列配置权重，权重用于决定资源使用量的占比。 特别要注意的是，在 有新任务提交后，并不是马上执行，而是等待一小段时间后开始执行，这一小段时间用于资源抢占时前一个任务释放一部分占用资源。
