Ухань Юань Чуанхуэй возвращается, поговорим о больших моделях 20 апреля»

Аннотация: Эта статья составлена на основе основного доклада «ByteDance Spark поддерживает практику вывода модели Wanka» на CommunityOverCode Asia 2023 инженера инфраструктуры ByteDance Лю Чанга и инженера системы машинного обучения ByteDance Чжан Юнцяна.

В процессе разработки облачной нативизации Kubernetes позволил все большему количеству типов загрузочных приложений, включая большие данные и искусственный интеллект, перейти на Kubernetes благодаря своим сильным возможностям экологического конструирования и внутреннему влиянию Byte, исследующему миграцию Spark из Hadoop в Kubernetes. запускает облачные задания. Архитектуру управления ресурсами больших данных ByteDance и эволюцию развертывания Spark можно условно разделить на три этапа:

Первый этап — автономное управление ресурсами, полностью основанное на YARN. Широкомасштабное использование YARN для управления кластерами больших данных позволяет эффективно улучшить использование ресурсов Spark, одновременно снижая затраты на эксплуатацию и обслуживание ресурсов.
Второй этап — это этап смешанного развертывания автономных ресурсов. За счет создания гибридного кластера развертывания YARN и Kubernetes общее использование автономных ресурсов еще больше улучшается. Благодаря технологии гибридного развертывания значительно улучшилось использование ресурсов как кластеров, так и отдельных компьютеров. Повышение эффективности использования ресурсов означает необходимость в более полных средствах изоляции. Поэтому мы начали постепенно продвигать контейнерное развертывание Spark.
Третий этап — полное развертывание в облаке. Автономные нагрузки больше не используют разные архитектуры для управления, а стек технологий и пул ресурсов действительно унифицированы. Облачная среда Spark также постепенно создается и улучшается.

Конечно, облачные решения — почти единодушная тенденция развития в отрасли, так зачем же использовать облачные решения? Зачем использовать Kubernetes в качестве единой базы управления ресурсами? Есть три основных преимущества. Первое — это эффективная эксплуатация и обслуживание. Kubernetes обеспечивает гибкое создание и управление нагрузкой, будь то онлайн-загрузка или загрузка больших данных, с помощью нее можно легко обеспечить непрерывную разработку, интеграцию и развертывание. Во-вторых, объединение ресурсов в пул . Единая облачная база снижает накладные расходы на инфраструктуру и еще больше повышает эффективность передачи ресурсов. С точки зрения использования ресурсов можно более комплексно и полностью улучшить коэффициент использования всего центра обработки данных, достигнув снижения эффективности. . Третье — экологическое процветание . Мы знаем, что Kubernetes имеет почти самую активную экосистему. Он способствует экологическому развитию на всех уровнях, предоставляя стандартизированные определения интерфейсов, будь то базовые средства эксплуатации и обслуживания, управление приложениями верхнего уровня или базовая сеть и хранилище. . и т. д., существует множество опций управления, которые облегчают использование Spark в облаке.

Весы ByteDance Spark

ByteDance обладает лидирующим в отрасли масштабом бизнеса Spark, ежедневно выполняя миллионы автономных заданий, занимая ресурсы миллионов ядер, десятков тысяч графических карт, а общий размер кластера достигает десятков тысяч узлов. Столь масштабная нагрузка Spark означает, что полностью реализовать Spark в исходном виде непросто. Вот вопросы, над которыми мы думаем на практике. Следует ли использовать оператор для развертывания заданий Spark: статическое развертывание в автономном режиме или динамическое развертывание с помощью K8s Native? Как реализовать управление ресурсами на уровне клиента и контроль заданий Spark на K8s. Должно ли управление выполняться при отправке задания или при создании модуля? Как удовлетворить потребности Spark в планировании? При отправке заданий в Spark вызывает ли большое количество созданных модулей проблемы с планированием? Как нам создать периферийные возможности и упростить работу до и после миграции операционной архитектуры при такой крупномасштабной миграции операционной архитектуры?

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

Собственные облачные решения Spark и улучшения ядра

В настоящее время распространенные методы использования собственных облачных технологических решений Spark включают Spark Native и Spark Оператор Google с открытым исходным кодом. Оба метода достигают одной и той же цели и в конечном итоге вызывают инструмент командной строки Spark-submit. Разница в том, что оператор Spark от Google поддерживает более богатую семантику и внедряет более богатые функции, близкие к K8, с помощью оператора и Mutatingwebhook.

