基于云芯一號(hào)的分布式文件系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)*

王界兵，王文利，董迪馬

(深圳前海信息技術(shù)有限公司，廣東 深圳 518000)

0 引言

網(wǎng)絡(luò)技術(shù)的飛速發(fā)展帶來(lái)了數(shù)據(jù)量的指數(shù)級(jí)增長(zhǎng)，互聯(lián)網(wǎng)傳統(tǒng)的C/S架構(gòu)(客戶端-服務(wù)器)也面臨著各類數(shù)據(jù)高峰和偶有發(fā)生的數(shù)據(jù)爆炸的挑戰(zhàn)。Google首席執(zhí)行官于2006年8月9日在SES San Jose 2006搜索引擎大會(huì)上首次提出云計(jì)算[1]的概念，云計(jì)算技術(shù)應(yīng)運(yùn)而生，其中又以開(kāi)源的分布式系統(tǒng)架構(gòu)Hadoop[2]最為著名。自發(fā)布后世界上多數(shù)互聯(lián)網(wǎng)公司和數(shù)據(jù)庫(kù)廠商已支持使用，其中多家公司進(jìn)行了更高效率的改進(jìn)和研發(fā)[3]。

然而，隨著大數(shù)據(jù)現(xiàn)代化的逐步推進(jìn)以及各類大數(shù)據(jù)處理技術(shù)的快速發(fā)展，現(xiàn)有的超大數(shù)據(jù)集甚至大數(shù)據(jù)集的應(yīng)用程序在基于原有的低廉、低性能服務(wù)器及硬件上的Hadoop架構(gòu)上的處理效率已大幅度降低。為了解決上述性能耗損的問(wèn)題，各企業(yè)不得不重新購(gòu)置高性能服務(wù)器、部署相關(guān)實(shí)驗(yàn)環(huán)境，這無(wú)疑會(huì)帶來(lái)新的經(jīng)濟(jì)挑戰(zhàn)和各類資源適配問(wèn)題。

本文基于上述問(wèn)題，提出基于自主研發(fā)的云芯一號(hào)DX硬件加速卡的分布式系統(tǒng)設(shè)計(jì)，在無(wú)需改變現(xiàn)有X86架構(gòu)上進(jìn)行硬件擴(kuò)充和優(yōu)化，并在此基礎(chǔ)上采用Hadoop分布式文件系統(tǒng)對(duì)大量數(shù)據(jù)進(jìn)行處理。

1 相關(guān)技術(shù)簡(jiǎn)介

1.1 Hadoop

眾所周知，Google研發(fā)的Apache Hadoop是基于Google云計(jì)算技術(shù)的開(kāi)源實(shí)現(xiàn)，其獨(dú)特的分布式架構(gòu)讓物理隔離上的低廉(low-cost)服務(wù)器可以通過(guò)互聯(lián)網(wǎng)傳輸自身的計(jì)算能力，并同時(shí)具有高可靠性、高擴(kuò)展性、高效性、高容錯(cuò)性、低成本等優(yōu)點(diǎn)[4]。Hadoop的核心組件主要包括Google GFS、BigTable、MapReduce。其中，Google GFS也同時(shí)提供一定程度的容錯(cuò)功能[5]，其開(kāi)源實(shí)現(xiàn)就是分布式存儲(chǔ)模型——HDFS[6](Hadoop Distributed File System)。在完成分布式數(shù)據(jù)庫(kù)和分布式文件系統(tǒng)后，一種分布式的計(jì)算模型——MapReduce也應(yīng)運(yùn)而生，其運(yùn)行原理是將需要執(zhí)行的任務(wù)進(jìn)行分割并分配至各個(gè)節(jié)點(diǎn)，分配的任務(wù)由各個(gè)節(jié)點(diǎn)分別執(zhí)行，最后將執(zhí)行結(jié)果合并形成總體計(jì)算結(jié)果。接下來(lái)分別對(duì)HDFS和MapReduce兩個(gè)組件進(jìn)行介紹。

1.2 分布式存儲(chǔ)模型(HDFS)

