Настройка вычислений (устаревшая версия)

В этой статье описываются параметры конфигурации, доступные при создании и изменении кластеров Azure Databricks. В нем основное внимание уделяется созданию и редактированию кластеров с помощью пользовательского интерфейса. Другие методы см. в интерфейсе командной строки Databricks, API кластеров и поставщике Databricks Terraform.

Сведения о том, какая комбинация параметров конфигурации соответствует вашим потребностям, см. в рекомендациях по настройке кластера.

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

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

Чтобы настроить политику кластера, выберите политику кластера в раскрывающемся списке "Политика ".

Если у вас есть:

• Разрешение на создание кластера, вы можете выбрать политику «Неограниченная» и создавать полностью настраиваемые кластеры. Политика без ограничений не ограничивает какие-либо атрибуты кластера или значения атрибутов.
• И разрешение на создание кластеров, и доступ к политикам кластера: вы можете выбрать политику неограниченного доступа и политики, к которым у вас есть доступ.
• Доступ только к политикам кластеров. Можно выбрать политики, к которым у вас есть доступ.

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

Azure Databricks поддерживает три режима кластера: Стандартный, Высокий параллелизм и Single Node. Режим кластера по умолчанию — "Стандартный".

Конфигурация кластера включает параметр автоматического завершения , значение по умолчанию которого зависит от режима кластера:

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

Стандартные кластеры

Для отдельных пользователей рекомендуется использовать стандартный кластер. Стандартные кластеры могут выполнять рабочие нагрузки, разработанные в Python, SQL, R и Scala.

Кластеры высокой параллелизма

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

Кластеры высокой параллелизма могут выполнять рабочие нагрузки, разработанные в SQL, Python и R. Производительность и безопасность кластеров высокого параллелизма обеспечивается путем выполнения пользовательского кода в отдельных процессах, что невозможно в Scala.

Кроме того, только кластеры высокой параллелизма поддерживают управление доступом к таблицам.

Чтобы создать кластер с высоким параллелизмом, задайте для режима кластеравысокий параллелизм.

Кластеры с одним узлом

Кластер одного узла не имеет рабочих ролей и выполняет задания Spark на узле драйвера.

Напротив, для выполнения заданий Spark требуется по крайней мере один рабочий узел Spark в дополнение к узлу драйвера.

Чтобы создать кластер с одним узлом, задайте для режима кластеразначение "Один узел".

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

Бассейны

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

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

Дополнительные сведения о работе с пулами в Azure Databricks см. в справочнике по конфигурации pool.

Среда выполнения Databricks

Среда выполнения Databricks — это набор основных компонентов, которые выполняются в кластерах. Все среды выполнения Databricks включают Apache Spark и добавляют компоненты и обновления, которые повышают удобство использования, производительность и безопасность. Дополнительные сведения см. в версиях заметок о выпуске Databricks Runtime и их совместимости .

Azure Databricks предлагает несколько типов сред выполнения и несколько версий этих типов среды выполнения в раскрывающемся списке Databricks Runtime Version при создании или изменении кластера.

Ускорение фотона

Photon доступен для кластеров под управлением Databricks Runtime 9.1 LTS и более поздних версий.

Чтобы включить ускорение Photon, установите флажок "Использовать ускорение фотона ".

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

Databricks рекомендует следующие типы экземпляров для оптимальной цены и производительности:

• Standard_E4ds_v4
• Standard_E8ds_v4
• Standard_E16ds_v4

Вы можете просмотреть действие Photon в пользовательском интерфейсе Spark. На следующем снимке экрана показаны детали DAG запроса. В DAG есть два признака Фотона. Во-первых, операторы Photon начинаются с "Photon", например PhotonGroupingAgg. Во-вторых, в графе DAG операторы и этапы Фотона окрашены в персиковый цвет, а не-Фотон — в синий цвет.

Образы Docker

Для некоторых версий среды выполнения Databricks можно указать образ Docker при создании кластера. Примеры использования включают настройку библиотеки, золотую среду контейнера, которая не изменяется, и интеграция Docker CI/CD.

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

