Поделиться через

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

  • Статья

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

Отображение кластеров

Чтобы просмотреть кластеры в рабочей области, щелкните " compute iconВычисления " на боковой панели.

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

Закрепление кластера

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

Администратор может закрепить кластер из списка кластеров или страницу сведений о кластере, щелкнув значок закрепления.

Можно также вызвать конечную точку API кластеров, чтобы закрепить кластер программным способом.

Просмотр конфигурации кластера как файла JSON

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

Изменение кластера

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

Примечание.

  • Подключенные к кластеру записные книжки и задания после редактирования остаются подключенными.
  • Библиотеки, установленные в кластере, после редактирования остаются установленными.
  • Если изменяется какой-либо атрибут работающего кластера (за исключением размера и разрешений кластера), его необходимо перезапустить. Это может нарушить работу пользователей, которые в настоящее время используют кластер.
  • Вы можете изменять только запущенные или завершенные кластеры. Однако вы можете обновить разрешения для кластеров , которые не находятся в этих состояниях, на странице сведений о кластере.

Клонирование кластера

Чтобы клонировать существующий кластер, выберите "Клонировать " в меню кебаб кластера Kebab menu (также известное как трехточное меню).

После выбора клонирования пользовательский интерфейс создания кластера откроется предварительно заполнен конфигурацией кластера. Следующие атрибуты не включаются в клон.

  • Разрешения кластера
  • Установленные библиотеки
  • Подключенные записные книжки

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

Управление доступом к кластеру на странице параметров администратора позволяет администраторам рабочей области предоставлять точный доступ к кластеру другим пользователям. Существует два типа управления доступом к кластеру:

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

Чтобы изменить разрешения для кластера, выберите "Изменить разрешения " в меню kebab этого кластера Kebab menu .

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

Завершение работы кластера

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

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

Завершенные кластеры отображаются в списке кластеров с серым кругом слева от имени кластера.

Примечание.

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

Важно!

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

  • При обновлении рабочей области до полного плана "Премиум".
  • Если рабочая область не обновлена и срок действия пробной версии истек.

Завершение работы вручную

Вы можете вручную завершить кластер из списка кластеров (щелкнув квадрат на строке кластера) или страницу сведений о кластере (нажав кнопку "Завершить").

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

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

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

Кластер считается неактивным, если выполнение всех команд в кластере, включая задания Spark, структурированную потоковую передачу и вызовы JDBC, завершено.

Предупреждение

  • Кластеры не сообщают о действиях, вызванных использованием DStreams. Это означает, что автоматически завершающийся кластер может быть завершен во время работы D Потоки. Отключите автоматическое завершение работы для кластеров, где выполняются DStreams, или рассмотрите возможность использования структурированной потоковой передачи.
  • Функция автоматического завершения работы отслеживает только задания Spark, а не определенные пользователем локальные процессы. Таким образом, если все задания Spark завершены, кластер может быть завершен, даже если выполняются локальные процессы.
  • Кластеры в состоянии простоя продолжают накапливать плату за DBU и облачные экземпляры в течение периода бездействия до завершения их работы.

Настройка автоматического завершения работы

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

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

Примечание.

Наиболее оптимальную поддержку автоматического завершения работы обеспечивают последние версии Spark. У более старых версий Spark есть известные ограничения, из-за которых отчеты о действиях кластера могут быть неточными. Например, кластеры, в которых выполняются команды JDBC, R или потоковой передачи, могут указывать в отчете устаревшее время действия, из-за чего работа кластера может завершиться преждевременно. Обновите версию Spark до последней, чтобы воспользоваться исправлениями и улучшениями автоматического завершения работы.

Непредвиденное завершение работы

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

Список причин завершения работы и действия по исправлению см. в Базе знаний.

Удаление кластера

Удаление кластера приводит к прекращению работы кластера и удалению его конфигурации. Чтобы удалить кластер, выберите "Удалить " из меню кластера Kebab menu .

Предупреждение

Это действие нельзя отменить.

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

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

Перезапуск кластера

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

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

Примечание.

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

Перезапуск кластера для его обновления с добавлением образов последних версий

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

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

Важно!

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

Пример записной книжки: поиск длительных кластеров

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

Первые строки скрипта определяют параметры конфигурации:

  • min_age_output: максимальное число дней, в течение которых может выполняться кластер. По умолчанию 1.
  • perform_restart: если имеет значение True, скрипт перезапускает кластеры, срок которых превышает число дней, указанное в параметре min_age_output. Значение по умолчанию Falseопределяет длительные кластеры, но не перезапускает их.
  • secret_configuration: замените REPLACE_WITH_SCOPE и REPLACE_WITH_KEYобластью действия секрета и именем ключа. Дополнительные сведения о настройке секретов см. в записной книжке.

Предупреждение

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