分布式存儲(chǔ)模型HDFS是Google File System(GFS)的開(kāi)源實(shí)現(xiàn)[7]。作為最底層的組件，HDFS的體系結(jié)構(gòu)是一個(gè)主從結(jié)構(gòu)，如圖1所示。

圖1 HDFS架構(gòu)圖

如圖1所示，在HDFS架構(gòu)中，主節(jié)點(diǎn)Namenode只有一個(gè)，而從節(jié)點(diǎn)Datanode可以有一個(gè)或者很多個(gè)。主節(jié)點(diǎn)作為一個(gè)管理的主服務(wù)器，系統(tǒng)中文件的命名空間由其來(lái)管理，同時(shí)各終端對(duì)文件的訪問(wèn)協(xié)調(diào)工作也由它負(fù)責(zé)。當(dāng)存儲(chǔ)的文件通過(guò)用戶請(qǐng)求發(fā)送到HDFS中時(shí)，該文件被分成多個(gè)數(shù)據(jù)塊并將這些數(shù)據(jù)庫(kù)塊并行復(fù)制到多個(gè)DataNode數(shù)據(jù)節(jié)點(diǎn)中。分割的數(shù)據(jù)塊大小及數(shù)量是在創(chuàng)建文件時(shí)由客戶機(jī)決定的(可以通過(guò)配置進(jìn)行適宜調(diào)整)，最終由NameNode主節(jié)點(diǎn)來(lái)控制所有文件操作。在HDFS中，各類節(jié)點(diǎn)都可以部署在配置普通的硬件上，通常運(yùn)行HDFS的服務(wù)器上運(yùn)行Linux操作系統(tǒng)，其開(kāi)源的屬性和對(duì)Hadoop的友好性是其他系統(tǒng)無(wú)法比擬。Hadoop基于最流行的Java語(yǔ)言來(lái)開(kāi)發(fā)，且HDFS內(nèi)部的所有通信都基于標(biāo)準(zhǔn)的TCP/IP協(xié)議，最大程度減輕了開(kāi)發(fā)成本和部署成本。

1.3 分布式計(jì)算模型(MapReduce)

相比功能較為單一的文件系統(tǒng)HDFS來(lái)說(shuō)，MapReduce則被稱為是到目前為止最為成功、最廣為接受和最易于使用的大數(shù)據(jù)并行處理技術(shù)。

簡(jiǎn)單來(lái)說(shuō)，MapReduce中的算法模型就是一種簡(jiǎn)化并行計(jì)算的編程模型。繼承了分布式的設(shè)計(jì)理念的MapReduce將具體應(yīng)用切分為多個(gè)小任務(wù)，分配至各個(gè)節(jié)點(diǎn)并行執(zhí)行，利用集群服務(wù)器的并行計(jì)算能力來(lái)并行處理，完美解決了傳統(tǒng)單機(jī)環(huán)境中并行能力和計(jì)算能力不足的缺點(diǎn)[8]。

MapReduce的主要組成是函數(shù)性編程中的Map和Reduce函數(shù)，其中Map函數(shù)轉(zhuǎn)換一組數(shù)據(jù)為Key/Value列表，而Reduce函數(shù)則根據(jù)Map函數(shù)產(chǎn)生列表的Key值來(lái)縮減這個(gè)列表，再將最終生成的列表應(yīng)用于另一個(gè)Reduce函數(shù)，得到相同的結(jié)果，具體流程如圖2所示。

圖2 MapReduce數(shù)據(jù)處理流程圖

MapReduce中的每個(gè)元素都是被獨(dú)立操作的，且原始列表沒(méi)有被更改，然后再創(chuàng)建了一個(gè)新的列表來(lái)保存新的答案?；谝陨显?，Map操作是可以高度并行的，這對(duì)高性能要求的應(yīng)用以及并行計(jì)算領(lǐng)域的需求非常有用。而化簡(jiǎn)操作指的是對(duì)一個(gè)列表的元素進(jìn)行適當(dāng)?shù)暮喜ⅰ?/p>

