壓縮對Hadoop性能影響研究*

向麗輝，繆 力,張大方

(湖南大學(xué)信息科學(xué)與工程學(xué)院，湖南 長沙 410086)

1 引言

隨著數(shù)據(jù)的高速增長，作為海量數(shù)據(jù)處理的代表性技術(shù)，MapReduce[1]思想越來越被重視。Hadoop作為MapReduce的一個開源實(shí)現(xiàn)，具有良好的擴(kuò)展性和容錯性，得到了廣泛的研究與應(yīng)用。然而，Hadoop在數(shù)據(jù)處理性能和效率方面與并行數(shù)據(jù)庫相差甚遠(yuǎn)。根據(jù)一項(xiàng)實(shí)驗(yàn)表明：在100節(jié)點(diǎn)規(guī)模上處理簡單查詢，DBMS-X(DataBase Management System-X)平均比Hadoop快了3.2倍，基于列存儲的數(shù)據(jù)庫Vertica平均比Hadoop快了2.3倍[2,3]；如果處理復(fù)雜的關(guān)聯(lián)查詢，數(shù)據(jù)庫的效率比Hadoop高出一個數(shù)量級。如何在保持Hadoop高擴(kuò)展性和高容錯性等特點(diǎn)的前提下提升Hadoop性能，已經(jīng)成為一個廣泛關(guān)注和研究的問題。

現(xiàn)階段Hadoop性能優(yōu)化自頂向下主要包括以下四個方面：(1)優(yōu)化Hadoop應(yīng)用程序，如減少不必要的reduce階段[4]；(2)Hadoop自身的優(yōu)化，主要包括參數(shù)調(diào)優(yōu)[5～7]、優(yōu)化調(diào)度算法[8]和日志監(jiān)控[9]；(3)優(yōu)化Hadoop的運(yùn)行環(huán)境，如操作系統(tǒng)的配置調(diào)優(yōu)；(4)改善Hadoop運(yùn)行的基礎(chǔ)設(shè)施。目前Intel公司已在致力發(fā)展提高Hadoop性能的硬件設(shè)備，其中包括使用固態(tài)磁盤SSD(Solid-State Drive)技術(shù)[10,11]。

多年來，在磁盤存儲容量快速增長的同時，磁盤I/O速度卻未能成比例地加快；現(xiàn)有的網(wǎng)絡(luò)帶寬越來越難以滿足人們的需求，I/O常常成為了磁盤與網(wǎng)絡(luò)的性能瓶頸。以HDFS(Hadoop Distributed File System)作為分布式文件系統(tǒng)的Hadoop能實(shí)現(xiàn)PB級的海量數(shù)據(jù)存儲，I/O問題更加明顯，因此I/O操作的優(yōu)化都有可能帶來Hadoop性能的提升。在Hadoop中，由一組配置參數(shù)來控制I/O，如塊大小、復(fù)制因子、壓縮算法等。這些參數(shù)直接影響Hadoop 的I/O性能：塊大小和內(nèi)存分配對Hadoop性能影響并不十分明顯[12]；減少復(fù)制因子能大大減少集群的寫操作[13]，從而減少磁盤訪問來提高Hadoop性能；壓縮技術(shù)是提高文件系統(tǒng)效率的重要手段之一，并行數(shù)據(jù)庫系統(tǒng)比Hadoop性能好很多的一個重要原因是使用了壓縮。Intel內(nèi)部測試表明：相比未壓縮，使用LZO的作業(yè)運(yùn)行時間減少60%[4]。從這些方面來看，壓縮是Hadoop I/O調(diào)優(yōu)的一個重要方法。

Figure 1 Flow diagram of MapReduce’s working圖1 MapReduce執(zhí)行流程圖

