yarn 框架

1. 简述什么是Yarn ？

Yarn是一个资源调度平台，负责为运算程序提供服务器运算资源，相当于一个分布式的操作系统平台，而mapreduce等运算程序则相当于运行于操作系统之上的应用程序。
在hadoop1.0中有一些弊端，比如hdfs元数据信息保存的单节点故障，并且任务计算框架只能使用mapreduce，而且造成了任务管理器的压力过大，因此在hadoop2.0中加入了yarn资源统一管理的机制，不仅解决了元数据单节点故障问题（双namenode）而且实现了元数据的实时热备（共享机制JournalNode），在hdfs和mr之间加入了yarn，统一协调资源。
主要角色：
Resource Manager：资源管理器，负责整个集群的资源分配，只在NameNode上。RM包括两个组件，一个是Application Manager，用于管理集群中的所有用户作业；另一个是Scheduler。
Node Manager：节点管理器，负责在单个节点上启动和监控Container，在所有节点上都有一个。向RM负责并保持心跳。
Container：容器负责任务的具体执行，可以是一个进程，也可以是一个Linux cgroup，可以配置，每个容器都有资源限制（CPU，内存），一个Container代表一个节点上的一组资源。
Application Master：对于向Yarn提交的应用，Application Master是这个应用的中枢，负责监控应用的信息。Application Master自身也在一个Container里，与Node Manager协同工作来执行/监控Container。Application Master会通过心跳与Resource Manager建立联系，申请资源；心跳应答中，Application Master会收到绑定了一组资源的Container租约。
RM（Resource Manager）主要负责的是在不同应用之间调度资源，AM(Application Master)负责应用的进程状态信息的监控和容错等。

2. 简述YARN基础架构 ？

Yarn总体上是master/slave结构，主要由ResourceManager、NodeManager、ApplicationMaster和Container等几个组件组成。

1.1 RM
RM 是一个全局的资源管理器，负责整个系统的资源管理和分配，它主要由两个部分组成：调度器（Scheduler）和应用程序管理器（Application Manager）。
调度器根据容量、队列等限制条件，将系统中的资源分配给正在运行的应用程序，在保证容量、公平性和服务等级的前提下，优化集群资源利用率，让所有的资源都被充分利用。
应用程序管理器负责管理整个系统中的所有的应用程序，包括应用程序的提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重启它。

1.2 AppMaster
用户提交的一个应用程序会对应于一个ApplicationMaster，它的主要功能有：

a.与RM 调度器协商以获得资源，资源以Container 表示。
b.将得到的任务进一步分配给内部的任务。
c.与NM 通信以启动/停止任务。
d.监控所有的内部任务状态，并在任务运行失败的时候重新为任务申请资源以重启任务。

1.3 NodeManager
NodeManager 是每个节点上的资源和任务管理器，一方面，它会定期地向RM 汇报本节点上的资源使用情况和各个Container 的运行状态；另一方面，他接收并处理来自AM 的Container 启动和停止请求。

1.4 Container
Yarn中的资源抽象，它封装了某个节点上的多维度资源，如内存，CPU，磁盘，网络等。AppMaster向NodeManager申请资源的时候，资源是以container的形式表示的。一个应用程序会分配一个Container，这个应用程序只能使用这个Container 中描述的资源。不同于MapReduceV1 中槽位slot 的资源封装，Container 是一个动态资源的划分单位，更能充分利用资源。

3. 简述YARN有什么优势，能解决什么问题 ？

YARN的优点：
解决了单点故障问题，由于每一个任务由一个AppMaster进行调度，且可进行AppMaster出错重试， 从而使单点故障影响到多个任务进行问题不存在。

解决了单点压力过大问题，每一个任务由一个AppMaster进行调度，而每一个AppMaster都是由集群 中资源较为充足的结点进行启动，调度任务，起到一个负载均衡的作用。
完成了资源管理和任务调度的解耦，Yarn只负责对集群资源的管理，各个计算框架只要继承了AppMaster，就可以共同使用Yarn资源管理，更加充分地利用集群资源。

