Yarn与ZooKeeper
Yarn是MapReduce引入的资源管理器，它的出现为集群在资源利用率、资源统一管理和数据共享等方面带来了巨大好处。ZooKeeper是一个分布式的、开源的协调服务框架，ZooKeeper出现就是为例减轻分布式应用实现协调服务的负担。
Yarn资源管理与调度
Yarn产生背景
在早期的Hadoop中，MRv1采用Master/Slave(M/S)框架，主要包括Client、JobTracker、TaskTracker和Task几个部分。其中JobTarcker负责整个系统的作业调度和资源管理，TaskTracker负责将本节点上资源的使用情况、节点健康状态和任务的运行进度汇报给JobTracker，同时接受JobTracker发送过来的命令并执行相应操作。
M/S架构的设计具有一定的缺陷，MRv1中存在的问题如下。
1）单点故障。JobTracker只有一个，如果JobTracker发生故障则整个集群就无法使用，削弱了集群的高可用性。
2）资源利用率低。MRv1采用的是基于槽位的资源分配模型，将槽位分为Map Slot和Reduce Slot，两种Slot由Map和Reduce任务独立使用，不能实现资源共享，导致资源利用率低。
3）JobTarcker任务过重。JobTracker既要负责作业的调度和监控，又要负责资源的管理和分配。随着集群节点规模的扩大，JobTracker主节点压力过大，成为影响性能的瓶颈，限制了集群的扩展。
4）仅支持MapReduce计算框架。近几年出现了一些新的计算框架，如内存计算框架、流式计算框架和迭代式计算框架等，而MRv1不能支持这些新的计算框架。
为了克服上述问题，Hadoop2.0对MRv1进行了重新设计，将资源管理和任务调度两个功能交给独立的模块负责，提出了MRv2和Yarn（yet another resource negotiator）。MRv2是计算框架，而Yarn独立负责资源管理和分配。通过这种功能划分，有效地降低了JobTracker的压力。Tarn为分布式应用提供了通用的资源管理框架，不但支持MapReduce应用，也支持几乎所有的其他分布式应用。
在Yarn命令行中同样包含很多功能，用于日常运维、查看日志和提交作业。在终端，可输入yarn，查看各种选项。
Yarn的体系结构
Yarn体系结构
Yarn体系结构，Yarn同样采用Master/Slave结构，主要由ResourceManager(简称RM)、NodeManager(简称NM)、ApplicationMaster(简称AM)和Container等几部分组成。ResourceManager负责资源管理，ApplicationMaster负责任务监控和调度，NodeManager负责执行原TaskTracker的任务。
一个集群中通常有一个ResourceManager和多个NodeManager。
1）ResourceManager是一个全局的资源管理器，负责整个系统资源管理和分配，整个集群只有一个。ResourceManager主要由两个组件构成：Scheduler和Applicaitons Manager。
Scheduler是一个纯粹的调度器，负责为各种运行中的应用程序分配资源，它不负责应用程序的监控和状态跟踪等于应用程序相关的工作。Scheduler根据资源容量、队列以及其他因素的限制条件，将资源进行分配。
Applications Manager是应用程序管理器，负责管理整个系统中所有应用程序的运行，包括应用程序的提交，与调度器协商资源以启动ApplicationMaster以及监控ApplicationMaster运行状态并在失败时重新启动等工作。
2）NodeManager。NodeManger是每个节点上的资源和任务管理器。NodeManager定时地向ResourceManager汇报本节点上地资源使用情况和各个Container的运行状态。NodeManager接受并处理来自AM的启动和停止任务等各种请求。
3）ApplicationMaster。用户提交的每个应用程序均会产生一个用于对其追踪和管理的ApplicationMaster。当用户提交作业时，ApplicationMaster与ResourceManager调度器协商从而获取资源(以Container形式)。将获得的资源进一步分配给内部的各个任务，如Hadoop平台上的Map任务和Reduce任务。ApplicationMaster与NodeManager通信，进行任务的启动、运行和停止。ApplicationMaster监控申请到的资源使用情况、任务的运行进度和状态，并在任务运行失败时进行恢复(重新为任务申请资源、重启任务等)。ApplicationMaster定时向ResourceManager发送“心跳”信息，汇报资源的使用情况和任务的执行状态。作业完成时，ApplicationMaster向ResourceManager注销容器。
不同的ApplicationMaster分布在不同的节点上，它们之间不会互相影响。
4）Container。Yarn以Container作为动态分配资源的单位。Container对任务运行环境进行抽象，封装CPU、内存等多维度的资源以及环境变量、启动命令等任务运行相关的信息。Yarn会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。
一个应用程序所需的Container分为两种：一种是运行ApplicationMaster的Container，由ResourceManager向内部资源调度器申请；另一种是运行各类的Container，它由ApplicationMaster向ResourceManager申请，并通过ApplicationMaster与NodeManager通信来启动。
ResourceManager Restart
ResourceManager作为Yarn上的Master，负责集群的资源和调度管理，一旦发生单点故障，整个集群的资源将无法使用。为此，在Yarn中引入了新特性——ResourceManager Restart(重启)和ResourceManager HA(高可用性)。
当发生故障时，应尽可能快地自动重启ResourceManager，另外，ResourceManager重启过程用户是感知不到的，ResourceManager Restart主要分为两个阶段。
1）阶段1——非工作保留RM重启。在Hadoop2.4.0版本之前，只有ResourceManager Restart阶段1是实现完成的。
在Client提交Application时，RM会将应用程序元数据(ApplicationSubmissionContext)保留在可插拔的状态存储中，并保存应用程序的最终状态，例如，完成状态(失败、终止、已完成)和诊断时的诊断应用程序完成。此外，RM还会保存安全密钥、令牌等凭据，以便在安全的环境中工作。任何时候RM关闭，只要在状态存储中可以获取所需的信息(应用程序元数据以及在安全环境中运行的凭据)，当RM重新启动时，它可以从状态存储中获取应用程序元数据并重新提交申请。如果Application在RM关闭前以及完成(Failed、Killed、Finished)，RM不会重新提交Application。
NodeManager和Cilent在RM的宕机时间内保持轮询RM状态知道RM恢复。当RM重新启动之后，他会通过心跳发送re - sync命令到所有的NodeManager和ApplicationMaster。到Hadoop2.4.0发布为止，NodeManager和ApplicationMaster处理此命令的行为是，NM会杀死它管理的所有Container，然后重新注册到RM。在RM看来，这些重新注册上来的NodeManager就相当于新加入的NM。AM(如MapReduce AM)在收到re-sync命令之后会关闭。在RM重新启动并加载所有应用程序元数据，并将状态存储的凭据填充到内存中之后，他将为尚未完成的每个应用程序创建一个新的ApplicationMaster并像往常一样重新启动该应用程序。
2）阶段2——保持工作的RM重启。从Hadoop2.6.0版本开始，进一步增强了RM重启功能来解决RM重启时可以不杀死任何在集群中运行的Application的问题。
除了阶段1已经完成了基础性工作，即Application持久化和重新加载Application状态，阶段2主要侧重于重新构建完整的集群运行状态，主要是RM内部的中心调度器保持跟踪所有容器的生命周期、Application的余量和资源请求使用情况等。在这种方式下，RM不再需要像在阶段1中那么杀死AM并重新运行，Application就能够简单地与RM重新同步(re-sync)，并从终端处继续它剩下的工作。
RM利用NM发送的Container状态信息恢复自身的运行状态。当NM与重新启动的RM重新同步时，NM不会杀死容器。在重新注册之后，NM继续管理容器，并在重新注册时发送容器状态到RM。RM通过这些容器的信号重新构建容器实例和相关Application的调度状态。与此同时，AM需要重新发送未完成的资源请求到RM，因为RM可能会在关闭时丢失未完成的请求。Application利用它的AMRMClient库与RM通信，不用担心AM在重新同步时发送资源请求，因为它自动由库本身处理。
另外，在Spark2.4.0之后，增加了高可用性功能。ResourceManager的高可用性可以"Active/Standby"的形式增加一个节点冗余，并利用ZooKeeper集群，把Active的ResourceManager状态信息写入ZooKeeper用于启动Standby状态的ResourceManager，以消除这个单点故障。
Yarn通信协议
在Yarn中，任何两个需要相互通信的组件之间都需要RPC协议，并且有且仅有一个。Yarn采用的是拉式(pull - based)通信模型，因为对于任何一个RPC协议，Clien总是主动连接Server。
1）JobClient与RM之间的协议：JobClient通过该协议提交应用程序，查询应用程序状态等。
2）Admin与RM之间的协议：admin通过该RPC协议更新系统配置文件。
3）AM与RM之间的协议：AM通过该RPC协议向RM注册和撤销自己，并为各个任务申请资源。
4）AM与NM之间的协议：AM通过该PRC协议要求NM启动或者停止Container，获取各个Container的使用状态等信息。
5）NM与RM之间的协议：NM通过该RPC协议向RM注册，并定时发送心跳信息汇报当前节点的资源使用情况和Container运行情况。
Yarn执行过程
第一阶段：提交作业
1）在客户端通过创建JobClient实例，启动作业Job。
2）向ResourceManager请求获取一个新的作业ID(JobID)，然后检查作业输出。例如，是否指定输出路径或输出路径是否已经存在，如果未指定输出路径或输出路径已经存在则放弃提交作业。计算作业的输入数据分片，若输入路径不存在则放弃提交作业。
3）如果输入输出检查没有错误，JobClient将作业运行所需要的资源复制到HDFS分布式文件系统中以JobID命名的目录下。这些资源包括本次作业相关的配置文件，计算所得的输入数据分片已经包含Mapper和Reducer类的jar文件等。
4）完成上述准备后，JobClient通过调用ResourceManager的submitApplication()方法发出作业提交请求。
第二阶段：初始化作业
5）ResourceManager接受到调用它的submitApplication()请求后，将该作业提交请求传递给调度器。调度器为该作业分配一个容器Container，然后ResourceManager在该Container内启动应用管理器ApplicationMaster进程，由NodeManager监控。