目前，國內(nèi)外關(guān)于Hadoop壓縮的探討，從作者所知的研究中，只有文獻(xiàn)[12]。 文獻(xiàn)[12]從一個能量角度評估了壓縮的好處：通過對四種不同壓縮比例的數(shù)據(jù)進(jìn)行實(shí)驗(yàn)，得出一個以壓縮比例為閾值的決策算法，該算法能平衡CPU代價和I/O收益，實(shí)現(xiàn)性能提升。但是，Hadoop輸入數(shù)據(jù)的壓縮比例是無法預(yù)知的，且未考慮壓縮與具體應(yīng)用之間的關(guān)系，也未考慮使用不同壓縮算法。本文探討在輸入數(shù)據(jù)壓縮比例未知的前提下，如何使用壓縮來提高Hadoop的性能。

文章結(jié)構(gòu)如下：第2節(jié)介紹了Hadoop以及Hadoop中的壓縮機(jī)制，得出一個壓縮使用策略。第3節(jié)搭建集群，對應(yīng)用使用不同的壓縮配置來驗(yàn)證策略的正確性，并探討策略在不同的應(yīng)用、不同的數(shù)據(jù)格式以及不同的數(shù)據(jù)規(guī)模中的可行性，總結(jié)出一個完整的壓縮使用策略。最后，在以上兩節(jié)的基礎(chǔ)上，分析了該壓縮策略的優(yōu)劣，并給出展望。

2 介紹

2.1 關(guān)于Hadoop

Hadoop由Doug Cutting即Apache Lucene創(chuàng)始人開發(fā)，源于開源的網(wǎng)絡(luò)搜索引擎Apache Nutch。用戶可以在不了解分布式底層細(xì)節(jié)的情況下開發(fā)分布式程序。Hadoop實(shí)現(xiàn)了一個分布式文件系統(tǒng)HDFS和一個分布式計(jì)算模型Hadoop MapReduce。在分布式集群中，HDFS存取MapReduce需要的數(shù)據(jù)，MapReduce負(fù)責(zé)調(diào)度與計(jì)算。兩者都是C/S(Client/Server)的服務(wù)模式：在HDFS中，Server為namenode，Client為datanodes;在MapReduce中，Server為master，Client為worker。后者的工作原理如圖1所示[14]：用戶程序首先產(chǎn)生一個master子進(jìn)程和多個worker子進(jìn)程；接下來master給各worker分配map任務(wù)，將map任務(wù)所需的輸入塊地址傳給worker；worker從HDFS中讀取相應(yīng)的輸入塊，用戶自定義的map函數(shù)會處理輸入塊，輸出即中間結(jié)果存于本地磁盤；reduce階段再通過網(wǎng)絡(luò)讀取相應(yīng)的reduce輸入，經(jīng)shuffle/copy 以及sort后的數(shù)據(jù)由用戶自定義的reduce函數(shù)處理，輸出結(jié)果存于HDFS中。

2.2 Hadoop中的壓縮

Hadoop通過參數(shù)配置來控制壓縮,在配置文件core-site.xml、mapred-site.xml中，可以從以下三個方面來配置壓縮：

(1)壓縮對象：Hadoop允許用戶壓縮任務(wù)的中間結(jié)果或者輸出，或者對兩者都進(jìn)行壓縮。同時，Hadoop會自動檢查輸入文件是否為壓縮格式，并在需要時進(jìn)行解壓縮。

(2)壓縮格式：Hadoop支持的各壓縮格式及特點(diǎn)如表1所示。