Записная книжка для определения и (при необходимости) перезапуска долго работающих кластеров

Получить записную книжку

Автоматическое запуск кластера для заданий и запросов JDBC/ODBC

Когда задание, назначенное завершенному кластеру, планируется запустить или подключиться к завершенному кластеру из интерфейса JDBC/ODBC, кластер автоматически перезапускается. См. раздел Создание задания и Подключение JDBC.

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

Перед автоматическим перезапуском кластера проверяются разрешения на управление доступом для кластера и задания.

Примечание.

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

Просмотр сведений о кластере в пользовательском интерфейсе Apache Spark

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

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

Просмотр журналов кластера

Azure Databricks предоставляет три типа ведения журнала действий, связанных с кластером:

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

В этом разделе обсуждаются журналы событий кластера и журналы драйверов и рабочих ролей. Дополнительные сведения о журналах сценариев init-script см. в разделе "Ведение журнала скриптов Init".

Журналы событий кластера

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

Сведения о поддерживаемых типах событий см. в структуре данных API кластеров.

События хранятся в течение 60 дней, что сравнимо со временем хранения других данных в Azure Databricks.

Просмотр журнала событий кластера

Чтобы просмотреть журнал событий кластера, перейдите на вкладку "Журнал событий" на страницах сведений о кластере.

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

Журналы драйверов и рабочих ролей кластера

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

Эти журналы имеют три типа выходных данных:

  • Стандартные выходные данные
  • Стандартная ошибка
  • Журналы log4j

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

Мониторинг производительности

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

Кроме того, вы можете настроить кластер Azure Databricks для отправки метрик в рабочую область Log Analytics в Azure Monitor (платформа мониторинга для Azure).

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

Метрики кластера

Метрики кластеров — это средство мониторинга по умолчанию для Databricks Runtime 13.0 и более поздних версий. Чтобы получить доступ к пользовательскому интерфейсу метрик кластера, перейдите на вкладку "Метрики " на странице сведений о кластере.

Вы можете просмотреть исторические метрики, выбрав диапазон времени с помощью фильтра средства выбора дат. Метрики собираются каждую минуту. Вы также можете получить последние метрики, нажав кнопку "Обновить ". Дополнительные сведения см. в разделе Просмотр динамических и исторических метрик кластера.

Метрики Ganglia

Примечание.

Метрики Ganglia доступны только для Databricks Runtime 12.2 и ниже.

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

Чтобы просмотреть динамические метрики, щелкните ссылку Пользовательский интерфейс Ganglia.

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

Примечание.

Ganglia не поддерживается с контейнерами Docker. Если вы используете контейнер Docker с кластером, метрики Ganglia не будут доступны.

Настройка коллекции метрик Ganglia

По умолчанию Azure Databricks собирает метрики Ganglia каждые 15 минут. Чтобы настроить период сбора, задайте DATABRICKS_GANGLIA_SNAPSHOT_PERIOD_MINUTES переменную среды с помощью скрипта инициализации или spark_env_vars в поле в API создания кластера.

Azure Monitor

Кластер Azure Databricks можно настроить для отправки метрик в рабочую область Log Analytics в Azure Monitor — платформе мониторинга Azure. Полные инструкции см. в статье Мониторинг Azure Databricks.

Примечание.

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

Пример записной книжки: метрики Datadog

Datadog metrics

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

Чтобы установить агент Datadog во всех кластерах, управляйте скриптом область инициализации кластера с помощью политики кластера.

Установка записной книжки скрипта инициализации агента Datadog

Получить записную книжку

Вывод точечных экземпляров

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

  • Сбои при получении случайных данных
  • Потеря случайных данных
  • Потеря данных RDD
  • Сбои задания

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

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

Примечание.

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

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

Включение вывода из эксплуатации

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

  • Чтобы включить отключение для приложений, введите это свойство в поле конфигурации Spark:

    spark.decommission.enabled true

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

    spark.storage.decommission.enabled true
spark.storage.decommission.shuffleBlocks.enabled true

  • Чтобы включить миграцию данных кэша RDD во время вывода из эксплуатации, введите это свойство в поле конфигурации Spark:

    spark.storage.decommission.enabled true
spark.storage.decommission.rddBlocks.enabled true

    Примечание.

    Если репликация StorageLevel RDD имеет значение больше 1, Databricks не рекомендует включать перенос данных RDD, так как реплики гарантируют, что данные RDD не будут потеряны.

  • Чтобы включить отключение рабочих ролей, введите это свойство в поле "Переменные среды":

    SPARK_WORKER_OPTS="-Dspark.decommission.enabled=true"

Просмотр состояния вывода и причины потери в пользовательском интерфейсе

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

Завершив вывод из эксплуатации, вы можете просмотреть причину потери исполнителя на вкладке "Исполнителя пользовательского интерфейса > Spark" на странице сведений о кластере.