yarn kill job命令（yarn 常用命令）

大家好，我是讯享网，很高兴认识大家。

文章目录

1：yarn简介

1.1：设计思想
1.2：yarn架构
1.3：yarn的shell命令

1：集群操作

1.4：yarn的TimelineClient
1.5：为什么container容器被杀死

2：详解Scheduler调度器

2.1：CapacityScheduler容量调度器
2.2：Fair 公平调度器
2.3：FIFO Scheduler(先进先出调度器)

3：YARN 作业执行流程
4：yarn上的程序日志查看
5：资源管理器的发展

YARN 是一个资源调度平台，负责为运算程序提供服务器运算资源，相当于一个分布式的操作系统平台。Spark、Storm 等运算框架都可以整合在 YARN 上运行，只要他们各自的框架中有符合 YARN 规范的资源请求机制即可

1.1：设计思想

YARN 的基本思想是将资源管理和作业调度/监控的功能拆分为单独的守护进程。这个想法是有一个全局 ResourceManager ( RM ) 和每个应用程序 ApplicationMaster ( AM )。应用程序是单个作业或作业的 DAG。

ResourceManager 和 NodeManager 构成了数据计算框架。ResourceManager 是在系统中的所有应用程序之间仲裁资源的最终权威。NodeManager 是每台机器的框架代理，负责容器、监控它们的资源使用情况（cpu、内存、磁盘、网络）并将其报告给 ResourceManager/Scheduler。

yarn kill 掉现在所有的任务 yarn kill job命令_开发语言
讯享网

1.2：yarn架构

yarn kill 掉现在所有的任务 yarn kill job命令_应用程序_02

1：ResourceManager
RM(ResourceManager)是 YARN 集群主控节点，负责协调和管理整个集群（所有 NodeManager）的资源。ResourceManager 会为每一个 Application 启动一个 AppMaster，并且 AppMaster 分散在各个 NodeManager 节点。

ResourceManager 有两个主要组件：Scheduler 和 ApplicationsManager。

Scheduler 调度器负责根据熟悉的容量、队列等约束将资源分配给各种正在运行的应用程序。调度器是纯粹的调度器，因为它不执行应用程序的状态监控或跟踪。此外，它不保证由于应用程序故障或硬件故障而重新启动失败的任务。调度器根据应用程序的资源需求执行其调度功能；它是基于资源容器的抽象概念来实现的，该容器包含内存、CPU、磁盘、网络等元素。
2：NodeManager
NodeManager 是 YARN 集群当中真正资源的提供者，是真正执行应用程序的容器的提供者，监控应用程序的资源使用情况（CPU，内存，硬盘，网络），并通过心跳向集群资源调度器ResourceManager 进行汇报以更新自己的健康状态。同时其也会监督 Container 的生命周期管理，监控每个 Container 的资源使用（内存、CPU 等）情况，追踪节点健康状况，管理日志和不同应用程序用到的附属服务（auxiliary service）。
3：AppMaster
AppMaster对应一个应用程序，职责是：向YARN资源调度器申请执行任务的资源容器，运行任务，监控整个任务的执行，跟踪整个任务的状态，处理任务失败以异常情况
4：Container容器
Container 容器是一个抽象出来的逻辑资源单位。容器是由 ResourceManager Scheduler 服务动态分配的资源构成，它包括了一个节点上的一定量 CPU，内存，磁盘，网络等信息，容器的大小是可以动态调整的,其最大大小就是一个nodemanger的资源，一个container只能在一个容器上。
5：

1.3：yarn的shell命令

命令在bin/yarn目录下

命令格式: yarn [SHELL_OPTIONS] COMMAND [GENERIC_OPTIONS] [SUB_COMMAND] [COMMAND_OPTIONS]

1：集群操作

对hadoop集群操作有效命令大概如下：
格式：yarn application [options]

yarn上的程序相关操作
会获取yarn上app任务的运行日志，可以进行开启日志聚合功能，用于程序运行日志分析

