(4)Yarn架构、资源管理原理和运维技术介绍

专栏目录

(1)大数据和应用场景介绍

(2)大数据技术综述总结

(3)HDFS原理与高可用技术原理介绍

(4)Yarn架构、资源管理原理和运维技术介绍

(5)Kafka原理和高可用介绍

1.Yarn简介

---

(1)经典Hadoop1.X问题

     在Hadoop1.X版本时的资源调度是由一个主节点JobTracker和多个从节点TaskTracker来协同完成，可以看出它是一个主从架构。其中

• JobTracker负责 资源管理和作业调度
• TaskTracker负责汇报本节点的健康状况、资源使用、任务执行情况和执行JobTracker的命令，如启动、停止任务等。

    最大的问题在资源管理策略：

    ① 主节点JobTracker既要负责集群的资源管理又要负责作业任务的调度，这导致工作繁重， 资源过度消耗，又限制了集群的扩张。随着节点规模的增大，成为了集群的瓶颈。

    ②典型单点故障，发生故障集群都崩。

    ③资源描述过于简单，资源利用率低。TaskTracker强制把资源划分为 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。

    ②核心思想：将JobTracker的两个主要职责：资源管理与作业调度进行拆分，分别交给两个角色负责——一全局ResourceManager，每个应用一个ApplicationMaster。 ResourceManager负责全局的资源管理和调度，ApplicationMaster作为一个进程运行在NodeManager节点上，负责单个应用的作业任务管理。

    ③集群资源容器Container：参考Docker容器和Kubernetes管理容器原理

 

(2)架构角色

①资源管理：ResourceManager（RM）

     作为主节点和全局资源管理器，主要负责管理和调度集群的整体资源。

• 对Container的分配管理，将系统资源(内存、CPU)分配给各个在集群上运行的作业。首先确定作业需要多少资源，然后将资源分配给Container (作业和容器类似线程和进程的关系)，从而限定每个作业使用的资源量。
• 负责启动ApplicationMaster， 监控ApplicationMaster的运行状态并在失败时重新启动，跟踪已分配的Container的进度和状态等职责（通过 心跳机制接收NodeManager的资源上报信息）。

②容器管理：NodeManager（NM）

     NodeManager是每个节点上的资源和任务管理器，他会定时的通过 心跳机制向ResourceManager汇报本节点上的 资源使用情况和各个Container的运行状态，同时 会接收并处理来自ApplicationMaster的各种Container启动、停止请求。

③应用管理：ApplicationMaster（AM）

    用户向集群提交的每一个应用均包含一个ApplicationMaster， 它负责某一个作业的执行和监控。ApplicationMaster是应用框架，由用户提交，ApplicationMaster负责向ResourceManager协调资源，并且与NodeManager协同工作完成作业的执行和监控。YARN为MapReduce和Spark等计算框架提供了ApplicationMaster的实现。

【待补充思考：到底什么是应用？】

(3)工作机制

1. 程序提交：用户通过主节点RM向YARN中提交一个作业，其中包括AM程序，AM启动命令，参数，用户程序等准确描述运行AM进程的信息。
2. 启动AM：RM为该作业分配第一个Container，并与对应的NM通信，要求它在这个Container中启动AM。        
3. 注册AM申请资源：AM首先向RM注册（这样用户以后能在RM查看应用程序的运行状态），然后AM将切分作业并为多个任务向RM申请资源。 
4. 分配AM资源：RM收到AM的请求后为这些任务分配资源，但是RM并不会主动把申请到的资源交给AM，而是由AM通过心跳机制采用轮询的方式向RM领取已经分配的资源，并且这个过程是异步的（以MapReduce分步骤拿资源为例：AM会先拿到Map task所要用到的资源并进行执行之后，再去拿Reduce Task所要使用的资源）。 
5. 协调容器各任务资源：一旦AM拿到资源，便会与NM通信，要求它们创建Container并在Container中运行切分好的各个任务（以MapReduce为例，Container中运行的就是一个Map Task或者Reduce Task）。AM会定时监控这些任务的状态和运行进度，以让AM随时掌握各个任务的运行情况，NM也会定时向RM汇报自己所拥有Container的情况（如每个Spark任务运行时，我们可以看到DAG运行图）。
6. 释放资源：当任务运行完成时，AM会向RM注销，并关闭自己。

3.Yarn高可用原理

---

(1)高可用架构

    ①与HDFS相同点：YARN的高可用依然是至少两台ResourceManager主节点：一台ActiveResourceManager一台StandbyResourceManager。 然后实现主节点间的自动切换。

    ②不同点：

• Zookeeper既负责Active节点的选举，又负责恢复ActiveResourceManager的原有状态信息。 也就是说Zookeeper在YARN的高可用实现中，除了负责Active节点的选举之外，还负责同步ResourceManager的状态信息，来满足主备节点切换时的状态信息一致性。
• ResourceManager有一个内嵌的基于Zookeeper的 ActiveStandbyElector去决定哪个ResourceManager应该是Active。当ActiveResourceManager宕机，另外一个ResourceManager将会自动被选举为Active，然后接手工作，并且这里不像HDFS高可用机制， 我们需要启动一个ZKFC的守护进程，因为内嵌的ActiveStandbyElector已经替代ZKFC，进行失败检测，和主备切换。

4.Yarn调度策略(核心)

---

(1)FIFO调度

• 默认调度器。
• 先进先出调度，按照作业的提交顺序进行运行。在此调度器中 只有一个队列供所有用户共享，无法干涉资源的使用。按提交的顺序排成一个队列，在进行资源分配的时候，先给队列中最靠前的作业进行资源分配，之后的作业保持阻塞，以此类推。

    ①优点：实现容易。

    ② 缺点：资源利用率低，无法交叉运行作业。不够灵活，比如紧急的作业无法插队等，在一般生产环境中不推荐使用。

 

(2)Capacity Scheduler调度（重点技术）

   支持多队列，并进一步细分，即 支持层级化队列，这使得该调度器对集群资源的使用率极高。 每个队列都有队列的访问权限控制，并且集群内空闲的资源可以额外分配给任何需要的队列，但是每个队列都要预设资源的分配比例，并且 在每个队列的内部依然使用的是FIFO的调度策略，队列内不支持资源抢占。

    【特点如图】

     ①优点：用于在共享或者多租户的集群环境中使用，在最大化吞吐量的前提下对多任务的运行尽可能的友好。  

     ②缺点：待补充。

(3)Fair Scheduler调度（“抢占式公平”）

• 核心思想： 尽可能的公平的调度，即资源占用量少的作业尽量优先完成。尽可能的使得每个应用都能够得到尽量相当的资源，并且使用无需预先设定资源的分配比例。
• 公平调度同样是多队列，并且每个队列同样拥有队列的访问权限控制，但是他和容量调度不同的是， Fair Schedule单一队列内部不再是FIFO策略，而是采用了公平调度策略（默认），支持抢占。这种策略使得 运行时间短的应用能够尽快结束，而不至于在等待资源时被饿死（短作业优先级更高）。
• 也可以 为队列配置权重，权重用于决定资源使用量的占比。 特别要注意的是，在 有新任务提交后，并不是马上执行，而是等待一小段时间后开始执行，这一小段时间用于资源抢占时前一个任务释放一部分占用资源。