Почему отправка задания в mapreduce занимает так много времени в целом?

поэтому обычно для 20-узлового кластера отправка задания на обработку 3GB (200 splits) данных занимает около 30 секунд, а фактическое выполнение-около 1м. Я хочу понять, что является узким местом в процессе отправки заданий и понять следующую цитату

накладные расходы на MapReduce значительны: запуск / завершение задания MapReduce стоит времени

некоторый процесс, который я знаю: 1. разделение данных 2. jar файла обмена

7
hadoop mapreduce

3 ответов

несколько вещей, чтобы понять о HDFS и M / R, который помогает понять эту задержку:

  1. HDFS хранит ваши файлы в виде фрагмента данных, распределенного на нескольких машинах под названием datanodes
  2. M / R запускает несколько программ под названием mapper на каждом из блоков данных или блоков. Выходные данные (ключ,значение) этих картографов компилируются вместе в результате редукторами. (Подумайте о суммировании различных результатов от нескольких картографов)
  3. каждый картограф и редуктор полный полноценная программа, которая рождается на этих распределенных системах. Требуется время, чтобы породить полноценные программы, даже если мы скажем, что они ничего не сделали (нет-OP map reduce programs).
  4. когда размер обрабатываемых данных становится очень большим, эти времена нереста становятся незначительными, и именно тогда Hadoop сияет.

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

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

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

сколько времени требуется для выполнения программы без операции map-reduce в кластере?

Используйте MRBench для этого:

  1. MRbench петли небольшое задание несколько раз
  2. проверяет, реагируют ли небольшие задания и эффективно работают на вашем группа.
  3. его влияние на слой HDFS очень ограничено

чтобы запустить эту программу, попробуйте следующее (Проверьте правильный подход для последних версий:

hadoop jar /usr/lib/hadoop-0.20/hadoop-test.jar mrbench -numRuns 50

удивительно, что на одном из наших кластеров разработчиков это было 22 секунды.

еще одна проблема-это размер файла.

Если размер файла меньше размера блока HDFS, то программы Map / Reduce имеют значительные накладные расходы. Hadoop, который, как правило, пробуют создавать маппера за квартал. Это означает, что если у вас есть 30 файлов 5KB, то Hadoop может в конечном итоге породить 30 картографов на блок, даже если размер файла мал. Это реальная потеря, так как каждая программа накладные расходы значительны по сравнению с временем, которое она будет тратить на обработку файла небольшого размера.

13

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

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

  1. запустить клиент hadoop. Он работает на Java, и я думаю, что можно предположить о 1 секундных накладных расходах.
  2. поставить задание в очередь и давай текущего планировщика запустите работу. Я не уверен, что накладные расходы, но из-за асинхронного характера процесса должна существовать некоторая задержка.
  3. расчет шпагат.
  4. бег и syncronizing задачи. Здесь мы сталкиваемся с тем, что TaskTrackes опрашивает JobTracker, а не наоборот. Я думаю, что это делается ради масштабируемости. Это означает, что когда JobTracker хочет выполнить какую-то задачу, он не вызывает task tracker, но ждет, что соответствующий трекер будет пинговать его, чтобы получить работу. Задача-трекеров не пингуйте JobTracker часто, иначе они убьют его в больших кластерах.
  5. выполняемые задачи. Без повторного использования JVM это занимает около 3 секунд, а накладные расходы-около 1 секунды на задачу.
  6. Client poll job tracker для результатов (по крайней мере, я так думаю), а также добавить некоторую задержку для получения информации, что работа завершена.
5

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

  1. когда HDFS хранит слишком много небольших файлов с фиксированным размером куска, будут проблемы с эффективностью в HDFS, лучшим способом было бы удалить все ненужные файлы и небольшие файлы с данными. Попробовать еще раз.

  2. попробуйте с узлами данных и узлами имен:

    • остановить все службы с помощью stop-all.sh.
      • имя-узел
  3. перезагрузка машины
  4. запустить все службы с помощью start-all.sh
  5. Проверьте узлы данных и имен.

  6. попробуйте установить более низкую версию hadoop (hadoop 2.5.2), которая работала в двух случаях, и она работала в hit и trial.

0