Hadoop之Yarn

目录

说明

1.Yarn是什么？

2.Yarn之ResourceManager

2.1ResourceManager主要职责

2.2ResourceManager主要组件

2.2.1与Client交互组件

2.2.2与ApplicationMaster交互组件

2.2.3与NodeManager交互组件

2.2.4其他核心组件

2.2.5安全相关组件

3.Yarn之NodeManager

3.1NodeManager主要职责

3.2NodeManager主要组件

3.2.1NodeStatusUpdater

3.2.2ContainerManager

3.2.3ContainerExcutor

3.2.4NodeHealthCheckerService

3.2.5ContainerTokenSecretManager

3.2.6WebServer

4.Yarn之ApplicationMaster

4.1ApplicationMaster主要职责

5.疑惑

---

---

说明

本篇文章参考自YARN源码解析(4)-ResourceManager, NodeManager以及ApplicationMaster的功能，外加上自己的一些理解。侵权即删！

1.Yarn是什么？

Yarn是作业调度和集群资源管理的一个框架，其主要包括ResourceManager、ApplicationMaster、NodeManager

附上一张根据下面的描述绘画出的一张ApplicationMaster启动一个Container的过程图

（建议将下面的内容看完之后再回来看这张图）

2.Yarn之ResourceManager

2.1ResourceManager主要职责

（1）分配运行ApplicationMaster的Container，并通知NodeManager加载Container

（2）响应ApplicationMaster申请资源的请求，将Container清单返回给ApplicationMaster

（3）监控NodeManager和ApplicationMaster的状态

（4）监控整个集群的可用资源

2.2ResourceManager主要组件

2.2.1与Client交互组件

（1）ClientRMService

用于接收Client请求的组件，例如编写的Job提交到ResourceManager时，实际上就是与ClientRMService交互。

（2）AdminService

用于接收Administrator请求的组件。

为何需要单独一个组件接收Administrator请求而不是直接公用ClientRMService呢？

因为ClientRMService可能存在太多请求而导致请求迟迟得不到处理，而对于Administrator的请求是需要做到优先处理的。

（3）ApplicationACLsManager

用于验证Client提交的application。例如验证用户是否有权限执行。

（4）RMWebApp

用于对外提供一个web界面，其中包含application信息，集群中可用资源信息等。

2.2.2与ApplicationMaster交互组件

（1）ApplicationMasterService

用于接收ApplicationMaster发来的信息，主要信息如下：

• ApplicationMaster注册信息
• 验证ApplicationMaster发送的请求
• 接收ApplicationMaster的申请和释放资源的请求，并转发给YarnScheduler

（2）AMLivelinessMonitor

用于接收ApplicationMaster的心跳信息，来确认ApplicationMaster是否还存活。若在设置的检测间隔内没有收到来自ApplicationMaster的心跳信息，则认为这个ApplicationMaster挂掉了。此时会重启一个ApplicationAttempt并重新调度一个新的ApplicationMaster。

2.2.3与NodeManager交互组件

（1）ResourceTrackerService

用于接收NodeManager的心跳信息

• 注册新的node
• 从注册过的node上，接收心跳信息
• 确保只有有效的Node能够和ResourceManager进行交互

在注册了一个新的Node之后, ResourceManager就会给NodeManager发送一个和安全性相关的master key。然后NodeManager用这个master key来验证ApplicationMaster发送给他的加载Container的请求。

这个master key也不是会一直不变的，为了防止恶意的ApplicationMaster破解master key并向NodeManager提交恶意的Container，所以ResourceManager会每隔一段时间变更一次master key，并发送给NodeManager

ResourceTrackerService会将有效的heartbeat转发给YARNScheduler,然后YARNScheduler会根据集群中可用的资源，进行容器的分配。

（2）NMLivelinessMonitor

用于对Node的有效性检测。它会根据NodeManager最后发送的heartbeat的时间，以及设置好的检测间隔，进行Node的有效性检查。一旦认为某个Node已经过期了，那么就会将在这个Node上运行的Container标记为dead状态，并在其他的正常的节点上进行调度。一旦一个Node已经过期，那么就不会再为这个Node分配任何容器，直到它恢复正常。

（3）NodeListManager

用于维护着一个Node白名单以及Node黑名单。启动时，它们分别被从'yarn.resourcemanager.nodes.include-path'以及'yarn.resourcemanager.nodes.exclude-path'中读取。当一个白名单中的Node被Administrator手动撤销，那么它就会进入到Node黑名单中。

2.2.4其他核心组件

（1）ApplicationManager

• 用于维护一个可用Application列表，当一个Client提交一个Application的时候，ResourceManager首先会验证这个Application需要的资源是否合适，然后验证这个Application是否已经被加载过。最终，ResourceManager会将它提交给Scheduler。
• 负责在一个Application完成后以及被完全清理之前，管理它们。当一个Application完成后，它会生成一个ApplicationSummary，并将它记录到daemon的日志文件中。

