微信公众号:运维开发故事
作者:冬子先生
1. 概述
1.1. Yarn基本概念
YARN(Yet Another Resource Negotiator)是Hadoop 2.x的一个计算框架,旨在解决Hadoop 1.x中的资源管理和任务调度问题。它的主要目的是将MR1 JobTracker 的两个主要功能(资源管理和作业调度/监控)分离,以便更好地支持多种应用程序,而不是仅支持MapReduce。
YARN采用了全新的架构,包括ResourceManager、NodeManager和ApplicationMaster等组件。其中,ResourceManager负责整个集群中的资源分配,NodeManager负责管理并监控节点上的容器,ApplicationMaster是一个Yarn的客户端,用于管理当前任务的调度。
img
- ResourceManager(RM)
- 负责整个系统的资源管理和分配,包括处理客户端请求、启动/监控APP master、监控nodemanager、资源的分配与调度
- Scheduler: 根据容量、队列等限制条件(如每个队列分配一定的资源,最多执行一定数量的作业等),将系统中的资源分配给各个正在运行的应用程序。Yarn提供了多种直接可用的调度器,比如FIFO Scheduler、Fair Scheduler和Capacity Scheduler等。
- Applications Manager: 负责管理整个系统中所有应用程序,包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动它等。
- NodeManager(NM)
- 负责接收处理来自ResourceManager的资源分配请求,分配具体的Container给应用
- 它还负责监控并报告Container使用信息给ResourceManager
- Container是一个动态资源分配单位,它将内存、cpu、磁盘、网络等资源封装在一起,从而限定每个任务使用的资源量
- NodeManager只负责管理自身的Container,它并不知道运行在它上面应用的信息。负责管理应用信息的组件是ApplicationMaster
- ApplicationMaster
- 应用程序级别的,运行在Container中,管理运行在YARN上的应用程序。
- 向ResourceManager申请资源
- 和NodeManager协同工作来运行应用的各个任务
- 与NodeManager通信以启动或停止任务
- 监控所有任务运行状态,并在任务运行失败时重新为任务申请资源以重启任务
1.2. 任务管理及资源管理
通过YARN的任务管理,可以将任务分配到不同的容器中,运行在不同的节点上,以满足任务的不同需求。通过任务分配、任务监控和任务状态跟踪等方式,确保应用程序能够在集群中顺利运行。
同时,YARN的资源管理模块负责管理Master和slave节点的资源,包括CPU、内存和磁盘等资源。通过YARN的资源管理,可以实现有效的资源池管理,通过实现资源调度和资源分配策略,使得不同应用程序能够充分利用集群资源,优化集群的性能。
因此,YARN的任务管理和资源管理至关重要。接下来我们详细介绍yarn的任务管理及资源管理。
2. 任务管理
2.1. 任务运行流程
当用户向YARN中提交一个应用程序后,YARN将分两个阶段运行该应用程序:第一个阶段是启动ApplicationMaster;第二个阶段是由ApplicationMaster创建应用程序,为它申请资源,并监控它的整个运行过程,直到运行完成,如下图所示。
img
(1)作业提交
第1步:Client调用job.waitForCompletion方法,向整个集群提交MapReduce作业。
第2步:Client向RM申请一个作业id。
第3步:RM给Client返回该job资源的提交路径和作业id。
第4步:Client提交jar包、切片信息和配置文件到指定的资源提交路径。
第5步:Client提交完资源后,向RM申请运行MrAppMaster。
(2)作业初始化
第6步:当RM收到Client的请求后,将该job添加到资源调度器中。
第7步:某一个空闲的NM领取到该Job。
第8步:该NM创建Container,并产生MRAppmaster。
第9步:下载Client提交的资源到本地。
(3)任务分配
第10步:MrAppMaster向RM申请运行多个MapTask任务资源。
第11步:RM将运行MapTask任务分配给另外两个NodeManager,另两个NodeManager分别领取任务并创建容器。
(4)任务运行
第12步:MR向两个接收到任务的NodeManager发送程序启动脚本,这两个NodeManager分别启动MapTask,MapTask对数据分区排序。
第13步:MrAppMaster等待所有MapTask运行完毕后,向RM申请容器,运行ReduceTask。
第14步:ReduceTask向MapTask获取相应分区的数据。
第15步:程序运行完毕后,MR会向RM申请注销自己。
(5)进度和状态更新
YARN中的任务将其进度和状态返回给应用管理器, 客户端每秒(通过mapreduce.client.progressmonitor.pollinterval设置)向应用管理器请求进度更新, 展示给用户。
(6)作业完成
除了向应用管理器请求作业进度外, 客户端每5秒都会通过调用waitForCompletion()来检查作业是否完成。时间间隔可以通过mapreduce.client.completion.pollinterval来设置。作业完成之后, 应用管理器和Container会清理工作状态。作业的信息会被作业历史服务器存储以备之后用户核查。
2.2. 任务状态跟踪和监控
在任务运行过程中,YARN使用ApplicationMaster来跟踪和管理任务的状态,ApplicationMaster可以定期向ResourceManager汇报任务的状态,从而实现状态跟踪。此外,可以通过定期监控Container的状态,了解任务的运行情况和状态。
下面是YARN中应用程序和Container的状态详细过程:
2.2.1. Application 状态
是指YARN应用程序的状态。每个应用程序都有一个唯一的Application ID,并且可以通过ResourceManager API或YARN Web UI来获取应用程序的当前状态。在YARN中,应用程序状态可以有以下状态:
- NEW:应用程序刚创建时的状态。应用程序会被分配一个唯一的Application ID,但还没有分配资源,也没有进入资源队列。
- NEW_SAVING:应用程序等待资源保存。这个状态只存在于开启了Application历史保存的集群上,如果没有保存历史,则该状态的转换不会发生。
- SUBMITTED:应用程序已经提交给YARN,等待调度器处理,****尚未进行资源分配。
- 调度器会根据调度算法和优先级等因素,从队列中选择合适的应用程序并为其分配资源。调度器会考虑集群中的负载情况,保证资源的合理利用和公平共享。调度器完成后,应用程序的状态将被更新为"ACCEPTED"
- ACCEPTED:应用程序已经通过队列,并ResourceManager已经分配了它需要的初始和最小容器( 这只是一个预分配的过程,并不代表资源已经真正分配给了应用程序)。
- 应用程序已通过队列,并为其分配了初始和最小容器,但实际的计算资源尚未分配
- RUNNING:应用程序正在运行中,并具有正在运行的容器。
- 应用程序已获得实际的计算资源分配,并开始执行任务
- FINISHED:应用程序已经成功完成,并且其最终状态已经保存到YARN应用历史中。
- FAILED:应用程序运行失败,并且其最终状态已经保存到YARN应用历史中。
- KILLED:应用程序已被终止,并且其最终状态已经保存到YARN应用历史中。
img
img
示例:
- application_1687214371118_29142:
- 第一次查询时,任务状态为ACCEPTED,这个状态表示任务已经被ResourceManager接受并等待资源分配
- 等待资源分配的原因,可以是没有可用资源了,也可能是正在对任务进行一些准备工作,例如检查任务的依赖关系、资源需求等。这些准备工作可能需要一些时间。
- 一旦适当的资源可用,并且所有准备工作完成,任务将从ACCEPTED状态转换为RUNNING状态,并开始在相应的容器中运行
2.2.1.1. 资源不足情况下状态变化
当资源不足时,YARN的资源管理器会对应用程序的状态进行调整,以帮助其适应现有的资源情况。下面是YARN中应用程序状态在资源不足的情况下的状态变化:
- 如果应用程序在 SUBMITTED 状态时,发现资源不足,那么应用程序会进入 ACCEPTED****状态。在这种情况下,YARN会尝试为应用程序分配资源,但可能需要等待其他应用程序释放资源后才能成功分配。
- 如果应用程序在 ACCEPTED 状态时,发现资源不足,那么应用程序会进入等待状态。在等待状态下,应用程序不会分配任何容器,因为资源不足无法分配。
- 如果应用程序在等待状态中,尝试重新分配资源,但仍然可以找到空闲资源。在这种情况下,应用程序会返回 ACCEPTED 状态,并成功分配新的容器。
- 如果应用程序在等待状态中,无法重新分配资源,那么应用程序会转移到 KILLED 或 FAILED 状态。在这种情况下,应用程序无法分配所需的资源,因此无法完成任务。
2.2.2. Container 状态
指的是在YARN集群上运行的应用程序内部的container状态。在YARN集群上运行的应用程序是通过启动多个container来实现的,每个container都运行着应用程序的一部分(如MapReduce中的一个map或reduce任务),并使用一个或多个资源(如内存、CPU等)来执行任务。当一个应用程序启动后,它的容器状态可能有以下几种:
- NEW:Container刚刚创建,但还没有分配资源。
- LOCALIZED:Container已经获取了运行时环境和所需的资源,表示资源已经被分配给某个容器,但资源还未完全在该容器上本地化。在容器执行应用程序之前,需要将应用程序所需的资源(如JAR包、配置文件等)拷贝到容器所在的节点上,并在容器内部完成相关配置。完成本地化操作后,容器就可以开始执行应用程序。
- RUNNING:Container正在运行,并且已经分配了资源。
- COMPLETE:Container已经完成工作并退出。
- EXITED_WITH_SUCCESS:表示容器成功执行完毕,并且已经被清理。
- EXITED_WITH_FAILURE:表示容器执行失败,并且已经被清理。
从 NEW 状态到 LOCALIZED 状态,Container 会向 NodeManager 发起本地化请求,要求 NodeManager 将所需的资源复制到本地磁盘。从 LOCALIZED 状态到 RUNNING 状态,Container会通过启动进程来运行任务。在运行过程中,Container 可能会由于各种原因失败,进入 FAILED 状态。如果Container 顺利完成任务,则进入 COMPLETE 状态。
2.2.3. Yarn任务监控
Yarn提供了丰富的任务监控和管理功能,可以实时监控和管理Yarn集群中的任务,并及时采取必要的措施来优化性能、发现问题和确保任务的顺利执行。以下是一些常见的Yarn任务监控方法:
\1. Yarn Web UI:Yarn的Web界面是一个强大的任务监控工具。通过访问Yarn的Web UI地址,可以查看整个集群上运行的应用程序、任务的执行状态、资源分配情况等详细信息。可以通过该界面来监视任务的进度、资源使用情况和容器的状态。
img
\2. Yarn命令行界面(CLI):Yarn提供了一组命令行工具,可以用于查看和管理任务。例如:
- "yarn application -list"命令可以列出集群上正在运行的应用程序及其状态;
- "yarn application -status <application_id>"命令可获取特定应用程序的详细状态信息;
- "yarn logs -applicationId <application_id>"命令可查看应用程序日志等。
img
\3. Yarn REST API:Yarn还提供了REST API接口,允许通过发送HTTP请求来获取任务的状态和其他相关信息。可以使用HTTP客户端(如curl、Postman)向适当的API端点发送请求,并解析响应以获取任务的监控数据。
curl -X GET http://localhost:8088/ws/v1/cluster/apps/<application_id>/state
img
4.Yarn日志:Yarn会记录任务执行过程中的日志信息。可以通过查看任务的日志文件,了解任务的执行情况、事件发生时间和错误信息等。任务日志会记录在每个NodeManager上,并在任务完成后上传到HDFS上的指定目录中。
#查看hdfs上的日志文件
hdfs dfs -get /tmp/logs/$username/logs/application_xxx
#nm本地日志文件
#1.登录到运行YARN作业的主节点(namenode)
#2.打开 Hadoop配置文件 yarn-site.xml,并找到以下属性:yarn.nodemanager.log-dirs,指示NodeManager在本地的存储路径
img
img
2.3. yarn容错机制
当任务出现错误或容器出现故障时,错误处理和容错配置可以帮助应用程序更好地处理错误和异常情况,保证任务的正常执行。针对任务或容器出现错误或异常情况时,可通过以下的错误处理和容错配置来实现:
- 容器级别的错误处理和容错配置:容器级别的错误处理和容错配置主要包括容器的重启次数、重启的时间间隔和日志的输出等方面。通过配置容器的重试次数和时间间隔等参数,可以实现容器故障自动重启和容错处理。同时,通过集成容器的日志内容,可以了解到容器在执行过程中的详细情况,便于出现异常时定位和解决问题。
- 应用程序级别的错误处理和容错配置:应用程序级别的错误处理和容错配置主要包括单个任务的执行错误处理、多个任务的执行错误容忍、多个任务的执行顺序控制等。通过这些配置,可以使应用程序在多个任务并行执行时,自动容错并协调任务的执行顺序,从而合理利用资源和提高任务执行效率。
需要注意的是,在进行错误处理和容错配置时,应仔细分析异常和故障的原因和频率,以合理地设置重试次数和时间间隔等参数,并确保日志输出方式和日志分析方法的正确性和有效性。
适当地进行错误处理和容错配置,可以有效地解决任务执行过程中出现的异常和位置问题,提高任务执行效率和可靠性。
3. 资源管理
3.1. 节点管理和资源分配
- 节点注册和心跳机制
- NodeManager在启动时向资源管理器(ResourceManager)注册自己,并定期发送心跳以保持与资源管理器的通信。
- 心跳包含节点状态、可用资源和运行容器等信息,帮助资源管理器进行节点健康监测和资源调度。
- 资源容量计算和分配
- 资源管理器根据每个节点注册的资源信息,计算出整个集群的总资源容量。
- 在分配资源给应用程序之前,资源管理器会考虑已分配的资源、队列配置和其他策略,进行资源分配决策。
- 节点黑名单管理
- Yarn提供了黑名单机制来解决节点故障或不可靠节点的问题。
- 当节点出现故障或无法达到预期性能时,可以添加节点到黑名单,资源管理器将不再向其分配任务,以避免任务失败或延迟。
3.2. 资源隔离和限制
- CPU资源管理
- YARN使用CPU资源管理来控制和分配集群中的处理器资源。
- 它通过预先设置的CPU配额或优先级来限制每个应用程序或任务可以使用的CPU核心数量。
- 资源调度器会根据预定义的调度策略和调度规则将CPU资源分配给不同的应用程序,确保公平和合理的资源分配。
- 内存资源管理
- YARN采用内存资源管理机制,以控制和分配集群中的内存资源。
- 它使用内存配额和限制来确保每个应用程序或任务能够获得足够的内存,并避免超出分配的内存限制。
- ResourceManager会跟踪可用的内存资源,并根据应用程序的需求进行内存分配。此外,动态内存调整功能使应用程序能够根据需要增加或释放内存资源。
- 网络和磁盘资源管理
- YARN还提供了网络资源管理和磁盘资源管理的机制,以确保应用程序可靠地访问网络和磁盘资源。
- 网络资源管理涉及网络带宽的配额和分配,以避免应用程序之间的网络拥塞和竞争。
- 磁盘资源管理关注应用程序对磁盘I/O的访问。YARN可以限制每个应用程序或任务可以使用的磁盘空间,并防止它们相互干扰。
通过这些资源隔离和限制的措施,YARN能够在集群中有效地管理和分配CPU、内存、网络和磁盘等资源。这使得不同的应用程序能够并行地运行在同一个集群上,而不会相互干扰或抢占资源,从而提高了整体的资源利用率和系统的稳定性。
3.3. 资源调度器
目前,Hadoop作业调度器主要有三种:FIFO、容量(Capacity Scheduler)和公平(Fair Scheduler)。Apache Hadoop 默认的资源调度器是Capacity Scheduler。CDH框架默认调度器是Fair Scheduler。
3.3.1. 先进先出调度器(FIFO)
先进先出:单队列,根据提交作业的先后顺序,先来先服务。同一时间队列中只有一个任务在执行。
img
优点:简单易懂;
缺点:不支持多队列,生产环境很少使用
3.3.2. 容量调度器(Capacity Scheduler)
多队列:每个队列内部先进先出, 同一时间队列中只有一个任务在执行, 队列的并行度为队列的个数。
img
容量调度器支持多个队列,每个队列可配置一定的资源量,每个队列采用FIFO调度策略;
支持多用户共享集群和多应用程序同时运行。为了防止同一个用户的作业独占队列中的资源,该调度器会对同一用户提交的作业所占资源进行限定:
- 首先,计算每个队列中正在运行的任务数与其应该分得的计算资源之间的比值,选择一个该比值最小的队列(即最闲的);
- 其次,按照作业优先级和提交时间的顺序,同时考虑用户资源量限制和内存限制对队列内任务排序。
如上图,三个队列同时按照任务的先后顺序依次执行,比如:job11,job21和job31分别排在队列最前面,先运行,也是并行运行。
3.3.3. 公平调度器(Fair Scheduler)
多队列:每个队列内部按照缺额大小分配资源启动任务,同一时间队列中有多个任务执行。队列的并行度大于等于队列的个数
img
- 与容量调度器相同点
- 多队列:支持多队列多作业
- 容量保证:管理员可为每个队列设置资源最低保证和资源使用上线
- 灵活性:如果一个队列中的资源有剩余,可以暂时共享给那些需要资源的队列,而一旦该队列有新的应用程序提交,则其他队列借调的资源会归还给该队列。
- 多租户:支持多用户共享集群和多应用程序同时运行;为了防止同一个用户的作业独占队列中的资源,该调度器会对同一用户提交的作业所占资源量进行限定。
\2. 与容量调度器不同点
- 核心调度策略不同
- 容量调度器:优先选择资源利用率低的队列
- 公平调度器:优先选择对资源的缺额比例大的
- 每个队列可以单独设置资源分配方式
- 容量调度器:FIFO、 DRF
- 公平调度器:FIFO、FAIR、DRF
公平调度器设计目标是:在时间尺度上,所有作业获得公平的资源。某一时刻一个作业应获资源和实际获取资源的差距叫“缺额” 。调度器会优先为缺额大的作业分配资源 。
3.3.3.1. 公平调度器队列资源分配方式
1)FIFO策略
公平调度器每个队列资源分配策略如果选择FIFO的话,此时公平调度器相当于上面讲过的容量调度器。
2)Fair策略
Fair 策略(默认)是一种基于最大最小公平算法实现的资源多路复用方式,默认情况下,每个队列内部采用该方式分配资源。这意味着,如果一个队列中有两个应用程序同时运行,则每个应用程序可得到1/2的资源;如果三个应用程序同时运行,则每个应用程序可得到1/3的资源。
3)DRF策略
DRF(Dominant Resource Fairness),我们之前说的资源,都是单一标准,例如只考虑内存(也是Yarn默认的情况)。但是很多时候我们资源有很多种,例如内存,CPU,网络带宽等,这样我们很难衡量两个应用应该分配的资源比例。
那么在YARN中,我们用DRF来决定如何调度:假设集群一共有100 CPU和10T 内存,而应用A需要(2 CPU, 300GB),应用B需要(6 CPU,100GB)。则两个应用分别需要A(2%CPU, 3%内存)和B(6%CPU, 1%内存)的资源,这就意味着A是内存主导的, B是CPU主导的,针对这种情况,我们可以选择DRF策略对不同应用进行不同资源(CPU和内存)的一个不同比例的限制。
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!-- https://community.cloudera.com/t5/Support-Questions/Unable-to-start-Node-Manager/td-p/285976 -->
<!-- TODO 这个只是我从好未来集群上抄的配置 实际配置QQ还没给我 -->
<allocations>
<queue name="root">
<weight>1.0</weight>
<schedulingPolicy>drf</schedulingPolicy>
<queue name="default">
<weight>1.0</weight>
<schedulingPolicy>drf</schedulingPolicy>
</queue>
<queue name="users" type="parent">
<weight>1.0</weight>
<schedulingPolicy>drf</schedulingPolicy>
<queue name="dr_dot_who" type="parent">
<maxRunningApps>0</maxRunningApps>
<weight>1.0</weight>
<schedulingPolicy>drf</schedulingPolicy>
</queue>
</queue>
</queue>
<defaultQueueSchedulingPolicy>fair</defaultQueueSchedulingPolicy>
<queuePlacementPolicy>
<rule name="specified" create="true"/>
<rule name="nestedUserQueue">
<rule name="default" create="true" queue="users"/>
</rule>
<rule name="default"/>
</queuePlacementPolicy>
</allocations>
#当一个应用程序提交时,它将首先被匹配到specified规则,如果没有匹配的则被路由到nestedUserQueue规则,再没有匹配的则被放置到default规则对应的队列
img
3.3.3.2. 配置资源使用限制
场景:在使用hdfsimporter导入数据时、distcp迁移hdfs数据时或者执行数据去重、删除等操作,为了避免资源争抢,影响数据导入性能,可以通过配置调度策略,为指定队列、应用或用户设置适当的资源限制和配额,确保我们的数据导入的作业优先获得资源。
#限制运行在"users"队列下 Application-Name 为 "HdfsImporter-*" 的程序资源使用上限
<allocations>
<queue name="root">
<weight>1.0</weight>
<schedulingPolicy>drf</schedulingPolicy>
<queue name="default">
<weight>1.0</weight>
<schedulingPolicy>drf</schedulingPolicy>
</queue>
<queue name="users" type="parent">
<weight>1.0</weight>
<schedulingPolicy>drf</schedulingPolicy>
<!-- 添加以下配置 -->
<rule name="HdfsImporterLimit">
<applicationName>HdfsImporter-*</applicationName>
<maxResources>2048mb,2vcores</maxResources>
</rule>
<queue name="dr_dot_who" type="parent">
<maxRunningApps>0</maxRunningApps>
<weight>1.0</weight>
<schedulingPolicy>drf</schedulingPolicy>
</queue>
</queue>
</queue>
<defaultQueueSchedulingPolicy>fair</defaultQueueSchedulingPolicy>
<queuePlacementPolicy>
<rule name="specified" create="true"/>
<rule name="nestedUserQueue">
<rule name="default" create="true" queue="users"/>
</rule>
<rule name="default"/>
</queuePlacementPolicy>
</allocations>
#限制运行在"users"队列下的Flink应用程序的资源使用
<allocations>
<queue name="root">
<weight>1.0</weight>
<schedulingPolicy>drf</schedulingPolicy>
<queue name="default">
<weight>1.0</weight>
<schedulingPolicy>drf</schedulingPolicy>
</queue>
<queue name="users" type="parent">
<weight>1.0</weight>
<schedulingPolicy>drf</schedulingPolicy>
<!-- 添加以下配置 -->
<rule name="FlinkLimit">
<type name="flink">
<maxResources>8192mb,8vcores</maxResources>
</type>
</rule>
<queue name="dr_dot_who" type="parent">
<maxRunningApps>0</maxRunningApps>
<weight>1.0</weight>
<schedulingPolicy>drf</schedulingPolicy>
</queue>
</queue>
</queue>
<defaultQueueSchedulingPolicy>fair</defaultQueueSchedulingPolicy>
<queuePlacementPolicy>
<rule name="specified" create="true"/>
<rule name="nestedUserQueue">
<rule name="default" create="true" queue="users"/>
</rule>
<rule name="default"/>
</queuePlacementPolicy>
</allocations>
#限定 用户名为 "HdfsUser" 的用户最大资源分配
<allocations>
<queue name="root">
<weight>1.0</weight>
<schedulingPolicy>drf</schedulingPolicy>
<queue name="default">
<weight>1.0</weight>
<schedulingPolicy>drf</schedulingPolicy>
</queue>
<queue name="users" type="parent">
<weight>1.0</weight>
<schedulingPolicy>drf</schedulingPolicy>
<!-- 添加以下配置 -->
<rule name="HdfsUserLimit">
<username>HdfsUser</username>
<maxResources>3096mb,3vcores</maxResources>
</rule>
<queue name="dr_dot_who" type="parent">
<maxRunningApps>0</maxRunningApps>
<weight>1.0</weight>
<schedulingPolicy>drf</schedulingPolicy>
</queue>
</queue>
</queue>
<defaultQueueSchedulingPolicy>fair</defaultQueueSchedulingPolicy>
<queuePlacementPolicy>
<rule name="specified" create="true"/>
<rule name="nestedUserQueue">
<rule name="default" create="true" queue="users"/>
</rule>
<rule name="default"/>
</queuePlacementPolicy>
</allocations>
4. Yarn常用命令
Yarn状态的查询,除了可以在yarn web页面查看外,还可以通过命令操作。常见的命令操作如下
4.1.1. yarn application查看任务
#列出所有Application
yarn application -list
#根据Application状态过滤
yarn application -list -appStates (所有状态:ALL、NEW、NEW_SAVING、SUBMITTED、ACCEPTED、RUNNING、FINISHED、FAILED、KILLED)
例:yarn application -list -appStates FINISHED
#Kill掉 指定Application
yarn application -kill application_1612577921195_0001
4.1.2. yarn logs查看日志
#查询Application日志
yarn logs -applicationId <ApplicationId>
#查询Container日志
yarn logs -applicationId <ApplicationId> -containerId <ContainerId>
例:yarn logs -applicationId application_1612577921195_0001 -containerId container_1612577921195_0001_01_000001
4.1.3. yarn applicationattempt查看尝试运行的任务
#列出所有Application尝试的列表
yarn applicationattempt -list <ApplicationId>
#打印ApplicationAttemp状态
yarn applicationattempt -status <ApplicationAttemptId>
4.1.4. yarn container查看容器
#列出所有Container
yarn container -list <ApplicationAttemptId>
#打印Container状态:yarn container -status <ContainerId>
#注:只有在任务跑的途中才能看到container的状态
4.1.5. yarn node查看节点状态
#列出所有节点
yarn node -list -all
#列出节点资源使用情况
yarn node -list -showDetails
4.1.6. yarn rmadmin更新配置
#加载队列配置
yarn rmadmin -refreshQueues
4.1.7. yarn queue查看队列
#查看YARN队列的列表
#hadoop2.x
yarn queue -list
#hadoop3.x
mapred queue -list
#打印队列信息
yarn queue -status <QueueName>
5. 问题排查
5.1. 排查思路
当遇到 yarn 任务运行异常情况时,不同的任务状态可能需要采取不同的排查方法。下面是针对不同状态的一些常见排查方法:
- 任务提交失败(Submission Failure):
- 检查网络连接:确保与 YARN 集群的网络连接正常。尝试 ping 集群主机以验证连接是否通畅。
- 检查配置文件:检查任务的配置文件是否正确设置,在提交任务之前,特别是检查集群和队列的配置。
- 任务启动失败(Job Initialization Failure):
- 检查输入/输出路径:确保任务所需的输入/输出路径存在且权限正确。
- 检查日志:查看任务的日志输出,尤其是初始化阶段的错误日志。
- 检查资源配额:确认任务所需的资源配额是否可用。可能需要增加任务的资源配额。
- 任务运行失败(Job Execution Failure):
- 检查任务日志:仔细查看日志,寻找具体的错误信息和异常堆栈跟踪。
- 检查依赖项:确认任务所需的依赖项已正确安装,并且版本匹配。
- 检查资源限制:确保集群资源足够满足任务的需求。可能需要增加资源配额或更换较大的集群。
- 任务超时(Job Timeout):
- 检查任务复杂性:确保任务的运行时间不超过了集群的限制。尝试优化任务以减少其运行时间。
- 检查资源配置:确认任务所需的资源配置是否合理,可能需要调整资源分配。
- 检查网络延迟:排查集群与外部系统之间的网络延迟是否超过了任务的超时设置。
- 任务被杀死(Job Killed):
- 检查资源限制:确认任务所需的资源配额是否超过了集群的限制。尝试增加资源配额或更换较大的集群。
- 检查任务优先级:确保任务的优先级适当,以便在集群资源紧张时能够得到足够的资源支持。
- 检查管理员操作:确定是否有管理员手动终止了任务。联系管理员以获取更多信息。
总之,在排查 yarn 任务异常情况时,首先关注任务的状态和错误日志,根据具体情况采取相应的排查方法。调试和日志记录是解决问题的重要手段,同时需要注意集群配置和资源限制等因素。如果问题仍然存在,寻求相关技术支持或社区的帮助可能也是一个好的选择。