Существует два собственных облачных технологических решения Byte Spark. Первое — плавная миграция, при которой не требуется изменять метод отправки YARN. Оно передается в Kubelet или Gödel для планирования через Yodel. Второе — Spark Native Submit. отправлено в систему планирования через Arcee. Здесь необходимо объяснить следующие концепции: Gödel — это распределенная система планирования ресурсов, разработанная компанией Byte. Она содержит возможности планирования ресурсов YARN и Kubernetes и унифицирует пул ресурсов, квоты, планирование и изоляцию Kubernetes и YARN; самим байтом Оператор, который поддерживает типы заданий YARN и преобразует компоненты YARN RM и NM. Arcee — это единый облачный оператор больших данных, независимо разработанный Byte, который может более удобно управлять загрузками больших данных, такими как Spark и Flink. Разница между Yodel и Arcee заключается в том, что Yodel — это решение для больших данных в Gödel, «совместимое с протоколом YARN», а Arcee — это решение для больших данных в Gödel, которое «совместимо с протоколом K8s. Нижний уровень обоих». будет повторно использовать одни и те же технологии Gödel Scheduler и Kubelet.

Эта практика представляет собой полное облачное развертывание, которое осуществляется через основные возможности Arcee Operation, в основном включают управление жизненным циклом заданий, управление ресурсами заданий и некоторые функции настройки механизма.

Знакомство с Арси

Основная идея дизайна Arcee — двухуровневое управление заданиями , основанное на двухуровневой модели управления YARN — служба центрального управления AM, которая в основном отвечает за создание и поддержание заданий с большими данными, а затем AM создает и поддерживает вычисления. рабочие. В соответствии с заданием Spark Арси создает Драйвер, а Драйвер создает требуемого Исполнителя. Эта модель управления позволяет эффективно управлять и отображать статус заданий по работе с большими данными, а также настраивать стратегии управления заданиями. С другой стороны, это также может гарантировать, что вычислительный механизм имеет полный контроль над выполнением вычислительных заданий и имеет возможность корректировать использование ресурсов по мере необходимости.

Общая архитектура показана на рисунке. Arcee Operation содержит шесть модулей . Модуль Arcee CRD определяет два типа ресурсов: ArceeApplication и ArceeCommand: ArceeApplication используется для описания конкретных заданий, а ArceeCommand в основном описывает операции, используемые для заданий; используется внедрение и проверка конфигурации для приложения/пода; диспетчер приложений отвечает за управление жизненным циклом заданий ; для выполнения задач взаимодействия с большими данными, таких как Spark, с пакетными планировщиками.

Полный процесс отправки задания заключается в том, что Arnold (платформа машинного обучения) инициирует отправку задания Spark, вызывает Spark Client и заполняет необходимые параметры для отправки задания в K8s. В режиме Arcee клиент Spark использует встроенный клиент Arcee для создания приложения Spark ArceeApplication, которое предварительно обрабатывается Webhook и отправляется на APIServer. Далее Контроллер Arcee получает событие создания Приложения. Arcee ApplicationManager генерирует соответствующий статус задания и создает Драйвер согласно описанию в Приложении. Драйвер создает необходимых Исполнителей по требованию. Arcee продолжает отслеживать всех Исполнителей. также выполнит соответствующее внедрение конфигурации. Все модули драйвера и исполнителя в приложении будут храниться в PodsetManager Arcee для сбора статистики использования ресурсов и предоставления соответствующей информации другим модулям.

Искра на Арси

Spark на Arcee можно считать в определенной степени улучшением модели развертывания Spark Native. Основное отличие состоит в том, что встроенный клиент K8s в клиенте Spark заменен компонентом Arcee Client, отвечающим за управление загрузкой драйвера. становится оператором Arcee; Драйвер и Исполнитель становятся независимыми друг от друга. Имеют единое приложение Arcee для обслуживания. Arcee также обеспечивает управление жизненным циклом заданий, планирование защиты и другие сопутствующие функции.

Оптимизация искрового двигателя

На основе бизнес-практики, представленной в предыдущем разделе, в подсистеме Spark были внесены следующие улучшения. Ниже приведены случаи возникновения и решения каждой проблемы.

Исполнитель завершает работу корректно, чтобы избежать отклонений в состоянии MPS.

