Планирование ресурсов в YARN: Capacity и Fair Scheduler

В эпоху больших данных эффективное планирование ресурсов в кластере Hadoop становится ключевым фактором для соблюдения SLA, предотвращения перегрузок и обеспечения предсказуемости выполнения задач. YARN выступает как механизм управления ресурсами, а Capacity Scheduler и Fair Scheduler - его два разножелезных подхода к организации очередей и долей процессорного времени и памяти между приложениями и пользователями. В рамках этой главы рассмотрены принципы работы каждого планировщика, типовые конфигурации очередей, сценарии эксплуатации в корпоративной среде, а также способы мониторинга и оптимизации. Особое внимание уделяется тому, как эти подходы соотносятся с архитектурой дата-lake, ETL-пайплайнами и рабочими нагрузками аналитических задач.

Две парадигмы планирования решают разные задачи: Capacity Scheduler ориентирован на предсказуемость и разделение ресурсов между командами через фиксируемые квоты очередей, что важно в мультиарендной среде и для регламентированных SLA. Fair Scheduler, напротив, обеспечивает справедливое разделение ресурсов между активными приложениями и пользователями, адаптируясь к меняющимся нагрузкам и динамике очередей. В корпоративной практике выбор между ними часто определяется характеристиками workloads, требованиями к предсказуемости и роли каждой команды в ходе lifecycle данных проектов. В рамках курса мы рассмотрим конфигурацию, принципы работы и практические подходы к внедрению каждого планировщика, а также подходы к мониторингу и совместной эксплуатации в рамках единого дата-слота.

Краткое содержание главы
Принципы архитектуры Capacity Scheduler и ключевые параметры очередей.
Принципы архитектуры Fair Scheduler, механизмы справедливого распределения и типовые настройки.
Практическая конфигурация, сравнение сценариев внедрения и мониторинг SLA.

Введение в планирование ресурсов в YARN

Планирование ресурсов в YARN опирается на концепцию ресурсов, которые представляют собой комбинированный набор характеристик узла: память и вычислительная мощность (vCores). ResourceManager отвечает за глобальное назначение этих ресурсов на очереди и приложения, в то время как NodeManager обеспечивает локальное выделение и контроль за использованием ресурсов на каждом узле. В многопользовательской корпоративной среде задача планировщика состоит не просто в распределении ресурса, но и в соблюдении границ между командами, недопущении перегрузок и учёте требований к SLA. Именно здесь на сцену выходят Capacity Scheduler и Fair Scheduler.

Capacity Scheduler реализует концепцию разделяемых очередей, каждая из которых получает фиксированную долю кластерных ресурсов, выраженную в процентах или долях памяти и vCores. Такой подход обеспечивает предсказуемое выделение для бизнес-подразделений, проектов или отделов, независимо от характера нагрузки в момент времени. Внутри очереди ресурсы распределяются между активными приложениями по справедливой доле, ограниченной пользовательскими квотами и политиками очереди. Это позволяет избегать ситуации, когда одна задача «бирает» все доступные ресурсы и задерживает работу других проектов.

Fair Scheduler же реализует модель справедливого распределения между активными приложениями или пользователями, динамически адаптируясь к изменяющейся нагрузке. В рамках Fair Scheduler до определенного момента выделяются доли ресурсов между pools и приложениями, а затем ресурсы перераспределяются с учетом текущей загрузки, задержек и очередей. Это особенно полезно в сценариях, когда требуется гибкость и равный доступ к ресурсам между командами, работающими над различными этапами пайплайна обработки данных.

С точки зрения интеграции, оба подхода требуют продуманной конфигурации и мониторинга: SLA-ориентированные проекты зачастую предпочитают Capacity Scheduler для фиксированной доли ресурсов, тогда как проекты, ориентированные на эксперименты и быструю итерацию, чаще используют Fair Scheduler. В любом случае критически важно обеспечить видимость перераспределения ресурсов через мониторингная панели и алерты, чтобы своевременно реагировать на отклонения и перераспределять квоты.

