Yarn01：诞生背景、架构和工作机制介绍

写在前面的总结：

Yarn只响应job的提交及为job的运行分配资源，yarn不参与job的具体运行机制和流程。

mapReduce程序中有一个进程MrAppMaster来负责程序的具体运行流程控制。

由于Yarn不参与用户程序的具体运行，所以Yarn可以为各种类型的应用程序提供资源服务（Yarn就类似于一个操作系统平台，可以运行各种各样的运算框架所开发的框架：mr，storm，spark等等）。

因为Yarn可以整合各种运算框架，企业就可以把各种分布式框架整合到Hadoop集群。

RM和AM分离资源调度和应用程序的执行，提高可扩展性、可维护性、实现对不同变成模型的支持。

什么是Yarn？

Yarn(Yet Another Resource Negotiator)是一个资源调度平台（集群），Hadoop的集群资源管理器，主要功能是为用户程序（如用户开发的map reduce 程序）提供资源的管理和调度。其核心思想是将JobTracker的资源管理和作业调度两个功能分离，主要包含两类节点和三个模块：ResourceManager(RM)、NodeManager(NM)、ApplicationMaster(AM)。

为什们会诞生Yarn？

随着业务飞升，技术会在很多层面出现瓶颈。MR1将编程模型与资源调度耦合在一起，为了跟上业务的步伐，必然会催生新的框架和系统。这部分内容根据文章Vavilapalli(2013)，梳理哪些需求推动了Yarn的诞生。

可扩展性（Scalability）：从MapReduce1开始讲起，在MR1的工作机制中，jobTacker负责同时事管理作业调度和创建任务，很容易遇到扩展瓶颈。雅虎在2006年采用Hadoop MapReduce进行WebMap应用网络图模型的计算支持其搜索引擎，但是当时的网络图已经超过 1000 亿个节点和 1 万亿条边，技术赶不上业务变化，当时的计算框架“Dreadnaught”已经达到了 800 台机器的可扩展性极限，需要对其架构进行重大转变以匹配 Web 的步伐。
Yarn使用ResourceManager和Application Master机构来实现作业和任务管理的分离，具有更强的可扩展性。
多租户的需求（Multi-tenancy ）：除了计算的超大管道、搜索和负责内容优化、垃圾过滤等工作的科学家也推动了Yarn的早期需求，工程上的优先级和计算平台的中间过程能过帮助理解这一背景。

Yarn是一个资源调度平台，可以调度不同框架的作业，只负责给运行程序提供所需的资源分配和回收等调度任务，不参与程序的内部运行。
可维护性（Serviceability）：为了解决多租户问题，雅虎早期开发部署了HoD框架，它使用 Torque和 Maui在共享硬件池上分配 Hadoop 集群。由于 Hadoop 每三个月发布一次重大修订，HoD 的灵活性变得至关重要，因此需要将这种升级依赖关系进行解耦，提高可维护性。

资源管理框架与上层应用框架各自的版本升级依赖解耦
本地感知（Locality Awareness）：Hod的弊端之一是没有考虑到任务的本地感知，这样虽然实现了共享数据集的计价内读取，但是会导致Map和Reduce之间的数据拉取跨机架，且在DAG中的数据倾斜也较难解释。

对于HDFS上存储的数据，将任务尽量分配到距离相近的结点上。
高集群利用率（High Cluster Utilization）：由于在使用 HoD 时没有在作业之间调整集群的大小，因此集群中的大部分容量处于闲置状态，随后的更精简的阶段完成了。在一个极端但非常常见的场景中，在一个节点上运行的单个 reduce 任务可能会阻止集群被回收。在这种状态下，一些作业使数百个节点处于空闲状态。

在Yarn中，一个nodeManager管理一个资源池，应用能够按需请求资源。
可用性（Availability）：JobTracker内存中有大量快速变化的复杂状态，容易出现单点故障。JobTracker 故障并没有丢失单个工作流，而是导致中断，这将丢失集群中所有正在运行的作业，并要求用户手动恢复他们的工作流。停机时间在处理管道中产生了积压，当重新启动时，会给 JobTracker 带来很大的压力。因此为了集群恢复重新启动通常涉及手动终止用户的作业。由于为每个作业存储的复杂状态，在重新启动时保留作业的实现从未完全调试过。

