異構分布式深度學習平臺的構建和優化方法研究

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

(1.北京信息科技大學 智能信息處理研究所, 北京 100101;2.國家經濟安全預警工程北京實驗室, 北京 100044;3.東北師范大學 文學院, 長春 130022)

0 引言

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

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

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

針對上述問題,本文中提出了一種異構資源下分布式機器學習框架整合平臺,以Spark框架為基礎,向下對異構資源進行拓展與管理,向上整合了SparkOnAngel與TensorFlowOnSpark 2種框架,對任務調度算法進行優化,并封裝一套統一的使用接口以方便用戶的調用。

1 研究現狀

1.1 異構計算平臺

近年來,各類不同體系架構的計算設備(如GPU、FPGA等)逐漸被引入大數據平臺中,研究人員設計策略與算法,使得平臺能夠實現對異構資源的管理,并根據設備特點為其分配不同任務[5],以達到優勢互補的目的。

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

1.2 資源管理與分配

隨著異構計算環境的增多,許多學者開始研究如何對這些資源進行管理與分配,以解決異構資源計算能力不同可能帶來的計算資源浪費問題。

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

1.3 大數據框架下的任務調度策略

當前的大數據集群一般采用YARN完成任務的調度工作,YARN內部有FIFO、FAIR、Capaciy 3種任務調度策略,雖然這些策略具有通用性,但仍有進一步優化的空間。

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

2 對異構資源的擴展與統一調度

2.1 YARN資源管理模型的不足

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

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

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

2.2 資源模型的雙重表示

為了能夠對異構資源進行更加細化的監測與管理,提高任務調度分配的合理性與高效性。選擇將資源狀態從實際資源狀態與邏輯資源狀態2個方面進行表示,主節點進程將這2種狀態分別進行記錄與更新。實際資源狀態可看作一種動態的表示,是集群中實際在用的資源狀態,由各子節點的資源匯報進程匯總得出;邏輯資源狀態可看作一種靜態的表示,在用戶提交任務時需要提供所需最小資源參數,將所有任務的最小資源之和作為當前已使用的邏輯資源。

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

因此,設置一個邏輯資源使用狀態作為任務調度的標準,當一個新任務添加到隊列后,先從邏輯層面判斷隊列是否滿足所有任務的最低資源標準,如果滿足則說明隊列可以出讓足夠多的資源滿足新任務的需求,新任務可以被添加到該隊列,否則說明該隊列資源不足。

2.3 對異構資源的擴展與管理

為了實現對異構資源的靈活擴展與資源實際使用情況的監測,選擇使用Linux資源監控命令實現。Linux系統自帶了多種資源監控命令,以幫助用戶進行系統性能的查看與分析。例如,使用cat/proc/meminfo命令可以獲取當前的內存使用情況,而使用cat/proc/stat命令可以獲取本機的CPU使用情況。對于GPU資源來說,以最常使用的NVIDIA系列為例,在安裝完驅動之后,可以使用nvidia-smi命令實現對本機所有顯卡使用情況的監控。

為了實現異構資源的隔離與管理,使用物理標注的方法,為掛載不同計算資源的機器打上不同的標簽,并依據標簽將集群劃分為幾個不同的邏輯集群。例如,Node1上不包含任何計算加速部件,則為Node1打上normal標簽,標識該節點只能負責運行無需加速的普通批處理與實時計算任務;如果Node2上加掛了GPU與FPGA,則可以為該節點打上normal、分布式機器學習和分布式深度學習標簽,表示該節點可以負責運行批處理計算、實時計算任務、機器學習任務和深度學習任務。

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

圖1 邏輯集群標簽劃分示例

2.4 資源管理模塊

本文中設計了一種主從結構的集群資源管理系統,以實現對分布式計算節點的資源監控及管理。系統使用Socket技術實現集群節點間的通信,Master節點負責維護集群可用節點信息、收集各Slave節點實際資源信息并更新集群整體資源;Slave節點負責采集本節點實際資源信息并上報給Master。資源管理模塊運行流程如圖2所示。

圖2 資源管理模塊運行流程

詳細的運行流程如下：

步驟1首先啟動主程序上的資源管理線程,指定端口開啟資源管理服務,等待子節點的連接,并維護已有的連接,定時從各子節點獲取資源信息并更新。

步驟2啟動各個子節點程序,向主節點的資源管理端口發送連接請求。

步驟3主節點資源管理服務接收到各子節點發來的連接請求,將其加入連接列表中進行維護。

步驟4若主節點連接列表中的連接數大于0,則循環列表中的連接,向對應子節點發送匯報信息命令。

步驟5子節點接收到匯報信息命令,統計自身的資源信息,報告給主節點,進入資源狀態。

步驟6主節點接收到各子節點的匯報信息,更新集群資源狀態。

步驟7休息指定的間隔時間,跳轉至步驟4。

3 分布式任務調度算法的改進

3.1 YARN的內置調度算法介紹

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

3.2 基于Capacity調度策略改進的任務調度算法

