HADOOP與HDFS資料壓縮格式

1、cloudera 資料壓縮的一般準則

一般準則

• 是否壓縮資料以及使用何種壓縮格式對性能具有重要的影響。在資料壓縮上，需要考慮的最重要的兩個方面是 MapReduce 作業和存儲在 HBase 中的資料。在大多數情況下，每個的原則都類似。
• 您需要平衡壓縮和解壓縮資料所需的能力、讀寫資料所需的磁盤 IO，以及在網絡中發送資料所需的網絡帶寬。正确平衡這些因素有賴于叢集和資料的特征，以及您的
• 使用模式。

• 如果資料已壓縮（例如 JPEG 格式的圖像），則不建議進行壓縮。事實上，結果檔案實際上可能大于原檔案。
• GZIP 壓縮使用的 CPU 資源比 Snappy 或 LZO 更多，但可提供更高的壓縮比。GZIP 通常是不常通路的冷資料的不錯選擇。而 Snappy 或 LZO 則更加适合經常通路的熱資料。
• BZip2 還可以為某些檔案類型生成比 GZip 更多的壓縮，但是壓縮和解壓縮時會在一定程度上影響速度。HBase 不支援 BZip2 壓縮。
• Snappy 的表現通常比 LZO 好。應該運作測試以檢視您是否檢測到明顯差別。
• 對于 MapReduce，如果您需要已壓縮資料可拆分，BZip2、LZO 和 Snappy 格式都可拆分，但是 GZip 不可以。可拆分性與 HBase 資料無關。
• 對于 MapReduce，您可壓縮中間資料、輸出或二者。相應地調整您為 MapReduce 作業提供的參數。以下示例壓縮中間資料和輸出。MR2 先顯示，然後顯示 MR1。

MR2
hadoop jar hadoop-examples-.jar sort "-Dmapreduce.compress.map.output=true"
      "-Dmapreduce.map.output.compression.codec=org.apache.hadoop.io.compress.GzipCodec"
      "-Dmapreduce.output.compress=true"
      "-Dmapreduce.output.compression.codec=org.apache.hadoop.io.compress.GzipCodec" -outKey
      org.apache.hadoop.io.Text -outValue org.apache.hadoop.io.Text input output
MR1
hadoop jar hadoop-examples-.jar sort "-Dmapred.compress.map.output=true"
      "-Dmapred.map.output.compression.codec=org.apache.hadoop.io.compress.GzipCodec"
      "-Dmapred.output.compress=true"
      "-Dmapred.output.compression.codec=org.apache.hadoop.io.compress.GzipCodec" -outKey
      org.apache.hadoop.io.Text -outValue org.apache.hadoop.io.Text input output           

2、Hadoop 壓縮實作分析

壓縮簡介

Hadoop 作為一個較通用的海量資料處理平台，每次運算都會需要處理大量資料，我們會在 Hadoop 系統中對資料進行壓縮處理來優化磁盤使用率，提高資料在磁盤和網絡中的傳輸速度，進而提高系統處理資料的效率。在使用壓縮方式方面，主要考慮壓縮速度和壓縮檔案的可分割性。綜合所述，使用壓縮的優點如下：

1. 節省資料占用的磁盤空間；
2. 加快資料在磁盤和網絡中的傳輸速度，進而提高系統的處理速度。

壓縮格式

1. Hadoop 對于壓縮格式的是自動識别。如果我們壓縮的檔案有相應壓縮格式的擴充名（比如 lzo，gz，bzip2 等）。
2. Hadoop 會根據壓縮格式的擴充名自動選擇相對應的解碼器來解壓資料，此過程完全是 Hadoop 自動處理，我們隻需要確定輸入的壓縮檔案有擴充名。
3. Hadoop 對每個壓縮格式的支援, 詳細見下表：

	工具	算法	擴充名	多檔案	可分割性
DEFLATE	無		.deflate	不
GZIP	gzip		.gzp
ZIP	zip		.zip	是	是，在檔案範圍内
BZIP2	bzip2		.bz2
LZO	lzop		.lzo

1. 如果壓縮的檔案沒有擴充名，則需要在執行 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*-inputformatorg.apache.hadoop.mapred.LzoTextInputFormat*           

性能對比

1. Hadoop 下各種壓縮算法的壓縮比，壓縮時間，解壓時間見下表:

壓縮算法	原始檔案大小	壓縮檔案大小	壓縮速度	解壓速度
	8.3GB	1.8GB	17.5MB/s	58MB/s
		1.1GB	2.4MB/s	9.5MB/s