Оценка потребностей: выделение команд и проектов в качестве очередей (Capacity) или pools (Fair) зависит от процессов планирования и требуемой предсказуемости.
Архитектура: Capacity Scheduler строит иерархию очередей с фиксированными квотами; внутри очередей применяется справедливый обмен между приложениями. Fair Scheduler строит pools и под pools - справедливый доступ к ресурсам между запущенными приложениями.
Мониторинг и SLA: в обоих подходах ключевыми метриками являются загруженность очередей, потребление ресурсов, headroom и время ожидания очередей.

Capacity Scheduler: архитектура, очереди и политики

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

Capacity Scheduler реализует двухуровневую схему планирования: глобальные очереди, распределяющие cluster-капасити между разными бизнес-подразделениями, и внутри каждой очереди - механизм распределения ресурсов между запущенными приложениями. Главный принцип - гарантированное выделение минимальной и максимальной доли ресурсов каждому узлу очереди. Такое разделение обеспечивает устойчивость к перегрузкам и ориентированность на SLA. В реальной конфигурации очереди Capacity Scheduler определяют параметры, такие как capacity, maximumCapacity, userLimit и различные политики ACL.

Внутри очереди применяется справедливое распределение между приложениями, которое учитывает вес (weight) и пользовательские квоты, чтобы предотвратить доминирование одного пользователя или одного приложения. Применяемая в Capacity Scheduler логика позволяет поддерживать предсказуемую пропускную способность для критически важных задач и избегать «цепных» задержек в проектах с более низким приоритетом. В результате получается предсказуемый обмен ресурсами между очередями и справедливый внутри очереди между приложениями.

Конфигурация очередей Capacity Scheduler

Конфигурация описывается в capacity-scheduler.xml. В файле задаются иерархические очереди, их доли кластерных ресурсов и ограничения по пользователям. Пример типичной структуры очередей:

корневая очередь "root", далее вложенные очереди для департаментов, например "marketing", "finance", "engineering".
каждая очередь получает параметр capacity (доля ресурсов) и maxCapacity (верхний предел).

внутри очередей - правила разрешений на публикацию приложений, ACL и квоты пользователей.

<property>
  <name>yarn.resourcemanager.scheduler.class</name>
  <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler</value>
</property>

<property>
  <name>yarn.scheduler.capacity.root.queues</name>
  <value>root.a.root.b</value>
</property>

<property>
  <name>yarn.scheduler.capacity.root.a.capacity</name>
  <value>40</value>
</property>

<property>
  <name>yarn.scheduler.capacity.root.b.capacity</name>
  <value>60</value>
</property>

<property>
  <name>yarn.scheduler.capacity.root.a.maximumCapacity</name>
  <value>60</value>
</property>

defaultQueueName - имя очереди по умолчанию, если приложение не выбирает конкретную очередь.
queues - иерархия очередей с вложенными узлами и их квотами.
userLimitPolicy - политика ограничения пользователей внутри очередей (например, strong или weak).

Алгоритмы планирования внутри Capacity Scheduler

В рамках Capacity Scheduler основной механизм - строгие квоты на очереди и их перераспределение. Правило простое: если общая загрузка очереди не превышает её capacity, ресурсы распределяются между приложениями внутри очереди пропорционально их заявкам. В условиях перегруза, когда очереди достигают своих квот, применяется прегрешение (preemption) - ресурсы временно возвращаются другим очередям или приложениям с более низкими потребностями. Внутри очереди применяется справедливый обмен между приложениями (один из элементов архитектуры Capacity Scheduler), однако ключевым ориентиром остается соблюдение квот на уровне очереди.

Параметры, влияющие на поведение:

capacity - базовая доля ресурсов кластера, выделенная очереди.
maximumCapacity - верхний предел для очереди.
userLimit - лимит на ресурсы, доступные каждому пользователю внутри очереди.
minimumActiveUsers - минимум активных пользователей, необходимый для поддержания равного распределения.
preemption - флаг включения принудительного освобождения ресурсов у приложений для обеспечения справедливости между очередями.

Интеграция и эксплуатация

