楊振宇 呂 敏 李永坤

(中國科學(xué)技術(shù)大學(xué)計算機(jī)科學(xué)與技術(shù)學(xué)院 合肥 230026)

1 引 言

在主流的分布式存儲系統(tǒng)中，為了保證數(shù)據(jù)的可靠性，往往采用多副本方式將原始數(shù)據(jù)的多個備份存儲在不同節(jié)點(diǎn)或設(shè)備上以達(dá)到容錯要求。但隨著互聯(lián)網(wǎng)數(shù)據(jù)的爆發(fā)式增長[1]，相較于原始數(shù)據(jù)量，多副本方式產(chǎn)生的存儲開銷成倍數(shù)增長，這已成為不可忽視的問題。當(dāng)前，越來越多的分布式存儲系統(tǒng)[2-3]開始引入糾刪碼機(jī)制[4]來保證系統(tǒng)的可靠性。糾刪碼通過將原始數(shù)據(jù)進(jìn)行條帶分組和編碼來得到冗余的校驗單元，并將整個條帶的數(shù)據(jù)單元和校驗單元分散放置在不同節(jié)點(diǎn)，在保證系統(tǒng)容錯需求的同時，其存儲開銷大大降低。然而，糾刪碼機(jī)制的引入改變了數(shù)據(jù)的組織方式，對上層業(yè)務(wù)的數(shù)據(jù)訪問產(chǎn)生了新的影響。圖 1(a)展示了 Hadoop 分布式文件系統(tǒng)(Hadoop Distributed File System，HDFS)3.x 版本[3]中條帶式糾刪碼存儲模式下的數(shù)據(jù)放置[5]，與圖 1(b)所示的 HDFS 在三副本存儲模式下的數(shù)據(jù)放置相比：糾刪碼模式在保留 HDFS 數(shù)據(jù)塊劃分的同時，將原始文件進(jìn)行了更細(xì)粒度的劃分以進(jìn)行條帶編碼；在副本模式下，一個數(shù)據(jù)塊一般對應(yīng)原始文件連續(xù)的一部分(數(shù)據(jù)塊大小可進(jìn)行配置)，而在糾刪碼模式下，一個數(shù)據(jù)塊中的內(nèi)容則對應(yīng)原始文件中一段段不連續(xù)的數(shù)據(jù)。

圖1 HDFS 三副本與 RS-(6,3)糾刪碼存儲模式下的數(shù)據(jù)布局示意圖Fig. 1 Data layouts of replication storage mode and RS-(6,3) erasure-coded storage mode in HDFS

條帶式糾刪碼的數(shù)據(jù)布局直接影響上層業(yè)務(wù)的數(shù)據(jù)訪問。以 Hadoop 基礎(chǔ)架構(gòu)下 MapReduce應(yīng)用的數(shù)據(jù)處理流程為例，MapReduce 將計算任務(wù)分為 Map 和 Reduce 兩個階段，在 Map 階段并發(fā)地執(zhí)行多個 Map 任務(wù)來對數(shù)據(jù)集進(jìn)行訪問和處理，每個 Map 任務(wù)處理原始數(shù)據(jù)集中連續(xù)的一部分。在 HDFS 三副本存儲模式下，為了實(shí)現(xiàn)“計算向數(shù)據(jù)靠攏”的目的，每個 Map 任務(wù)處理的數(shù)據(jù)量默認(rèn)與數(shù)據(jù)塊大小保持一致，以盡可能減少計算任務(wù)所在節(jié)點(diǎn)向其他多個節(jié)點(diǎn)請求數(shù)據(jù)的情況。而在以圖 1(a)為例的 RS-(6,3)糾刪碼存儲模式下，一個 Map 任務(wù)需要獲取的數(shù)據(jù)對應(yīng)分布在整個條帶的所有數(shù)據(jù)塊節(jié)點(diǎn)上，計算節(jié)點(diǎn)不可避免地要從多個存儲節(jié)點(diǎn)訪問所需要的數(shù)據(jù)。在大多數(shù)情況下，集群各節(jié)點(diǎn)的硬件設(shè)備(磁盤、網(wǎng)絡(luò)帶寬、內(nèi)存容量等)存在異構(gòu)情況，集群各節(jié)點(diǎn)運(yùn)行時的負(fù)載狀況也不盡相同。因此，當(dāng) Map 任務(wù)在訪問糾刪碼存儲模式下的數(shù)據(jù)時，節(jié)點(diǎn)性能差異導(dǎo)致的數(shù)據(jù)傳輸性能波動將會極大地影響任務(wù)的運(yùn)行效率。如圖 2 所示，結(jié)合表 1 的相關(guān)度量指標(biāo)，相較于三副本存儲模式，在糾刪碼存儲模式下上層運(yùn)行的 Map 任務(wù)呈現(xiàn)出更為嚴(yán)重的不均衡性，任務(wù)完成用時接近三副本存儲模式的 3 倍。

表1 RS-(6,3)糾刪碼與三副本存儲存儲模式下 Wordcount 作業(yè)運(yùn)行情況統(tǒng)計Table 1 Wordcount Application’s running statistics in replication storage mode and RS-(6,3) erasure-coded storage mode

