YARN資源分配引入時間因素的研究

汪健

摘要：Hadoop2使用YARN平臺進(jìn)行資源管理，支持更多的計算框架和可插拔的資源調(diào)度器?，F(xiàn)有的資源調(diào)度機(jī)制中并不支持時間因素，而新的應(yīng)用方向需要YARN對預(yù)分配、實時性、截止期限等與時間密切相關(guān)的資源調(diào)度提供支持。本文對YARN進(jìn)行擴(kuò)展，以支持各種與時間相關(guān)的調(diào)度策略。

關(guān)鍵詞：Hadoop YARN；資源請求與分配；時間因素

中圖分類號：TP3 文獻(xiàn)標(biāo)識碼：A 文章編號：1009-3044（2016）17-0272-03

作為Apache頂級項目之一，Hadoop可以使數(shù)據(jù)分析工作分布在成千上萬臺普通計算機(jī)組成的集群上同時運(yùn)行，同時具備良好的擴(kuò)展性和容錯性。隨著信息技術(shù)越來越廣泛的使用，人們需要處理的數(shù)據(jù)量呈爆發(fā)式增長，為充分利用Hadoop集群處理能力，集群中的資源分配是一個關(guān)鍵環(huán)節(jié)。Hadoop從 2.0版本開始使用YARN通用資源管理平臺，從而使得資源管理工作從MapReduce v1計算框架中分離出來，并支持Storm、Spark等其他計算框架在其上運(yùn)行。

YARN中目前集成了Capacity Scheduler和Fair Scheduler兩種資源調(diào)度器，支持在多用戶、多任務(wù)環(huán)境下平衡資源分配，達(dá)到共享Hadoop集群的目的，并提供了諸如優(yōu)先級、標(biāo)簽管理等措施來幫助集群資源的管理。然而，YARN中現(xiàn)有的調(diào)度幾乎沒有考慮時間，而在實際的資源調(diào)度需求中，時間也是一個重要的因素，特別是在支持資源預(yù)留的調(diào)度中。文獻(xiàn)[1]指出基于資源預(yù)留的調(diào)度對集群的利用率幾乎可達(dá)到100%，而Capacity Scheduler不超過80%；文獻(xiàn)[2，3]基于Hadoop來實現(xiàn)高實時需求的軟件系統(tǒng)；基于截止時間的調(diào)度策略[4]和可同時啟動多個Container的Gang調(diào)度策略[5]也在研究中。因此，需要擴(kuò)充YARN現(xiàn)有資源請求和調(diào)度框架，增加時間因素，各種調(diào)度策略從其中獲得資源和時間需求并進(jìn)行資源調(diào)度，從而彈性地滿足作業(yè)對時間上的需求和更充分地利用資源。本文通過對YARN中的資源調(diào)度環(huán)節(jié)進(jìn)行分析研究，定義了可自定義的時間標(biāo)記定義，擴(kuò)充了現(xiàn)有的資源請求方式，從而將時間因素與現(xiàn)有的資源分配結(jié)合起來。

1 YARN資源管理平臺簡述

RM（ResourceManager）是YARN中的核心模塊，負(fù)責(zé)整個集群所有資源的統(tǒng)一管理和分配；集群中每個提供資源服務(wù)的結(jié)點由其內(nèi)部的NM（NodeManager）進(jìn)行管理； NM中的資源以Container的形式進(jìn)行分配，每個Container封裝了一定的資源量。

客戶端可以向RM提交作業(yè)（Job），每個作業(yè)將被分為多個子任務(wù)（Task），并分布到Hadoop集群中的多個結(jié)點并行地運(yùn)算。作業(yè)提交到RM后不會馬上被運(yùn)行，而是由RM先分配一個合適的Container，以容納該作業(yè)的AM（ApplicationMaster）。AM是該作業(yè)申請資源及內(nèi)部管理的必要部件。AM向RM注冊成功后，便可持續(xù)地申請資源來運(yùn)行子任務(wù)。RM通過內(nèi)部的調(diào)度機(jī)制為請求分配資源，AM通過周期性的心跳來獲取這些以Container形式表示的資源。AM得到Container后，與Container所在的NM通信以真正獲得資源，并在Container中運(yùn)行子任務(wù)。

