吳仁彪，劉 備，賈云飛

（中國(guó)民航大學(xué)天津市智能信號(hào)與圖像處理重點(diǎn)實(shí)驗(yàn)室，天津 300300）

傳統(tǒng)的單機(jī)處理模式不再滿足越來(lái)越多的機(jī)構(gòu)處理其海量數(shù)據(jù)，Spark 以內(nèi)存計(jì)算、通用和可擴(kuò)展性等優(yōu)勢(shì)成為目前主流的大數(shù)據(jù)計(jì)算框架[1]。集群硬件設(shè)備的不斷更新、損耗及計(jì)算需求的擴(kuò)大，會(huì)導(dǎo)致Spark 集群中的節(jié)點(diǎn)性能差異較大，使得集群異構(gòu)。異構(gòu)是指集群節(jié)點(diǎn)因CPU 等不同硬件的性能差異而導(dǎo)致其自身處理能力出現(xiàn)差異。如果仍用現(xiàn)有的資源調(diào)度策略，在集群異構(gòu)且資源約束的環(huán)境下會(huì)導(dǎo)致集群節(jié)點(diǎn)的負(fù)載失衡，影響作業(yè)執(zhí)行效率。Spark 資源調(diào)度策略是影響集群執(zhí)行效率的關(guān)鍵之一，因此，研究Spark集群異構(gòu)環(huán)境下高效、合理的資源調(diào)度策略具有重要意義。目前，國(guó)內(nèi)外針對(duì)資源調(diào)度優(yōu)化的研究主要著眼點(diǎn)于以下兩方面。

（1）通過(guò)優(yōu)化資源調(diào)度，提高集群的運(yùn)行效率是研究的熱點(diǎn)之一。楊志偉等[2]在Spark 默認(rèn)調(diào)度策略基礎(chǔ)上，通過(guò)分布式集群監(jiān)視系統(tǒng)Ganglia 獲取異構(gòu)集群節(jié)點(diǎn)負(fù)載及資源利用率，動(dòng)態(tài)調(diào)整節(jié)點(diǎn)的優(yōu)先級(jí)，提高了集群的執(zhí)行效率。Cheng 等[3]提出一種動(dòng)態(tài)資源下考慮作業(yè)完成期限的Hadoop 作業(yè)調(diào)度（RDS，resource and deadline-aware Hadoop job scheduler）算法，RDS 通過(guò)考慮未來(lái)資源的動(dòng)態(tài)變化，減少作業(yè)未在截止時(shí)間完成造成的損失。馮興杰等[4]通過(guò)建立異構(gòu)Hadoop 集群節(jié)點(diǎn)硬件參數(shù)和動(dòng)態(tài)信息兩個(gè)節(jié)點(diǎn)性能評(píng)價(jià)指標(biāo)，度量節(jié)點(diǎn)優(yōu)先級(jí)并改進(jìn)Hadoop 資源管理器的公平調(diào)度算法，提高了Hadoop 集群的執(zhí)行效率。胡亞紅等[5]將文獻(xiàn)[4]的方法運(yùn)用到異構(gòu)Spark 集群的默認(rèn)調(diào)度策略中，提出了一種基于節(jié)點(diǎn)優(yōu)先級(jí)的Spark 動(dòng)態(tài)自適應(yīng)調(diào)度算法，縮短了Spark 作業(yè)的執(zhí)行時(shí)間。隨著機(jī)器學(xué)習(xí)算法的快速發(fā)展，眾多研究人員將遺傳算法[6-7]、粒子群算法[8-9]和蟻群算法[10-11]等運(yùn)用在資源調(diào)度中并對(duì)多目標(biāo)進(jìn)行優(yōu)化，且上述算法應(yīng)用到集群資源調(diào)度中能夠取得較好的效果。

（2）隨著集群規(guī)模的擴(kuò)大，集群能源的消耗問(wèn)題是研究的另一熱點(diǎn)。大量的能源消耗不僅導(dǎo)致集群運(yùn)行維護(hù)成本增加，還會(huì)產(chǎn)生大量的二氧化碳，造成一定的環(huán)保問(wèn)題。因此，有必要研究如何在不違反服務(wù)水平協(xié)議的前提下，優(yōu)化資源調(diào)度以減少集群的能源消耗[12]。Grozev 等[13]提出了一種虛擬機(jī)資源調(diào)度算法，通過(guò)利用虛擬機(jī)實(shí)時(shí)遷移技術(shù)，將虛擬機(jī)合并到較少的物理節(jié)點(diǎn)上，從而降低集群的能源開(kāi)銷，提高資源利用率。

