hadoop中使用 Gzip 壓縮格式支援筆記
hadoop中支援的壓縮方式有多種,比如Gzip,bzip2,zlib等,其中Gzip是hadoop中內建就支援的一種壓縮方式,這種壓縮方式在平 時linux 的開發人員和管理 員中使用的比較廣泛,壓縮比也比較高,壓縮速度也還不
錯,所以很多人都喜歡第一趨向於使用這種壓縮格式進行文 件 的壓縮。
在hadoop中,要在mapreduce 的job中使用gzip壓縮是比較容易的,不記得是從哪個版本開始,hadoop就內建了使用gzip壓縮格式讀取輸入檔案,寫中間結果和輸出結果的支 持。
要在hadoop的mapreduce中使用gzip非常簡單,分為以下幾種情況:
- 從壓縮的輸入文 件時直接讀入
由於hadoop在讀取輸入檔案時,會很智慧的根據輸入檔案的字尾名來進行判斷是否採用壓縮格式進行讀入,所以當讀到輸入檔案 是***.gz時,就會猜測該檔案是一個用gzip壓縮過的檔案,於是就會嘗試使用gzip的讀取方式來讀取. - 將mapreduce job所產生的中間結果進行壓縮
由於mapreduce演算法本身的特徵,必然會在job的執行過程中產生一定的中間結果檔案,當資料 量很大的時候,這些中間結果也非常的客觀,一定程度上, 對job的效率會有一定的影響。由於通常計算任務的瓶頸都在磁碟的讀寫IO上,因此如果能夠減少因中間檔案而產生的disk IO,則對作業的效率肯定有益無害。因此如果希望將mapreduce作業的中間結果進行壓縮,在hadoop的conf(可以通過修改hadoop- site.xml的配置選項,可以在程式中用JobConf的類介面
<property>
<name>mapred.compress.map.output</name>
<value>true</value>
</property>
這樣,作業就會將產生的中間結果寫 入slave local的時候,對結果進行壓縮,reduce讀取時也能夠根據gz的字尾知道該中間結果是壓縮檔案,於是採用相應的讀取格式來讀取。 - 將 最終的計算輸出的結果進行壓縮
有的時候,我們需要對作業的執行結果進行歷史儲存,但是如果每天積累的計算結果非常大,又想要儲存儘量多的歷史結果 一邊將來的結算,那麼日積月累下,就會佔據非常非常大的HDFS的儲存
<property>
<name>mapred.output.compress</name>
<value>true</value>
</property>
以下是使用hadoop-0.19.1對一個11358 Byte的檔案進行三種方式的壓縮的對比:
- 讀取非壓縮檔案,中間結果不 壓縮,輸出結果也不壓縮
HDFS bytes read | HDFS bytes written | Local bytes read | Local bytes written | |
Map | 13872 | 0 | 0 | 9922 |
Reduce | 0 | 6117 | 9860 | 9860 |
Total | 13872 | 6117 | 9860 | 19782 |
- 讀 取非壓縮檔案,中間結果壓縮,輸出結果不壓縮
HDFS bytes read | HDFS bytes written | Local bytes read | Local bytes written | |
Map | 13872 | 0 | 0 | 9922 |
Reduce | 0 | 2663 | 9860 | 9860 |
Total | 13872 | 2663 | 9860 | 19782 |
- 讀 取非壓縮檔案,中間結果壓縮,輸出結果也壓縮
HDFS bytes raed | HDFS bytes written | Local bytes read | Local bytes written | |
Map | 13872 | 0 | 0 | 4221 |
Reduce | 0 | 2663 | 3623 | 3423 |
Total | 13872 | 2663 | 3623 | 7844 |
因此我們可以看到,在hadoop中使用gzip壓縮來進行讀取,中間結果,資料結果的儲存都是非常的容易,因為hadoop native本身就提供了我們相應的類來解析和壓縮資料。不過這裡要特別提到的是:gzip壓縮格式在hadoop中的支援有一定的侷限性: 由於gzip壓縮演算法本身的原因,我們無法對gzip壓縮檔案進行分塊,也就是說,在hadoop中,如果想要用hadoop 的mapreduce來處理資料,沒一個mapper就必須對應一個gz檔案,不能多個mapper對一個gzip檔案的多個chunk進行並行的處理,
因此如果要在hadoop mapreduce任務中使用gzip,在資料處理之前就需要對資料進行認為的切分,讓一個mapper來處理一塊資料。這樣其實有一點有違 mapreduce的本質。
hadoop中支援的壓縮方式有多種,比如Gzip,bzip2,zlib等,其中Gzip是hadoop中內建就支援的一種壓縮方式,這種壓縮方式在平 時linux 的開發人員和管理 員中使用的比較廣泛,壓縮比也比較高,壓縮速度也還不
錯,所以很多人都喜歡第一趨向於使用這種壓縮格式進行文 件 的壓縮。
在hadoop中,要在mapreduce 的job中使用gzip壓縮是比較容易的,不記得是從哪個版本開始,hadoop就內建了使用gzip壓縮格式讀取輸入檔案,寫中間結果和輸出結果的支 持。
要在hadoop的mapreduce中使用gzip非常簡單,分為以下幾種情況:
- 從壓縮的輸入文 件時直接讀入
由於hadoop在讀取輸入檔案時,會很智慧的根據輸入檔案的字尾名來進行判斷是否採用壓縮格式進行讀入,所以當讀到輸入檔案 是***.gz時,就會猜測該檔案是一個用gzip壓縮過的檔案,於是就會嘗試使用gzip的讀取方式來讀取. - 將mapreduce job所產生的中間結果進行壓縮
由於mapreduce演算法本身的特徵,必然會在job的執行過程中產生一定的中間結果檔案,當資料 量很大的時候,這些中間結果也非常的客觀,一定程度上, 對job的效率會有一定的影響。由於通常計算任務的瓶頸都在磁碟的讀寫IO上,因此如果能夠減少因中間檔案而產生的disk IO,則對作業的效率肯定有益無害。因此如果希望將mapreduce作業的中間結果進行壓縮,在hadoop的conf(可以通過修改hadoop- site.xml的配置選項,可以在程式中用JobConf的類介面設 置 ,或者在提交作業時用-D選項來設定該選項)中配置一個選項:
<property>
<name>mapred.compress.map.output</name>
<value>true</value>
</property>
這樣,作業就會將產生的中間結果寫 入slave local的時候,對結果進行壓縮,reduce讀取時也能夠根據gz的字尾知道該中間結果是壓縮檔案,於是採用相應的讀取格式來讀取。 - 將 最終的計算輸出的結果進行壓縮
有的時候,我們需要對作業的執行結果進行歷史儲存,但是如果每天積累的計算結果非常大,又想要儲存儘量多的歷史結果 一邊將來的結算,那麼日積月累下,就會佔據非常非常大的HDFS的儲存空 間 ,並且由於是歷史資料,使用的頻率也不高,這就會造成很大的儲存空間的浪費,因此,將計算的結果進行壓縮,也是一種 非常好的節省空間的方法。要在hadoop job中做到這一點也很容易,只需要告訴hadoop,“我想要多job的輸出結果進行壓縮,並儲存到HDFS上去”,就行了。具體的操作就是:在 conf中設定配置選項:
<property>
<name>mapred.output.compress</name>
<value>true</value>
</property>
以下是使用hadoop-0.19.1對一個11358 Byte的檔案進行三種方式的壓縮的對比:
- 讀取非壓縮檔案,中間結果不 壓縮,輸出結果也不壓縮
HDFS bytes read | HDFS bytes written | Local bytes read | Local bytes written | |
Map | 13872 | 0 | 0 | 9922 |
Reduce | 0 | 6117 | 9860 | 9860 |
Total | 13872 | 6117 | 9860 | 19782 |
- 讀 取非壓縮檔案,中間結果壓縮,輸出結果不壓縮
HDFS bytes read | HDFS bytes written | Local bytes read | Local bytes written | |
Map | 13872 | 0 | 0 | 9922 |
Reduce | 0 | 2663 | 9860 | 9860 |
Total | 13872 | 2663 | 9860 | 19782 |
- 讀 取非壓縮檔案,中間結果壓縮,輸出結果也壓縮
HDFS bytes raed | HDFS bytes written | Local bytes read | Local bytes written | |
Map | 13872 | 0 | 0 | 4221 |
Reduce | 0 | 2663 | 3623 | 3423 |
Total | 13872 | 2663 | 3623 | 7844 |
因此我們可以看到,在hadoop中使用gzip壓縮來進行讀取,中間結果,資料結果的儲存都是非常的容易,因為hadoop native本身就提供了我們相應的類來解析和壓縮資料。不過這裡要特別提到的是:gzip壓縮格式在hadoop中的支援有一定的侷限性: 由於gzip壓縮演算法本身的原因,我們無法對gzip壓縮檔案進行分塊,也就是說,在hadoop中,如果想要用hadoop 的mapreduce來處理資料,沒一個mapper就必須對應一個gz檔案,不能多個mapper對一個gzip檔案的多個chunk進行並行的處理,
因此如果要在hadoop mapreduce任務中使用gzip,在資料處理之前就需要對資料進行認為的切分,讓一個mapper來處理一塊資料。這樣其實有一點有違 mapreduce的本質。