Инструкции см. в разделе Databricks Container Services для выделенных вычислительных ресурсов и служб контейнеров Databricks на вычислительных ресурсах GPU.

Тип узла кластера

Кластер состоит из одного узла драйвера и нуля или нескольких рабочих узлов.

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

• Управляющий узел
• Рабочий узел
• Типы экземпляров GPU
• Спот-экземпляры

Узел драйвера

Узел драйвера хранит сведения о состоянии всех записных книжек, подключенных к кластеру. Узел драйвера также поддерживает SparkContext и интерпретирует все команды, выполняемые из записной книжки или библиотеки в кластере, и запускает главный узел Apache Spark, который координирует работу с исполнителями Spark.

Значение типа узла драйвера по умолчанию совпадает с типом рабочего узла. Если вы планируете collect() большой объем данных от исполнителей Spark и затем анализировать их в блокноте, можно выбрать тип узла драйвера большего размера с увеличенным объемом памяти.

Рабочий узел

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

Типы экземпляров GPU

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

SPOT-экземпляры

Для экономии можно выбрать экземпляры Spot, также известные как Azure Spot виртуальные машины, установив флажок Spot.

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

Размер кластера и автомасштабирование

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

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

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

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

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

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

Как ведет себя автомасштабирование

• Увеличение масштаба с минимального до максимального в два шага.
• Может уменьшить масштаб даже когда кластер не находится в состоянии простоя, просматривая состояние файла шейпл.
• Уменьшение масштаба на основе процента текущих узлов.
• Масштаб кластеров заданий уменьшается, если кластер недоиспользуется в течение последних 40 секунд.
• В кластерах общего назначения масштаб уменьшается, если кластер недоиспользуется в течение последних 150 секунд.
• Свойство spark.databricks.aggressiveWindowDownS конфигурации Spark указывает в секундах, как часто кластер принимает решения по уменьшению масштаба. Увеличение значения приводит к замедлению масштабирования кластера. Максимальное значение — 600.

Включение и настройка автомасштабирования

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

1. Включите автомасштабирование.

   • All-Purpose кластере . На странице "Создание кластера" установите флажок "Включить автомасштабирование " в поле "Параметры Автопилота ":

     

   • Кластер заданий — на странице настройки кластера установите флажок "Включить автомасштабирование " в поле "Параметры Autopilot ":

     

2. Настройте минимальное и максимальное количество рабочих.

   

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

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

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

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

Автоматическое масштабирование локального хранилища

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

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

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

Шифрование локальных дисков

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

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

Чтобы включить шифрование локальных дисков, необходимо использовать API кластеров. Во время создания или редактирования кластера задайте:

{
  "enable_local_disk_encryption": true
}

Примеры вызова этих API см. в API кластеров .

Ниже приведен пример вызова создания кластера, который включает шифрование локальных дисков:

{
  "cluster_name": "my-cluster",
  "spark_version": "7.3.x-scala2.12",
  "node_type_id": "Standard_D3_v2",
  "enable_local_disk_encryption": true,
  "spark_conf": {
    "spark.speculation": true
  },
  "num_workers": 25
}

Режим безопасности

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

В разделе "Дополнительные параметры" выберите следующие режимы безопасности кластера:

• Нет: изоляция отсутствует. Не применяет контроль доступа к таблицам в локальной рабочей области или сквозную передачу учетных данных. Не удается получить доступ к данным каталога Unity.
• Один пользователь: может использоваться только одним пользователем (по умолчанию пользователь, создавший кластер). Другие пользователи не могут подключиться к кластеру. При доступе к представлению из кластера с режимом безопасности одного пользователя представление выполняется с разрешениями пользователя. Кластеры отдельных пользователей поддерживают рабочие нагрузки с помощью Python, Scala и R. Сценарии Init, установка библиотеки и подключения DBFS поддерживаются в кластерах отдельных пользователей. Автоматические задания должны использовать кластеры отдельных пользователей.
• Изоляция пользователей: может совместно использоваться несколькими пользователями. Поддерживаются только рабочие нагрузки SQL. Установка библиотек, инициализационные скрипты и монтажи DBFS отключены для обеспечения строгой изоляции пользователей кластера.
• Только таблица ACL (устаревшая): обеспечивает управление доступом к таблицам локальной рабочей области, но не может получить доступ к данным каталога Unity.
• Сквозная аутентификация только (устаревшее): применяется только локальная передача учетных данных рабочей области, но доступ к данным каталога Unity невозможен.

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