綜上，針對(duì)異構(gòu)Spark 集群在資源約束條件下，根據(jù)集群節(jié)點(diǎn)的負(fù)載變化動(dòng)態(tài)調(diào)度資源方面的研究較少。直接修改源代碼是優(yōu)化Spark 資源調(diào)度策略最直接、有效的方式。將集群節(jié)點(diǎn)的靜態(tài)負(fù)載和運(yùn)行時(shí)的動(dòng)態(tài)負(fù)載信息作為異構(gòu)集群節(jié)點(diǎn)負(fù)載的評(píng)價(jià)指標(biāo)，在集群分配資源時(shí)，基于負(fù)載大小對(duì)集群節(jié)點(diǎn)的順序進(jìn)行更新調(diào)整，實(shí)現(xiàn)資源動(dòng)態(tài)分配，從而改進(jìn)Spark 資源調(diào)度策略。

1 異構(gòu)Spark 集群節(jié)點(diǎn)負(fù)載評(píng)價(jià)

在異構(gòu)環(huán)境下，為保障作業(yè)的完成時(shí)間，提高集群執(zhí)行效率，需要準(zhǔn)確衡量各節(jié)點(diǎn)的負(fù)載大小，從而選出合適的節(jié)點(diǎn)進(jìn)行資源分配。有效的評(píng)價(jià)指標(biāo)是資源調(diào)度優(yōu)化的基礎(chǔ)，節(jié)點(diǎn)負(fù)載情況不僅受節(jié)點(diǎn)靜態(tài)負(fù)載的影響，同時(shí)也受節(jié)點(diǎn)動(dòng)態(tài)負(fù)載的影響。

1.1 節(jié)點(diǎn)靜態(tài)負(fù)載

傳統(tǒng)節(jié)點(diǎn)負(fù)載評(píng)價(jià)方法將CPU 核數(shù)、內(nèi)存及磁盤等硬件參數(shù)作為衡量節(jié)點(diǎn)性能的指標(biāo)。隨著集成電路技術(shù)的發(fā)展和制作工藝水平的提高，幾年前的單核CPU 和當(dāng)前單核CPU 的計(jì)算能力存在巨大差距，相同大小的內(nèi)存、磁盤等硬件性能也不可同日而語(yǔ)。文中選取SparkPi、WordCount 和K-means 3 組實(shí)驗(yàn)分別在單個(gè)Worker 節(jié)點(diǎn)上執(zhí)行，3 組實(shí)驗(yàn)充分利用了集群?jiǎn)蝹€(gè)節(jié)點(diǎn)的計(jì)算處理能力。首先，為了避免其他因素的影響，保證實(shí)驗(yàn)結(jié)果的有效性，每組實(shí)驗(yàn)在Worker 節(jié)點(diǎn)執(zhí)行m 次，得到3 組實(shí)驗(yàn)的平均執(zhí)行時(shí)間；然后，累加計(jì)算得到3 組實(shí)驗(yàn)的總平均執(zhí)行時(shí)間；最后，對(duì)總平均執(zhí)行時(shí)間進(jìn)行歸一化處理，歸一化的結(jié)果表示節(jié)點(diǎn)的靜態(tài)負(fù)載。

SparkPi 實(shí)驗(yàn)是運(yùn)用蒙特卡洛法計(jì)算出圓周率π值，主要利用服務(wù)器的CPU 資源。WordCount 實(shí)驗(yàn)是對(duì)大規(guī)模的文本文件數(shù)據(jù)進(jìn)行拆分和處理，最后進(jìn)行詞頻統(tǒng)計(jì)，該實(shí)驗(yàn)在處理數(shù)據(jù)的過(guò)程中利用了服務(wù)器的CPU 和內(nèi)存資源。K-means 是一種經(jīng)典的聚類算法，Spark 集群通過(guò)K-means 實(shí)驗(yàn)對(duì)數(shù)據(jù)進(jìn)行聚類分析，迭代結(jié)果在內(nèi)存中反復(fù)讀寫，主要利用服務(wù)器的內(nèi)存資源。通過(guò)SparkPi、WordCount 和K-means 3 組不同類型的實(shí)驗(yàn)，綜合衡量服務(wù)器的硬件性能。

（1）每組實(shí)驗(yàn)在Worker 節(jié)點(diǎn)的平均執(zhí)行時(shí)間表示如下

