我有大量的服务。我记录事件。每隔几分钟，我使用gzip压缩日志并将其旋转到s3。在那里，我们使用amazon的hadoop——ElasticMapReduce——通过hive处理日志。
现在，在服务器上，当我们压缩和旋转日志时，cpu会在几分钟内出现峰值。我们希望从gzip切换到lzo或snappy，以帮助减少cpu峰值。我们是一个cpu受限的服务，所以我们愿意用更大的日志文件换取更少的cpu消耗。
我读了很多关于lzo和snappy（又名zippy）的书。lzo的优点之一是它在hdfs中是可拆分的。但是，我们的文件是通过gzip压缩的~15mb，所以我认为在hdfs中不会达到64mb的默认块大小，所以这不重要。即使是这样，我们也应该能够将默认值调到128mb。
现在，我想试试snappy，因为它似乎稍微快一点/资源密集度低一点。两者似乎都不在amazon的yum repo中，因此我们可能无论如何都必须定制安装/构建--因此在工程时间方面没有多少折衷。我听说了一些关于lzo许可证的问题，但我认为我发现只要在我们的服务器上安装它，如果它不接近我们的代码，对吗？
那么，我该选哪一个呢？一个在hadoop中的性能会比另一个更好吗？是否有人在其中一个实现中做到了这一点，并且有任何问题可以分享？
1条答案
按热度按时间sqougxex1#
也许为时已晚，但python snappy提供了一个用于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_datasnappy的解压速度也一直比lzo快20%以上，如果你想在hadoop上读很多的文件，这是一个很大的成功。最后，它被google用于bigtable和mapreduce之类的东西，这至少对我来说是一个非常重要的认可。