王全民,張 程,趙小桐,雷佳偉
(北京工業(yè)大學(xué) 計(jì)算機(jī)學(xué)院,北京 100124)
一種Hadoop小文件存儲(chǔ)優(yōu)化方案
王全民,張 程,趙小桐,雷佳偉
(北京工業(yè)大學(xué) 計(jì)算機(jī)學(xué)院,北京 100124)
Hadoop分布式文件系統(tǒng)(HDFS)適合處理和存儲(chǔ)大文件,在處理的文件體積較大時(shí)表現(xiàn)出色,但是在處理海量的小文件時(shí)效率和性能下降明顯,過多的小文件將會(huì)導(dǎo)致整個(gè)集群的負(fù)載過高。為了提高HDFS處理小文件的性能,提出了雙重合并算法-即基于文件之間的關(guān)聯(lián)關(guān)系和基于數(shù)據(jù)塊平衡的小文件合并算法,能夠?qū)⑿∥募奈募w積大小進(jìn)行均勻分布。通過該算法能夠進(jìn)一步提升小文件的合并效果,減少HDFS集群主節(jié)點(diǎn)內(nèi)存消耗,降低負(fù)載,有效降低合并所需的數(shù)據(jù)塊數(shù)量,最終能夠提高HDFS處理海量小文件的性能。
Hadoop分布式文件系統(tǒng);小文件;合并算法;文件關(guān)聯(lián)
隨著互聯(lián)網(wǎng)的高速發(fā)展,當(dāng)今社會(huì)所產(chǎn)生的數(shù)據(jù)量在急速增長,據(jù)統(tǒng)計(jì)目前人類一年產(chǎn)生的數(shù)據(jù)量的規(guī)模就相當(dāng)于人類進(jìn)入現(xiàn)代化以前所有歷史的總和。2014年國內(nèi)數(shù)據(jù)總量約為1.4 ZB,是2012年的3.5倍,預(yù)計(jì)2020年國內(nèi)產(chǎn)生的數(shù)據(jù)總量將超過8.6 ZB[1]。
Hadoop是一個(gè)能夠?qū)Υ髷?shù)據(jù)進(jìn)行分布式處理的軟件框架,以一種高效、高擴(kuò)展性、低成本、高可靠性的方式進(jìn)行數(shù)據(jù)處理[2]。Hadoop在互聯(lián)網(wǎng)領(lǐng)域應(yīng)用廣泛,例如Yahoo使用4 000個(gè)節(jié)點(diǎn)的Hadoop集群來支持廣告系統(tǒng)和Web搜索的研究;Facebook使用1 000個(gè)節(jié)點(diǎn)的集群運(yùn)行Hadoop,存儲(chǔ)日志數(shù)據(jù),支持其上的數(shù)據(jù)分析和機(jī)器學(xué)習(xí);百度用Hadoop處理每周200 TB的數(shù)據(jù),從而進(jìn)行搜索日志分析和網(wǎng)頁數(shù)據(jù)挖掘工作;中國移動(dòng)研究院基于Hadoop開發(fā)了“大云”(Big Cloud)系統(tǒng),不但用于相關(guān)數(shù)據(jù)分析,而且還對(duì)外提供服務(wù);淘寶將Hadoop系統(tǒng)應(yīng)用在存儲(chǔ)并處理電子商務(wù)交易的相關(guān)數(shù)據(jù)。
物聯(lián)網(wǎng)、電子商務(wù)、社交網(wǎng)絡(luò)和移動(dòng)互聯(lián)網(wǎng)的迅猛崛起,帶來的是海量數(shù)據(jù)的存儲(chǔ)問題,尤其在小型文件的存儲(chǔ)上,目前還沒有十分高效的解決方案[3]。目前存在一些針對(duì)大文件研發(fā)的文件系統(tǒng),如EXT4,Lustre,GFS,HDFS等,這些文件系統(tǒng)在架構(gòu)設(shè)計(jì)、數(shù)據(jù)管理和實(shí)現(xiàn)策略上都偏重于大文件,而在小文件的存儲(chǔ)效率和性能方面就會(huì)大幅下降[4]。
Hadoop分布式文件系統(tǒng)(Hadoop Distributed File System,HDFS)是Hadoop底層基礎(chǔ)架構(gòu)的存儲(chǔ)部分,是分布式計(jì)算中數(shù)據(jù)存儲(chǔ)管理的基礎(chǔ),現(xiàn)在已經(jīng)成為海量數(shù)據(jù)存儲(chǔ)集群部署的主流文件系統(tǒng)。處理大量小文件時(shí),HDFS中用于管理元數(shù)據(jù)的NameNode節(jié)點(diǎn)中的元數(shù)據(jù)量就會(huì)激增,導(dǎo)致NameNode內(nèi)存空間消耗過大、檢索效率降低等問題[5]。
文中提出一種基于文件關(guān)聯(lián)關(guān)系與基于數(shù)據(jù)塊平衡的小文件雙合并算法,用于優(yōu)化HDFS在小文件存儲(chǔ)中表現(xiàn)出的劣勢,使系統(tǒng)更加適合小文件存儲(chǔ)。
對(duì)于HDFS存儲(chǔ)小文件時(shí)面臨的諸多問題,目前已經(jīng)提出一些解決方案:
文獻(xiàn)[6]是Hadoop自帶的兩種解決方案,Hadoop Archive方法可以將小文件歸檔成一個(gè)相對(duì)較大的文件并存放在對(duì)應(yīng)的HDFS存檔工具中。該方案的優(yōu)點(diǎn)是能夠在一定程度上緩解大量小文件對(duì)NameNode內(nèi)存的消耗,缺點(diǎn)是對(duì)于小文件進(jìn)行歸檔后,之前的文件需要用戶自己刪除,創(chuàng)建之后不可更改,如需刪除或者增加就必須重新創(chuàng)建歸檔文件。SequenceFile序列文件是Hadoop提供的第二個(gè)小文件解決方案,序列文件用于存儲(chǔ)二進(jìn)制形式的鍵值對(duì),支持?jǐn)?shù)據(jù)壓縮。
文獻(xiàn)[7]針對(duì)WebGIS系統(tǒng)的特點(diǎn),提出了針對(duì)于HDFS小文件存儲(chǔ)問題的解決方案。根據(jù)地理信息系統(tǒng)(GIS)的特點(diǎn)將數(shù)據(jù)切分成kB大小的小文件存儲(chǔ)在分布式系統(tǒng)中。根據(jù)WebGIS數(shù)據(jù)的關(guān)聯(lián)特性將相鄰地理位置信息的小文件合并成一個(gè)大的文件進(jìn)行存儲(chǔ)。但是應(yīng)用面較為狹窄,龐大數(shù)量的互聯(lián)網(wǎng)小文件并沒有像GIS小文件一樣具有很強(qiáng)的關(guān)聯(lián)性。
文獻(xiàn)[8]針對(duì)海量的MP3小文件存儲(chǔ)在HDFS的情況,提出了利用MP3自身文件所包含的信息,通過歸類算法將MP3小文件歸并到SequenceFile文件中,同時(shí)引入索引機(jī)制來解決NameNode的內(nèi)存瓶頸問題。
文獻(xiàn)[9]針對(duì)教育資源小文件提出了基于HDFS的存儲(chǔ)優(yōu)化方案,利用教育資源中小文件之間的關(guān)聯(lián)關(guān)系,將大量小文件合并成大文件,通過索引和預(yù)取機(jī)制,緩解了NameNode的內(nèi)存負(fù)擔(dān)并且提高了Hadoop分布式文件系統(tǒng)對(duì)小文件的存儲(chǔ)和讀取效率。
文獻(xiàn)[10]針對(duì)HDFS中存儲(chǔ)小文件的不足,提出了一種基于DataNode緩存部分小文件元數(shù)據(jù)的策略。該策略讓Client在請(qǐng)求小文件時(shí)將大部分的小文件請(qǐng)求交由DataNode處理,當(dāng)DataNode不能處理請(qǐng)求時(shí)交給NameNode進(jìn)行處理,從而減少NameNode接收請(qǐng)求的次數(shù),提高整個(gè)分布式系統(tǒng)的性能,但沒有很好地解決NameNode元數(shù)據(jù)量因眾多小文件而猛增的問題。
2.1 方案設(shè)計(jì)
已有的小文件合并解決方案大都采用小文件數(shù)目達(dá)到一個(gè)設(shè)定閾值就進(jìn)行合并的方法,這樣很容易造成數(shù)據(jù)塊分布不均。文獻(xiàn)[11]在合并之前基于大量的歷史文件訪問日志分析小文件之間的關(guān)聯(lián)關(guān)系,然后在文件集合遍歷,將該文件與關(guān)聯(lián)文件合并成一個(gè)不大于64 M的大文件,然后存儲(chǔ)到HDFS。文獻(xiàn)[12]盡量將同一文件夾的文件合并到一起,文獻(xiàn)[13]也采取了達(dá)到合并閾值就進(jìn)行文件合并的思路處理小文件。文獻(xiàn)[14]利用文獻(xiàn)圖片之間的相關(guān)性來合并小文件。這一類的合并算法常以文件總體積溢出為合并條件,會(huì)造成合并后的塊內(nèi)存浪費(fèi),文件體積分布不均。如圖1所示,按照普通算法合并時(shí),數(shù)據(jù)塊的使用率較低。
圖1 普通文件合并算法過程示意圖
2.2 算法設(shè)計(jì)
文中提出了基于雙重合并的小文件合并算法。該算法的核心思想是根據(jù)小文件集合的文件體積分布,盡量將同一用戶的文件資源首先合并在一起,其次再將文件進(jìn)行均勻分布,合并成大文件,使每一個(gè)數(shù)據(jù)塊得到充分利用(即達(dá)到閾值64 M)。相比普通的文件合并,該方案能夠保證合并后的大文件不會(huì)被分割出多余的塊,也不會(huì)出現(xiàn)數(shù)據(jù)塊空間使用率過低的情況。該算法能夠在一定程度上最大化利用每一個(gè)數(shù)據(jù)塊的空間,使文件體積分布均勻,也能夠降低NameNode節(jié)點(diǎn)的內(nèi)存負(fù)載。其中的小文件合并策略是尋找合適的文件部分來盡可能填充數(shù)據(jù)塊,因此命名為PS算法(Partner Seeking)。
該算法中使用的數(shù)據(jù)結(jié)構(gòu)有三種:用戶文件映射、小文件存儲(chǔ)池和小文件合并隊(duì)列。小文件存儲(chǔ)池用于收集用戶上傳的小文件,是一個(gè)可配置的參數(shù),共有m個(gè),用于保證系統(tǒng)有可用的存儲(chǔ)池。共有n個(gè)小文件合并隊(duì)列,當(dāng)隊(duì)列中的文件總大小達(dá)到系統(tǒng)指定的文件大小時(shí),將指定的文件合并后存入HDFS。接下來將介紹文件合并策略與合并條件。
算法執(zhí)行流程如下:
(1) 根據(jù)配置文件創(chuàng)建m個(gè)小文件存儲(chǔ)池P、n個(gè)小文件合并隊(duì)列和用戶文件映射Map。
(2) 用戶上傳小文件時(shí),先查看是否達(dá)到當(dāng)前文件存儲(chǔ)池容量閾值,如果沒到,繼續(xù)上傳;如果達(dá)到閾值,上傳到其他文件存儲(chǔ)池。
(3) 對(duì)于當(dāng)前上傳的小文件,查看Map中是否有該用戶上傳的文件,如果有,則合并該用戶的小文件(此為第一次合并);如果沒有,文件信息加入Map中,Map中的文件按照第一次合并后的文件體積排列。
(4) 文件存儲(chǔ)池P達(dá)到閾值后,啟動(dòng)合并模塊(第二次合并),遍歷Map,找出體積最大的文件,如果該文件體積大于合并閾值的1/2,進(jìn)入步驟(5),如果該文件體積小于合并閾值的1/2,進(jìn)入步驟(6)。
(5) 將該文件放入當(dāng)前隊(duì)列,然后尋找該文件的伙伴文件,即尋找文件體積最接近合并閾值減去當(dāng)前遍歷隊(duì)列文件總體積的文件,找到伙伴文件后加入到當(dāng)前隊(duì)列,然后繼續(xù)尋找當(dāng)前隊(duì)列的伙伴文件直到找不到伙伴文件為止,此時(shí)一個(gè)隊(duì)列完成。對(duì)該隊(duì)列進(jìn)行合并,開啟新的隊(duì)列循環(huán)步驟(4),直到隊(duì)列用完。
(6) 如果當(dāng)前文件體積小于文件合并閾值的1/2,將當(dāng)前文件存入當(dāng)前隊(duì)列,繼續(xù)遍歷Map找到最大的文件加入到當(dāng)前隊(duì)列,直到隊(duì)列的總體積大于文件合并閾值的1/2,進(jìn)入到步驟(5)。
(7) 前面的6步就是文件合并階段。
經(jīng)過PS算法合并后的圖1實(shí)例,其合并效果如圖2所示。
圖2 PS算法文件合并效果
在此實(shí)驗(yàn)中,文中的Hadoop集群是由一個(gè)NameNode節(jié)點(diǎn)、兩個(gè)DataNode節(jié)點(diǎn)構(gòu)成。實(shí)驗(yàn)環(huán)境:操作系統(tǒng)為Ubuntu14.04,CPU為Intel(R)Core(TM)i5 2.4GHz,內(nèi)存為4GB,硬盤大小為320G,搭建了完全的虛擬機(jī)分布式Hadoop集群。Hadoop版本為2.5,Java運(yùn)行環(huán)境版本為1.7。HDFS中數(shù)據(jù)塊默認(rèn)采用64MB,每個(gè)數(shù)據(jù)塊的副本數(shù)量為2。
為了驗(yàn)證提出算法的可行性,收集了一系列的測試用小文件,測試的文件集合總大小是4.78GB,文件體積小于5MB以下的小文件占所有測試文件集合大小的81%,而5~64MB的文件則用來觀察文件合并效果。
3.1 向HDFS導(dǎo)入文件消耗對(duì)比實(shí)驗(yàn)
圖3使用柱狀圖更為直觀地表示了三種導(dǎo)入算法的時(shí)間消耗(單位:s)表現(xiàn)對(duì)比。經(jīng)過PS算法合并后的文件總數(shù)為77個(gè),正常導(dǎo)入的文件總數(shù)為1 640個(gè),采用普通的單文件合并算法合并后的文件總數(shù)為87個(gè)。三種導(dǎo)入方法的數(shù)據(jù)塊大小采用相同的64 M。通過對(duì)比測試實(shí)驗(yàn)可以看出,在導(dǎo)入文件消耗方面,PS合并算法導(dǎo)入要比正常導(dǎo)入提升39.4%的效率,和單文件導(dǎo)入的效率基本持平??梢钥闯觯ㄟ^PS合并算法進(jìn)行合并后大大減少了總的大文件數(shù)目,相比于單文件合并算法在數(shù)據(jù)塊使用量方面也有一些下降,主要是因?yàn)镻S合并算法通過文件關(guān)聯(lián)關(guān)系和文件體積的重新分布來進(jìn)行小文件的合并,能夠達(dá)到比正常導(dǎo)入和單文件合并算法更好的效果。上傳文件消耗時(shí)間與單文件合并算法基本持平。
圖3 小文件導(dǎo)入消耗時(shí)間對(duì)比
3.2 NameNode節(jié)點(diǎn)內(nèi)存消耗對(duì)比
圖4使用柱狀圖的形式更為直觀地對(duì)比了三種導(dǎo)入算法的名字節(jié)點(diǎn)(NameNode)的內(nèi)存消耗。正常導(dǎo)入NameNode內(nèi)存消耗為24 600字節(jié),合并后的文件數(shù)量為1 640個(gè);單文件合并算法合并導(dǎo)入的NameNode消耗為13 050字節(jié),合并后的文件數(shù)量為87個(gè);而PS合并算法合并導(dǎo)入的NameNode內(nèi)存消耗為11 550字節(jié),合并后的文件數(shù)量為77個(gè)。通過實(shí)驗(yàn)測試相比于正常導(dǎo)入,PS文件合并算法對(duì)NameNode節(jié)點(diǎn)的內(nèi)存消耗具有十分顯著的效果,節(jié)約了95.3%的內(nèi)存空間。單文件合并算法和PS合并算法都考慮到了數(shù)據(jù)塊大小對(duì)于內(nèi)存消耗的影響,但PS合并算法較之單文件合并算法,NameNode節(jié)點(diǎn)內(nèi)存消耗節(jié)省了11.5%。由此可見,通過文件體積分布和利用文件關(guān)聯(lián)關(guān)系,PS文件合并算法有更好的效率和空間使用率。
圖4 NameNode內(nèi)存消耗對(duì)比
文中提出了一種基于HDFS的小文件合并算法-PS合并算法,能夠優(yōu)化HDFS在小文件存儲(chǔ)方面表現(xiàn)出的不足,通過對(duì)文件關(guān)聯(lián)關(guān)系的挖掘和文件體積的合理分布實(shí)現(xiàn)對(duì)小文件的合并重組,大幅降低了Hadoop集群中NameNode節(jié)點(diǎn)的內(nèi)存消耗,減少了上傳大量小文件所需時(shí)間。接下來的工作中可以在文件類型方面進(jìn)行合并工作的研究,探討文件類型對(duì)于數(shù)據(jù)處理以及文件合并的影響,以便能達(dá)到更好的效果。
[1] 李國琦. 中國產(chǎn)業(yè)互聯(lián)網(wǎng)峰會(huì)[EB/OL]. 2015.http://www.sootoo.com/content/548884.shtml.
[2] Finta I,Farkas L,Szenasi S,et al.Buffering strategies in HDFS environment with STORM framework[C]//16th IEEE international symposium on computational intelligence and informatics.[s.l.]:IEEE,2015:297-302.
[3] 杜忠暉,何 慧,王 星.一種Hadoop小文件存儲(chǔ)優(yōu)化策略研究[J].智能計(jì)算機(jī)與應(yīng)用,2015,5(3):28-32.
[4] Zhang Q F,Zhang W D,Li W J,et al.Cloud storage system for small file based on P2P[J].Journal of Zhejiang University (Engineering Science),2013,47(1):7-8.
[5] Mackey G,Sehrish S,Wang J.Improving metadata management for small files in HDFS[C]//IEEE international conference on cluster computing and workshops.[s.l.]:IEEE,2009:1-4.
[6] Apache.The homepage of Hadoop[EB/OL].2012.http://Hadoop.apache.org/.
[7] 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]//IEEE international conference on cluster computing and workshops.[s.l.]:IEEE,2009:1-8.
[8] 趙曉永,楊 揚(yáng),孫莉莉,等.基于Hadoop的海量MP3文件存儲(chǔ)架構(gòu)[J].計(jì)算機(jī)應(yīng)用,2012,32(6):1724-1726.
[9] 游小容,曹 晟.海量教育資源中小文件的存儲(chǔ)研究[J].計(jì)算機(jī)科學(xué),2015,42(10):76-80.
[10] 江 柳.HDFS下小文件存儲(chǔ)優(yōu)化相關(guān)技術(shù)研究[D].北京:北京郵電大學(xué),2011.
[11] 李 鐵,燕彩蓉,黃永鋒,等.面向Hadoop分布式文件系統(tǒng)的小文件存取優(yōu)化方法[J].計(jì)算機(jī)應(yīng)用,2014,34(11):3091-3095.
[12] 張 丹.HDFS中文件存儲(chǔ)優(yōu)化的相關(guān)技術(shù)研究[D].南京:南京師范大學(xué),2013.
[13] 胡海峰,賈玉辰.一種Hadoop存取海量小文件的優(yōu)化方法:CN,CN104536959A[P].2015-04-22.
[14] 張春明,芮建武,何婷婷.一種Hadoop小文件存儲(chǔ)和讀取的方法[J].計(jì)算機(jī)應(yīng)用與軟件,2012,29(11):95-100.
A Small Hadoop File Storage Optimization Scheme
WANG Quan-min,ZHANG Cheng,ZHAO Xiao-tong,LEI Jia-wei
(School of Computer Science,Beijing University of Technology,Beijing 100124,China)
The performance of Hadoop Distributed File System (HDFS) in dealing with the problem of storing and handling large files is excellent,but the performance and efficiency is down significantly when dealing with a huge number of small files.Too many small files will lead to the high load of entire cluster.In order to improve the performance of HDFS handling small files,the double-merging algorithm is put forward based on the relationship between files and merging algorithm based on the data block balance and used for uniform distribution of file size for small file.The program can further improve the effect of small file merging,decreasing the memory spending of HDFS cluster master node,reducing workload,and effectively declining the number of data blocks combined.Eventually the performance of HDFS is improved when dealing with large small files.
HDFS;small files;merge algorithm;file connection
2016-01-20
2016-05-11
時(shí)間:2016-10-24
國家自然科學(xué)基金資助項(xiàng)目(61272500)
王全民(1963-),男,副教授,博士,碩士生導(dǎo)師,CCF高級(jí)會(huì)員,研究方向?yàn)榫W(wǎng)絡(luò)與信息安全;張 程(1991-),男,碩士研究生,研究方向?yàn)榉植际较到y(tǒng)與網(wǎng)絡(luò)與信息安全。
http://www.cnki.net/kcms/detail/61.1450.TP.20161024.1113.036.html
TP301
A
1673-629X(2016)11-0041-04
10.3969/j.issn.1673-629X.2016.11.009