異構(gòu)集群節(jié)點與作業(yè)特性感知資源分配算法

胡亞紅，吳寅超，朱正東，李小軒

1.浙江工業(yè)大學 計算機學院，杭州310023

2.西安交通大學 計算機學院，西安710049

隨著大數(shù)據(jù)時代的到來，用戶產(chǎn)生的數(shù)據(jù)呈指數(shù)級增長。單一節(jié)點已經(jīng)滿足不了數(shù)據(jù)處理的需求，傳統(tǒng)的計算模型也無法滿足大數(shù)據(jù)處理的性能和效率要求，故Hadoop[1]、Spark[2]和Storm[3]等分布式框架應運而生。在這些框架中，Apache Spark由于其出色的性能和豐富的應用程序支持而成為通用且最受歡迎的大數(shù)據(jù)處理平臺。與其他的平臺相比，Spark 在性能上有著較大的優(yōu)勢，例如Spark的運行速度是MapReduce框架的數(shù)十倍[4-5]。

Spark提供了幾種部署模式，包括Local、Standalone、Spark on YARN 和Spark on Mesos 等。它的調(diào)度策略根據(jù)運行層次可以分為application scheduling、job scheduling、stage scheduling 和task scheduling 等[6]。以上的四個調(diào)度策略，除了application scheduling 是對用戶作業(yè)（也稱為應用）的調(diào)度，其余三個都是系統(tǒng)較為底層的調(diào)度。Standalone 模式中，默認的多作業(yè)任務調(diào)度方式采用FIFO 或FAIR 兩種策略，資源調(diào)度算法則有SpreadOut和非SpreadOut[7]。這兩種資源調(diào)度算法采用了非常簡單的邏輯，即通過對比作業(yè)的資源需求以及節(jié)點的可用資源來進行調(diào)度。

由于分布式系統(tǒng)的復雜性，Spark 在實際運行環(huán)境中不能充分利用集群中計算機的全部性能，因此優(yōu)化Spark 系統(tǒng)的執(zhí)行效率非常重要，其中對于資源調(diào)度機制的研究已成為當前的研究重點。分布式框架的調(diào)度算法主要分為基于用戶作業(yè)級別的調(diào)度和基于任務級別的調(diào)度?，F(xiàn)在已有許多基于Hadoop 的相關(guān)研究工作，這些為進行Spark調(diào)度優(yōu)化提供了良好的基礎。

徐佳俊等認為隨著硬件的更迭和高性能硬件的引用，集群的異構(gòu)化現(xiàn)象日趨顯著[8]?；诩和|(zhì)化假設提出的Spark原生調(diào)度策略已經(jīng)無法適應集群的異構(gòu)化，因此引入了分層調(diào)度的思想。調(diào)度算法綜合考慮了任務復雜度、節(jié)點性能及節(jié)點資源使用情況等因素，實現(xiàn)了高效公平的任務調(diào)度。這個新的Spark調(diào)度策略雖然對系統(tǒng)性能的提升效果較為明顯，但是其未考慮應用程序的類型和節(jié)點的實時處理能力的偏向性。

不同的用戶作業(yè)對于集群資源的需求差異很大。針對這一問題，Xu 等提出了一種面向大數(shù)據(jù)平臺的異構(gòu)任務調(diào)度系統(tǒng)RUPAM[9]，該調(diào)度系統(tǒng)考慮了任務級的資源特性、節(jié)點的硬件特性和數(shù)據(jù)本地性，有效提升了集群的性能。

Spark 集群的異構(gòu)性會導致集群計算資源的不均衡，而Spark 默認的調(diào)度算法在任務調(diào)度時未考慮集群的異構(gòu)性以及節(jié)點資源的利用情況，影響了系統(tǒng)性能的發(fā)揮。針對該問題，胡亞紅等利用節(jié)點的優(yōu)先級來表示其計算能力，提出節(jié)點優(yōu)先級調(diào)整算法來動態(tài)調(diào)整任務執(zhí)行過程中節(jié)點的優(yōu)先級，并提出基于節(jié)點優(yōu)先級的Spark 動態(tài)自適應調(diào)度算法，根據(jù)實時的節(jié)點優(yōu)先級完成任務的分配[10]。

