Snappy или LZO для журналов, которые затем используются Hadoop

У меня большой объем услуг. Я регистрирую события. Каждые несколько минут я архивирую журналы с помощью gzip и перемещаю их на S3. Оттуда мы обрабатываем журналы с помощью Amazon Hadoop — эластичного mapreduce — через Hive.

Прямо сейчас на серверах мы получаем всплеск загрузки ЦП каждые несколько минут, когда мы архивируем и ротируем журналы. Мы хотим переключиться с gzip на lzo или snappy, чтобы уменьшить этот всплеск загрузки процессора. Мы являемся сервисом, привязанным к процессору, поэтому мы готовы обменять большие файлы журналов на меньшее потребление процессора при ротации.

Я много читал о LZO и Snappy (он же zippy). Одним из преимуществ LZO является возможность разделения в HDFS. Тем не менее, наши файлы ~15 МБ заархивированы через Gzip, поэтому я не думаю, что мы доберемся до размера блока 64 МБ по умолчанию в HDFS, так что это не должно иметь значения. Даже если это так, мы должны просто увеличить значение по умолчанию до 128 МБ.

Прямо сейчас я хочу попробовать snappy, так как он кажется немного быстрее/менее ресурсоемким. Кажется, ни того, ни другого нет в репозитории yum от Amazon, поэтому нам, вероятно, все равно придется устанавливать / собирать на заказ - так что это не большой компромисс с точки зрения времени разработки. Я слышал некоторые опасения по поводу лицензии LZO, но я думаю, что просто установлю ее на наш сервер, если она не соответствует нашему коду, верно?

Итак, что мне выбрать? Будет ли один из них работать в Hadoop лучше, чем другой? Кто-нибудь сделал это с любой реализацией и есть какие-либо проблемы, которыми они могли бы поделиться?


person John Hinnegan    schedule 26.09.2012    source источник
comment
Взгляните на сообщение в блоге Cloudera. Они подробно рассказывают о каждом из них и рекомендуют Snappy. blog.cloudera.com/blog/2011/09/snappy-and -hadoop Вы также можете найти тесты различных типов сжатия здесь: github. com/ning/jvm-compressor-benchmark/wiki   -  person Dimitry    schedule 04.01.2013
comment
Спасибо. Мы остановились на LZO. Мы сравнивали только время сжатия, которое примерно эквивалентно. Нам также было трудно найти надежный и быстрый инструмент командной строки, что очень важно, когда вам нужно время от времени проверять данные вручную.   -  person John Hinnegan    schedule 07.01.2013


Ответы (1)


Возможно, уже слишком поздно, но 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 также стабильно распаковывает на 20%+ быстрее, чем lzo, что является довольно большим преимуществом, если вы хотите, чтобы файлы Начитались хаупа. Наконец, он используется Google для таких вещей, как BigTable и MapReduce, что является действительно важное одобрение для меня, по крайней мере.

person Eli    schedule 28.03.2013
comment
Спасибо. Мы закончили тем, что выбрали lzo — у нас был lzop. Это хорошо знать, хотя. Хотя, вероятно, это коррелирует, на самом деле нас больше всего беспокоят требования к ЦП и памяти для сжатия. Наши внешние хосты должны выполнять сжатие (на тех же хостах, которые обслуживают живой трафик), тогда как распаковка всегда происходит в автономном режиме. В то время отсутствие удобного инструмента командной строки было большим сдерживающим фактором. Возможно, мне нужно будет пересмотреть. - person John Hinnegan; 29.03.2013