Рекомендации по настройке вычислений

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

• Какой тип пользователя будет использовать вычислительные ресурсы? Типы заданий, которые может запускать специалист по обработке и анализу данных, а также их требования, отличаются от таковых в работе инженера данных или аналитика данных.
• Какие типы рабочих нагрузок будут выполняться пользователями на вычислительных ресурсах? Например, требования к заданиям извлечения, преобразования и загрузки (ETL) пакетов, скорее всего, будут иметь отличия от аналитических рабочих нагрузок.
• Какой уровень соглашения об уровне обслуживания необходим?
• Какие у вас ограничения бюджета?

В этой статье приведены рекомендации по настройке вычислений для различных сценариев на основе этих рекомендаций. В этой статье также рассматриваются конкретные функции вычислений Azure Databricks и рекомендации, которые следует учитывать для этих функций.

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

Функции вычислений

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

Вычисления всех назначений и вычисления заданий

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

Вычисления с одним узлом и несколькими узлами

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

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

Экземпляры по требованию и точечные

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

Защита точечных экземпляров от прерывания с помощью вывода из эксплуатации

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

Чтобы устранить эти проблемы, можно включить выключение на вычислительные ресурсы. Дополнительные сведения см. в разделе "Вывод из эксплуатации" экземпляров.

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

Примечание.

Автоматическое масштабирование вычислений имеет ограничения, ограничивающие размер кластера для структурированных рабочих нагрузок потоковой передачи. Databricks рекомендует использовать разностные динамические таблицы (Delta Live Tables) с расширенным автомасштабированием для потоковых рабочих нагрузок. См. раздел Что такое расширенное автомасштабирование?.

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

• Автомасштабирование обычно снижает затраты по сравнению с вычислением фиксированного размера.
• Рабочие нагрузки автомасштабирования могут выполняться быстрее по сравнению с не подготовленными вычислительными ресурсами фиксированного размера.
• Некоторые рабочие нагрузки несовместимы с вычислениями автомасштабирования, включая задания spark-submit и некоторые пакеты Python.
• При использовании вычислительных ресурсов с одним пользователем пользователи могут обнаружить, что автомасштабирование замедляет разработку или анализ, если минимальное количество рабочих ролей установлено слишком низко. Это связано с тем, что выполняемые команды или запросы часто находятся в нескольких минутах от времени, в течение которого вычислительные ресурсы неактивны и могут сократиться, чтобы сэкономить на затратах. При выполнении следующей команды диспетчер вычислений попытается увеличить масштаб, за несколько минут при извлечении экземпляров из поставщика облака. В течение этого времени задания могут выполняться с недостаточными ресурсами, замедляя получение результатов. При увеличении минимального количества рабочих ролей также увеличивается стоимость. Это еще один пример, в котором стоимость и производительность должны быть сбалансированы.
• Если используется кэширование Delta, важно помнить, что все кэшированные данные на узле утрачиваются при завершении работы этого узла. Если сохранение кэшированных данных важно для рабочей нагрузки, рассмотрите возможность использования вычислений фиксированного размера.
• Если у вас есть вычислительные ресурсы задания, на которых выполняется рабочая нагрузка ETL, иногда вы можете соответствующим образом масштабировать вычислительные ресурсы при настройке, если вы знаете, что задание вряд ли изменится. Однако автомасштабирование обеспечивает гибкость при увеличении размеров данных. Кроме того, следует отметить, что оптимизированное автомасштабирование может сократить расходы с длительными заданиями, если вычислительные ресурсы не используются или ожидают результатов другого процесса. Тем не менее, ваше задание может столкнуться с незначительными задержками, так как вычислительные ресурсы пытаются масштабироваться соответствующим образом. Если у вас есть жесткие соглашения об уровне обслуживания для задания, вычисление фиксированного размера может быть лучшим выбором или рассмотрите возможность использования пула Azure Databricks для снижения времени запуска вычислений.

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

Пулы

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

Версии Databricks Runtime

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

Для вычислений заданий, выполняющих операционные рабочие нагрузки, рекомендуется использовать версию среды выполнения Databricks(LTS). Использование версии LTS обеспечит отсутствие проблем совместимости и может тщательно протестировать рабочую нагрузку перед обновлением. Если у вас есть расширенный вариант использования машинного обучения, рассмотрите специализированную версию Databricks Runtime.

Политики вычислений

Политики вычислений Azure Databricks позволяют администраторам применять элементы управления при создании и настройке вычислений. Databricks рекомендует использовать политики вычислений для применения рекомендаций, рассмотренных в этом руководстве.

Автоматическое завершение

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

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

Внимание

Неактивные вычисления продолжают накапливать расходы на DBU и облачные экземпляры в течение периода бездействия до завершения работы.

Сбор мусора

Хотя это может быть менее очевидным, чем другие рекомендации, рассмотренные в этой статье, внимание к сборке мусора может помочь оптимизировать производительность заданий на вычислительных ресурсах. Предоставление большого объема ОЗУ может повысить эффективность работы заданий, но также может привести к задержкам во время сбора мусора.

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

Управление доступом вычислений

Вы можете настроить два типа разрешений вычислений:

• Разрешение на создание неограниченного кластера позволяет пользователям создавать вычислительные ресурсы.
• Разрешения на уровне вычислений управляют возможностью использования и изменения определенного вычислительных ресурсов.

Дополнительные сведения о настройке разрешений вычислений см. в статье "Управление доступом к вычислительным ресурсам".

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

Общие сведения о разрешениях вычислений и политиках вычислений важны при выборе конфигураций вычислений для распространенных сценариев.

