本篇文章做了小部分更改,仅介绍了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.