2 云芯一號(hào)——DX SDK硬件加速卡

云芯一號(hào)是一張我們擁有自主知識(shí)產(chǎn)權(quán)的硬件加速卡，可以使用任何可用的12V PCle插槽供電，如圖3所示。云芯一號(hào)支持8路雙工收發(fā)器，可插入x8或更大的PCle 3.0插槽。所有和云芯一號(hào)之間的通信都通過(guò)PCle接口進(jìn)行。

圖3 云芯一號(hào)硬件加速卡

在軟件架構(gòu)方面，云芯一號(hào)主要由以下幾個(gè)軟件模塊組成，如圖4所示。

圖4 云芯一號(hào)軟件架構(gòu)圖

具體結(jié)構(gòu)如下：

(1)服務(wù)助理基礎(chǔ)設(shè)施(SAI)：為其他模塊提供基礎(chǔ)服務(wù)。SAI由OS抽象層(OSAL)、日志和文件解析器組件組成。

(2)API層：云芯一號(hào)提供Raw加速(原始)API來(lái)連接用戶應(yīng)用程序。Raw Acceleration API利用云芯一號(hào)上的所有功能，包括壓縮、加密、認(rèn)證、RNG和PK操作。

(3)Frontsurf服務(wù)框架：Frontsurf Service Framework(FSF)為API層提供算法加速。所有與芯片組無(wú)關(guān)的代碼都位于FSF中，而所有與芯片組相關(guān)的代碼位于設(shè)備專用驅(qū)動(dòng)程序中。FSF模塊管理所有使用設(shè)備特定驅(qū)動(dòng)程序注冊(cè)的會(huì)話、密鑰和設(shè)備，從而實(shí)現(xiàn)硬件加速和軟件庫(kù)操作。FSF從API層檢索操作，將這些操作轉(zhuǎn)換為硬件命令，將命令提交給硬件，檢索完成的命令，并將完成的操作返回給API層。FSF還管理負(fù)載平衡、會(huì)話上下文和密鑰池。如果硬件不可用于數(shù)據(jù)操作，則FSF與軟件庫(kù)一起工作以提供軟件支持以進(jìn)行各種操作，例如壓縮、認(rèn)證、加密和PK操作。

(4)設(shè)備專用驅(qū)動(dòng)程序：設(shè)備專用驅(qū)動(dòng)程序(DSD)是一個(gè)與芯片組相關(guān)的模塊。設(shè)備專用驅(qū)動(dòng)程序?yàn)镋xar服務(wù)框架(ESF)提供統(tǒng)一的硬件接口。DSD將每個(gè)設(shè)備的特定結(jié)構(gòu)格式轉(zhuǎn)換為ESF的統(tǒng)一結(jié)構(gòu)。

目前，云芯一號(hào)支持用于XR9240協(xié)處理器的DSD，用于軟件庫(kù)的DSD以及用于傳統(tǒng)820x處理器的DSD。DSD的單個(gè)實(shí)例將管理系統(tǒng)中安裝的該類別的所有設(shè)備。

(5)軟件庫(kù)：軟件庫(kù)執(zhí)行軟件中的壓縮、認(rèn)證、加密和公鑰操作等操作。如果云芯一號(hào)發(fā)生錯(cuò)誤或正在從錯(cuò)誤中恢復(fù)，或者系統(tǒng)中沒(méi)有可操作的Exar設(shè)備，則軟件庫(kù)將作為設(shè)備特定的驅(qū)動(dòng)程序來(lái)實(shí)現(xiàn)，以模擬硬件。

3 基于云芯一號(hào)的分布式文件系統(tǒng)