В настоящее время некоторые задания очистки базы данных Spark, требующие использования графического процессора, выполняются на K8 и смешиваются с онлайн-сервисами. Эти задания совместно используют устройство графического процессора на хосте через MPS (MPS — это технология многопроцессной службы, предоставляемая Nvidia, которая позволяет использовать разные процессы). Процесс выполняет мультиплексирование с пространственным разделением на графическом процессоре вместо мультиплексирования с временным разделением по умолчанию). Если один из нескольких общих процессов завершается при выполнении ядра, легко вызвать фатальное исключение на аппаратном уровне. что приведет к выходу других процессов на графическом процессоре, поэтому необходимо обеспечить корректный выход каждого процесса.

Запуск на K8 может привести к выселению или уничтожению контейнера из-за исчерпания ресурсов по определенным причинам планирования. Мы тщательно проанализировали ситуации выхода различных исполнителей и исполнителей из отношений драйвера, исполнителя, демона и работника. Реализуя плавный выход Executor в среде контейнера, перехватывая сигнал выхода и автоматически выполняя cudaDeviceSync, он предотвращает переход MPS в неопределенное состояние из-за автономного выхода.
Решите большое количество проблем с ожидающими модулями с помощью квоты

Spark поддерживает DynamicAllocation. При фактическом использовании пользователи обычно устанавливают для Max относительно большое значение. В настоящее время, чтобы предотвратить создание большого количества ожидающих модулей, Arnold выполняет проверку квоты на основе Max только тогда, когда квоты достаточно для запуска Max. Исполнители действительно могут это передать в K8s, иначе ждите в очереди в сервисе Arnold. Однако текущий недостаток использования Max для проверки квоты заключается в том, что можно легко растратить ресурсы. Если в очереди есть квота меньше Max, в соответствии с характеристиками текущей задачи, задача может быть запущена первой, чтобы использовать текущие ресурсы. Однако текущая логика проверки квоты приводит к тому, что эта часть ресурса будет отключена. непригоден для использования, и задача всегда находится в очереди на верхнем уровне. Эту проблему можно решить следующими средствами:
- Используйте параметр Spark.kubernetes.allocation.batch.size, чтобы контролировать количество подов, поднимаемых в каждом пакете;
- Ограничьте максимальное количество Pening Pods для одного задания с помощью параметра Spark.kubernetes.allocation.maxPendingPods;
- Однако настройка параметров по-прежнему не может решить проблему большого количества отправок в одной очереди в один и тот же период времени. Поэтому вы можете использовать Webhook для проверки квоты на основе очереди. Если квоты нет, создание модуля не удастся. . Spark обрабатывает исключение, добавляет стратегию создания Pod, экспоненциально увеличивает временной интервал создания и т. д., чтобы решить эту проблему.
Надежная оптимизация операций в сценариях нестабильных ресурсов со смешанным расположением

Приведем несколько примеров: часто обнаруживается, что модуль Spark Executor Pod ненормально отклоняется (UnexpectedAdmissionError) во время нескольких тестов нагрузочного тестирования во время планирования оптимизации стабильности ресурсов. Благодаря централизованному исследованию были исправлены многочисленные проблемы с состоянием гонки в серии логики Kubelet, а средний дневной смешанный ресурс достиг стабильного увеличения скорости заполнения лимита. Мы также провели серию настроек и преобразований, добавив несколько точек сбора индикаторов графического процессора, чтобы облегчить наблюдение за использованием ресурсов, и улучшили отказоустойчивость задачи к нестабильности ресурсов с помощью таких параметров, как «Черный список» и «Спекуляция».

Окружающая экологическая интеграция

В среде Spark на K8s журналы и индикаторы мониторинга также очень важны. Они могут помочь нам наблюдать за рабочим состоянием всего кластера, контейнера и задачи, быстро находить проблемы на основе журналов и мониторинга и своевременно их решать. . Поэтому система Trace постепенно создавалась в процессе нативизации облака Spark. Arcee Оператор и планировщик Gödel предоставляют некоторые индикаторы заданий, Spark предоставляет бизнес-индикаторы, а автономный компонент Metrics Collector предоставляет индикаторы физических компьютеров и индикаторы контейнеров. Что касается журналов, агент журналов, работающий на каждом узле, собирает журналы по указанным путям и автоматически загружает их на платформу журналов для анализа и запросов. Все индикаторы и журналы можно запрашивать в режиме реального времени на основе учебной платформы машинного обучения Arnold. Также предоставляются специальные таблицы данных. Пользователи могут выполнять запросы более высокого уровня в зависимости от своих потребностей, такие как создание отчетов, оптимизация заданий, обнаружение аномалий в заданиях. и т. д. . В то же время Arnold может своевременно получать обновления с помощью управления изображениями.

