Вопрос по – Формат хранения в HDFS

4

How Does HDFS store data?

Я хочу хранить огромные файлы в сжатом виде.

Например, у меня есть 1,5 ГБ файла с коэффициентом репликации по умолчанию 3.

Требуется (1,5) * 3 = 4,5 ГБ пространства.

Я считаю, что в настоящее время не происходит неявного сжатия данных.

Is there a technique to compress the file and store it in HDFS to save disk space ?

Ваш Ответ

4   ответа
0

Во. По сути, это вопрос разделения данных, поскольку файл делится на блоки, которые являются элементарными блоками для репликации. Имя узла отвечает за отслеживание всех этих блоков, принадлежащих одному файлу. При выборе сжатия важно, чтобы блок был автономным - не все кодеки разделяемы. Если формат + кодек не разделяемый, это означает, что для его распаковки он должен находиться в одном месте, что оказывает большое влияние на параллелизм в mapreduce. По сути работает в одном слоте. Надеюсь, это поможет

0

Hadoop_Summit, особенно Слайд 6 и Слайд 7.

Если размер блока DFS составляет 128 МБ, для хранения 4,5 ГБ (включая коэффициент репликации 3) необходимо 35,15 (~ 36 блоков)Only формат файла bzip2 разделяемый. В других форматах все блоки целых файлов хранятся в том же датоде Посмотрите на типы алгоритмов, имена классов и кодеки@ Chris White answer предоставляет информацию о том, как включить архивирование при написании вывода карты.
6

ся для каждого файла, но имеет значение по умолчанию (например, 64/128/256 МБ)

Так как для файла размером 1,5 ГБ и размера блока 128 МБ hadoop разбил бы файл на ~ 12 блоков (12 x 128 МБ ~ = 1,5 ГБ). Каждый блок также реплицируется настраиваемое количество раз.

Если ваши данные хорошо сжимаются (например, текстовые файлы), то вы можете сжать файлы и сохранить сжатые файлы в HDFS - то же самое относится и к описанному выше, поэтому, если файл объемом 1,5 ГБ сжимается до 500 МБ, он будет храниться как 4 блока.

Однако при использовании сжатия важно учитывать, поддерживает ли метод сжатия разбиение файла, то есть можно ли произвольно искать позицию в файле и восстанавливать сжатый поток (например, GZIp не поддерживает разбиение, BZip2 поддерживает).

Даже если метод не поддерживает разбиение, hadoop все равно будет хранить файл в нескольких блоках, но вы потеряете некоторое преимущество «локальности данных», так как блоки, скорее всего, будут распределены по вашему кластеру.

В вашей карте уменьшен код, Hadoop по умолчанию имеет несколько кодеков сжатия и автоматически распознает определенные расширения файлов (например, .gz для файлов GZip), что избавляет вас от беспокойства о необходимости сжатия ввода-вывода. .

Надеюсь, это имеет смысл

РЕДАКТИРОВАТ Дополнительная информация в ответ на комментарии:

При записи в HDFS в качестве вывода из задания Map Reduce см. API для FileOutputFormat, в частности следующие методы:

setCompressOutput (Job, логическое значение)setOutputCompressorClass (Job, Class)

