GZIP、LZO、Zippy/Snappy是常用的幾種壓縮算法，各自有其特點，因此適用的應(yīng)用場景也不盡相同。這里結(jié)合相關(guān)工程實踐的情況，做一次小結(jié)。

作者: 大圓那些事 | 文章可以轉(zhuǎn)載，請以超鏈接形式標明文章原始出處和作者信息

網(wǎng)址: http://www.rzrgm.cn/panfeng412/archive/2012/12/24/applications-scenario-summary-of-compression-algorithms.html

GZIP、LZO、Zippy/Snappy是常用的幾種壓縮算法，各自有其特點，因此適用的應(yīng)用場景也不盡相同。這里結(jié)合相關(guān)工程實踐的情況，做一次小結(jié)。

壓縮算法的比較

以下是Google幾年前發(fā)布的一組測試數(shù)據(jù)（數(shù)據(jù)有些老了，有人近期做過測試的話希望能共享出來）：

Algorithm	% remaining	Encoding	Decoding
GZIP	13.4%	21 MB/s	118 MB/s
LZO	20.5%	135 MB/s	410 MB/s
Zippy/Snappy	22.2%	172 MB/s	409 MB/s

 

 

 

 

注：來自《HBase: The Definitive Guide》

其中：

1）GZIP的壓縮率最高，但是其實CPU密集型的，對CPU的消耗比其他算法要多，壓縮和解壓速度也慢；

2）LZO的壓縮率居中，比GZIP要低一些，但是壓縮和解壓速度明顯要比GZIP快很多，其中解壓速度快的更多；

3）Zippy/Snappy的壓縮率最低，而壓縮和解壓速度要稍微比LZO要快一些。

BigTable和HBase中壓縮算法的選擇

BigTable中采用的是Zippy算法，目標是達到盡可能快的壓縮和解壓速度，同時減少對CPU的消耗。

HBase中，在Snappy發(fā)布之前（Google 2011年對外發(fā)布Snappy），采用的LZO算法，目標和BigTable類似；在Snappy發(fā)布之后，建議采用Snappy算法（參考《HBase: The Definitive Guide》），具體可以根據(jù)實際情況對LZO和Snappy做過更詳細的對比測試后再做選擇。

實際項目中的實踐經(jīng)驗

項目中使用clearspring公司開源的基數(shù)估計的概率算法：stream-lib，用于解決去重計算問題，如UV計算等，它的特點在于：

1）一個UV的計算，可以限制在一個固定大小的位圖空間內(nèi)完成（不同大小，對應(yīng)不同的誤差率），如8K，64K；

2）不同的位圖可以進行合并操作，得到合并后的UV。

當系統(tǒng)中維護的位圖越多的時候，不管是在內(nèi)存中，還是在存儲系統(tǒng)（MySQL、HBase等）中，都會占用相當大的存儲空間。因此，需要考慮采取合適的算法來壓縮位圖。這里分為以下兩類情況：

1）當位圖在內(nèi)存中時，此時壓縮算法的選擇，必須有盡可能快的壓縮和解壓速度，同時不能消耗過多CPU資源，因此，適合使用LZO或Snappy這樣的壓縮算法，做到快速的壓縮和解壓；

2）當位圖存儲到DB中時，更關(guān)注的是存儲空間的節(jié)省，要有盡可能高的壓縮率，因此，適合使用GZIP這樣的壓縮算法，同時在從內(nèi)存Dump到DB的過程也可以減少網(wǎng)絡(luò)IO的傳輸開銷。

總結(jié)的話

以上是對GZIP、LZO、Zippy/Snappy壓縮算法特點的概括比較，以及一些實踐上的方法。如有不對之處，歡迎大家指正，討論。