2016-07-22 1 views
3

Обычно говорят, что любой формат сжатия, такой как Gzip, при использовании вместе с форматом файла контейнера, таким как avro и последовательность (форматы файлов), сделает формат сжатия разделенным.Форматы сжатия файлов и форматы файлов в контейнере

Означает ли это, что блоки в формате контейнера сжаты на основе предпочтительного сжатия (например, gzip) или чего-то еще. Может ли кто-нибудь объяснить это? Благодаря!

Ну, думаю, вопрос требует обновления.

Update:

У нас есть простой подход, чтобы преобразовать большой файл в неразрываемом формате сжатие файлов (как Gzip) в расщепимый файл (используя формат файл-контейнера, такие как Avro, последовательность или паркет) для обработки MapReduce?

Примечание. Я не хочу просить обходных решений, таких как разжатие файла, и снова сжимание данных с использованием формата сплиттируемого сжатия.

ответ

1

Для файлов последовательности, если вы указали BLOCK сжатие, каждый блок будет сжиматься с использованием указанного кодека сжатия. Блоки позволяют Hadoop разделить данные на уровне блока, используя сжатие (когда само сжатие не является раздробленным) и пропускать целые блоки без необходимости их распаковывать.

Большинство это описано на вики Hadoop: https://wiki.apache.org/hadoop/SequenceFile

Блок сжатых ключ/значение записи - оба ключа и значения собраны в «блоки» отдельно и прессуют. Размер «блок» настраивается.

Для Avro это все очень похожи, а также: https://avro.apache.org/docs/1.7.7/spec.html#Object+Container+Files

Объекты хранятся в блоках, которые могут быть сжаты. Синхронизация маркеры используются между блоками, чтобы обеспечить эффективное разделение файлов для обработки MapReduce.

Таким образом, двоичные данные каждого блока могут быть эффективно извлечены или пропущены без десериализации содержимого.

Самый простой (и, как правило, самый быстрый) способ преобразования данных из одного формата в другой - это позволить MapReduce выполнять эту работу за вас. В примере:

GZip Text -> SequenceFile

Вы бы иметь карту только работу, которая использует TextInputFormat для входов и выходов SequenceFileFormat. Таким образом, вы получаете преобразование 1 к 1 на количество файлов (добавьте шаг уменьшения, если это необходимо изменить), и вы выполняете преобразование параллельно, если есть много файлов для конвертирования.

+0

Можно ли использовать формат контейнера поверх файла, сжатого с использованием нерастяжимого формата сжатия? – Marco99

+0

Термин 'container' немного запутан, они являются« файловыми форматами », поэтому должна быть какая-то форма преобразования, если вы хотите взять существующий файл и преобразовать его в другой формат. Вы не можете просто _wrap_ файл в чем-то. –

+0

Извините за путаницу. Упомянув «форматы файлов контейнеров», я имел в виду только форматы файлов hadoop, такие как Avro. – Marco99

0

Не знаю, о чем вы действительно говорите ... но любой файл может быть разделен в любой момент.

Почему я говорю это ... надеясь, что вы используете что-то вроде Linux или аналогичного.

В Linux (не так много) легко создать блок-устройство, которое действительно хранится при объединении некоторых файлов.

Я имею в виду:

  • Вы разбить файл на столько же куски, как вы хотите, каждый из другого размера, нет необходимости быть ООД или даже размер, кратен 512 байт, и т.д., независимо от размера вы хотите, математически expresed splitted_file_size = (wish_size mod 1).
  • Вы определяете блочное устройство, объединяющее все файлы в правильном порядке
  • Вы определяете символическую ссылку на такое устройство

Таким образом, вы можете иметь большой файл (более 16GiB, более 4GiB) хранящийся на одном разделе FAT32 (который имеет ограничение на 4 гигабайта на 1 байт на файл) ... и доступ к нему «на лету» и прозрачно ... мышление только при чтении.

Для чтения/записи ... есть трюк (то есть сложная часть), которая работает:

  • Разбить файл (на этот раз в кусках N * 512 байт)
  • Определит драйвер устройства параметризованный (так он знает, как выделить больше кусков, создав несколько файлов)

в Linux я использовал в прошлом некоторых инструментов (командная строка), которые делают всю работу, и они позволяют создать виртуальный контейнер, изменяемый на лету, который будет использовать файлы точного размера (включая последний) и предоставляет его как обычное блочное устройство (где вы можете сделать dd if = ... of = ... для его заполнения) и связанный с ним виртуальный файл.

Таким образом, у вас есть:

  • Некоторые не столь большие файлы одинакового размера
  • Они будут держать внутри реальных данных потока
  • Они созданы/удалены по мере необходимости (расти/сокращаться или усечение)
  • Они подвергаются как обычный файл на какой-то момент
  • экранным такой файл будет как видно конкатенации

Может быть, дает представление о других ПОДХОД к проблеме вы имеете:

  • Вместо того, чтобы настроить систему сжатия, просто положить слой (немного более сложным, что простое устройство контура), что делать на лету и прозрачно Разделение/присоединение

Такие инструменты существуют, я не помню названия, извините! Но я помню один только для чтения (dvd_double_layer * находятся на файловой системе FAT32.):

# cd /mnt/FAT32 
# ls -lh dvd_double_layer.* 
total # 
-r--r--r-- 1 root root 3.5G 2017-04-20 13:10 dvd_double_layer.000 
-r--r--r-- 1 root root 3.5G 2017-04-20 13:11 dvd_double_layer.001 
-r--r--r-- 1 root root 0.2G 2017-04-20 13:12 dvd_double_layer.002 
# affuse dvd_double_layer.000 /mnt/transparent_concatenated_on_the_fly 
# cd /mnt/transparent_concatenated_on_the_fly 
# ln -s dvd_double_layer.000.raw dvd_double_layer.iso 
# ls -lh dvd_double_layer.* 
total # 
-r--r--r-- 1 root root 7.2G 2017-04-20 13:13 dvd_double_layer.000.raw 
-r--r--r-- 1 root root 7.2G 2017-04-20 13:14 dvd_double_layer.iso 

Надежда эта идея может помочь вам.

 Смежные вопросы

  • Нет связанных вопросов^_^