Введение
Вы проследили Map, Shuffle и Reduce и проверили настоящий локальный запуск WordCount. Теперь компания хочет применить то же правило подсчёта к файлам HDFS, используя службы управления ресурсами среды. Вопрос бизнеса остаётся прежним; меняется организация хранения и выполнения.
YARN управляет ресурсами приложений. ResourceManager координирует выделение ресурсов, а NodeManager управляет выполнением на рабочей машине. У каждого отправленного приложения есть ApplicationMaster, координирующий его работу; выполнение идёт в выделенных контейнерах — наборах ресурсов с процессами внутри. Эти контейнеры YARN не обязательно являются контейнерами Docker.
Вы отправите готовый JAR WordCount, определите его настоящее приложение YARN, изучите завершённое состояние и журналы и проверите результаты HDFS. Во втором запуске будет другой выходной путь, чтобы исходные данные и первый результат оставались доступны. Работа подготавливает собственные данные и запускает службы; файлы предыдущей работы и навыки Java не нужны. Используйте терминал.
Отправьте знакомый алгоритм в YARN
На этом шаге вы подготовите входные данные HDFS и отправите тот же алгоритм WordCount, используя настроенную среду выполнения YARN.
Начните в локальном рабочем каталоге:
cd /home/labex/project
Прочитайте подготовленные входные данные:
cat /home/labex/project/data/product-words.txt
Это те же шесть строк, которые использовались для объяснения алгоритма. Ожидаемые итоги по-прежнему folder=3, notebook=4 и pen=4. Создайте каталог исходных данных HDFS и отдельный родительский каталог результатов:
hdfs dfs -mkdir -p /user/labex/yarn-batch/raw /user/labex/yarn-batch/results
Загрузите входные данные:
hdfs dfs -put /home/labex/project/data/product-words.txt /user/labex/yarn-batch/raw/product-words.txt
Вы уже знаете, что -put сохраняет локальный оригинал. Каталог HDFS raw — входные данные задания; results должен оставаться вне него, чтобы прошлые результаты не читались как новые входные данные.
JAR примера и имя wordcount те же, что при локальном запуске. На этот раз опустите переопределения локального режима: установленная конфигурация использует mapreduce.framework.name=yarn и HDFS как файловую систему по умолчанию. Поэтому оба последних аргумента ниже — пути HDFS. Задание само создаёт выходной каталог run-1, который не должен существовать заранее:
hadoop jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.5.0.jar wordcount /user/labex/yarn-batch/raw /user/labex/yarn-batch/results/run-1
Дождитесь завершения команды. Она выводит ID отправленного приложения, затем ход задания и сообщение об успешном завершении. ID приложений и заданий, время и порядок сообщений о ходе выполнения различаются. Ловить мгновенное состояние RUNNING не нужно; завершённые приложения тоже можно изучать.
Свяжите команду с ролями:
Клиент отправляет приложение → ResourceManager выделяет ресурсы
ApplicationMaster координирует MapReduce → NodeManager запускает контейнеры
Задачи читают входные данные HDFS → Задачи записывают результаты HDFS
Это по-прежнему учебная среда на одной машине. Роли YARN настоящие, хотя их процессы находятся на одной машине. Далее вы запросите у YARN прямое подтверждение успешного завершения приложения.
Изучите завершённое приложение
На этом шаге вы сохраните настоящий ID приложения и используете его для запроса состояния и собранных журналов.
YARN назначает ID приложения (Application ID) при его приёме. Он отличается от пути HDFS и имени файла результата. Выведите приложения во всех состояниях, включая завершённые:
yarn application -list -appStates ALL
В этой новой среде есть одно отправленное приложение. Его тип должен быть MAPREDUCE, состояние — FINISHED, итоговый статус — SUCCEEDED. Одно лишь FINISHED не доказывает успех: важен и итоговый статус.
Сохраните фактический ID приложения, не копируя значение из примера. Следующий конвейер использует grep -o, чтобы вывести только совпавшую часть. В этом шаблоне [0-9]* соответствует последовательностям цифр в ID приложения:
yarn application -list -appStates ALL | grep -o 'application_[0-9]*_[0-9]*' > /home/labex/project/output/application-id.txt
Прочитайте сохранённый ID:
cat /home/labex/project/output/application-id.txt
Вы должны увидеть одну строку, начинающуюся с application_. Остальная часть назначается этой средой; не используйте ID другого учащегося.
Чтобы вставить сохранённое значение в команду, $(cat ...) запускает cat и подставляет её вывод. Двойные кавычки сохраняют подставленное значение одним аргументом. Запросите это настоящее приложение:
yarn application -status "$(cat /home/labex/project/output/application-id.txt)"
Найдите State, Final-State и Application-Type. Ожидаются FINISHED, SUCCEEDED и MAPREDUCE. Сохраните отчёт:
yarn application -status "$(cat /home/labex/project/output/application-id.txt)" > /home/labex/project/output/application-status.txt
YARN также собирает журналы контейнеров. Команда logs -applicationId читает их для выбранного приложения. Сохраните журналы локально, чтобы просмотреть удобную по размеру часть:
yarn logs -applicationId "$(cat /home/labex/project/output/application-id.txt)" > /home/labex/project/output/application.log
Локальная команда tail -n 20 показывает последние двадцать строк:
tail -n 20 /home/labex/project/output/application.log
Точные сообщения журналов различаются. Заголовки контейнеров и сообщения задач связывают приложение с реально выполненной YARN работой. Журналы помогают объяснить поведение; успешное состояние вместе с правильным результатом для бизнеса — более убедительное доказательство, чем одна обнадёживающая строка журнала. В следующей работе вы примените те же инструменты диагностики к сбоям.
Проверьте и повторите запуск без загрязнения входных данных
На этом шаге вы проверите данные результата, выгрузите их и повторите запуск во второй выходной путь.
Выведите список первого каталога результата:
hdfs dfs -ls /user/labex/yarn-batch/results/run-1
Маркер _SUCCESS указывает на завершённую запись. Файлы part-* содержат количества. Как и прежде, используйте шаблон HDFS в кавычках и отсортируйте записи для стабильного просмотра:
hdfs dfs -cat '/user/labex/yarn-batch/results/run-1/part-*' | sort
Ожидаемый результат:
folder 3
notebook 4
pen 4
Сохраните отсортированную локальную выгрузку способом чтения обратно:
hdfs dfs -cat '/user/labex/yarn-batch/results/run-1/part-*' | sort > /home/labex/project/output/run-1-counts.txt
Перед следующим запуском предположите, должны ли измениться количества при повторном выполнении на одинаковых входных данных. Не должны. Новый выходной путь сохраняет первый результат и позволяет избежать ошибки существующего выходного каталога:
hadoop jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.5.0.jar wordcount /user/labex/yarn-batch/raw /user/labex/yarn-batch/results/run-2
После успешного завершения прочитайте и сохраните отсортированные количества второго запуска:
hdfs dfs -cat '/user/labex/yarn-batch/results/run-2/part-*' | sort > /home/labex/project/output/run-2-counts.txt
Сравните две локальные выгрузки:
diff /home/labex/project/output/run-1-counts.txt /home/labex/project/output/run-2-counts.txt
Различия не должны появляться. Результаты находятся рядом друг с другом вне каталога исходных данных, поэтому повторный запуск не добавил предыдущий результат в следующий входной пакет. Теперь вы проверили настоящее приложение, его журналы, данные результата и повторяемость поведения, не меняя алгоритм.
Итоги
Вы перенесли знакомый алгоритм подсчёта с локального выполнения в HDFS и YARN. Вы определили настоящее приложение MapReduce, изучили успешное завершение и журналы контейнеров и проверили правильные результаты из двух выходных путей.
Алгоритм не изменился, а организация хранения и управления ресурсами изменилась. Далее вы научитесь отличать проблемы на стороне клиента от сбоев уже отправленного приложения и выполнять минимальное подходящее исправление.