楊忙忙提出了均衡-飽和度的概念以衡量程序運行時節(jié)點資源的有效利用率。該定義不僅可以量化CPU與內(nèi)存資源使用的均衡性關(guān)系，還能夠量化資源的有效利用率[11]。

丁晶晶等認為Spark的資源調(diào)度方式和資源的利用率直接關(guān)系到集群的效率。他們提出的新的調(diào)度算法通過綜合考慮工作節(jié)點資源實時利用情況、節(jié)點CPU處理速度和CPU剩余利用率等以進行資源的調(diào)度與分配，能夠滿足Spark 系統(tǒng)的高并發(fā)請求、低延遲響應，同時也減少了資源利用傾斜現(xiàn)象，提高了資源的利用率[12]。該算法考慮了集群中節(jié)點的實時資源使用情況，并根據(jù)得到的集群狀態(tài)進行資源的分配，但是未考慮異構(gòu)集群中的節(jié)點處理不同類型的用戶作業(yè)的能力不同。

為了滿足硬實時調(diào)度的需求，Wang 等提出了一種新的硬實時調(diào)度算法，稱為DVDA（deadline 和value density aware）[13]。與僅考慮截止日期的傳統(tǒng)EDF（earliest deadline first）算法相比，DVDA算法同時考慮應用的截止期限和值密度。在YARN 上實現(xiàn)的基于DVDA 的Spark調(diào)度實驗驗證了算法的有效性。該算法將用戶作業(yè)的截止日期加入到算法的評價體系，但是沒有考慮集群中節(jié)點的實時資源使用狀況。

Cheng 等提出了一種資源和期限感知的Hadoop 作業(yè)調(diào)度算法RDS[14]，該算法能夠在最小化作業(yè)期限錯失時考慮將來的資源可用性。RDS 設計了一個自學習模型來估計作業(yè)完成時間，并使用一個簡單但有效的模型來預測將來的資源可用性。

為解決電力供應受限集群中的任務調(diào)度問題，Kumbhare 等提出了基于任務價值的任務調(diào)度方法[15]。該算法首先預測出所有待執(zhí)行任務在所有可能的資源配置條件下的運行時間；之后計算每一個任務在每種資源配置條件下能夠獲得的價值。算法挑選出獲得價值最大的任務，為其提供所需的最優(yōu)集群配置，進行任務的執(zhí)行。

異構(gòu)集群中并行執(zhí)行的任務會爭用集群中的資源，從而導致集群性能的下降。Zhang 等提出的基于強化學習和神經(jīng)協(xié)同過濾的兩階段任務調(diào)度方法，通過對任務進行分割來解決上述問題。其學習驅(qū)動的負載并行化算法能夠為相互獨立的任務找到適合的運行節(jié)點[16]。

默認的Spark資源調(diào)度方法將重點聚焦于合理分配計算資源，卻未考慮網(wǎng)絡資源，這可能會使網(wǎng)絡延遲變大，降低集群性能。針對該問題，Du等提出了一種任務完成時間感知的章魚調(diào)度優(yōu)化方法OctopusKing[17]。該算法考慮了節(jié)點的異構(gòu)性、每個任務的數(shù)據(jù)量和計算復雜度以及網(wǎng)絡傳輸?shù)人膫€影響因素，采用深度學習方法來預測任務完成時間，較為有效地減小了任務的運行時間并提高了集群資源利用率。

異構(gòu)集群中影響數(shù)據(jù)本地性的不僅僅是網(wǎng)絡帶寬，另一重要影響因素是存儲設備的差異，如選用的是固態(tài)硬盤還是機械硬盤。忽略存儲設備讀寫速度的差異，會導致高速存儲設備的利用率低下，進而影響集群整體性能。因此，Pan等提出了一種基于異構(gòu)存儲集群的任務調(diào)度策略H-Scheduler[18]。該策略可以根據(jù)存儲類型區(qū)分存儲設備的速度，同時結(jié)合數(shù)據(jù)位置和存儲類型來對任務進行優(yōu)先級的排列，以減少作業(yè)執(zhí)行時間。該調(diào)度策略考慮了存儲設備速度的異構(gòu)性問題，但未考慮影響節(jié)點性能的其他因素。