在分布式文件處理系統(tǒng)中，文件的存儲(chǔ)和傳輸性能是由組成該存儲(chǔ)系統(tǒng)的多個(gè)模塊相互作用所決定的。而傳統(tǒng)HDFS中，文件在存儲(chǔ)前并不會(huì)進(jìn)行相關(guān)的壓縮，即使有也是依賴CPU進(jìn)行軟壓縮處理。在基于云芯一號(hào)的分布式文件處理系統(tǒng)中，對(duì)文件進(jìn)行分布式存儲(chǔ)前，將使用云芯一號(hào)對(duì)文件進(jìn)行硬件壓縮，在大幅度減少了文件大小的同時(shí)避免了傳統(tǒng)存儲(chǔ)過(guò)程中因需要對(duì)文件壓縮而產(chǎn)生的CPU額外使用壓力。另外，通過(guò)硬件上的獨(dú)立壓縮，文件的安全性和完整性上也得到了穩(wěn)定的提高。顯然，壓縮后的文件在磁盤(pán)中IO時(shí)間、HDFS的各個(gè)節(jié)點(diǎn)之間的傳輸時(shí)間得以大幅減少，其架構(gòu)圖如圖5所示。

圖5 基于云芯一號(hào)的分布式文件系統(tǒng)

具體流程包括：

(1)客戶端將需要存儲(chǔ)的文件發(fā)送給云芯一號(hào)進(jìn)行壓縮處理。

(2)云芯一號(hào)返回壓縮處理后的文件給HDFS Client。

(3)Client調(diào)用DistributedFileSystem的create方法創(chuàng)建一個(gè)新的文件。

(4)DistributedFileSystem通過(guò)RPC調(diào)用Name Node節(jié)點(diǎn)上的接口，創(chuàng)建一個(gè)沒(méi)有blocks關(guān)聯(lián)的新文件。創(chuàng)建前，Name Node會(huì)做各種校驗(yàn)，如果校驗(yàn)通過(guò)，Name Node就會(huì)記錄下新文件，否則就會(huì)拋出IO異常。

(5)前兩步結(jié)束后會(huì)返回FSDataOutputStream的對(duì)象，F(xiàn)SDataOutputStream被封裝成DFSOutputStream，DFSOutputStream可以協(xié)調(diào)Name Node和Data Node?？蛻舳碎_(kāi)始寫(xiě)數(shù)據(jù)到DFSOutputStream，同時(shí)DFSOutputStream會(huì)把數(shù)據(jù)切成一個(gè)個(gè)小packet，然后排成隊(duì)列data queue。

(6)DataStreamer會(huì)去處理接收data queue，它先問(wèn)詢Name Node這個(gè)新的block最適合存儲(chǔ)的在哪幾個(gè)Data Node里，把它們排成一個(gè)pipeline。

(7)DFSOutputStream還有一個(gè)隊(duì)列叫ack queue，也是由packet組成的，等待Data Node的收到響應(yīng)，當(dāng)pipeline中的所有Data Node都表示已經(jīng)收到的時(shí)候，akc-queue才會(huì)把對(duì)應(yīng)的packet包移除掉。

(8)客戶端完成寫(xiě)數(shù)據(jù)后，調(diào)用close方法關(guān)閉寫(xiě)入流。

(9)DataStreamer把剩余的包都刷到pipeline里，然后等待ack信息，收到最后一個(gè)ack后，通知Data Node把文件標(biāo)示為已完成。

4 實(shí)驗(yàn)對(duì)比

通過(guò)上文描述，完成了基于云芯一號(hào)的分布式系統(tǒng)的設(shè)計(jì)和實(shí)現(xiàn)。接下來(lái)通過(guò)純壓縮測(cè)試對(duì)比實(shí)驗(yàn)和HDFS數(shù)據(jù)存儲(chǔ)速度對(duì)比實(shí)驗(yàn)來(lái)驗(yàn)證所提出的分布式文件系統(tǒng)的性能和優(yōu)越性。

4.1 純壓縮測(cè)試

純壓縮測(cè)試是為了對(duì)比傳統(tǒng)的基于CPU的各類HDFS軟壓縮特性和基于云芯一號(hào)芯片的硬件壓縮能力。為此測(cè)試了一組隨機(jī)大小(從最小數(shù)據(jù)大小7.27 MB到最大數(shù)據(jù)大小100 MB)，總共88 132 MB的數(shù)據(jù)集的壓縮速度，測(cè)試環(huán)境如下：CPU：Intel(R) Core(TM) i5-4590 CPU @ 3.30 GHz；MEM：DDR3 -1 333 MHz 64 GB。

