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

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

2.西安交通大學(xué) 計算機(jī)學(xué)院，西安710049

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1 Spark主要運(yùn)行模式及流程

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

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

目前，Spark的幾種主要運(yùn)行模式及其特點(diǎn)如下：

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

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

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

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

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

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

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

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

2.1 用戶作業(yè)類型

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

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

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

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

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

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

2.2 節(jié)點(diǎn)性能偏向性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ATNPA算法的偽代碼如下。

3 仿真實(shí)驗(yàn)

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

3.1 實(shí)驗(yàn)環(huán)境

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

表1 仿真實(shí)驗(yàn)硬件配置Table 1 Hardware configuration of simulation experiments

表2 仿真實(shí)驗(yàn)軟件配置Table 2 Software configuration of experiments

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

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

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

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

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

3.3 實(shí)驗(yàn)過程

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

（1）串行實(shí)驗(yàn)。按照串行的方式分別向集群提交用戶作業(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ùn)行這兩個用戶作業(yè)。

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

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

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

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

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

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

3.4 實(shí)驗(yàn)結(jié)果

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

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

從圖5 可以看出，ATNPA 算法相較于Spark 默認(rèn)的調(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ù)量不同負(fù)載并行實(shí)驗(yàn)

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

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

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

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

4 結(jié)束語

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

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

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

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