式中：m 為每組實(shí)驗(yàn)在Worker 節(jié)點(diǎn)的執(zhí)行次數(shù)；Ti，t表示第i 節(jié)點(diǎn)第t 次的執(zhí)行時(shí)間；N 為集群的Worker 節(jié)點(diǎn)數(shù)量。

（2）3 組實(shí)驗(yàn)的總平均執(zhí)行時(shí)間歸一化的結(jié)果表示W(wǎng)orker 節(jié)點(diǎn)靜態(tài)負(fù)載，即

式中：Lstatic，i表示第i 節(jié)點(diǎn)的靜態(tài)負(fù)載；Ti′表示第i 節(jié)點(diǎn)3 組實(shí)驗(yàn)的總平均執(zhí)行時(shí)間，T′={T1′，T2′，…，TN′}；min（T′）表示T′中最小的元素值；max（T′）表示T′中最大的元素值。

該方法較好地解決了異構(gòu)集群節(jié)點(diǎn)中CPU、內(nèi)存及磁盤等硬件型號(hào)不同導(dǎo)致傳統(tǒng)性能評(píng)價(jià)指標(biāo)不能很好適用的問(wèn)題。SparkPi、WordCount 和K-means 的平均執(zhí)行時(shí)間長(zhǎng)短更充分展現(xiàn)出了硬件性能差異。

1.2 節(jié)點(diǎn)動(dòng)態(tài)負(fù)載

Spark 是基于內(nèi)存處理的計(jì)算框架，主要利用CPU和內(nèi)存進(jìn)行計(jì)算。節(jié)點(diǎn)負(fù)載會(huì)隨著集群運(yùn)行狀態(tài)動(dòng)態(tài)變化，因此，需要實(shí)時(shí)關(guān)注集群資源使用情況以獲取相關(guān)信息。為了準(zhǔn)確反映節(jié)點(diǎn)負(fù)載的動(dòng)態(tài)變化，選取了CPU 利用率、內(nèi)存利用率和任務(wù)競(jìng)爭(zhēng)程度3 個(gè)指標(biāo)。

通過(guò)Linux 系統(tǒng)提供的一個(gè)內(nèi)存文件系統(tǒng)proc來(lái)進(jìn)行節(jié)點(diǎn)數(shù)據(jù)信息的采集。proc 提供了一個(gè)基于文件的Linux 內(nèi)部接口，其中的數(shù)據(jù)隨時(shí)間不斷變化，可用于確定系統(tǒng)中各種不同進(jìn)程的狀態(tài)。

（1）選取Linux proc/stat 命令采集的CPU 用戶態(tài)時(shí)間（user）、低優(yōu)先級(jí)的用戶態(tài)時(shí)間（nice）、核心態(tài)時(shí)間（system）及空閑時(shí)間（idle）的累加和作為Worker 節(jié)點(diǎn)CPU 運(yùn)行總時(shí)長(zhǎng)，第i 節(jié)點(diǎn)第k 次計(jì)算的CPU 運(yùn)行總時(shí)間表示為

式中Tuser，i，k、Tnice，i，k、Tsystem，i，k、Tidle，i，k分別表示第i 節(jié)點(diǎn)第k 次采集的用戶態(tài)時(shí)間、低優(yōu)先級(jí)的用戶態(tài)時(shí)間、核心態(tài)時(shí)間及空閑時(shí)間。再根據(jù)相鄰兩次采集的數(shù)據(jù)計(jì)算出當(dāng)前的CPU 利用率，第i 節(jié)點(diǎn)第k 次計(jì)算的CPU利用率表示為

式中：Tidle，i，k1和Tidle，i，k2分別表示第i 節(jié)點(diǎn)相鄰兩次采集到的空閑時(shí)間；Ttotal，i，k1和Ttotal，i，k2分別表示第i 節(jié)點(diǎn)相鄰兩次計(jì)算的CPU 運(yùn)行總時(shí)間。

（2）選取Linux proc/meminfo 命令采集的總共可用的內(nèi)存大?。╩emtotal）和未使用的內(nèi)存大小（memfree）計(jì)算出Worker 節(jié)點(diǎn)的內(nèi)存利用率，第i 節(jié)點(diǎn)第k 次計(jì)算的內(nèi)存利用率表示為

式中Tmemtotal，i，k和Tmemfree，i，k分別表示第i 節(jié)點(diǎn)第k 次采集的總共可用的內(nèi)存大小和未使用的內(nèi)存大小。