NM用心跳機(jī)制定期向RM匯報結(jié)點信息以及Container信息。

2 資源分配中引入時間因素

Hadoop集群在實際應(yīng)用中，由于其上運(yùn)行的作業(yè)不同，數(shù)據(jù)的多樣性，集群本身的異構(gòu)性等，從而對資源分配有不同的需求，進(jìn)而產(chǎn)生各種調(diào)度策略。這里我們并不對具體調(diào)度策略做討論，僅關(guān)注如何在申請資源時引入時間因素。

2.1 擴(kuò)展ResourceRequest

AM申請資源時，用ResourceRequest對象描述所需資源。為引入時間因素，我們擴(kuò)展現(xiàn)有的資源請求環(huán)節(jié)，采用新的ResourceDescription類封裝原有的ResourceRequst，并在類中引入對時間需求的描述。增加時間因素并不會改變YARN的原有流程，僅是對其中的操作有部分?jǐn)U展。資源申請流程分析如下（圖1）：

1）AM通過RPC函數(shù)與RM中的ApplicationMasterService通信，并傳遞ResouceDescription對象，該對象中包含了原有的ResourceRequest對象，并增加了時間或其他資源相關(guān)條件。由于該通信是周期性調(diào)用，因此也稱為心跳。

2）ApplicationMasterService調(diào)用ResourceScheduler.allocate（）函數(shù)，將資源需求匯報給ResouceScheduler。

3）ResourceScheduler根據(jù)調(diào)度策略分配資源，并以Container形式更新到相應(yīng)的數(shù)據(jù)結(jié)構(gòu)中?，F(xiàn)有調(diào)度只能在收到資源請求時立即分配，增加了時間因素后，可在將來的某個時間才進(jìn)行資源分配。

4）每次心跳會返回AllocateResponse應(yīng)答對象，包含分配的Container及集群規(guī)模等信息，AM獲取信息后與對應(yīng)的NM通信以真正啟動Container并運(yùn)行子任務(wù)。

圖1 ApplicationMaster申請資源流程

2.2 時間需求格式

在分配和占用資源時，可能涉及的時間需求可能包含起始時間、截止時間、占用時長等等。在具體實現(xiàn)中，如果用對象來傳遞各種時間條件，那么當(dāng)時間條件需求發(fā)生任何變化，都需要修改對象類型，且難以滿足復(fù)雜的條件組合例如與、并、非邏輯。因此在傳遞時間條件時，采用獨立于語言平臺的JSON格式數(shù)據(jù)以避免上述的缺陷。通信雙方可通過預(yù)定義字段和取值類型，并相應(yīng)實現(xiàn)解釋器，從而達(dá)到交換數(shù)據(jù)的目的。

在支持時間條件的資源分配機(jī)制中，可能的字段及解釋如下：

1）DemandID：

客戶端向RM發(fā)送資源請求時生成的流水號。在引入時間條件后，該流水號對應(yīng)的資源可能在將來某時刻被分配。

2）Start： {， ， …}

資源分配時間。代表客戶端希望在此時間得到所請求的資源，若RM接受此請求，應(yīng)在此時間之前就預(yù)留足夠的資源。

3）Duration： {， ， …}

資源已分配后，預(yù)計占用時間。該字段便于RM掌握資源的預(yù)期使用時長，從而合理進(jìn)行調(diào)度。

4）DeadLine： {， ， …}

資源上的任務(wù)截止完成期限。該字段可用于實時性要求較高的作業(yè)，RM可選擇能夠滿足截止期限的結(jié)點來運(yùn)行該任務(wù)。

