4

我有大量的服务。我记录事件。每隔几分钟，我使用 gzip 压缩日志并将它们旋转到 S3。从那里，我们通过 Hive 使用 Amazon 的 Hadoop（弹性 mapreduce）处理日志。

现在在服务器上，当我们压缩和旋转日志时，每隔几分钟就会出现一次 CPU 峰值。我们希望从 gzip 切换到 lzo 或 snappy 以帮助减少这种 cpu 峰值。我们是一个 cpu-bound 服务，所以我们愿意在轮换时用更大的日志文件换取更少的 cpu 消耗。

我一直在阅读有关 LZO 和 Snappy（又名 zippy）的大量内容。LZO 的优点之一是它在 HDFS 中是可拆分的。但是，我们的文件是通过 Gzip 压缩的 ~15MB，所以我认为我们不会达到 HDFS 中 64MB 的默认块大小，所以这无关紧要。即使是这样，我们也应该能够将默认值设置为 128MB。

现在，我想尝试一下 snappy，因为它似乎稍微快一些/占用更少的资源。亚马逊的 yum 存储库中似乎都没有，所以我们可能无论如何都必须自定义安装/构建——所以在工程时间方面并没有太大的权衡。我听说过一些关于 LZO 许可证的担忧，但我想如果它不靠近我们的代码，我会发现它只是安装在我们的服务器上，对吧？

那么，我应该选择哪个？一个在 Hadoop 中的性能会比另一个更好吗？有没有人用这两种实现方式做到这一点并且有任何他们可以分享的问题？

4

1 回答 1

2

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

压缩和解压文件：

$ python -m snappy -c uncompressed_file compressed_file.snappy

$ python -m snappy -d compressed_file.snappy uncompressed_file

压缩和解压缩流：

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

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

Snappy 的解压缩速度也始终比 lzo 快 20% 以上，如果您希望它用于通过 hadoop 大量阅读的文件，这是一个相当大的胜利。最后，它被 Google 用于 BigTable 和 MapReduce 之类的东西，至少对我来说这是一个非常重要的认可。

于 2013-03-28T22:49:12.380 回答