（3）集群在執(zhí)行任務(wù)的過(guò)程中，節(jié)點(diǎn)的任務(wù)隊(duì)列會(huì)隨著時(shí)間變化，選取Linux proc/loadavg 命令采集的1 min 時(shí)的任務(wù)隊(duì)列的平均長(zhǎng)度計(jì)算出Worker 節(jié)點(diǎn)的任務(wù)競(jìng)爭(zhēng)程度，第i 節(jié)點(diǎn)第k 次計(jì)算的任務(wù)競(jìng)爭(zhēng)程度表示為

式中：Ltask，i，k表示第i 節(jié)點(diǎn)第k 次采集的任務(wù)隊(duì)列的平均長(zhǎng)度；Ncpu，core，i表示第i 節(jié)點(diǎn)CPU 核數(shù)。

（4）選取CPU 利用率、內(nèi)存利用率和任務(wù)競(jìng)爭(zhēng)程度表示W(wǎng)orker 節(jié)點(diǎn)動(dòng)態(tài)負(fù)載，則第i 節(jié)點(diǎn)第k 次計(jì)算的動(dòng)態(tài)負(fù)載表示為

1.3 節(jié)點(diǎn)負(fù)載

綜合考慮節(jié)點(diǎn)靜態(tài)負(fù)載和動(dòng)態(tài)負(fù)載作為節(jié)點(diǎn)負(fù)載的評(píng)價(jià)指標(biāo)，異構(gòu)集群第i 節(jié)點(diǎn)第k 次計(jì)算的負(fù)載表示為

式中α、β 分別表示節(jié)點(diǎn)靜態(tài)負(fù)載和動(dòng)態(tài)負(fù)載的權(quán)重，α+β=1。

此異構(gòu)Spark 集群節(jié)點(diǎn)負(fù)載評(píng)價(jià)策略不用在集群中安裝Nanglia 就可獲取到Worker 節(jié)點(diǎn)的數(shù)據(jù)信息，不會(huì)額外消耗集群資源，直接通過(guò)Linux 命令獲取Worker 節(jié)點(diǎn)的數(shù)據(jù)信息，延遲較小。

2 Spark 資源調(diào)度策略描述

2.1 默認(rèn)資源調(diào)度策略

Standalone 是Spark 計(jì)算框架的默認(rèn)資源調(diào)度器[14]，合理的資源分配是集群高效運(yùn)行的基礎(chǔ)。Spark 計(jì)算框架復(fù)雜，資源調(diào)度中重要流程如圖1所示。

圖1 資源調(diào)度流程圖Fig.1 The flow chart of the resource scheduling

Spark 集群在Standalone 調(diào)度下，當(dāng)多個(gè)用戶提交應(yīng)用程序（Application）到集群中運(yùn)行，按提交時(shí)間順序?qū)pplication 進(jìn)行排序。Master 節(jié)點(diǎn)在集群中根據(jù)Worker 節(jié)點(diǎn)剩余CPU 核數(shù)從大到小排序。默認(rèn)分配規(guī)則先進(jìn)先出取出隊(duì)列第一個(gè)Application，按照Worker 節(jié)點(diǎn)順序篩選滿足資源的節(jié)點(diǎn)啟動(dòng)執(zhí)行器（Executor），剩余排隊(duì)的Application 在剩余資源中再次篩選。Spark 默認(rèn)資源調(diào)度策略基于集群節(jié)點(diǎn)同構(gòu)的理想化設(shè)計(jì)，只考慮節(jié)點(diǎn)CPU 使用情況，沒(méi)有考慮集群異構(gòu)性及節(jié)點(diǎn)當(dāng)前內(nèi)存使用情況。這種資源調(diào)度策略在執(zhí)行CPU 密集型作業(yè)時(shí)具有很高的效率，但執(zhí)行內(nèi)存密集型作業(yè)時(shí)很可能造成CPU 配置高且內(nèi)存配置較低的節(jié)點(diǎn)內(nèi)存經(jīng)常處于滿負(fù)載狀態(tài)，而CPU 配置較低且內(nèi)存配置高的節(jié)點(diǎn)內(nèi)存經(jīng)常處于饑餓狀態(tài)。

2.2 Spark 動(dòng)態(tài)資源調(diào)度策略設(shè)計(jì)架構(gòu)