圖2 RS-(6,3)糾刪碼與三副本存儲模式下 MapReduce 的任務(wù)運(yùn)行時間分布Fig. 2 Task running time distribution of MapReduce applications in replication storage mode and RS-(6,3)erasure-coded storage mode

目前，國內(nèi)外學(xué)者針對 MapReduce 應(yīng)用的性能優(yōu)化主要聚焦于多副本存儲模式下的數(shù)據(jù)放置策略。如 Wang 等[6]通過分析 HDFS 數(shù)據(jù)的歷史訪問記錄，發(fā)掘數(shù)據(jù)間的關(guān)聯(lián)性并重新組織數(shù)據(jù)布局，使得運(yùn)行 MapReduce 應(yīng)用時能最大化地利用數(shù)據(jù)本地性優(yōu)勢，盡可能減少跨網(wǎng)絡(luò)的數(shù)據(jù)傳輸，提高 MapReduce 應(yīng)用的運(yùn)行效率。此外，針對集群的異構(gòu)環(huán)境，Xiong 等[7]通過選取節(jié)點(diǎn)關(guān)鍵性能參數(shù)對異構(gòu)集群進(jìn)行邏輯分層，并結(jié)合數(shù)據(jù)訪問熱度決定副本數(shù)量和放置位置，從而提高異構(gòu)環(huán)境下 MapReduce 應(yīng)用的運(yùn)行效率。

關(guān)于糾刪碼在存儲中的應(yīng)用，目前大量研究工作集中于優(yōu)化糾刪碼機(jī)制引入的編解碼操作在實(shí)際系統(tǒng)中的數(shù)據(jù)更新[8]及故障修復(fù)等性能[9]。如 Wang 等[10]提出一種基于異或網(wǎng)絡(luò)計算的數(shù)據(jù)更新及修復(fù)流程，通過在復(fù)雜網(wǎng)絡(luò)拓?fù)湎逻x取合適的交換機(jī)卸載部分編解碼操作，降低糾刪碼機(jī)制帶來的網(wǎng)絡(luò)傳輸流量，從而優(yōu)化系統(tǒng)的更新和故障修復(fù)性能。此外，也有學(xué)者利用糾刪碼的編解碼特性對系統(tǒng)訪問請求進(jìn)行負(fù)載均衡，如 Rashmi 團(tuán)隊[11]在內(nèi)存對象緩存系統(tǒng) Alluxio 中引入糾刪碼機(jī)制取代原來的選擇性復(fù)制策略，當(dāng)某些數(shù)據(jù)的訪問熱度較高時，將數(shù)據(jù)分片的一部分訪問請求轉(zhuǎn)移到訪問條帶的校驗分片，再進(jìn)行解碼操作恢復(fù)原始數(shù)據(jù)，從而實(shí)現(xiàn)系統(tǒng)的訪問負(fù)載均衡。

部分學(xué)者也嘗試在 Hadoop、Spark 等分布式計算框架中通過引入糾刪碼進(jìn)行中間結(jié)果的容錯。如 Yao 等[12]將糾刪碼用于 Spark 的 Shuffle階段對彈性分布式數(shù)據(jù)集進(jìn)行編碼，避免部分節(jié)點(diǎn)發(fā)生故障時，系統(tǒng)運(yùn)行的部分任務(wù)需要重新進(jìn)行。Tandon 等[13]和 Wang 等[14]在分布式機(jī)器學(xué)習(xí)框架中引入了糾刪碼對分布式神經(jīng)網(wǎng)絡(luò)計算過程的中間梯度結(jié)果進(jìn)行編碼。通過引入冗余校驗信息，主節(jié)點(diǎn)可在收取一部分從節(jié)點(diǎn)的計算結(jié)果后就恢復(fù)出全局結(jié)果，從而減少網(wǎng)絡(luò)傳輸過程中因部分節(jié)點(diǎn)的延遲造成主節(jié)點(diǎn)過長的同步等待時間。Li 等[15]更改了 MapReduce 應(yīng)用在 Shuffle 階段的網(wǎng)絡(luò)傳輸模式，通過增加本地重復(fù)性計算對臨時結(jié)果進(jìn)行編碼，而后利用網(wǎng)絡(luò)多播傳輸來降低 Reduce 任務(wù)需要跨網(wǎng)絡(luò)獲取的數(shù)據(jù)總量。

綜上可知，糾刪碼存儲策略雖然具有存儲友好的優(yōu)勢，但由于其存儲模式的變化，上層業(yè)務(wù)的數(shù)據(jù)訪問性能存在較大的優(yōu)化空間。本文基于當(dāng)前 HDFS 的條帶式糾刪碼策略，通過考慮集群的異構(gòu)情況和長期負(fù)載為每個條帶選取合適的放置位置，并根據(jù)集群各節(jié)點(diǎn)運(yùn)行時的負(fù)載選取合適的任務(wù)并發(fā)量，從而避免產(chǎn)生嚴(yán)重的“掉隊”任務(wù)，影響整個 MapReduce 應(yīng)用的執(zhí)行效率。