Yarn分离式架构，可以分而治之，先为RM提供高可用，再为Yarn其他应用提供高可用。
安全且可审核的操作（Secure and Auditable Operation）：面向多租户技术的环境隔离。随着 Hadoop 管理更多的租户、多样化的用例和原始数据，它对隔离的要求变得更加严格，但授权模型缺乏强大的、可扩展的身份验证——这是多租户集群的一个关键特性。
支持不同的编程模型（Support for Programming Model Diversity）
灵活的资源模型（Flexible Resource Model）
向下兼容（Backward Compatability）：庞大的 MapReduce 应用程序安装基础、相关项目的生态系统、陈旧的部署实践以及紧迫的时间表都无法容忍彻底的重新设计。为了避免“第二个系统综合症”的陷阱，新架构尽可能多地重用现有框架中的代码，以熟悉的模式运行，并在绘图板上留下了许多推测性特征。

Yarn的架构

为了解决上面所讨论的诉求，YARN 将一些功能提升到负责资源管理的平台层，将逻辑执行计划的协调留给许多框架实现。具体来说，每个集群的 ResourceManager (RM) 跟踪资源使用情况和节点活跃度，负责全局的资源管理和分配，并仲裁租户之间的争用。 ApplicationMaster (AM)，它通过向 RM 请求资源、从其接收的资源生成物理计划以及围绕故障协调该计划的执行来协调单个作业的逻辑计划。

RM进程运行在专用机器上，在应用程序之间进行资源管理和分配；由于RM具有集群资源的中央和全局视图，它可以跨租户强制执行例如公平性 [R10]、容量 [R10] 和局部性 [R4]的职能。RM根据应用程序的资源需求、调度优先级和资源可用性等标准，动态在特定节点上分配租用容器给应用程序运行。其中容器Container是对任务运⾏环境的抽象，封装了了CPU、内存等多维资源（例如，⟨2GB RAM，1 CPU⟩）以及环境变量、启动命令等任务运行相关的信息、绑定到特定节点的的资源逻辑包。

NM进程运行在特殊节点上，负责监控资源可用性、报告故障和容器生命周期管理（例如启动和终止）。RM与NM进行交互，并从这些NM状态的快照中组装其全局视图，RM和NM之间通过心跳实现通信，从而实现的可扩展性。

作业通过公共提交协议提交给 RM，并经过一个准入控制阶段。在此阶段，RM 验证安全凭证并执行各种操作和管理检查 [R7]，通过的作业被传递给调度器。如果调度器有足够的资源，应用程序就会从接受状态转移到运行状态。除了内部簿记之外，RM还要为 AM在集群点点中分配并生成一个容器。已接受应用程序的记录被写入持久存储，并在 RM 重新启动或失败时恢复。

ApplicationMaster 是作业的“负责人”，管理相关的所有生命周期，包括动态增加和减少资源消耗、管理执行流程（例如，针对 map 的输出运行 reducer）、处理错误和计算偏差，以及其他本地优化。事实上，AM 可以运行任意用户代码，代码可以用任何编程语言编写，因为与 RM 和 NM 的所有通信都使用可扩展通信协议进行编码。 YARN 对 AM 做出的假设很少，尽管在实践中我们预计大多数工作将使用更高级别的编程框架（例如 MapReduce、Dryad、Tez、REEF 等）。通过将资源管理和应用程序运行分离，YARN 的架构获得了极大的可扩展性 [R1]、编程模型的灵活性 [R8] 和改进的升级/测试 [R3]（因为同一框架的多个版本可以共存）。

通常，AM 需要利用多个节点上可用的资源（cpu、RAM、磁盘等）来完成一项工作。为了获取容器，AM 向 RM 发出资源请求。这些请求的形式包括对容器的位置偏好和属性的规范。 RM 将尝试根据可用性和调度策略满足来自每个应用程序的资源请求。**当代表 AM 分配资源时，RM 会为该资源生成租约，该租约由后续的 AM 心跳拉动。**当 AM 将容器租约提交给 NM [R4] 时，基于tocken的安全机制可保证其真实性。一旦 ApplicationMaster 发现容器可供其使用，它就会使用租约对特定于应用程序的启动请求进行编码。如果需要，运行中的容器可以通过特定于应用程序的协议直接与 AM 通信，以报告状态和活跃度并接收特定于框架的命令——YARN 既不促进也不强制执行这种通信。

总体而言，YARN 部署为容器的生命周期管理和监控提供了一个基本但强大的基础架构，而特定于应用程序的语义由每个框架 [R3，R8] 管理。下面分别介绍Yarn的三大组件：ResourceManager、ApplicationMaster 和NodeManager：