解决的问题：
在Hadoop 1.x版本时，JobTracker和TaskTracker是常服务，资源管理和任务调度的耦合，而在Hadoop 2.x 版本之后，Yarn将二者分离，只有资源管理成为了常服务，而任务调度则变成只有任务在调度时，才启 用的临时服务。

4. 简述YARN资源调度平台三大组件 ？

（1）Resource Manager（RM） ：负责资源的分配与调度，接收客户端请求、监控NodeManager以及Application Master
（2）Node Manager（NM） ：负责管理本机资源，处理Resource Manager与Application Master相关命令
（3）Application Master（AM） ：运行在NodeManager节点中，负责向Resource Manager申请资源并分配给内部任务和任务监控、容错以及销毁等工作（每个Job任务都有一个对应的AppMaster）

5. 简述YARN提交MR的流程 ？

① 客户端提交任务到Yarn集群中的RM
② 然后RM随机找一台有资源的NM节点，用于启动AppMaster程序。节点启动后，AppMaster汇报给RM并建立心跳机制
③ RM准备好AppMaster申请的资源信息，等待AppMaster的拉取
④ AppMaster拉取到了相关的资源后连接对应NM节点, 让其启动MapTask和ReduceTask并占用相关的资源，同时反向注册回AppMaster
⑤ AppMaster开始任务分配工作。各个任务向AppMaster汇报自己的状态和进度，以便当任务失败时可以重启任务。当任务执行结束时AppMaster会通知NM自动回收资源

6. 简述YARN的三种调度方案及特征 ？

（1）FIFO scheduler（先进先出的调度器）
一般不使用，除非整个集群就你自己用

措施：根据作业的提交顺序，先来先服务
优势：保证每一个任务拿到最大的资源
弊端：如果第一个任务比较大, 有可能将整个集群中所有的资源都占用了, 导致后续的任务长时间等待

（2）Capacity Scheduler（容量调度器）
Apache官方版本默认的调度方案

措施：可以提前定义多个队列(每个队列依然是FIFO特性)，每个队列可以使用集群中部分资源。
优势：可以让多个部门都拥有一部分资源, 不会因为某个部门将全部资源占用, 而导致其他部门没有资源可用, 同时通过资源抢占, 可以让大的任务拥有更多的一些资源(一般拿不到100%资源)
弊端：如果遇到超大任务, 由于无法获取到资源中所有资源, 可能会导致任务执行效率会有所降低

（3）Fair Scheduler（公平调度器）
CDH商业版本hadoop默认采用的调度方案

措施：当任务到达队列后, 集群会将所有的资源都交给第一个任务, 让其获取最大的资源 以达到快速运行, 在此运行过程中, 如果有了新的任务到来, 会让其先前释放出最多50%资源, 交给下一个任务来运行, 当下一个任务执行完成后, 如果发现上一个任务依然没有跑完, 还会在此将资源交给上一个任务
注意：在找上一个任务获取资源的时候, 采用 先等待 后强制措施
优势：可以保证让所有任务都拿到相对公平的资源, 保证大家都可以运行
弊端：如果任务量比较庞大, 而且每个任务也都比较庞大, 可能会导致长时间无法运行完

7. 简述YARN容错机制 ？

任务失败可能存在以下几种情况：

MapTask或者ReduceTask中由于代码原因抛出异常，jvm在关闭之前，会通知mrAppMaster这个task任务 失败，在mrAppMaster中，错误报告被写入到用户日志并且任务标记为失败，并释放jvm资源，供其他任 务使用。对于streaming任务，如果streaming进程以非0退出代码退出，则被标记为失败。这种行为由stream.non.zero.is.failure属性（默认值为true）控制。
jvm突然退出，可能是由于jvm缺陷而导致mr用户代码由于某种特殊原因造成jvm退出。nodeManage会将 这消息通知到mrAppMaster，标记此次任务失败。
任务挂起（可能是由于资源不足造成）：一旦mrAppMaster一段时间没有接收到进度的更新，则将任务 标记为失败，nodeManager会将该jvm进程杀死。任务失败时长可以由mapreduce.task.timeout来设置。 如果为0 ，则表示关闭。如果关闭这个属性，那么可能会造成长时间运行的任务不会被标记为失败，被挂起的任务就会一直不被释放资源，长时间会造成集群效率降低，因此尽量避免这个设置。同时充分保 证每个任务定期更新进度。