針對(duì)以上不足，設(shè)計(jì)出基于異構(gòu)集群節(jié)點(diǎn)負(fù)載的Spark動(dòng)態(tài)資源調(diào)度策略，以包含2 個(gè)Worker 節(jié)點(diǎn)的集群為例，設(shè)計(jì)架構(gòu)如圖2所示。其中：Worker 節(jié)點(diǎn)中的節(jié)點(diǎn)動(dòng)態(tài)負(fù)載指標(biāo)收集模塊負(fù)責(zé)獲取每個(gè)Worker節(jié)點(diǎn)的CPU 利用率、內(nèi)存利用率和任務(wù)競(jìng)爭(zhēng)程度3 個(gè)指標(biāo)的實(shí)時(shí)數(shù)據(jù)，通過(guò)Spark 的RPC（remote procedure call）將收集的數(shù)據(jù)以心跳方式傳輸?shù)組aster 節(jié)點(diǎn)；Master 節(jié)點(diǎn)中的節(jié)點(diǎn)負(fù)載計(jì)算存儲(chǔ)模塊負(fù)責(zé)獲取Spark 配置文件spark-defaults.conf 中的節(jié)點(diǎn)靜態(tài)負(fù)載，將傳輸?shù)臄?shù)據(jù)代入節(jié)點(diǎn)動(dòng)態(tài)負(fù)載公式，得到節(jié)點(diǎn)的動(dòng)態(tài)負(fù)載，再根據(jù)節(jié)點(diǎn)的靜態(tài)負(fù)載和動(dòng)態(tài)負(fù)載數(shù)據(jù)計(jì)算出節(jié)點(diǎn)負(fù)載。當(dāng)需要分配資源時(shí)，Master 節(jié)點(diǎn)將Worker 節(jié)點(diǎn)根據(jù)負(fù)載值由小到大進(jìn)行排序，優(yōu)先選擇隊(duì)列靠前且滿足運(yùn)行條件的Worker 節(jié)點(diǎn)開(kāi)辟資源。Worker 節(jié)點(diǎn)序列調(diào)整的頻率與Spark 的心跳頻率有直接關(guān)系。為保證Worker 節(jié)點(diǎn)序列能準(zhǔn)確、迅速地根據(jù)節(jié)點(diǎn)負(fù)載值動(dòng)態(tài)調(diào)整，本策略將Spark 源代碼中的心跳頻率由默認(rèn)的15 s 調(diào)整到3 s，提高了資源分配時(shí)節(jié)點(diǎn)的適配性。

圖2 Spark 動(dòng)態(tài)資源調(diào)度策略設(shè)計(jì)架構(gòu)Fig.2 The design architecture of spark dynamic resource scheduling strategy

2.3 Spark 動(dòng)態(tài)資源調(diào)度策略模塊實(shí)現(xiàn)

直接修改Spark 源代碼實(shí)現(xiàn)基于異構(gòu)集群節(jié)點(diǎn)負(fù)載的Spark 動(dòng)態(tài)資源調(diào)度策略。Spark 源代碼默認(rèn)資源調(diào)度策略涉及的主要的類和特質(zhì)如圖3所示，修改之后進(jìn)行多次調(diào)試、驗(yàn)證，最后部署到Spark 集群中運(yùn)行。

圖3 源碼模塊實(shí)現(xiàn)框圖Fig.3 Implementation diagram of source code module

LinuxSystemTool 類實(shí)現(xiàn)以下功能：①通過(guò)采集/proc/stat 文件中當(dāng)前i 節(jié)點(diǎn)的Tuser，i，k、Tnice，i，k、Tsystem，i，k及Tidle，i，k4 個(gè)參數(shù)值，然后設(shè)置線程睡眠1 s（Thread.sleep（1 000）），再次采集上述4 個(gè)參數(shù)值，將前后兩次采集值代入式（3）和式（4），可得到當(dāng)前i 節(jié)點(diǎn)的CPU 利用率；②通過(guò)采集proc/meminfo 文件中當(dāng)前i 節(jié)點(diǎn)的Tmemtotal，i，k和Tmemfree，i，k參數(shù)值，代入式（5）可得到當(dāng)前i 節(jié)點(diǎn)的內(nèi)存利用率；③通過(guò)采集/proc/loadavg 文件中1 min 時(shí)的任務(wù)隊(duì)列的平均長(zhǎng)度，代入式（6）可得到當(dāng)前i 節(jié)點(diǎn)的任務(wù)競(jìng)爭(zhēng)程度。

