Введение
Вчера пакет компании выполнился успешно, а сегодня команда сообщает об ошибке. Повторение без чтения сообщения может скрыть настоящую причину или подтолкнуть к разрушительному обходному решению. Отсутствующий входной файл, неверный адрес службы и сбой задачи обработки требуют разных действий.
Вы пройдёте небольшую последовательность диагностики: определите файловую систему и подключение, проверьте наличие и доступность входных данных, проверьте выходной путь, затем изучите состояние и журналы принятого приложения. Ошибка клиента может возникнуть до отправки приложения. У отправленного приложения есть идентификатор YARN, а его диагностика даёт дополнительные свидетельства.
В этой работе намеренно предусмотрено несколько сбоев, включая заранее скомпилированное учебное приложение, отклоняющее помеченную входную запись. Это контролируемые учебные примеры, а не случайные сбои инфраструктуры. Вы сохраните их как доказательства и завершите чистый запуск WordCount с другими входным и выходным путями. Написание Java-кода, переустановка служб, форматирование и массовое удаление не требуются. Все учебные данные независимы; используйте терминал.
Найдите ошибки подключения и входных данных
На этом шаге вы отличите неверный адрес службы от отсутствующего файла, читая настоящие ошибки клиента.
Начните в локальном рабочем каталоге:
cd /home/labex/project
Сначала вспомните настроенную файловую систему:
hdfs getconf -confKey fs.defaultFS
Должно появиться hdfs://localhost:9000. Теперь намеренно попросите клиент подключиться к порту 1, на котором NameNode не слушает. Свойства -D ниже ограничивают повторные подключения и задают тайм-аут подключения 2000 миллисекунд для этого вызова, ограничивая длительность намеренной ошибки. Они не меняют общую конфигурацию.
Перенаправление > file 2>&1 сохраняет обычный вывод в локальном файле и отправляет туда же поток ошибок. Следующая команда должна завершиться ошибкой.
hdfs dfs -Dipc.client.connect.max.retries=0 -Dipc.client.connect.timeout=2000 -ls hdfs://localhost:1/user/labex > /home/labex/project/output/connection-error.log 2>&1
Прочитайте сохранённую ошибку:
cat /home/labex/project/output/connection-error.log
Найдите сообщение о сбое или отказе подключения и неверный адрес. Это происходит до успешного получения списка файловой системы. Не форматируйте HDFS и не переустанавливайте службы; команда использовала неверную конечную точку. Вернитесь к настроенному адресу, используя путь по умолчанию:
hdfs dfs -ls /user/labex/job-diagnostics/data
Вы должны увидеть clean.txt и rejected.txt. Подключение работает. Другая проблема — запрос несуществующего файла в исправной файловой системе. Следующая команда должна завершиться ошибкой.
hdfs dfs -ls /user/labex/job-diagnostics/data/missing.txt > /home/labex/project/output/missing-input.log 2>&1
Изучите сообщение:
cat /home/labex/project/output/missing-input.log
Оно должно сообщить, что указанный путь не существует. Проверьте нужные входные данные знакомой операцией чтения:
hdfs dfs -cat /user/labex/job-diagnostics/data/clean.txt
Две строки — notebook pen и notebook folder. Исправленный входной путь решает проблему отсутствующего файла; изменение конфигурации сервера не помогло бы. Сохраните журналы ошибок как доказательства.
Распознайте существующий выходной путь
На этом шаге вы увидите, почему задание отклоняет уже существующий выходной каталог, и выберете сохранение вместо массового удаления.
При подготовке создан пустой каталог результатов existing, представляющий уже занятое место назначения. Изучите запись этого каталога:
hdfs dfs -ls -d /user/labex/job-diagnostics/results/existing
Формат вывода примера MapReduce ожидает создание нового выходного каталога. Существующий каталог может вызвать отказ клиента до приёма приложения обработки. Следующая команда должна завершиться ошибкой.
hadoop jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.5.0.jar wordcount /user/labex/job-diagnostics/data/clean.txt /user/labex/job-diagnostics/results/existing > /home/labex/project/output/existing-output.log 2>&1
Прочитайте сохранённое сообщение:
cat /home/labex/project/output/existing-output.log
Найдите сообщение о существующем выходном каталоге или FileAlreadyExistsException. Это конфликт путей, а не свидетельство ошибки алгоритма подсчёта товаров.
Выведите принятые YARN приложения:
yarn application -list -appStates ALL
Эти ошибки клиента не должны создавать завершённое приложение обработки. Клиент может обращаться к службам кластера или получать идентификатор при подготовке отправки; принятое приложение и его состояние — отдельные свидетельства.
Вы сохраните занятый каталог и используете новый выходной путь для успешного запуска. Удаление всего results или исходных данных было бы гораздо более широким изменением, чем требует проблема.
Изучите настоящее приложение со сбоем
На этом шаге вы отправите контролируемое учебное приложение и объясните сбой по его настоящему идентификатору YARN и журналам.
Подготовленный controlled-failure.jar принимает входной путь и новый выходной путь. Его обработчик Map намеренно отклоняет маркер BAD_RECORD. Изучать и редактировать Java-код не нужно; цель — отличить сбой задачи принятого приложения от предыдущих ошибок клиента.
Сначала прочитайте помеченные входные данные:
hdfs dfs -cat /user/labex/job-diagnostics/data/rejected.txt
Они содержат обычную строку товаров, за которой идёт BAD_RECORD. Учебное задание использует одну попытку Map, чтобы один и тот же намеренный сбой не повторялся многократно. Следующая команда должна завершиться ошибкой.
hadoop jar /home/labex/project/tools/controlled-failure.jar /user/labex/job-diagnostics/data/rejected.txt /user/labex/job-diagnostics/results/failed-example > /home/labex/project/output/failed-job.log 2>&1
Дождитесь приглашения, затем прочитайте конец журнала:
tail -n 25 /home/labex/project/output/failed-job.log
В отличие от предыдущих случаев, у этого запуска должно быть отправленное приложение YARN и свидетельство сбоя задачи. Сохраните его фактический ID с помощью того же шаблона списка приложений, что и в предыдущей работе:
yarn application -list -appStates ALL | grep -o 'application_[0-9]*_[0-9]*' > /home/labex/project/output/failed-application-id.txt
Запросите и сохраните его отчёт:
yarn application -status "$(cat /home/labex/project/output/failed-application-id.txt)" > /home/labex/project/output/failed-application-status.txt
Прочитайте отчёт:
cat /home/labex/project/output/failed-application-status.txt
Найдите идентификатор приложения, итоговый статус и диагностику. Итоговый статус должен быть FAILED; отчёт — свидетельство от YARN, а не вручную написанная отметка о сбое. Прочитайте и настоящие собранные журналы:
yarn logs -applicationId "$(cat /home/labex/project/output/failed-application-id.txt)" > /home/labex/project/output/failed-application.log
Используйте grep, чтобы найти в них известное учебное диагностическое сообщение:
grep 'Training input rejected' /home/labex/project/output/failed-application.log
Сообщение указывает на помеченную запись. Вы перешли от общего ненулевого результата команды к конкретному объяснению, подкреплённому журналами приложения и задач. Сохраните это доказательство вместо того, чтобы считать любой сбой поводом перезапустить кластер.
Исправьте выбор пакета и завершите запуск
На этом шаге вы используете чистые входные данные и новый выходной каталог, затем сохраните краткую диагностику на основе доказательств.
Нужный входной файл отчётности — clean.txt; отклонённый файл был учебным примером. Сохраните оба оригинала. Отправьте знакомый пример WordCount только для чистого файла, используя новый каталог результата:
hadoop jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.5.0.jar wordcount /user/labex/job-diagnostics/data/clean.txt /user/labex/job-diagnostics/results/successful-run > /home/labex/project/output/successful-job.log 2>&1
Эта команда должна завершиться успешно. Входные данные содержат два появления notebook, одно pen и одно folder. Прочитайте результат:
hdfs dfs -cat '/user/labex/job-diagnostics/results/successful-run/part-*' | sort
Ожидаемые количества:
folder 1
notebook 2
pen 1
Журнал драйвера успешного запуска содержит ID приложения. sort -u сортирует и удаляет повторяющиеся одинаковые строки ID, оставляя один ID этого вызова:
grep -o 'application_[0-9]*_[0-9]*' /home/labex/project/output/successful-job.log | sort -u > /home/labex/project/output/successful-application-id.txt
Подтвердите фактическое состояние успешного приложения:
yarn application -status "$(cat /home/labex/project/output/successful-application-id.txt)"
Итоговый статус должен быть SUCCEEDED. Объедините предыдущие доказательства в одну локальную запись диагностики:
cat /home/labex/project/output/connection-error.log /home/labex/project/output/missing-input.log /home/labex/project/output/existing-output.log /home/labex/project/output/failed-application-status.txt > /home/labex/project/output/diagnosis.md
Добавьте выбранное исправление. printf выводит текст, \n создаёт переносы строк, а >> дописывает, а не заменяет сохранённые доказательства:
printf '\nRepair: select /user/labex/job-diagnostics/data/clean.txt and use the new /user/labex/job-diagnostics/results/successful-run output. Preserve original inputs and the existing result directory.\n' >> /home/labex/project/output/diagnosis.md
Эта запись связывает ошибку, наблюдение и действие. Если служба недоступна или произошёл сбой платформы вне ваших полномочий, запишите адрес и сообщение и сообщите о проблеме вместо форматирования хранилища. Для изученных здесь проблем хватило конкретного выбора пути или входных данных.
Итоги
Вы отличили ошибки подключения, отсутствующие входные данные и существующие выходные пути от сбоя задачи принятого приложения YARN. Вы использовали фактическое состояние приложения и журналы задач для объяснения контролируемого отклонения, затем завершили правильный пакет с чистыми входными данными и новым выходным путём.
Итоговое задание курса объединяет эти привычки с организацией входных данных и правами доступа. Вам предстоит самостоятельно завершить новый пакет уже отработанными способами.