При загрузке файлов в HDFS, да, они должны быть предварительно сжаты, и с соответствующим расширением файла для этого типа сжатия (из коробки, hadoop поддерживает gzip с расширением .gz, поэтому file.txt.gz будет обозначать gzipped файл

Так, Hadoop не имеет механизма для неявного сжатия файла, если я делаю "hadoop fs -copyFromLocal ...". Нам придется явно сжать файл, а затем скопировать в Hdfs. Итак, вы хотите сказать, что метод сжатия, который нужно использовать, должен быть разделяемым; если это не так, если я хочу выполнить некоторые задания MR, то это может не дать правильных результатов? Итак, если я хочу использовать hdf только для хранения, я могу использовать любую технику сжатия. Однако, если мне нужно запустить задания MR, то лучше использовать сжатие, которое поддерживает разбиение. Это правильно Uno
0

чтобы сначала понять формат файла, доступный сегодня в Hadoop. Теперь в HDFS есть выбор, который может управлять форматом файла и методами сжатия. Альтернатива явному кодированию и разбиению с использованием LZO или BZIP. В настоящее время существует множество форматов, которые поддерживают сжатие блоков и сжатие столбцов строк с функциями.

Формат хранения - это способ определения способа хранения информации. Иногда это обычно указывается расширением файла. Например, мы знаем, что изображения могут иметь несколько форматов хранения: PNG, JPG, GIF и т. Д. Все эти форматы могут хранить одно и то же изображение, но каждый имеет свои особенности хранения.

В файловой системе Hadoop у вас есть все традиционные форматы хранения, доступные вам (например, вы можете хранить изображения PNG и JPG в HDFS, если хотите), но у вас также есть некоторые форматы файлов, ориентированные на Hadoop, которые можно использовать для структурированных и неструктурированных данных.

Почему важно знать эти форматы

При любых компромиссах в производительности огромным узким местом для приложений с поддержкой HDFS, таких как MapReduce, Hive, HBase и Spark, является время, необходимое для поиска соответствующих данных в определенном месте и время, необходимое для записи данных в другое место. Эти проблемы усугубляются при управлении большими наборами данных. Форматы файлов Hadoop эволюционировали, чтобы облегчить эти проблемы в ряде случаев использования.

Выбор подходящего формата файла может иметь некоторые существенные преимущества:

Оптимум времени чтения Оптимум времени записи Разделение или разбиение файлов (поэтому вам не нужно читать весь файл, только его часть) Адаптация схемы (возможность изменения поля в наборе данных) Поддержка сжатия (без ущерба для этих функций)

Некоторые форматы файлов предназначены для общего использования, другие предназначены для более конкретных случаев использования (например, для питания базы данных), а некоторые разработаны с учетом конкретных характеристик данных. Поэтому при хранении данных в Hadoop действительно существует большой выбор, и нужно знать, как оптимально хранить данные в HDFS. В настоящее время я хожу в хранилище в формате ORC.

Проверьте, поддерживают ли ваши компоненты больших данных (Spark, Hive, HBase и т. Д.) Этот формат, и примите соответствующее решение. Например, в настоящее время я внедряю данные в Hive и преобразовываю их в формат ORC, который мне подходит с точки зрения сжатия и производительности.

Некоторые распространенные форматы хранения для Hadoop:

Хранение текста в тексте (например, файлы CSV, TSV, файлы с разделителями и т. Д.)

Data размещается в строках, каждая из которых является записью. Строки заканчиваются символом новой строки \ n в типичном мире UNIX. Текстовые файлы по своей природе разделимы. но если вы хотите сжать их, вам придется использовать кодек сжатия на уровне файлов, который поддерживает разбиение, такой как BZIP2. Это неэффективно и потребует немного работы при выполнении задач MapReduce.

Последовательные файлы

Первоначально разработан для MapReduce, поэтому его очень легко интегрировать в процессы Hadoop MapReduce. Они кодируют ключ и значение для каждой записи и ничего более. Хранится в двоичном формате, который меньше, чем текстовый формат. Даже здесь он не кодирует ключ и значение в любом случае. Одним из преимуществ файлов последовательностей является то, что они поддерживают сжатие на уровне блоков, поэтому вы можете сжимать содержимое файла, сохраняя при этом возможность разбивать файл на сегменты для нескольких задач карты. Хотя по статистике вроде Parquet и ORC все еще неэффективен.

Avro

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

Парке

Мой любимый и горячий формат в эти дни. Это столбчатая структура хранения файлов при кодировании и записи на диск. Таким образом, наборы данных разделены как по горизонтали, так и по вертикали. Одно огромное преимущество форматов файлов, ориентированных на столбцы, заключается в том, что данные в одном и том же столбце, как правило, сжимаются друг с другом, что может привести к значительной оптимизации хранилища (поскольку данные в одном и том же столбце имеют тенденцию быть похожими). Попробуйте использовать это, если ваша обработка может оптимально использовать хранилище столбцов. Вы можете сослаться на преимущества колонных хранилищ.

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

ORC

ORC означает «Оптимизированный столбец строк», что означает, что он может хранить данные оптимизированным способом, чем другие форматы файлов. ORC уменьшает размер исходных данных до 75% (например, файл размером 100 ГБ станет 25 ГБ). В результате скорость обработки данных также увеличивается. ORC показывает лучшую производительность, чем форматы текста, последовательности и RC. Файл ORC содержит данные строк в группах, называемых полосами, а также нижний колонтитул файла. Формат ORC повышает производительность, когда Hive обрабатывает данные.

Это похоже на паркет, но с другой техникой кодирования. Это не для этой темы, но вы можете посмотреть на Google для различий.

Похожие вопросы