处理阶段：
当mrAppMaster被告知，一个任务失败的时候，会重新调度该任务。mrAppMaster会尝试避免在以前失败 过的nodeManager重新调度该任务。此外，一个任务失败的次数超过4次，将不会再重新调度。这个数值 由mapreduce.map.maxattempts控制。如果一个任务失败次数大于该属性设置的，则整个作业都会失败。对于一些应用程序中，不希望少部分任务失败，而导致整个作业失败，因为即使一些任务失败，作 业的输出结果也是可用的，我们可用通过运行任务失败的最大比例：maptask由mapreduce.map.failures.maxpercent，reducetask由mapreduce.reduce.failures.maxpercent来设置。任务尝试也是可以用来中止（killed），因为它是一个推测副本（如果一个任务执行时间比预期的慢的时候， 会启动另外一个相同的任务作为备份，这个任务为推测执行）或者它所在的nodeManager失败，导致该nodeManager所执行的任务被标记为killed，被中止的任务是不会被记录到任务运行尝试次数。
在YARN中，ApplicationMaster有几次尝试次数，最多尝试次数由：mapreduce.am.max-attempts和
yarn.resourcemanager.am.max-attempts确定，默认为2。
mapreduce.am.max-attempts：表示mrAppMaster失败最大次数
yarn.resourcemanager.am.max-attempts：表示在YARN中运行的应用程序失败最大次数。 所以如果要设置mrAppMaster最大失败次数，这两个都需要设置。

在ApplicationMaster向resourceManager定期发送心跳，当ResourceManager检查到ApplicationMaster失败 的时候，ResourceManager会在新的NodeManager开启新的ApplicationMaster实例。如果是mrAppMaster，则会使用作业历史来恢复作业的运行状态，不必重新运行，由yarn.app.mapreduce.am.job.recovery.enable来控制该功能。
MapReduce客户端向mrAppMaster来轮询进度报告，如果mrAppMaster失败了，则客户端通过询问ResourceManager会定位新的mrAppMaster实例。在整个MapReduce任务作业初始化的时候，客户端会向ResourceManager询问并缓存mrAppMaster地址。

当NodeManager由于奔溃或者非常缓慢运行而失败，会停止向ResourceManager发送心跳信息。则如果10 分钟内（由yarn.resourcemanager.nm.liveness-monitor.expiry-interval-ms来设置，以ms为单位），
ResourceManager会停止通知发送的NodeManager，并将起从自己的节点池中移除。
在失败的NodeManager上的任务或者ApplicationMaster将由上面的机制恢复。对于曾经在失败的
NodeManager运行并且成功的Map Task，如果属于为完成的作业，则ApplicationMaster则会重新分配资源重新运行，因为输出结果在失败的NodeManager的本地文件系统中，Reduce任务可能无法访问到。
如果在一个NodeManager中，任务失败次数过多，即使自己并没有失败过，则ApplicationMaster则会尽 量将任务调度到其他的NodeManager上。失败次数由mapreduce.job.maxtaskfailures.per.tracker设置。

在YARN中，ResourceManager失败是个致命的问题，如果失败，任何任务和作业都无法启动。在默认配 置中，ResourceManager是单点故障。为了获得高可用（HA），我们需要配置一对ResourceManager，在 主ResourceManager失败后，备份ResourceManager可以继续运行。
将所有的ApplicationMaster的运行信息保存到一个高可用的状态存储中（由ZooKeeper或者HDFS备份），这样备份ResourceManager就可以恢复出失败的ResourceManager状态。当新的ResourceManager 从存储区读取ApplicationMaster，然后在集群中重启所有ApplicationMaster。这个行为不会计入到ApplicationMaster尝试。
ResourceManager在主备切换由故障转移器（failover controller）处理。默认情况，failover controller自动工作，由ZooKeeper的Leader选举，保证同一时刻只有一个主ResourceManager。不同于HDFS的HA， 该failover controller不必是单独的进程，而是嵌入ResourceManager中。

