Введение:В этой статье представлена ​​серия оптимизаций, которые ByteDance провела в Hadoop YARN за последние четыре года по четырем аспектам: улучшение использования, оптимизация сценариев с несколькими загрузками, повышение стабильности и удаленная многозадачность, а также практический опыт работы в производственной среде. .

1. Введение в пряжу

1.1 Экосистема пряжи

YARN (Yet Another Resource Negotiator) — это система управления ресурсами кластера Hadoop и очень важный проект-участник экосистемы Hadoop.

В целом экологию офлайн можно разделить на пять слоев:

• Нижний уровень — это уровень «голого железа», который состоит из множества физических узлов, каждый из которых работает под управлением общей операционной системы.
• Второй нижний уровень — это уровень управления ресурсами кластера, и YARN находится на этом уровне.
• Далее идет уровень распределенного вычислительного механизма, где расположены MR/Spark/Flink и другие вычислительные механизмы.Чтобы студенты-бизнесмены могли писать вычислительные задачи с меньшими затратами, каждый механизм поддерживает функции SQL.
• Далее идет уровень размещения заданий, который используется для отправки специальных заданий, управления периодическими пакетными заданиями и управления длительными потоковыми заданиями.
• Верхний уровень — это уровень пользовательской логики, такой как ежедневные отчеты по данным, анализ данных, обучение модели и т. д.

1.2 Архитектура пряжи

Область серого фона на приведенном выше рисунке — это основная архитектура YARN, которая в основном включает две роли:

• ResourceManager

  • Мозг всего кластера отвечает за планирование ресурсов для приложений и управление жизненным циклом приложений.
  • Предоставьте пользователям интерфейс, включая интерфейс командной строки, API, интерфейс WebUI.
  • Одновременно может быть несколько РМ, но одновременно работает только один, а мастер выбирается по ЗК между РМ.

• NodeManager

  • Предоставьте ресурсы для всего кластера и примите запуск контейнеров.
  • Управляйте жизненным циклом Contianer во время выполнения, включая локализацию, изоляцию ресурсов, агрегирование журналов и т. д.

Вакансии, работающие на YARN:

• Он будет получать доступ к внешним службам данных во время выполнения, таким как HDFS, Kafka и т. д.
• YARN будет отвечать за загрузку журналов в HDFS после запуска.

2. Настройка YARN от ByteDance

YARN от ByteDance был разветвлен из последней версии сообщества 2.6.0 в 2016 году и в основном включает три основных сценария: автономные задания / потоковые задания / обучение моделям внутри компании. Из-за огромного масштаба и сложных сценариев службы YARN в компании возникали различные проблемы. До того, как версия сообщества не предоставила решения, внутренние студенты отдела исследований и разработок настраивали множество контента для решения конкретных проблем. После тысяч исправлений более последние четыре года компания Версия сильно отличалась от версии сообщества.

Сегодня я познакомлю вас с некоторыми ключевыми настройками, надеясь вдохновить вас. Эти ключевые настройки в основном включают четыре аспекта:

• Увеличение использования: включая увеличение скорости распределения и увеличение физического использования.
• Оптимизация различных сценариев нагрузки: в том числе улучшение опыта пакетного/потокового/моделированного обучения в трех сценариях.
• Повышение стабильности: в том числе избавление от сильной зависимости от HDFS, классификация и выселение контейнеров, а также неконтролируемое управление контейнерами.
• Живите в разных местах: включая единый клиент YARN и пользовательский интерфейс.

2.1 Улучшение использования

2.1.1 Многопоточная версия Fair Scheduler

Нативная для сообщества версия FairScheduler является однопоточной, что является самым большим узким местом всего кластера при большом количестве узлов.

Преобразовав FairScheduler в параллельную многопоточную версию и разделив блокировки внутри планировщика на более мелкие блокировки чтения и записи, мы увеличили пропускную способность планирования более чем в 7 раз, достигнув скорости 3K контейнеров в секунду в производственной среде. (без узких мест производительности).

2.1.2 Рассмотрим планирование узла DRF

Родной YARN учитывает только, удовлетворены ли ресурсы при планировании.Часто бывает, что ЦП узла заполнен, но еще остается память.

Мы вводим механизм node DRF (Dominant Resource Fairness) для расчета основного ресурса из оставшихся ресурсов каждого узла.Когда основной ресурс запланированной задачи не соответствует основному ресурсу узла, планирование будет отложено до определенного количество раз, прежде чем ослабить ограничение.

Благодаря внедрению этого механизма проблема фрагментации ресурсов кластера значительно снижается, а среднее использование ЦП и памяти в производственной среде за 24 часа может превышать 90%.

2.1.3 Увеличение масштаба отдельного кластера

Чем больше размер одного кластера, тем больше пользователей и заданий могут использовать кластер, а загрузка кластера будет выше. Но у родного YARN начались различные проблемы, когда он достиг масштаба узлов 5K. Например, простой мастер-свич может привести к лавине всего кластера.

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

