胡昌秀,張仰森,2,彭 爽,陳 涵,祁浩家

(1.北京信息科技大學(xué) 智能信息處理研究所, 北京 100101;2.國家經(jīng)濟(jì)安全預(yù)警工程北京實(shí)驗(yàn)室, 北京 100044;3.東北師范大學(xué) 文學(xué)院, 長春 130022)

0 引言

機(jī)器學(xué)習(xí)是一種非常依賴于數(shù)據(jù)與計(jì)算能力的技術(shù)。隨著大數(shù)據(jù)技術(shù)的出現(xiàn)與不斷發(fā)展,得以存儲大量的數(shù)據(jù),促進(jìn)了機(jī)器學(xué)習(xí)的又一輪發(fā)展浪潮。雖然硬件性能已經(jīng)飛速提升,利用GPU進(jìn)行機(jī)器學(xué)習(xí)任務(wù)的訓(xùn)練也使得訓(xùn)練速度得到了極大提升,然而高性能單節(jié)點(diǎn)在不斷增多的海量數(shù)據(jù)面前已是杯水車薪,如何開發(fā)出高效的大數(shù)據(jù)學(xué)習(xí)框架成為了研究的熱點(diǎn)。

誕生于2008年的Mahout[1]旨在建立可伸縮的機(jī)器學(xué)習(xí)算法,依托Hadoop框架,Mahout可以將文檔聚類、推薦、過濾等機(jī)器學(xué)習(xí)任務(wù)部署到分布式環(huán)境中;Hadoop的MapRuduce計(jì)算模型在每次計(jì)算時(shí)都需要讀寫磁盤,產(chǎn)生大量I/O操作,不適合多次迭代計(jì)算,導(dǎo)致Mahout的效率不高。Spark MLlib[2]是隨Spark計(jì)算框架出現(xiàn)的機(jī)器學(xué)習(xí)庫,Spark的核心概念是RDD(彈性分布式數(shù)據(jù)集),其特性是邏輯不落地以及不可變性,雖然邏輯不落地可以很好地解決迭代計(jì)算的問題,但是不可變性卻不適合參數(shù)多次反復(fù)更新的需求,導(dǎo)致Spark MLlib后續(xù)發(fā)展緩慢。Angel[3]是由騰訊公司與北京大學(xué)聯(lián)合開發(fā)的分布式機(jī)器學(xué)習(xí)框架,它使用參數(shù)服務(wù)器進(jìn)行參數(shù)的同步與更新,解決了RDD不可變性所帶來的問題,使得在Spark框架上也能高效地執(zhí)行機(jī)器學(xué)習(xí)任務(wù)。TensorFlow是目前使用人數(shù)最多的機(jī)器學(xué)習(xí)框架之一,雅虎開源的TensorFlowOnSpark框架能夠輕松地將TensorFlow代碼遷移到Spark集群上運(yùn)行,并且允許調(diào)用GPU資源進(jìn)行計(jì)算,也具有自身獨(dú)特的優(yōu)勢。

隨著分布式機(jī)器學(xué)習(xí)框架的發(fā)展,GPU等計(jì)算資源也被引入到大數(shù)據(jù)集群之中。YARN[4]是大數(shù)據(jù)集群中使用最廣泛的集群資源管理與調(diào)度程序,然而YARN僅能對資源進(jìn)行邏輯上的管理,無法監(jiān)測到各節(jié)點(diǎn)的實(shí)際資源情況,同時(shí)YARN也無法較好地管理GPU等資源。各分布式機(jī)器學(xué)習(xí)框架的部署、使用流程不同,為在同一集群中有使用多框架需求的用戶帶來不便。YARN原生的任務(wù)調(diào)度算法需要手動(dòng)指定任務(wù)提交隊(duì)列,靈活性較差,同時(shí)在引入GPU等資源后可能導(dǎo)致計(jì)算資源的浪費(fèi)。

針對上述問題,本文中提出了一種異構(gòu)資源下分布式機(jī)器學(xué)習(xí)框架整合平臺,以Spark框架為基礎(chǔ),向下對異構(gòu)資源進(jìn)行拓展與管理,向上整合了SparkOnAngel與TensorFlowOnSpark 2種框架,對任務(wù)調(diào)度算法進(jìn)行優(yōu)化,并封裝一套統(tǒng)一的使用接口以方便用戶的調(diào)用。

1 研究現(xiàn)狀

1.1 異構(gòu)計(jì)算平臺