在Master 類中，讀取配置文件spark-defaults.conf中的節(jié)點(diǎn)靜態(tài)負(fù)載，將靜態(tài)負(fù)載與節(jié)點(diǎn)IP 地址進(jìn)行映射。通過(guò)負(fù)載計(jì)算公式和心跳傳輸?shù)膭?dòng)態(tài)負(fù)載指標(biāo)，計(jì)算出實(shí)時(shí)的節(jié)點(diǎn)負(fù)載值。根據(jù)節(jié)點(diǎn)負(fù)載值大小對(duì)節(jié)點(diǎn)進(jìn)行由小到大排序，確定節(jié)點(diǎn)的優(yōu)先級(jí)。

在DeployMessage 特質(zhì)中添加MachineInfo 類，類中包含節(jié)點(diǎn)CPU 核數(shù)、CPU 利用率、內(nèi)存利用率和任務(wù)競(jìng)爭(zhēng)程度4 個(gè)參數(shù)。將樣本類MachineInfo 添加到心跳Heartbeat 類參數(shù)中。

在Worker 類中，通過(guò)修改HEARTBEAT_MILLIS變量，將心跳頻率由默認(rèn)的15 s 調(diào)整到3 s，提高節(jié)點(diǎn)負(fù)載實(shí)時(shí)更新頻率。心跳觸發(fā)時(shí)，通過(guò)調(diào)用Linux SystemTool 類收集節(jié)點(diǎn)動(dòng)態(tài)負(fù)載指標(biāo)。

將修改后的Spark 源代碼通過(guò)Maven 進(jìn)行編譯，編譯生成的spark-core.jar 文件與集群所有節(jié)點(diǎn)的spark-core.jar 文件進(jìn)行替換，實(shí)現(xiàn)上述基于異構(gòu)集群節(jié)點(diǎn)負(fù)載的Spark 動(dòng)態(tài)資源調(diào)度策略。當(dāng)集群擴(kuò)展時(shí)，只需要將增加的節(jié)點(diǎn)靜態(tài)負(fù)載與對(duì)應(yīng)的IP 地址添加到spark-defaults.conf 中，無(wú)需重新修改、編譯sparkcore.jar 文件。此策略具有良好的可擴(kuò)展性。

3 實(shí)驗(yàn)分析

通過(guò)實(shí)驗(yàn)得到Spark 集群中Worker 節(jié)點(diǎn)靜態(tài)負(fù)載，并確定節(jié)點(diǎn)的靜態(tài)負(fù)載和動(dòng)態(tài)負(fù)載的權(quán)重，分別取值為0.4 和0.6。將基于異構(gòu)集群節(jié)點(diǎn)負(fù)載的Spark動(dòng)態(tài)資源調(diào)度策略（簡(jiǎn)稱改進(jìn)調(diào)度策略）與默認(rèn)資源調(diào)度策略進(jìn)行比較，分析策略的優(yōu)缺點(diǎn)。

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

通過(guò)安裝VMware 虛擬機(jī)（VM）來(lái)構(gòu)建異構(gòu)Spark集群，每臺(tái)VM 作為集群的1 個(gè)節(jié)點(diǎn)，共3 個(gè)節(jié)點(diǎn)。部署的Spark 集群包括1 個(gè)Master 節(jié)點(diǎn)和2 個(gè)Worker節(jié)點(diǎn)。集群相關(guān)配置參數(shù)如表1所示。

表1 集群相關(guān)配置Tab.1 Cluster related configuration

3.2 節(jié)點(diǎn)負(fù)載實(shí)驗(yàn)結(jié)果分析

利用SparkPi、WordCount 和K-means 3 組實(shí)驗(yàn)，測(cè)試集群中每個(gè)節(jié)點(diǎn)的性能。每個(gè)Worker 節(jié)點(diǎn)都分別執(zhí)行2 000 次隨機(jī)選點(diǎn)的SparkPi 實(shí)驗(yàn)、1 GB 數(shù)據(jù)量的WordCount 實(shí)驗(yàn)和1 GB 數(shù)據(jù)量的K-means 實(shí)驗(yàn)，為程序分配節(jié)點(diǎn)的所有資源。實(shí)驗(yàn)重復(fù)10 次，3 組實(shí)驗(yàn)執(zhí)行時(shí)間如圖4所示。

圖4 3 組點(diǎn)節(jié)負(fù)載實(shí)驗(yàn)執(zhí)行時(shí)間Fig.4 Three groups of node load experiments execution time