В корпоративной среде Capacity Scheduler часто применяется для отделения ресурсов между бизнес-единицами, проектами и временными задачами, например, планирование ETL-процессов, архивирования, обработку данных на Data Lake. Включение контроля доступа через ACL позволит ограничить публикацию приложений и изменение конфигураций очередей только уполномоченным пользователям. Для обеспечения устойчивости к сбоям и поддержания SLA следует включать мониторинг загруженности очередей, времени ожидания и headroom - запас ресурса в текущий момент времени для предотвращения чрезмерной задержки.

Пример сценария внедрения: выделение 40% кластерных ресурсов под core-проекты engineering, 30% под аналитическую команда marketing и 30% под финансовые расчеты. В рамках engineering применяется внутренняя балансировка между задачами, а в маркетинге - строгий cap на пиковые нагрузки в период кампаний.
Взаимодействие с LDAP/kerberos: настройка безопасного доступа к очередям и дашбордам мониторинга, разграничение полномочий на конфигурацию очередей.

Fair Scheduler: архитектура, принципы и особенности

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

Fair Scheduler строит динамическое разделение ресурсов между активными приложениями, называемыми задачами, через pools (пулы) и справедливый доступ к ресурсам. Основная идея - обеспечить каждому приложению «честную долю» от общего объема ресурсов, с учетом текущей загрузки кластера. В отличие от Capacity Scheduler, где грань между очередями фиксируется, в Fair Scheduler ключевую роль играет динамическое перераспределение между активными задачами на основе текущего потребления. В корпоративном контексте это означает более гибкую реакцию на неожиданные пики нагрузки и равный доступ к ресурсам между командами, работающими над разными этапами пайплайна.

Конфигурация Fair Scheduler

Настройки для Fair Scheduler видимы в fair-scheduler.xml и позволяют определить pools, их minShare, weight и правила очередей. Важными параметрами являются:

minShare - минимальная доля ресурсов, гарантированная пулу.
weight - относительный вес пула в рамках общего пула справедливости.
-fairSharePreemption - включение принудительной перераспределимости, если одна задача навязывает ресурсы другим.
```
<property>
  <name>yarn.resourcemanager.scheduler.class</name>
  <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
</property>

<property>
  <name>yarn.scheduler.fair.allocation.file</name>
  <value>/etc/hadoop/conf/fair-schedule.xml</value>
</property>
```
Файл fair-schedule.xml описывает pools и правила перераспределения. Пример структуры пула:
pools: root → data-science, etl, reporting
каждый pool имеет minShare и weight

внутри pool - приложения, которые получают ресурсы пропорционально своему спросу и весу

<pool name="root">
  <minShare>0</minShare>
  <weight>1.0</weight>
  <pool name="data-science">
    <minShare>20</minShare>
    <weight>2.0</weight>
  </pool>
  <pool name="etl">
    <minShare>15</minShare>
    <weight>1.5</weight>
  </pool>
  <pool name="reporting">
    <minShare>10</minShare>
    <weight>1.0</weight>
  </pool>
</pool>

Алгоритмы планирования и предельные режимы

Fair Scheduler применяет концепцию доминирующей доли ресурса (dominant share) для определения того, как перераспределять ресурсы между активными приложениями. В условиях пиковых нагрузок планировщик стремится сохранить отношение между аппликациями в рамках заданных весов и минимальных долей. Принудительная перераспределяемость (preemption) активируется, когда текущие потребности превышают доступность ресурсов, и приложение может быть «вытащено» из ресурсоемкой фазы, чтобы обеспечить доступ к ресурсам другим критичным задачам.

Важно учитывать: в рамках Fair Scheduler динамика может приводить к более коротким задержкам для новых задач при отсутствии предсказуемости по очередям, но при этом обеспечивает справедливость между активными задачами. Это особенно полезно в сценариях, когда проекты находятся на стадии активной разработки и требуют гибкого доступа к вычислительным ресурсам без жесткой фиксации квот.

Практические аспекты эксплуатации

