摘  要： 針對目前Hadoop平臺不能高效處理海量小文件而出現(xiàn)的小文件問題，提出一種基于曲線擬合最小二乘法的確定Hadoop平臺下何為小文件的方法。該方法首先確定小文件訪問時間的量化方法，然后采用訪問時間作為確立何為小文件的影響因子，通過對不同數(shù)據(jù)集大小的不同訪問時間的實(shí)驗(yàn)，最終結(jié)合線性擬合的相關(guān)知識找到了小文件大小的量化方法。

　　關(guān)鍵詞： Hadoop；小文件問題；曲線擬合的最小二乘法；線性擬合

　　Hadoop[1]是一個具有高擴(kuò)展性、高可靠性、高容錯性和高效性的開源軟件系統(tǒng)，它已成為互聯(lián)網(wǎng)、金融、生物信息學(xué)等領(lǐng)域進(jìn)行大數(shù)據(jù)分析和處理的代表性云計(jì)算平臺。它由Hadoop Distributed File System（HDFS）[2]和MapReduce[3]兩部分組成，其中，MapReduce主要用來處理數(shù)據(jù)密集型數(shù)據(jù)，而HDFS則主要負(fù)責(zé)大數(shù)據(jù)的存儲。

　　HDFS的產(chǎn)生得益于Google File System（GFS）[4]，它遵循一次寫、多次讀的流數(shù)據(jù)訪問模式，采用Master-Slave架構(gòu)，其中的Master，即NameNode，作為單一的節(jié)點(diǎn)來管理整個文件系統(tǒng)中所存儲數(shù)據(jù)的元數(shù)據(jù)。為了快速響應(yīng)客戶端的讀寫請求，NameNode將文件的元數(shù)據(jù)存放在內(nèi)存當(dāng)中。HDFS設(shè)計(jì)之初就是為了處理海量大文件的，因此，它能高效地存儲和處理海量大文件的讀寫請求。然而，HDFS不能高效地處理海量小文件，小文件問題[5]由此產(chǎn)生。目前，學(xué)術(shù)界關(guān)注的小文件問題有：（1）海量小文件耗費(fèi)主節(jié)點(diǎn)內(nèi)存；（2）海量小文件的I/O效率低，沒有一種優(yōu)化機(jī)制來提高I/O性能；（3）HDFS下沒有明確的能夠區(qū)分何為小文件的大小文件分界點(diǎn)；（4）海量小文件的放置未考慮文件相關(guān)性[6]。針對大小文件的分界點(diǎn)問題提出一種確定何為小文件的方法。在深入研究HDFS存儲和訪問機(jī)制的基礎(chǔ)上，經(jīng)過海量小文件訪問、指數(shù)擬合和線性擬合等過程，確定了大小文件的臨界點(diǎn)。

　　1 相關(guān)研究

　　Hadoop集群分為NameNode和DataNode兩部分，NameNode負(fù)責(zé)HDFS中文件元數(shù)據(jù)的存放和對客戶端訪問的控制，DataNode則負(fù)責(zé)提供塊存儲，為客戶端的I/O請求提供服務(wù)，并根據(jù)NameNode的指令執(zhí)行塊的讀寫操作。其中，NameNode為了向客戶端高效地提供元數(shù)據(jù)信息，將每個文件的元數(shù)據(jù)信息都存放在內(nèi)存當(dāng)中，包括文件名、相應(yīng)文件對應(yīng)的塊號以及持有這些塊的DataNode信息。因此，當(dāng)客戶端請求創(chuàng)建、讀、寫和刪除等操作時，客戶端都需要先向主節(jié)點(diǎn)查詢元數(shù)據(jù)信息，然后跟相應(yīng)的數(shù)據(jù)節(jié)點(diǎn)交互，執(zhí)行需要的操作。