8. 简述YARN高可用实现机制 ？

ResourceManager(RM)负责资源管理，并调度应用作业。在Hadop2.4之前RsourceManage是单点的，容易 产生单点故障。HA 提供活动和备用的RM，解决了一个RM单点故障问题。
ResourceManager存在单点故障，基于Zookeeper实现HA，通常任务失败后，RM将失败的任务告诉AM，RM负责任务的重启，AM来决定如何处理失败的任务。RMAppMaster会保存已经运行完成的Task，启后无 需重新运行。

【集群概述】
（1）RM：ResourceManage:r一个集群只有一个active状态的,负责整个集群的管理和调度 处理客户端请求启动监控ApplicationMaster(AM,一个作业对应一个)

（2）监控NM
系统资源的分配和调度
NM：负责单个节点的资源管理和使用以及task运行定期想RM汇报本节点的资源使用情况和container运行情况接收处理RM对container的启停各种命令单节点资源管理和任务管理

（3）ZK：
在ZooKeeper上会有一个/yarn-leader-election/yarn1的锁节点，所有的ResourceManager在启动的时候， 都会去竞争写一个Lock子节点：/yarn-leader-election/yarn1/ActiveBreadCrumb，该节点是临时节点。ZooKeepr能够为我们保证最终只有一个ResourceManager能够创建成功。创建成功的那个ResourceManager就切换为Active状态，没有成功的那些ResourceManager则切换为Standby状态。

（4）ZKFC：
是RM里面的一个线程，在HDFS HA中，zkfc是一个独立的进程。作用 是监控RM的健康状态，并执行选举作用。
RMStateStoreRM会把job的信息存放在zookeeper的/rmstore目录下，active RM会向这个目录写app的信息。当active RM挂掉之后，standby RM会通过zkfc切换为active状态，然后从zookeeper的/rmstore目录下读取相应的作业信息。重新构建作业的内存信息，启动内部服务，开始接受NM的心跳信息，构建集群的资源信 息，并且接受客户端的作业提交请求

9. 简述YARN中Container是如何启动的 ？

1、ApplicationMaster的主要逻辑
AM与NM通信
AM与NM们通过NMClientAsync通信，后者需要调用方提供一个回调类，NM会在合适的时机调用回调类中的方法来通知AM。回调类被AM实现为NMCallbackHandler，其中最重要的两个函数是：
onContainerStarted()，当NM新启动了Containers时，会调用改方法，把Container列表传给它。
onContainerStopped()，当NM停止了一些Containers时，会调用改方法，把 Container 列表传给它。
AM与RM通信
AM与RM通过AMRMClientAsync通信。
首先，通过 AMRMClientAsync.registerApplicationMaster() 向 RM 注册自己。

