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

Application Master

Application Master — это компонент в распределённых вычислительных системах, в частности в среде выполнения Apache Hadoop YARN (Yet Another Resource Negotiator), который отвечает за управление жизненным циклом одного приложения в кластере. Application Master (AM) является посредником между диспетчером ресурсов (ResourceManager) и узлами кластера (NodeManager), координируя выполнение задач, запрашивая ресурсы (память, процессорное время) и отслеживая состояние приложения. В экосистеме Hadoop Application Master представляет собой первый процесс, запускаемый для каждого приложения, и служит его «мозгом», обеспечивая отказоустойчивость и масштабируемость.

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

До появления YARN в Hadoop версии 1.x (Hadoop MapReduce) архитектура была монолитной: JobTracker выполнял функции как управления ресурсами, так и мониторинга задач. Это приводило к узким местам — при большом количестве задач JobTracker становился точкой отказа и не мог масштабироваться для поддержки различных моделей вычислений (не только MapReduce). С выпуском Hadoop 2.x в 2012 году была внедрена архитектура YARN, которая разделила эти функции: ResourceManager стал отвечать за распределение ресурсов между приложениями, а Application Master — за управление каждым отдельным приложением. Это позволило запускать в кластере не только MapReduce, но и другие фреймворки, такие как Apache Spark, Apache Flink, Apache Tez, а также интерактивные запросы и потоковую обработку.

Архитектура и роль в YARN

Основные компоненты YARN

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

Жизненный цикл Application Master

  1. Запуск: Когда пользователь отправляет приложение (например, задачу MapReduce или Spark-джоб), ResourceManager создаёт первый контейнер для запуска Application Master. Обычно AM запускается на одном из узлов кластера.
  2. Регистрация: После запуска AM регистрируется в ResourceManager, сообщая о своём существовании и получая идентификатор приложения.
  3. Запрос ресурсов: AM анализирует требования приложения (количество задач, объём данных, необходимые ресурсы) и отправляет запросы в ResourceManager на выделение контейнеров. Запросы могут быть динамическими — AM может увеличивать или уменьшать количество контейнеров в зависимости от прогресса.
  4. Выполнение задач: Получив контейнеры, AM запускает в них задачи (например, map или reduce для MapReduce, executor’ы для Spark). Он контролирует их выполнение через NodeManager, получая уведомления о завершении или сбоях.
  5. Мониторинг и отказоустойчивость: AM отслеживает состояние каждой задачи. При сбое контейнера или задачи AM может запросить новый контейнер и перезапустить задачу. Если сам AM выходит из строя, ResourceManager может перезапустить его (если приложение поддерживает такую возможность), используя сохранённое состояние.
  6. Завершение: После выполнения всех задач AM отправляет ResourceManager отчёт о завершении и освобождает все ресурсы. Затем AM завершает свою работу.

Типы Application Master

В экосистеме Hadoop каждый фреймворк имеет свою реализацию Application Master, адаптированную под его модель вычислений:

  • MapReduce Application Master — классическая реализация для пакетной обработки данных по модели MapReduce. Управляет задачами map и reduce, поддерживает спекулятивное выполнение (запуск дублирующих задач при медленной работе).
  • Spark Application Master — для Apache Spark. Управляет драйвером и исполнителями (executor’ами). В режиме кластера (cluster mode) AM запускает драйвер внутри себя, а в режиме клиента (client mode) — драйвер работает на машине пользователя, а AM только координирует ресурсы.
  • Tez Application Master — для Apache Tez, оптимизированного для сложных DAG-графов задач. AM управляет выполнением вершин графа, динамически планируя задачи.
  • Flink Application Master — для Apache Flink, используемого для потоковой обработки. AM управляет долгоживущими кластерами Flink.
  • Custom Application Master — разработчики могут создавать собственные AM для специфических задач, используя API YARN (например, для машинного обучения или симуляций).