對于數(shù)據(jù)密集型任務，數(shù)據(jù)加載成本是影響任務完成時間的最主要因素。緩存中的數(shù)據(jù)有助于提高任務執(zhí)行效率，因此需要最小化緩存未命中率。針對該問題，Meng 等提出了一種貪婪在線調(diào)度算法[19]。該算法綜合考慮了負載平衡、數(shù)據(jù)相關(guān)性和數(shù)據(jù)本地性，解決了數(shù)據(jù)密集型任務的并行調(diào)度問題。但是它只考慮了數(shù)據(jù)密集型負載，對于其他類型的負載未加考慮。

現(xiàn)有的資源調(diào)度算法在給作業(yè)分配集群資源的時候沒有同時考慮作業(yè)的類型（任務偏向）以及節(jié)點的處理能力（性能偏向），雖利用了具有可用資源的節(jié)點，但在多作業(yè)運行的時候，會造成一些節(jié)點在運行其不擅長類型的作業(yè)，導致系統(tǒng)較低的執(zhí)行效率。為了解決上述問題，本文提出了用戶作業(yè)類型及節(jié)點性能偏向感知的資源調(diào)度算法ATNPA（application type and node preference-aware scheduling）來進行用戶作業(yè)層次的資源調(diào)度。在用戶提交作業(yè)之后，該調(diào)度算法判斷應用程序的類型并結(jié)合節(jié)點的實時處理性能來進行準確、高效的資源調(diào)度。

1 Spark主要運行模式及流程

Spark大數(shù)據(jù)框架采用了分布式計算的Master/Slave模型，其中Master 作為整個集群的控制端，主要負責Spark 的正常進行、應用管理與資源管理；Slave 的主要職責是接收Master的命令并進行用戶作業(yè)的執(zhí)行。

Spark框架中有兩個核心的組件，即Driver和Worker。Driver是任務的調(diào)度器也是程序執(zhí)行的入口，Worker是任務的實際執(zhí)行者。在負載被提交到Spark 時，Driver首先將代碼分發(fā)到各個Worker 節(jié)點，然后Worker 節(jié)點上的Executor工作進程對相應分區(qū)的數(shù)據(jù)進行處理，當處理完成后將結(jié)果返回給Driver進程。

目前，Spark的幾種主要運行模式及其特點如下：

（1）local：主要用于開發(fā)調(diào)試Spark應用程序。

（2）Standalone：即獨立模式，自帶完整的服務，采用Master/Slave 結(jié)構(gòu)，無需依賴其他的資源管理系統(tǒng)。為解決單點故障，可以采用Zookeeper實現(xiàn)高可靠性。

（3）Apache Mesos：運行在著名的Mesos 資源管理框架基礎之上，該集群運行模式將資源管理交給Mesos，Spark只負責運行任務調(diào)度和計算。

（4）Hadoop YARN：集群運行在YARN 資源管理器上，YARN完成資源管理，Spark只負責進行任務調(diào)度和計算。

本文旨在優(yōu)化Spark 集群的資源調(diào)度算法，因此選用了Standalone 模式。Standalone 模式下Spark 的運行流程如圖1所示。

圖1 Spark Standalone模式Fig.1 Operating mode of Spark Standalone

2 用戶作業(yè)類型和節(jié)點性能偏向性感知的資源調(diào)度算法ATNPA

將用戶作業(yè)匹配到最適合其特點的節(jié)點，能夠充分發(fā)揮節(jié)點的性能，有效縮短作業(yè)的執(zhí)行時間，提高節(jié)點吞吐量。下面分別定義用戶作業(yè)類型和節(jié)點性能偏向性。

2.1 用戶作業(yè)類型