近年來,各類不同體系架構(gòu)的計(jì)算設(shè)備(如GPU、FPGA等)逐漸被引入大數(shù)據(jù)平臺中,研究人員設(shè)計(jì)策略與算法,使得平臺能夠?qū)崿F(xiàn)對異構(gòu)資源的管理,并根據(jù)設(shè)備特點(diǎn)為其分配不同任務(wù)[5],以達(dá)到優(yōu)勢互補(bǔ)的目的。

Wu等[6]實(shí)現(xiàn)了一種基于CPU-GPU異構(gòu)平臺的雷達(dá)成像系統(tǒng),借助于GPU高效的并行計(jì)算能力,使得系統(tǒng)的計(jì)算速度比多線程CPU快了數(shù)倍以上。劉昆昆[7]針對節(jié)點(diǎn)計(jì)算性能不均產(chǎn)生的異構(gòu)問題,在集群中加入了節(jié)點(diǎn)性能監(jiān)測模塊,使得各節(jié)點(diǎn)情況能夠被實(shí)時(shí)監(jiān)測并為后續(xù)分配提供依據(jù)。周松江[8]提出了一種基于CPU與多FPGA的深度學(xué)習(xí)異構(gòu)計(jì)算平臺,在耗能增加較少的情況下提升了計(jì)算速度。欒奕等[9]提出利用FPGA邏輯資源搭建TPU,并結(jié)合ARM CPU構(gòu)建了一種新型的邊緣計(jì)算框架,提高了深度神經(jīng)網(wǎng)絡(luò)模型的加速計(jì)算能力以及準(zhǔn)確度,并降低了功耗。何健等[10]提出一種基于CPU+FPGA混合異構(gòu)計(jì)算資源平臺框架,結(jié)合GPU的并行計(jì)算與FPGA可編程特性,用于實(shí)現(xiàn)高速弱小目標(biāo)智能處理的神經(jīng)網(wǎng)絡(luò)算法。湯小春等[11]提出一種可感知批處理/流處理應(yīng)用的混合式資源調(diào)度框架,將CPU-GPU資源動(dòng)態(tài)結(jié)合,利用隊(duì)列堆疊技術(shù),滿足實(shí)時(shí)流處理作業(yè)的要求。

1.2 資源管理與分配

隨著異構(gòu)計(jì)算環(huán)境的增多,許多學(xué)者開始研究如何對這些資源進(jìn)行管理與分配,以解決異構(gòu)資源計(jì)算能力不同可能帶來的計(jì)算資源浪費(fèi)問題。

湯小春等[12]提出了一種集中式異構(gòu)資源管理模型,并設(shè)計(jì)了一種混合主資源分配算法,使得異構(gòu)資源的使用率以及任務(wù)的完成數(shù)量提升了15%。馮碩等[13]在對數(shù)據(jù)特征進(jìn)行量化,分析不同服務(wù)器之間性能差異的基礎(chǔ)上,引入工作負(fù)載預(yù)測模型,以提升資源的利用率。田國忠等[14]提出了一種基于總費(fèi)用變化量探測的費(fèi)用優(yōu)化算法,降低了多DAG任務(wù)在異構(gòu)資源調(diào)度上的費(fèi)用優(yōu)化問題。朱紫鈺等[15]提出了一種基于不均勻數(shù)據(jù)分片的方法,結(jié)合線性規(guī)劃的手段,讓CPU作業(yè)與GPU作業(yè)執(zhí)行時(shí)間盡可能相近,從而降低分布式機(jī)器學(xué)習(xí)作業(yè)的整體作業(yè)時(shí)間。

1.3 大數(shù)據(jù)框架下的任務(wù)調(diào)度策略

當(dāng)前的大數(shù)據(jù)集群一般采用YARN完成任務(wù)的調(diào)度工作,YARN內(nèi)部有FIFO、FAIR、Capaciy 3種任務(wù)調(diào)度策略,雖然這些策略具有通用性,但仍有進(jìn)一步優(yōu)化的空間。

