Я получаю:
FAILED: Execution Error, return code 2 from org.apache.hadoop.hive.ql.exec.MapRedTask
При попытке сделать копию разделенной таблицы с помощью команд в консоли улья:
CREATE TABLE copy_table_name LIKE table_name;
INSERT OVERWRITE TABLE copy_table_name PARTITION(day) SELECT * FROM table_name;
Сначала я получил некоторые ошибки семантического анализа и должен был установить:
set hive.exec.dynamic.partition=true
set hive.exec.dynamic.partition.mode=nonstrict
Хотя я не уверен, что делают эти свойства?
Полноэкранный вывод из консоли улья:
Total MapReduce jobs = 1
Launching Job 1 out of 1
Number of reduce tasks determined at compile time: 1
In order to change the average load for a reducer (in bytes):
set hive.exec.reducers.bytes.per.reducer=<number>
In order to limit the maximum number of reducers:
set hive.exec.reducers.max=<number>
In order to set a constant number of reducers:
set mapred.reduce.tasks=<number>
Starting Job = job_201206191101_4557, Tracking URL = http://jobtracker:50030/jobdetails.jsp?jobid=job_201206191101_4557
Kill Command = /usr/lib/hadoop/bin/hadoop job -Dmapred.job.tracker=master:8021 -kill job_201206191101_4557
2012-06-25 09:53:05,826 Stage-1 map = 0%, reduce = 0%
2012-06-25 09:53:53,044 Stage-1 map = 100%, reduce = 100%
Ended Job = job_201206191101_4557 with errors
FAILED: Execution Error, return code 2 from org.apache.hadoop.hive.ql.exec.MapRedTask
Это не настоящая ошибка, вот как ее найти:
Перейдите на веб-панель управления joboracker hadoop, найдите текущие задания на улей, которые не удались, и просмотрите журналы неудавшихся задач. Это покажет вам реальную ошибку.
Ошибки вывода на консоль бесполезны, в основном потому, что у него нет представления о отдельных заданиях/задачах, чтобы вытащить реальные ошибки (могут быть ошибки в нескольких задачах)
Надеюсь, что это поможет.
Я знаю, что я на 3 года опоздал на эту тему, но все же предоставляю свои 2 цента для подобных случаев в будущем.
Недавно я столкнулся с той же проблемой/ошибкой в моем кластере. Задача JOB всегда будет уменьшаться до 80% + и сбой с той же ошибкой, и в журналах выполнения ничего не будет. После нескольких итераций и исследований я обнаружил, что среди множества загружаемых файлов некоторые из них были несовместимы со структурой, предоставленной для базовой таблицы (таблица используется для вставки данных в секционированную таблицу).
Точка, которую нужно отметить здесь, всякий раз, когда я выполнял запрос выбора для определенного значения в столбце разбиения или создавал статический раздел, он работал нормально, поскольку в этом случае пропущены записи ошибок.
TL; DR: проверьте входящие данные/файлы на предмет несогласованности в структурировании, поскольку HIVE следует философии схемы на чтение.
Добавив здесь некоторую информацию, так как мне потребовалось некоторое время, чтобы найти веб-панель управления сайтом joboracker в HDInsight (Azure Hadoop), и коллега наконец показал мне, где это было. На головке node есть ярлык под названием "Hadoop Yarn Status", который является лишь ссылкой на локальную страницу http (http://headnodehost:9014/cluster в моем случае). При открытии приборной панели выглядел так:
В этой информационной панели вы можете найти неудавшееся приложение, а затем после нажатия на него вы можете посмотреть журналы отдельной карты и сократить задания.
В моем случае в редукторах все еще не хватало памяти, хотя я уже запустил память в конфигурации. По какой-то причине это не отражало ошибки "java outofmemory", которые я получил раньше.
Я удалил файл _SUCCESS из пути вывода EMR в S3, и он работал нормально.
Даже я столкнулся с той же проблемой - при проверке на приборной панели я обнаружил следующую ошибку. Поскольку данные поступали через Flume и прерывались между ними, из-за чего может быть несогласованность в нескольких файлах.
Caused by: org.apache.hadoop.hive.serde2.SerDeException: org.codehaus.jackson.JsonParseException: Unexpected end-of-input within/between OBJECT entries
Запуск на меньшее количество файлов, с которыми он работал. В моем случае причиной была согласованность формата.
Главный ответ правильный, что код ошибки не дает вам много информации. Одной из распространенных причин, которые мы видели в нашей команде для этого кода ошибки, было то, что запрос не был оптимизирован хорошо. Известная причина заключалась в том, что мы выполняем внутреннее соединение с величинами в левой стороне стола, большими, чем таблица справа. В таких случаях замена этих таблиц обычно делает трюк.
Я также столкнулся с такой же ошибкой, когда я вставлял данные в внешнюю таблицу HIVE, которая указывала на кластер Elastic search.
Я заменил старый JAR elasticsearch-hadoop-2.0.0.RC1.jar на elasticsearch-hadoop-5.6.0.jar, и все сработало нормально.
Мое предложение - пожалуйста, используйте конкретную JAR в соответствии с эластичной поисковой версией. Не используйте старшие JAR, если вы используете более новую версию поиска эластичности.
Благодаря этому сообщению Hive-Elasticsearch Запись операции № 409