Что такое YARN: архитектура, принцип работы, роль в Apache Hadoop

YARN – это система планирования заданий и управления кластером (Yet Another Resource Negotiator), которую также называют MapReduce 2.0 – набор системных программ (демонов), обеспечивающих совместное использование, масштабирование и надежность работы распределенных приложений. YARN является интерфейсом между аппаратными ресурсами кластера и приложениями, использующих его мощности для вычислений и аналитики больших данных.

История появления и роль YARN в экосистеме Apache Hadoop

Будучи впервые выпущен в 2013 году под лицензией Apache 2.0, YARN является одним из основных модулей ядра экосистемы Hadoop, отвечая за планирование заданий и управление распределенными приложениями. YARN решает проблемы 1-ой версии технологии распределенных вычислений – MapReduce, предоставляя компоненты и API для разработки Big Data приложений, обеспечивая распределение ресурсов в ответ на запросы и отслеживания статусы выполнения заданий.

Поэтому очень часто этот фреймворк называют Apache Hadoop YARN или MapReduce 2.0, хотя он используется не только в классическом Hadoop MapReduce. Благодаря более общей модели, чем в классическом Hadoop MapReduce, YARN позволяет запускать в кластере Apache Hadoop не только MapReduce-задания, но и любые распределенные приложения. В частности, в Apache Spark именно YARN обеспечивает распределённому приложению доступ к кластеру через свой диспетчер ресурсов – один из главных модулей YARN, которые мы рассмотрим далее.

Архитектура и принципы работы

YARN состоит из следующих компонентов:

ResourceManager (RM) — менеджер ресурсов, которых отвечает за распределение ресурсов, необходимых для работы распределенных приложений, и наблюдение за узлами кластера, где эти приложения выполняются. ResourceManager включает планировщик ресурсов (Scheduler) и диспетчер приложений (ApplicationsManager, AsM).
ApplicationMaster (AM) – мастер приложения, ответственный за планирование его жизненного цикла, координацию и отслеживание статуса выполнения, включая динамическое масштабирование потребления ресурсов, управление потоком выполнения, обработку ошибок и искажений вычислений, выполнение локальных оптимизаций. Каждое приложение имеет свой экземпляр ApplicationMaster. ApplicationMaster выполняет произвольный пользовательский код и может быть написан на любом языке программирования благодаря расширяемым протоколам связи с менеджером ресурсов и менеджером узлов.
NodeManager (NM) – менеджер узла – агент, запущенный на узле кластера, который отвечает за отслеживание используемых вычислительных ресурсов (CPU, RAM и пр.), управление логами и отправку отчетов об использовании ресурсов планировщику. NodeManager управляет абстрактными контейнерами – ресурсами узла, доступными для конкретного приложения.
Контейнер (Container) — набор физических ресурсов (ЦП, память, диск, сеть) в одном вычислительном узле кластера.

ApplicationsManager отвечает за прием задач и запуск экземпляров мастера приложений (ApplicationMaster), мониторингов узлов (контейнеров), на которых происходит выполнение распределенных заданий, и предоставляет сервис для перезапуска контейнера ApplicationMaster в случае сбоя. Планировщик менеджера ресурсов (Scheduler) является не ведет мониторинг и не отслеживает статус выполнения распределенного приложений, а также не дает гарантий перезапуска неудачных задач при аппаратных или программных отказах.

Таким образом, YARN разделяет функции управления ресурсами и планирования/мониторинга заданий на отдельные демоны, имея глобальный диспетчер ресурсов и мастер приложения для каждого отдельного задания или их конвейера в виде направленного ациклического графа (DAG, Directed Acyclic Graph).

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

Компоненты YARN взаимодействуют друг с другом через следующие протоколы:

ClientRMProtocol – протокол взаимодействия клиента с ResourceManager для запуска, завершения и проверки статуса приложений;
AMRMProtocol– протокол, который использует мастер приложения для регистрации или ее регистрации в менеджере ресурсов, а также для запроса ресурсов у планировщика;
ContainerManager— протокол взаимодействия мастера приложения с диспетчером узлов для запуска или остановки и получения данных о необходимости обновления контейнеров под управлением NodeManager.

Принцип работы Hadoop YARN можно описать следующим образом:

клиентское приложение отправляет запрос в кластер;
менеджер ресурсов выделяет необходимые ресурсы для контейнера и запускает ApplicationMaster для обслуживания этого приложения;
ApplicationMaster отправляет запрос менеджеру узла NodeManager, включая контекст запуска контейнера Container Launch Context (CLC);
ApplicationMaster выделяет контейнеры для приложения в каждом узле и контролирует их работу до завершения работы приложения;
Для запуска контейнера менеджер узла копирует в локальное хранилище все необходимые зависимости (данные, исполняемые файлы, архивы);
по завершении задачи мастер приложения отменяет выделенный контейнер в диспетчере ресурсов, завершая жизненный цикл распределенного задания.
клиент может отслеживать состояние распределенного приложения, обращаясь к менеджеру ресурсов или сразу к мастеру приложения.

что такое YARN и как он работает, архитектура и принципы работы YARN, основы Big Data для начинающих, обучение Hadoop, курсы администраторов и разработчиков Apache Hadoop, администратор кластера Apache Hadoop курсы обучение, администрирование кластера Apache Hadoop YARN — Архитектура и принципы работы Apache Hadoop YARN

При необходимости клиент может самостоятельно завершить работу приложения. Являясь контейнером, работающим в кластере, мастер приложения должен быть отказоустойчивым. Хотя YARN и поддерживает восстановление при сбоях, но большая часть нагрузки по обеспечению отказоустойчивости все равно лежит на мастере приложения.

Более подробно про некоторые аспекты работы YARN читайте в наших отдельных статьях:

Источники