Рекомендации: Конфигурация кластера

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

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

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

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

Функции кластера

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

Кластеры всех целей и кластеры заданий

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

Режим кластера

Azure Databricks поддерживает три режима кластера: Стандартный, высокий параллелизм и один узел. Большинство обычных пользователей используют кластеры уровня "Стандартный" или "один узел".

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

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

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

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

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

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

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

Пулы

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

Версии Databricks Runtime

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

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

Политики кластера

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

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

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

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

Важно!

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

Сборка мусора

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

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

Управление доступом к кластеру

Можно настроить два типа разрешений кластера:

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

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

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

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

Теги кластера

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

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

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

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

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

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

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

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

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

Примеры размера кластера

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

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

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

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

Размер кластера анализа данных

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

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

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

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

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

Базовый ETL пакетной службы

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

Размер базового пакета ETL для кластера

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

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

Возможно, следующие функции не полезны:

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

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

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

Размер сложных ETL-кластеров

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

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

Возможно, следующие функции не полезны:

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

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

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

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

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

Размер кластера машинного обучения

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

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

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

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

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

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

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

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

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

Сценарий

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

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

Сценарий для нескольких пользователей

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

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

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

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

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

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

Сценарий

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

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

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

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

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

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

Сценарий

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

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