Обработка больших двоичных файлов с помощью Hadoop

Я знаю, что здесь были подобные сообщения, но я не могу найти ни одного, у которого действительно есть твердый ответ.

У нас есть кластер Hadoop, загруженный бинарными файлами. Эти файлы могут иметь размер от нескольких сотен тысяч до сотен мегабайт.

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

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

Есть ли изящный способ обработки таких больших двоичных файлов? Особенно те, которые нельзя разделить, потому что мы не знаем, в каком порядке редуктор соберет их вместе?


large-files hadoop mapreduce binary-data
person Matt E    schedule 20.06.2012    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Так что не ответ как таковой, но у меня так много вопросов, что список комментариев было бы труднее передать, так что вот:

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

  • Содержат ли они логические записи, то есть один входной файл представляет собой одну запись или содержит много записей?
  • Сжаты ли файлы (постфактум или какой-то внутренний механизм сжатия)?
  • Как вы в настоящее время обрабатываете этот файл одновременно, какова ваша общая логика ETL для преобразования в JSON?
  • Вам действительно нужно прочитать весь файл, прочитанный в память, прежде чем обработка может начаться, или вы можете обработать, как только у вас будет заполнен буфер некоторого размера (например, синтаксический анализ DOM vs SAX XML).

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

Чтобы решить некоторые моменты в вашем вопросе:

  • NameNode требует памяти только для хранения информации о блоках (имена, блоки [размер, длина, расположение]). Предполагая, что вы назначаете ему приличный объем памяти (ГБ), нет никаких причин, по которым вы не можете иметь кластер, который хранит петабайты данных в хранилище HDFS (при условии, что у вас достаточно физического хранилища).
person Chris White    schedule 21.06.2012
comment
Крис, это файлы TIFF, содержащие много логических записей. Мы извлекаем определенные метаданные из файлов TIFF и преобразовываем их в JSON. Я считаю, что мы должны прочитать весь файл. - person Matt E; 05.07.2012
comment
Я предполагаю, что логические записи являются подфайлами, как описано в en.wikipedia.org/wiki/ - person Chris White; 05.07.2012
comment
На самом деле нет, в этом случае нам не нужно беспокоиться о подфайлах. - person Matt E; 06.07.2012
comment
То есть в таком случае каждый файл TIFF содержит одну запись? - person Chris White; 06.07.2012
comment
Какие метаданные вы извлекаете — на основе содержимого или фактических метаданных, хранящихся в заголовке файла? - person Chris White; 06.07.2012

arrow_upward
0
arrow_downward

Namenode не имеет ничего общего ни с хранением, ни с обработкой. Вместо этого вы должны сосредоточиться на своих узлах данных и трекерах задач. Также я не понимаю, пытаетесь ли вы решить проблему хранения или обработки ваших файлов здесь. Если вы имеет дело с большим количеством двоичных файлов, стоит взглянуть на Hadoop SequenceFile. SequenceFile — это плоский файл, состоящий из двоичных пар ключ/значение, поэтому он широко используется в MapReduce в качестве форматов ввода/вывода. Для подробного объяснения вы можете посетить эту страницу -

http://wiki.apache.org/hadoop/SequenceFile
person Tariq    schedule 20.06.2012

arrow_upward
0
arrow_downward

Если у вас есть большие двоичные файлы, используйте формат SequenceFile в качестве входного формата и соответствующим образом задайте размер разделения ввода mapred. Вы можете установить количество картографов на основе общего размера ввода и размера разделения, который вы установили. Hadoop позаботится о разделении входных данных.

Если у вас есть бинарные файлы, сжатые в каком-либо формате, то Hadoop не может выполнить такое разделение. Таким образом, двоичный формат должен быть SequenceFile.

person Prakash Chockalingam    schedule 21.06.2012