在Hadoop-0.20.203版本中，Hadoop自帶三種壓縮格式:Default、Gzip和Bzip2。Default 和Gzip[15]實(shí)現(xiàn)的是Lempel-Ziv 1977(LZ77)和哈夫曼編碼相結(jié)合的DEFLATE算法，兩者的區(qū)別在于Gzip格式在DEFLATE格式的基礎(chǔ)上增加了一個文件頭和一個文件尾。Bzip2[16]采用了新的壓縮算法，壓縮效果比傳統(tǒng)的LZ77/LZ78壓縮算法好。LZO(Lempel-Ziv-Oberhumer)[17]算法實(shí)現(xiàn)了以解壓速度著稱的一種LZ77變體，但LZO代碼庫擁有GPL的許可，因而未包含在Apache的發(fā)行版中，需要自行安裝、編譯[18]。是否包含多文件：表明壓縮文件是否支持文件邊界處分割，是否可包含一個或多個壓縮文件，當(dāng)前版本不支持zip,所以各壓縮格式都不支持包含多文件。是否可切分：表示壓縮算法是否可以搜索數(shù)據(jù)流的任意位置并進(jìn)一步往下讀取數(shù)據(jù)，它是處理海量數(shù)據(jù)時的一個重要屬性。例如一個1 GB的壓縮文件，如果該壓縮文件使用的壓縮算法支持可切分，塊大小為64 MB，該壓縮文件可分割成16塊，每塊都能由一個獨(dú)立的mapper處理，從而實(shí)現(xiàn)并發(fā)。如果該壓縮算法不支持可切分，該壓縮文件只能由一個mapper串行完成。目前，Hadoop支持的壓縮格式中：Bzip2 格式的壓縮文件，塊與塊間提供了一個48位的同步標(biāo)記，因而支持可切分;LZO格式的壓縮文件，加索引后也支持可切分。

(3)壓縮單元：Hadoop允許對任務(wù)的輸出以記錄或者塊的形式進(jìn)行壓縮，塊壓縮效果更好。

2.2.1 各種壓縮方式的性能

不同壓縮方式有不同的性能表現(xiàn)，Hadoop中各壓縮算法的性能表現(xiàn)如表2所示[19]。

Table 2 Comparison of performance amongdifferent compression algorithms in Hadoop

從表2中可知：在空間/時間性能的權(quán)衡中，Gzip/Default居于其他兩個壓縮方法之間，LZO是最快速度壓縮，Bzip2是最優(yōu)空間壓縮。

2.2.2 關(guān)于壓縮的研究

目前，Hadoop 0.20.x和Hadoop 0.23.x是Hadoop版本的兩個分支，其中CDH(Cloud Distribute Hadoop)版本從Hadoop 0.23.x發(fā)展而來，而Hadoop 0.20.x是當(dāng)前的Apache系列[20]。CDH的版本中，Hadoop還支持snappy壓縮算法[21]，如需使用snappy壓縮，只需調(diào)用snappy的壓縮器/解壓縮器即可。同時，數(shù)據(jù)壓縮往往是計(jì)算密集型的操作，考慮到性能，常使用本地庫(Native Library)來壓縮和解壓，這與HDFS的初衷不謀而合：移動計(jì)算要比移動數(shù)據(jù)便宜。Hadoop的DEFLATE、gzip和Snappy都支持算法的本地實(shí)現(xiàn)。

基于以上調(diào)研的啟發(fā)，可以得出一個壓縮使用策略，即LZO主要用于分布式計(jì)算場景，Bzip2主要用于分布式存儲場景。對于壓縮使用策略的正確性與可行性，以下以實(shí)驗(yàn)的方式對其進(jìn)行驗(yàn)證補(bǔ)充。

3 實(shí)驗(yàn)

3.1 不同的應(yīng)用與壓縮的關(guān)系

3.1.1 任務(wù)和數(shù)據(jù)

實(shí)驗(yàn)選擇了三個經(jīng)典的Hadoop基準(zhǔn)程序：即Grep、Wordcount和Terasort。這些基準(zhǔn)程序都包含map階段和reduce階段，能充分體現(xiàn)壓縮在各階段的作用。同時采用由Teragen產(chǎn)生的10 000 000個記錄(大小為1 GB)來進(jìn)行實(shí)驗(yàn)。

對于每種壓縮算法，它有多種設(shè)置。用0表示不壓縮，1表示壓縮，輸入-中間結(jié)果-輸出的配置有0-0-0、0-1-0、0-0-1、0-1-1這四種可能。其中0-0-1、0-1-1又可以分兩種情況，因?yàn)檩敵鼋Y(jié)果的壓縮類型分為block和record兩種。每種配置情況下重復(fù)運(yùn)行基準(zhǔn)程序10次，取平均值做比較。