　　然而，NameNode節(jié)點(diǎn)是單一的，其對應(yīng)的內(nèi)存大小也是固定的，當(dāng)一個大于文件塊大小的文件存儲到HDFS中時，產(chǎn)生的元數(shù)據(jù)僅僅由文件大小決定，但當(dāng)海量小文件存儲到HDFS中時，每個小文件都會形成一個文件塊，因此會產(chǎn)生相當(dāng)大的元數(shù)據(jù)信息，例如，假設(shè)一個文件的文件塊會產(chǎn)生150 B的元數(shù)據(jù)信息，對于1GB的文件，會被分成16個大小為64 MB的塊，此時會產(chǎn)生2.4KB的元數(shù)據(jù)，然而，對于10 600個大小為100 KB的文件（總大小1 GB），這種情況下將會產(chǎn)生1.5 MB的元數(shù)據(jù)信息。因此，海量小文件會占用大量的主節(jié)點(diǎn)內(nèi)存，進(jìn)而當(dāng)處理海量小文件時，單一的主節(jié)點(diǎn)內(nèi)存就會成為瓶頸，進(jìn)而影響小文件的存儲和訪問性能，小文件問題由此而生。

　　參考文獻(xiàn)[7]指出小文件就是那些文件大小明顯小于HDFS默認(rèn)塊大小64 MB的文件，海量小文件的產(chǎn)生會限制許多包含大量小文件的應(yīng)用獲益于Hadoop平臺。Liu等人[8]針對包含大量小文件的典型應(yīng)用WebGIS，提出了一種基于HDFS的提升小文件I/O性能的方法。基本思想就是通過小文件合并成大文件來減少文件的數(shù)目，然后為每個文件建立索引，同時考慮WebGIS的文件相關(guān)特征。實(shí)驗(yàn)表明，該方法確實(shí)能夠提高Hadoop處理WebGIS下相關(guān)小文件的處理性能，但它們將文件大小小于16 MB的文件作為小文件，并且沒有具體的理論分析和實(shí)驗(yàn)來證明16 MB就是大小文件的臨界值。

　　2 小文件量化過程

　　2.1 Hadoop下小文件訪問時間量化

　　當(dāng)從HDFS中訪問一個文件時，訪問過程如下。

　　（1）客戶端通過初始化RPC（Remote Procedure Calls）[9]請求向NameNode發(fā)送讀指令，其時間開銷記為tCN；

　　（2）NameNode在內(nèi)存中查詢相應(yīng)文件的元數(shù)據(jù)，時間開銷記為tmetadata；

　　（3）所需文件的元數(shù)據(jù)返回到客戶端，時間開銷記為tNC；

　　（4）客戶端向相關(guān)DataNode發(fā)送讀取指令，時間開銷記為tCD；

　　（5）DataNode從磁盤中取出所需文件的文件塊，時間開銷記為tdisk；

　　（6）所需文件的相應(yīng)文件塊返回到客戶端，所需時間記為tnetwork。

　　其中，因?yàn)閠CN和tCD是發(fā)送指令所帶來的開銷，通常作為常量；同時，由于元數(shù)據(jù)非常小，tmetadata也可以當(dāng)做常量；tnetwork與所讀取文件的長度（L）和網(wǎng)絡(luò)傳輸速度（V）有關(guān)，因此，它可以表示為δnetwork（L/V）。

　　假設(shè)有N個不同的小文件，文件長度分別表示為L1，L2，L3，…，Ln，那么N個文件的訪問時間可以表示為：

　　其中，因?yàn)閷τ谛∥募碇v，每一個文件僅僅有一個塊，所以讀取塊數(shù)和文件的個數(shù)是相等的，即M和N相等，那么式（1）還可表示為：

　　2.2 文件隨機(jī)訪問算法

　　文件隨機(jī)訪問算法通過N來控制隨機(jī)數(shù)的產(chǎn)生個數(shù)，進(jìn)而來控制隨機(jī)訪問的文件，然后調(diào)用HDFS提供的訪問API來獲取分布式文件系統(tǒng)中存放的文件，最終返回訪問指定文件個數(shù)的文件所需要的時間，具體算法偽代碼如下。

　　Input：SmallFile

　　Output：AccessTime

　　Create a collection//創(chuàng)建一個集合

　　getConfiguration（）//獲取HDFS必要的文件配置信息

　　for（int i=0；i<N；i++）{

　　//N為隨機(jī)下載的文件個數(shù)

　　int j=getRandom（）//獲取一個隨機(jī)數(shù)

　　add（j）//將隨機(jī)數(shù)添加到集合中

　　}