然后AM开始提交对Container的需求，在申请到需要数量的Container之前，先调用setupContainerAskForRM()设置对Container的具体需求（优先级、资源等），然后调用AMRMClientAsync.addContainerRequest()把需求提交给RM，最终该方法会把需求存到一个集合(AMRMClient.ask)里面。
AMRMClientAsync同样需要调用方提供一个回调类，AM实现为RMCallbackHandler。这个回调类主要实现 了两个方法：
onContainersAllocated()，获得新申请的 Container，创建一个新线程，设置
ContainerLaunchContext，最终调用NMClientAsync.startContainerAsync() 来启动 Container。onContainersCompleted()，检查已完成的Container的数量是否达到了需求，没有的话，继续添加需 求。
AM的三个主流程
总结上面说的，AM有三个主要流程与Container的创建密切相关： 提交需求，通过心跳，把需求发送给RM；
获取Container，通过心跳，拿到申请好的Container；
每申请到一个Container ，与 NM 通信，启动这个Container；
分析清楚了这三个主流程，也就清楚了 YARN Container 的启动逻辑。
Application 与 ResourceManager 的心跳
再看RM这边，在AM向RM注册时，RM最终会生成一个代表这个APP的实例，我们先不分析注册的具体过程，只要知道在我们的情景下，最终是生成了一个FicaSchedulerApp。
AM与RM进行心跳，发送的信息中含有： AM告诉RM两个信息： a) 自己对Container的要求，b) 已经用完的待回收的Container列表。
RM给AM的回应：a) 新申请的 Container，b) 已经完成的 Container 的状态。
ApplicationMasterService是RM的一个组成部分。RM启动时，会初始化这个服务，并根据配置，把相应的 调度器YarnScheduler传进来。它实现了ApplicationMasterProtocol接口，负责对来自AM的 RPC 请求进行回应。在我们的情景中， ApplicationMasterService.allocate() 方法会被调用，核心逻辑是：
触发 RMappAttemptStatusupdateEvent 事件。
调用 YarnScheduler.allocate() 方法，把执行的结果封装起来返回。YarnScheduler 是与调度器通信的接口。所以，最后调用的是具体调度器的 allocate() 方法。
我们使用的是 FIFO 调度器，FifoScheduler.allocate() 方法的主要做两件事情：
调用FicaSchedulerApp.updateResourceRequests()更新APP（指从调度器角度看的APP) 的资源需求。通过FicaSchedulerApp.pullNewlyAllocatedContainersAndNMTokens()把
FicaSchedulerApp.newlyAllocatedContainers这个 List 中的Container取出来，封装后返回。
FicaSchedulerApp.newlyAllocatedContainers 这个数据结构中存放的，正是最近申请到的 Container 。那么，这个 List 中的元素是怎么来的呢，这要从 NM 的心跳说起。
NodeManager与ResourceManager的心跳
NM 需要和 RM 进行心跳，让 RM 更新自己的信息。心跳的信息包含：
Request(NM->RM) : NM 上所有 Container 的状态；
Response(RM->NM) : 已待删除和待清理的 Container 列表
NM 启动时会向RM注册自己，RM生成对应的RMNode结构，代表这个NM ，存放了这个NM的资源信息以及其他一些统计信息。