Практика рассуждения по модели Ванки

Наши текущие кластеры в основном разделены на офлайн-кластеры и онлайн-кластеры. Автономный кластер в основном ориентирован на задачи обучения и в основном ориентирован на производительность задач. Существуют такие карты, как V100, A100 и A800. Онлайн-кластер в основном ориентирован на онлайн-сервисы вывода. и фокусируется на задержке и пропускной способности, в основном на картах меньшего размера, таких как T4, A10 и A30, с десятками тысяч карт графического процессора.

главное противоречие

Основное противоречие на данный момент заключается в том, что квота автономного кластера полностью распределена. Логически говоря, ресурсы распределены, но еще есть много возможностей для улучшения общего использования автономного кластера. Кроме того, существует множество внутренних вычислительных потребностей, которые не были удовлетворены. Например, наш кластер похож на большой контейнер. Эти качественные задачи на самом деле похожи на камни. Камни могут быть полными, но между камнями все равно остается много промежутков. песок, поэтому наша постановка задачи состоит в том, чтобы найти эти пробелы и заполнить их песком, то есть найти подходящие многоразовые ресурсы и поставить подходящие задачи.

ресурс

Офлайн-кластер: некачественные задачи

Первый — низкоприоритетные задачи в автономном кластере. Эта часть находится в автономном кластере в целом и не чувствительна к задержкам. Мы используем эти простаивающие ресурсы с низким приоритетом и планируем низкоприоритетные задачи, когда есть свободное время. Тогда, когда появятся высокоприоритетные задачи, они будут вытеснены. В то же время это ресурсы всей карты, и их подача не имеет очевидных правил, поскольку сама офлайн-подача не имеет очевидных правил, а общий уровень изоляции относительно невысок.

Онлайн -> Оффлайн: Tide

Другая часть — это приливные ресурсы из онлайна в оффлайн. Эта часть требует кредитования простаивающих ресурсов онлайн-кластера в оффлайн-кластер. Мы реализуем это на основе Virtual-Kubelet. Эта часть также является целым карточным ресурсом, и его поставка — это. случайный. Существует очевидная закономерность взлетов и падений бизнеса. Когда онлайн-бизнес находится на пике своего развития, ресурсы освобождаются посредством автоматического масштабирования, а затем передаются в автономный кластер. Когда пик достигается, емкость снижается. будет снова расширен, и кластер исключит автономный модуль. Это средний уровень изоляции, автономный модуль должен работать на той же машине, но карту все равно можно изолировать.

Онлайн->Офлайн: обычное совместное размещение

Другая часть — это обычное совместное размещение ресурсов из онлайн-в офлайн-режим. Эта часть фактически означает, что мы предоставляем часть вычислительной мощности относительно малоиспользуемого графического процессора в онлайн-кластере оффлайн-кластеру. Основная причина в том, что некоторые модели. не используют всю карту и пусты. Вычислительные мощности можно использовать повторно, а общая реализация основана на Virtual-Kubelet + ByteCUDA + MPS.

ByteCUDA — это самостоятельно разработанный CUDA Hook. Он выполняет некоторую работу по изоляции памяти и мультиплексированию с временным разделением на верхнем уровне. MPS нижнего уровня улучшает общий уровень изоляции за счет мультиплексирования с пространственным разделением. То, что предоставляется в аренду, на самом деле является неинтегрированным ресурсом карты, то есть одну карту можно использовать для нескольких целей. Эта карта может иметь онлайн-задачи и офлайн-задачи. Преимущество в том, что объем поставок относительно стабилен. Эта часть службы не расширяется и не сжимается автоматически. Все они работают на одной карте и имеют самый высокий уровень изоляции.

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

Кроме того, MPS известен своей проблемой распространения ошибок. Упомянутая выше проблема решается плавным выходом. Из приведенных выше изображений мы видим, что пропускная способность онлайн до и после колокейшн практически не меняется, а задержка увеличивается примерно на 0,75 мс. На самом деле, это приемлемо. Уровень использования увеличился с первоначальных 10% до 70%. Это немного повлияло на общий доход, но уровень использования значительно улучшился.

Задача

