[轉] - hadoop中使用lzo的壓縮

標籤：

在hadoop中使用lzo的壓縮演算法可以減小資料的大小和資料的磁碟讀寫時間，不僅如此，lzo是基於block分塊的，這樣他就允許資料被分解成chunk，並行的被hadoop處理。這樣的特點，就可以讓lzo在hadoop上成為一種非常好用的壓縮格式。

lzo本身不是splitable的，所以當資料為text格式時，用lzo壓縮出來的資料當做job的輸入是一個檔案作為一個map。但是sequencefile本身是分塊的，所以sequencefile格式的檔案，再配上lzo的壓縮格式，就可實現lzo檔案方式的splitable。

 

由於壓縮的資料通常只有未經處理資料的1/4，在HDFS中儲存壓縮資料，可以使叢集能儲存更多的資料，延長叢集的使用壽命。不僅如此，由於mapreduce作業通常瓶頸都在IO上，儲存壓縮資料就意味這更少的IO操作，job運行更加的高效。但是，在hadoop上使用壓縮也有兩個比較麻煩的地方：第一，有些壓縮格式不能被分塊，並行的處理，比如gzip。第二，另外的一些壓縮格式雖然支援分塊處理，但是解壓的過程非常的緩慢，使job的瓶頸轉移到了cpu上，例如bzip2。比如我們有一個1.1GB的gzip檔案，該檔案 被分成128MB/chunk儲存在hdfs上，那麼它就會被分成9塊。為了能夠在mapreduce中並行的處理各個chunk，那麼各個mapper之間就有了依賴。而第二個mapper就會在檔案的某個隨機的byte出進行處理。那麼gzip解壓時要用到的上下文字典就會為空白，這就意味這gzip的壓縮檔無法在hadoop上進行正確的平行處理。也就因此在hadoop上大的gzip壓縮檔只能被一個mapper來單個的處理，這樣就很不高效，跟不用mapreduce沒有什麼區別了。而另一種bzip2壓縮格式，雖然bzip2的壓縮非常的快，並且甚至可以被分塊，但是其解壓過程非常非常的緩慢，並且不能被用streaming來讀取，這樣也無法在hadoop中高效的使用這種壓縮。即使使用，由於其解壓的低效，也會使得job的瓶頸轉移到cpu上去。

如果能夠擁有一種壓縮演算法，即能夠被分塊，並行的處理，速度也非常的快，那就非常的理想。這種方式就是lzo。lzo的壓縮檔是由許多的小的blocks組成（約256K），使的hadoop的job可以根據block的劃分來splitjob。不僅如此，lzo在設計時就考慮到了效率問題，它的解壓速度是gzip的兩倍，這就讓它能夠節省很多的磁碟讀寫，它的壓縮比的不如gzip，大約壓縮出來的檔案比gzip壓縮的大一半，但是這樣仍然比沒有經過壓縮的檔案要節省20%-50%的儲存空間，這樣就可以在效率上大大的提高job執行的速度。以下是一組壓縮對比資料，使用一個8.0GB的未經過壓縮的資料來進行對比：

壓縮格式	檔案	大小(GB)	壓縮時間	解壓時間
None	some_logs	8.0	-	-
Gzip	some_logs.gz	1.3	241	72
LZO	some_logs.lzo	2.0	55	35

可以看出，lzo壓縮檔會比gzip壓縮檔稍微大一些，但是仍然比原始檔案要小很多倍，並且lzo檔案壓縮的速度幾乎相當於gzip的5倍，而解壓的速度相當於gzip的兩倍。lzo檔案可以根據blockboundaries來進行分塊，比如一個1.1G的lzo壓縮檔，那麼處理第二個128MBblock的mapper就必須能夠確認下一個block的boundary，以便進行解壓操作。lzo並沒有寫什麼資料頭來做到這一點，而是實現了一個lzoindex檔案，將這個檔案（foo.lzo.index）寫在每個foo.lzo檔案中。這個index檔案只是簡單的包含了每個block在資料中的offset，這樣由於offset已知的緣故，對資料的讀寫就變得非常的快。通常能達到90-100MB/秒，也就是10-12秒就能讀完一個GB的檔案。一旦該index檔案被建立，任何基於lzo的壓縮檔就能通過load該index檔案而進行相應的分塊，並且一個block接一個block的被讀取。也因此，各個mapper都能夠得到正確的block，這就是說，可以只需要進行一個LzopInputStream的封裝，就可以在hadoop的mapreduce中並行高效的使用lzo。如果現在有一個job的InputFormat是TextInputFormat，那麼就可以用lzop來壓縮檔，確保它正確的建立了index，將TextInputFormat換成LzoTextInputFormat，然後job就能像以前一樣正確的運行，並且更加的快。有時候，一個大的檔案被lzo壓縮過之後，甚至都不用分塊就能被單個mapper高效的處理了。

[轉] - hadoop中使用lzo的壓縮