Лучшее сплитматическое сжатие для входа Hadoop = bz2?

Ответ 1

BZIP2 является разделяемым в hadoop - он обеспечивает очень хорошую степень сжатия, но от времени процессора и производительности не обеспечивает оптимальных результатов, так как сжатие очень потребляет процессор.

LZO расщепляется в hasoop - используя hadoop-lzo, у вас есть сплитбельная сжатая LZO. Вам нужно иметь внешние .lzo.index файлы, чтобы иметь возможность обрабатывать параллельно. Библиотека предоставляет все способы генерации этих индексов локальным или распределенным образом.

LZ4 расщепляется в hasoop - используя hadoop-4mc, у вас есть сплиттируемые сжатые 4mc. Вам не нужна внешняя индексация, и вы можете создавать архивы с предоставленным инструментом командной строки или кодом Java/C внутри/вне hadoop. 4mc выпускается на hadoop LZ4 на любом уровне скорости/сжатия: от быстрого режима до 500 МБ/с при скорости сжатия до высоких/ультрамодулей, что обеспечивает повышенную степень сжатия, почти сравнимую с GZIP.

Ответ 2

Я не считаю правильный ответ правильным, bzip2 в соответствии с этим:

http://comphadoop.weebly.com/

расщепляется. LZO тоже индексируется.

Итак, ответ "да", если вы хотите использовать больше картографов, чем у вас есть файлы, тогда вы захотите использовать bzip2.

Чтобы сделать это, вы можете написать простое задание MR для чтения данных, а затем просто записать его снова, тогда вам нужно убедиться, что вы установили mapred.output.compression.codec в org.apache.hadoop.io.compress.BZip2Codec

Ответ 3

Вот пять способов с gzip, три - с индексом, два - нет.

Можно создать индекс для любого файла gzip, т.е. специально не сконструированного, как это сделано zran.c. Затем вы можете начать декомпрессию на границах блоков. Индекс включает 32K несжатой истории данных в каждой точке входа.

Если вы создаете файл gzip, его можно сделать с помощью периодических точек входа, индекс которых не нуждается в несжатой истории в этих точках входа, делая для меньшего индекса. Это делается с опцией Z_FULL_FLUSH на deflate() в zlib.

Вы также можете сделать Z_SYNC_FLUSH, за которым следует Z_FULL_FLUSH в каждой такой точке, которая вставляет два маркера. Затем вы можете найти девятибайтный шаблон 00 00 ff ff 00 00 00 ff ff, чтобы найти их. Это не отличается от поиска шестибайтового маркера в файлах bzip2, за исключением того, что ложный положительный результат гораздо менее вероятен с девятью байтами. Тогда вам не нужен отдельный индексный файл.

Оба gzip и xz поддерживают простую конкатенацию. Это позволяет вам легко подготовить архив для параллельной декомпрессии по-другому. Короче говоря:

gzip < a > a.gz
gzip < b > b.gz
cat a.gz b.gz > c.gz
gunzip < c.gz > c
cat a b | cmp - c

приведет к следующему результату сравнения.

Затем вы можете просто сжать куски нужного размера и объединить результаты. Сохраните индекс в смещениях начала каждого потока gzip. Декомпрессия от этих смещений. Вы можете выбрать размер кусков по своему усмотрению, в зависимости от вашего приложения. Если вы сделаете их слишком маленькими, сжатие будет затронуто.

С простой конкатенацией файлов gzip вы также можете отказаться от индекса, если вы сделали каждый кусок фиксированным несжатым размером. Затем каждый фрагмент заканчивается теми же четырьмя байтами, несжатая длина в порядке порядка юнитов, например. 00 00 10 00 для 1 кусков MiB, затем 1f 8b 08 из следующего фрагмента, который является началом заголовка gzip. Этот семибайтовый маркер можно искать так же, как маркер bzip2, хотя и с меньшей вероятностью ложных срабатываний.

То же самое можно сделать с конкатенированными файлами xz, заголовком которых является семь байтов: fd 37 7a 58 5a 00 00.