本文中提出一種針對任務調度算法的改進方案,在Capacity調度策略的基礎上,根據節點計算資源的不同進行標簽的標注,將不同標簽的節點劃分至指定隊列以實現異構資源的隔離管理;任務的調度管理交由平臺實現,用戶使用統一的提交格式,提交時只需指定任務的類型而無需指定隊列,平臺根據集群的實時資源情況進行任務的分配執行、隊列切換等操作。詳細的調度算法流程如下,其流程如圖3所示。

圖3 基于Capacity調度策略改進的任務調度算法流程

步驟1若當前有新的任務提交或者已提交的任務結束時,進入調度算法環節。

步驟2若是新任務提交,則執行步驟3;若是任務執行結束,則對整體的資源進行重新分配,使其達到隊列內部最優分配,最優分配算法如式(1)、式(2)所示。

(1)

(2)

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

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

步驟3用戶按照指定的格式提交任務命令至異構資源下分布式深度學習框架整合平臺。

步驟4平臺進行任務命令解析,根據任務的標簽進行最優隊列匹配,分配任務到指定隊列(例如deep-learning隊列主要負責GPU類型的任務、batch-process隊列主要負責CPU類型的任務)。

步驟5判斷當前隊列的邏輯資源是否足夠支撐該任務(見式(3)),若支撐,則對當前隊列的資源進行全局最優分配并執行任務命令,結束;反之,則進入步驟4。

(3)

式中：CoreNeeded表示當前任務需要的線程核心數;CoreLeft表示當前隊列剩余可用的線程核心數;MemNeeded表示當前任務需要的內存大小;MemLeft表示當前隊列剩余可用的內存大小;VideoMemTotal表示當前隊列中的GPU的總內存大小;VideoMemNeeded表示當前任務需要的GPU內存大小;VideoMemLeft表示當前隊列剩余可用的GPU內存大小。

步驟6若當前任務標簽為CPU類型任務,則檢測deep-learning隊列是否還存在閑置資源,若存在,將當前任務轉至deep-learning隊列執行任務命令;若當前任務標簽為GPU類型任務,則進入等待隊列,等待deep-learning隊列中任務結束,釋放資源,進而執行命令。

本文調度算法的優點在于能夠借助平臺對異構資源整合與資源模型進行雙重表示的優勢,能夠將異構資源的調度分配達到最優。例如,當batch-process隊列的資源全部被占用,平臺會去檢測deep-learning隊列是否存在閑置資源,將當前的任務分發到deep-learning隊列,從而充分利用集群資源,極大地提高了批處理任務的效率。

4 實驗

4.1 實驗環境

本文實驗環境是基于實驗室現有的4臺服務器搭建的,詳細的配置信息如下：操作系統為Linux,內存2 G以上;集群組件版本為Hadoop2.7、Spark2.7.7、JDK1.8、Python3.6。集群節點、隊列信息如表1、表2所示。

表1 集群節點信息配置

表2 集群隊列信息

為了保證實驗的可靠性,選取經典的詞頻統計WordCount與手寫數字識別minist_spark作為實驗的任務對象,并選用任務群的整體執行時間作為評價指標。

4.2 實驗結果與分析

算法性能的提升往往通過任務執行時間來體現,任務執行時間是判斷異構資源分布式深度學習平臺的一個關鍵性指標。調度算法性能的優越性在于能夠為多個任務進行CPU或GPU資源合理分配,使資源的利用率達到最大,降低整體任務群的執行時間。

為了證明基于Capacity調度策略改進的任務調度算法的適用性與優越性,選取5個WordCount任務與5個minist_spark作為一個任務群進行實驗。其中,minist_spark是基于GPU資源的手寫數字集識別任務;WordCount是基于CPU資源的詞頻統計任務。實驗詳細步驟如下。

步驟1利用隨機算法對任務群進行隨機排序組合,生成各個子任務的執行順序。

步驟2按照排列后的順序分別基于本地Capacity調度算法與基于Capacity調度策略改進的任務調度算法(NewCapacity)執行任務。

步驟3重復3次步驟1、步驟2,求在不同調度算法下任務執行時間的平均值。

通過圖4可知,在CPU與GPU類型任務混合場景下,基于Capacity調度策略改進的任務調度算法NewCapacity的性能普遍優于集群默認的Capacity調度算法。NewCapacity相對于Capacity調度算法,在該混合任務場景下,平均耗時降低了13.4%。

圖4 WordCount與minist_spark混合場景下的調度算法性能

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

圖6 基于WordCount的時間消耗曲線

通過圖5、圖6可知,NewCapacity調度算法在時間消耗上基本優于Capacity調度算法,并且隨著批處理任務的作業量的不斷遞增,NewCapacity調度算法相對于YARN默認的Capacity調度算法的執行時間將逐步降低,尤其是在作業量為60時,執行耗時降低了32.31%。可以證明,NewCapacity調度算法相對于Capacity調度算法,進一步降低了spark集群的資源空轉,極大提高了集群資源的利用率。

通過實驗可知,在有大批量的批處理任務、少量的deep-learning任務的場景下,當batch-process隊列的可用資源不充足時,借助平臺對異構資源集中管理的優勢,平臺改進的調度算法就會調用deep-learning隊列中閑置的資源,使其資源利用最大化。

5 結束語

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

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