负责具体心跳的，在NM这边是NodeStatusUpdater服务，在RM那边则是ResourceTrackerService服务。心 跳的信息包括这个NM的状态，其中所有Container的状态等。
心跳最终通过RPC调用到了ResourceTrackerService.nodeHeartbeat() 。其核心逻辑就是触发一个
RMNodeStatusEvent(RMNodeEventType.STATUS_UPDATE) 事件，这个事件由 NM 注册时生成的RMNode处理。
RMNode接收RMNodeStatusEvent(RMNodeEventType.STATUS_UPDATE) 消息，更新自己的状态机，然后调用 StatusUpdateWhenHealthyTransition.transition ，该方法从参数中获得这个NM所有的Container的信
息，根据其状态分成两组：a) 刚申请到还未使用的，b) 运行完毕需要回收的，这两组 Container 的信息存放在 RMNode 的一个队列中。接着，发出一个消息：
NodeUpdateSchedulerEvent（SchedulerEventType.NODE_UPDATE） 。这个消息，由调度器处理。
ResourceManager处理 NODE_UPDATE 消息
RM 接收到 NM 的心跳后，会发出一个 SchedulerEventType.NODE_UPDATE 的消息，改消息由调度器处理。FifoScheduler 接收到这个消息后，调用了 FifoScheduler.nodeUpdate() 方法。与 Container 申请相关的主要逻辑如下：
获取已申请到的
从 RMNode 中获取出那些「刚申请还未使用」的 Container （NM 与 RM 心跳是获得），发出消息：
RMContainerEventType.LAUNCHED，该消息由 RMContainer 处理；
回收已完成的
从 RMNode 中获取出那些「已经使用完待回收」的 Container，进行回收（具体回收过程略）；
申请新的
在这个 NM 上申请新的 Container：
通过 FicaSchedulerApp.getResourceRequest() 拿到资源请求（ResourceRequest）
计算可申请的资源，调用 FicaSchedulerApp.allocate()，根据传进来的参数，封装出一个 RMContainer 添加到 newlyAllocatedContainers 中。然后触发事件 RMContainerEventType.START。该事件之后会由
RMContainer 处理。
调用 FicaSchedulerNode.allocateContainer()和RMContainer对RMContainerEventType事件进行处理处理： RMContainerEventType.START : 状态从 NEW 变为 ALLOCATED，最终触发事件
RMAppAttemptEvent(type=CONTAINER_ALLOCATED)， 改事件由 RMAppAttemptImpl 处理。
RMContainerEventType.LAUNCHED : 状态从 ACQUIED 变为 RUNNING 。
RMAppAttemptImpl对RMAppAttemptEvent事件进行处理，该事件告诉就是告诉AppAttempt ，你这个APP 有Container申请好了，AppAttempt 检查自己的状态，如果当前还没有运行AM ，就把这个Container拿来运行AM。
到此，我们已经理清楚了FicaSchedulerApp.newlyAllocatedContainers中元素的来源，也就理清楚了，AM 与 RM 心跳中获得的那些「新申请」的 Container 的来源。
ApplicationMaster 与 NodeManager 通信启动 Container
关于“AM的三个主流程”，上面已经讲过了。
基于上面的分析，第1，2两个流程已经清楚。下面我们来具体看看 NM 具体是怎么启动一个 Container
的。
AM 设置好 ContainerLaunchContext , 调用 NMClientAsync.startContainerAsync() 启动Container。
NMClientAsync 中有一个名叫 events 的事件队列，同时，NMClientAsync 还启动这一个线程，不断地从
events 中取出事件进行处理。

startContainerAsync() 方法被调用时，会生成一个 ContainerEvent(type=START_CONTAINER) 事件放入events 队列。对于这个事件，处理逻辑是调用 NMClient.startContainer() 同步地启动 Container ，然后调用回调类中的 onContainerStarted() 方法。
NMClient 最终会调用 ContainerManagementProtocol.startContainers() ，以 Google Protocol Buuer 格式， 通过 RPC 调用 NM 的对应方法。NM 处理后会返回成功启动的 Container 列表。
NodeManager 中启动 Container ContainerManagerImpl
NM 中负责响应来自 AM 的 RPC 请求的是 ContainerManagerImpl ，它是 NodeManager 的一部分，负责
Container 的管理，在 Nodemanager 启动时，该服务被初始化。该类实现了接口ContainerManagementProtocol ，接到 RPC 请求后，会调用 ContainerManagerImpl.startContainers() 。改函数的基本逻辑是：
首先进行 APP 的初始化（如果还没有的话），生成一个 ApplicationImpl 实例，然后根据请求，生成一堆 ContainerImpl 实例
触发一个新事件：ApplicationContainerInitEvent ，之前生成的 ApplicationImpl 收到改事件，又出发一个 ContainerEvent(type=INIT_CONTAINER) 事件，这个事件由 ContainerImpl 处理
ContainerImpl 收到事件， 更新状态机，启动辅助服务，然后触发一个新事件
ContainersLaucherEvent(type=LAUNCH_CONTAINER) ，处理这个事件的是 ContainersLauncher 。
ContainerLauncher 是 ContainerManager 的一个子服务，收到
ContainersLaucherEvent(type=LAUNCH_CONTAINER) 事件后，组装出一个 ContainerLaunch 类并使用
ExecutorService 执行。
ContainerLaunch 类负责一个 Container 具体的 Lanuch 。基本逻辑如下：
设置运行环境，包括生成运行脚本，Local Resource ，环境变量，工作目录，输出目录等触发新事件 ContainerEvent(type=CONTAINER_LAUNCHED)，该事件由 ContainerImpl 处理。调用 ContainerExecutor.launchContainer() 执行 Container 的工作，这是一个阻塞方法。
执行结束后，根据执行的结果设置 Container 的状态。
ContainerExecutor
ContainerExecutor 是 NodeManager 的一部分，负责 Container 中具体工作的执行。该类是抽象类，可以有不同的实现，如 DefaultContainerExecutor ，DockerContainerExecutor ，LinuxContainerExecutor 等。根据 YARN 的配置，NodeManager 启动时，会初始化具体的 ContainerExecutor 。
ContainerExecutor 最主要的方法是 launchContainer() ，该方法阻塞，直到执行的命令结束。
DefaultContainerExecutor 是默认的 ContainerExecutor ，支持 Windows 和 Linux 。它的 launchContainer()
的逻
创建 Container 需要的目录
拷贝 Token、运行脚本到工作目录
做一些脚本的封装，然后执行脚本，返回状态码
至此，Container 在 NM 中已经启动，AM 中 NMCallback 回调类中的 onContainerStarted() 方法被调用

