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的一些优点：

① 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