Теги вычислений

Теги вычислений позволяют легко отслеживать стоимость облачных ресурсов, используемых различными группами в организации. Теги можно указать как строки "ключ-значение" при создании вычислений, а Azure Databricks применяет эти теги к облачным ресурсам. Дополнительные сведения о применении тегов см. в статье о применении тегов с помощью политик .

Рекомендации по размеру вычислений

Azure Databricks запускает один исполнитель на каждый рабочий узел. Таким образом, в контексте архитектуры Azure Databricks термины "исполнитель" и "рабочая роль" взаимозаменяемы. Люди часто думать о размере вычислительных ресурсов с точки зрения количества рабочих ролей, но существуют и другие важные факторы, которые следует учитывать:

• Общее число ядер (вычислений) исполнителя: общее количество ядер по всем исполнителям. Это определяет максимальный параллелизм вычислений.
• Общая память исполнителей: общий объем ОЗУ по всем исполнителям. Это определяет объем данных, которые можно хранить в памяти, прежде чем сбрасывать их на диск.
• Локальное хранилище исполнителя: тип и объем локального дискового хранилища. Локальный диск в основном используется при операциях сброса при перемешивании и кэшировании данных.

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

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

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

Между числом рабочих ролей и размером экземпляров рабочих ролей существует баланс. Вычисление с двумя рабочими рабочая роль, каждая из которых имеет 40 ядер и 100 ГБ ОЗУ, имеет те же вычислительные ресурсы и память, что и восемь рабочих вычислений с 10 ядрами и 25 ГБ ОЗУ.

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

Примеры размера вычислений

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

Анализ данных

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

Кластер D, скорее всего, обеспечит наихудшую производительность, так как большее количество узлов с меньшим объемом памяти и хранилище потребует большего перемешивания данных для завершения обработки.

Для аналитических рабочих нагрузок, скорее всего, потребуется многократное считывание одних и тех же данных, поэтому рекомендуемые типы рабочих ролей — хранилище с включенным кэшем Delta.

Для аналитических рабочих нагрузок рекомендуется использовать следующие дополнительные функции:

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

Возможности, которые, скорее всего, не принесут пользы:

• Автомасштабирование хранилища, так как этот пользователь, вероятно, не будет производить большой объем данных.
• Общие вычислительные ресурсы, так как это вычисление предназначено для одного пользователя.

Базовые пакетные ETL

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

Рекомендуется использовать типы рабочих ролей, оптимизированные для вычислений; это будет дешевле, и эти рабочие нагрузки, скорее всего, не потребуют значительных объемов памяти или хранилища.

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

Следующие возможности, скорее всего, не принесут пользы:

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

Сложные пакетные ETL

Более сложные задания ETL, такие как обработка, требующая объединения и соединения в нескольких таблицах, скорее всего, будут работать наилучшим образом при максимальном снижении количества данных в случайном порядке. Так как сокращение числа рабочих ролей в вычислительных ресурсах поможет свести к минимуму перетасовку, следует рассмотреть меньшие вычислительные ресурсы, такие как Cluster A, на следующей схеме над большими вычислительными ресурсами, такими как Cluster D.

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

Как и для простых заданий ETL, рекомендуется использовать типы рабочих ролей, оптимизированные для вычислений; это будет дешевле, и эти рабочие нагрузки, скорее всего, не потребуют значительных объемов памяти или хранилища. Кроме того, как и простые задания ETL, основной вычислительный компонент, который следует учитывать, заключается в уменьшении времени запуска вычислений и уменьшении общего времени выполнения при выполнении конвейеров заданий.

Следующие возможности, скорее всего, не принесут пользы:

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

Обучение моделей машинного обучения

Так как начальные итерации обучения модели машинного обучения часто экспериментальны, меньшее вычисление, например Cluster A, является хорошим выбором. Меньшие вычислительные ресурсы также снижают влияние перетасовок.

Если стабильность является проблемой или для более сложных этапов, более крупные вычислительные ресурсы, такие как Кластер B или C, могут быть хорошим выбором.

Не рекомендуется использовать большие вычислительные ресурсы, такие как Кластер D, из-за затрат на перетасовку данных между узлами.

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

Дополнительные функции, рекомендуемые для рабочих нагрузок машинного обучения, включают:

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

Возможности, которые, скорее всего, не принесут пользы:

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

Распространенные сценарии

В следующих разделах приведены дополнительные рекомендации по настройке вычислений для распространенных шаблонов использования вычислений:

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

Вычисление с несколькими пользователями

Сценарий

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

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

Это вычисление всегда доступно и совместно используется пользователями, принадлежащими группе по умолчанию. Включение автоматического масштабирования позволяет вычислительным ресурсам увеличивать и уменьшать масштаб в зависимости от нагрузки.

У пользователей нет доступа к запуску и остановке вычислений, но начальные экземпляры по запросу сразу же доступны для реагирования на запросы пользователей. Если для запроса пользователя требуется больше ресурсов, автомасштабирование автоматически подготавливает дополнительные узлы (в основном, точечные экземпляры) для размещения рабочей нагрузки.

Azure Databricks имеет и другие возможности для дальнейшего улучшения вариантов использования в нескольких клиентах:

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

Такой подход позволяет снизить общую стоимость следующим образом.

• Использование общей вычислительной модели.
• Использование сочетания экземпляров по запросу и точечных экземпляров.
• Использование автомасштабирования, чтобы избежать оплаты за недоиспользуемые вычисления.

Специализированные рабочие нагрузки

Сценарий

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

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

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

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

Рабочие нагрузки пакетной службы

Сценарий

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