Особенности и преимущества

  • Масштабируемость: Благодаря разделению функций ResourceManager и Application Master, YARN может управлять кластерами из тысяч узлов и десятков тысяч приложений одновременно.
  • Гибкость: Application Master может быть написан для любого типа вычислений — от пакетной обработки до потоковой и интерактивных запросов.
  • Отказоустойчивость: При сбое AM ResourceManager может перезапустить его, используя сохранённое состояние (например, через механизм checkpointing в MapReduce). Это повышает надёжность выполнения длительных задач.
  • Динамическое управление ресурсами: AM может запрашивать и освобождать контейнеры в реальном времени, адаптируясь к изменяющимся требованиям задачи (например, при увеличении объёма данных).

Недостатки и ограничения

  • Накладные расходы: Запуск отдельного AM для каждого приложения требует времени и ресурсов (память, процессор). Для коротких задач (менее нескольких минут) накладные расходы могут быть значительными.
  • Сложность разработки: Создание собственного AM требует глубокого понимания API YARN, управления состоянием и отказоустойчивости. Это не тривиальная задача.
  • Зависимость от ResourceManager: Если ResourceManager выходит из строя, все AM теряют связь с ним, и приложения могут быть прерваны. В современных версиях Hadoop (начиная с 2.4) реализована высокая доступность (HA) для ResourceManager, но это требует дополнительной настройки.
  • Ограниченная поддержка в некоторых фреймворках: Не все приложения корректно обрабатывают перезапуск AM, что может привести к потере данных или необходимости повторного выполнения.

Примеры использования

  • Пакетная обработка данных: Крупные компании, такие как Facebook (продукт Meta, признанной экстремистской и запрещённой в РФ), LinkedIn и Twitter, используют YARN и Application Master для выполнения ежедневных ETL-процессов, анализа логов и построения отчётов. Например, Facebook обрабатывает петабайты данных в день с помощью MapReduce и Spark, где каждый джоб имеет свой AM.
  • Машинное обучение: В системах, подобных Apache Mahout или TensorFlow on YARN, AM управляет распределённым обучением моделей, запрашивая ресурсы для вычислительных узлов.
  • Потоковая обработка: Apache Flink на YARN использует AM для управления долгоживущими кластерами, которые обрабатывают потоки данных в реальном времени (например, мониторинг финансовых транзакций).

Сравнение с другими архитектурами

  • Apache Mesos: В Mesos роль, аналогичную Application Master, выполняет фреймворк (framework), который также управляет задачами, но взаимодействует с Mesos master через двухуровневое планирование. В YARN AM более тесно интегрирован с ResourceManager.
  • Kubernetes: В Kubernetes управление приложениями осуществляется через контроллеры (Deployment, Job, CronJob). В отличие от YARN, Kubernetes не имеет отдельного компонента для каждого приложения — контроллеры управляют подами, но не предоставляют такой же гибкости в динамическом запросе ресурсов, как AM.
  • Slurm: В высокопроизводительных вычислениях (HPC) Slurm использует задания (jobs) и шаги (steps), где роль AM выполняет сам пользовательский процесс, но без встроенного механизма отказоустойчивости.

Интересные факты

  • Изначально Application Master был разработан для Hadoop MapReduce, но его универсальность позволила интегрировать множество других фреймворков, что сделало YARN основой для «озера данных» (data lake) в крупных организациях.
  • В YARN существует понятие «unmanaged AM» — такой AM запускается вне кластера (например, на машине пользователя) и не управляется ResourceManager. Это используется для отладки или для приложений, которые не требуют динамического выделения ресурсов.
  • В версии Hadoop 3.x была добавлена поддержка «YARN Federation», которая позволяет объединять несколько кластеров YARN в один логический, что ещё больше повышает масштабируемость.

Источники

  • Apache Hadoop YARN Documentation (официальная документация).
  • V. K. Vavilapalli et al., «Apache Hadoop YARN: Yet Another Resource Negotiator», Proceedings of the 4th Annual Symposium on Cloud Computing (SOCC), 2013.
  • T. White, «Hadoop: The Definitive Guide», 4th Edition, O'Reilly Media, 2015.
  • J. N. Matthews, «YARN Application Master Development Guide», Apache Software Foundation, 2016.
  • Документация Apache Spark, Apache Flink, Apache Tez по интеграции с YARN.

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

Заметили ошибку или не согласны с информацией в статье? Напишите нам support@bfometr.ru