• Во-первых, путем сортировки и настройки внутренних событий YARN была точно изменена логика обработки некоторых событий.
• Затем измените механизм сердцебиения узла NodeManager, чтобы он динамически настраивался в соответствии с давлением ResourceManager.
• После этого измените блок памяти (int->long), чтобы преодолеть ограничение в 2,1 миллиарда МБ для одного кластера.
• После этого за счет глубокой оптимизации процесса основного переключения на втором уровне контролируется время основного переключения.

Конечно, есть много других подробных оптимизаций, которые не будут перечисляться по отдельности.Конечным результатом является увеличение масштаба одного производственного кластера до 20 000 узлов.

2.1.4 Совместно с потоковыми и онлайн-сервисами

Автономные ресурсы в компании относительно ограничены в течение дня, а использование ресурсов потоковых заданий и онлайн-сервисов имеет очевидные пики и спады в зависимости от поведения пользователя.Избыточные ресурсы предоставляются в автономном режиме, что может всесторонне улучшить коэффициент использования. .

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

В настоящее время в производственной среде совместно размещены десятки тысяч узлов, после чего абсолютное значение использования ЦП исходной машины увеличилось более чем на 20%.

2.1.5 Smart Resource: настройка ресурсов во время выполнения/перезапуска

В родном YARN часто бывает большое отклонение между ресурсами, применяемыми пользователями, и фактически используемыми ресурсами, что приводит к большому количеству растраты ресурсов.По этой причине мы разработали полный набор решений для динамической настройки ресурсов, которые могут отрегулируйте применяемые ресурсы до значения, близкого к фактически используемому ресурсу.

Более того, при реальном использовании обнаруживается, что если корректировка ресурсов должна основываться на одном ядре в качестве минимальной детализации, все равно будут серьезные потери.Например, реальный запрос пользователя может составлять 0,001 ядро ​​* 1000, а нативный YARN может выделить только 1000 ядер, 999 ядер были потрачены впустую. Мы разработали функцию с тысячной долей ядра в качестве наименьшей детализации, которая может эффективно сократить трату ресурсов. А сочетание тысячного ядра и динамической настройки ресурсов позволяет более точно регулировать ресурсы.

2.2 Оптимизация различных сценариев нагрузки

YARN от ByteDance поддерживает три основных сценария пакетной обработки/потоковой передачи/обучения модели внутри компании. Поскольку YARN по своей сути предназначен для пакетной обработки, многие места не соответствуют сценариям потоковой передачи/обучения модели. Чтобы обеспечить эти сценарии, лучший опыт требует некоторых работа по настройке.

2.2.1 Планировщик YARN Gang Scheduler

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

Gang Scheduler обеспечивает семантику «все или ничего».Например, если задание применяется для 1000 контейнеров, оно либо возвращает 1000 контейнеров напрямую, либо возвращает ошибку и запрашивает причину ошибки. Это может эффективно избежать ситуации блокировки, в которой оба задания получают только половину ресурсов, и никто не может их запустить.

Кроме того, Gang Scheduler также имеет сверхнизкую задержку, которая может дать заключение «все или ничего» за миллисекунды, что может значительно облегчить проблему отставания при перезапуске потоковых заданий.

Что наиболее важно, Gang Scheduler обеспечивает глобальную перспективу для потоковой передачи заданий и заданий по обучению, и каждое задание может обеспечить глобально оптимальную стратегию размещения, настроив свои собственные настраиваемые сильные и слабые ограничения. Среди них сильные ограничения относятся к условиям, которые должны быть выполнены; слабые ограничения относятся к ограничениям, которые выполняются в максимально возможной степени, но могут быть понижены, если они не могут быть удовлетворены. Поддерживаемые в настоящее время сильные ограничения включают атрибуты узла, высокую нагрузку и т. д.; поддерживаемые слабые ограничения включают: атрибуты узла, высокую нагрузку, разбиение контейнера, среднее значение квоты, привязку графического процессора и т. д.

2.2.2 Более точная политика использования ЦП

В дополнение к включению ограничения CGroup, которое YANR изначально поддерживает по умолчанию, мы также настроили более богатую стратегию управления CGroup, такую ​​как поддержка пользовательского максимального ограничения в режиме общего доступа, поддержка привязки ядра и поддержка узлов привязки NUMA. более гибкие стратегии управления и контроля для потоковой передачи заданий и заданий обучения для удовлетворения требований к изоляции или совместному использованию в различных сценариях.

2.2.3 Другие настройки в сценариях обучения

Для учебных сценариев мы также настраиваем более богатый контент. включать:

• Для лучшей изоляции настроил Docker для поддержки GPU и Ceph.
• Для более гибкого применения ресурса значение ресурса с диапазоном настраивается (традиционные ресурсы YARN имеют только число, без диапазона, например, сколько процессоров и сколько ГБ памяти, но в сценариях обучения иногда вам нужно иметь диапазон, Например, при использовании двух карт GPU вам нужны не только две случайные карты, но и две последовательные карты GPU на одном компьютере, например, карта 0 и карта 1 являются последовательными, а карта 0 и карта 2 не являются последовательными. Этот сценарий также применим к номерам портов.)
• Чтобы более эффективно использовать машины ЦП и ГП одновременно, функция атрибута узла настроена.