5）OrderBy： < DemandID expression>

次序字段隱性地與時間相關(guān)。這里并不指定具體時間，而是指本次資源請求是在其他資源上的任務(wù)完成之后進(jìn)行分配，非常適合于類似Oozie[6]的工作流任務(wù)的資源預(yù)分配。

每個字段對應(yīng)的值對象可包含多個內(nèi)容，常用的內(nèi)容為：

1）

時間表達(dá)式格式為Time： [T1， T2]。當(dāng)T1、T2均有明確指定時，代表一段時間間隔；當(dāng)T1未指定而T2指定時，表示到T2截止；當(dāng)T2未指定而T1指定時，表示從T1開始；當(dāng)T1、T2均未指定時，表示不對時間做任何要求，從而兼容現(xiàn)有的無時間條件調(diào)度機(jī)制。

T1為絕對時間，以“YY-MM-DD hh：mm：ss”表示，并支持特定標(biāo)識，如以NOW代表當(dāng)前時間；T2可為絕對時間、相對時間或延遲調(diào)度次數(shù)，相對時間以“+數(shù)字及單位”來表示，單位可為小時h、分鐘m和秒s，延遲調(diào)度次數(shù)以“^數(shù)字”表示可放棄多次調(diào)度機(jī)會。

2）

策略表達(dá)式格式為Strategy： strict | loose。策略可取值strict表示嚴(yán)格遵從條件，或loose表示寬松遵從。例如對于資源分配，可用strict指明資源必須在指定時間分配，否則應(yīng)拒絕該請求；也可用loose指明盡量在指定時間分配資源，如未能保證，可拒絕也可延期。

3）邏輯運(yùn)算

數(shù)值中可包含邏輯運(yùn)算，即AND（與）、OR（并）、NOT（非）。例如，可以用Time： { OR： [ [NOW， +5m]， [NOW， ^3] ] }表示時間間隔為當(dāng)前時間起5分鐘內(nèi)，或是當(dāng)前時間起延遲調(diào)度次數(shù)在3次以內(nèi)。

下面是一個時間需求的例子，其請求ID為1234，所需資源在ID號為1200的子任務(wù)運(yùn)行完后分配，分配后其上的子任務(wù)盡量在20分鐘以內(nèi)完成。

2.3 資源請求狀態(tài)機(jī)

在資源分配過程中引入時間因素后，AM請求的資源并非立即返回，而將經(jīng)歷多個階段，為追蹤這些階段狀態(tài)，我們引入RMDemand狀態(tài)機(jī)，每個請求對應(yīng)一個狀態(tài)機(jī)對象，狀態(tài)之間的轉(zhuǎn)換基于事件機(jī)制。RM通過訪問狀態(tài)機(jī)列表來掌控請求對應(yīng)資源的分配情況。狀態(tài)的說明以及它們之間的轉(zhuǎn)換關(guān)系如下。

圖2 資源請求狀態(tài)轉(zhuǎn)換

1）NEW：初識狀態(tài)。當(dāng)RM接收到一個資源請求時，若請求合法（權(quán)限校驗通過、格式正確），則生成該請求對應(yīng)的RMDemand對象，并通知調(diào)度器進(jìn)行調(diào)度。

2）ACCEPTED：若調(diào)度器接受該資源請求，進(jìn)入此狀態(tài)。

3）ALLOCATING：開始實際分配資源時狀態(tài)。RM應(yīng)盡量保證在用戶指定的時刻T1可得到資源，因此在T1之前就應(yīng)通知調(diào)度器開始調(diào)度，并進(jìn)入此狀態(tài)。

4）FAILED：若調(diào)度器拒絕該資源請求，或是調(diào)度器未能按預(yù)計分配足夠的資源時，進(jìn)入此狀態(tài)。另外，除FINISHED狀態(tài)，其他狀態(tài)都可因該請求被殺死而進(jìn)入FAILED狀態(tài)，為清晰起見未畫出這些狀態(tài)的轉(zhuǎn)換。