　　collectionIterator（）；//創(chuàng)建一個迭代器

　　Long t1=getStarttime（）

　　while（iterator.hasNextNumber）{

　　getNextValue（）//獲取迭代器中的隨機(jī)數(shù)

　　Path src//HDFS中符合相應(yīng)隨機(jī)數(shù)的文件路徑

　　Path dst//訪問隨機(jī)文件的存放路徑

　　copyToLocalFile（src，dst）

　　}

　　Close（）//關(guān)閉分布式文件系統(tǒng)

　　long t2=getStopTime（）

　　output（“AceessTime”，t2-t1）

　　2.3 曲線擬合的最小二乘法

　　若要求一個函數(shù)y=S*（x）與所給數(shù)據(jù){（xi，yi），i=0，1，…，m}擬合，若記誤差δi=y-S*（xi）-yi（i=0，1，…，m），δ=（δ0，δ1，…，δm）T，設(shè)?漬0（x），?漬1（x），…，?漬n（x）是C[a，b]上線性無關(guān)函數(shù)族，在?漬=span{?漬0（x），?漬1（x），…，?漬n（x）}中找一個函數(shù)S*（x），使誤差平方和

　　以上就是一般的最小二乘逼近，用幾何語言說，就成為曲線擬合的最小二乘法[10]。

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

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

　　實(shí)驗(yàn)所用Hadoop平臺包含6臺PC，其中1臺作為NameNode，其他5臺為DataNode，每臺機(jī)器的配置為：Intel Core 2（2.99 GHz）處理器，2 GB內(nèi)存，160 GB硬盤。

　　所有節(jié)點(diǎn)均連接在1.0 Gb/s的以太網(wǎng)中。每臺機(jī)器的軟件環(huán)境為：操作系統(tǒng)采用內(nèi)核為3.5.0-25的Ubuntu 12.04，集群的Hadoop版本為1.1.2，Java版本是JDK 7.0。

　　其中HDFS的默認(rèn)副本數(shù)為3，塊大小默認(rèn)為64 MB。

　　3.2 數(shù)據(jù)集

　　實(shí)驗(yàn)所采用的數(shù)據(jù)集共有23個，數(shù)據(jù)集內(nèi)容來自于China Daily的新聞稿，各個數(shù)據(jù)集分別命名為ds1，ds2，…ds23。每個數(shù)據(jù)集分別包含10 000個文件，數(shù)據(jù)集大小有0.5 MB~64 MB不等，具體分布情況如圖1所示。

　　3.3 實(shí)驗(yàn)方法

　　分別將上述數(shù)據(jù)集上傳到空白的HDFS中，然后采用上文所提到的文件隨機(jī)訪問算法隨機(jī)獲取500個文件到本地文件系統(tǒng)，同時記錄下程序反饋的每個數(shù)據(jù)集的訪問時間。

　　每個數(shù)據(jù)集的訪問時間測試分別進(jìn)行7次，然后舍棄其中的兩個最大值和兩個最小值，剩余的3組值取平均，最后以平均值作為每個數(shù)據(jù)集的實(shí)驗(yàn)所得訪問時間。通過這種方法來過濾掉因網(wǎng)絡(luò)擁塞或者其他未知因素導(dǎo)致的噪聲點(diǎn)。

　　測得每組數(shù)據(jù)的平均訪問時間后，分別計(jì)算每組數(shù)據(jù)集的平均訪問速率，當(dāng)HDFS默認(rèn)塊大小為64 MB時，其訪問速率與文件大小在曲線擬合后的關(guān)系如圖2所示。

　　根據(jù)圖2圖像的變化規(guī)律可知，小文件數(shù)據(jù)集的訪問速率在一定范圍內(nèi)變化顯著，隨著數(shù)據(jù)集文件大小的增大，變化逐步趨于平緩。根據(jù)指數(shù)函數(shù)的特性，為了更好地觀察其變化規(guī)律，分別對x和y軸取對數(shù)，由圖3可明顯地看到前8個數(shù)據(jù)點(diǎn)在一條直線上，而除此之外的其他數(shù)據(jù)點(diǎn)在另外的直線上，然后采用線性擬合的方法，得到兩直線交點(diǎn)，進(jìn)而得到對應(yīng)直線交點(diǎn)的文件大小為4.38 MB。

