Экономика должна быть экономной: о стоимости Spark-приложений

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

Экономика Big Data систем: распределенная разработка и операционные затраты

Организация эффективных с экономической точки зрения конвейеров обработки данных (data pipeline) лежит в сфере ответственности инженера Big Data. Однако, на практике не так-то просто объективно оценить адекватность использования вычислительных ресурсов для распределенных приложений. В случае Apache Spark это особенно актуально, т.к. этот Big Data фреймворк упрощает обработку огромных объемов информации, скрывая внутри себя сложность распределенных вычислений и позволяя разработчику оперировать распределенным набором данных как коллекцией объектов в локальной памяти. При этом Spark не гарантирует, что он сможет линейно масштабироваться с увеличением объема данных и будет автоматически оптимизирован, чтобы использовать предоставленные вычислительные ресурсы с максимальной эффективностью. Таким образом, нередки ситуации, когда не слишком опытные разработчики создают распределенные Spark-задания как локальные Java-приложения, не заботясь об эффективности использования ресурсов и экономике Big Data проекта, например, выделяя сотни виртуальных ядер и ГБ памяти в PaaS-сервисе.

Однако, время выполнения задания, умноженное на выделенные ресурсы (ЦП и ОЗУ), прямо пропорционально экономическим затратам, и это весьма значимо в денежном выражении, особенно в облачной инфраструктуре. Получается неэффективные задания занимают ресурсы дольше, чем необходимо или занимают больше ресурсов, чем это нужно на самом деле, тратя их впустую во время выполнения. Регулярное повторение таких трат приводит к росту постоянных операционных затрат (OPEX, Operational Expenditure).

Напомним, при выполнении в кластере каждое Spark- задание требует:

процесс, называемый драйвером, (driver) который выполняет весь Java-код;
один или несколько процессов-исполнителей (executor), которые будут выполнять весь код, определенный внутри преобразований и действий со структурами данных этого фреймворка (RDD, датасет, датафрейм).

Это означает, что в реальном кластере будут одновременно работать разные JVM и часто на разных узлах: по одной для драйвера и по одной для каждого исполнителя [2]. Поэтому экономика Spark-приложения тесно связана с техническими особенностями этого Big Data фреймворка.

Как оптимизировать экономику Spark-приложений: 3 простых совета

Снизить стоимость выполнения Spark-приложений и повысить общую эффективность использования Big Data инфраструктуры позволят следующие простые мероприятия, которые, как и любые процедуры мониторинга и контроля, следует проводить на регулярной основе [1]:

сохраняя веру в человечество и технологии, помните: все врут – в т.ч. ваши Big Data разработчики, которые заявляют о максимально оптимальной архитектуре, бизнес-логике, используемых структурах данных и настройке конфигурационных параметров. На практике тюнинг распределенных приложений является весьма длительным и утомительным процессом, который требует множества итераций, моделирования различных сценариев и тщательного сбора данных о производительности. Большинство разработчиков стремятся избегать этой однообразной и не слишком творческой работы, если она официально не прописана в контракте или плане проекта. Поэтому сделайте оптимизацию Spark-приложений неотъемлемой частью процесса разработки.
В продолжение предыдущего совета, выберите параметр, который хотите улучшить и определитесь, насколько. Сделать это поможет эталонный тест с определенным набором данных и вычислительными ресурсами.
Проводите настройку Spark-заданий, определяя предельный запас прочности приложения. Например, начиная с определенного количества ресурсов с их постепенным уменьшением, чтобы найти критическую точку, когда ресурсов не хватит и приложение даст сбой. Такая практика особенно полезна в случае нерегулярной нагрузки, когда объем входных данных для аналитической обработки меняется в течение суток. При этом стоит убедиться, что сбой возник по причине внешних сигналов (объема входных данных), а не из-за отказа конкретного узла Spark-кластера.

Пример оптимизации Spark-приложения и 5 рекомендаций руководителю

В качестве практического примера рассмотрим задание приема данных из 100 исполнителей Spark с 20 ГБ ОЗУ каждый, то есть всего 2 ТБ ОЗУ. Это приложение носило регулярный характер: его планировалось запускать ежедневно длительностью около 30 минут, что стоило примерно 200 долларов за запуск. Команда разработчиков пыталась уменьшить объем выделенной памяти исполнителя, но столкнулась с проблемами OutOfMemory. Количество исполнителей было настолько велико, что лишь небольшое улучшение было замечено после увеличения общего параллелизма. Дальнейший анализ показал, что только один из исполнителей фактически работал первые 28 минут из 30 и ему требовалось 20 ГБ ОЗУ для выполнения своих задач. Внеся изменения в исходный код и структуру файлов, разработчики получили Spark-задание с линейным масштабированием и завершением всего за 12 минут только с 20 исполнителями, имеющими 20 ГБ ОЗУ каждый. В итоге его стоимость запуска этого Spark-приложения снизилась более чем в 10 раз, до 16 долларов, что составило экономия 67000 долларов в год!

Таким образом, каждый ИТ-руководитель, управляющий проектами, системами или приложениями на базе Apache Spark должен помнить о связанных с ними расходах и запрашивать у разработчиков с инженерами Big Data подробные отчеты о процессах настройки производительности перед запуском решения в production, например, [1]:

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

На первый взгляд все эти рекомендации кажутся довольно дорогостоящими дополнительными мероприятиями, но это капитальные затраты (CapEx, CAPital EXpenditure – единоразовые инвестиции на приобретение серьёзных активов), которые положительно влияют на операционные расходы (OPEX) [1].

Разобраться с экономикой и технологиями инженерии больших данных и разработки распределенных приложений Apache Spark вы сможете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Смотреть расписание

Записаться на курс

Источники