集群規(guī)模為4，盡管一個4節(jié)點(diǎn)的集群規(guī)模比較小。一項(xiàng)集群產(chǎn)品的調(diào)查表明:70%的MR集群包括不到50臺機(jī)器，因此小集群上的發(fā)現(xiàn)很容易推廣到更大規(guī)模的集群[22]。在本文中，性能是指各benchmark的反應(yīng)時間。

3.1.2 不同的壓縮配置

為了簡化實(shí)驗(yàn)，除了復(fù)制因子為2，其他配置都采用默認(rèn)配置。Teragen格式下，Grep、Terasosrt和Wordcount采用不同的壓縮配置時運(yùn)行所需的時間分別如圖2～圖4所示。其中有些算法未配置成0-0-1-r和0-1-1-r，因?yàn)閷?shí)驗(yàn)需要的是最優(yōu)壓縮配置，如果0-0-1-b配置下平均運(yùn)行時間比0-0-1-r配置下少，且0-1-1-b配置下平均運(yùn)行時間比0-0-1-b配置多，為了簡化實(shí)驗(yàn)，就不再對壓縮方式采用0-1-1-r的配置。

Figure 2 Performance impact of different compression algorithms on Grep圖2 不同壓縮算法對Grep的性能影響

圖2顯示，Grep應(yīng)用的最優(yōu)壓縮配置方式為LZO-0-0-1-r，即使用LZO壓縮算法對任務(wù)輸出進(jìn)行記錄壓縮時效率最高。

Figure 3 Performance impact of different compression algorithms on Terasort圖3 不同壓縮算法對Terasort的性能影響

從圖3可知,Terasort應(yīng)用的最優(yōu)壓縮配置方式為LZO-0-1-1-r,即使用LZO壓縮算法對任務(wù)的中間結(jié)果和輸出進(jìn)行記錄壓縮時效率最高。圖4表明,Wordcount應(yīng)用的最優(yōu)壓縮配置方式也為LZO-0-1-1-r。

Figure 4 Performance impact of different compression algorithms on Wordcount圖4 不同壓縮算法對Wordcount的性能影響

比較各圖，發(fā)現(xiàn)各應(yīng)用使用合理的壓縮配置后，性能提高了10%～65%，其中以Wordcount使用LZO壓縮算法的表現(xiàn)最為突出。此外,對比HDFS讀、HDFS寫以及shuffle數(shù)據(jù)，雖然Bzip2情況下I/O最不緊張，但Bzip2壓縮和解壓縮速度慢，壓縮產(chǎn)生的CPU代價大于壓縮帶來的好處。所以在效率方面，LZO最好，Gzip和Default次之，Bzip2最差。對于Terasort、Wordcount這些計(jì)算密集型的程序，使用Bzip2的時間是不使用壓縮的兩倍，但使用Bzip2壓縮能節(jié)省約90%的空間。所以，壓縮使用策略是正確的，同時記錄壓縮效率高于塊壓縮。

3.2 不同的數(shù)據(jù)格式對壓縮的影響

Hadoop需要處理的數(shù)據(jù)類型很多，圖5表示各基準(zhǔn)采用由Teragen、Randomtextwriter和Randomwriter產(chǎn)生的1 GB數(shù)據(jù)作為輸入后，使用最好壓縮配置和不使用壓縮的性能表現(xiàn)。

Figure 5 Performance impact of compression_best vs uncompression on benchmarks in different input types圖5 不同格式下最好壓縮與不壓縮對各基準(zhǔn)的性能影響

對于不同的數(shù)據(jù)格式，各benchmarks性能效率變化如表3所示。

Table 3 Change of Benchmarks’ performance efficiencyunder different data formats