2.2.4 Пропуск узлов с высокой нагрузкой

Сценарий автономной пакетной обработки часто сталкивается с проблемой «Ошибка выборки». Основной причиной является недостаточное количество операций ввода-вывода в секунду на локальном диске, из-за чего служба перемешивания зависает. Чтобы облегчить эту проблему, мы добавляем коэффициент учета целевого хоста LoadAvg. в процессе планирования ресурсов. Если LoadAvg машины слишком высока, назначение новых задач на нее временно пропускается. Благодаря этому механизму проблема «Fetch Failed» снижается примерно на 40%.

2.3 Оптимизация стабильности

Масштаб службы ByteDance YARN огромен, он столкнулся со многими проблемами с точки зрения стабильности, и есть много деталей оптимизации. Из-за ограниченного времени вот несколько репрезентативных моментов оптимизации, которыми можно поделиться с вами:

• Сделать HDFS слабой зависимостью
  • Для обычной автономной пакетной обработки, если служба HDFS недоступна, YARN не нужно продолжать работу. Однако в ByteDance, поскольку YARN также выполняет потоковые задания и обучение моделей, сбои HDFS не могут повлиять на YARN. По этой причине мы избавляемся от сильной зависимости от HDFS, сохраняя NodeLabel в ZK и изменяя инициализацию каталога и загрузку Container Log в HDFS на асинхронный режим.
• Классификация контейнеров и выселение
  • Дисковое пространство некоторых контейнеров слишком велико, или установлена ​​очень высокая нагрузка на одну машину, что серьезно повлияет на нормальную работу других контейнеров.С этой целью мы настроили классификацию контейнеров и механизм выселения для YARN. Активное выселение будет выполняться для Контейнеров, которые могут серьезно повлиять на другие Контейнеры. Для удаленного задания его можно применить к отдельной метке для запуска.
• Механизм очистки неконтролируемых контейнеров
  • По разным причинам некоторые контейнеры всегда будут работать онлайн, но они больше не находятся под контролем YARN. Обычно это вызвано ненормальной эксплуатацией и техническим обслуживанием или выходом из строя самой машины. Если эти Контейнеры не контролируются, не только фактические ресурсы одной машины будут перегружены, но иногда повторное использование Kafka Topic приведет к сетевым авариям. С этой целью мы добавили механизм очистки неконтролируемых контейнеров в NodeManager YARN.

2.4 Больше живите в разных местах

С быстрым развитием компании YARN также открыл сценарий нескольких компьютерных залов в разных местах. Собственный YARN поддерживает использование только одного кластера, что неудобно для пользователей. Если каждый кластер предоставляется пользователям изолированно , это заставит пользователей использовать это очень сложно, по этой причине мы провели некоторую работу по настройке удаленного многоквартирного дома:

• Глобальный унифицированный пользовательский интерфейс YARN
  • Пользовательский интерфейс YARN настраивается одинаково для всех пользователей YARN, включая все очереди и пользовательские задания по всему миру.
• Отказ от ожидания задержки планирования местоположения данных
  • Локальное выравнивание данных с HDFS затруднено при наличии нескольких кластеров.
  • Сетевых ресурсов в машинном зале предостаточно, локальность данных существенно не улучшает производительность, а также приведет к снижению пропускной способности кластера.
• Безопасный режим пряжи
  • Для совместной работы с многокомнатным аварийным восстановлением иногда необходимо активно переводить некоторые кластеры YARN в безопасный режим, который не планирует новые задачи.

3. Будущая работа

В будущем мы продолжим оптимизировать совместное размещение потоковых и онлайн-сервисов, в том числе:

• Улучшение физического использования
• лучшая изоляция
• Более контролируемая скорость убийства
• Смешивание ресурсов GPU

В то же время мы продолжим улучшать YARN Gang Scheduler, в том числе:

• Расширенные предикаты планирования
• меньшая задержка

4. Знакомство с командой

Инфраструктура Команда YARN отвечает за управление ресурсами и планирование в трех основных сценариях автономного/потокового/моделированного обучения в ByteDance, поддерживая многие основные направления деятельности, такие как рекомендации/хранилище данных/поиск/реклама, а также управление масштабом кластера, планирование пропускной способности. , использование ресурсов, сложность бизнеса и другие аспекты являются ведущими в отрасли сверхкрупномасштабными кластерами.

Учитывая характеристики Douyin, Toutiao и других продуктов компании, которые в значительной степени полагаются на рекомендации, команда тщательно настроила планировщик для поддержки таких сценариев, как потоковое обучение (Flink) и обучение на GPU, и имеет десятки запатентованных технологий. В то же время, чтобы еще больше улучшить использование ресурсов кластера, команда планирования приступила к крупномасштабному совместному размещению в автономном режиме, и ожидается, что в ближайшем будущем будут дополнительно интегрированы такие системы планирования, как YARN / K8S.

Расширение бизнеса, команда уже давно набирает людей в Пекине/Ханчжоу. Портал доставки резюме: https://job.toutiao.com/s/KcoXsV

Добро пожаловать в техническую команду ByteDance