ResourceManager：一个全局的资源管理器，负责整个集群的资源管理和调度。

RM负责处理客户端请求、启动或监控ApplicationMaster、监控NodeManager、资源的分配与调度。主要由两个组件构成：调度器(Scheduler)和应用程序管理器(ApplicationsManager，即ASM)。

调度器根据调度策略（如每个队列分配一定资源，最多执行一定数量的任务等）将系统中的资源分配给各个正在运行的程序。资源分配单位用一个抽象概念“Container”表示，Container将内存、CPU、磁盘、网络等资源封装在一起。
另一个组件ApplicationManager主要负责接收job的提交请求，1）应用分配第一个Container来运行ApplicationMaster，2）负责监控ApplicationMaster，3）遇到失败时重启ApplicationMaster运行的Container。RM 生成容器以及授予对资源访问权限的tocken来响应 AM 请求，此外RM 将完成容器的退出状态（由 NM 报告）转发给负责的 AM，当新的 NM 加入集群时，AM 也会收到通知，以便它们可以开始在新节点上请求资源。

ResourceManager 公开了两个公共接口：1) 客户端提交应用程序，2) ApplicationMaster(s) 动态协商对资源的访问，3)一个面向 NodeManagers 的内部接口，用于集群监控和资源访问管理。其中 RM 和 AM 之间的公共协议是 YARN 平台和运行在其上的各种应用程序/框架之间的协作的核心内容。
RM 将集群状态的全局模型与正在运行的应用程序报告的资源需求摘要进行匹配。这使得严格执行全局调度属性成为可能（YARN 中的不同调度器专注于不同的全局属性，例如容量或公平性），但它需要调度器准确了解应用程序的资源需求。通信消息和调度程序状态必须紧凑且高效，RM 才能根据应用程序需求和集群 [R1] 的大小进行扩展。捕获资源请求的方式在捕获资源需求的准确性和紧凑性之间取得了平衡。幸运的是，调度程序只处理每个应用程序的整体资源配置文件，而忽略本地优化和内部应用程序流。 YARN完全脱离了对map和reduce资源的静态划分；它将集群资源视为一个（离散的）连续体 [R9]，这显着提高了集群利用率。

应用先向ApplicationMaster发送一个满足自己需求的资源请求，然后ApplicationMaster把这个资源请求以ResourceRequests的形式发送给ResourceManager的调度器，调度器再在这个原始的ResourceRequests中返回分配到的资源描述Container。每个ResourceRequest可看做一个可序列化Java对象，每个 ResourceRequests 跟踪：容器数量（例如，200 个容器）、每个容器的资源大小 ⟨2GB RAM，1 个 CPU⟩、容器的位置偏好，以及应用内请求的优先级。包含的字段信息如下：

<resource-name, priority, resource-requirement, number-of-containers>

resource-name：资源名称，现阶段指的是资源所在的host和rack，后期可能还会支持虚拟机或者更复杂的网络结构
priority：资源的优先级
resource-requirement：资源的具体需求，现阶段指内存和cpu需求的数量
number-of-containers：满足需求的Container的数量

ApplicationMaster：协调单个应用在集群中的执行

提交的每个应用程序包括一个AM，负责应用程序相关事物。包括与RM调度器协商获取资源、为应用程序申请资源并分配给内部的任务、与NM通信以启/停任务、监控所有任务状态，并在任务失败时重新申请资源以重启任务。

由于RM不解释容器状态，AM通过RM判断NM上报的容器退出状态成功或失败的语义。由于 AM 本身是一个运行在不可靠硬件集群中的容器，因此它应该能够抵御故障。 YARN 为恢复提供了一些支持，但由于容错和应用程序语义如此紧密地交织在一起，大部分负担都落在了 AM 身上。

NodeManager：每个节点上的资源和任务管理器。

