本篇文章做了小部分更改，僅介紹了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的一些優點：
① Map tasks begin transferring data sooner compared to Gzip or Bzip (though more data needs to be transferred to Reduce tasks)
相比Gzip和Bzip來說的話，使用Snappy，Map任務會更早的開始去傳輸數據。這個優點顯而易見了，呵呵，因爲其壓縮速度比Gzip要快好多倍了，早完成早傳輸。但是其傳輸給Reduce任務的數據要大一些。
② Reduce tasks run faster with better decompression speeds.
因爲更快地解壓速度，Reduce任務跑的更快。
③ Snappy is not CPU intensive – which means MR tasks have more CPU for user operations.
Snappy 不是CPU敏感型的，不會佔用大量的cpu.
適合Snappy發揮其長處的場合：
① Map output. Snappy works great if you have large amounts of data flowing from Mappers to the Reducers (you might not see a significant difference if data volume between Map and Reduce is low)
Snappy尤其適合於從Mappers到 Reducers有大量數據搬運的場合。
②Temporary Intermediate files(臨時中間文件). If you have a series of MR jobs chained together, Snappy compression is a good way to store the intermediate files. Please do make sure these intermediate files are cleaned up soon enough so we don’t have disk space issues on the cluster.
對於一些列鏈接在一起的MR任務，適合使用Snappy去存儲這些Job間的臨時中間文件。但是要保證能夠儘快的清除這些臨時文件。
不適合使用Snappy的場合：
① Permanent Storage: Snappy compression is not efficient space-wise and it is expensive to store data on HDFS (3-way replication)
永久性存儲
② Plain text files: Like Gzip, Snappy is not splittable. Do not store plain text files in Snappy compressed form, instead use a container like SequenceFile.
轉載自：http://m.blog.csdn.net/blog/yydcj/8783994