從表3可以看出，三種不同的數(shù)據(jù)格式下，benchmarks在Teragen數(shù)據(jù)格式下性能提高得最多，Randomtextwriter次之，Randomwriter最差。若對Teragen、Randomtextwriter和Randomwriter生成的文件分別采用Gzip壓縮，壓縮比例分別為0.13、0.25、1。因而可以得知：隨著壓縮比例的增大，各benchmarks使用壓縮的性能逐漸下降。其次， Randomtextwriter數(shù)據(jù)格式相比于Teragen：Grep和Terasort性能小幅度下降的同時，Wordcount性能降低了16倍，而Wordcount的輸出減少了20倍。因?yàn)閿?shù)據(jù)格式的不同，會使得同一應(yīng)用的中間結(jié)果和輸出不同，所以最好的壓縮配置帶來的效益也不一樣。同樣在Randomwriter格式下，Wordcount采用壓縮性能提高了24%，而Grep和Terasort分別下降3%和12%，結(jié)合未壓縮的輸入和壓縮后的輸出，發(fā)現(xiàn)該數(shù)據(jù)格式下，采用壓縮后Wordcount的輸出約為輸入的兩倍。因此：不使用壓縮時，若輸出遠(yuǎn)小于輸入，即使數(shù)據(jù)可壓縮比例高，性能不會大幅度提升；當(dāng)輸出大于或等于同比例規(guī)模的輸入且數(shù)據(jù)可壓縮比例高，在本實(shí)驗(yàn)中性能可提高35%；即使數(shù)據(jù)可壓縮性不高，如果輸出大于輸入的同比例規(guī)模，壓縮也能提高性能。因此，壓縮還是不壓縮，輸出大小是非常重要的，原因在于壓縮的屬性是針對中間結(jié)果和輸出設(shè)置的。從輸出大小可以判斷中間結(jié)果的大?。喝绻敵鲆?guī)模大，reduce前的中間結(jié)果不會小。無論對中間結(jié)果還是輸出進(jìn)行壓縮，需要一定的數(shù)據(jù)規(guī)模才能體現(xiàn)壓縮的價值。而輸出如何本質(zhì)上由數(shù)據(jù)格式和Hadoop應(yīng)用程序共同決定。

3.3 不同數(shù)據(jù)規(guī)模對壓縮的影響

Hadoop通常處理的數(shù)據(jù)規(guī)模很大，壓縮使用策略是否適用于大規(guī)模數(shù)據(jù)？圖6是Wordcount運(yùn)行由Teragen產(chǎn)生的1 GB、5 GB和10 GB數(shù)據(jù)的性能表現(xiàn)。實(shí)驗(yàn)環(huán)境為四個節(jié)點(diǎn)的集群，系統(tǒng)存儲能力為70 GB，復(fù)制因子為1。從圖6中可以看出：1 GB、5 GB和10 GB的數(shù)據(jù)，最好壓縮配置使得程序運(yùn)行的效率分別提高了53%、60%和55%。前兩個數(shù)據(jù)規(guī)模之間，壓縮帶來的效率是成上升狀態(tài)，原因首先在于數(shù)據(jù)規(guī)模越大，壓縮的效果更加明顯；其次，在數(shù)據(jù)增長的過程中，資源特別是CPU資源充足。后兩個數(shù)據(jù)規(guī)模之間，壓縮帶來的效益有所下降，主要原因是數(shù)據(jù)增倍，壓縮占用的CPU資源越來越多，集群資源出現(xiàn)了緊張狀態(tài)。因此，數(shù)據(jù)規(guī)模在一定程度上能使壓縮效益顯著，但數(shù)據(jù)越大，壓縮會占用更多的CPU資源，這樣會降低壓縮效益。

Figure 6 Performance of compression_best vs uncompression to Wordcount in different sizes圖6 不同數(shù)據(jù)規(guī)模下最好壓縮與不壓縮對Wordcount的性能影響

3.4 壓縮使用策略