由圖4可看出，相同實(shí)驗(yàn)每次的執(zhí)行時(shí)間稍有波動(dòng)，為保證結(jié)果的可靠性，取每組執(zhí)行時(shí)間的平均值。根據(jù)式（1）和式（2）得到Worker 節(jié)點(diǎn)靜態(tài)負(fù)載值。3 組實(shí)驗(yàn)平均執(zhí)行時(shí)間充分反映出節(jié)點(diǎn)的硬件性能，節(jié)點(diǎn)的硬件性能制約著作業(yè)的完成時(shí)間，因此，節(jié)點(diǎn)的靜態(tài)負(fù)載是集群資源調(diào)度的關(guān)鍵指標(biāo)。

3.3 有效性實(shí)驗(yàn)結(jié)果分析

本節(jié)實(shí)驗(yàn)分成兩種：實(shí)驗(yàn)1 是CPU 密集型作業(yè)，選擇計(jì)算π 值的SparkPi 實(shí)驗(yàn)；實(shí)驗(yàn)2 是內(nèi)存密集型作業(yè)，選擇聚類算法K-means 實(shí)驗(yàn)。測(cè)試改進(jìn)調(diào)度策略與默認(rèn)調(diào)度策略對(duì)兩種不同作業(yè)的執(zhí)行效果，實(shí)驗(yàn)執(zhí)行10 次，取執(zhí)行時(shí)間的平均值。兩種實(shí)驗(yàn)的參數(shù)設(shè)置如表2所示。

表2 參數(shù)設(shè)置Tab.2 Parameter settings

實(shí)驗(yàn)1SparkPi 實(shí)驗(yàn)分為兩組，分別將程序重復(fù)提交到集群中2 次和3 次，提交間隔為5 s，測(cè)試多個(gè)CPU 密集型作業(yè)向集群申請(qǐng)資源執(zhí)行時(shí)，集群資源的分配情況和作業(yè)平均執(zhí)行時(shí)間。實(shí)驗(yàn)在Standalone 集群模式下執(zhí)行，結(jié)果如表3所示。

表3 SparkPi 實(shí)驗(yàn)結(jié)果Tab.3 Experimental results of SparkPi

表3中Executor 的啟動(dòng)位置和啟動(dòng)個(gè)數(shù)表示集群已啟動(dòng)資源的分布情況。分析表3結(jié)果可知，集群異構(gòu)的情況下，默認(rèn)調(diào)度策略在分配資源時(shí)存在負(fù)載失衡的情況。根據(jù)本組實(shí)驗(yàn)結(jié)果顯示和對(duì)Spark 源代碼研究分析可得：默認(rèn)調(diào)度策略對(duì)使用CPU 計(jì)算的作業(yè)具有很好的執(zhí)行效率；在一般情況下，改進(jìn)調(diào)度策略和默認(rèn)調(diào)度策略在執(zhí)行CPU 密集型作業(yè)時(shí)效率相當(dāng)；當(dāng)默認(rèn)調(diào)度策略出現(xiàn)多個(gè)作業(yè)集中在單個(gè)節(jié)點(diǎn)的情況時(shí)，改進(jìn)調(diào)度策略能夠一定程度上縮短作業(yè)執(zhí)行時(shí)間。

實(shí)驗(yàn)2K-means 實(shí)驗(yàn)提交方式同實(shí)驗(yàn)1，該實(shí)驗(yàn)是為了驗(yàn)證默認(rèn)調(diào)度策略在分配資源時(shí)只考慮了CPU的使用情況，沒(méi)有考慮此類內(nèi)存密集型作業(yè)內(nèi)存的使用情況，當(dāng)用戶以一定時(shí)間間隔提交多個(gè)內(nèi)存密集型作業(yè)向集群申請(qǐng)資源時(shí)，造成資源分配不均，影響作業(yè)執(zhí)行時(shí)間，同時(shí)分析改進(jìn)調(diào)度策略在此情況下是否能得到更好的效果。實(shí)驗(yàn)使用1 GB 數(shù)據(jù)量，K-means 實(shí)驗(yàn)結(jié)果如表4所示。

分析表4結(jié)果可知，集群異構(gòu)的情況下，當(dāng)單個(gè)作業(yè)占用的內(nèi)存較大時(shí)，基于剩余CPU 核數(shù)考慮的默認(rèn)調(diào)度策略會(huì)導(dǎo)致集群負(fù)載嚴(yán)重失衡，改進(jìn)調(diào)度策略則能取得良好的效果。當(dāng)重復(fù)提交2 個(gè)作業(yè)時(shí)，改進(jìn)調(diào)度策略作業(yè)平均執(zhí)行時(shí)間縮短了7.97%。當(dāng)重復(fù)提交3 個(gè)作業(yè)時(shí)，此時(shí)默認(rèn)資源調(diào)度下節(jié)點(diǎn)間負(fù)載已經(jīng)極度不均衡，改進(jìn)調(diào)度策略作業(yè)平均執(zhí)行時(shí)間縮短了13.40%。