胡亞紅等[16]提出了基于節(jié)點(diǎn)優(yōu)先級的Spark動(dòng)態(tài)自適應(yīng)調(diào)度算法,核心思想是設(shè)計(jì)評價(jià)指標(biāo)并給節(jié)點(diǎn)標(biāo)記優(yōu)先級作為任務(wù)分配的依據(jù)。胡亞紅等[17]提出一種節(jié)點(diǎn)實(shí)時(shí)性能自適應(yīng)的集群資源分配算法NPARSA,核心思想是按照作業(yè)的任務(wù)標(biāo)簽自動(dòng)選擇節(jié)點(diǎn)性能評價(jià)指標(biāo)的權(quán)值。黃錦增等[18]設(shè)計(jì)了一種面向計(jì)算密集型應(yīng)用的異構(gòu)GPU調(diào)度方法,使得集群能夠根據(jù)計(jì)算能力、任務(wù)計(jì)算強(qiáng)度及優(yōu)先級,在異構(gòu)GPU集群上合理分配計(jì)算資源。劉夢青等[19]針對Storm集群難以將節(jié)點(diǎn)資源與任務(wù)需求結(jié)合等問題,提出了一種基于蟻群算法的資源感知任務(wù)調(diào)度方式,達(dá)到了集群負(fù)載均衡、性能優(yōu)化的目的。高原等[20]提出一種支持異構(gòu)集群的CPU與GPU協(xié)同計(jì)算的全局和節(jié)點(diǎn)兩級動(dòng)態(tài)調(diào)度算法,該算法的核心思想是“能者多勞”,依據(jù)各節(jié)點(diǎn)的計(jì)算能力與作業(yè)請求動(dòng)態(tài)分發(fā)數(shù)據(jù)。

2 對異構(gòu)資源的擴(kuò)展與統(tǒng)一調(diào)度

2.1 YARN資源管理模型的不足

原生YARN的資源監(jiān)測與管理存在以下兩方面問題。

問題一是YARN對資源的管理是邏輯上的,并沒有做實(shí)際資源的管理。用戶在配置文件中對各節(jié)點(diǎn)的內(nèi)存、CPU核數(shù)資源進(jìn)行配置,YARN讀取后得出初始資源總量,在任務(wù)調(diào)度時(shí)對資源做邏輯上的增減。這種設(shè)計(jì)在集群僅用來執(zhí)行YARN所分配的任務(wù)時(shí)是合理的,然而在復(fù)雜環(huán)境下卻可能出現(xiàn)問題。例如,用戶在一個(gè)節(jié)點(diǎn)上未經(jīng)過YARN調(diào)度開啟了一個(gè)進(jìn)程,占用了該節(jié)點(diǎn)大量資源,但YARN并不知情,在分配任務(wù)時(shí)依舊認(rèn)為該節(jié)點(diǎn)具有足夠的資源而為其指派任務(wù),最終導(dǎo)致任務(wù)執(zhí)行緩慢甚至失敗。

問題二是對GPU等異構(gòu)資源的管理粒度過粗。YARN本身只支持內(nèi)存與CPU的管理調(diào)度,雖然在Hadoop3版本中YARN新增了對GPU與FPGA的支持,但是粒度卻非常粗。例如,一個(gè)任務(wù)需要使用GPU資源,YARN會將一整塊GPU資源分配給該任務(wù),無法使多個(gè)任務(wù)使用同一塊GPU進(jìn)行計(jì)算,這會導(dǎo)致很大程度的資源浪費(fèi)。

2.2 資源模型的雙重表示

為了能夠?qū)Ξ悩?gòu)資源進(jìn)行更加細(xì)化的監(jiān)測與管理,提高任務(wù)調(diào)度分配的合理性與高效性。選擇將資源狀態(tài)從實(shí)際資源狀態(tài)與邏輯資源狀態(tài)2個(gè)方面進(jìn)行表示,主節(jié)點(diǎn)進(jìn)程將這2種狀態(tài)分別進(jìn)行記錄與更新。實(shí)際資源狀態(tài)可看作一種動(dòng)態(tài)的表示,是集群中實(shí)際在用的資源狀態(tài),由各子節(jié)點(diǎn)的資源匯報(bào)進(jìn)程匯總得出;邏輯資源狀態(tài)可看作一種靜態(tài)的表示,在用戶提交任務(wù)時(shí)需要提供所需最小資源參數(shù),將所有任務(wù)的最小資源之和作為當(dāng)前已使用的邏輯資源。

