Открыть сервис
Главная → Блог → ApplicationMaster

ApplicationMaster

ApplicationMaster — это компонент архитектуры Apache Hadoop YARN (Yet Another Resource Negotiator), отвечающий за управление жизненным циклом одного конкретного приложения, выполняющегося в кластере. Он является ключевым элементом модели YARN, которая отделяет функции управления ресурсами и планирования заданий от функций мониторинга и координации выполнения приложения. ApplicationMaster представляет собой фреймворк или процесс, который запускается на одном из узлов кластера и координирует выполнение задач приложения, запрашивая необходимые ресурсы (контейнеры) у ResourceManager и отслеживая их состояние.

История и контекст появления

До появления Hadoop YARN (версия 2.0, выпущенная в 2012 году) в экосистеме Hadoop использовалась архитектура Hadoop 1.x, где центральным компонентом был JobTracker. JobTracker выполнял одновременно две функции: управление ресурсами кластера и управление выполнением заданий MapReduce. Это создавало узкое место по масштабируемости (ограничение до 4000 узлов) и не позволяло эффективно запускать приложения, отличные от MapReduce (например, Spark, Flink, Giraph). Для решения этих проблем была разработана архитектура YARN, которая разделила функции JobTracker на два компонента: глобальный ResourceManager (управление ресурсами) и периферийный, создаваемый для каждого приложения, — ApplicationMaster. Таким образом, ApplicationMaster стал универсальным интерфейсом для интеграции различных вычислительных фреймворков в кластер Hadoop.

Архитектура и взаимодействие компонентов

ApplicationMaster является частью трехуровневой архитектуры YARN, включающей:

  • ResourceManager (RM) — центральный планировщик и распределитель ресурсов кластера.
  • NodeManager (NM) — агент на каждом узле, отвечающий за управление контейнерами (изолированными средами выполнения с выделенными CPU, памятью, диском).
  • ApplicationMaster (AM) — процесс, создаваемый для каждого приложения.

Процесс запуска приложения

  1. Клиент (например, команда hadoop jar или Spark-приложение) отправляет запрос на запуск приложения в ResourceManager.
  2. ResourceManager назначает первый контейнер (Container 0) на одном из узлов кластера и запускает в нём ApplicationMaster. Для этого RM использует спецификацию приложения, которая включает имя класса AM, путь к JAR-файлу, необходимые переменные окружения.
  3. ApplicationMaster регистрируется в ResourceManager, сообщая о своём существовании и получая идентификатор приложения.
  4. AM анализирует требования приложения (количество задач, объём данных, необходимые ресурсы) и отправляет ResourceManager запросы на выделение дополнительных контейнеров (например, для Map- и Reduce-задач в MapReduce, или для исполнителей в Spark).
  5. ResourceManager, используя планировщик (например, Capacity Scheduler или Fair Scheduler), выделяет контейнеры на узлах, где есть свободные ресурсы. AM получает уведомления о выделении контейнеров (с указанием узла и порта).
  6. AM связывается с NodeManager на каждом узле, где выделен контейнер, и запускает в нём задачу (Task) приложения. Для этого AM передаёт NM команду на запуск процесса, спецификацию контейнера и необходимые данные.
  7. AM отслеживает выполнение задач: получает от NodeManager отчёты о прогрессе, статусе (успех/ошибка) и потреблении ресурсов. В случае сбоя задачи AM может запросить повторное выделение контейнера и перезапустить задачу.
  8. После завершения всех задач приложения AM отключается от ResourceManager, сообщая о завершении. ResourceManager освобождает все ресурсы, занятые приложением.

Классификация и реализации

