Запрос Hive показывает несколько убитых редукторов, но запрос все еще выполняется. Будет ли вывод правильным? - PullRequest
0 голосов
/ 22 октября 2019

У меня сложный запрос с несколькими левыми внешними объединениями, запущенными в течение последнего часа в Amazon AWS EMR. Но немногие редукторы показаны как неудачные и убитые.

Мой вопрос: почему убивают некоторые редукторы? Будет ли конечный результат правильным?

Hive query running with few reducers killed

Ответы [ 3 ]

3 голосов
/ 22 октября 2019

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

Редких сбоев некоторых попыток выполнения задачи нет. такая критическая проблема, особенно при работе в кластере EMR с точечными узлами, которые могут быть удалены во время выполнения, что приводит к сбоям и частичному перезапуску некоторых вершин.

В большинстве случаев причину сбоев вы можете найти в логах трекера.

И, конечно, это не причина для перехода на устаревший MR. Попробуйте найти причину и устранить ее.

В некоторых крайних случаях, даже если задание с некоторыми неудачными попытками выполнено успешно, полученные данные могут быть частично повреждены. Например, при использовании некоторой недетерминированной функции в предложении «распределить по». Как и rand (). В этом случае перезапущенный контейнер может попытаться скопировать данные, полученные на предыдущем шаге (преобразователь), и точечный узел с результатами преобразователя уже удален. В таком случае некоторые контейнеры предыдущего шага перезапускаются, но полученные данные могут отличаться из-за недетерминированной природы функции rand.

Об убитых заданиях.

Мапперы или редукторы могут быть убиты по многим причинам. Прежде всего, когда один из контейнеров полностью вышел из строя, все остальные выполняющиеся задачи уничтожаются. Если спекулятивное выполнение включено, дублированные задачи уничтожаются, если задача не отвечает в течение длительного времени и т. Д. Это вполне нормально и обычно не является показателем того, что что-то не так. Если вся работа завершилась неудачно или у вас много попыток неудачных попыток, вам нужно проверить журналы неудачных задач, чтобы найти причину, а не убитые.

1 голос
/ 22 октября 2019

Может быть много причин, чтобы убить редукторы. Вот некоторые из них:

  • Недостаточно памяти для промежуточной области.
  • Недоступность или тупик ресурса.
  • Ограничение на число редукторов, которые будут созданы задачей. и т. д.

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

Кроме того, похоже, чтоу вас работает куст в режиме TEZ попробуйте запустить в режиме MR , может помочь.

0 голосов
/ 22 октября 2019

Краткий ответ: Да, если ваше задание завершено успешно, вы увидите правильный результат.

Может быть много причин сбоя задачи во время выполнения. В основном за счет ресурсов. Это может быть процессор / диск / память.

Tez AppMaster отвечает за обработку временных сбоев выполнения контейнера и должен отвечать на запросы RM относительно выделенных и, возможно, освобожденных контейнеров.

Tez AppMaster пытается переназначить задачу для некоторых других контейнеров с ограничениями

  • tez.maxtaskfailures.per.node default=3 Чтобы убедиться, что этот узел не будет использоваться для переназначения.

  • tez.am.task.max.failed.attempts default=4 Максимальное количество попыток, которые могут потерпеть неудачу для конкретной задачи до ее сбоя. Это не считается убитых попыток. 4 Сбой задачи приводит к сбою DAG

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...