通過實(shí)驗(yàn)，首先驗(yàn)證了壓縮使用策略：即一個應(yīng)用采用不同的壓縮方式時，使用LZO壓縮最好，因?yàn)長ZO是當(dāng)前最快速度壓縮，Bzip2雖然壓縮效果好，但壓縮速度慢，所以Bzip2壓縮算法適合分布式存儲的場景，而LZO壓縮算法適合分布式計(jì)算的場景；同時記錄壓縮比塊壓縮效率更高，雖然塊壓縮效果好，但速度慢；其次，不同數(shù)據(jù)格式代表不同的輸入類型，輸入的壓縮比例越大，使用壓縮帶來的性能會逐漸下降，對于類似圖片、視頻、音頻這些不可壓縮的數(shù)據(jù)，使用壓縮不一定能提高性能；對于不同的數(shù)據(jù)規(guī)模，發(fā)現(xiàn)數(shù)據(jù)規(guī)模越大，壓縮的效益越明顯，但數(shù)據(jù)規(guī)模增大到一定程度，壓縮使用的CPU資源過多所以效益會下降；最后同一種壓縮方式對不同應(yīng)用的影響不同，因?yàn)椴煌膽?yīng)用會產(chǎn)生不同數(shù)據(jù)規(guī)模的中間結(jié)果和輸出，在Hadoop中，相對輸入，對數(shù)據(jù)規(guī)模很少的中間結(jié)果和輸出進(jìn)行壓縮是沒意義的。

因此，得出以下壓縮使用策略：首先，針對應(yīng)用類型，若僅為存儲，則使用Bzip2進(jìn)行壓縮存儲，數(shù)據(jù)存儲之后再用來計(jì)算的，則使用LZO壓縮，并建立相應(yīng)索引，雖然Bzip2也支持可拆分，但它的解壓速度大大慢于LZO；若為計(jì)算型應(yīng)用，則首選LZO。其次，輸入數(shù)據(jù)的可壓縮性是無法預(yù)知的，所以根據(jù)負(fù)載來進(jìn)行判斷：選取小部分負(fù)載，運(yùn)行相應(yīng)的程序，對于文本類型的輸入，如果運(yùn)行后它的輸出大于輸入，那么采用中間和輸出都采用LZO壓縮；如果輸出遠(yuǎn)小于輸入，再或者是圖片、視頻類型的輸入，不建議采用壓縮，同時在數(shù)據(jù)庫中建立負(fù)載檔案，將其壓縮配置存于檔案中，以便運(yùn)行相同負(fù)載時使用；最后，計(jì)算應(yīng)用場景中，首選記錄壓縮。由此可以非常簡單地決定壓縮或不壓縮以及使用何種壓縮。對Hadoop的sort基準(zhǔn)使用該壓縮策略，由于sort基準(zhǔn)是計(jì)算類型的應(yīng)用，所以選擇LZO記錄壓縮，當(dāng)輸入是與圖片壓縮比例類似的Randomwriter隨機(jī)數(shù)文件時，壓縮策略為不使用壓縮。實(shí)驗(yàn)表明：該策略比使用最好壓縮配置的性能提高了26%。

4 結(jié)束語

本文分析了Hadoop文件壓縮方式及其特點(diǎn)，得出一個壓縮使用策略，通過實(shí)驗(yàn)分析了不同的文件壓縮方式對Hadoop性能的影響，以及壓縮使用策略在不同數(shù)據(jù)格式和不同的數(shù)據(jù)規(guī)模下的可行性，從而對壓縮使用策略進(jìn)行驗(yàn)證補(bǔ)充。雖然本文的實(shí)驗(yàn)結(jié)果很容易拓展到大規(guī)模的數(shù)據(jù)處理，但不同的應(yīng)用使用壓縮的表現(xiàn)不一樣，同時未考慮對中間結(jié)果和輸出分別采用不同的壓縮算法進(jìn)行測試。希望未來可以通過監(jiān)控不同負(fù)載在Hadoop集群上的運(yùn)行情況，分析壓縮帶來的CPU成本、量化壓縮的代價和收益，得到一個決策算法來決定如何合理使用壓縮。同時對已有的壓縮算法進(jìn)行改進(jìn)：如LZO需要建立索引才能切分，則可以設(shè)計(jì)一個簡化版的LZO算法，即使用定長的壓縮塊來避免建立索引的開銷；或者研究雙壓縮策略，對存儲類型的數(shù)據(jù)采用Bzip2壓縮來減少空間，對計(jì)算類型的數(shù)據(jù)采用LZO壓縮或者snappy壓縮來提高速度。

