Надежность в Azure Databricks

Azure Databricks — это совместное использование данных на основе Apache Spark и платформы искусственного интеллекта, оптимизированной для Microsoft Azure. Она предоставляет единую среду для рабочих нагрузок больших данных и ИИ и объединяет лучшие возможности Databricks и Azure для упрощения проектирования данных, обработки и анализа данных и машинного обучения.

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

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

Обзор архитектуры надежности

Необходимо понимать надежность каждого основного компонента в Azure Databricks:

Контрольная плоскость — это коллекция бездействующих служб, которые управляют метаданными рабочего пространства, доступом пользователей, планированием заданий и управлением кластерами. Эти службы поддерживаются базами данных, которые реплицируются между зонами доступности в поддерживаемых регионах.
Корень файловой системы Databricks (DBFS) — это учетная запись хранения, которую Azure Databricks автоматически подготавливает при создании рабочей области Azure Databricks в облачной учетной записи. Рекомендуется не хранить данные в корневом каталоге DBFS и по возможности отключить эту учетную запись хранения.
Хранилище каталога Unity включает одну или несколько учетных записей хранения, которые хранят данные каталога Unity в облачной учетной записи. Дополнительные сведения см. в разделе "Каталог Unity".
Вычислительная платформа обрабатывает рабочие нагрузки с помощью кластеров виртуальных машин (ВМ). Вычислительная плоскость обрабатывает переходящие ошибки и автоматически заменяет отказавшие узлы без вмешательства пользователя. Вы можете выбрать один из нескольких типов вычислительных ресурсов. Дополнительные сведения см. в разделе "Вычисления".

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

Устойчивость к временным сбоям

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

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

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

Для приложений, работающих в Azure Databricks, реализуйте логику повторных попыток с экспоненциальным откатом, подключаясь к внешним службам или службам Azure, таким как Azure Хранилище, Azure SQL Database или Azure Event Hubs. Databricks Runtime включает встроенную устойчивость для многих служб Azure, но код приложения должен обрабатывать временные сбои конкретной службы.

Устойчивость к сбоям зоны доступности

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

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

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

Данные рабочей области уровня управления хранятся в базах данных. В регионах, поддерживающих зоны доступности, базы данных реплицируются в нескольких зонах в регионе. Учетные записи хранения, обслуживающие образы среды выполнения Databricks, также избыточны в регионе. Все регионы имеют вторичные учетные записи хранения, используемые при отключении основной учетной записи хранения.
Корневой каталог DBFS: В регионах, поддерживающих зоны доступности, можно настроить учетную запись хранения для корневого каталога DBFS, чтобы использовать зонально избыточное хранилище (ZRS). В парных регионах, поддерживающих зоны доступности, можно опционально использовать геоизбыточное хранилище (GZRS).
Плоскость вычислений: Databricks поддерживает автоматическое распределение зон для вычислительных ресурсов, что означает, что ресурсы распределяются по нескольким зонам доступности. Это распределение помогает рабочим нагрузкам обеспечить устойчивость к сбоям зон.

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

Требования

Чтобы использовать поддержку зоны доступности в Azure Databricks, вам потребуется следующее:

Поддержка региона: Поддержка зоны доступности Azure Databricks доступна во всех регионах Azure, которые поддерживают Azure Databricks и предоставляют зоны доступности. Список регионов, поддерживающих Azure Databricks, см. в разделе "Продукты", доступные по регионам. Полный список регионов, поддерживающих зоны доступности, см. в регионах Azure, поддерживающих зоны доступности.
Репликация хранилища: Настройте учетные записи хранения рабочей области для использования ZRS или GZRS (где доступно).
Вычислительные ресурсы: Убедитесь, что достаточно вычислительных ресурсов существует в нескольких зонах в целевом регионе. Azure Databricks автоматически распределяет узлы кластера между зонами, но убедитесь, что выбранные типы экземпляров доступны во всех целевых зонах.

Соображения

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

Себестоимость

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

Избыточность по умолчанию для управляемой учетной записи хранения или корневого каталога DBFS — геоизбыточное хранилище (GRS). Изменение на ZRS или GZRS может повлиять на затраты на хранилище. Дополнительные сведения см. в разделе цены на Azure Blob Storage.

Настройка поддержки зоны доступности