yarn上的节点信息

1.4：yarn的TimelineClient

ARN 中以通用方式存储和检索应用程序的当前和历史信息。yarn的TimelineClient有两个功能

1：持久化应用程序特定信息
比如map任务以及reduce任务的数量等
2：保留有关已完成应用程序的通用信息
比如程序的运行日志，运行的队列，容器，用户等信息

也就是我们在web中或者等方式可以查看任务的历史情况，可以配置任务的保存期限等

1.5：为什么container容器被杀死

这可能是由于程序内存使用量超过了您请求的容器内存大小。导致这种情况的原因有很多。首先，查看 NodeManager 在杀死容器时转储的进程树。您感兴趣的两件事是物理内存和虚拟内存。如果您超出了物理内存限制，则您的应用使用了过多的物理内存。如果您正在运行 Java 应用程序，则可以使用 -hprof 查看堆中占用空间的内容。如果已超出虚拟内存，则可能需要增加集群范围的配置变量yarn.nodemanager.vmem-pmem-ratio 的值。

2.1：CapacityScheduler容量调度器

容量调度器:允许创建多个任务队列,每个队列使用所有资源的一部分。多个任务队列可以同时执行。但是一个队列内部还是先进先出。(Hadoop 2.7.2 默认的调度器);

2.2：Fair 公平调度器

2.3：FIFO Scheduler(先进先出调度器)

yarn kill 掉现在所有的任务 yarn kill job命令_java_03

利用yarn进行资源调度的程序，基本流程都和下面一致，包括spark,MR等数据处理组件

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

集中式调度器
集中式调度器最大的特点是全局只运行一个中央调度器，整合的计算框架的资源请求全部交给中央调度器来满足，所有的调度逻辑都由中央调度器来实现，所以调度器在遇到高并发的情况下很容易遇到瓶颈。
所有的调度逻辑都集中在中央调度器里，这对并发影响很大，所以在分配资源时，是完全顺序执行的，类似的调度框架有MRv1的JobTracker，目前已经淘汰。
双层调度器
顾名思义，双层调度器（two-level scheduler）将整个调度工作划分为两层：中央调度器和框架调度器。中央调度器管理集群中所有资源的状态，它拥有集群所有的资源信息，它按照一定的策略（如FIFO、Fair、Capacity、Delay、Dominant Resource Fair）将资源粗粒度地分配给框架调度器，各个框架收到资源后再根据作业特性细粒度地将资源分配给容器执行具体的计算任务。在这种双层架构中，每个计算框架看不到整个集群的资源，只能看到中央调度器给自己的资源。
二级调度器的存在大大减轻了中央调度器的负载，这对并发来说有很大提升，资源利用率也得到了提升。但由于中央调度器的存在，这种并发还是一种悲观并发。当中央调度器做出将某些资源分配给哪个计算框架的决策的时候，还是必须顺序执行，属于悲观锁。值得注意的是中央调度器还是保存在整个集群的资源信息，但每个二级调度器只能看到部分的集群资源信息。
这种双调度的实现有Apache YARN 和 Apache Mesos。

状态共享调度器
状态共享调度器是由Google公司的Omega调度系统提出的一种新范型。它大大弱化了中央调度器，只需要保存一份集群使用信息，取而代之的是各个框架调度器，每个调度器都能获取集群的全部信息，并采取了乐观锁控制并发。
Omega与双层调度器的不同在于严重弱化了中央调度器，每个框架内部会不断地从主调度器更新集群信息并保存一份，而框架对资源的申请则会在该份信息上进行，一旦框架做出决策，就会将该信息同步到主调度，资源竞争过程是通过事务进行的，从而保证了操作的原子性。由于决策是在自己的私有数据上做出的，并通过原子事务提交，系统保证只有一个胜出者，这是一种类似于MVCC的乐观并发机制，可以增加系统的整体并发性能