個人小站,正在持續整理中,歡迎訪問:http://shitouer.cn
小站博文地址：Hadoop壓縮-SNAPPY算法安裝
本篇文章做了小部分更改，僅介紹了Snappy，去掉了安裝過程，不過不必嘆氣，更加詳細的Hadoop Snappy及HBase Snappy的安裝步驟已經另起了一篇文章專門來介紹：Hadoop HBase 配置 安裝 Snappy 終極教程 通過這篇文章，相信你一定會幾乎毫無困難的成功安裝Snappy。
Compression就是在用CPU換IO吞吐量/磁盤空間，如果沒有什么特殊原因推薦針對Column Family設置compression，下面主要有三種算法: GZIP, LZO, Snappy，作者推薦使用Snappy，因為它有較好的Encoding/Decoding速度和可以接受的壓縮率。
Comparison between compression algorithms
| 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 |
Snappy已經被Google開源，作為一個壓縮庫，它可以利用單顆Intel Core i7處理器內核處理至少每秒250MB~500MB的數據流。
Snappy的前身是Zippy。雖然只是一個數據壓縮庫，它卻被Google用於許多內部項目程，其中就包括BigTable，MapReduce和RPC。Google宣稱它在這個庫本身及其算法做了數據處理速度上的優化，作為代價，並沒有考慮輸出大小以及和其他類似工具的兼容性問題。Snappy特地為64位x86處理器做了優化，在單個Intel Core i7處理器內核上能夠達到至少每秒250MB的壓縮速率和每秒500MB的解壓速率。
如果允許損失一些壓縮率的話，那么可以達到更高的壓縮速度，雖然生成的壓縮文件可能會比其他庫的要大上20%至100%，但是，相比其他的壓縮庫，Snappy卻能夠在特定的壓縮率下擁有驚人的壓縮速度，“壓縮普通文本文件的速度是其他庫的1.5-1.7倍，HTML能達到2-4倍，但是對於JPEG、PNG以及其他的已壓縮的數據，壓縮速度不會有明顯改善”。
Google極力贊揚Snappy的各種優點，Snappy從一開始就被“設計為即便遇到損壞或者惡意的輸入文件都不會崩潰”，而且被Google在生產環境中用於壓縮PB級的數據。其健壯性和穩定程度可見一斑。
Snappy也可以用於和其他壓縮庫-zlib、LZO、LZF、FastLZ和QuickLZ-做對比測試，前提是你在機器上安裝了這些壓縮庫。Snappy是一個C++的庫，你可以在產品中使用，不過也有一些其他語言的版本，例如Haskell、Java、Perl、Python和Ruby。
Snappy采用新BSD協議開源。