Как выбрать правильную конфигурацию кластера для запуска приложений Databricks без лишних затрат

Databricks становится популярной платформой для анализа больших данных в общедоступных облаках. Как и в случае с большинством аналитических платформ, управлять их стоимостью сложно и требует более глубоких знаний о его функциях. Управление затратами в Databricks в значительной степени зависит от рентабельности кластеров. Для простоты мы ориентируемся на платформу Databricks в Azure, но ее легко перевести на другие облачные платформы. Чтобы получить представление об управлении кластером в Azure Databricks, вы можете просмотреть официальную документацию: кластеры, настроить кластеры и управлять политиками кластера.

Цены на Azure Databricks

Прежде чем узнавать больше о кластерах, важно узнать больше о ценах на Azure Databricks. Databricks имеет два ценовых уровня: стандартный и премиальный. Сервис премиум-уровня предоставляет расширенные функции безопасности, которые необходимы для управления контролируемым доступом к его функциям. Этот уровень стоит дороже, чем стандартный уровень, но его ставка зависит от типа кластера. Посмотрите на рисунок 1, чтобы получить представление о ценах на различные типы кластеров. Ожидайте немного других цен для других облачных операторов.

Azure Databricks взимает плату за виртуальные машины (ВМ), подготовленные в кластерах и модулях Databricks (DBU), в зависимости от выбранного экземпляра виртуальной машины. DBU - это единица вычислительной мощности в час, которая используется для посекундной оплаты. DBU зависит от размера и типа экземпляра в Azure Databricks. Экземпляры - это типы узлов в зависимости от их вычислительных ресурсов, например ЦП и ОЗУ.

Помимо платы за виртуальную машину и DBU, вы будете платить за следующее:

  • Затраты на хранение BLOB-объектов для размещения файловой системы Databricks (DBFS), в которой хранятся все файлы
  • Затраты на виртуальные машины Azure для экземпляров, используемых в кластерах для выполнения рабочих нагрузок.
  • Затраты на управляемые диски Azure для дисков, подключенных к каждому рабочему узлу, включая корневой диск экземпляра объемом 30 ГБ, подключенный к каждой виртуальной машине, и диск данных объемом 150 ГБ, подключенный к контейнеру среды выполнения Databricks на каждой виртуальной машине.
  • Стоимость общедоступного IP-адреса, поскольку каждая виртуальная машина кластера имеет динамический общедоступный IP-адрес, если заказчик не использует функцию «Нет общедоступного IP-адреса».

Есть несколько других затрат, связанных с пропускной способностью сети и дополнительным хранилищем, в зависимости от типа приложений, поддерживаемых в Databricks.

Конфигурации кластера, влияющие на цену

Кластеры являются основной движущей силой затрат на работу платформы Databricks. На рисунке 2 показаны параметры конфигурации (отмечены красными прямоугольниками), которые сильно влияют на стоимость работы кластера.

Кластеры в Azure Databricks можно создавать двумя способами: с помощью пользовательского интерфейса кластеров / интерфейса командной строки / API и интерфейса пользовательского интерфейса / интерфейса командной строки / API заданий. Если вы создаете кластер с использованием Clusters UI / CLI / API, он называется универсальным кластером (на рисунке 2 показано создание универсального кластера с использованием Cluster UI). Этот тип кластера является постоянным, может быть перезапущен вручную и может использоваться несколькими пользователями.

Когда вы создаете задание с помощью Jobs UI / CLI / API, у вас есть возможность создать новый кластер заданий (на экране 3 показано создание кластера заданий с помощью Job UI). Обратите внимание, что вы также можете использовать существующий кластер (см. Рисунок 4). Этот тип кластера сохраняется, пока задания активно выполняются, и позволяет запускать (запланированные) автоматические задания с изоляцией. Стоимость вычислений для запуска кластера заданий значительно меньше. Затраты на вычисления для запуска кластера заданий с малым временем выполнения дешевле.

Мы кратко опишем важные параметры следующим образом.

Кластерный режим