2 異構(gòu)感知的數(shù)據(jù)放置策略

2.1 異構(gòu)感知的重要性

在實(shí)際的集群環(huán)境中，隨著時間擴(kuò)展，各節(jié)點(diǎn)的硬件設(shè)備、節(jié)點(diǎn)間網(wǎng)絡(luò)拓?fù)渫钱悩?gòu)的[7]，并且由于各節(jié)點(diǎn)運(yùn)行時負(fù)載不盡相同，統(tǒng)一配置的參數(shù)無法很好地適應(yīng)異構(gòu)環(huán)境下的任務(wù)處理。目前，已有許多學(xué)者針對集群異構(gòu)情況，基于分布式機(jī)器學(xué)習(xí)系統(tǒng)[14]或分布式存儲系統(tǒng)[7]設(shè)計了合適的任務(wù)分配和數(shù)據(jù)存儲策略。在 Hadoop 中，條帶式糾刪碼默認(rèn)的隨機(jī)放置策略僅僅考慮機(jī)架間的容錯，對集群異構(gòu)環(huán)境并未進(jìn)行針對性的優(yōu)化，對數(shù)據(jù)塊和校驗塊未進(jìn)行區(qū)分，在任務(wù)分配時也并未考慮系統(tǒng)運(yùn)行時各類資源(CPU、內(nèi)存、網(wǎng)絡(luò)等)的占用情況。如圖 3 所示，通過將測試數(shù)據(jù)集的部分條帶完全放置于高性能固態(tài)硬盤(NVME SSD)(對應(yīng)區(qū)域 2)，另一部分條帶隨機(jī)放置在普通機(jī)械硬盤并限制上行網(wǎng)絡(luò)帶寬來模擬節(jié)點(diǎn)數(shù)據(jù)訪問性能差異(對應(yīng)區(qū)域 1)，此外還在部分節(jié)點(diǎn)運(yùn)行 Linux Stress 壓力測試工具模擬較高的 CPU 和內(nèi)存占用(對應(yīng)區(qū)域 3)，可以觀察到明顯的 Map 任務(wù)運(yùn)行用時差異。因此，根據(jù)集群各節(jié)點(diǎn)自身的硬件情況與運(yùn)行負(fù)載來設(shè)計合適的數(shù)據(jù)放置策略以彌合 Map任務(wù)的用時差異具有相當(dāng)大的優(yōu)化空間。

圖3 硬件異構(gòu)對任務(wù)運(yùn)行時間的影響Fig. 3 Impact of heterogeneous hardware and load differences on task running time

2.2 數(shù)據(jù)放置算法

針對前面提到的集群異構(gòu)環(huán)境，本文提出一種異構(gòu)感知數(shù)據(jù)放置策略(Heterogeneous-aware Data Placement Algorithm，HDPA)：首先對各節(jié)點(diǎn)影響 HDFS 數(shù)據(jù)訪問的關(guān)鍵硬件參數(shù)進(jìn)行統(tǒng)計，而后根據(jù)各節(jié)點(diǎn)相關(guān)硬件的歷史負(fù)載進(jìn)行分析，為各節(jié)點(diǎn)設(shè)備計算出一個常量負(fù)載因子，最后基于上述兩點(diǎn)對集群節(jié)點(diǎn)進(jìn)行性能分組，使同一個條帶的數(shù)據(jù)塊盡可能位于同一個節(jié)點(diǎn)組內(nèi)。

2.2.1 節(jié)點(diǎn)劃分策略

根據(jù) MapReduce 的數(shù)據(jù)訪問模式可知，影響Map 任務(wù)數(shù)據(jù)讀取的因素主要有數(shù)據(jù)存放節(jié)點(diǎn)的磁盤順序讀寫性能和網(wǎng)絡(luò)上行帶寬，以及任務(wù)執(zhí)行節(jié)點(diǎn)的網(wǎng)絡(luò)下行帶寬等；影響 MapReduce 任務(wù)計算的因素主要有 CPU、內(nèi)存，以及磁盤的順序讀寫、隨機(jī)讀寫性能等，其中關(guān)于 MapReduce 任務(wù)計算的負(fù)載均衡優(yōu)化將在任務(wù)分配算法中實(shí)現(xiàn)。

本文先按照影響任務(wù)數(shù)據(jù)讀取的節(jié)點(diǎn)數(shù)據(jù)傳輸性能將所有節(jié)點(diǎn)進(jìn)行分組，數(shù)據(jù)傳輸性能將結(jié)合節(jié)點(diǎn)本身的硬件參數(shù)及歷史負(fù)載來衡量。通過訪問節(jié)點(diǎn)日志，對節(jié)點(diǎn)相關(guān)硬件設(shè)備較長一段時間的歷史負(fù)載(利用 Node Exporter、Prometheus以及 Grafana 等集群性能監(jiān)控組件以分鐘為粒度采集)進(jìn)行分析，得到節(jié)點(diǎn)的長期后臺數(shù)據(jù)訪問負(fù)載情況，用常量化的負(fù)載因子表示，單位為數(shù)據(jù)傳輸速度 MB/s，具體計算方式如下：