　　此外，針對dfs.blocksize默認(rèn)塊大小為48 MB的情況也進(jìn)行相同的實(shí)驗(yàn)，得到的結(jié)果如圖4所示。其中，文件塊大小為48 MB的線性擬合后直線交點(diǎn)處所對應(yīng)的文件臨界值大小為4.41，很明顯，文件塊大小在64 MB和48 MB兩種情況下，這個臨界點(diǎn)文件大小幾乎相同，由此確定了大小文件的臨界值大小。

　　提出一種確定Hadoop平臺下大小文件分界點(diǎn)的方法，該方法首先確定了Hadoop平臺下小文件的訪問時間量化方法，然后通過客戶端隨機(jī)訪問HDFS中不同大小數(shù)據(jù)集的不同訪問時間，并且結(jié)合曲線擬合的最小二乘法相關(guān)知識，通過實(shí)驗(yàn)找到了大小文件的臨界點(diǎn)。今后的工作將考慮通過對其他相關(guān)因子的量化來進(jìn)一步細(xì)化該臨界點(diǎn)的獲取方法。此外，計(jì)劃在結(jié)合大小文件的臨界點(diǎn)問題的基礎(chǔ)上，針對小文件問題進(jìn)行進(jìn)一步研究，并且結(jié)合文件合并、文件的分布式索引和相應(yīng)的緩存預(yù)提取等機(jī)制來優(yōu)化Hadoop平臺下海量小文件的讀取和存儲性能。

　　參考文獻(xiàn)

　　[1] WHITE T. Hadoop： The Definitive Guide， 2nd[M]. California： O′Reilly Media， 2009.

　　[2] SHVACHKO K， KUANG H， RADIA S， et al. The hadoop distributed file system[C]. Proceedings of IEEE 26th Symposium on Mass Storage Systems and Technologies， Incline Village， USA： IEEE Press，2010：1-10.

　　[3] DEAN J， GHEMAWAT S. MapReduce： simplified data processing on large clusters[J]. Communications of the ACM，2008， 51（1）：107-111.

　　[4] SEHRISH S， MACKEY G， WANG J， et al. MRAP： a novel MapReduce-based framework to support HPC analytics applications with access patterns[C]. Proceedings of the 19th ACM International Symposium on High Performance Distributed Computing. New York， USA： ACM Press， 2010：107-118.

　　[5] Liu Xiaojun， Xu Zhengquan， Gu Xin. Study on the small files problem of Hadoop[C]. Proceedings of 2012 IEEE 2nd International Conference on Cloud Computing and Intelligence Systems， Hangzhou， China： IEEE Press，2012：278-281.

　　[6] DONG B， QIU J， ZHENG Q， et al. A novel approach to improving the efficiency of storing and accessing small files on hadoop： A case study by PowerPoint files[C]. Proceedings of the IEEE International Conference on Services Computing. Florida， USA： IEEE Press，2010：65-72.

　　[7] The small files problem[EB/OL]. http：//www.cloudera.com/blog/2009/02/the-smallfiles-problem/，2009.

　　[8] Liu X， Han J， Zhong Y， et al. Implementing  WebGIS on Hadoop： a case study of improving small file I/O Performance on HDFS[C]. Proceedings of the IEEE international conference on cluster computing and workshops. New Orleans， USA： IEEE Press，2009：1-8.

　　[9] CHANDRASEKAR S， DAKSHINAMURTHY R， SESHAK-UMAR P G， et al. A novel indexing scheme for efficient handling of small files in Hadoop distributed file system[C]. Proceedings of the International Conference on Computer Communication and Informatics. Coimbatore， USA： IEEE Press，2013： 1-8.

　　[10] 陳珂，鄒權(quán).融入時間關(guān)聯(lián)因子曲線擬合的交通流異常挖掘方法[J].計(jì)算機(jī)工程與設(shè)計(jì)，2013，34（7）：2561-2565.