表4 K-means 實(shí)驗(yàn)結(jié)果Tab.4 Experimental results of K-means

3.4 可擴(kuò)展性實(shí)驗(yàn)結(jié)果分析

Spark 集群增加Worker03 節(jié)點(diǎn)，節(jié)點(diǎn)硬件配置為雙核、4 GB 內(nèi)存和40 GB 硬盤。Worker03 節(jié)點(diǎn)的3 組實(shí)驗(yàn)執(zhí)行時(shí)間如表5所示，可求得該節(jié)點(diǎn)總的平均執(zhí)行時(shí)間為64.5 s。

表5 3 組可擴(kuò)展性實(shí)驗(yàn)執(zhí)行時(shí)間Tab.5 Three groups of scalability experiments execution time

Spark 集群執(zhí)行K-means 實(shí)驗(yàn)，參數(shù)設(shè)置、數(shù)據(jù)集和提交方式同實(shí)驗(yàn)2。該組K-means 實(shí)驗(yàn)的可擴(kuò)展性實(shí)驗(yàn)結(jié)果如表6所示。

表6 可擴(kuò)展性實(shí)驗(yàn)結(jié)果Tab.6 Experimental results on scalability

分析表6結(jié)果可得，當(dāng)集群節(jié)點(diǎn)增加時(shí)，改進(jìn)調(diào)度策略同樣可以有效緩解集群負(fù)載失衡問(wèn)題且縮短了作業(yè)平均執(zhí)行時(shí)間，驗(yàn)證了改進(jìn)調(diào)度策略的可擴(kuò)展性。

綜上，實(shí)驗(yàn)驗(yàn)證了默認(rèn)調(diào)度策略存在不足，而改進(jìn)調(diào)度策略不僅適用默認(rèn)調(diào)度的應(yīng)用場(chǎng)景，且在用戶執(zhí)行多個(gè)內(nèi)存密集型作業(yè)場(chǎng)景中取得更好的效果，縮短了作業(yè)平均執(zhí)行時(shí)間，提高了集群的工作效率，同時(shí)具備較好的可擴(kuò)展性。

4 結(jié)語(yǔ)

通過(guò)研究Spark 的資源管理器Standalone，對(duì)傳統(tǒng)衡量節(jié)點(diǎn)性能的方法進(jìn)行優(yōu)化。綜合考慮節(jié)點(diǎn)靜態(tài)負(fù)載和動(dòng)態(tài)負(fù)載確定了異構(gòu)集群節(jié)點(diǎn)負(fù)載評(píng)價(jià)指標(biāo)，在獲取節(jié)點(diǎn)動(dòng)態(tài)負(fù)載方面，此策略沒(méi)有添加集群監(jiān)控組件，而是通過(guò)Linux 的內(nèi)存文件系統(tǒng)proc 實(shí)現(xiàn)，不會(huì)額外消耗集群資源。根據(jù)異構(gòu)集群節(jié)點(diǎn)負(fù)載評(píng)價(jià)指標(biāo)計(jì)算出節(jié)點(diǎn)實(shí)時(shí)負(fù)載，優(yōu)先選取負(fù)載低的節(jié)點(diǎn)分配資源，實(shí)現(xiàn)集群資源的動(dòng)態(tài)調(diào)度。從源代碼層級(jí)對(duì)Spark資源調(diào)度策略進(jìn)行改進(jìn)，并搭建異構(gòu)Spark 集群進(jìn)行實(shí)驗(yàn)，結(jié)果表明：Spark 集群中加入此改進(jìn)調(diào)度策略，在集群負(fù)載均衡方面取得較好效果；在特定場(chǎng)景下，提高了作業(yè)執(zhí)行效率，證明了策略的有效性和可擴(kuò)展性。下一步工作要在源代碼的基礎(chǔ)上，進(jìn)一步改進(jìn)Spark 任務(wù)調(diào)度，將任務(wù)調(diào)度策略與改進(jìn)的資源調(diào)度相結(jié)合，使得調(diào)度策略更具有普適性。