作者: 大圓那些事 | 文章可以轉載，請以超鏈接形式標明文章原始出處和作者信息
GZIP、LZO、Zippy/Snappy是常用的幾種壓縮算法，各自有其特點，因此適用的應用場景也不盡相同。這里結合相關工程實踐的情況，做一次小結。
壓縮算法的比較
以下是Google幾年前發布的一組測試數據（數據有些老了，有人近期做過測試的話希望能共享出來）：
| 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發布之前（Google 2011年對外發布Snappy），采用的LZO算法，目標和BigTable類似；在Snappy發布之后，建議采用Snappy算法（參考《HBase: The Definitive Guide》），具體可以根據實際情況對LZO和Snappy做過更詳細的對比測試后再做選擇。
實際項目中的實踐經驗
項目中使用clearspring公司開源的基數估計的概率算法：stream-lib，用於解決去重計算問題，如UV計算等，它的特點在於：
1）一個UV的計算，可以限制在一個固定大小的位圖空間內完成（不同大小，對應不同的誤差率），如8K，64K；
2）不同的位圖可以進行合並操作，得到合並后的UV。
當系統中維護的位圖越多的時候，不管是在內存中，還是在存儲系統（MySQL、HBase等）中，都會占用相當大的存儲空間。因此，需要考慮采取合適的算法來壓縮位圖。這里分為以下兩類情況：
1）當位圖在內存中時，此時壓縮算法的選擇，必須有盡可能快的壓縮和解壓速度，同時不能消耗過多CPU資源，因此，適合使用LZO或Snappy這樣的壓縮算法，做到快速的壓縮和解壓；
2）當位圖存儲到DB中時，更關注的是存儲空間的節省，要有盡可能高的壓縮率，因此，適合使用GZIP這樣的壓縮算法，同時在從內存Dump到DB的過程也可以減少網絡IO的傳輸開銷。
總結的話
以上是對GZIP、LZO、Zippy/Snappy壓縮算法特點的概括比較，以及一些實踐上的方法。如有不對之處，歡迎大家指正，討論。