Как сделать попытку задачи hadoop завершиться неудачей после слишком большого количества сбоев выборки данных?

У меня есть попытка уменьшить задачу hadoop, которая никогда не завершится и не завершится, если я не завершу ее вручную.

Проблема возникает, когда узел отслеживания задач (из-за сетевых проблем, которые я все еще исследую) теряет связь с другими узлами отслеживания задач / данных, но не с устройством отслеживания заданий.

По сути, задача уменьшения не может получить необходимые данные из других узлов данных из-за проблем с тайм-аутом и помещает их в черный список. Пока все хорошо, черный список ожидается и необходим, проблема в том, что он будет повторять попытки одних и тех же хостов из черного списка в течение нескольких часов (соблюдая то, что кажется экспоненциальным алгоритмом отката), пока я не убью его вручную. Последняя длительная задача: повторная попытка> 9 часов.

Я вижу в журнале сотни таких сообщений:

2013-09-09 22:34:47,251 WARN org.apache.hadoop.mapred.ReduceTask (MapOutputCopier attempt_201309091958_0004_r_000044_0.1): attempt_201309091958_0004_r_000044_0 copy failed: attempt_201309091958_0004_m_001100_0 from X.X.X.X
2013-09-09 22:34:47,252 WARN org.apache.hadoop.mapred.ReduceTask (MapOutputCopier attempt_201309091958_0004_r_000044_0.1): java.net.SocketTimeoutException: connect timed out

Есть ли способ или параметр указать, что после n попыток или секунд задача должна завершиться сбоем и перезапуститься сама по себе на другом узле отслеживания задач?

Вот некоторые из релевантных параметров кластера Hadoop для уменьшения / тайм-аута, которые я установил в своем кластере:

<property><name>mapreduce.reduce.shuffle.connect.timeout</name><value>180000</value></property>
<property><name>mapreduce.reduce.shuffle.read.timeout</name><value>180000</value></property>
<property><name>mapreduce.reduce.shuffle.maxfetchfailures</name><value>10</value></property>

<property><name>mapred.task.timeout</name><value>600000</value></property>
<property><name>mapred.jobtracker.blacklist.fault-timeout-window</name><value>180</value></property>
<property><name>mapred.healthChecker.script.timeout</name><value>600000</value></property>

Кстати, это задание выполняется в кластере AWS EMR (версия Hadoop: 0.20.205).

Заранее спасибо.


amazon-emr hadoop mapreduce elastic-map-reduce
person scetoaux    schedule 12.09.2013    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Хотя я не уверен наверняка, то, что вам интересно понять, реализовано в классе org.apache.hadoop.mapred.ReduceTask.ReduceCopier, особенно если вы посмотрите на источник конструктора для этого класса:

this.abortFailureLimit = Math.max(30, numMaps / 10);

this.maxFetchFailuresBeforeReporting = conf.getInt(
      "mapreduce.reduce.shuffle.maxfetchfailures", REPORT_FAILURE_LIMIT);

this.maxFailedUniqueFetches = Math.min(numMaps, 
                                       this.maxFailedUniqueFetches);

Вы заметите, что это один из значений конфигурации, которые вы уже указали - mapreduce.reduce.shuffle.maxfetchfailures. Вы пробовали установить меньшее значение (1 или 0), обеспечивает ли это желаемую функциональность?

Вы также можете уменьшить тайм-аут соединения с помощью mapreduce.reduce.shuffle.connect.timeout (опять же, это у вас тоже есть в вашем вопросе). Попробуйте уменьшить значение, чтобы тайм-аут соединения срабатывал раньше (180000 - это 3 минуты, попробуйте вместо этого 30000).

Извините, это не окончательно, но, по крайней мере, с чего начать.

person Chris White    schedule 19.09.2013

arrow_upward
1
arrow_downward

«Слишком много сбоев выборки» на самом деле довольно распространено, если вы перешли на Hadoop 0.20 (что вы и сделали). Проблема, по-видимому, связана с проблемой в версии Jetty 6, которая входит в состав более поздних дистрибутивов Hadoop. См. MAPREDUCE-2386, MAPREDUCE-2529, MAPREDUCE-3851, MARREDUCE-3184.

Две вещи, которые, кажется, помогли мне перестать видеть этот режим отказа:

  1. найдите исправленную версию Jetty 6 от Тодда Липкона от Cloudera и используйте действие начальной загрузки, чтобы замените стандартный из AWS на исправленные двоичные файлы
  2. Увеличьте somaxconns со значения по умолчанию 128 до примерно 16384 с помощью действия начальной загрузки, а также установите для ipc.server.listen.queue.size то же значение с помощью действия начальной загрузки Hadoop configure.

Я считаю, что AMI в диапазоне 2.3.x используют Jetty 7, поэтому, если вы склонны перейти на более позднюю версию Hadoop (1.0.3), это также должно помочь.

person Judge Mental    schedule 19.09.2013