Snappy或LZO用于由Hadoop消耗的日志

Question

我有一个高流量的服务，我记录事件。每隔几分钟，我使用gzip压缩并将日志旋转到S3中。从那里，我们使用Amazon的Hadoop -- Elastic MapReduce -- 通过Hive处理日志。

目前在服务器上，当我们压缩和旋转日志时，我们会出现CPU峰值。我们想要从gzip切换到lzo或snappy以帮助减少这种CPU峰值。我们是一个CPU限制型服务，所以我们愿意为较少的CPU消耗而交换更大的日志文件。

我一直在阅读LZO和Snappy（也称zippy）方面的资料。 LZO的优点之一是它在HDFS中是可分割的。然而，我们的文件经过Gzip压缩后大约为15MB，因此我认为我们不会达到HDFS中64MB的默认块大小，因此这不应该成为问题。即使如此，我们应该能够将默认值调高到128MB。

目前，我想尝试Snappy，因为它似乎略微更快/资源占用更少。两者都不在Amazon的yum存储库中，因此我们可能需要自定义安装/构建--因此在工程时间方面没有太多的权衡。我听说过一些关于LZO许可证的担忧，但是如果它不接近我们的代码，我认为在我们的服务器上安装它就可以了，对吗？

那么，我应该选择哪一个呢？ 其中一个在Hadoop中的表现会比另一个更好吗？ 有人使用其中任何一种实现并分享任何问题吗？

- John Hinnegan

---

看看Cloudera的博客文章。他们详细介绍了每个压缩类型并推荐使用Snappy。http://blog.cloudera.com/blog/2011/09/snappy-and-hadoop/ 您还可以在此处找到各种压缩类型的基准测试：https://github.com/ning/jvm-compressor-benchmark/wiki - Dimitry

谢谢。我们最终选择了LZO。我们仅比较了压缩时间，它们大致相等。我们还很难找到一个可靠的snappy命令行工具，而这在您需要偶尔手动检查数据时非常重要。 - John Hinnegan

Answer 1

也许有些晚了，但Python-snappy提供了一个用于Snappy压缩/解压缩的命令行工具：

压缩和解压缩文件：

$ python -m snappy -c 未压缩文件 压缩后文件.snappy

$ python -m snappy -d 压缩后文件.snappy 未压缩文件

压缩和解压缩流：

$ cat 未压缩数据 | python -m snappy -c > 压缩后数据.snappy

$ cat 压缩后数据.snappy | python -m snappy -d > 未压缩数据

Snappy解压速度比lzo快20%以上, 如果您想在hadoop上频繁读取文件，则这是一个非常大的优势。最后，Google将其用于BigTable和MapReduce等项目, 对我来说这是一个非常重要的认可。

- Eli

---

谢谢。我们最终选择了lzo -- 我们有lzop。虽然可能相关，但我们实际上最关心的是压缩CPU和内存要求。我们的前端主机必须进行压缩（在为实时流量提供服务的同一主机上），而解压始终是离线完成的。当时没有方便的命令行工具是一个很大的障碍。也许我需要重新考虑一下。 - John Hinnegan