Существует три режима кластера: одиночный узел, стандартный, высокий уровень параллелизма (см. Рисунок 5). Кластер с одним узлом имеет только узел драйвера, на котором выполняются все команды. Кластеру стандартного режима требуется по крайней мере один рабочий узел Spark в дополнение к узлу драйвера. Кластер с высоким уровнем параллелизма - это многоузловой кластер, который обеспечивает детализированное совместное использование для максимального использования ресурсов.

Версия во время выполнения

Среда выполнения - это набор основных компонентов, которые работают в ваших кластерах. Среды выполнения, которые актуальны для типичных продуктовых групп, - это среда выполнения Databricks, среда выполнения Databricks для машинного обучения и Databricks Light (на рисунке 6 показаны различные варианты среды выполнения для кластера).

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

Автомасштабирование

Автомасштабирование позволяет добавлять и удалять рабочие узлы по мере изменения рабочей нагрузки. Когда он включен, Databricks автоматически выбирает соответствующее количество рабочих, необходимых для запуска задания Spark по мере выполнения задания. Автоматическое масштабирование позволяет выполнять рабочие нагрузки быстрее по сравнению со статическим кластером с недостаточной подготовкой и снижает затраты по сравнению со статическим кластером с избыточной подготовкой. При использовании автомасштабирования необходимо указать минимальное и максимальное количество узлов в кластере. Значения по умолчанию - 2 и 8 соответственно (см. Рисунок 7). Когда задание запускается, оно начинается с минимального количества рабочих узлов, но по мере выполнения задания и увеличения числа задач количество рабочих узлов может увеличиваться до максимального значения.

Время завершения параметра применимо для универсальных стандартных или одноузловых кластеров. Когда вы создаете кластер с помощью Cluster UI / CLI / Rest API, вы указываете период бездействия в минутах, после которого вы хотите, чтобы кластер завершил работу (или выключился). Databricks автоматически завершает работу кластера, если время, прошедшее с момента последней команды, выполненной в кластере, превышает период бездействия. Команды, которые поддерживают кластер активным, - это задания Spark, структурированная потоковая передача, вызовы JDBC и т. Д. Команды Bash не учитываются. Значение по умолчанию составляет 120 минут и может быть изменено, когда кластер не работает (см. Рисунок 7).

Тип экземпляра

Databricks предоставляет набор типов экземпляров для узлов на основе выделенных им вычислительных ресурсов, ЦП, ОЗУ, хранилища и т. Д. (На рисунке 7 показан конкретный тип экземпляра). Распространенные типы экземпляров:

  • Универсальные, со сбалансированным соотношением ресурсов ЦП и памяти по сравнению с другими типами экземпляров.
  • Оптимизированный для вычислений, обеспечивающий больше ЦП по сравнению с другими типами инстансов
  • GPU-ускорение, обеспечивающее графические процессоры
  • Оптимизирован для памяти, что обеспечивает больший объем оперативной памяти по сравнению с другими типами экземпляров.
  • Оптимизация хранилища, обеспечивающая ускорение дельта-кеша

Подходы к снижению затрат

Мы перечисляем некоторые важные подходы к снижению затрат, связанных с кластерами.

Уровень рабочей области

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

Тип кластера

  • Универсальные кластеры оптимальны для анализа и разовой работы. Если вы занимаетесь исследовательской работой и велика вероятность того, что работа может быть отброшена после того, как работа будет выполнена, вам следует выбрать универсальный кластер.
  • Кластеры заданий оптимальны для производственных и повторяющихся рабочих нагрузок. Когда вы используете стабильную записную книжку, которую не нужно запускать в интерактивном режиме или в производственном / тестовом конвейере, вам следует использовать задания с новыми кластерами заданий. Обычно выполнение рабочих нагрузок с использованием кластеров заданий обходится примерно в 3 раза дешевле, чем универсальные кластеры (см. Рисунок 1). Может возникнуть соблазн использовать малое время выполнения для снижения затрат, но избегайте этого, если вы не уверены в ресурсных требованиях рабочей нагрузки.
  • Если при выполнении задания ваша рабочая нагрузка не требует дополнительных функций, таких как автоматическое масштабирование, вы должны выбрать для времени выполнения задание Light Light, поскольку оно стоит в 6 раз меньше по сравнению с универсальными кластерами (см. Рисунок 1). Запуск тестовых заданий - это сценарий, в котором вы можете использовать легкую среду выполнения.

