YARN¶

YARN (Yet Another Resource Negotiator) — это компонент архитектуры Apache Hadoop, отвечающий за управление ресурсами кластера и планирование выполнения заданий. YARN является второй версией системы управления ресурсами в экосистеме Hadoop, пришедшей на смену классическому MapReduce, и выполняет функции системы распределённого управления ресурсами (Resource Management) и планировщика задач (Job Scheduler). YARN позволяет отделить логику обработки данных от управления вычислительными ресурсами, что обеспечивает поддержку различных парадигм обработки, включая не только MapReduce, но и потоковую обработку (Spark, Flink), итеративные вычисления и интерактивные запросы (Tez, Impala).

¶История

Проект Hadoop был создан в 2005 году на основе работ Google по распределённой файловой системе (GFS) и модели MapReduce. В ранних версиях Hadoop (до версии 1.x) единственным способом выполнения заданий была модель MapReduce, а управление ресурсами и планирование выполнялись непосредственно внутри JobTracker. С ростом объёмов данных и усложнением бизнес-задач стало очевидно, что монолитная архитектура JobTracker/ TaskTracker имеет ряд недостатков: ограниченная масштабируемость (JobTracker мог управлять не более чем 4000 узлов), низкая отказоустойчивость и невозможность параллельно запускать разные типы приложений.

В 2012 году сообщество Apache выпустило версию Hadoop 2.0, в которой была представлена архитектура YARN (Yet Another Resource Negotiator). Разработка велась под руководством Ардата Мерфи (Arun Murthy) и других участников проекта. YARN заменил классический JobTracker на более гибкую систему, состоящую из глобального менеджера ресурсов (ResourceManager) и периферийных менеджеров узлов (NodeManager). Это позволило повысить масштабируемость до 10 000 узлов и 100 000 контейнеров, а также обеспечить параллельную работу различных фреймворков обработки данных.

В 2017 году вышла версия Hadoop 3.0, в которой YARN был существенно доработан: улучшена поддержка контейнеров с GPU и FPGA, введена поддержка очередей с приоритетами и улучшено управление памятью.

¶Архитектура и компоненты

Архитектура YARN построена по принципу «мастер-раб» (master-slave). Основными компонентами являются:

• ResourceManager (RM) — глобальный менеджер ресурсов, работающий на главном узле кластера. Он отвечает за распределение вычислительных ресурсов (память, CPU, сеть) между приложениями и управляет очередями заданий. RM состоит из двух subsystem: Scheduler (планировщик) и ApplicationsManager (менеджер приложений). Планировщик распределяет ресурсы между очередями и приложениями, а ApplicationsManager управляет жизненным циклом приложений.

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

• Application Master (AM) — компонент, специфичный для каждого приложения. Он создаётся один раз для каждого задания и управляет его выполнением: запрашивает у ResourceManager ресурсы для контейнеров, координирует работу параллельных задач (mappers/reducers) и отслеживает их выполнение. AM может быть запущен как отдельный контейнер на любом узле кластера. После завершения задания AM завершает работу.

• Container — базовая единица распределения ресурсов. Каждый контейнер представляет собой выделенную вычислительную среду с определённым объёмом памяти и ядер CPU, в которой выполняется один или несколько процессов. Контейнеры управляются NodeManager.

¶Процесс выполнения задания

При поступлении задания (например, MapReduce-задачи) в YARN происходит следующий процесс:

1. Клиент отправляет задание ResourceManager.
2. ResourceManager создаёт экземпляр Application Master, который запускается в контейнере на узле, выбранном планировщиком.
3. Application Master регистрирует себя в ResourceManager и запрашивает необходимое количество контейнеров для выполнения параллельных задач (mappers / reducers).
4. ResourceManager распределяет контейнеры на узлы, учитывая свободные ресурсы и политики планировщика.
5. NodeManager на каждом узле запускает контейнеры с компонентами задачи (например, Mapper или Reducer).
6. Application Master координирует выполнение задач, обрабатывает ошибки и управляет перезапусками.
7. После завершения всех задач Application Master отправляет отчёт ResourceManager и завершает работу.

