淺談yarn的任務管理與資源管理(yarn任務運行的幾種狀態)
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的客戶端,用于管理當前任務的調度。
-
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創建應用程序,為它申請資源,并監控它的整個運行過程,直到運行完成,如下圖所示。
(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應用歷史中。
示例:
-
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地址,可以查看整個集群上運行的應用程序、任務的執行狀態、資源分配情況等詳細信息??梢酝ㄟ^該界面來監視任務的進度、資源使用情況和容器的狀態。
2. Yarn命令行界面(CLI):Yarn提供了一組命令行工具,可以用于查看和管理任務。例如:
-
“yarn application -list”命令可以列出集群上正在運行的應用程序及其狀態;
“yarn application -status <application_id>”命令可獲取特定應用程序的詳細狀態信息;
“yarn logs -applicationId <application_id>”命令可查看應用程序日志等。
3. Yarn REST API:Yarn還提供了REST API接口,允許通過發送HTTP請求來獲取任務的狀態和其他相關信息??梢允褂肏TTP客戶端(如curl、Postman)向適當的API端點發送請求,并解析響應以獲取任務的監控數據。
curl -X GET http://localhost:8088/ws/v1/cluster/apps/<application_id>/state
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在本地的存儲路徑
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)
先進先出:單隊列,根據提交作業的先后順序,先來先服務。同一時間隊列中只有一個任務在執行。
優點:簡單易懂;
缺點:不支持多隊列,生產環境很少使用
3.3.2. 容量調度器(Capacity Scheduler)
多隊列:每個隊列內部先進先出, 同一時間隊列中只有一個任務在執行, 隊列的并行度為隊列的個數。
容量調度器支持多個隊列,每個隊列可配置一定的資源量,每個隊列采用FIFO調度策略;
支持多用戶共享集群和多應用程序同時運行。為了防止同一個用戶的作業獨占隊列中的資源,該調度器會對同一用戶提交的作業所占資源進行限定:
-
首先,計算每個隊列中正在運行的任務數與其應該分得的計算資源之間的比值,選擇一個該比值最小的隊列(即最閑的);
其次,按照作業優先級和提交時間的順序,同時考慮用戶資源量限制和內存限制對隊列內任務排序。
如上圖,三個隊列同時按照任務的先后順序依次執行,比如:job11,job21和job31分別排在隊列最前面,先運行,也是并行運行。
3.3.3. 公平調度器(Fair Scheduler)
多隊列:每個隊列內部按照缺額大小分配資源啟動任務,同一時間隊列中有多個任務執行。隊列的并行度大于等于隊列的個數
-
與容量調度器相同點
-
多隊列:支持多隊列多作業
容量保證:管理員可為每個隊列設置資源最低保證和資源使用上線
靈活性:如果一個隊列中的資源有剩余,可以暫時共享給那些需要資源的隊列,而一旦該隊列有新的應用程序提交,則其他隊列借調的資源會歸還給該隊列。
多租戶:支持多用戶共享集群和多應用程序同時運行;為了防止同一個用戶的作業獨占隊列中的資源,該調度器會對同一用戶提交的作業所占資源量進行限定。
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規則對應的隊列
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 任務運行異常情況時,不同的任務狀態可能需要采取不同的排查方法。下面是針對不同狀態的一些常見排查方法:
-
任務提交失?。⊿ubmission Failure):
-
檢查網絡連接:確保與 YARN 集群的網絡連接正常。嘗試 ping 集群主機以驗證連接是否通暢。
檢查配置文件:檢查任務的配置文件是否正確設置,在提交任務之前,特別是檢查集群和隊列的配置。
任務啟動失?。↗ob Initialization Failure):
-
檢查輸入/輸出路徑:確保任務所需的輸入/輸出路徑存在且權限正確。
檢查日志:查看任務的日志輸出,尤其是初始化階段的錯誤日志。
檢查資源配額:確認任務所需的資源配額是否可用??赡苄枰黾尤蝿盏馁Y源配額。
任務運行失敗(Job Execution Failure):
-
檢查任務日志:仔細查看日志,尋找具體的錯誤信息和異常堆棧跟蹤。
檢查依賴項:確認任務所需的依賴項已正確安裝,并且版本匹配。
檢查資源限制:確保集群資源足夠滿足任務的需求。可能需要增加資源配額或更換較大的集群。
任務超時(Job Timeout):
-
檢查任務復雜性:確保任務的運行時間不超過了集群的限制。嘗試優化任務以減少其運行時間。
檢查資源配置:確認任務所需的資源配置是否合理,可能需要調整資源分配。
檢查網絡延遲:排查集群與外部系統之間的網絡延遲是否超過了任務的超時設置。
任務被殺死(Job Killed):
-
檢查資源限制:確認任務所需的資源配額是否超過了集群的限制。嘗試增加資源配額或更換較大的集群。
檢查任務優先級:確保任務的優先級適當,以便在集群資源緊張時能夠得到足夠的資源支持。
檢查管理員操作:確定是否有管理員手動終止了任務。聯系管理員以獲取更多信息。
總之,在排查 yarn 任務異常情況時,首先關注任務的狀態和錯誤日志,根據具體情況采取相應的排查方法。調試和日志記錄是解決問題的重要手段,同時需要注意集群配置和資源限制等因素。如果問題仍然存在,尋求相關技術支持或社區的幫助可能也是一個好的選擇。