Кластерный режим

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

Время выполнения

  • Если вы используете задания Databricks для выполнения своей рабочей нагрузки Spark без дополнительных функций, таких как дельта-озеро, автоматическое масштабирование, расширенные источники / приемники данных Azure, вам следует использовать облегченную среду выполнения.
  • Вам следует избегать использования среды выполнения Databricks для машинного обучения, если вы не используете широко функции машинного обучения, предоставляемые средой выполнения. Для интерактивной рабочей нагрузки и расширенных заданий выберите стандартную среду выполнения.

Автомасштабирование

  • Специальное использование обычно имеет большие различия. Вам следует начинать с малых чисел, особенно с мин. несколько узлов. Если вы заметили, что рабочая нагрузка выполняется медленно, измените конфигурацию.
  • Вы можете оставить автоматическое масштабирование для предсказуемых серийных производственных заданий. Если рабочая нагрузка имеет непредсказуемые изменения, добавьте более высокое значение для верхнего предела.
  • Вам следует избегать автомасштабирования для потоковых рабочих нагрузок, поскольку автомасштабирование в структурированной потоковой передаче всегда масштабируется до максимального количества узлов по умолчанию (350 узлов). Для потоковых заданий отключите автомасштабирование и запустите его как задание Databricks в новом кластере заданий с бесконечным числом повторных попыток.
  • Оставлять 120 минут на период бездействия - не лучший вариант. Вы должны начать с низких значений, то есть не слишком низких, например, 30 минут. Иногда небольшой период бездействия нежелателен, поскольку ваш ноутбук выполняет длительный процесс, прежде чем выполнять какой-либо анализ. Например, вам нужно обработать большой объем данных перед анализом / моделированием. В таком случае рассмотрите возможность разделения записной книжки на отдельные записные книжки, чтобы лучше управлять потоком.

Тип экземпляра

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

Размерное упражнение

Начните с небольшого кластера, такого как универсальный стандартный DS4 v2, с 2–8 рабочими узлами с виртуальными машинами, соответствующими классу рабочей нагрузки, как описано в предыдущих пунктах. Вы можете выбрать более крупный экземпляр, например. г., DS5 v2 для узла драйвера. Выполняйте сквозные тесты на подмножестве данных, измеряя при этом ЦП, память и операции ввода-вывода, используемые кластером на агрегированном уровне.

Если задачи связаны с ЦП, добавьте больше ядер, добавив больше узлов. Если задачи связаны с сетью, используйте меньшее количество компьютеров с SSD-накопителем большего размера, чтобы уменьшить размер сети и повысить производительность удаленного чтения. Если задачи I / 0 связаны, используйте экземпляры с большим объемом памяти. После определения базового размера кластера масштабируйте кластер для репрезентативной рабочей нагрузки.

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

Вам следует использовать автомасштабирование, если вы не уверены в количестве рабочих. Возможность автоматического масштабирования кластера является наиболее важной для интерактивных заданий. Измерьте количество трудоемких задач. Настройте экземпляры по количеству задач. Обычно каждое ядро ​​может одновременно поддерживать 2–3 задачи. Как только вы узнаете базовое количество задач, вы можете использовать автомасштабирование с более высоким буфером для Max Workers.

Используйте меньшее количество экземпляров большой емкости вместо множества меньших экземпляров для пакетных заданий, так как это уменьшает перетасовку. Чтобы определить размер кластера, возьмите% набора данных → кешируйте его → посмотрите, сколько памяти используется → экстраполировать на остальные данные. Также обратите внимание на размер задач при перемешивании и сравните это с желаемой пропускной способностью.

Замечания

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