Производительность HDFS для небольших файлов
Я новичок в Haddoop. Недавно я пытаюсь обработать (только прочитать) много маленький файлы на hdfs / hadoop. Средний размер файла составляет около 1 Кб и количество файлов больше чем 10M. Программа должна быть написана на C++ из-за некоторых ограничений.
Это просто оценка производительности, поэтому я использую только 5 машин для узлов данных. Каждый из узлов данных имеет 5 дисков данных.
Я написал небольшую проект C++ для чтения файлов напрямую с жесткого диска(не из HDFS) для построения базовой линии производительности. Программа создаст 4 потока чтения для каждого диска. Результат производительности должен иметь около 14 мб/с на диск. Общая пропускная способность составляет около 14 мб/с * 5 * 5 = 350MB/s (14MB / S * 5 дисков * 5 машин).
однако, когда эта программа (все еще используя C++, динамически связана с libhdfs.Итак, создание 4*5*5=100 потоков) считывает файлы из hdfs кластер, пропускная способность около только 55MB/с.
Если это программирование запускается в mapreduce (Hadoop streamming, 5 заданий, каждое из которых имеет 20 потоков, общее количество потоков по-прежнему 100), пропускная способность снижается до 45 МБ/с. (Я думаю, это замедляется каким-то бухгалтерским процессом).
Мне интересно, какова разумная производительность HDFS может prvoide. Как вы можете видеть, по сравнению с собственным кодом, пропускная способность данных только о 1/7. Это проблема моей конфигурации? Или HDFS ограничение? Или ограничение на Java? Каков наилучший вариант для моего сценария? Поможет ли файл последовательности (много)? Какова разумная пропускная способность по сравнению с родной IO чтения мы можем ожидать?
вот мой конфиг:
NameNode размер кучи 32G.
размер кучи узла задания/задачи 8G.
Количество Обработчиков NameNode: 128
Количество Обработчиков DataNode: 8
DataNode максимальное количество потоков передачи: 4096
1Гбит / с локальная сеть.
спасибо.
3 ответов
давайте попробуем понять наши пределы и посмотреть, когда мы попали в них
a) нам нужно namenode, чтобы дать нам информацию, где файлы сидят. Я могу предположить, что это число составляет около тысячи в секунду. Более подробная информация здесь https://issues.apache.org/jira/browse/HADOOP-2149
Предполагая, что это число равно 10000K, мы сможем получить информацию о файлах 10 MB second for 1K. (каким-то образом вы получаете более...). Мэй!--1-->
B) накладные расходы HDFS. Эта нагрузка в основном на задержка не в пропускной способности. HDFS можно настроить для обслуживания большого количества файлов в parralel. HBase делает это, и мы можем взять настройки из руководства по настройке HBase. Вопрос здесь заключается в том, сколько Datanodes вам нужно
c) ваша ЛВС. Вы перемещаете данные из сети, так что вы можете нажать ограничение пропускной способности 1Gb ethernet. (я думаю, это то, что у тебя есть.
Я также должен согласиться с Джо - что HDFS не построен для сценария, и вы должны использовать другие технологии (например, HBase, если хотите Hadoop stack) или сжимать файлы вместе - например, в файлы последовательности.
Что касается чтения больших файлов из HDFS-запустите dfsio benchmark, и это будет ваш номер.
В то же время-SSD на одном хосте отлично может быть и решением.
HDFS действительно не предназначен для многих небольших файлов.
для каждого нового файла, который Вы читаете, клиент должен поговорить с namenode, который дает ему местоположение блока(блоков) файла, а затем клиент передает данные из datanode.
теперь, в лучшем случае, клиент делает это один раз, а затем обнаруживает, что это is машина с Данные, и можно считать ее непосредственно с диска. Это будет быстро: сопоставимо с direct disk читает.
Если это не машина, на которой есть данные, то она должна передавать данные по сети. Тогда вы связаны скоростями сетевого ввода-вывода, которые не должны быть ужасными, но все же немного медленнее, чем прямое чтение диска.
однако вы получаете еще худший случай - когда накладные расходы на разговор с namenode становятся значительными. Только с файлами 1KB вы добираетесь до точки, где вы обмениваетесь столько же метаданных, сколько фактических данных. Клиент должен сделайте два отдельных сетевых обмена, чтобы получить данные из каждого файла. Добавьте к этому, что namenode, вероятно, забивается всеми этими различными потоками, и поэтому он может стать узким местом.
Итак, чтобы ответить на ваш вопрос, да, если вы используете HDFS для чего-то, для чего он не предназначен, он будет медленным. Объедините свои небольшие файлы и используйте MapReduce для получения местоположения данных, и у вас будет гораздо лучшая производительность. На самом деле, потому что вы сможете лучше воспользоваться из последовательных чтения диска я не удивлюсь, если чтение из одного большого файла HDFS было даже быстрее чем чтение многих небольших локальных файлов.
чтобы добавить к тому, что сказал Джо, еще одно различие между HDFS и другими файловыми системами заключается в том, что он сохраняет дисковый ввод-вывод как можно меньше, сохраняя данные в больших блоках (обычно 64M или 128M) по сравнению с традиционными FS, где размер блока FS находится в порядке KBs. по этой причине они всегда говорят, что HDFS хорош в обработке нескольких больших файлов, а не больших нет маленьких файлов. причиной этого является тот факт, что, хотя были достигнуты значительные успехи в компоненты, такие как cpu, ram и т. д. В последнее время дисковый ввод-вывод-это область, в которой мы все еще не настолько продвинулись. это было намерение иметь такие огромные блоки (в отличие от традиционных FS) и сохранить использование диска как можно меньше.
кроме того, если размер блока слишком мал, у нас будет больше никаких блоков. что означает больше метаданных. это может снова ухудшить производительность, так как больше информации необходимо загрузить в память. для каждого блока, который считается объект в HDFS имеет около 200B метаданных, связанных с ним. если у вас много небольших блоков, это просто увеличит метаданные, и у вас могут возникнуть проблемы с ОЗУ.
В разделе блога Cloudera есть очень хороший пост, в котором говорится об одной и той же проблеме. Вы можете посетить это здесь.