ResourceManager中有一个属性-'yarn.resourcemanager.max-completed-applications'，这个属性控制ResourceManager最多能够维护多少个已经完成但没有被清理的Application。这就相当于一个FIFO队列，一旦超过了这个阈值，最早的Application就会被从这个队列中清除（暂时不清楚作用是什么）

（2）ApplicationMasterLauncher

Container都是由ApplicaitonMaster告诉NodeManager，然后NodeManager来加载的。但是对于ApplicationMaster这个容器比较特殊，它是由ResourceManager直接告诉NodeManager去加载的。而ApplicationMasterLauncher就是负责这个工作的。

在ApplicationMasterLauncher的内部有一个线程池，用于启动ApplicationMaster。它不仅会为新提交的Application启动ApplicationMaster，也会为那些失败的ApplicationAttempt重启一个ApplicationMaster。在一个Application完成后，它也负责告诉NodeManager来清理ApplicationMaster。

（3）YarnScheduler

用于负责将Application分配到对应的队列上。它会基于CPU，内存，磁盘等进行调度。

（4）ContainerAllocationExpirer

用于确保为ApplicationMaster分配的Container都会被加载。

2.2.5安全相关组件

（1）RMContainerTokenSecretManager

负责为Container生成ContainerToken，并维护这些信息。

ContainerToken中维护着和这个Container相关的一些信息，并且被加密过。

由于ApplicationMaster是不被信任的，所以我们需要ContainerToken，让NodeManager来验证这个Container是否确实是ResourceManager分配的，以及是否确实就是在这个NodeManager上运行的等其他信息。

ContainerToken中，包含下面的信息:

• Container ID
• NodeManager address
• Application submitter
• Resource

• Expiry timestamp
• Master key identifier: ResourceManager生成的一个安全密钥
• ResourceManager identifier: 由于在ResourceManager分配给ApplicationMaster容器之后，以及这个容器被从NodeManager启动之前，ResourceManager可能挂掉并启动了一个新的。为了避免这种情况，就需要ResourceManager将它的ID也编码到ContainerToken中。如果一个NodeManager重启，它会停掉之前运行的所有的Container，NodeManager也会拒绝运行由以前的ResourceManager分配的Container.

（2）AMRMTokenSecretManager

负责为每个ApplicationMaster都生成一个Token。ResourceManager会通过这个Token验证每个来自ApplicationMaster的请求。

（3）NMTokenSecretManager

ApplicationMaster通过NMToken来和NodeManager进行通讯。

（4）RMDelegationTokenSecretManager

负责为Client生成一个token。

（5）DelegationTokenManager

负责在Kerberos验证中，为已提交的Application生成一个新的Token。

3.Yarn之NodeManager

3.1NodeManager主要职责

（1）定时向ResourceManager汇报Container状态

（2）响应ResourceManager和ApplicationMaster的请求，例如启动或清除Container的命令

（3）监控Container资源使用情况

（4）管理Container日志文件

（5）监控Node节点的状态

3.2NodeManager主要组件

3.2.1NodeStatusUpdater

• 负责定时向ResourceManager汇报NodeManager的Container状态、NodeManager刚启动的Container以及完成的Container。
• 负责执行ResourceManager返回的命令，例如让NodeManager Kill掉一个Container。

3.2.2ContainerManager

（1）RPC Server

负责接收来自ApplicationMaster的请求（运行或者停止一个Container）

（2）ResourceLocalizationService

负责将Resource进行本地化，根据不同的Resource visibility - PUBLIC, APPLICATION, PRIVATE，会执行不同的本地化操作

（3）ContainersLauncher

内部维护一个线程池，用于准备并启动Container。当RPC Server（ApplicationMaster发来的Clean up Container请求）接收到一个Clean up请求，或者NodeStatusUpdater（ResourceManager发来的Clean up Container请求）接收到一个Clean up请求时，它会对相应的Container做Clean up操作。每个启动或者Clean up的操作，都是在一个线程中执行的，并且直到对应的操作完成才会返回。所以，不同Container之间是相互不影响的。

（4）ContainersMonitor

监控Container占用的资源是否超过了给它配制的最大值，如果是，则将它Kill掉。

（5）LogHandler

负责决定是在这个NodeManager保存Container的日志，还是将它压缩打包之后，上传到某个文件系统上。

3.2.3ContainerExcutor

负责从操作系统层面启动Container。

3.2.4NodeHealthCheckerService

这个组件会通知经常执行预先配制的检查脚本，来检查Node是否有问题。此外，它还可以通过创建临时文件的方式，检查Node的磁盘是否有问题。每一次这个信息修改，都会被发送给NodeStatusUpdater。最后被发送给ResourceManager.

3.2.5ContainerTokenSecretManager

用于验证ApplicationMaster让NodeManager启动的Container,都经过ResourceManager验证过。

