Подавать статические файлы от Hadoop

Question

Моя задача - создать распределенную систему для статических изображений/видеофайлов. Размер данных - около десятков терабайт. Это в основном для доступа к HTTP (таким образом, обработка данных отсутствует или просто простая обработка, например изменение размера, однако это не важно, поскольку это можно сделать непосредственно в приложении).

Чтобы быть немного более ясно, что это система, которая:

1. должны быть распределены (горизонтальная шкала), так как общий размер данных очень велик.
2. В первую очередь обслуживает небольшие статические файлы (например, изображения, миниатюры, короткие видеоролики) через HTTP.
3. Как правило, нет необходимости в обработке данных (при этом MapReduce не требуется)
4. Настройка HTTP-доступа к данным может быть легко выполнена.
5. (Должно иметь) хорошая пропускная способность.

Я рассматриваю:

1. Native сетевая файловая система: Но это, кажется, не представляется возможным, поскольку данные не могут поместиться в одну машину.

2. Hadoop файловая система. Ранее я работал с Hadoop mapreduce, но у меня нет опыта использования Hadoop в качестве статического репозитория файлов для HTTP-запросов. Поэтому я не знаю, возможно ли это, или если это рекомендуемый способ.

3. MogileFS. Это кажется многообещающим, но я считаю, что использование MySQL для управления локальными файлами (на одной машине) создаст слишком много накладных расходов.

Любое предложение пожалуйста?

Answer 1

Я являюсь автором Weed-FS. Для вашего требования WeedFS идеален. Hadoop не может обрабатывать множество небольших файлов, в дополнение к вашим причинам каждый файл должен иметь запись в главном. Если количество файлов велико, главный узел hdfs не может масштабироваться.

Weed-FS ускоряется при составлении последних выпусков Golang.

В последнее время на Weed-FS было сделано много новых улучшений. Теперь вы можете легко протестировать и сравнить с встроенным инструментом загрузки. Этот файл загружает все файлы рекурсивно в каталог.

weed upload -dir=/some/directory 

Теперь вы можете сравнить по «ей -k/какой/каталогу», чтобы увидеть использование дискового пространства, и «Ls -l/ваш/сорняки/объем/каталог», чтобы увидеть использование дискового пространства Weed-FS.

И я полагаю, вам понадобится репликация с центром обработки данных, стойкой и т. Д. Они сейчас!

Answer 2

У Hadoop есть API-интерфейс для доступа к файлам. См. this запись в документации. Я считаю, что Hadoop не предназначен для хранения большого количества небольших файлов.

• HDFS не предназначен для эффективного доступа к небольшим файлам: он в первую очередь предназначен для потокового доступа к большим файлам. Чтение небольших файлов обычно вызывает много попыток и много прыжков из datanode в datanode для извлечения каждого маленького файла, все из которых являются неэффективным шаблоном доступа к данным.
• Каждый файл, каталог и блок в HDFS представлен как объект в памяти памяти, каждый из которых занимает 150 байт. Размер блока - 64 МБ. Таким образом, даже если файл имеет размер 10 КБ, ему будет выделен весь блок размером 64 МБ. Это пустое место на диске.
• Если файл очень мал и их много, то каждая задача карты обрабатывает очень мало ввода, и есть намного больше задач карты, каждая из которых налагает дополнительные накладные расходы. Сравните 1 ГБ файл, разбитый на 16 файлов из 64 МБ блоков и 10 000 или около 100 КБ файлов. 10 000 файлов используют по одной карте каждый, а время работы может быть в десятки или сотни раз медленнее, чем эквивалентное, с одним входным файлом.

В «Hadoop Summit 2011», был this talk по Karthik Ranganathan о Facebook сообщений, в которых он отдал этот бит: Facebook хранит данные (профили, сообщения и т.д.) над HDFS, но они не используют один и тот же инфра для изображений и видео. У них есть собственная система под названием Haystack для изображений.Его не с открытым исходным кодом, но они обменивались деталями абстрактного уровня дизайна.

Это приводит меня к weed-fs: проект с открытым исходным кодом, вдохновленный дизайном Haystacks. Его портной предназначен для хранения файлов. Я до сих пор не использовал его, но, похоже, стоит того.

Answer 3

Hadoop оптимизирован для больших файлов, например. Размер блока по умолчанию - 64M. На Hadoop очень много мелких файлов, и они неэффективны.

Вы можете посмотреть другие распределенные файловые системы, например. GlusterFS

Answer 4

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

Это подход, который я предпринял при использовании Hadoop для обработки изображений CT (подробности на Image Processing in Hadoop). Здесь 225 фрагментов КТ-сканирования (каждое отдельное изображение) были скомпилированы в один, намного больший двоичный файл последовательности для длительной потоковой передачи в Hadoop для обработки.

Надеюсь, это поможет!

G