Способы хранения небольших файлов в Hadoop HDFS, отличных от HAR или Sequence Files + сомнения относительно них

java algorithm hadoop apache-spark hdfs

730 просмотра

1 ответ

754 Репутация автора

Я прочитал много записей в блоге и статей о «проблеме маленьких файлов в hadoop», но многие из них просто кажутся копией предыдущего. Более того, все они выглядят немного устаревшими, и последние (2015-й) в любом случае описывают, что этот блог Cloudera делал в начале 2009 года.
Означает ли это, что решение по архивированию не было найдено за 6 лет?

Вот причина моего исследования: мне нужно перемещать и каталогизировать файлы по мере их поступления, в разных количествах, иногда даже по одному, а затем сохранять их в HDFS .
Эти файлы будут позже доступны и возвращены на уровне веб-службы (должны быть быстрыми), чтобы открываться и просматриваться людьми или программным обеспечением.
Файлы могут быть видео, изображениями, документами , чем угодно, и к ним нужно обращаться позже, используя идентификатор, который я создаю вместе с классом Java UUID.
Выбор использовать hdfs полностью личныймоего премьер-министра, поскольку я предложил HBase, чтобы компенсировать отсутствие индексации в HDFS (хотя я не уверен, что это оптимальное решение), но он попросил меня в любом случае посмотреть на HBase в случае необходимости иметь дело с файлы большего размера (до сих пор самый большой среди 1000 был 2 МБ, но мы ожидаем, что видео 1 ГБ).
Насколько я понял, проблема маленьких файлов возникает, когда вы используете задания MapReduce для потребления памяти, но мне было интересно:
действительно ли имеет значение, сколько файлов в HDFS, если я использую Spark для их извлечения? Или если я использую webhdfs / v1 /? Или ява?

Говоря о хранении группы небольших файлов, я обнаружил три основных решения , все из которых довольно неудобны в производственной среде:

  • HAR : выглядит фантастически с извлечением индексированных файлов , но тот факт, что я не могу добавлять или добавлять новые файлы , довольно проблематичен. Весит ли открытие и восстановление HAR в системе?
  • Файлы последовательности имеют противоположные плюсы и минусы: вы можете добавлять файлы, но они не индексируются , поэтому есть время поиска O (n). Стоит ли оно того?
  • Слить их: невозможно сделать в моем случае.

Есть ли какие-то новые технологии, которые я упускаю из-за этой общей проблемы? Что-то на линиях Avro или Parquet для файлов?

Автор: Vale Источник Размещён: 18.07.2016 08:28

Ответы (1)


1 плюс

333 Репутация автора

Вот некоторые отзывы о ваших решениях:

а) HAR не может быть добавлен Вы можете разархивировать и заархивировать свой архив с новыми файлами через интерфейс командной строки HDFS. Оба метода реализованы в виде задания MapReduce, поэтому время выполнения зависит от вашего вычислительного кластера, а также от размера ваших архивных файлов. Я и мой коллега используем и разработали AHAR . Инструмент, позволяющий добавлять данные более эффективно, не переписывая весь архив.

б) Насколько я знаю, вы правы с высоким показателем времени поиска. Но учтите, что с HAR у вас также больше время поиска благодаря двухступенчатой ​​стратегии индексации.

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

Автор: jim Размещён: 07.03.2017 12:28
Вопросы из категории :
32x32