現(xiàn)實應用場景中可以根據(jù)用戶作業(yè)對計算資源的需求確定其類型。目前，運用較為廣泛的用戶作業(yè)類型有CPU密集型、內(nèi)存密集型、I/O密集型和網(wǎng)絡密集型等等。不同種類的用戶作業(yè)對于集群資源的需求不同。用戶在提交作業(yè)的時候，一般需要指定該作業(yè)運行所需的資源，如需要的CPU 核數(shù)、內(nèi)存等。在Spark 默認的配置下，每個用戶作業(yè)需要開啟若干個Executor以滿足其資源需求以及運行的并行度，從而提升作業(yè)執(zhí)行效率。Spark默認每個Executor包含1個CPU核和1 GB內(nèi)存[6]。

從用戶作業(yè)層面上看，作業(yè)的類型是用戶作業(yè)的固有屬性。本文引入UAT（user application type）表示作業(yè)類型。

定義1 用戶作業(yè)類型（UAT）

requiredMemory是作業(yè)運行所需的內(nèi)存資源，requiredCores是作業(yè)運行所需要的CPU 核數(shù)，這兩個參數(shù)由用戶指定。UAT 閾值的選取對于判斷用戶作業(yè)的類型至關(guān)重要。使用不同的UAT值，本文使用ATNPA算法和Spark默認調(diào)度算法進行了大量的實驗。圖2給出了實驗數(shù)據(jù)的分析結(jié)果。

圖2 不同UAT閾值對集群性能提升的影響Fig.2 Effects of UAT value to cluster performance improvement

可以看到，當UAT 的閾值取1.1 時，系統(tǒng)整體的優(yōu)化效果最優(yōu)。即當UAT ≤1.1 的時候，認定該作業(yè)為CPU 密集型，反之為內(nèi)存密集型。ATNPA 將根據(jù)所得到的作業(yè)類型為其分配合適的集群資源。

2.2 節(jié)點性能偏向性

Spark默認調(diào)度策略僅依據(jù)CPU核數(shù)來完成節(jié)點選擇，節(jié)點的內(nèi)存量僅僅作為一個簡單的比較參考，而節(jié)點的其他信息（如是否包含GPU、網(wǎng)絡帶寬等）都未被考慮。

隨著集群異構(gòu)性的增強，集群中各節(jié)點的處理能力相差很大。一些節(jié)點的CPU 處理能力非常強勁，故其在處理CPU 密集型的用戶作業(yè)時，效率相較于其他節(jié)點會比較高；而有些節(jié)點具有較為高速的I/O讀寫能力，故而處理注重讀寫的用戶作業(yè)會有更加優(yōu)秀的表現(xiàn)。

因此需要進行節(jié)點對用戶作業(yè)的偏向性分析。

定義2 節(jié)點偏向性（node preference type，NPT）

其中，StaticResourcej是節(jié)點j的靜態(tài)資源值；DynamicResourcej是節(jié)點j的動態(tài)資源值；j∈{1,2,…,N},N為集群中節(jié)點個數(shù)。α、β分別是節(jié)點靜態(tài)資源值和動態(tài)資源值的對應權(quán)值。

根據(jù)專家分析得到，節(jié)點的靜態(tài)資源可以用CPU速度、CPU 核數(shù)、內(nèi)存大小以及磁盤容量表示。節(jié)點的動態(tài)資源可以用其CPU剩余率、內(nèi)存剩余率、磁盤剩余率及磁盤讀寫速度表示。

其中，節(jié)點靜態(tài)資源各影響因素的權(quán)值α1+α2+α3+α4=1。Coresj是節(jié)點j的CPU核數(shù)；Memoryj是其內(nèi)存總量；Storej表示磁盤容量，CpuSpeedj則是其CPU速度。

其中，節(jié)點動態(tài)資源各影響因素的權(quán)值β1+β2+β3+β4=1。AvaiCoresj是節(jié)點j的CPU剩余率；AvaiMemoryj是其內(nèi)存剩余率；AvaiSSdSpdj是當前磁盤讀寫速度，AvaiSSdj是其磁盤剩余率。