5）ALLOCATED：資源分配完成后狀態(tài)。AM可根據(jù)請求ID，自行到RM來獲取這些資源信息（位置、實際大小等），并與相應(yīng)結(jié)點的NM通信以啟動Container。需要指出的是，若一段時間之后用戶不來取這些資源，RM可釋放這些資源并置狀態(tài)為FAILED。

6）MONITORING：若資源請求中需要對已分配的資源進(jìn)行監(jiān)控，進(jìn)入此狀態(tài)。RM可管理處于該狀態(tài)的資源請求時長、截止期限，或是資源請求的依次處理等。

7）FINISHED：結(jié)束狀態(tài)。資源分配結(jié)束、或Container上的子任務(wù)運(yùn)行完成后進(jìn)入此狀態(tài)，完成資源回收等工作。

3 小結(jié)

作業(yè)的運(yùn)行先要分配一個Container來容納AM，這個工作是由ApplicationMasterLauncher完成。仿照前述的思路，可對AM的啟動加入時間條件，以預(yù)定作業(yè)的開始時間。雖然可以通過修改客戶端接口，在提交作業(yè)時通知RM預(yù)先分配一定數(shù)量的資源來運(yùn)行子任務(wù)，但是更簡便的辦法是避免修改現(xiàn)有由AM申請資源的方式，提前一定時間啟動AM。例如要求作業(yè)在早晨3點準(zhǔn)時運(yùn)行一批子任務(wù)，那么可以預(yù)定AM提前半小時啟動，然后申請所需資源，當(dāng)然，這就需要用戶手動估算提前量。

增加時間因素后，調(diào)度器分配資源時需要更多考慮，這也是當(dāng)前的研究熱點。在我們給出的擴(kuò)展方案中，RM通過RMDemand狀態(tài)機(jī)來監(jiān)控資源分配情況，因此不需要對調(diào)度器接口作出改變。

對YARN平臺的主要改變是將原來的ResourceRequest資源對象請求擴(kuò)展為ResourceDescription對象，以及增加資源請求狀態(tài)的管理。對YARN的運(yùn)行機(jī)制沒有重大修改，可兼容現(xiàn)有調(diào)度器并支持將來的調(diào)度器。除了時間因素，ResourceDescription中也可加入其他調(diào)度因素，滿足調(diào)度器的其他特性，對未來的調(diào)度策略提供良好的支撐。

參考文獻(xiàn)：

[1] C Curino， DE Difallah， C Douglas， S Krishnan， R Ramakrishnan. Reservation-based Scheduling： If You're Late Don't Blame Us！[C]. ACM Symposium on Cloud Computing，2014.

[2] Ciprian Barbieru， Florin Pop. Soft Real-Time Hadoop Scheduler for BigData Processing in Smart Cities[C]. 2016 IEEE 30th International Conference on Advanced Information Networking and Applications（AINA）， 2016.

[3] M. Mazhar Rathore， Awais Ahmad， Anand Paul， Alfred Daniel. Hadoop based real-time Big Data Architecture for remote sensing Earth Observatory System[C]. 2015 6th International Conference on Computing， Communication and Networking Technologies （ICCCNT）， 2015.

[4] Quentin Perret， Gabriel Charlemagne， Stelios Sotiriadis， Nik Bessis. A Deadline Scheduler for Jobs in Distributed Systems[C]. Advanced Information Networking and Applications Workshops （WAINA）， 2013 27th International Conference on，2013.

[5] Support gang scheduling in the AM RM protocol [EB/OL]. https：//issues.apache.org/jira/browse/YARN-624，2015-8-12

[6] Apache Oozie Workflow Scheduler for Hadoop[EB/OL]. http：//oozie.apache.org/，2016-4-12