基于上述劃分方式，本文通過設(shè)計合適的數(shù)據(jù)放置策略可以實(shí)現(xiàn)向 HDFS 寫入數(shù)據(jù)時將同一條帶的數(shù)據(jù)塊盡量分布在數(shù)據(jù)傳輸性能相近的節(jié)點(diǎn)組，使 Map 任務(wù)向多個節(jié)點(diǎn)讀取數(shù)據(jù)時不會因為節(jié)點(diǎn)性能差異過大而導(dǎo)致數(shù)據(jù)傳輸時間過長，從而有效縮短 Map 任務(wù)的數(shù)據(jù)訪問用時。

2.2.2 數(shù)據(jù)放置策略

在為條帶選取放置位置時，必須保證系統(tǒng)的可靠性。當(dāng)前 HDFS 糾刪碼模式并不對數(shù)據(jù)塊和校驗塊的放置進(jìn)行區(qū)分，而是通過隨機(jī)放置的方式盡可能容錯多個機(jī)架，然而在真實(shí)環(huán)境中單磁盤、節(jié)點(diǎn)以及單機(jī)架故障這類情況占絕大多數(shù)[16]。因此，為了更容易為條帶找到合適的存儲節(jié)點(diǎn)，并盡量減少 MapReduce 應(yīng)用運(yùn)行產(chǎn)生的跨機(jī)架網(wǎng)絡(luò)流量，鑒于多個機(jī)架同時發(fā)生故障的可能性較小，在滿足實(shí)際需求的前提下，HDPA 將只保證單個機(jī)架的故障容錯。與此同時，為了保證節(jié)點(diǎn)在正常狀態(tài)下的數(shù)據(jù)訪問性能，HDPA 在選取條帶位置時將對條帶的數(shù)據(jù)塊和校驗塊進(jìn)行區(qū)分。當(dāng) HDPA 在集群同一節(jié)點(diǎn)組內(nèi)無法找到存放完整條帶的節(jié)點(diǎn)數(shù)目時，將會優(yōu)先將條帶拆分并把校驗塊放在性能相對較弱的節(jié)點(diǎn)組。具體流程如算法 1代碼所示：

?

HDPA 算法替代默認(rèn)隨機(jī)放置策略集成在HDFS 主節(jié)點(diǎn)的核心步驟如下：

Step 1. 在 Client 端寫入文件，確定文件被劃分的條帶個數(shù)；在主節(jié)點(diǎn)端開始為每個條帶選取合適的放置位置。該步驟對應(yīng)算法 1 第 1～2 行的初始化設(shè)置。

Step 3. 主節(jié)點(diǎn)統(tǒng)計每一個節(jié)點(diǎn)組的平均存儲占用率：

上述 HDPA 算法保證了 HDFS 集群正常讀寫性能和容錯需求，同時提高了系統(tǒng)在 MapReduce這類應(yīng)用場景下的數(shù)據(jù)讀取性能。當(dāng)節(jié)點(diǎn)磁盤及網(wǎng)絡(luò)負(fù)載總體較高時，上述 HDPA 算法優(yōu)化了Map 任務(wù)執(zhí)行時因節(jié)點(diǎn)性能差異導(dǎo)致數(shù)據(jù)傳輸時間過長的問題。

3 負(fù)載感知的任務(wù)分配算法

當(dāng)前 Hadoop 版本通過另一種資源協(xié)調(diào)者(Yet Another Resource Negotiator，YARN)框架對集群計算資源進(jìn)行管理，用戶通過在每個節(jié)點(diǎn)的配置文件中設(shè)置參數(shù)劃分節(jié)點(diǎn)可用的計算資源(主要是 CPU 核心和內(nèi)存可用量)，因此 YARN確定了集群的最大任務(wù)并發(fā)度(即可同時運(yùn)行Map/Reduce 任務(wù)的最大數(shù)量)。但這種確定的節(jié)點(diǎn)管理方式在一定程度上無法適用于集群的異構(gòu)環(huán)境和運(yùn)行負(fù)載。如圖 3 的區(qū)域 3 所示，即使在相同硬件配置的集群中，在 CPU 負(fù)載較高的節(jié)點(diǎn)上運(yùn)行相同數(shù)目的 Map 任務(wù)，運(yùn)行時間也會被大大拉長，甚至?xí)捎谶\(yùn)行時間過長而導(dǎo)致任務(wù)失敗。

與 HDPA 類似，本文基于集群異構(gòu)場景和節(jié)點(diǎn)硬件負(fù)載情況，提出一種動態(tài)的任務(wù)分配算法(Dynamic Task Allocation Algorithm，DTAA)，其核心在于 YARN 會在 MapReduce 應(yīng)用進(jìn)行任務(wù)分配前采集集群各節(jié)點(diǎn)的計算資源負(fù)載，并為每個節(jié)點(diǎn)確定合適的任務(wù)分配數(shù)量，通過動態(tài)調(diào)節(jié)集群的任務(wù)并發(fā)度避免因計算資源競爭造成任務(wù)運(yùn)行效率低下的問題。