Выбор между двумя подходами часто основывается на бизнес-целях. Capacity Scheduler лучше подходит для корпоративной мультиарендной среды, где важна предсказуемость и разделение ресурсов между командами. Fair Scheduler - если требуется более гибкое распределение между активными задачами, особенно в условиях неопределенной нагрузки.
Мониторинг: для обоих планировщиков разумно внедрять дашборды по загрузке очередей или пулов, headroom, среднему времени ожидания и доле ресурсов, занятых приложениями. Визуализация помогает оперативно корректировать квоты и веса.

Конфигурация и стиль эксплуатации: как выбрать и настроить

В типовой корпоративной инфраструктуре целевая архитектура может сочетать элементы обеих парадигм: Capacity Scheduler как базовый уровень разделения ресурсов между бизнес-единицами, Fair Scheduler - внутри отдельных очередей для балансировки между активно работающими приложениями.
Важные практики:
- Определение четких очередей и пулов на уровне бизнес-единиц и проектов.
- Применение ACL и правил безопасности для контроля доступа к очередям и приложениям.
- Мониторинг через YARN ResourceManager UI, интеграцию с системами оповещения (например, Prometheus + Grafana) и логирование.
- Постепенная настройка: запуск в тестовом окружении, моделирование нагрузки, затем постепенное внедрение в прод.
Примеры практических шагов:
- Выделение минимальных долей времени и памяти под критичные пайплайны ETL, чтобы они быстрее проходили через очереди.
- Введение предачи между очередями для устойчивости к пиковым нагрузкам.
- Оптимизация политик пользовательских квот (userLimit) и предельной доли для предотвращения «запирания» ресурсов конкретными пользователями.

Мониторинг, SLA и интеграция с дата-озером

Эффективное управление ресурсами требует постоянного наблюдения за состоянием кластера. Рекомендуются следующие практики:

Мониторинг заполненности очередей и пулов, средней очередности и времени ожидания задач.
Контроль headroom - запас ресурсов, позволяющий предсказать перегрузку и предотвратить задержки.
Визуализация метрик: использование панели Yard Manager UI, интеграции с внешними системами мониторинга, настройка тревог по критическим порогам.
Интеграция с корпоративной политикой доступа и идентификации: Kerberos/LDAP обеспечивает безопасное управление правилами очередей и доступом к данным в Data Lake.
Взаимодействие с данными Data Lake: планировщики влияют на скорость загрузки и обновления индексов, что критично для своевременного обновления каталога данных и обеспечения высокоуровневой доступности к данным.
В копилке практик полезно держать единый регламент по отношение к SLA: какие очереди получают какие гарантии, какие задачи могут временно превысить квоты и как заранее информировать бизнес.

Интеграция в корпоративные пайплайны: сценарии и практики

ETL-пайплайны с предсказуемой задержкой: Capacity Scheduler обеспечивает стабильную пропускную способность и предсказуемые сроки выполнения.
Аналитика в реальном времени и пакетная обработка: компромисс между предсказуемостью и гибкостью, выбор между планировщиками в зависимости от стадий пайплайна.
Data Lake и хранение данных: выделение ресурсов под задачи загрузки и индексации, чтобы не блокировать аналитические задачи, работающие с уже загруженными данными.
Рекомендации по миграции:
- Начните с моделирования текущей загрузки в тестовом кластере и определения приоритетов очередей.
- Постепенно внедряйте квоты, веса и прегрешение, отслеживая влияние на latency и throughput.
- Внесите необходимые изменения в политики безопасности и мониторинга.

Key takeaways

Capacity Scheduler обеспечивает предсказуемость ресурсов между очередями за счет фиксированных квот и гибкого внутриочередного распределения.
Fair Scheduler ориентирован на динамическое и справедливое распределение ресурсов между активными приложениями и пулами.
Выбор между планировщиками основывается на акцентах бизнеса: предсказуемость и изоляция против гибкости и адаптивности.
Эффективная конфигурация требует четко продуманной структуры очередей или пулов, а также мониторинга headroom, очередности и SLA.
Безопасность и управление доступом следует внедрить на уровне очередей и пулов, совместив это с корпоративной политикой идентификации.
Интеграция планировщиков с инфраструктурой Data Lake должна обеспечивать баланс между загрузкой данных и аналитическими задачами, сохраняя цепочку доверенных источников и своевременный доступ к данным.
Мониторинг и алерты - ключ к устойчивости: своевременная реакция на перегрузку и перераспределение ресурсов помогают поддерживать SLA.