После ресурсов идут задачи, которые мы называем песком. Во-первых, его спрос должен быть достаточно большим, иначе не придется «возиться». Кроме того, поскольку это сами по себе фрагментированные ресурсы, размер требуемых задач должен быть относительно умеренным и не может быть особенно большим. Также необходимо, чтобы эти задачи не могли сильно потреблять эти неизолированные ресурсы, такие как диски, сети и т. д., кроме того, задачи также должны иметь возможность адаптироваться к автоматическому расширению и сжатию ресурсов, поскольку эти ресурсы эластичны; ресурсы и должны автоматически использоваться при расширении задач. Ресурсам при сжатии это сжатие не помешает.

Автономные задачи рассуждения на основе Spark

На основании вышеуказанных требований к реализации задача автономного рассуждения на основе Spark была окончательно заблокирована. Во-первых, поскольку существует большое количество внутренних требований к автономному рассуждению, спрос достаточно велик, кроме того, процесс задачи рассуждения относительно прост; , и между Исполнителями ничего нет. Для нужд связи нет необходимости в онлайн-картах, RDMA и т. д., кроме того, большой объем данных фактически хранится в HDFS и Hive, что естественно совместимо со Spark; в то же время нам также необходимо использовать возможности Spark по обработке и распределению данных, а также возможность динамического расширения и сокращения емкости на основе динамического распределения;

Сборка SDK

После блокировки задачи нам нужно максимально инкапсулировать лучшие практики. Выше приведена схематическая диаграмма SDK, который представляет собой Tide Box, который поддерживает общие выводы моделей, такие как Pytorch и Tensorflow, а также поддерживает. Контрольные точки на уровне раздела. Таким образом, нет необходимости повторять вычисления при изъятии ресурсов, что позволяет избежать потери вычислительной мощности и улучшить общее использование ресурсов за счет поддержки пакетной обработки.

Конструкция платформы

После сборки SDK построение платформы также является очень важным аспектом. Мы не хотим, чтобы пользователи выполняли команды напрямую через Spark Submit, которым неудобно управлять. Таким образом, платформа машинного обучения Arnold используется в качестве основы для унифицированного управления этими ресурсами. На основе разработки и отладки Notebook необходимые переменные могут быть установлены заранее. Пользователи также могут выполнять отладку за один шаг без ручного поиска «Отправить». Относительно удобно переключать ресурсы в разных сценариях одновременно. Также более гибко.

Кроме того, метод запуска задачи может поддерживать несколько методов, таких как запуск восходящих событий, запуск по времени, запуск API и т. д., что облегчает использование пользователем. Например, если вы хотите организовать некоторые требования к конвейеру или автоматизации пользователей, вы можете гибко реализовать их с помощью этих методов. Кроме того, очень важно выполнение и обслуживание задач. Он может реализовать возможность просмотра исторических задач и возврата проблем одним щелчком мыши.

Сопоставление задач и ресурсов

Существует много типов задач вывода Spark. Одна из них — внезапный экстренный спрос. Эта часть потребности в ресурсах относительно велика, время также срочное, и для этой части нам нужно использовать автономную низкую оптимизацию. а Tide — это ресурс с более совершенными картами и более мощной вычислительной мощностью. Кроме того, необходимо группировать задачи с возвратом, которые требуют регулярных повторных запусков, имеют относительно большие требования к ресурсам и среднюю срочность задач, и использовать эти ресурсы в периодических и обычных смешанных развертываниях. Рутинные задачи могут быть ежедневными и требовать средних ресурсов. Для их поддержки мы будем использовать относительно более стабильный и стабильный запас обычных ресурсов совместного размещения.

Пиковое состояние от онлайн-кредитования до офлайн-графика составляет около 10 000+ Tidal GPU; обычное смешанное развертывание составляет около 20 000+. Эта часть также связана с оффлайн-смешанным развертыванием, общее использование удвоилось, каждый раз приходится выполнять около 100+ задач автономного вывода; день и один Максимальный лимит задачи составляет 5 000+ графических процессоров. Мы активно ограничиваем эту часть, иначе пользователи могут увеличить ее еще больше, в результате чего все ресурсы будут заняты. Типичная задача очистки базы данных требует стабильных ресурсов для работы в течение 9,5 дней. Благодаря этому эластичному ресурсу график был сокращен до 7,5 часов.

прогноз на будущее

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

ByteDance Spark поддерживает практику вывода модели Wanka