随着全球经济的不断发展，大数据时代早已悄悄到来，而Hadoop又是大数据环境的基础，想入门大数据行业首先需要了解Hadoop的知识。2017年年初apache发行了Hadoop3.0，也意味着一直有一群人在对Hadoop不断的做优化，不仅如此，各个Hadoop的商业版本也有好多公司正在使用，这也印证了它的商业价值。
读者可以通过阅读“一文读懂Hadoop”系列文章，对Hadoop技术有个全面的了解，它涵盖了Hadoop官网的所有知识点，并且通俗易懂，英文不好的读者完全可以通过阅读此篇文章了解Hadoop。
本期独家内容“一文读懂Hadoop”系列文章先介绍Hadoop，继而分别详细介绍HDFS、MAPREDUCE、YARN的所有知识点，分为四期内容在近几天推送。欢迎关注往期内容。
本期内容为大家详解YARN：
1. 简介
YARN的基本思想是将资源管理和作业调度的功能分成独立的守护进程。ResourceManager和NodeManager构成了数据计算框架，其中ResourceManager（RM）负责协调整个系统的所有应用程序的资源，NodeManager是每个机器框架的代理，是执行应用程序的容器，监控应用程序的资源使用情况 (CPU，内存，硬盘，网络 ) 并且向ApplicationMaster汇报。每个应用程序的ApplicationMaster实际上是一个负责跟ResourceManager协商资源，和NodeManager一起执行和监控任务的框架。
MapReduce下一代架构
ResourceManager拥有两大主要组件：Scheduler和ApplicationsManager。
Scheduler负责给所有的运行的应用程序分配资源，受制于容量和队列等。Scheduler仅仅是调度而不关心应用程序的状态监控跟踪。也不保证失败任务和应用失败以及硬件失败。仅仅关心应用程序的资源需求，是一个抽象的资源容器，包括内存，cpu，硬盘，网络等元素；
Scheduler是插件化的负责在各种队列和应用程序直接隔离集群资源，现在的MR调度机制包括CapacityScheduler 和FairScheduler都是插件化的；
CapacityScheduler支持层次队列，支持共享集群资源；
ApplicationsManager 负责接收任务提交，协调容器去执行应用,尤其ApplicationMaster，同时当ApplicationMaster失败了提供重启服务；
NodeManager在每个节点上都有，负责容器，监控资源使用情况，上报状态信息到 ResourceManager/Scheduler；
每个应用的ApplicationMaster用于协调从Scheduler的资源容器状态跟踪监控。
2. 命令
2.1 概述
YARN命令由bin/yarn脚本调用。运行不带任何参数的yarn脚本将打印所有命令的描述。
用法：yarn [SHELL_OPTIONS] COMMAND [GENERIC_OPTIONS] [COMMAND_OPTIONS]
2.2 用户命令
Hadoop集群用户使用的命令。
2.3 管理命令
Hadoop集群管理员使用的命令。
3. 调度
3.1 容量调度
3.1.1 目的
容量调度，对于Hadoop的一个可插入的调度程序，允许用于 multiple-tenants安全地共享一个大集群，使得他们的应用程序是根据所分配容量限制分配资源，及时处理。
3.1.2 概述
该容量调度被设计为运行Hadoop的一个共享的应用程序，在操作者友好的方式multi-tenant实现集群的最大化吞吐量和集群的最大利用率。
传统上每个组织都有它自己的私有组具有足够的能力来满足组织的SLA下的峰值或接近峰值条件下的计算资源。这通常会导致平均利用率和管理多个独立的群集不平衡，使之成为每个组织开销之一。组织之间共享集群是运行大型的Hadoop的安装，因为这使他们能够获得规模经济的好处，而无需创建私人集群的成本效益的方式。然而，组织都在关注共享群集，因为他们担心别人使用，这是他们的SLA至关重要的资源。
该容量调度被设计成允许共享一个大的集群，同时给每个组织能力的保证。其中心思想是，在Hadoop集群中的可用资源，谁共同出资建设集群的基础上需要计算需求多个组织之间共享。有一个组织可以访问不被他人使用任何产能过剩的一个额外的好处。这提供了弹性的组织以具有成本效益的方式。
跨组织共享集群就必须对multi-tenant的大力支持，因为每个组织必须保证能力和安全防护装置，以确保共享群集是不受单个表面应用程序或用户或设定物。该容量调度提供了一套严格的限制，以确保单个应用程序或用户或队列都不能消耗在集群中的资源不成比例。此外，容量调度提供initialized/pending。
从单用户应用程序的限制和排队控制，以确保公平集群和稳定性。
由容量调度提供的初级抽象是队列中的概念。这些队列通常设置由管理员反映共享集群的经济性。
为进一步控制和可预测的资源共享，在容量调度支持层次化队列，以确保资源的子队列的组织之间共享其他队列。
3.2 公平调度
3.2.1 目的
公平调度，一个用于Hadoop的可插入调度程序，它允许YARN应用程序公平地共享大型集群中的资源。
3.2.2 介绍
公平调度是将资源分配给应用程序的方法，使所有的应用程序得到的平均值，资源随时间的相等份额。Hadoop的下一代系统能够调度多个资源类型。默认情况下，公平调度器调度仅在内存中实现公平调度。它可以被配置为内存和CPU调度，利用资源优势公平的概念。此方法有由Ghodsi等人开发的。在应用程序使用的集群中，当有一个单一的应用程序运行时。当其他应用程序提交后，即释放被分配给新的应用程序的资源，这样每个应用程序对最终得到的资源量大致相当。不同于默认Hadoop的调度，形成应用程序的队列，这让短暂的应用程序在合理的时间内完成，而不会饿死长时间运行的应用程序。它也是一种合理的方式来共享多个用户之间的集群资源。最后在公平共享的同时还能配合的应用程序优先级 作为权重来确定总的资源为每个应用程序应该得到的资源数。
调度组织进一步应用到“队列”，并在这些队列之间分享资源??。默认情况下，所有用户共享一个单一的队列，命名为“default”。如果一个应用程序专门列出一个队列在一个容器资源请求，该请求被提交到该队列。它也可以分配基于包括通过配置请求中的用户名的队列。在每个队列调度策略用于共享运行的应用程序之间的资源。默认的是基于存储器的公平共享，但是FIFO和多资源具有优势资源公平也可以配置。队列可以被安排在一个层次结构来划分资源，并与重量配置为共享集群中的特定比例。
除了提供公平共享，公平调度器允许分配最低保证分享的队列，这是保证某些用户，组或生产应用程序总能得到足够的资源是有效的。当队列中包含的应用程序，它得到至少为其最小的份额，但是当队列并不需要它的全面保证份额，则超出部分拆分其他正在运行的应用程序之间。这让调度保障能力的同时有效地利用资源，当这些队列不包含应用程序的队列。
公平调度器让默认情况下运行的所有应用程序，但它也可以通过配置文件限制运行的每个用户和每个队列的应用程序的数量。这可能是有用的，当一个用户必须同时提交上百的应用程序，或在总体上提高性能，如果同时运行了太多的应用程序会导致创建太多的中间数据或过多的上下文切换。限制应用程序不会造成任何其后提交的应用程序失败，只能等待调度的队列中，直到一些用户的较早的应用程序完成的。
3.3 机会型容器
3.3.1 主要目标
与仅存在未分配资源时在节点中调度的现有YARN容器不同，机会性容器可以被分派到NM，即使它们在该节点处的执行不能立即开始。在这种情况下，机会性容器将在该NM处排队，直到资源变得可用。机会性容器执行的主要目标是提高集群资源利用率，从而增加任务吞吐量。资源利用率和任务吞吐量改进对于包括相对较短任务（秒级）的工作负载更加明显。
3.3.2 概述
YARN（公平和容量调度程序）中的现有调度程序仅在调度容器时在该节点上有未分配资源时才将容器分配给节点。这种保证的执行类型的优点在于，一旦AM将容器分派给节点，容器执行将立即开始，因为它保证将有可用的资源。此外，除非违反公平或能力限制，否则保证容器运行到完成而不被抢占。
虽然此设计提供了更可预测的任务执行，但它有两个主要缺点，可能导致次优的集群资源利用率：
反馈延迟。当容器在节点完成其执行时，RM通过下一个NM-RM心跳通知有可用资源，然后RM在该节点调度新容器，AM通过下一个AM-RM心跳通知，最后AM在节点启动新的容器。这些延迟导致空闲节点资源，这又导致较低的资源利用，特别是当工作负载涉及持续时间相对较短的任务时。
分配与已利用资源。RM基于在每个节点处分配的资源来分配容器，这可能显着高于实际使用的资源（例如，考虑已经分配了4GB内存但仅使用2GB的容器）。这降低了有效的资源利用，并且如果RM在调度期间考虑所利用的资源，则可以避免这种情况。然而，这必须以允许在运行的容器的所利用的资源增加的情况下回收资源的方式来完成。
为了减轻上述问题，除现有的容器，我们介绍的概念机会主义容器。即使在调度的时刻没有可用的（未分配的）资源，也可以将机会性容器分派给NM。在这种情况下，机会性容器将在NM处排队，等待资源变得可用于其开始执行。机会性容器具有比保证容器低的优先级，这意味着它们可以被抢占以保证容器开始它们的执行。因此，它们可以用于提高集群资源利用率，而不会影响现有保证容器的执行。
机会性容器的另一个优点是它们在NM处引入执行优先级的概念。例如，不要求严格执行保证的较低优先级作业可以对其任务使用机会性容器或容器执行类型的混合。
我们介绍了两种分配机会主义容器的方法：集中式和分布式。在集中式调度中，机会性容器通过YARN RM分配，而在分布式容器中，通过驻留在每个NM的本地调度器来分配。集中式分配允许更高质量的布置决策，并且实现跨应用的更多涉及的共享策略（例如，公平性）。另一方面，分布式调度可以提供更快的容器分配，这对于短任务是有用的，因为它避免了到RM的往返。在这两种情况下，保证容器的调度保持完整，并通过YARN RM（使用现有的公平或容量调度程序）进行。
注意，在当前实现中，我们基于分配（和未使用）资源来分配容器。因此，我们处理上述“反馈延迟”问题，而不是“分配与利用资源”问题。
3.4 YARN安全容器
3.4.1 安全容器概述
容器执行器必须访问容器所需的本地文件和目录，例如jar，配置文件，日志文件，共享对象等。虽然它是由NodeManager启动的，但容器不应该访问NodeManager的私有文件和配置。运行由不同用户提交的应用程序的容器应该隔离，并且无法访问其他文件和目录。
在Linux环境中，安全容器执行程序是LinuxContainerExecutor。它使用一个名为container-executor的外部程序来启动容器。此程序具有setuid访问权限标志，允许其启动具有YARN应用程序用户权限的容器。
3.4.2 Yarn的工作流程
步骤1：用户将应用程序提交到ResourceManager上。
步骤2：ResourceManager为应用程序ApplicationMaster申请资源，并与某个NodeManager通信，以启动ApplicationMaster。
步骤3：ApplicationMaster与ResourceManager通信，为内部要执行的任务申请资源，一旦得到资源后，将于NodeManager通信，以启动对应的任务。
步骤4：所有任务运行完成后，ApplicationMaster向ResourceManager注销，整个应用程序运行结束。
上述步骤中，步骤2~3涉及到资源申请与使用，而这正是Container出现的地方。
4. ResourceManger
4.1 概述
ResourceManager是管理资源和调度YARN中运行的application的中心机构。因此，它在Apache YARN 集群中存在潜在的单点故障。下面给出有关ResourceManager Restart特性，该特性强化ResourceManager可以跨越重启操作继续运转，另外让ResourceManager的停机时间对终端用户不可见。
ResourceManager Restart特性分成两个阶段：
ResourceManager Restart阶段1（Non-work-preserving RM restart）：RM在插件化的 state-store中持久化application/attempt状态以及其他证书信息。在重启过程中RM会从state-store中重载这些信息，并且重新启动之前Running的application。用户不需要重新提交这些application。
ResourceManager Restart阶段 2 (Work-preserving RM restart):聚焦在通过结合重启过程中来自NodeManager的容器状态和来自ApplicationMaster的容器请求重新构建ResourceManager的运行状态。与阶段1的关键不同是之前运行中的应用程序在RM重启中不会被kill，所以application不会因为RM的中断丢失它的工作内容。
4.2 高可用性
ResourceManager（RM）负责跟踪集群中的资源，并调度应用程序（例如MapReduce作业）。在Hadoop 2.4之前，ResourceManager是YARN集群中的单点故障。高可用性功能以活动/备用ResourceManager添加冗余，以消除这种单点故障。
5. NodeManager
NodeManager（NM）是YARN中每个节点上的代理，它管理Hadoop集群中单个计算节点，包括与ResourceManger保持通信，监督Container的生命周期管理，监控每个Container的资源使用（内存、CPU等）情况，追踪节点健康状况，管理日志和不同应用程序用到的附属服务（auxiliary service）。NodeManager负责启动和管理节点上的容器。容器执行AppMaster指定的任务。
NodeManager运行服务以确定其正在执行的节点的运行状况。服务对磁盘以及任何用户指定的测试执行检查。如果任何健康检查失败，则NodeManager将该节点标记为不正常，并将其传达给ResourceManager，ResourceManager将停止向该节点分配容器。节点状态的通信是作为NodeManager和ResourceManager之间的心跳的一部分来完成的。磁盘检查器和运行状况监视器运行的时间间隔不影响心跳间隔。当心跳发生时，两个检查的状态用于确定节点的运行状况。
磁盘检查程序检查NodeManager配置使用的磁盘的状态（local-dirs和log-dirs，分别使用yarn.nodemanager.local-dirs和yarn.nodemanager.log-dirs配置）。检查包括权限和可用磁盘空间。它还检查文件系统不处于只读状态。默认情况下，检查以2分钟间隔运行，但可以配置为按用户期望的频率运行。如果磁盘检查失败，NodeManager停止使用该特定磁盘，但仍报告节点状态为正常。但是，如果多个磁盘无法通过检查（可以配置该数目，如下所述），则会将该节点报告为对ResourceManager不正常，并且不会将新容器分配给该节点。
用户可以指定自己的健康检查器脚本，由健康检查器服务调用。用户可以指定超时以及要传递给脚本的选项。如果脚本使用非零退出代码退出，超时或抛出异常，则会将节点标记为不正常。请注意，如果由于权限或路径不正确而无法执行脚本，则会将其视为失败，并将该节点报告为不正常。请注意，健康检查脚本不是强制性的。如果未指定脚本，则仅使用磁盘检查程序状态来确定节点的运行状况。
6. 节点标签
节点标签是一种对具有类似特征的节点进行分组的方法，应用程序可以指定运行的位置。
现在我们只支持节点分区，即：
一个节点可以只有一个节点分区，因此一个节点分区将一个集群分区为几个不相交的子集群。默认情况下，节点属于DEFAULT分区（partition =“”）。
用户需要配置每个分区可以使用不同队列的资源量。
有两种节点分区：
用户可以指定每个队列可以访问的节点标签集，一个应用程序只能使用可以由包含应用程序的队列访问的节点标签的子集。
7. 扩展阅读
7.1 Web应用程序代理
Web应用程序代理是YARN的一部分。同时也是资源管理器（RM）的一部分，它可以在独立模式下运行。用于减少YARN遭受Web攻击的可能性。ResourceManager Web的访问基于受信用户，当Application Master运行于一个非受信用户，其提供给ResourceManager的将是非受信连接，Web Application Proxy可以阻止这种连接提供给RM。
7.2 时间轴服务器
7.2.1 介绍
以一种通用的方式向YARN Timeline Server上注册应用程序的当前和历史状态，便于存储和检索。它主要有两大职责：
收集并检索应用程序或者框架的具体信息。例如，hadoop MR框架里面的与分片线关系的信息，诸如map tasks、reduce tasks、counters等。应用程序开发者可以在App Master端或者应用程序需的containers中通过TimelineClient将这些信息发送给Timeline Server。
这些信息都可以通过REST APIs在具体App或者执行框架的UI界面查询到。
关于这一点，在Application history server中，显然只支持MR框架的job。Generic information包括了像queue-name，用户信息等用户程序级别的数据，还有设置在ApplicationSubmissionContext中的信息，用于运行应用程序的application-attempts 列表，关于每个application-attempt的信息，container列表以及运行在每个application-attempt下的每个container的信息。
7.2.2时间轴框架
Timeline Domain为Timeline Server提供了一个命令空间，使得用户可以搜集多个节点，将它们与其他用户和应用程序隔离开来。Timeline server security就定义在这一层。一个Domain首先是用于存储用户的信息、读写ACL信息、创建和修改时间戳。每个Domain以一个唯一的ID在整个YARN集群中标识。
一个Timeline Entity（即Timeline实体）包含一个概念实体的元信息以及它的相关的events.一个实体可以是一个application，一个 application attempt，一个container卓尔其他任何的应用自定义的object。它还包含多个Primary filters用于作为timeline store中多个实体的索引。其他的数据可以以非索引的方式存储。每个实体都通过一个EntityId和EntityType唯一的确定。
Timeline Events用于描述一个与某个具体Application的timeline实体相关的event。用户也可以随意定义一个event方法，比如启动一个应用程序，获取分配的container、操作失败或者其他的与用户和集群操作相关的失败信息等等。
7.2.3 时间轴服务v.2
YARN时间轴服务v.2是时间轴服务的下一个主要迭代，遵循v.1和v.1.5。V.2是为了解决v.1的两个主要挑战而创建的。
V.1限于写入/读取和存储的单个实例，并且不能超出群集扩展。V.2使用更可扩展的分布式写入架构和可扩展存储。
YARN时间轴服务v.2将数据的收集（写入）与服务（读取）数据分离。它使用分布式收集器，每个YARN应用程序基本上有一个收集器。阅读器是专用于通过REST API提供查询的单独实例。YARN Timeline Service v.2选择Apache HBase作为主要后备存储，因为Apache HBase可以很好地扩展性，同时保持读取和写入的良好响应。
在许多情况下，用户对YARN应用程序的“流”或逻辑组级别的信息感兴趣。启动一组或一系列YARN应用程序以完成逻辑应用程序是更常见的。时间轴服务v.2明确支持流的概念。此外，它支持在流级别聚合。
流层次
7.3 应用程序
客户端提交应用到Resource Manager，首先客户端需要使用ApplicationClientProtocol连接ResourceManager获取一个ApplicationId，通过ApplicationClientProtocol#getNewApplication(类名#方法)，然后通过ApplicationClientProtocol#submitApplication方法，提交应用运行。作为 ApplicationClientProtocol#submitApplication方法的一部分，客户端需要提供足够的信息到ResourceManager用来‘发布’应用的第一个Container作为ApplicationMaster。你需要提供的信息包括应用运行所需要的本地文件或者jar，实际的执行的命令行（和必要的命令行参数），环境设置（可选）等等。你需要描述ApplicationMaster运行的Unix进程资源。
YARN的ResourceManager将会发布ApplicationMaster（按照指定的）。然后ApplicationMaster将会采用ApplicationMasterProtocol与ResourceManager 进行通讯，首先ApplicationMaster会使用ApplicationMasterProtocol#allocate方法注册自己到ResourceManager.为了完成指定的任务。ApplicationMaster要通过ApplicationMasterProtocol#allocate来请求和接收containers。在一个container分配给他之后，ApplicationMaster使用ContainerManager#startContainer来与NodeManager 通讯发布任务到这个container。作为发布到container的部分，ApplicationMaster需要指明ContainerLaunchContext（这个类似于ApplicationSubmissionContext）并且发布的信息应包括指定的命令行，环境等。一旦任务完成ApplicationMaster会通过ApplicationMasterProtocol#finishApplicationMaster通知ResourceManager完成。
同时，客户端通过ResourceManager监控应用的状态或者是直接查询ApplicationMaster（如果支持这个服务的话），如有需要客户端也可以通过ApplicationClientProtocol#forceKillApplication杀掉应用的进程。
7.4 应用程序安全
任何编写YARN应用程序的人都需要了解该过程，以便编写短期应用程序或长期服务。他们还需要在早期开发阶段开始在安全集群上测试，以便编写实际工作的代码。
YARN资源管理器（RM）和节点管理器（NM）协作以用该用户的身份和因此的用户的访问权限来执行用户的应用。
（活动）资源管理器：
查找群集中的空间以部署应用程序的核心，应用程序主（AM）。
请求该节点上的NM分配容器并在其中启动AM。
与AM通信，以便AM可以请求新的容器并操纵/释放当前容器，并提供关于已分配和正在运行的容器的通知。
节点管理器：
本地化资源：从HDFS或其他文件系统下载到本地目录。这是使用附加到容器启动上下文的委托令牌来完成的。（对于非HDFS资源，使用其他凭据，如群集配置文件中的对象存储库登录详细信息）
以用户身份启动应用程序。
监视应用程序并向RM报告故障。
要在集群中执行代码，YARN应用程序必须：
有一个客户端应用程序，它设置了ApplicationSubmissionContext详细说明是什么推出。这包括：
集群文件系统中要“本地化”的文件列表。
要在容器中设置的环境变量。
在容器中执行以启动应用程序的命令。
YARN启动应用程序所需的任何安全凭证。
应用程序与任何Hadoop集群服务和应用程序交互所需的任何安全凭证。
有一个Application Master，当启动时，向YARN RM注册并监听事件。任何AM它希望执行的其他容器的工作必须要求他们离开RM，并且在分配时，创建ContainerLaunchContext包含要执行的命令，环境执行命令，双星定位和所有相关的安全证书。
即使NM处理本地化过程，AM也必须能够检索在启动时提供的安全证书，以便它自己可以与HDFS和任何其他服务一起工作，并将这些证书中的一些或全部传递到启动容器。
YARN应用所需的代理令牌必须从作为认证用户执行的程序中获取。对于YARN应用程序，这意味着用户启动应用程序。它是YARN应用程序的客户端部分，必须这样做：
通过UserGroupInformation登录。
识别必须获取的所有令牌。
从特定的Hadoop服务请求这些令牌。
Marshall将所有令牌转换成字节缓冲区。
将它们添加到ApplicationSubmissionContext中的ContainerLaunchContext。
需要哪些令牌？通常，至少需要一个令牌来访问HDFS。
应用程序必须从与其打算交互的每个文件系统请求委派令牌 - 包括集群的主FS。FileSystem.addDelegationTokens（renewer，credentials）可以用来收集这些; 它是没有发出令牌（包括非kerberized HDFS集群）的那些文件系统上的无操作。
与其他服务（如Apache HBase和Apache Hive）通信的应用程序必须从这些服务请求令牌，使用这些服务的库来获取委派令牌。所有令牌可以添加到相同的凭据集，然后保存到字节缓冲区以提交。
应用程序时间表服务器还需要一个委派令牌。这是在AM启动时自动处理的。
7.5 CGroups
CGroups是将任务集及其所有未来的子任务聚集/分组成具有专门层次。CGroups是一个Linux内核功能，并被并入内核版本2.6.24。从YARN的角度来看，这允许容器在其资源使用中受到限制。一个很好的例子是CPU使用率。没有CGroups，很难限制容器CPU的使用。目前，CGroups仅用于限制CPU使用。
7.6 预约系统
该预约系统为用户提供了资源预留，以确保可以随时运行重要作业的能力。ReservationSystem执行细力度的资源控制，并提供对绝对资 源量（而不是集群大小的百分比）的保证。保留可以是可延展的或具有成组含义，并且可以具有时变资源要求。ReservationSystem是YARN ResourceManager的组件。
本期独家内容“一文读懂Hadoop”系列文章先介绍Hadoop，继而分别详细介绍HDFS、MAPREDUCE、YARN的所有知识点，分为四期内容在近几天推送。欢迎关注往期内容。
一文读懂Hadoop系列往期回顾：
独家 | 一文读懂Hadoop（一）：综述
独家 | 一文读懂Hadoop（二）HDFS（上）
独家 | 一文读懂Hadoop（二）HDFS（下）
独家 | 一文读懂Hadoop（三）：Mapreduce
宋莹，数据派研究部志愿者，北京中软融鑫ETL工程师。喜爱数学和计算机，酷爱大数据分析、大数据挖掘、机器学习。
转载须知
如需转载文章，请做到 1、正文前标示：转自数据派THU（ID：DatapiTHU）；2、文章结尾处附上数据派二维码。
申请转载，请发送邮件至[email protected]
公众号底部菜单有惊喜哦！
企业，个人加入组织请查看“联合会”
往期精彩内容请查看“号内搜”
加入志愿者或联系我们请查看“关于我们”