2.3 節(jié)點性能偏向性各影響因素權(quán)值的確定

本文采用層次分析法（analytic hierarchy process，AHP）來確定影響節(jié)點性能偏向性的各因素的權(quán)值，層次結(jié)構(gòu)模型如圖3所示。

圖3 節(jié)點性能偏向性層次結(jié)構(gòu)模型Fig.3 Hierarchical model for node performance

經(jīng)專家打分，靜態(tài)因素的四個影響因素的判斷矩陣如下：

計算得到W=[0.113 0.641 0.073 0.173]T，對應的CR=0.017<0.1，滿足一致性要求。

動態(tài)因素的四個影響因素經(jīng)專家打分，構(gòu)造出的判斷矩陣如下：

計算得到W=[0.344 0.422 0.156 0.078]T，對應的CR=0.008<0.1，滿足一致性要求。

公式（2）中的靜態(tài)資源值和動態(tài)資源值經(jīng)專家打分生成的判斷矩陣為：

根據(jù)相同步驟，得到α、β分別為0.5和0.5。

因為使用AHP 計算得到的權(quán)值具有一定的主觀性，因此，在后續(xù)的實驗過程當中，將根據(jù)實驗的運行結(jié)果對權(quán)值做出相應的調(diào)整，使作業(yè)運行時效率達到最優(yōu)。

2.4 基于用戶作業(yè)類型及節(jié)點性能偏向的資源調(diào)度算法ATNPA

為了提高Spark集群性能、縮短用戶作業(yè)執(zhí)行時間，本文設計了基于用戶作業(yè)類型及節(jié)點性能偏向的資源調(diào)度算法ATNPA。因為集群是多用戶共享的，所以會有很多的用戶作業(yè)在隊列中等待資源分配。ATNPA根據(jù)每個用戶作業(yè)的類型計算當前集群中各節(jié)點的性能偏向，進而確定節(jié)點的優(yōu)先級，并根據(jù)節(jié)點的優(yōu)先級進行節(jié)點的選擇和用戶作業(yè)的分發(fā)，將用戶作業(yè)分配到最適合作業(yè)特點的集群節(jié)點。ATNPA調(diào)度算法的實現(xiàn)框架如圖4所示。

圖4 ATNPA實現(xiàn)框架Fig.4 Implementation framework of ATNPA

Spark 集群啟動時，Worker 節(jié)點向Master 提交資源注冊消息。用戶提交作業(yè)時需要提供所需的CPU核數(shù)和內(nèi)存大小。當為一個用戶作業(yè)進行節(jié)點資源分配時，ATNPA 算法根據(jù)各個作業(yè)提交的參數(shù)，計算出用戶作業(yè)的類型，并在此基礎上計算得到集群中各節(jié)點的實時優(yōu)先級。ATNPA將用戶作業(yè)分發(fā)至若干個高優(yōu)先級的節(jié)點，直到滿足用戶要求的資源量。當集群中某個用戶作業(yè)運行結(jié)束，Master會結(jié)合Spark心跳信息機制，自動獲取各個Worker節(jié)點的現(xiàn)有資源狀態(tài)并重新計算出節(jié)點的動態(tài)資源數(shù)據(jù)，更新節(jié)點的優(yōu)先級，并為等待隊列中的用戶作業(yè)進行資源分配。

ATNPA算法的偽代碼如下。

3 仿真實驗

為了驗證ATNPA 調(diào)度算法的有效性，本文分別進行了串行作業(yè)和并行作業(yè)的實驗，下面將進行詳細介紹。

3.1 實驗環(huán)境

本文的實驗環(huán)境如表1與表2所示。

表1 仿真實驗硬件配置Table 1 Hardware configuration of simulation experiments

表2 仿真實驗軟件配置Table 2 Software configuration of experiments