基于云芯一號(hào)的硬件壓縮的進(jìn)程壓縮速度在1 508.7 MB/s(>1 500 MB/s)。與此同時(shí)，也將該數(shù)據(jù)集在傳統(tǒng)HDFS上的各類軟壓縮軟件上進(jìn)行了相同實(shí)驗(yàn)，得到壓縮性能對(duì)比表如表1所示。

從表1可以清楚地看出，基于硬件加速的云芯一號(hào)芯片在同樣大小的原始文件上，無(wú)論是壓縮速度、解壓速度還是壓縮后的文件大小都占據(jù)絕對(duì)的優(yōu)勢(shì)地位，尤其是壓縮速度和解壓速度兩個(gè)指標(biāo)更是較普通的軟件壓縮高10倍左右。為了更直觀地體現(xiàn)壓縮速度的對(duì)比性，將測(cè)試的隨機(jī)大小文件集群的壓縮速度進(jìn)行了同一坐標(biāo)對(duì)比，如圖6所示。

表1 各類壓縮軟件和云芯一號(hào)的文件壓縮性能對(duì)比

圖6 壓縮速度位于同一坐標(biāo)上對(duì)比

4.2 HDFS寫(xiě)入和讀取測(cè)試

在完成了純文件壓縮對(duì)比后，進(jìn)行了在HDFS平臺(tái)下的各類文件基于不同壓縮渠道的寫(xiě)入和讀取對(duì)比測(cè)試。

搭建了一個(gè)5節(jié)點(diǎn)的HDFS平臺(tái)，包括一個(gè)Client Node、一個(gè)Name Node、三個(gè)Data Node，其中云芯一號(hào)部署在Client Node上。分別測(cè)試了10 MB、100 MB、1 GB、10 GB的文件在不同壓縮方法下基于HDFS平臺(tái)的寫(xiě)入和讀取速度，如圖7所示。

圖7 HDFS上基于各類壓縮方式上寫(xiě)入讀取平均數(shù)據(jù)對(duì)比

選取了各類大小的文件，并測(cè)試了其在HDFS上經(jīng)過(guò)各類壓縮方式后的寫(xiě)入和讀取的速度，然后取其平均值。通過(guò)對(duì)比可知，基于云芯一號(hào)硬件加速卡的HDFS系統(tǒng)在各類大小文件的寫(xiě)入和讀取速度上都遠(yuǎn)遠(yuǎn)優(yōu)于傳統(tǒng)的軟件壓縮方式。從而在分布式文件系統(tǒng)的最基礎(chǔ)的功能上完成了實(shí)質(zhì)性的優(yōu)化和性能提升。

5 結(jié)論

本文著力于提高分布式文件處理的效率和性能，在從數(shù)據(jù)結(jié)構(gòu)以及算法應(yīng)用上進(jìn)行優(yōu)化外，也思考從數(shù)據(jù)處理的平臺(tái)和依托的硬件環(huán)境進(jìn)行思考和創(chuàng)新。因此，本文提出基于云芯一號(hào)硬件加速卡的分布式系統(tǒng)設(shè)計(jì)，在傳統(tǒng)的X86架構(gòu)上進(jìn)行硬件擴(kuò)充和優(yōu)化，在此基礎(chǔ)上采用Hadoop分布式文件系統(tǒng)對(duì)大量數(shù)據(jù)進(jìn)行處理。通過(guò)不同環(huán)境的實(shí)驗(yàn)結(jié)果對(duì)比，得出無(wú)論是在純文件壓縮上還是HDFS平臺(tái)中文件的寫(xiě)入讀取速度上，本文提出的系統(tǒng)在性能上都遠(yuǎn)遠(yuǎn)優(yōu)于傳統(tǒng)壓縮方式，為后續(xù)工作帶了更好的創(chuàng)新方向和架構(gòu)支撐。