1、概述
壓縮技術(shù)能夠有效減少底層存儲(chǔ)系統(tǒng)（HDFS）讀寫(xiě)字節(jié)數(shù)。壓縮提高了網(wǎng)絡(luò)帶寬和磁盤(pán)空間的效率奏司。在Hadood下，尤其是數(shù)據(jù)規(guī)模很大和工作負(fù)載密集的情況下樟插，使用數(shù)據(jù)壓縮顯得非常重要韵洋。在這種情況下，I/O操作和網(wǎng)絡(luò)數(shù)據(jù)傳輸要花大量的時(shí)間黄锤。還有搪缨，Shuffle與Merge過(guò)程同樣也面臨著巨大的I/O壓力。
鑒于磁盤(pán)I/O和網(wǎng)絡(luò)帶寬是Hadoop的寶貴資源鸵熟，數(shù)據(jù)壓縮對(duì)于節(jié)省資源副编、最小化磁盤(pán)I/O和網(wǎng)絡(luò)傳輸非常有幫助。不過(guò)流强，盡管壓縮與解壓操作的CPU開(kāi)銷(xiāo)不高痹届，其性能的提升和資源的節(jié)省并非沒(méi)有代價(jià)。
如果磁盤(pán)I/O和網(wǎng)絡(luò)帶寬影響了MapReduce作業(yè)性能打月，在任意MapReduce階段啟用壓縮都可以改善端到端處理時(shí)間并減少I(mǎi)/O和網(wǎng)絡(luò)流量队腐。
壓縮mapreduce的一種優(yōu)化策略：通過(guò)壓縮編碼對(duì)mapper或者reducer的輸出進(jìn)行壓縮，以減少磁盤(pán)IO奏篙，提高M(jìn)R程序運(yùn)行速度（但相應(yīng)增加了cpu運(yùn)算負(fù)擔(dān)）柴淘。
注意：壓縮特性運(yùn)用得當(dāng)能提高性能，但運(yùn)用不當(dāng)也可能降低性能秘通。
基本原則
（1）運(yùn)算密集型的job为严，少用壓縮
（2）IO密集型的job，多用壓縮
2肺稀、MapReduce支持的壓縮編碼
| 壓縮格式 | 工具 | 算法 | 文件擴(kuò)展名 | 是否可切分 |
|---|---|---|---|---|
| DEFAULT | 無(wú) | DEFAULT | .deflate | 否 |
| Gzip | gzip | DEFAULT | .gz | 否 |
| bzip2 | bzip2 | bzip2 | .bz2 | 是 |
| LZO | lzop | LZO | .lzo | 否 |
| LZ4 | 無(wú) | LZ4 | .lz4 | 否 |
| Snappy | 無(wú) | Snappy | .snappy | 否 |
為了支持多種壓縮/解壓縮算法第股，Hadoop引入了編碼/解碼器，如下表所示
| 壓縮格式 | 對(duì)應(yīng)的編碼/解碼器 |
|---|---|
| DEFLATE | org.apache.hadoop.io.compress.DefaultCodec |
| gzip | org.apache.hadoop.io.compress.GzipCodec |
| bzip2 | org.apache.hadoop.io.compress.BZip2Codec |
| LZO | com.hadoop.compression.lzo.LzopCodec |
| LZ4 | org.apache.hadoop.io.compress.Lz4Codec |
| Snappy | org.apache.hadoop.io.compress.SnappyCodec |
壓縮性能的比較
| 壓縮算法 | 原始文件大小 | 壓縮文件大小 | 壓縮速度 | 解壓速度 |
|---|---|---|---|---|
| gzip | 8.3GB | 1.8GB | 17.5MB/s | 58MB/s |
| bzip2 | 8.3GB | 1.1GB | 2.4MB/s | 9.5MB/s |
| LZO | 8.3GB | 2.9GB | 49.3MB/s | 74.6MB/s |
http://google.github.io/snappy/
On a single core of a Core i7 processor in 64-bit mode, Snappy compresses at about 250 MB/sec or more and decompresses at about 500 MB/sec or more.
3话原、采用壓縮的位置
壓縮可以在MapReduce作用的任意階段啟用炸茧。
1）輸入壓縮
在有大量數(shù)據(jù)并計(jì)劃重復(fù)處理的情況下，應(yīng)該考慮對(duì)輸入進(jìn)行壓縮稿静。然而，你無(wú)須顯示指定使用的編解碼方式辕狰。Hadoop自動(dòng)檢查文件擴(kuò)展名改备，如果擴(kuò)展名能夠匹配，就會(huì)用恰當(dāng)?shù)木幗獯a方式對(duì)文件進(jìn)行壓縮和解壓蔓倍。否則悬钳，Hadoop就不會(huì)使用任何編解碼器盐捷。
2）壓縮mapper輸出
當(dāng)map任務(wù)輸出的中間數(shù)據(jù)量很大時(shí)，應(yīng)考慮在此階段采用壓縮技術(shù)默勾。這能顯著改善內(nèi)部數(shù)據(jù)Shuffle過(guò)程碉渡，而Shuffle過(guò)程在Hadoop處理過(guò)程中是資源消耗最多的環(huán)節(jié)。如果發(fā)現(xiàn)數(shù)據(jù)量大造成網(wǎng)絡(luò)傳輸緩慢母剥，應(yīng)該考慮使用壓縮技術(shù)滞诺。可用于壓縮mapper輸出的快速編解碼器包括LZO环疼、LZ4或者Snappy习霹。
注：LZO是供Hadoop壓縮數(shù)據(jù)用的通用壓縮編解碼器。其設(shè)計(jì)目標(biāo)是達(dá)到與硬盤(pán)讀取速度相當(dāng)?shù)膲嚎s速度炫隶，因此速度是優(yōu)先考慮的因素淋叶，而不是壓縮率。與gzip編解碼器相比伪阶，它的壓縮速度是gzip的5倍煞檩，而解壓速度是gzip的2倍。同一個(gè)文件用LZO壓縮后比用gzip壓縮后大50%栅贴，但比壓縮前小25%~50%斟湃。這對(duì)改善性能非常有利，map階段完成時(shí)間快4倍筹误。
3）壓縮reducer輸出
在此階段啟用壓縮技術(shù)能夠減少要存儲(chǔ)的數(shù)據(jù)量桐早，因此降低所需的磁盤(pán)空間。當(dāng)mapreduce作業(yè)形成作業(yè)鏈條時(shí)厨剪，因?yàn)榈诙€(gè)作業(yè)的輸入也已壓縮哄酝，所以啟用壓縮同樣有效。
4祷膳、壓縮配置參數(shù)
要在Hadoop中啟用壓縮陶衅，可以配置如下參數(shù)（mapred-site.xml文件中）
| 參數(shù) | 默認(rèn)值 | 階段 | 建議 |
|---|---|---|---|
| io.compression.codecs（在core-site.xml中配置） | org.apache.hadoop.io.compress.DefaultCodec, org.apache.hadoop.io.compress.GzipCodec, org.apache.hadoop.io.compress.BZip2Codec, org.apache.hadoop.io.compress.Lz4Codec | 輸入壓縮 | Hadoop使用文件擴(kuò)展名判斷是否支持某種編解碼器 |
| mapreduce.map.output.compress | false | mapper輸出 | 這個(gè)參數(shù)設(shè)為true啟用壓縮 |
| mapreduce.map.output.compress.codec | org.apache.hadoop.io.compress.DefaultCodec | mapper輸出 | 使用LZO、LZ4或snappy編解碼器在此階段壓縮數(shù)據(jù) |
| mapreduce.output.fileoutputformat.compress | false | reducer輸出 | 這個(gè)參數(shù)設(shè)為true啟用壓縮 |
| mapreduce.output.fileoutputformat.compress.codec | org.apache.hadoop.io.compress. DefaultCodec | reducer輸出 | 使用標(biāo)準(zhǔn)工具或者編解碼器直晨，如gzip和bzip2 |
| mapreduce.output.fileoutputformat.compress.type | RECORD | reducer輸出 | SequenceFile輸出使用的壓縮類(lèi)型：NONE和BLOCK |