[1] Dean J, Ghemawat S. MapReduce:Simplified data processing on large clusters [J]. Communications of the ACM, 2008, 51(1):107-113.

[2] Abouzeid A, Bajda-Pawlikowski K, Abadi D, et al. HadoopDB:An architectural hybrid of MapReduce and DBMS technologies for analytical workloads [J]. Proceedings of the VLDB Endowment, 2009, 2(1):922-933.

[3] Stonebraker M, Abadi D, DeWitt D J, et al. MapReduce and parallel DBMSs:Friends or foes?[J]. Communications of the ACM, 2010, 53(1):64-71.

[4] Xin Da-xin,Liu Fei.Hadoop cluster performance optimization technology research [J].Computer Knowledge and Technology, 2011, 7(8):5484-5486. (in Chinese)

[5] Herodotou H. Hadoop performance models [J]. arXiv preprint arXiv:1106.0940, 2011:1-16.

[6] Babu S. Towards automatic optimization of MapReduce programs[C]∥Proc of the 1st ACM Symposium on Cloud Computing, 2010:137-142.

[7] Herodotou H, Babu S. Profiling, what-if analysis, and cost-based optimization of MapReduce programs [J]. Proceedings of the VLDB Endowment, 2011, 4(11):1111-1122.

[8] Zaharia M, Borthakur D, Sarma J S, et al. Job scheduling for multi-user mapreduce clusters[R]. Berkeley:Technical Report USB/EECS,EECS Department, University of California, 2009.

[9] Boulon J, Konwinski A, Qi R, et al. Chukwa, a large-scale monitoring system[C]∥Proc of CCA, 2008:1-5.

[10] Claburn T.Google plans to use Intel SSD storage in servers [EB/OL]. [2008-07-02]. http://www.informationwee- k.com.

[11] Wong G. SSD market overview [M]. Netherlands:Springer, 2013.

[12] Chen Y, Ganapathi A, Katz R H. To compress or not to compress-compute vs. I/O tradeoffs for mapreduce energy efficiency[C]∥Proc of 1st ACM SIGCOMM Workshop on Green Networking,2010:23-28.

[13] Chen Y, Keys L, Katz R H. Towards energy efficient mapreduce [R]. EECS Department, University of California, Berkeley, Tech. Rep. UCB/EECS-2009-109, 2009.

[14] White T. Hadoop:the definitive guide [M]. California:O’Reilly Media, 2012.

[15] wiki. Gzip[EB/OL]. [2013-6-24]. http://zh.wikipedia.org/wiki/Gzip.

[16] wiki. Bzip2[EB/OL]. [2013-6-24]. http://zh.wikipedia.org/wiki/Bzip2.

[17] wiki. LZO[EB/OL]. [2013-3-12]. http://zh.wikipedia.org/wiki/LZO.

[18] Kevinweil.Hadoop/LZO[EB/OL].[2011-03-11]. https://github.com/kevinweil/Hadoop-lzo.

[19] Ggjucheng. The compressed file supported by Hadoop and the advantages and disadvantages of algorithm[EB/OL]. [2012-04-23].http://tech.it168.com/a2012/0423/1340/000001340446.shtml. (in Chinese)

[20] Hadoop A. Hadoop [EB/OL]. [2009-03-06]. http://hadoop.apache.org.

[21] wiki.Snappy[EB/OL].[2013-8-31].http://en.wikipedia.org/wiki/Snappy_%28software%29.

[22] wiki.Hadoop Power -ByPage [EB/OL].[2011-03-11]:http://wiki.apacheorg/Hadoop/Powered By.

附中文參考文獻(xiàn)：

[4] 辛大欣, 劉飛. Hadoop 集群性能優(yōu)化技術(shù)研究 [J]. 電腦知識與技術(shù), 2011, 7(22)：5484-5486.

[19] Ggjucheng.Hadoop對于壓縮文件的支持及算法優(yōu)缺點(diǎn)[EB/OL].[2012-04-23].http://tech.it168.com/a2012/0423/1340/000001340446.shtml.