LZO-bset		2GB	4MB/s	60.6MB/s
		2.9GB	49.3MB/s	74.6MB/s

是以我們可以得出：

1) Bzip2 壓縮效果明顯是最好的，但是 bzip2 壓縮速度慢，可分割。

2) Gzip 壓縮效果不如 Bzip2，但是壓縮解壓速度快，不支援分割。

3) LZO 壓縮效果不如 Bzip2 和 Gzip，但是壓縮解壓速度最快！并且支援分割！

這裡提一下，檔案的可分割性在 Hadoop 中是很非常重要的，它會影響到在執行作業時 Map 啟動的個數，進而會影響到作業的執行效率！

所有的壓縮算法都顯示出一種時間空間的權衡，更快的壓縮和解壓速度通常會耗費更多的空間。在選擇使用哪種壓縮格式時，我們應該根據自身的業務需求來選擇。

3、4種常用壓縮格式在Hadoop中的應用

目前在Hadoop中用得比較多的有lzo，gzip，snappy，bzip2這4種壓縮格式，筆者根據實踐經驗介紹一下這4種壓縮格式的優缺點和應用場景，以便大家在實踐中根據實際情況選擇不同的壓縮格式。

1.gzip壓縮

• 優點：
  1. 壓縮率比較高，而且壓縮/解壓速度也比較快；
  2. hadoop本身支援，在應用中處理gzip格式的檔案就和直接處理文本一樣；
  3. 有hadoop native庫；
  4. 大部分linux系統都自帶gzip指令，使用友善。
• 缺點：不支援split。
• 應用場景：
  1. 當每個檔案壓縮之後在130M以内的（1個塊大小内），都可以考慮用gzip壓縮格式。譬如說一天或者一個小時的日志壓縮成一個gzip檔案，運作mapreduce程式的時候通過多個gzip檔案達到并發。
  2. hive程式，streaming程式，和java寫的mapreduce程式完全和文本處理一樣，壓縮之後原來的程式不需要做任何修改。

2.lzo壓縮

• 1. 壓縮/解壓速度也比較快，合理的壓縮率；
  2. 支援split，是hadoop中最流行的壓縮格式；
  3. 支援hadoop native庫；
  4. 可以在linux系統下安裝lzop指令，使用友善。
• 缺點：
  1. 壓縮率比gzip要低一些；
  2. hadoop本身不支援，需要安裝；
  3. 在應用中對lzo格式的檔案需要做一些特殊處理（為了支援split需要建索引，還需要指定inputformat為lzo格式）。
• 一個很大的文本檔案，壓縮之後還大于200M以上的可以考慮，而且單個檔案越大，lzo優點越明顯。

3.snappy壓縮

• 1. 高速壓縮速度和合理的壓縮率；
  2. 支援hadoop native庫。
• 1. 不支援split；
  2. 壓縮率比gzip要低；
  4. linux系統下沒有對應的指令。
• 1. 當mapreduce作業的map輸出的資料比較大的時候，作為map到reduce的中間資料的壓縮格式；
  2. 或者作為一個mapreduce作業的輸出和另外一個mapreduce作業的輸入。

4.bzip2壓縮

• 1. 支援split；
  2. 具有很高的壓縮率，比gzip壓縮率都高；
  3. hadoop本身支援，但不支援native；
  4. 在linux系統下自帶bzip2指令，使用友善。
• 1. 壓縮/解壓速度慢；
  2. 不支援native。
• 1. 适合對速度要求不高，但需要較高的壓縮率的時候，可以作為mapreduce作業的輸出格式；
  2. 或者輸出之後的資料比較大，處理之後的資料需要壓縮存檔減少磁盤空間并且以後資料用得比較少的情況；
  3. 或者對單個很大的文本檔案想壓縮減少存儲空間，同時又需要支援split，而且相容之前的應用程式（即應用程式不需要修改）的情況。

5.4種壓縮格式的特征的比較

	split	native	壓縮率	速度	是否hadoop自帶	linux指令	換成壓縮格式後，原來的應用程式是否要修改
	否		很高	比較快	是，直接使用	有	和文本處理一樣，不需要修改
lzo			比較高	很快	否，需要安裝		需要建索引，還需要指定輸入格式
snappy						沒有
			最高	慢

目前CDH叢集一般都可選安裝 Hadoop_Lzo,ucloud叢集目前是內建了lzo的