根據(jù)節(jié)點性能偏向性的定義，影響節(jié)點性能的主要因素包括節(jié)點的內(nèi)存大小、CPU 核數(shù)、CPU 速度和磁盤讀寫速度等。在搭建仿真實驗環(huán)境時，各節(jié)點在這些因素上取值都加以區(qū)分，以體現(xiàn)出節(jié)點性能的偏向性和集群的異構(gòu)性。從表1可以看到，Master節(jié)點與其他節(jié)點內(nèi)存容量不同；Slave2 的CPU 核數(shù)較少；Slave3 采用的是普通機械硬盤，而其他節(jié)點均采用了固態(tài)硬盤，這樣可以體現(xiàn)出節(jié)點在存儲設備讀寫速度上的差異。在小型物理集群實驗中，各節(jié)點的CPU速度也有所不同。

3.2 實驗數(shù)據(jù)集及權(quán)值計算

本文采用的負載來自于中國科學院計算技術(shù)研究所研發(fā)的基于大數(shù)據(jù)基準測試的開源性程序集Big-DataBench[20]。BigDataBench總共包含了14個真實數(shù)據(jù)集和34個大數(shù)據(jù)工作負載。本文從BigDataBench基準測試套件中選擇了WordCount 和Sort 兩種工作負載。選擇WordCount 和Sort 的理由是這些工作負載簡單易懂，可以代表基本的Spark 應用程序，具有廣泛的應用性；同時它們在宏觀上分表代表了CPU 密集型和內(nèi)存密集型兩類應用。

為了彌補層次分析法主觀性強的缺點，本文通過具體的實驗對影響節(jié)點性能的各項動態(tài)因素的權(quán)值進行了調(diào)整。針對CPU 密集型和內(nèi)存密集型的任務，實驗中各指標的權(quán)值如表3所示。

表3 不同類型作業(yè)對應的指標權(quán)值Table 3 Weighs of indexes under different type of tasks

3.3 實驗過程

通過ATNPA 算法可以主動獲取節(jié)點的資源狀態(tài)，感知對應不同類型任務的節(jié)點的計算能力。本節(jié)根據(jù)仿真實驗的配置，按照以下步驟展示ATNPA的執(zhí)行過程。

（1）串行實驗。按照串行的方式分別向集群提交用戶作業(yè)Wordcount 和Sort，兩種作業(yè)數(shù)據(jù)集的大小均為6 GB，其中Wordcount 要求CPU 核數(shù)為3，內(nèi)存3 GB；Sort 要求CPU 核數(shù)為3，內(nèi)存6 GB。根據(jù)公式（1）可以得到，WordCount 是CPU 密集型作業(yè)，Sort 為內(nèi)存密集型作業(yè)。集群按照FIFO的順序運行這兩個用戶作業(yè)。

（2）根據(jù)步驟（1）的提交順序，通過公式（1）計算出用戶作業(yè)的類型，再根據(jù)此類型使用公式（2）、（3）、（4）計算節(jié)點的優(yōu)先級。之后按照優(yōu)先級列表進行用戶作業(yè)的分發(fā)。在串行運行作業(yè)開始時各個節(jié)點的優(yōu)先級如表4所示。

表4 用戶作業(yè)串行運行集群節(jié)點優(yōu)先級Table 4 Nodes priorities with serial user application execution

（3）并行實驗。重啟集群，按照并行的方式向集群提交WordCount和Sort的數(shù)據(jù)集。WordCount和Sort作業(yè)的具體要求與步驟（1）中描述的相同。集群按照并行的方式運行這兩個作業(yè)。

（4）通過公式（1）計算出各用戶作業(yè)的類型，再據(jù)此類型使用公式（2）、（3）、（4）計算集群中各節(jié)點的優(yōu)先級，同時按照優(yōu)先級列表進行用戶作業(yè)的分發(fā)。在并行運行作業(yè)開始時，各個節(jié)點的優(yōu)先級如表5所示。

從表4 和表5 給出的節(jié)點選擇結(jié)果可以看出，針對不同類型的用戶作業(yè)以及不同的運行模式（串行或并行運行），集群中的節(jié)點的優(yōu)先級是不一樣的，各節(jié)點的優(yōu)先級會隨著集群中作業(yè)的狀態(tài)而發(fā)生改變。所以本文提出的ATNPA算法會根據(jù)用戶作業(yè)的類型計算集群中節(jié)點相應的優(yōu)先級，并根據(jù)此優(yōu)先級把作業(yè)分配到最適合的節(jié)點，從而充分發(fā)揮節(jié)點的性能，縮短作業(yè)的完成時間。

