我有大量的服务.我记录事件.每隔几分钟,我使用gzip压缩日志并将它们旋转到S3.从那里,我们使用亚马逊的Hadoop处理日志 – 弹性mapreduce – 通过Hive.

就在服务器上,当我们压缩和旋转日志时,我们会在几分钟内获得CPU峰值.我们想要从gzip切换到lzo或snappy以帮助减少这个cpu峰值.我们是一个cpu绑定服务,所以我们愿意交换更大的日志文件,以减少旋转时消耗的CPU.

我一直在LZO和Snappy(又名zippy)上做很多阅读. LZO的一个优点是它可以在HDFS中拆分.但是,我们的文件通过Gzip压缩了大约15MB,所以我认为我们不会达到HDFS中64MB的默认块大小,所以这应该没关系.即使它确实如此,我们也应该能够将默认值调高至128MB.

现在,我想尝试一下,因为它似乎稍快/资源密集度更低.似乎没有亚马逊的yum回购,所以我们可能不得不自定义安装/构建 – 所以在工程时间方面没有太大的权衡.我听说过有关LZO许可证的一些担忧,但我想如果它不接近我们的代码,我发现它只是安装在我们的服务器上,对吧？

那么,我应该选择哪个？
一个人在Hadoop中的表现会比另一个好吗？
有没有人用这两种方法做到这一点并且有任何可以分享的问题？

最佳答案 也许为时已晚,但
Python-snappy提供了一个用于快速压缩/解压缩的命令行工具：

Compressing and decompressing a file:

$python -m snappy -c uncompressed_file compressed_file.snappy

$python -m snappy -d compressed_file.snappy uncompressed_file

Compressing and decompressing a stream:

$cat uncompressed_data | python -m snappy -c > compressed_data.snappy

$cat compressed_data.snappy | python -m snappy -d > uncompressed_data

Snappy also consistently decompresses 20%+ faster than lzo,这是一个非常大的胜利,如果你想要它的文件,你正在阅读hadoop很多.最后,it’s used by Google for stuff like BigTable and MapReduce,至少对我来说这是一个非常重要的认可.