Таким образом, ResourceManager не участвует непосредственно в выполнении кода — он только распределяет ресурсы, что позволяет избежать перегрузки центрального узла.

¶Планировщики YARN

YARN поддерживает несколько типов планировщиков, каждый из которых ориентирован на разные сценарии:

• FIFO Scheduler — простой планировщик, работающий по принципу «первый пришёл — первый обслужен». Задания выполняются строго в порядке очереди. Не подходит для многопользовательских сред, так как одно большое задание может заблокировать очередь для маленьких задач.

• Fair Scheduler — планировщик, стремящийся равномерно распределить ресурсы между всеми запущенными приложениями. Применяется в средах с большим количеством пользователей. Поддерживает очереди с весами и временное резервирование ресурсов.

• Capacity Scheduler — планировщик, использующий иерархию очередей с заданными ёмкостями. Каждая очередь гарантирует определённую долю ресурсов, но может превышать её, если другие очереди не используют ресурсы. Это стандартный планировщик в Hadoop 3.x и используется по умолчанию в платформах типа Cloudera и Hortonworks.

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

YARN является ключевым компонентом экосистемы Hadoop и используется в корпоративных дата-центрах для обработки больших объёмов данных (Big Data). Основные сценарии применения:

• Пакетная обработка данных — выполнение задач MapReduce, Hive, Pig.
• Интерактивные запросы — работа с Apache Spark SQL, Apache Impala, Presto.
• Потоковая обработка — запуск Apache Flink, Apache Storm.
• Машинное обучение — распределённое обучение моделей на Spark MLlib или TensorFlowOnYARN.
• Управление вычислительными кластерами — для поддержки научных расчётов, обработки логов и аналитики.

YARN широко применяется в крупных интернет-компаниях (Facebook, Yahoo!, LinkedIn, eBay), финансовых учреждениях и государственных структурах. В России YARN используется в платформах обработки данных крупных банков (Сбербанк, ВТБ), телекоммуникационных компаний (МТС, Ростелеком) и государственных информационных систем.

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

Несмотря на широкое распространение, YARN подвергается критике по нескольким причинам:

• Сложность конфигурации — настройка ресурсов, очередей и политик требует глубоких знаний и часто ведёт к непредсказуемому поведению при перегрузке кластера.
• Производительность — из-за необходимости постоянно согласовывать ресурсы между ResourceManager и NodeManager, накладные расходы могут быть высокими, особенно при работе с большим количеством короткоживущих контейнеров.
• Недостаточная поддержка контейнеров — в ранних версиях YARN плохо поддерживал управление GPU, что ограничивало его применение в задачах машинного обучения.
• Миграция на Kubernetes — в последние годы наблюдается тенденция к переходу с YARN на Kubernetes как более универсальную платформу оркестрации контейнеров, что снижает актуальность YARN в новых проектах.

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

• Название «Yet Another Resource Negotiator» было выбрано в ироническом ключе, подчёркивая, что проект является очередной реализацией системы управления ресурсами, но с улучшенной архитектурой.
• В версии Hadoop 3.0 была добавлена поддержка так называемых «Resource Profiles» — возможность задавать произвольные метрики (например, GPU, FPGA) для контейнеров.
• Компания Microsoft выпустила собственную реализацию YARN под названием «HDInsight» в облачной платформе Azure.

¶Источники

• Apache Hadoop Documentation. Apache Software Foundation.
• White, T. (2015). Hadoop: The Definitive Guide. 4th ed. O'Reilly Media.
• Murthy, A. et al. (2013). Apache Hadoop YARN: Moving beyond MapReduce and Batch Processing with Apache Hadoop 2. Addison-Wesley.
• Hadoop 3.0 Release Notes. Apache Hadoop.
• Сафонов, А. (2018). Большие данные в российских компаниях: практика использования Hadoop. Издательство «ДМК Пресс».