3.1 計算資源的動態(tài)限制

不同于 YARN 默認(rèn)情況下，主節(jié)點(diǎn)通過各從節(jié)點(diǎn)訪問節(jié)點(diǎn)本地的配置文件并向主節(jié)點(diǎn)發(fā)送心跳包來確定集群可用的計算資源情況(在 Hadoop中稱為 Container)，DTAA 在各節(jié)點(diǎn)向主節(jié)點(diǎn)發(fā)送的心跳包中額外添加了 Preferred-Container 信息，其含義是通過訪問節(jié)點(diǎn)當(dāng)前硬件負(fù)載情況，結(jié)合硬件參數(shù)，計算出在不影響節(jié)點(diǎn)運(yùn)行效率的情況下節(jié)點(diǎn)自身可用的計算資源數(shù)量，以實(shí)現(xiàn)計算資源的動態(tài)限制。各節(jié)點(diǎn)的 Preferred-Container數(shù)量(簡記為 )計算如下：

其中， 分別是節(jié)點(diǎn)配置文件中設(shè)置的可用 CPU 核心數(shù)和內(nèi)存分配容量；分別是節(jié)點(diǎn)上的 C P U、內(nèi)存負(fù)載情況；

分別是節(jié)點(diǎn) CPU 核心數(shù)和內(nèi)存容量的硬件信息。由此可以根據(jù)節(jié)點(diǎn)負(fù)載情況對YARN 的默認(rèn)參數(shù)進(jìn)行動態(tài)調(diào)整。

3.2 任務(wù)選取

根據(jù) 3.1 節(jié)的資源動態(tài)限制，可以得知集群的兩類關(guān)鍵信息：MapReduce 應(yīng)用需要處理的數(shù)據(jù)集合、當(dāng)前集群的可用計算資源。接下來需要解決任務(wù)分配問題，存在兩種情況：

(1)數(shù)據(jù)量小，需要分配的 Map/Reduce 任務(wù)數(shù)量小于集群并發(fā)度；

(2)數(shù)據(jù)量大，需要分配的 Map/Reduce 任務(wù)數(shù)量大于集群并發(fā)度，涉及到節(jié)點(diǎn)計算資源的分配、釋放與再分配。

當(dāng)前 Hadoop 在運(yùn)行 MapReduce 應(yīng)用時的默認(rèn)策略是正常情況下 Map 任務(wù)訪問條帶的數(shù)據(jù)塊，當(dāng) Map 任務(wù)運(yùn)行效率過低或訪問數(shù)據(jù)塊失敗時重新執(zhí)行任務(wù)并訪問條帶的校驗塊進(jìn)行數(shù)據(jù)修復(fù)，而重新執(zhí)行和超時機(jī)制造成了集群資源的浪費(fèi)與 Map 階段用時的增加。

上述兩種任務(wù)情況存在相同的問題。如圖 4，Map 任務(wù)僅僅訪問條帶數(shù)據(jù)塊(藍(lán)色)，容易在不同節(jié)點(diǎn)產(chǎn)生數(shù)據(jù)讀取熱度差異，并可能產(chǎn)生部分節(jié)點(diǎn)磁盤負(fù)載和網(wǎng)絡(luò)流量的瓶頸，影響任務(wù)的執(zhí)行。因此，DTAA 引入主動降級讀取機(jī)制，在Map 任務(wù)運(yùn)行速度過慢時根據(jù)任務(wù)進(jìn)度緩慢的不同原因選取對應(yīng)的解決策略。DTAA 在 Map 任務(wù)的執(zhí)行邏輯中引入數(shù)據(jù)等待計時器，分別統(tǒng)計Map 任務(wù)在數(shù)據(jù)讀取和計算兩個過程的用時情況，判斷可能的瓶頸位置。若 Map 任務(wù)在數(shù)據(jù)讀取時等待數(shù)據(jù)同步的用時相對較長，則額外隨機(jī)訪問條帶的一個校驗塊來替換條帶數(shù)據(jù)塊響應(yīng)最慢的節(jié)點(diǎn)，從而降低一定的時間開銷。

圖4 任務(wù)對應(yīng)數(shù)據(jù)塊訪問不均衡Fig. 4 Unbalanced datablock read in task running

針對上述情況，DTAA 均給出了對應(yīng)的任務(wù)分配方式進(jìn)行優(yōu)化，具體流程如算法 2 中偽代碼所示，步驟概括如下：

?

Step 1. 各從節(jié)點(diǎn)定期采集自身 CPU、內(nèi)存等負(fù)載情況，并根據(jù)公式(2)計算 Preferred-Container 數(shù)量，附加在向主節(jié)點(diǎn)發(fā)送的心跳包信息中。如算法 2 第 2～6 行所示，主節(jié)點(diǎn)獲悉集群默認(rèn) Container 資源總量和 Preferred-Container資源總量。

Step 2. 提交 MapReduce 應(yīng)用時，主節(jié)點(diǎn)啟動應(yīng)用服務(wù)進(jìn)程開始計算 MapReduce 應(yīng)用的資源需求并向主節(jié)點(diǎn)申請資源。對應(yīng)算法 2 第 1 行的初始化設(shè)置。