Дополнительные сведения см. в режимах доступа.

Конфигурация Spark

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

1. На странице "Конфигурация кластера" щелкните переключатель Дополнительные параметры.

2. Перейдите на вкладку Spark.

   В файле конфигурации Spark укажите свойства конфигурации в виде одной пары «ключ-значение» в каждой строке.

При настройке кластера с помощью API кластера задайте свойства Spark в поле в spark_conf разделе "Создание нового API кластера " или "Обновить API конфигурации кластера".

Databricks не рекомендует использовать глобальные скрипты инициализации.

Чтобы задать свойства Spark для всех кластеров, создайте глобальный скрипт инициализации:

dbutils.fs.put("dbfs:/databricks/init/set_spark_params.sh","""
  |#!/bin/bash
  |
  |cat << 'EOF' > /databricks/driver/conf/00-custom-spark-driver-defaults.conf
  |[driver] {
  |  "spark.sql.sources.partitionOverwriteMode" = "DYNAMIC"
  |}
  |EOF
  """.stripMargin, true)

Получение свойства конфигурации Spark из хранилища секретов

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

spark.<property-name> {{secrets/<scope-name>/<secret-name>}}

Например, чтобы настроить для свойства конфигурации Spark с именем password значение секрета, хранящегося в secrets/acme_app/password:

spark.password {{secrets/acme-app/password}}

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

Переменные среды

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

1. На странице "Конфигурация кластера" щелкните переключатель Дополнительные параметры.

2. Перейдите на вкладку Spark.

3. Задайте переменные среды в поле "Переменные среды ".

   

Можно также задать переменные среды с помощью spark_env_vars поля в API создания кластера или API обновления конфигурации кластера.

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

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

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

Подробные сведения о том, как работают типы тегов пула и кластера, см. в разделе "Использование тегов для атрибутов и отслеживания использования".

Для удобства Azure Databricks применяет четыре тега по умолчанию к каждому кластеру: Vendor, Creator, ClusterName и ClusterId.

Кроме того, в кластерах заданий Azure Databricks применяется два тега по умолчанию: RunName и JobId.

В ресурсах, используемых Databricks SQL, Azure Databricks также применяет тег по умолчанию SqlWarehouseId.

При создании кластера можно добавить настраиваемые теги. Чтобы настроить теги кластера, выполните приведенные действия.

1. На странице "Конфигурация кластера" щелкните переключатель Дополнительные параметры.

2. В нижней части страницы щелкните вкладку "Теги ".

   

3. Добавьте пару "ключ-значение" для каждого пользовательского тега. Можно добавить до 43 пользовательских тегов.

Доступ SSH к кластерам

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

Доставка логов кластера

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

Назначение журналов зависит от идентификатора кластера. Если указано местоположение dbfs:/cluster-log-delivery, журналы кластера для 0630-191345-leap375 доставляются в dbfs:/cluster-log-delivery/0630-191345-leap375.

Чтобы настроить расположение доставки журналов, выполните следующие действия.

1. На странице "Конфигурация кластера" щелкните переключатель Дополнительные параметры.

2. Нажмите на вкладку Ведение журнала.

   

3. Выберите целевой тип.

4. Введите путь к журналу кластера.

Инициализационные скрипты

Инициализация узла кластера (или инициализация) — это скрипт оболочки, который выполняется во время запуска каждого узла кластера перед запуском драйвера Spark или рабочей JVM. Скрипты init можно использовать для установки пакетов и библиотек, не включенных в среду выполнения Databricks, изменения системного класса JVM, задания свойств системы и переменных среды, используемых JVM, или изменения параметров конфигурации Spark среди других задач конфигурации.

Вы можете присоединить скрипты инициализации к кластеру, развернув раздел "Дополнительные параметры " и щелкнув вкладку "Скрипты Init ".

Подробные инструкции см. в разделе "Что такое скрипты инициализации?".