hadoop - 用于日志的 Snappy 或 LZO，然后由 hadoop 使用

Question

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

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

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

现在，我想试试 snappy，因为它似乎速度稍快/占用资源较少。两者似乎都不在亚马逊的 yum 存储库中，因此我们可能无论如何都必须自定义安装/构建——因此在工程时间方面没有太多的权衡。我听说过一些关于 LZO 许可证的担忧，但我认为如果它不接近我们的代码，我会发现只需将它安装在我们的服务器上，对吗？

那么，我应该选择哪个呢？ 一个在 Hadoop 中的表现会比另一个更好吗？ 有没有人通过这两种实现方式完成过此操作并且有任何问题可以分享？

Answer 1

也许为时已晚，但是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 ，这至少对我来说是一个非常重要的认可。