對於檔案的儲存、傳輸、磁碟IO讀取等操作在使用Hadoop生態圈的儲存系統時是非常常見的，而檔案的大小等直接影響了這些操作的速度以及對磁碟空間的消耗。
此時，一種常用的方式就是對檔案進行壓縮。但檔案被壓縮之後，在讀取資料時要先進行解壓縮，會對CPU造成一定負擔。
因此，在實際生產中，是否對資料進行壓縮以及採用哪種方式進行壓縮顯得尤為重要。需要綜合考慮壓縮和解壓縮資料所需的資源、磁碟IO，以及在網路傳輸資料所需頻寬以及叢集的效能和檔案的特性等。它至少能帶來以下好處：
-
減少磁碟儲存空間
-
降低IO（包括磁碟和網路IO），加快資料在磁碟和網路中的傳輸速度，提升效能
首先來看一下常見的Hadoop壓縮格式一覽表，以及詳細介紹：
snappy壓縮
優點：高速壓縮速度和合理的壓縮率；支援Hadoop native庫。
缺點：不支援split；壓縮率比gzip要低；Hadoop本身不支援，需要安裝；linux系統下沒有對應的命令。
應用場景：當MapReduce作業的map輸出的資料量比較大的時候，作為map到reduce的中間資料的壓縮格式；或者作為一個MapReduce作業的輸出和另外一個MapReduce作業的輸入。
lzo壓縮
優點：壓縮/解壓速度也比較快，合理的壓縮率；支援split，是Hadoop中最流行的壓縮格式；支援Hadoop native庫；可以在linux系統下安裝lzop命令，使用方便。
缺點：壓縮率比gzip要低一些；hadoop本身不支援，需要安裝；在應用中對lzo格式的檔案需要做一些特殊處理（為了支援split需要建索引，還需要指定inputformat為lzo格式）。
應用場景：一個很大的文字檔案，壓縮之後還大於200M以上的可以考慮，而且單個檔案越大，lzo優點越明顯。
gzip壓縮
優點：壓縮率比較高，而且壓縮/解壓速度也比較快；Hadoop本身支援，在應用中處理gzip格式的檔案就和直接處理文字一樣；有Hadoop native庫；大部分linux系統都自帶gzip命令，使用方便。
缺點：不支援split
應用場景：當每個檔案壓縮之後在130M以內的，都可以考慮用gzip壓縮格式。比如每天的日誌壓縮成一個gzip檔案，執行MapReduce程式的時候通過多個gzip檔案達到併發。對於處理這些檔案的程式（如Hive、流、MapReduce程式）完全和文字處理一樣，壓縮之後原來的程式不需要做任何修改。
bzip2壓縮
優點：支援split；具有很高的壓縮率，比gzip壓縮率都高；Hadoop本身支援，但不支援native；在linux系統下自帶bzip2命令，使用方便。
缺點：壓縮/解壓速度慢；不支援native。
應用場景：適合對速度要求不高，但需要較高的壓縮率的場景。可以作為MapReduce作業的輸出格式；輸出之後的資料比較大，處理之後的資料需要壓縮存檔減少磁碟空間並且以後資料用得比較少的情況；對單個很大的文字檔案想壓縮減少儲存空間，同時又需要支援split，而且相容之前的應用程式（即應用程式不需要修改）的情況。
在介紹上述壓縮格式時，強調了它們是否對Hadoop native庫的支援，因為是否支援Hadoop native庫對效能產生巨大影響。
Hadoop是使用Java語言開發的，但是有些操作並不總適合使用Java，所以才引入了native庫即本地庫的概念。通過使用本地庫，Hadoop可更加高效的執行某些操作。
Hadoop帶有預置的32位和64位Linux的本地壓縮庫。
本地庫通過Java系統屬性java.library.path來使用。Hadoop的指令碼在bin目錄中已經設定好這個屬性，但如果不使用該指令碼，則需要在應用中設定屬性。
預設情況下，Hadoop會在它執行的平臺上查詢本地庫，如果發現就自動載入，這意味著不需要修改任何配置就可以使用本地庫。如果想禁用本地庫（比如需要除錯壓縮相關問題），則將屬性hadoop.native.lib設定為false，即可確保內建的Java等同內建實現 被使用（如果它們可用的話）。
推薦文章：
必須掌握的分散式檔案儲存系統—HDFS
關於HDFS應知應會的幾個問題
NameNode調優
詳解MapReduce
關注微信公眾號：大資料學習與分享，獲取更對技術乾貨