Step 3. 當(dāng) MapReduce 應(yīng)用的任務(wù)規(guī)模小于集群 Preferred-Container 總數(shù)時，主節(jié)點(diǎn)將按各節(jié)點(diǎn)的 Preferred-Container 數(shù)量等比例分配任務(wù)。對應(yīng)算法 2 中第 7～11 行條件分支。否則進(jìn)行 Step 4 操作。

Step 4. 當(dāng) MapReduce 應(yīng)用的任務(wù)規(guī)模小于集群默認(rèn)的 Container 配置數(shù)量，主節(jié)點(diǎn)將按各節(jié)點(diǎn) Preferred-Container 相對比例進(jìn)行可用 Container 的分配與限制。對應(yīng)算法 2 中第12～16 行條件分支。例如，6 個節(jié)點(diǎn)的默認(rèn)Container 資源均為 8，MapReduce 應(yīng)用的 Map任務(wù)數(shù)為 34，在 6 個節(jié)點(diǎn)上計算出的 Preferred-Container 分別為 3、5、5、6、4、3，此時各節(jié)點(diǎn)對應(yīng)的任務(wù)分配數(shù)量為 4、7、7、8、4、4。若 MapReduce 應(yīng)用的任務(wù)規(guī)模超過集群默認(rèn)的Container 配置數(shù)量，則進(jìn)行 Step 5 的操作。

Step 5. 若 MapReduce 應(yīng)用的任務(wù)規(guī)模超過集群默認(rèn)的 Container 配置數(shù)量，Map 任務(wù)則需多次分配運(yùn)行，每一次任務(wù)分配數(shù)量以各節(jié)點(diǎn)的 Preferred-Container 數(shù)量為限制，直至所有Map 任務(wù)分配完成。對應(yīng)算法 2 中第 17～21 行條件分支。

4 實(shí)驗結(jié)果與分析

4.1 實(shí)驗環(huán)境配置及參數(shù)設(shè)置

本文實(shí)驗在一個由 16 臺服務(wù)器組成的集群上進(jìn)行，每臺服務(wù)器的 CPU 為兩顆 Intel(R)Xeon(R)CPU E5-2650 v4 @ 2.20GHz 組成的NUMA 節(jié)點(diǎn)，標(biāo)準(zhǔn)配置 64 GB 頻率為 2400 MHz的服務(wù)器 ECC 內(nèi)存和萬兆網(wǎng)卡，每臺節(jié)點(diǎn)掛載若干個 1 TB 希捷機(jī)械硬盤和三星 EVO860 SSD，每臺節(jié)點(diǎn)均運(yùn)行 CentOS 7.9 版本的 Linux操作系統(tǒng)，集群上運(yùn)行若干常見分布式系統(tǒng)以及容器環(huán)境(Ceph，Redis，Cassandra 等)。

本實(shí)驗選取一臺服務(wù)器作為主節(jié)點(diǎn)運(yùn)行，其他機(jī)器作為數(shù)據(jù)節(jié)點(diǎn)和任務(wù)執(zhí)行節(jié)點(diǎn)。通過對網(wǎng)卡帶寬、掛載磁盤等進(jìn)行設(shè)置以及在其他分布式系統(tǒng)上運(yùn)行不同的 Benchmark 來模擬集群的軟硬件異構(gòu)。實(shí)驗以 Hadoop-3.3.0 默認(rèn)的隨機(jī)數(shù)據(jù)放置和任務(wù)分配作為基準(zhǔn)，數(shù)據(jù)塊大小設(shè)置為 256 MB，通過在 Hadoop 系統(tǒng)中運(yùn)行幾類常見的 MapReduce 應(yīng)用，對比本文提出的 HDPA數(shù)據(jù)放置和 DTAA 任務(wù)分配策略對 MapReduce應(yīng)用運(yùn)行速度的優(yōu)化結(jié)果。

4.2 常見 MapReduce 應(yīng)用運(yùn)行情況對比

4.2.1 詞頻統(tǒng)計

詞頻統(tǒng)計(Wordcount)作業(yè)是 MapReduce 應(yīng)用中常見的一類數(shù)據(jù)分析任務(wù)，即通過分片處理海量數(shù)據(jù)統(tǒng)計某些屬性的情況(如天氣分析、用戶地域?qū)傩詣澐值?。本文用 HiBench 生成的60 GB 文本數(shù)據(jù)作為測試數(shù)據(jù)集，實(shí)驗結(jié)果如圖 5 所示。

圖5 詞頻統(tǒng)計作業(yè)處理 60 GB 文本數(shù)據(jù)的作業(yè)完成用時Fig. 5 Completion time of Wordcount Application processing 60 GB text data