3.2.6WebServer

提供一个Web界面，里面包含了Application列表，Node状态，Container日志等信息。

4.Yarn之ApplicationMaster

4.1ApplicationMaster主要职责

（1）定时向ResourceManager发送心跳信息

（2）计算一个Application所需资源

（3）通过ResourceRequest的形式向ResourceManager申请资源，ResourceManager返回Container清单

（4）与NodeManager交互从而加载ResourceManager分配的Container

（5）跟踪Container的状态

（6）处理Container和Node的故障问题

当ApplicationMaster注册到ResourceManager时，它可以向ResourceManager发送IPC address或者Web URL，而ResourceManager作为响应，会返回给它一些它需要的信息，比如ResourceManager能够接受的最小以及最大的Resource的限制，Application的ACL等。

在ApplicationMaster成功注册到ResourceManager之后，它就需要不间断地向ResourceManager发送心跳信息，保证ResourceManager知道它还存活。

如果ApplicationMaster积累了足够多的ResourceRequest，或者已经到了再次发送heartbeat的时候了，那么它就会通过heartbeat信息，将这些ResourceRequest发送给ResourceManager.

ResourceRequest是ApplicationMaster发送给ResourceManager的用于请求Resource的一个数据结构。它包含了:

• Priority of the request
• Resource location。当前接受一台主机的名称或者一个机架的名称。有一个比较特殊的值，"*"代表任何主机或者机架都可以。
• 请求的各种资源。比如内存，CPU。
• Container的数量，以及对应的Priority和Resource location.
• relaxLocality flag。这个flag用于告诉ResourceManager如果不能在指定的Resource location上面分配，是否选择一个与它相邻的。

当ApplicationMaster从ResourceManager中取到Container之后，它就开始在NodeManager上真正启动这个Container。

ApplicationMaster会构造一个ContainerLaunchContext对象，这个对象中，包含了运行一个Container所需要的全部信息，比如ResourceManager分配给这个容器的Resource、一些token、Container要执行的命令、环境变量等。它既可以一个一个地启动这些Container，也可以一次把它们全部启动起来。

在NodeManager接收到AppliationMaster的请求之后，它会发送一个列表作为响应，里面包含了已经成功启动的Container，以及失败的Container，以及NodeManager上全部AuxiliaryService相关的元数据。

ApplicationMaster也可以告诉NodeManager来停止Contaienr，通过发送一个StopContainersRequest，这个请求包含了要停止的Container的ID。NodeManager会回复一个StopContainersResponse，告诉ApplicationMaster哪些Container已经成功停止。此外，处理Container失败的情况，是Application的责任。YARN只是将集群中的资源暴露给Application。所以ApplicationMaster需要观察Container的状态、exit code、以及一些诊断信息。例如当MapReduce ApplicationMaster知道一个Container失败之后，它会不断重试这个Map或者Reducer，通过跟ResourceManager沟通分配Container。直到达到了指定的最大重试阈值。

此外，ApplicationMaster也需要在它自己发生错误并恢复后，恢复之前的Applicaiton的信息。当一个ApplicationMaster发生错误之后，ResourceManager只会启动一个新的ApplicationAttempt，并为其分配一个ApplicationMaster。这个新的ApplicationMaster应该能够自动检索旧的ApplicationMaster中的Application的信息。当然，如果从头再运行一个也是可以的。但是毕竟性能可能低一些。

在MapReduce中，ApplicationMaster会恢复已经完成的Task，而那些在ApplicationMaster恢复过程中仍在运行的Task，则会被Kill掉。

当一个ApplicationMaster已经完成了它的全部工作之后，它应该向ResourceManager发送一个FinishApplicationRequest的请求，来取消注册。在这个请求中，ApplicationMaster可以告诉ResourceManager一个IPC以及Web URL，让Client能够检索这个Application的历史信息。

5.疑惑

Application经过ResourceManager的ApplicationManager的检验之后，会将符合条件的Application提交给Yarn Scheduler进行资源的调度分配，而ApplicationMaster则会计算Application的资源并向ResourceManager申请资源。在这一过程中，我的疑问如下：

（1）既然ResourceManager的Yarn Scheduler已经会为Application分配资源，形成一个Container清单返回ApplicationMaster，那么ApplicationMaster的计算资源这一个步骤到底是何意呢？

我目前暂时的理解是：提交Application给Yarn Scheduler只是将满足条件的Application加入处理队列中，ApplicationMaster会通过计算划分需要多少个Container、每个Container分布在哪个Node节点上，然后向ResourceManager申请资源，之后Yarn Scheduler会根据ApplicationMaster的需求进行资源的调度分配。总的来说就是ApplicationMaster提供资源调度策略，Yarn Scheduler根据这个策略进行具体的资源调度分配。

以上只是本人一些粗略的见解，若有错误，欢迎大神们给我指点一下，在此感谢！！！