這樣劃分的原因是充分利用YARN的資源彈性分配機(jī)制,例如,當(dāng)一個(gè)隊(duì)列剩余50 G內(nèi)存資源,資源彈性限度為100%,一個(gè)任務(wù)需要20 G,則YARN會先將50 G資源全部分配給該任務(wù);第2個(gè)任務(wù)需要20 G內(nèi)存,YARN則會釋放一部分任務(wù)一的資源,為任務(wù)一與任務(wù)二各分配25 G內(nèi)存。在此前提下,如果僅以集群的實(shí)際資源使用狀況為標(biāo)準(zhǔn)進(jìn)行任務(wù)調(diào)度的判斷是不合理的,因?yàn)樵陂_啟資源彈性分配并且設(shè)置出讓資源比例較大的情況下,在有任務(wù)運(yùn)行時(shí),大部分情況下隊(duì)列資源顯示都是近乎滿負(fù)載,然而用戶卻無法判斷任務(wù)提交至隊(duì)列后是否能夠立即分到資源進(jìn)行運(yùn)算;如果關(guān)閉資源彈性分配機(jī)制,則會很大程度造成資源浪費(fèi)(例如剩余50 G內(nèi)存,一個(gè)任務(wù)需要20 G,則只分配給它20 G,浪費(fèi)了剩余的30 G資源)。

因此,設(shè)置一個(gè)邏輯資源使用狀態(tài)作為任務(wù)調(diào)度的標(biāo)準(zhǔn),當(dāng)一個(gè)新任務(wù)添加到隊(duì)列后,先從邏輯層面判斷隊(duì)列是否滿足所有任務(wù)的最低資源標(biāo)準(zhǔn),如果滿足則說明隊(duì)列可以出讓足夠多的資源滿足新任務(wù)的需求,新任務(wù)可以被添加到該隊(duì)列,否則說明該隊(duì)列資源不足。

2.3 對異構(gòu)資源的擴(kuò)展與管理

為了實(shí)現(xiàn)對異構(gòu)資源的靈活擴(kuò)展與資源實(shí)際使用情況的監(jiān)測,選擇使用Linux資源監(jiān)控命令實(shí)現(xiàn)。Linux系統(tǒng)自帶了多種資源監(jiān)控命令,以幫助用戶進(jìn)行系統(tǒng)性能的查看與分析。例如,使用cat/proc/meminfo命令可以獲取當(dāng)前的內(nèi)存使用情況,而使用cat/proc/stat命令可以獲取本機(jī)的CPU使用情況。對于GPU資源來說,以最常使用的NVIDIA系列為例,在安裝完驅(qū)動(dòng)之后,可以使用nvidia-smi命令實(shí)現(xiàn)對本機(jī)所有顯卡使用情況的監(jiān)控。

為了實(shí)現(xiàn)異構(gòu)資源的隔離與管理,使用物理標(biāo)注的方法,為掛載不同計(jì)算資源的機(jī)器打上不同的標(biāo)簽,并依據(jù)標(biāo)簽將集群劃分為幾個(gè)不同的邏輯集群。例如,Node1上不包含任何計(jì)算加速部件,則為Node1打上normal標(biāo)簽,標(biāo)識該節(jié)點(diǎn)只能負(fù)責(zé)運(yùn)行無需加速的普通批處理與實(shí)時(shí)計(jì)算任務(wù);如果Node2上加掛了GPU與FPGA,則可以為該節(jié)點(diǎn)打上normal、分布式機(jī)器學(xué)習(xí)和分布式深度學(xué)習(xí)標(biāo)簽,表示該節(jié)點(diǎn)可以負(fù)責(zé)運(yùn)行批處理計(jì)算、實(shí)時(shí)計(jì)算任務(wù)、機(jī)器學(xué)習(xí)任務(wù)和深度學(xué)習(xí)任務(wù)。

設(shè)定了標(biāo)簽之后,整個(gè)集群中的節(jié)點(diǎn)根據(jù)能夠處理的任務(wù)被劃分成了幾個(gè)邏輯集群。每個(gè)節(jié)點(diǎn)可以同時(shí)隸屬于多個(gè)邏輯集群,每個(gè)邏輯集群用于處理一類計(jì)算任務(wù)。在Resource Manager內(nèi)部使用隊(duì)列來抽象表示整個(gè)集群的資源。為了讓需要加速的作業(yè)被提交到具有相應(yīng)加速器的邏輯集群中,可以按照作業(yè)的類型,在Resource Manager上將整個(gè)集群資源組織到幾個(gè)隊(duì)列中,并為每個(gè)隊(duì)列設(shè)置標(biāo)簽。利用YARN的基于標(biāo)簽的調(diào)度算法,提交到某個(gè)隊(duì)列中的作業(yè)只能被調(diào)度到具有與隊(duì)列標(biāo)簽相同標(biāo)簽的節(jié)點(diǎn)上運(yùn)行。資源隊(duì)列的劃分即是邏輯集群的劃分,Resource Manager根據(jù)Node Manager標(biāo)簽將其歸入到邏輯集群中。圖1為一組標(biāo)簽劃分示例。