10. 简述YARN的改进之处，Hadoop 3.x相对于Hadoop 2.x ？

YARN Timeline Service版本更新到v.2
本版本引入了Yarn时间抽服务v.2，主要用于解决2大挑战：改善时间轴服务的可伸缩性和可靠性，通过 引入流和聚合增强可用性。
YARN Timeline Service v.2 alpha 1可以让用户和开发者测试以及反馈，以便使得它可以替换现在的Timeline Service v.1.x。

11. 简述Yarn作业执行流程 ？

1.用户向 YARN 中提交应用程序，其中包括 MRAppMaster 程序，启动 MRAppMaster 的命令，用户程序等。
2.ResourceManager 为该程序分配第一个 Container，并与对应的 NodeManager 通讯，要求它在这个 Container 中启动应用程序 MRAppMaster。
3.MRAppMaster 首先向 ResourceManager 注册，这样用户可以直接通过 ResourceManager 查看应用程序的运行状态，然后将为各个任务申请资源，并监控它的运行状态，直到运行结束，重复 4 到 7 的步骤。
4.MRAppMaster 采用轮询的方式通过 RPC 协议向 ResourceManager 申请和领取资源。
5.一旦 MRAppMaster 申请到资源后，便与对应的 NodeManager 通讯，要求它启动任务。
6.NodeManager 为任务设置好运行环境（包括环境变量、JAR 包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。
7.各个任务通过某个 RPC 协议向 MRAppMaster 汇报自己的状态和进度，以让 MRAppMaster 随时掌握各个任务的运行状态，从而可以在任务败的时候重新启动任务。

12. 简述YARN完整的工作机制 ？

作者：酸辣鱼籽酱
链接：https://ac.nowcoder.com/discuss/951014?type=0&order=3&pos=12&page=0&channel=-1&source_id=discuss_center_0_nctrack
来源：牛客网

1）作业提交
2）作业初始化
3）任务分配
4）任务运行
5）进度和状态更新
6）作业完成

● 第1步：Client调用job.waitForCompletion方法，向整个集群提交MapReduce作业。
● 第2步：Client向RM申请一个作业id。
● 第3步：RM给Client返回该job资源的提交路径和作业id。
● 第4步：Client提交jar包、切片信息和配置文件到指定的资源提交路径。
● 第5步：Client提交完资源后，向RM申请运行ApplicationMaster。
● 第6步：当RM收到Client的请求后，将该job添加到容量调度器中。
● 第7步：某一个空闲的NM领取到该Job。
● 第8步：该NM创建Container，并产生ApplicationMaster。
● 第9步：下载Client提交的资源到本地。
● 第10步：ApplicationMaster向RM申请运行多个MapTask任务资源。
● 第11步：RM将运行MapTask任务分配给另外两个NodeManager，另两个NodeManager分别领取任务并创建容器。
● 第12步：MR向两个接收到任务的NodeManager发送程序启动脚本，这两个NodeManager分别启动MapTask，MapTask对数据分区排序。
● 第13步：ApplicationMaster等待所有MapTask运行完毕后，向RM申请容器，运行ReduceTask。
● 第14步：ReduceTask向MapTask获取相应分区的数据。
● 第15步：程序运行完毕后，MR会向RM申请注销自己。

