汪健

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

關鍵詞：Hadoop YARN；資源請求與分配；時間因素

中圖分類號：TP3 文獻標識碼：A 文章編號：1009-3044（2016）17-0272-03

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

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

1 YARN資源管理平臺簡述

RM（ResourceManager）是YARN中的核心模塊，負責整個集群所有資源的統一管理和分配；集群中每個提供資源服務的結點由其內部的NM（NodeManager）進行管理； NM中的資源以Container的形式進行分配，每個Container封裝了一定的資源量。

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

NM用心跳機制定期向RM匯報結點信息以及Container信息。

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

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

2.1 擴展ResourceRequest

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

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

2）ApplicationMasterService調用ResourceScheduler.allocate（）函數，將資源需求匯報給ResouceScheduler。

3）ResourceScheduler根據調度策略分配資源，并以Container形式更新到相應的數據結構中。現有調度只能在收到資源請求時立即分配，增加了時間因素后，可在將來的某個時間才進行資源分配。

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

圖1 ApplicationMaster申請資源流程

2.2 時間需求格式

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

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

1）DemandID：

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

2）Start： {， ， …}

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

3）Duration： {， ， …}

資源已分配后，預計占用時間。該字段便于RM掌握資源的預期使用時長，從而合理進行調度。

4）DeadLine： {， ， …}

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

5）OrderBy： < DemandID expression>

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

每個字段對應的值對象可包含多個內容，常用的內容為：

1）

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

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

2）

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

3）邏輯運算

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

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

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

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

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

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

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

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

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

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

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

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

3 小結

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

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

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

參考文獻：

[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