圖1 邏輯集群標(biāo)簽劃分示例

2.4 資源管理模塊

本文中設(shè)計(jì)了一種主從結(jié)構(gòu)的集群資源管理系統(tǒng),以實(shí)現(xiàn)對分布式計(jì)算節(jié)點(diǎn)的資源監(jiān)控及管理。系統(tǒng)使用Socket技術(shù)實(shí)現(xiàn)集群節(jié)點(diǎn)間的通信,Master節(jié)點(diǎn)負(fù)責(zé)維護(hù)集群可用節(jié)點(diǎn)信息、收集各Slave節(jié)點(diǎn)實(shí)際資源信息并更新集群整體資源;Slave節(jié)點(diǎn)負(fù)責(zé)采集本節(jié)點(diǎn)實(shí)際資源信息并上報(bào)給Master。資源管理模塊運(yùn)行流程如圖2所示。

圖2 資源管理模塊運(yùn)行流程

詳細(xì)的運(yùn)行流程如下：

步驟1首先啟動(dòng)主程序上的資源管理線程,指定端口開啟資源管理服務(wù),等待子節(jié)點(diǎn)的連接,并維護(hù)已有的連接,定時(shí)從各子節(jié)點(diǎn)獲取資源信息并更新。

步驟2啟動(dòng)各個(gè)子節(jié)點(diǎn)程序,向主節(jié)點(diǎn)的資源管理端口發(fā)送連接請求。

步驟3主節(jié)點(diǎn)資源管理服務(wù)接收到各子節(jié)點(diǎn)發(fā)來的連接請求,將其加入連接列表中進(jìn)行維護(hù)。

步驟4若主節(jié)點(diǎn)連接列表中的連接數(shù)大于0,則循環(huán)列表中的連接,向?qū)?yīng)子節(jié)點(diǎn)發(fā)送匯報(bào)信息命令。

步驟5子節(jié)點(diǎn)接收到匯報(bào)信息命令,統(tǒng)計(jì)自身的資源信息,報(bào)告給主節(jié)點(diǎn),進(jìn)入資源狀態(tài)。

步驟6主節(jié)點(diǎn)接收到各子節(jié)點(diǎn)的匯報(bào)信息,更新集群資源狀態(tài)。

步驟7休息指定的間隔時(shí)間,跳轉(zhuǎn)至步驟4。

3 分布式任務(wù)調(diào)度算法的改進(jìn)

3.1 YARN的內(nèi)置調(diào)度算法介紹

YARN內(nèi)置了3種任務(wù)調(diào)度算法：FIFO調(diào)度算法、Fair調(diào)度算法、Capacity調(diào)度算法。FIFO調(diào)度算法將所有任務(wù)按照優(yōu)先級提交至對應(yīng)的隊(duì)列中,然后按照作業(yè)提交的順序執(zhí)行,該策略實(shí)現(xiàn)簡單,調(diào)度開銷小,但是會導(dǎo)致某些小作業(yè)為了執(zhí)行而等待大量時(shí)間和低優(yōu)先級隊(duì)列可能長時(shí)間阻塞等問題;Fair調(diào)度算法以隊(duì)列為單位劃分資源,在隊(duì)列內(nèi)可以選擇以接近相等的比例將資源分配給隊(duì)列中的任務(wù),該策略考慮為后來任務(wù)出讓資源,適合有大量Hive Sql等小任務(wù)的業(yè)務(wù)場景,然而對于各節(jié)點(diǎn)的實(shí)際負(fù)載能力及節(jié)點(diǎn)間的性能差異缺乏考慮;Capacity調(diào)度算法也是基于隊(duì)列劃分的思想,用戶可以對每個(gè)隊(duì)列進(jìn)行使用權(quán)限、資源限制與共享等定制化配置,實(shí)現(xiàn)不同類型任務(wù)各自的最低資源保證,同時(shí)擁有一定的資源共享靈活性,然而用戶在提交任務(wù)時(shí)需要人為指定隊(duì)列,隊(duì)列的參數(shù)配置需要反復(fù)研究調(diào)整,同時(shí)在某一隊(duì)列長期處于任務(wù)饑餓狀態(tài)時(shí)仍存在一定程度的資源浪費(fèi)問題。