ApplicationMaster может быть реализован по-разному в зависимости от вычислительного фреймворка. Существуют две основные модели:

  • Специализированные AM — разработаны для конкретного фреймворка и тесно интегрированы с его логикой. Примеры:
  • MapReduce ApplicationMaster — управляет выполнением заданий MapReduce. Он разбивает задание на Map-задачи (обработка входных данных) и Reduce-задачи (агрегация результатов), отслеживает их выполнение, обрабатывает сбои (например, перезапускает упавшие задачи на других узлах).
  • Spark ApplicationMaster — управляет Spark-приложением. Он запускает драйвер Spark (Driver) и запрашивает контейнеры для исполнителей (Executors). AM координирует выполнение этапов (Stages) и задач (Tasks) Spark, а также управляет кэшированием данных.
  • Flink ApplicationMaster — управляет Flink-кластером, запуская JobManager и TaskManagers в контейнерах YARN.
  • Tez ApplicationMaster — управляет выполнением DAG-графов (Directed Acyclic Graph) задач, оптимизируя выполнение сложных запросов (например, в Hive или Pig).
  • Универсальные AM — предоставляют общий интерфейс для запуска произвольных приложений. Пример: YARN Long Running Service (LRS) ApplicationMaster — позволяет запускать долгоживущие сервисы (например, веб-серверы, базы данных) в кластере YARN.

Характеристики и особенности

  • Изоляция и отказоустойчивость: ApplicationMaster работает в собственном контейнере, изолированном от других приложений. В случае сбоя AM (например, из-за ошибки в коде или аппаратного отказа узла) ResourceManager может перезапустить AM на другом узле. При этом задачи, которые выполнялись в контейнерах, могут быть потеряны, но AM может восстановить состояние из внешнего хранилища (например, из HDFS) или перезапустить их с нуля.
  • Масштабируемость: Поскольку AM создаётся для каждого приложения, ResourceManager не управляет напрямую тысячами задач. Это позволяет кластеру YARN масштабироваться до десятков тысяч узлов.
  • Гибкость: ApplicationMaster может запрашивать контейнеры с различными ресурсами (CPU, память, GPU, диски) в зависимости от требований приложения. AM также может динамически изменять количество запрашиваемых контейнеров во время выполнения (например, добавлять исполнителей в Spark при увеличении нагрузки).
  • Взаимодействие с ResourceManager: AM использует протокол ApplicationMasterProtocol для регистрации, запроса контейнеров, получения уведомлений о выделении и отчёта о завершении. ResourceManager, в свою очередь, может отправить AM команду на завершение (например, при превышении квоты или при остановке приложения администратором).
  • Взаимодействие с NodeManager: AM использует протокол ContainerManagementProtocol для запуска, остановки и мониторинга контейнеров на узлах.

Применение и значение

ApplicationMaster является ключевым компонентом, который позволил Hadoop YARN стать универсальной платформой для выполнения различных типов приложений. Без AM YARN был бы просто менеджером ресурсов, не способным координировать выполнение логики приложений.

Основные области применения:

Критика и ограничения

  • Сложность разработки: Создание собственного ApplicationMaster требует глубокого понимания архитектуры YARN, протоколов и управления состоянием. Это сложная задача, что ограничивает круг разработчиков, способных интегрировать новые фреймворки.
  • Накладные расходы на запуск: Запуск ApplicationMaster требует выделения первого контейнера и времени на его инициализацию. Для коротких заданий (например, небольших запросов Hive) эти накладные расходы могут быть значительными.
  • Управление состоянием: ApplicationMaster не имеет встроенного механизма сохранения состояния. В случае сбоя AM и его перезапуска состояние приложения может быть потеряно, если оно не было сохранено во внешнем хранилище (например, в HDFS). Это требует дополнительной разработки для обеспечения отказоустойчивости.
  • Конкуренция за ресурсы: Поскольку AM сам потребляет ресурсы (память, CPU), при большом количестве одновременно запущенных приложений может возникнуть конкуренция за ресурсы между AM и задачами приложений.

Источники

  • Apache Hadoop Documentation. YARN Architecture.
  • Vavilapalli, V. K., et al. "Apache Hadoop YARN: Yet Another Resource Negotiator." Proceedings of the 4th Annual Symposium on Cloud Computing (SOCC '13).
  • Murthy, A. C., et al. "Apache Hadoop YARN: Moving beyond MapReduce and Batch Processing with Apache Hadoop 2." Addison-Wesley Professional, 2014.
  • White, T. "Hadoop: The Definitive Guide." 4th Edition, O'Reilly Media, 2015.

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →

Похожие материалы