結(jié)果表明，與 Hadoop 默認(rèn)的數(shù)據(jù)放置和任務(wù)分配策略相比，本文提出的“HDPA+DTAA”優(yōu)化策略能夠縮短 MapReduce 作業(yè)的運(yùn)行時間。在三次重復(fù)實(shí)驗中(如表 2 所示)，詞頻統(tǒng)計 MapReduce 作業(yè)在默認(rèn)設(shè)置(藍(lán)色線條)情況下和在“HDPA+DTAA”方案(黃色線條)下的平均完成時間分別為 128.0 s 和 90.8 s，“HDPA+DTAA”方案提升約 29%，其中 Map階段運(yùn)行用時分別為 105.7 s 和 74.4 s。

表2 Wordcount 應(yīng)用運(yùn)行情況統(tǒng)計Table 2 Wordcount Application’s running statistics

此外，為了進(jìn)一步分析數(shù)據(jù)布局和任務(wù)分配分別對 MapReduce 作業(yè)運(yùn)行的影響，本文分別測試了 HDPA 和 DTAA 算法對 MapReduce 作業(yè)運(yùn)行的優(yōu)化效果，如圖 5 中紫色和綠色線條所示，當(dāng)各節(jié)點(diǎn)上的任務(wù)瓶頸出現(xiàn)在不同位置時，HDPA 和 DTAA 算法的優(yōu)化效果也不盡相同。如圖 5 紫色圈定范圍 1 所示，在詞頻統(tǒng)計作業(yè)中監(jiān)控各任務(wù)進(jìn)程的 CPU、內(nèi)存及磁盤 IO 占用信息和節(jié)點(diǎn)整體資源使用情況發(fā)現(xiàn)，對于極端長尾任務(wù)，往往由于計算節(jié)點(diǎn) CPU、內(nèi)存等計算資源發(fā)生較為嚴(yán)重的競爭，HDPA 數(shù)據(jù)訪問的優(yōu)化并不能帶來明顯的效果，而 DTAA 可以通過各節(jié)點(diǎn)均衡計算資源的占用有效緩和極端任務(wù)的產(chǎn)生；與之對應(yīng)，從圖中綠色圈定范圍 2 可以看出，HDPA 能夠有效緩和部分任務(wù)完成用時的“參差”情況，因為范圍 2 的任務(wù)計算資源較為寬松，HDPA 能夠均衡任務(wù)并發(fā)訪問多節(jié)點(diǎn)數(shù)據(jù)時各節(jié)點(diǎn)的響應(yīng)性能 (與數(shù)據(jù)所在節(jié)點(diǎn)的磁盤和上行帶寬占用相關(guān))。綜合各方面來看，HDPA 和DTAA 能夠分別對集群并發(fā)任務(wù)可能面臨的不同瓶頸情況進(jìn)行優(yōu)化，從而協(xié)同達(dá)到更好的優(yōu)化結(jié)果。

4.2.2 排序

排序(Sort)任務(wù)是 MapReduce 作業(yè)中數(shù)據(jù)全量處理的一類代表性任務(wù)(如數(shù)據(jù)分類、歸檔、批量修改等)，其特點(diǎn)是在糾刪碼策略下數(shù)據(jù)在Map 訪問、Shuffle、Reduce 寫回階段均會產(chǎn)生大量磁盤讀寫和跨網(wǎng)絡(luò)傳輸。本文基于 60 GB 向量標(biāo)簽數(shù)據(jù)集進(jìn)行 Sort 排序和分類寫回，實(shí)驗結(jié)果如圖 6 所示：

圖6 Sort 應(yīng)用統(tǒng)計 60 GB 向量標(biāo)簽數(shù)據(jù)的作業(yè)完成用時Fig. 6 Completion time of Sort Aplication processing 60 GB vector record data

在 Sort 排序應(yīng)用中，“HDPA+DTAA”方案的平均完成時間為 104.7 s，與采用默認(rèn)策略的 180.6 s 相比，提速約 42.0%。一方面，是因為Sort 排序應(yīng)用的中間結(jié)果在數(shù)據(jù)量上約等于原始數(shù)據(jù)，因此在 Map 階段會產(chǎn)生大量磁盤溢寫，不均衡的數(shù)據(jù)放置會進(jìn)一步加劇磁盤負(fù)載的熱度差異；另一方面，是因為各節(jié)點(diǎn)的任務(wù)分配數(shù)量除了影響節(jié)點(diǎn) CPU、內(nèi)存等計算資源的占用外，也決定了中間結(jié)果數(shù)據(jù)量，從而影響節(jié)點(diǎn)磁盤負(fù)載。在默認(rèn)策略下，上述兩方面原因共同造成了極端 Map 任務(wù)的出現(xiàn)，延長了 Map 階段的執(zhí)行時間。如圖 6 所示，在分別部署 HDPA 和 DTAA的實(shí)驗中，兩種策略均體現(xiàn)了一定的優(yōu)化效果，分別對應(yīng)了上述兩方面的因素。關(guān)于 Sort 應(yīng)用的其他運(yùn)行的詳細(xì)信息如表 3 所示。

表3 Sort 應(yīng)用運(yùn)行情況統(tǒng)計Table 3 Sort Application’s running statistics

4.2.3 K-Means 機(jī)器學(xué)習(xí)算法