3.2 基于Capacity調(diào)度策略改進(jìn)的任務(wù)調(diào)度算法

本文中提出一種針對任務(wù)調(diào)度算法的改進(jìn)方案,在Capacity調(diào)度策略的基礎(chǔ)上,根據(jù)節(jié)點(diǎn)計(jì)算資源的不同進(jìn)行標(biāo)簽的標(biāo)注,將不同標(biāo)簽的節(jié)點(diǎn)劃分至指定隊(duì)列以實(shí)現(xiàn)異構(gòu)資源的隔離管理;任務(wù)的調(diào)度管理交由平臺實(shí)現(xiàn),用戶使用統(tǒng)一的提交格式,提交時(shí)只需指定任務(wù)的類型而無需指定隊(duì)列,平臺根據(jù)集群的實(shí)時(shí)資源情況進(jìn)行任務(wù)的分配執(zhí)行、隊(duì)列切換等操作。詳細(xì)的調(diào)度算法流程如下,其流程如圖3所示。

圖3 基于Capacity調(diào)度策略改進(jìn)的任務(wù)調(diào)度算法流程

步驟1若當(dāng)前有新的任務(wù)提交或者已提交的任務(wù)結(jié)束時(shí),進(jìn)入調(diào)度算法環(huán)節(jié)。

步驟2若是新任務(wù)提交,則執(zhí)行步驟3;若是任務(wù)執(zhí)行結(jié)束,則對整體的資源進(jìn)行重新分配,使其達(dá)到隊(duì)列內(nèi)部最優(yōu)分配,最優(yōu)分配算法如式(1)、式(2)所示。

(1)

(2)

式中：N表示當(dāng)前隊(duì)列的中正在運(yùn)行的作業(yè)數(shù)量之和;Taski表示當(dāng)前隊(duì)列中第i個(gè)作業(yè);CoresLeft與MemLeft分別表示當(dāng)前隊(duì)列剩余可用的線程核心數(shù)與剩余可用內(nèi)存大小;executorCoreNum與executorMem分別表示每個(gè)executor需要的核心數(shù)量與內(nèi)存大小;AddedCoresTaski與AddedMemTaski分別表示當(dāng)前隊(duì)列中第i個(gè)作業(yè)可分配的核心數(shù)與內(nèi)存;AddedTaski表示當(dāng)前隊(duì)列中第i個(gè)作業(yè)核心數(shù)與內(nèi)存可分配的比例數(shù);ActualCoresTaski表示當(dāng)前隊(duì)列中第i個(gè)作業(yè)實(shí)際分配的核心數(shù),其等于當(dāng)前作業(yè)需要的邏輯核心數(shù)加上當(dāng)前作業(yè)分配比例數(shù)與當(dāng)前作業(yè)單個(gè)executor的需要的核心數(shù)量之積;ActualMemTaski表示當(dāng)前隊(duì)列中第i個(gè)作業(yè)的實(shí)際內(nèi)存分配大小,其等于當(dāng)前作業(yè)需要的邏輯內(nèi)存加上當(dāng)前作業(yè)分配比例數(shù)與當(dāng)前作業(yè)單個(gè)executor需要的內(nèi)存之積。

而式(2)中的ActualCoresSortCoreNeeded(Task)1與ActualCoresSortMemNeeded(Task)1本質(zhì)上是對剩余邏輯資源的二次分配。SortCoreNeeded(Task)1表示當(dāng)前所有任務(wù)需要的邏輯核心數(shù)量從大到小排序后的第一個(gè)作業(yè);SortMemNeeded(Task)1表示當(dāng)前所有任務(wù)需要的邏輯內(nèi)存從大到小排序后的第一個(gè)作業(yè);ActualCoresSortCoreNeeded(Task)1表示當(dāng)前SortCoreNeeded(Task)1作業(yè)的實(shí)際分配核心數(shù)大小,其等于實(shí)際分配的核心數(shù)與剩余核心數(shù)之和;ActualCoresSortMemNeeded(Task)1表示當(dāng)前SortMemNeeded(Task)1作業(yè)的實(shí)際分配內(nèi)存大小,其等于實(shí)際分配的內(nèi)存與剩余內(nèi)存之和。