负责定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态、接受并处理来自AM的Container启动/停止等各种请求。
NodeManager 是 YARN 中的“worker”守护进程。它验证容器租约，管理容器的依赖关系，监控它们的执行，并为容器提供一组服务。运营商将其配置为报告此节点上可用并分配给 YARN 的内存、CPU 和其他资源。向 RM 注册后，NM 对其状态进行心跳检测并接收指令。
YARN 中的所有容器（包括 AM）都由容器启动上下文 (CLC) 描述。记录包括环境变量映射、存储在可远程访问的存储中的依赖项、安全令牌、NM 服务的有效负载以及创建进程所需的命令。在验证租约的真实性 [R7] 之后，NM 为容器配置环境，包括使用租约中指定的资源约束初始化其监控子系统。为了启动容器，NM 将所有必要的依赖项（数据文件、可执行文件、tarball）复制到本地存储。如果需要，CLC 还包括用于验证下载的凭据。依赖关系可以在应用程序中的容器之间、由同一租户启动的容器之间、甚至在租户之间共享，如 CLC 中所指定。 NM 最终会垃圾收集运行容器未使用的依赖项。
NM 还将按照 RM 或 AM 的指示杀死容器。当 RM 报告其拥有的应用程序已完成时，当调度程序决定为另一个租户驱逐它时，或者当 NM 检测到容器超出其租约限制时，容器可能会被杀死 [R2,R3,R7]。当不再需要相应的工作时，AM 可能会请求终止容器。每当容器退出时，NM 都会清理其在本地存储中的工作目录。当应用程序完成时，其容器拥有的所有资源在所有节点上都将被丢弃，包括仍在集群中运行的任何进程。
NM 还会定期监控物理节点的健康状况。它监视本地磁盘的任何问题，并经常运行管理员配置的脚本，这反过来又可以指向任何硬件/软件问题。当发现这样的问题时，NM 将其状态更改为不健康并报告 RM 相同的情况，然后做出调度程序特定的决定，即终止容器和/或停止该节点上的未来分配，直到健康问题得到解决。
除了上述之外，NM 还为在该节点上运行的容器提供本地服务。例如，当前的实现包括一个日志聚合服务，该服务将在应用程序完成后将应用程序写入的数据上传到 stdout 和 stderr 到 HDFS。
最后，管理员可以为 NM 配置一组可插入的辅助服务。虽然容器的本地存储将在退出后被清理，但允许提升一些输出以保留到应用程序退出。通过这种方式，一个进程可能会产生超出容器生命周期的数据，由节点管理。这些服务的一个重要用例是 Hadoop MapReduce 应用程序，其中中间数据使用辅助服务在 map 和 reduce 任务之间传输。

Yarn工作机制：MR程序提交的流程

作业提交

1 client提交作业到ResourceManger请求作业id；
2 RM给client返回job资源的提交路径和作业id。
3 client提交jar包，切片信息和配置文件到指定的资源提交路径。
4 client提交资源后，向rm申请运行MrAppMaster

作业初始化

5 Rm收到client请求，将job添加到容量调度器。并分配给空闲的NM初始化job。
6/7 该NM领取任务并创建容器，并产生MrAppMaster，
6-1 NM下载client提交的job文件到本地。

任务分配

8 MrAppmaster向Rm注册并申请运行多个Maptask任务资源。
9 Rm将运行MapTask任务分配给另外的NodeManger，对应的NodeManger分别领取任务并创建容器。
10 RM向申请资源的MrAppmaster返回资源列表

任务运行

11 MR向接受到任务的NodeManger发送程序启动脚本。这两个NM分别启动MapTask，MapTask对数据分区排序。
12 MapTask处理完成后向MrAppMaster汇报结果。
13 MrAppmaster等所有Maptask执行完成之后，向RM申请资源。
14 NM领取任务分配容器
15 MrAppMaster启动ReduceTask进程，ReduceTask向 MapTask获取相应分区的数据。
16 ReduceTask向MrAppMaster汇报处理结果。
17 程序运行完毕后，MR会向RM申请注销⾃⼰

进度和状态更新

Yarn中的任务将其进度返回给应用管理器，客户端每秒（mapreduce.client.progressmonitor.pollinterval设置）向应用管理器请求进度更新，展示给用户。

作业完成

除了向应用管理器请求作业进度外, 客户端每5秒都会通过调用waitForCompletion()来检查作业是否完成。时间间隔可以通过mapreduce.client.completion.pollinterval来设置
作业完成之后，应用管理器和Container会清理⼯作状态。作业的信息会被作业历史服务器存储以备之后⽤户核查。

参考文献

[1] Vavilapalli V K, Murthy A C, Douglas C, et al. Apache hadoop yarn: Yet another resource negotiator[C]//Proceedings of the 4th annual Symposium on Cloud Computing. 2013: 1-16.

[2] hadoop Yarn详解

关于Yarn的组件架构、容错和调度机制在后续文章中记录。感谢阅读，欢迎批评与指正！