这是我参与「第四届青训营 」笔记创作活动的第13天，这次记录了资源调度中的离线调度Yarn模块的学习笔记，希望大家多多指导。
Yarn的介绍
yarn是hadoop集群当中的资源管理系统模块
Hadoop 1.0 时代：由分布式存储系统 HDFS 和分布式计算框架 MapReduce(MR v1) 组成，MR v1 存在很多局限：
- 可扩展性差：JobTracker 兼备资源管理和任务控制，是系统最大的瓶颈
- 可靠性差：采用 master/slave 结构，master 存在单点故障问题
- 资源利用率低：基于槽位的资源分配模型，各槽位间资源使用差异大
- 无法支持多种计算框架：只支持 MR 任务，无法支持其他计算框架
Hadoop 2.0 时代：解决了 Hadoop 1.0 时代中 HDFS 和 MR 中存在的问题：
- YARN(MR v2) 在 MR v1 的基础上发展而来，将资源管理和任务控制解耦，分别由 Resource Manager 和 ApplicationMaster 负责，是一个两层调度系统
- Hadoop YARN(Yet Another Resource Negotiator) 支持多种计算框架的统一资源管理平台
Yarn核心出发点是为了分离资源管理与作业监控，实现分离的做法是拥有一个全局的资源管理(ResourceManager,RM)，以及每个应用程序对应一个的应用管理器（ApplicationMaster,AM）
其调度分为两个层级来说：
- 一级调度管理：计算资源管理（CPU，内存，网络IO，磁盘）
- 二级调度管理：任务内部的计算模型管理（AppMaster的任务精细化管理）
Yarn的组件
Yarn总体上是Master/Slave结构，主要由ResourceManager、NodeManager、ApplicationMaster和Container等几个组件构成。
Resource Manager
- 整个集群的大脑，负责为应用调度资源，管理应用生命周期
- 对用户提供接口，包括命令行接口，API， WebUI 接口
- 可以同时存在多个RM、，同一时间只有一个在工作，RM 之间通过 ZK 选主
Node Manager
- 为整个集群提供资源, 接受 Container 运行
- 管理Contianer的运行时生命周期, 包括Localization, 资源隔离, 日志聚合等
YARN上运行的作业在运行时会访问外部的数据服务，常见的如 HDFS， Kafka 等；在运行结束后由 YARN 负责将日志上传到 HDFS.
ResourceManager（RM）负责处理客户端请求，对各NM上的资源进行统一管理和调度。给ApplicationMaster分配空闲的Container运行并监控其运行状态。主要由两个组件构成：调度器和应用程序管理器：
- 调度器（Scheduler）：调度器根据容量、队列等限制条件，将系统中的资源分配给各个正在运行的应用程序。调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位是Container。Scheduler不负责监控或者跟踪应用程序的状态。总之，调度器根据应用程序的资源要求，以及集群机器的资源情况，为应用程序分配封装在Container中的资源。
- 应用程序管理器（Applicatios Manager）:应用程序管理器负责管理整个系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动等，跟踪分给的Container的进度、状态也是其职责。
NodeManager（NM）：NodeManager是每个节点上的资源和任务管理器。它会定时地向ResourceManager汇报本节点上的资源使用情况和各个Container的运行状态；同时会接受并处理来自ApplicationMaster的Container启动/停止等请求。
ApplicationMaster（AM）：用户提交的应用程序均包含一个ApplicationMaster，负责应用的监控，跟踪应用执行状态，重启失败任务等。ApplicationMaster是应用框架，它负责向ResourceManager协调资源，并且与NodeManager协同工作完成Task的执行和监控。
Container：Container是Yarn中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当ApplicationMaster向ResourceManager申请资源时，ResourceManager为ApplicationMaster返回资源便是用Container表示的。
yarn的结构和任务运行核心流程
yarn的调度器
yarn我们都知道主要是用于做资源调度，任务分配等功能的，那么在hadoop当中，究竟使用什么算法来进行任务调度就需要我们关注了，hadoop支持好几种任务的调度方式，不同的场景需要使用不同的任务调度器。
第一种调度器：FIFO Scheduler（队列调度）
把任务按提交的顺序排成一个队列，这是一个先进先出队列，在进行资源分配的时候，先给队列中最头上的任务进行分配资源，待最头上任务需求满足后再给下一个分配，以此类推。
FIFO Scheduler是最简单也是最容易理解的调度器，也不需要任何配置，但它并不适用于共享集群。大的任务可能会占用所有集群资源，这就导致其它任务被阻塞。
第二种调度器：Capacity Scheduler（容量调度器，apache版本默认使用的调度器）
Capacity调度器允许多个组织共享整个集群，每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列，然后再为每个队列分配一定的集群资源，这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。除此之外，队列内部又可以垂直划分，这样一个组织内部的多个成员就可以共享这个队列资源了，在一个队列内部，资源的调度是采用的是先进先出（FIFO）策略。
第三种调度器：Fair Scheduler（公平调度器，CDH版本的Hadoop默认使用的调度器）
Fair调度器的设计目标是为了所有的应用分配公平的资源（对公平的定义可以通过参数来设置）。公平调度也可以在多个队列间工作。举个例子，假设有两个用户A和B，他们分别拥有一个队列。当A启动一个Job而B没有任务时，A会获得全部集群资源；当B启动一个Job后，A的Job会继续运行，不过一会儿之后两个任务各自获得一半的集群资源。如果此时B再启动第二个Job并且其它Job还在运行，则它将会和B的第一个Job共享B这个队列的资源，也就是B的两个Job会用于四分之一的集群资源，而A的Job仍然用于集群一半的资源，结果就是资源最终再两个用户之间平等的共享。
任务运行核心流程
- Client 获取 ApplicationID，调用 ApplicationClientProtocol #getNewApplication。
- RM 返回 GetNewApplicationResponse，其中主要包括：ApplicationID、最大可申请资源以及相关配置。
- Client 将任务运行所需的资源上传至HDFS的指定目录下，并初始化AM配置，主要构造 ApplicationSubmissionContext （应用ID、应用名称、所属队列、应用优先级、应用类型、应用尝试次数、运行AM所需要的资源等）和 ContainerLaunchContext（容器运行所需的本地资源、容器持有的安全令牌、应用自有的数据、使用的环境变量、启动容器的命令行等）。
- Client 将 AM 提交至 RM，调用 ApplicationClientProtocol #submitApplication。
- RM 根据一定的分配策略为 AM 分配container，并与 NM 通信。
- NM 启动 AM。
- AM 从 HDFS 下载本任务运行所需要的资源并进行初始化工作。
- AM 向 RM 注册和申请资源。ApplicationMasterProtocol # registerApplicationMaster，注册信息包括：AM所在节点的主机名、AM的对外RPC服务端口和跟踪应用状态的Web接口；ApplicationMasterProtocol # allocate，相关信息封装在 AllocateRequest中包括：响应ID、申请的资源列表、AM主动释放的容器列表、资源黑名单、应用运行进度。
- RM 接受 AM 请求后，按照调度算法分配全部或部分申请的资源给 AM，返回一个 AllocateResponse 对象，其中包括：响应ID、分配的container列表、已完成的container状态列表、状态被更新过的节点列表、资源抢占信息（强制收回部分和可自主调配部分）等。
- AM 获取到资源后与对应的 NM 通信以启动 container， ContainerManagementProtocol # startContainers
- NM 启动container。
- Container 从 HDFS 下载任务运行必要的资源。
- Container 在运行过程中与AM通信及时汇报运行情况。
任务运行完成后 AM 向 RM 注销，ApplicationMasterProtocol # finishApplicationMaster()。
YARN面临的挑战
- 公平性：各租户能够公平的拿到资源运行任务
- 高性能：高调度吞吐、低调度延迟，保障资源快速流转
- 高可用：集群要具备很强的容错能力
- 单集群规模提升：原生 YARN 单集群仅支持 5K
- 高集群资源利用率
- 高任务运行质量保障