步驟3用戶按照指定的格式提交任務(wù)命令至異構(gòu)資源下分布式深度學(xué)習(xí)框架整合平臺。

步驟4平臺進(jìn)行任務(wù)命令解析,根據(jù)任務(wù)的標(biāo)簽進(jìn)行最優(yōu)隊(duì)列匹配,分配任務(wù)到指定隊(duì)列(例如deep-learning隊(duì)列主要負(fù)責(zé)GPU類型的任務(wù)、batch-process隊(duì)列主要負(fù)責(zé)CPU類型的任務(wù))。

步驟5判斷當(dāng)前隊(duì)列的邏輯資源是否足夠支撐該任務(wù)(見式(3)),若支撐,則對當(dāng)前隊(duì)列的資源進(jìn)行全局最優(yōu)分配并執(zhí)行任務(wù)命令,結(jié)束;反之,則進(jìn)入步驟4。

(3)

式中：CoreNeeded表示當(dāng)前任務(wù)需要的線程核心數(shù);CoreLeft表示當(dāng)前隊(duì)列剩余可用的線程核心數(shù);MemNeeded表示當(dāng)前任務(wù)需要的內(nèi)存大小;MemLeft表示當(dāng)前隊(duì)列剩余可用的內(nèi)存大小;VideoMemTotal表示當(dāng)前隊(duì)列中的GPU的總內(nèi)存大小;VideoMemNeeded表示當(dāng)前任務(wù)需要的GPU內(nèi)存大小;VideoMemLeft表示當(dāng)前隊(duì)列剩余可用的GPU內(nèi)存大小。

步驟6若當(dāng)前任務(wù)標(biāo)簽為CPU類型任務(wù),則檢測deep-learning隊(duì)列是否還存在閑置資源,若存在,將當(dāng)前任務(wù)轉(zhuǎn)至deep-learning隊(duì)列執(zhí)行任務(wù)命令;若當(dāng)前任務(wù)標(biāo)簽為GPU類型任務(wù),則進(jìn)入等待隊(duì)列,等待deep-learning隊(duì)列中任務(wù)結(jié)束,釋放資源,進(jìn)而執(zhí)行命令。

本文調(diào)度算法的優(yōu)點(diǎn)在于能夠借助平臺對異構(gòu)資源整合與資源模型進(jìn)行雙重表示的優(yōu)勢,能夠?qū)悩?gòu)資源的調(diào)度分配達(dá)到最優(yōu)。例如,當(dāng)batch-process隊(duì)列的資源全部被占用,平臺會去檢測deep-learning隊(duì)列是否存在閑置資源,將當(dāng)前的任務(wù)分發(fā)到deep-learning隊(duì)列,從而充分利用集群資源,極大地提高了批處理任務(wù)的效率。

4 實(shí)驗(yàn)

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

本文實(shí)驗(yàn)環(huán)境是基于實(shí)驗(yàn)室現(xiàn)有的4臺服務(wù)器搭建的,詳細(xì)的配置信息如下：操作系統(tǒng)為Linux,內(nèi)存2 G以上;集群組件版本為Hadoop2.7、Spark2.7.7、JDK1.8、Python3.6。集群節(jié)點(diǎn)、隊(duì)列信息如表1、表2所示。

表1 集群節(jié)點(diǎn)信息配置

表2 集群隊(duì)列信息

為了保證實(shí)驗(yàn)的可靠性,選取經(jīng)典的詞頻統(tǒng)計(jì)WordCount與手寫數(shù)字識別minist_spark作為實(shí)驗(yàn)的任務(wù)對象,并選用任務(wù)群的整體執(zhí)行時(shí)間作為評價(jià)指標(biāo)。

4.2 實(shí)驗(yàn)結(jié)果與分析

算法性能的提升往往通過任務(wù)執(zhí)行時(shí)間來體現(xiàn),任務(wù)執(zhí)行時(shí)間是判斷異構(gòu)資源分布式深度學(xué)習(xí)平臺的一個(gè)關(guān)鍵性指標(biāo)。調(diào)度算法性能的優(yōu)越性在于能夠?yàn)槎鄠€(gè)任務(wù)進(jìn)行CPU或GPU資源合理分配,使資源的利用率達(dá)到最大,降低整體任務(wù)群的執(zhí)行時(shí)間。