13. 简述YRAN 如何监控 ？

在大数据处理中，Apache Hadoop是一个非常受欢迎的框架。作为Hadoop的一个核心组件，YARN（Yet Another Resource Negotiator）负责资源管理和作业调度。在实际应用中，对YARN任务进行监控和管理是非常重要的，因为它可以提供有关任务状态和性能的实时信息，帮助我们更好地理解和优化作业的执行。

本文将介绍如何使用Hadoop API和YARN命令行工具来监控YARN任务，并提供一些实用的代码示例。

监控YARN任务的方法

1. 使用Hadoop API
   Hadoop提供了丰富的API来管理和监控YARN任务。下面是一个使用Hadoop API获取YARN任务状态的示例代码：

import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.yarn.api.records.ApplicationId;
import org.apache.hadoop.yarn.api.records.ApplicationReport;
import org.apache.hadoop.yarn.client.api.YarnClient;
import org.apache.hadoop.yarn.client.api.YarnClientFactory;

public class YARNTasksMonitor {

public static void main(String[] args) throws Exception {
Configuration conf = new Configuration();
YarnClient yarnClient = YarnClientFactory.createYarnClient(conf);
yarnClient.init(conf);
yarnClient.start();

// 获取所有正在运行的YARN任务
List runningApps = yarnClient.getApplications();
for (ApplicationReport app : runningApps) {
System.out.println("Application ID: " + app.getApplicationId());
System.out.println("Application State: " + app.getYarnApplicationState());
// 其他任务信息…
}

yarnClient.stop();
}
}
上述代码使用YarnClient API来连接到YARN集群，并获取正在运行的YARN任务的状态信息。

2. 使用YARN命令行工具
   除了使用Hadoop API外，我们还可以使用YARN提供的命令行工具来监控YARN任务。下面是一些常用的YARN命令：

yarn application -list：列出所有正在运行的YARN应用程序。
yarn application -status ：获取指定YARN应用程序的状态。
yarn application -logs ：获取指定YARN应用程序的日志。
以下是一个使用命令行工具获取YARN任务状态的示例：

$ yarn application -list
$ yarn application -status application_161234567890_12345
$ yarn application -logs application_161234567890_12345
这些命令可以在YARN集群上的终端中执行。

监控YARN任务的实践
为了更好地说明如何监控YARN任务，我们将通过一个简单的示例来演示。假设我们有一个使用YARN运行的MapReduce作业，我们将监控该作业的运行状态和性能指标。

首先，让我们创建一个名为YARNJobMonitor的Java类。我们将使用上述的Hadoop API示例代码来获取YARN任务的状态。

import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.yarn.api.records.ApplicationReport;
import org.apache.hadoop.yarn.client.api.YarnClient;
import org.apache.hadoop.yarn.client.api.YarnClientFactory;

public class YARNJobMonitor {

public static void main(String[] args) throws Exception {
Configuration conf = new Configuration();
YarnClient yarnClient = YarnClientFactory.createYarnClient(conf);
yarnClient.init(conf);
yarnClient.start();

// 获取所有正在运行的YARN任务
List runningApps = yarnClient.getApplications();
for (ApplicationReport app : runningApps) {
System.out.println("Application ID: " + app.getApplicationId());
System.out.println("Application State: " + app.getYarnApplicationState());
// 其他任务信息…
}

yarnClient.stop();
}
}
然后，我们可以使用Maven来构建和运行该示例。在项目的根目录下，创建一个名为pom.xml的文件，并添加以下内容：

4.0.0
com.example
yarn-job-monitor
1.0-SNAPSHOT

org.apache.hadoop
hadoop-client
3.3