Apache Spark в Kubernetes — уроки, извлеченные из запуска миллионов исполнителей Spark (блоки данных…

В этой статье кратко изложена захватывающая сессия, организованная Чжоу Цзяном и Ааруной Годти из Apple на Data+AI Summit 2022. В этой сессии Чжоу и Ааруна рассказали о том, как они построили централизованный кластер Apache Spark на Kubernetes, который обрабатывает более 380 000 заданий Spark в день для поддерживать рабочий процесс аналитики и эксперименты ученых в Apple.

Оригинальный обмен: видео

С одного взгляда

Различные шаблоны рабочей нагрузки (широкий, глубокий, широкий и глубокий) предъявляют различные требования к ресурсам и обработке в кластере.
Apple предоставляет единый интерфейс (плоскость управления), совместно используемый локальным облаком и облаком, принадлежащим клиенту, с быстрым и простым процессом адаптации кластера.
Большое количество одновременных приложений Spark создает огромную нагрузку на кластер Kubernetes. Чтобы назвать несколько с решениями:
Масштабирование рабочей нагрузки Kubernetes для Spark: увеличение размера хранилища ETCD, автоматическое масштабирование кластера, класс приоритета и вытеснение, использование IPv6.
Spark Orchestration (с оператором) в масштабе: глобальный максимальный предел одновременных заданий, групповое планирование, тайм-ауты на стороне оператора, сокращение истории переходов.
(Великолепно!) Используйте метрики Spark из предыдущих запусков, чтобы предоставить рекомендации по ресурсам для будущего запуска того же задания.
Включение функции «Динамическое распределение» для лучшего использования ресурсов.
Сервер истории увеличения масштаба — хранит агрегированное представление самых последних заданий.

Платформа данных в Apple

Платформа данных Apple по своему дизайну допускала различные варианты использования из разных дисциплин и ролей в компании, например, большие данные — инженер данных, специалист по данным, инженер по машинному обучению и бизнес-аналитика — бизнес-аналитики. Масштабы, которых они достигли в 2022 году, впечатляют!

В MSAI мы разбиваем вариант использования «больших данных» на «большие данные» и «науку», чтобы лучше соответствовать требованиям для инженера по данным и специалиста по данным. Благодаря этой структуре мы можем предоставить лучшие наборы инструментов и ресурсов в соответствии с их конкретными потребностями. Представьте себе разницу между «вычислением индекса производительности пользователя» и «умным составлением электронной почты».

Жизненный цикл приложения E2E Spark

Нет ничего особенного в инфраструктуре E2E, которая гарантирует безопасное, рутинное развертывание кода с некоторым видом интеграционного тестирования, мониторинга и инструментов безопасности. Это серьезная работа, проделанная для процветания бизнеса платформы данных.

Запуск заданий Spark в масштабе (с Kubernetes)

Типы рабочей нагрузки Spark

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

Spark Orchestrator спасает положение

При обучении вложений графа арендаторов у нас больше всего проблем с обработкой «широкого» шаблона рабочей нагрузки — по сути, нам нужно построить десятки тысяч «графов арендаторов», которые сильно различаются по размеру. Хотя количество пользователей может быть разным (в 1000 раз), фактическое время построения графика на самом деле отличается всего на пару часов.

Пара проблем, с которыми MSAI столкнулась при обработке «широкой» рабочей нагрузки:

Накладные расходы: разница во времени процесса меньше, чем ожидалось, доказывает, что накладные расходы могут занимать значительную часть времени процесса.
Планирование заданий и создание очереди: HDInsights не предоставляет внешний планировщик, что означает, что внутренний планировщик YARN или очередь сеансов Livy используются для буферизации «скачкообразного трафика». (и работает плохо)
Наблюдаемость: из-за требований соответствия обработки пользовательского контента, журналы, метрики не легко доступны.

Параллелизм заданий и управление ресурсами для масштабирования

Платформа данных Apple сделала очень хороший выбор дизайна для использования внешнего планировщика, который в значительной степени решает некоторые проблемы, с которыми мы сталкивались, используя более старомодную настройку. Используя Spark Orchestrator, Apple выигрывает от нескольких аспектов:

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