為了證明基于Capacity調(diào)度策略改進(jìn)的任務(wù)調(diào)度算法的適用性與優(yōu)越性,選取5個(gè)WordCount任務(wù)與5個(gè)minist_spark作為一個(gè)任務(wù)群進(jìn)行實(shí)驗(yàn)。其中,minist_spark是基于GPU資源的手寫數(shù)字集識別任務(wù);WordCount是基于CPU資源的詞頻統(tǒng)計(jì)任務(wù)。實(shí)驗(yàn)詳細(xì)步驟如下。

步驟1利用隨機(jī)算法對任務(wù)群進(jìn)行隨機(jī)排序組合,生成各個(gè)子任務(wù)的執(zhí)行順序。

步驟2按照排列后的順序分別基于本地Capacity調(diào)度算法與基于Capacity調(diào)度策略改進(jìn)的任務(wù)調(diào)度算法(NewCapacity)執(zhí)行任務(wù)。

步驟3重復(fù)3次步驟1、步驟2,求在不同調(diào)度算法下任務(wù)執(zhí)行時(shí)間的平均值。

通過圖4可知,在CPU與GPU類型任務(wù)混合場景下,基于Capacity調(diào)度策略改進(jìn)的任務(wù)調(diào)度算法NewCapacity的性能普遍優(yōu)于集群默認(rèn)的Capacity調(diào)度算法。NewCapacity相對于Capacity調(diào)度算法,在該混合任務(wù)場景下,平均耗時(shí)降低了13.4%。

圖4 WordCount與minist_spark混合場景下的調(diào)度算法性能

為了證明NewCapacity在批處理場景下能夠提高集群資源的利用率,解決集群資源空轉(zhuǎn)問題,選用WordCount作為實(shí)驗(yàn)任務(wù),不斷提高任務(wù)的作業(yè)量,對比Capacity與NewCapacity的整體執(zhí)行時(shí)間消耗情況,并對該過程中每組任務(wù)群進(jìn)行8次重復(fù)實(shí)驗(yàn),利用箱線圖分析法去掉異常值,最后取實(shí)驗(yàn)數(shù)據(jù)的平均值,詳細(xì)的實(shí)驗(yàn)數(shù)據(jù)如圖5、圖6所示。

圖6 基于WordCount的時(shí)間消耗曲線

通過圖5、圖6可知,NewCapacity調(diào)度算法在時(shí)間消耗上基本優(yōu)于Capacity調(diào)度算法,并且隨著批處理任務(wù)的作業(yè)量的不斷遞增,NewCapacity調(diào)度算法相對于YARN默認(rèn)的Capacity調(diào)度算法的執(zhí)行時(shí)間將逐步降低,尤其是在作業(yè)量為60時(shí),執(zhí)行耗時(shí)降低了32.31%?？梢宰C明,NewCapacity調(diào)度算法相對于Capacity調(diào)度算法,進(jìn)一步降低了spark集群的資源空轉(zhuǎn),極大提高了集群資源的利用率。

通過實(shí)驗(yàn)可知,在有大批量的批處理任務(wù)、少量的deep-learning任務(wù)的場景下,當(dāng)batch-process隊(duì)列的可用資源不充足時(shí),借助平臺對異構(gòu)資源集中管理的優(yōu)勢,平臺改進(jìn)的調(diào)度算法就會調(diào)用deep-learning隊(duì)列中閑置的資源,使其資源利用最大化。

5 結(jié)束語

針對異構(gòu)資源管理能力弱、原生調(diào)度算法靈活性差、多框架缺少統(tǒng)一的使用接口3個(gè)問題,提出了一種異構(gòu)資源下分布式深度學(xué)習(xí)框架整合平臺,以Spark框架為基礎(chǔ),整合了SparkOnAngel與TensorFlowOnSpark 2種框架,為用戶提供了統(tǒng)一的命令模板接口;在YARN原有的Capacity調(diào)度算法基礎(chǔ)上進(jìn)行優(yōu)化,利用平臺對集群資源管理的靈活性,對集群整體資源進(jìn)行了靈活分配,對deep-learning隊(duì)列的閑置資源進(jìn)行合理高效的利用。針對存在大量批處理任務(wù)的場景,集群整體資源能夠被充分調(diào)度,相對于傳統(tǒng)的集群調(diào)度算法,性能有較大提升。

目前該平臺能夠處理CPU與GPU資源的調(diào)度,已經(jīng)適應(yīng)了絕大多數(shù)場景下的應(yīng)用,接下來還需要探索其他類型資源的調(diào)度和整合問題,如嵌入式場景的多任務(wù)資源管理。