Hadoop在MapReduce中使用壓縮詳解
Hadoop對于壓縮文件的支持
如果我們壓縮的文件有相應壓縮格式的擴展名（比如lzo，gz，bzip2等），hadoop就會根據擴展名去選擇解碼器解壓。
hadoop對每個壓縮格式的支持,詳細見下表：
如果壓縮的文件沒有擴展名，則需 要在執行mapreduce任務的時候指定輸入格式.
- hadoop jar /usr/home/hadoop/hadoop-0.20.2/contrib/streaming/hadoop-streaming-0.20.2-CD H3B4.jar
- -file /usr/home/hadoop/hello/mapper.py -mapper /usr/home/hadoop/hello/mapper.py
- -file /usr/home/hadoop/hello/reducer.py -reducer /usr/home/hadoop/hello/reducer.py
- -input lzotest -output result4
- -jobconf mapred.reduce.tasks=1
- *-inputformat org.apache.hadoop.mapred.LzoTextInputFormat*
hadoop下各種壓縮算法的壓縮比，壓縮時間，解壓時間見下表:
| 壓縮算法 | 原始文件大小 | 壓縮后的文件大小 | 壓縮速度 | 解壓縮速度 |
| gzip | 8.3GB | 1.8GB | 17.5MB/s | 58MB/s |
| bzip2 | 8.3GB | 1.1GB | 2.4MB/s | 9.5MB/s |
| LZO-bset | 8.3GB | 2GB | 4MB/s | 60.6MB/s |
| LZO | 8.3GB | 2.9GB | 49.3MB/S | 74.6MB/s |
hadoop各種壓縮算法的優缺點簡述
在考慮如何壓縮那些將由MapReduce處理的數據時，考慮壓縮格式是否支持分割是很重要的。考慮存儲在HDFS中的未壓縮的文件，其大小為1GB，HDFS的塊大小為64MB，所以該文件將被存儲為16塊，將此文件用作輸入的MapReduce作業會創建1個輸人分片（split ,也稱為“分塊”。對于block，我們統一稱為“塊”。）每個分片都被作為一個獨立map任務的輸入單獨進行處理。
現在假設。該文件是一個gzip格式的壓縮文件，壓縮后的大小為1GB。和前面一樣，HDFS將此文件存儲為16塊。然而，針對每一塊創建一個分塊是沒有用的，因為不可能從gzip數據流中的任意點開始讀取，map任務也不可能獨立于其他分塊只讀取一個分塊中的數據。gzip格式使用DEFLATE來存儲壓縮過的數據，DEFLATE將數據作為一系列壓縮過的塊進行存儲。問題是，每塊的開始沒有指定用戶在數據流中任意點定位到下一個塊的起始位置，而是其自身與數據流同步。因此，gzip不支持分割(塊)機制。
在這種情況下，MapReduce不分割gzip格式的文件，因為它知道輸入是gzip壓縮格式的(通過文件擴展名得知)，而gzip壓縮機制不支持分割機制。這樣是以犧牲本地化為代價:一個map任務將處理16個HDFS塊。大都不是map的本地數據。與此同時，因為map任務少，所以作業分割的粒度不夠細，從而導致運行時間變長。
在我們假設的例子中，如果是一個LZO格式的文件，我們會碰到同樣的問題，因為基本壓縮格式不為reader提供方法使其與流同步。但是，bzip2格式的壓縮文件確實提供了塊與塊之間的同步標記(一個48位的PI近似值)，因此它支持分割機制。
對于文件的收集，這些問題會稍有不同。ZIP是存檔格式，因此它可以將多個文件合并為一個ZIP文件。每個文件單獨壓縮，所有文檔的存儲位置存儲在ZIP文件的尾部。這個屬性表明ZIP文件支持文件邊界處分割，每個分片中包括ZIP壓縮文件中的一個或多個文件。
在MapReduce我們應該使用哪種壓縮格式
根據應用的具體情況來決定應該使用哪種壓縮格式。就個人而言，更趨向于使用最快的速度壓縮，還是使用最優的空間壓縮？一般來說，應該嘗試不同的策略，并用具有代表性的數據集進行測試，從而找到最佳方法。對于那些大型的、沒有邊界的文件，如日志文件，有以下選項。
存儲未壓縮的文件。
使用支持分割機制的壓縮格式，如bzip2。
在應用中將文件分割成幾個大的數據塊，然后使用任何一種支持的壓縮格式單獨壓縮每個數據塊(可不用考慮壓縮格式是否支持分割)。在這里，需要選擇數據塊的大小使壓縮后的數據塊在大小上相當于HDFS的塊。
使用支持壓縮和分割的Sequence File(序列文件)。
對于大型文件，不要對整個文件使用不支持分割的壓縮格式，因為這樣會損失本地性優勢，從而使降低MapReduce應用的性能。
hadoop支持Splittable壓縮lzo
在hadoop中使用lzo的壓縮算法可以減小數據的大小和數據的磁盤讀寫時間，在HDFS中存儲壓縮數據，可以使集群能保存更多的數據，延長集群的使用壽命。不僅如此，由于mapreduce作業通常瓶頸都在IO上，存儲壓縮數據就意味這更少的IO操作，job運行更加的高效。
但是在hadoop上使用壓縮也有兩個比較麻煩的地方：第一，有些壓縮格式不能被分塊，并行的處理，比如gzip。第二，另外的一些壓縮格式雖然支持分塊處理，但是解壓的過程非常的緩慢，使job的瓶頸轉移到了cpu上，例如bzip2。
如果能夠擁有一種壓縮算法，即能夠被分塊，并行的處理，速度也非常的快，那就非常的理想。這種方式就是lzo。
lzo的壓縮文件是由許多的小的blocks組成（約256K），使的hadoop的job可以根據block的劃分來split job。不僅如此，lzo在設計時就考慮到了效率問題，它的解壓速度是gzip的兩倍，這就讓它能夠節省很多的磁盤讀寫，它的壓縮比的不如gzip，大約壓縮出來的文件比gzip壓縮的大一半，但是這樣仍然比沒有經過壓縮的文件要節省20%-50%的存儲空間，這樣就可以在效率上大大的提高job執行的速度。
hadoop下lzo配置文檔參考http://www.tech126.com/hadoop-lzo/
如何在MapReduce中使用壓縮
1.輸入的文件的壓縮
如果輸入的文件是壓縮過的，那么在被MapReduce讀取時，它們會被自動解壓，根據文件擴展名來決定應該使用哪一個壓縮解碼器。
2.MapReduce作業的輸出的壓縮
如果要壓縮MapReduce作業的輸出，請在作業配置文件中將mapred.output.compress屬性設置為true。將mapred.output.compression.codec屬性設置為自己打算使用的壓縮編碼/解碼器的類名。
如果為輸出使用了一系列文件，可以設置mapred.output.compression.type屬性來控制壓縮類型，默認為RECORD，它壓縮單獨的記錄。將它改為BLOCK，則可以壓縮一組記錄。由于它有更好的壓縮比，所以推薦使用。
3.map作業輸出結果的壓縮
即使MapReduce應用使用非壓縮的數據來讀取和寫入，我們也可以受益于壓縮map階段的中間輸出。因為map作業的輸出會被寫入磁盤并通過網絡傳輸到reducer節點，所以如果使用LZO之類的快速壓縮，能得到更好的性能，因為傳輸的數據量大大減少了。以下代碼顯示了啟用rnap輸出壓縮和設置壓縮格式的配置屬性。
- conf.setCompressMapOutput(true);
- conf.setMapOutputCompressorClass(GzipCodec.class);
本地壓縮庫
考慮到性能，最好使用一個本地庫（native library）來壓縮和解壓。例如，在一個測試中，使用本地gzip壓縮庫減少了解壓時間50%，壓縮時間大約減少了10%(與內置的Java實現相比較)。表4-4展示了Java和本地提供的每個壓縮格式的實現。井不是所有的格式都有本地實現(例如bzip2壓縮)，而另一些則僅有本地實現（例如LZO）。
| 壓縮格式 | Java實現 | 本地實現 |
| DEFLATE | 是 | 是 |
| gzip | 是 | 是 |
| bzip2 | 是 | 否 |
| LZO | 否 | 是 |
Hadoop帶有預置的32位和64位Linux的本地壓縮庫，位于庫/本地目錄。對于其他平臺，需要自己編譯庫，具體請參見Hadoop的維基百科http://wiki.apache.org/hadoop/NativeHadoop。
本地庫通過Java系統屬性java.library.path來使用。Hadoop的腳本在bin目錄中已經設置好這個屬性，但如果不使用該腳本，則需要在應用中設置屬性。
默認情況下，Hadoop會在它運行的平臺上查找本地庫，如果發現就自動加載。這意味著不必更改任何配置設置就可以使用本地庫。在某些情況下，可能希望禁用本地庫，比如在調試壓縮相關問題的時候。為此，將屬性hadoop.native.lib設置為false，即可確保內置的Java等同內置實現被使用(如果它們可用的話)。
原文鏈接：http://www.cnblogs.com/ggjucheng/archive/2012/04/22/2465580.html
【編輯推薦】
- Apache .htaccess文件的8個用法
- Hadoop 從Yahoo向Google的技術轉折
- Hadoop集群與Hadoop性能優化
- Facebook實時信息系統：HBase每月存儲1350億條信息