表5 用戶作業(yè)并行運行集群節(jié)點優(yōu)先級Table 5 Nodes priorities with parallel user application execution

3.4 實驗結(jié)果

3.4.1 相同作業(yè)不同數(shù)據(jù)量

本小節(jié)選取了比較典型的WordCount和Sort任務，分別在使用Spark 默認調(diào)度算法和使用ATNPA 算法的Spark 集群中運行。任務采用不同規(guī)模的數(shù)據(jù)集，分別是2 GB、4 GB、6 GB、8 GB 和10 GB。每個數(shù)據(jù)規(guī)模實驗5次，取平均值作為實驗結(jié)果。實驗結(jié)果如圖5所示，圖5中的橫坐標代表不同的數(shù)據(jù)量，縱坐標表示完成整個用戶作業(yè)所需要的時間。

從圖5 可以看出，ATNPA 算法相較于Spark 默認的調(diào)度算法，可以將WordCount作業(yè)時間平均縮短8.33%；將Sort 作業(yè)時間平均縮短9.71%。因而無論是CPU 密集型還是內(nèi)存密集型的作業(yè)，使用ATNPA 算法都能夠有效縮短作業(yè)執(zhí)行時間，提高集群的效率。

圖5 相同作業(yè)不同數(shù)據(jù)量完成時間比較Fig.5 Comparison of completion time of same workloads with different amount of data

3.4.2 相同數(shù)據(jù)量不同負載并行實驗

本小節(jié)同樣選取了WordCount和Sort任務，讓這兩個負載進行并行運算來驗證ATNPA算法處理并行作業(yè)的系統(tǒng)效率提升。每次實驗兩類程序采用等量的數(shù)據(jù)量，分別為6 GB、8 GB 和10 GB，每個數(shù)據(jù)規(guī)模實驗5次，取平均值作為實驗結(jié)果。實驗結(jié)果圖6所示。

圖6 WordCount和Sort負載并行運算時間比較Fig.6 Comparison of completion time when both WordCount and Sort are executed in parallel

從圖6 可以看出，當WordCount 和Sort 兩個負載進行并行運算時，相比于Spark 的默認調(diào)度算法，ATNPA算法有著平均8.33%的提升。

從并行和串行的實驗結(jié)果分析表明，當集群一次運行一個用戶作業(yè)或是同時運行多個用戶作業(yè)時，由于ATNPA 能夠為每個作業(yè)分配到最適合其特點的節(jié)點，因此作業(yè)的完成時間都能夠減少，集群的性能從而得以提高。

4 結(jié)束語

目前關(guān)于Spark集群的資源調(diào)度算法沒有充分考慮用戶作業(yè)的類型和節(jié)點處理性能偏向性之間的關(guān)系。為了進一步提高Spark 集群的性能、有效地縮短作業(yè)運行時間，本文提出了ATNPA資源調(diào)度算法，它綜合考慮了作業(yè)的特性和節(jié)點處理性能偏向性。仿真實驗表明，與Spark默認的資源調(diào)度算法和沒有考慮節(jié)點性能與作業(yè)類型相關(guān)性的SDASA算法相比，ATNPA能夠有效提升系統(tǒng)性能，縮短作業(yè)的執(zhí)行時間。未來的工作將在以下幾個方面進行：

（1）目前本文考慮的作業(yè)類型只包括CPU 密集型和內(nèi)存密集型，下一步研究將討論更多的用戶作業(yè)類型，如I/O密集型、通信密集型等。將引入機器學習等人工智能方法更加準確地確定用戶作業(yè)類型的判定閾值。

（2）將增加節(jié)點動態(tài)資源影響因素，以便更加準確地確認節(jié)點在不同時間段的處理性能偏向。

（3）在大規(guī)模的集群上進行實驗，以驗證算法的有效性。