常見壓縮格式

壓縮優缺點

• 優點:
  • 減少存儲磁盤空間
  • 降低 IO (網絡的 IO 和磁盤的IO)
  • 加快數據在磁盤和網絡中的傳輸速度, 從而提高系統的處理速度
• 缺點:
  • 由於使用數據時, 需要先將數據解壓, 加重CPU負荷

常見壓縮格式

壓縮格式	工具	算法	文件擴展名	是否可切分	對應的編碼/解碼器(org.apache.hadoop.io.compress.)
DEFAULT	無	DEFAULT	.delete	否	DefaultCodec
Gzip	gzip	DEFAULT	.gz	否	GzipCodec
bzip2	bzip2*	bzip2*	.bz2	是	BZipCodec
LZO	lzop	LZO	.lzo	是(加索引)	LzopCodec
LZ4	無	LZ4	lz4	否	Lz4Codec
Snappy	無	Snappy	.snappy	否	SnappyCodec

壓縮格式	codec類	算法	擴展名	多文件	splitable	native	工具	hadoop自帶
gzip	GzipCodec	deflate	.gz	否	否	是	gzip	是
bzip2	Bzip2Codec	bzip2	.bz2	是	是	否	bzip2	是
lzo	LzopCodec	lzo	.lzo	否	是	是	lzop	否
snappy	SnappyCodec	snappy	.snappy	否	否	是	無	否

• 說明

  • gzip
    • 算法 hadoop 內置支持, 使用時直接處理文本數據一樣, 使用方便, 壓縮比高, 缺點就是不支持split。
    • 如果壓縮后文件與塊大小相當，可以考慮使用gzip壓縮，比如：小時原始日志壓縮成gzip文件，使用方便。
  • bzip2
    • Ÿ bzip2 支持split，壓縮比高，支持多文件，缺點就是慢。
  • lzo
    • 壓縮/解壓速度也比較快，合理的壓縮率
    • 支持split(需要建索引，文件修改后需要重新建索引)
    • 支持hadoop native庫，需要自己安裝。
  • snappy
    • 壓縮/解壓速度也比較快，合理的壓縮率,不支持split
    • 支持hadoop native庫，需要自己安裝。

• 對比

  壓縮格式	優點	缺點
  gzip	壓縮比在四種壓縮方式中較高；hadoop本身支持，在應用中處理gzip格式的文件就和直接處理文本一樣；有hadoop native庫；大部分linux系統都自帶gzip命令，使用方便。	不支持split
  lzo	壓縮/解壓速度也比較快，合理的壓縮率；支持split，是hadoop中最流行的壓縮格式；支持hadoop native庫；需要在linux系統下自行安裝lzop命令，使用方便	壓縮率比gzip要低；hadoop本身不支持，需要安裝；lzo雖然支持split，但需要對lzo文件建索引，否則hadoop也是會把lzo文件看成一個普通文件（為了支持split需要建索引，需要指定inputformat為lzo格式）
  snappy	壓縮速度快；支持hadoop native庫	不支持split；壓縮比低；hadoop本身不支持，
  bzip2	支持split；具有很高的壓縮率，比gzip壓縮率都高；hadoop本身支持，但不支持native；在linux系統下自帶bzip2命令，使用方便	支持split,壓縮/解壓速度慢；不支持native

壓縮比

壓縮格式	壓縮比	壓縮速率	解壓速率
gzip/deflate	13.4%	21 MB/s	118 MB/s
bzip2	13.2%	2.4 MB/s	9.5 MB/s
lzo	20.5%	135 MB/s	410 MB/s
snappy	22.2%	172 MB/s	409 MB/s

• gzip在時間和空間上的取舍比較折中，bzip2壓縮比gzip更有效，但是速度更慢。
• bzip2的解壓速度比它的壓縮速度要快。
• 但是和其他壓縮格式比又是最慢的，但是壓縮效果明顯是最好的。
• 我咋覺得bzip很雞肋啊, 壓縮比也就比gzip低一點, 壓縮速率和解壓速率慢那么多, 感覺只有追求極致的磁盤空間的時候才會用吧。
• 從理上來說, 壓縮比越低, 壓縮速率和解壓速率就越慢, 但是這個百分之0.2真的應該造成這么大的壓縮解壓速率差別嗎? 懷疑底層算法的有效性。

Hadoop配置壓縮

• core-site.xml

  <property>
     <name>io.compression.codecs</name>
     <value>
  org.apache.hadoop.io.compress.GzipCodec,
  org.apache.hadoop.io.compress.DefaultCodec,
  org.apache.hadoop.io.compress.BZip2Codec,
    </value>
  </property>  
  

• mapred-site.xml

  <property>
      <name>mapreduce.output.fileoutputformat.compress</name>
  	<value>true</value>
  </property>
  
  <property> 
  	<name>mapreduce.output.fileoutputformat.compress.codec</name>
  	<value>org.apache.hadoop.io.compress.BZip2Codec</value>
  </property>	
  <property> 
       <name>mapreduce.map.output.compress</name>
       <value>true</value>
  </property>
  <property>
     <name>mapreduce.map.output.compress.codec</name> 
     <value>org.apache.hadoop.io.compress.SnappyCodec</value>                      </property>
  

場景

• 為什么map端用snappy壓縮格式；而reduce用gzip或者bzip2的壓縮格式呢？
  • Map壓縮主要是增加MapReduce運行的效率，我們就需要找壓縮效率最高的壓縮格式，snappy的壓縮時間最快
  • 選擇高壓縮比gzip或者bzip2的原因有二:
    • 這兩個壓縮格式高
    • 對於不可分割我們采用每個reduce端壓縮后的數據不要超過一個block的大小的方法
    • 對於后續的map清洗也就不會出現分割問題。
• 為什么每個reduce端壓縮后的數據不要超過一個block的大小呢？
  • Reduce壓縮就是輸出文件壓縮 ，故考慮占用磁盤空間的大小

Splitable

• splitable表示壓縮格式是否可以被分割，也就是說是否支持隨即讀。
• 壓縮數據是否能被mapreduce使用，關鍵得看壓縮數據是否能被分割。
• 舉例一個未壓縮的文件有1GB大小，hdfs默認的block大小是128MB。
• 那么這個文件就會被分為8個block作為mapreduce的輸入，每一個單獨使用一個map任務。
• 若該文件是已經使用gzip壓縮的呢，若分成8個塊，每個塊做成一個輸入，顯然是不合適的, 因為gzip壓縮流的隨機讀是不可能的。
• 實際上，當mapreduce處理壓縮格式的文件的時候它會認識到這是一個gzip的壓縮文件，而gzip又不支持隨機讀，它就會把8個塊分給一個map去處理。
• 這里就會有很多非本地處理的map任務，整個過程耗費的時間就會相當長。
• lzo壓縮格式也會是同樣的問題，但是通過使用hadoop lzo庫的索引工具以后，lzo就可以支持splittable。bzip2也是支持splitable的。

總結

• 每一種壓縮方式都有他的優缺點，講求壓縮效率，壓縮比就會低，占用的網絡io和磁盤io就多
• 講求壓縮比，對cpu的損耗就比較大，同時壓縮和解壓的耗時就比較多
• 對於支持split的（lzo和bzip）可以實現並行處理