MapReduce 框架也可用于大規(guī)模機(jī)器學(xué)習(xí)任務(wù)。本文針對典型的機(jī)器學(xué)習(xí)算法 K-Means 進(jìn)行測試，Hadoop 通過將 K-Means 聚類算法抽象為多次迭代的 MapReduce 任務(wù)得到最終結(jié)果，實(shí)驗結(jié)果如圖 7 所示。

圖7 K-Means 應(yīng)用計算 75 GB 數(shù)據(jù) 10 次迭代運(yùn)行情況Fig. 7 10 Iteration of K-Means with 75 GB data

K-Means 聚類算法每次迭代均會訪問全部數(shù)據(jù)集進(jìn)行聚類中心的更新，因此 Map 階段占據(jù)了大部分執(zhí)行時間。K-Means 應(yīng)用運(yùn)行時，數(shù)據(jù)放置和任務(wù)分配是否負(fù)載均衡將隨著迭代次數(shù)增加K-Means 應(yīng)用的執(zhí)行時間。在“HDPA+DTAA”策略下，10 次迭代以及最終結(jié)果寫回共計用時 696 s，相較于默認(rèn)策略下用時 778 s 縮短了10.5%，并且在每次迭代中的用時波動也更加穩(wěn)定。

4.3 優(yōu)化方案對 HDFS 數(shù)據(jù)吞吐量的影響

為驗證本文 HDPA 方案對 Hadoop 集群自身的讀寫性能并未產(chǎn)生明顯影響，本文通過向集群并發(fā)讀寫 200 個文件，每個文件設(shè)為 1 GB大小，測試 HDPA 方案和默認(rèn)數(shù)據(jù)放置策略下Hadoop 集群的數(shù)據(jù)吞吐量。如表 4 所示，HDPA數(shù)據(jù)放置算法取代了 HDFS 默認(rèn)的隨機(jī)放置，在數(shù)據(jù)寫入的 IO 路徑上會帶來一定開銷，主要原因在于節(jié)點(diǎn)分組和數(shù)據(jù)放置選取。由于節(jié)點(diǎn)分組時只考慮硬件性能參數(shù)和較長一段時間的平均負(fù)載，因此單次劃分可作為系統(tǒng)較長一段時間的劃分參考。此外，數(shù)據(jù)的放置位置選取主要包括節(jié)點(diǎn)組平均存儲占用排序、機(jī)架級可靠性保障檢測以及條帶放置選取結(jié)束后的節(jié)點(diǎn)組平均存儲占用更新等三部分，其計算開銷相對較低，因此 HDPA 不會在文件寫入時帶來過長的額外延遲。并且，由于條帶按節(jié)點(diǎn)性能放置，部分條帶反而會更快完成寫入或讀取，因此 HDPA 不會對HDFS 的總體讀寫性能造成明顯消極影響。

表4 Hadoop 默認(rèn)策略和 HDPA+DTAA 兩種策略下 HDFS 數(shù)據(jù)吞吐量Table 4 HDFS data throughput in the Hadoop default strategy and HDPA+DTAA strategy

5 結(jié) 論

本文提出了一種基于異構(gòu) Hadoop 集群的數(shù)據(jù)放置算法 HDPA 和任務(wù)分配策略 DTAA，分別從存儲側(cè)和計算側(cè)兩端解決在條帶式糾刪碼存儲模式下，上層 MapReduce 應(yīng)用由于“一對多”數(shù)據(jù)訪問模式和節(jié)點(diǎn)性能差異造成的任務(wù)運(yùn)行用時增加的問題。實(shí)驗結(jié)果表明，在 Wordcount、Sort、K-Means 等三類具有代表性的 MapReduce應(yīng)用中，通過對異構(gòu)集群節(jié)點(diǎn)的數(shù)據(jù)訪問性能進(jìn)行評估和分組，以此作為糾刪碼條帶放置位置的選取依據(jù)，能夠有效提升 MapReduce 應(yīng)用在 Map 階段的數(shù)據(jù)訪問性能；此外，根據(jù)集群節(jié)點(diǎn)各項資源負(fù)載情況對 Hadoop 的任務(wù)并發(fā)度進(jìn)行動態(tài)調(diào)節(jié)，能夠有效避免各節(jié)點(diǎn)任務(wù)間因資源競爭產(chǎn)生嚴(yán)重的長尾效應(yīng)，最終驗證了“HDPA+DTAA”方案的可行性與有效性。目前，國內(nèi)外針對 MapReduce 應(yīng)用優(yōu)化的主要場景大多基于多副本存儲模式[6,17]，基于 Hadoop條帶式糾刪碼存儲模式的相關(guān)工作相對較少，主要是一些問題的提出和在同構(gòu)場景下的實(shí)驗分析[18]，因此本文具有一定創(chuàng)新性。在未來工作中，我們將嘗試采用不同評估標(biāo)準(zhǔn)對集群節(jié)點(diǎn)的性能進(jìn)行更加精確的劃分，并設(shè)計更加高效靈活的數(shù)據(jù)放置和任務(wù)分配策略來進(jìn)一步提升本研究方案的優(yōu)化效果。