FAQ

Чем принципиально отличаются Capacity Scheduler и Fair Scheduler в реальном кластере?

Capacity Scheduler предоставляет строгую разделяемую квоту между очередями и внутри очередей применяет справедливый обмен между приложениями. Это обеспечивает предсказуемость для бизнес-единиц и проектов, которые требуют фиксированного объема ресурсов. Fair Scheduler обеспечивает динамическое справедливое распределение между активными задачами и пулами, что особенно полезно в условиях изменяющейся загрузки и необходимости быстрого реагирования на пики.

Какие параметры очередей критичны для Capacity Scheduler?

capacity и maximumCapacity определяют долю ресурсов очереди; userLimit ограничивает ресурсы, доступные каждому пользователю внутри очереди; preemption позволяет вернуть ресурсы другим очередям; ACL и descriptions помогают управлять доступом и управляемостью очередей.

Какие параметры пулов критичны для Fair Scheduler?

minShare обеспечивает базовую долю ресурсов для пула; weight определяет относительный вклад пула в общую справедливость; preemption позволяет перераспределить ресурсы между пулами при перегрузке;Allocation файл описывает набор пулов и приложений.

Какой подход выбрать для мультиарендной корпоративной среды?

В большинстве случаев для мультиарендной среды предпочтителен Capacity Scheduler, поскольку он обеспечивает предсказуемость и изоляцию между бизнес-единицами. Однако, если нагрузка между проектами крайне изменчива и требуется гибкость, можно рассмотреть внедрение Fair Scheduler внутри отдельных очередей.

Как мониторить производительность планировщика?

Используйте ResourceManager UI для отображения статуса очередей/пулов, загрузку ресурсов и время ожидания приложений. Дополнительно настройте внешние панели мониторинга (Prometheus, Grafana) и тревоги по порогам headroom иthroughput, чтобы оперативно реагировать на перегрузку.

Как учитывать SLA и производительность при миграции на другой планировщик?

Начните с моделирования нагрузки в тестовом кластере, выберите набор бизнес-юнитов и определите желаемые квоты и веса. В процессе внедрения постепенно расширяйте набор очередей/пулов и проводите A/B-тесты по SLA и latency. Включите мониторинг и регламент обновления политик очередей.

Какие типовые риски при работе с планировщиками?

Неправильно настроенные квоты могут привести к недоиспользованию ресурсов или к задержкам у критичных приложений. Преждевременная прегрешенность может вызывать ненужные перерывы в выполнении задач. Важно выстроить цикл обратной связи: сбор метрик, корректировка квот и регулярные ревизии политик.

Какие open-source решения чаще всего применяются вместе с YARN в роли мониторинга?

Prometheus и Grafana - популярное сочетание для мониторинга метрик YARN, KPI очередей и производительности. Открытые экспортёры позволяют собирать метрики с ResourceManager, NodeManager и приложений.

Что важно учитывать при настройке секьюрности для планировщиков?

Необходимо управлять доступом к очередям (ACL), ограничивать возможность изменения конфигураций, использовать Kerberos или LDAP для аутентификации, а также обеспечить аудит действий администраторов и пользователей.

Как планировщики взаимодействуют с Data Lake и пайплайнами?

Планировщики влияют на скорость загрузки данных и доступ к ресурсам для ETL-процессов. Корректная настройка очередей/пулов обеспечивает своевременное выполнение загрузок, индексаций и репликаций, что поддерживает актуальность каталогов и доступность данных в Data Lake. Важно учесть зависимость между загрузкой данных и аналитикой, чтобы не блокировать критические задачи.

← Предыдущая статья

Архитектура YARN: ResourceManager, NodeManager, ApplicationMaster

Следующая статья →

Контейнеризация и выполнение задач в YARN: схемы обновления и fault tolerance