為什麼會出現需要對文件進行壓縮？

在Hadoop中，文件需要存儲、傳輸、讀取磁盤、寫入磁盤等等操作，而文件的大小，直接決定了這些這些操作的速度。

好處

• 減少存儲磁盤空間
• 降低io(網絡的IO和磁盤的IO)
• 加快數據在磁盤和網絡中的傳輸速度，從而提高系統的處理速度

壞處

• 由于使用數據時，需要先将數據解壓，加重CPU負荷。而且壓縮的越狠，耗費的時間越多。

支持native表示，hadoop自己提供了功能的實現，而不是依賴外部，如bzip2是不支持native，則表示物理機要另行安裝支持bzip2壓縮的軟件。

一個簡單的案例對于集中壓縮方式之間的壓縮比和壓縮速度進行一個感觀性的認識

壓縮比

壓縮時間/解壓時間

可以看出，壓縮比越高，壓縮時間越長，壓縮比：Snappy<LZ4<LZO<GZIP<BZIP2

a. gzip

優點：壓縮比在四種壓縮方式中較高；hadoop本身支持，在應用中處理gzip格式的文件就和直接處理文本一樣；有hadoop native庫；大部分linux系統都自帶gzip命令，使用方便

缺點：不支持split

b. lzo

優點：壓縮/解壓速度也比較快，合理的壓縮率；支持split，是hadoop中最流行的壓縮格式；支持hadoop native庫；需要在linux系統下自行安裝lzop命令，使用方便

缺點：壓縮率比gzip要低；hadoop本身不支持，需要安裝；lzo雖然支持split，但需要對lzo文件建索引，否則hadoop也是會把lzo文件看成一個普通文件（為了支持split需要建索引，需要指定inputformat為lzo格式）

c. snappy

優點：壓縮速度快；支持hadoop native庫

缺點：不支持split；壓縮比低；hadoop本身不支持，需要安裝；linux系統下沒有對應的命令

d. bzip2

優點：支持split；具有很高的壓縮率，比gzip壓縮率都高；hadoop本身支持，但不支持native；在linux系統下自帶bzip2命令，使用方便

缺點：壓縮/解壓速度慢；不支持native

1. 第一次傳入壓縮文件，應選用可以切片的壓縮方式，否則整個文件将隻有一個Map執行。Use Compressd Map Input:從HDFS中讀取文件進行Mapreuce作業，如果數據很大，可以使用壓縮并且選擇支持分片的壓縮方式（Bzip2,LZO），可以實現并行處理，提高效率，減少磁盤讀取時間，同時選擇合适的存儲格式例如Sequence Files，RC,ORC等。
2. 第二次壓縮應選擇壓縮解壓速度快的壓縮方式，生産中，Map階段數據落盤通常使用snappy壓縮格式（快速壓縮解壓）。Compress Intermediate Data:Map輸出作為Reducer的輸入，需要經過shuffle這一過程，需要把數據讀取到一個環形緩沖區，然後讀取到本地磁盤，所以選擇壓縮可以減少了存儲文件所占空間，提升了數據傳輸速率，建議使用壓縮速度快的壓縮方式，例如Snappy和LZO。
3. 第三次壓縮有兩種場景分别是：一.當輸出文件為下一個job的輸入，選擇可切分的壓縮方式例如：BZip2。二.當輸出文件直接存到HDFS，作為歸檔，選擇壓縮比高的壓縮方式。reduce階段數據落盤通常使用gzip或bzip2進行壓縮（減少磁盤使用）。Compress Reducer Output:進行歸檔處理或者鍊接Mapreduce的工作（該作業的輸出作為下個作業的輸入），壓縮可以減少了存儲文件所占空間，提升了數據傳輸速率，如果作為歸檔處理，可以采用高的壓縮比（Gzip,Bzip2），如果作為下個作業的輸入，考慮是否要分片進行選擇。

不同的場景選擇不同的壓縮方式，肯定沒有一個一勞永逸的方法，如果選擇高壓縮比，那麼對于cpu的性能要求要高，同時壓縮、解壓時間耗費也多；選擇壓縮比低的，對于磁盤io、網絡io的時間要多，空間占據要多；對于支持分割的，可以實現并行處理。

☆若該壓縮格式不支持文件分割，則後續無法實現并行處理，生産優化核心是讓每個文件大小略微低于塊大小，如塊128M文件怎樣為125M。未壓縮的文件是支持文件分割的

一般在HDFS 、Hive、HBase中會使用；

當然一般較多的是結合Spark 來一起使用。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!