Контрольная плоскость: Контрольная плоскость автоматически поддерживает зональную избыточность в регионах с зонами доступности. Вам не нужно ничего настраивать.
Корневой каталог DBFS: Вы можете настроить избыточность зоны для корневого хранилища DBFS при создании новой рабочей области или изменении существующей рабочей области:
- Создайте новую рабочую область с корневым хранилищем DBFS с зональной избыточностью: При создании рабочей области Azure Databricks можно настроить связанную учетную запись хранилища для использования ZRS или GZRS вместо GRS по умолчанию. Дополнительные сведения см. в разделе "Изменение параметров избыточности хранилища рабочей области".
- Включите избыточность зоны в корневом хранилище DBFS: Для существующих рабочих областей можно изменить конфигурацию избыточности учетной записи хранения рабочей области на ZRS или GZRS. Для получения дополнительной информации о включении зональной избыточности см. раздел "Изменение параметров репликации для учетной записи хранения".
Плоскость вычислений: Узлы кластера автоматически распределяются по зонам доступности. Конфигурация клиента не требуется для распространения зоны.

Поведение, когда все зоны работоспособны

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

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

Поведение во время сбоя зоны

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

Обнаружение и ответ: Корпорация Майкрософт автоматически обнаруживает сбои зоны и инициирует процедуры реагирования. Вам не нужно предпринимать никаких действий для переключения на резерв на уровне зоны.
Уведомление: Корпорация Майкрософт не уведомляет вас об отключении зоны. Но вы можете использовать страницу состояния Azure Databricks , чтобы просмотреть обзор всех основных служб Azure Databricks. Вы также можете подписаться на обновления состояния отдельных компонентов службы и получать оповещения, когда состояние службы, на которую вы подписаны, меняется.
Активные запросы: Запущенные кластеры могут потерять узлы в затронутой зоне. Диспетчер кластеров автоматически запрашивает замещающие узлы из других зон. Если узел драйвера потерян, кластер и задание полностью перезагрузятся.
Ожидаемая потеря данных:
- Плоскость управления: Ожидайте отсутствия потерь данных во время сбоя в зоне.
- Корневой каталог DBFS: Данные рабочей области остаются доступными, если они используют конфигурации хранилища ZRS или GZRS.
- Плоскость вычислений: Кэшированные данные на виртуальных машинах являются временными. Все данные, потерянные с виртуальных машин во время сбоя зоны, восстанавливаются из хранилища. Если управляющий узел потерян, задание перезапускается и пересчитывает результаты.
Ожидаемое время простоя:
- Плоскость управления: Плоскость управления Databricks выполняет автоматическое переключение на работоспособные зоны в течение примерно 15 минут.
- Корневой каталог DBFS: Ожидайте отсутствия простоя для аккаунтов хранения, использующих ZRS или GZRS.
- Плоскость вычислений: Если узлы потеряны, так как их виртуальные машины находятся в затронутой зоне доступности, диспетчер кластеров Azure запрашивает замены узлов от поставщика вычислений Azure. Если остальные здоровые зоны имеют достаточную емкость для выполнения запроса, поставщик вычислений извлекает узлы из работоспособных зон, чтобы заменить потерянные узлы. Этот процесс может занять несколько минут.
  
  Если узел драйвера потерян из-за сбоя зоны, весь кластер перезапускается, что может привести к более длительному времени восстановления по сравнению с потерей рабочих узлов. Запланируйте это поведение в стратегиях планирования и мониторинга заданий.
  
  Вы можете использовать бессерверную архитектуру или группы экземпляров, чтобы сократить это время.
Перенаправка трафика:
- Управляющая плоскость: Управляющая плоскость Databricks выполняет автоматическое переключение на резервные зоны в течение около 15 минут.
- Корневой каталог DBFS: Служба хранилища Azure автоматически перенаправляет запросы в кластеры хранилища в здоровых зонах.
- Плоскость вычислений: Диспетчер кластеров автоматически переключается на узлы в здоровых зонах.

Восстановление зоны

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

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

Тестирование на сбои в зоне

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

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

Устойчивость к сбоям на уровне региона

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

Индивидуальные решения для нескольких регионов для повышения устойчивости

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

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

Чтобы выбрать архитектуру, рассмотрите следующие факторы:

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

Сведения о рабочих нагрузках, требующих защиты нескольких регионов, см. в статье Об аварийном восстановлении Azure Databricks.

Резервное копирование и восстановление

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

Замечание

Если происходит сбой зоны, Azure Databricks не ожидает потери данных.

Мы рекомендуем хранить данные в хранилище каталога Unity. Данные можно реплицировать с помощью репликации хранилища или разностного клонирования.

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

Устойчивость к обслуживанию служб

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

Соглашение об уровне обслуживания

Соглашение об уровне обслуживания (SLA) для служб Azure описывает ожидаемую доступность каждой службы и условия, которые должно соответствовать вашему решению для достижения этого ожидания доступности. Для получения дополнительной информации см. Соглашения об уровне обслуживания для онлайн-сервисов.

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-12-10