Часто задаваемые вопросы о декларативных пакетах автоматизации

В этой статье перечислены часто задаваемые вопросы о декларативных пакетах автоматизации (ранее известных как наборы ресурсов Databricks).

Почему пакеты ресурсов Databricks переименованы в декларативные пакеты автоматизации?

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

Как использовать декларативные пакеты автоматизации в рамках конвейера CI/CD в Azure Databricks?

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

• Записные книжки Azure Databricks часто являются ключевой частью рабочих процессов в области инженерии данных и анализа данных. Вы можете использовать управление версиями для ноутбуков, а также проверить и протестировать их в рамках конвейера CI/CD. Вы можете запускать автоматические тесты для записных книжек, чтобы проверить, работают ли они должным образом.
• Библиотеки. Управление зависимостями библиотеки , необходимыми для запуска развернутого кода. Используйте управление версиями для библиотек и включите их в автоматизированное тестирование и проверку.
• Рабочие процессы. Задания Lakeflow состоят из заданий, которые позволяют планировать и запускать автоматизированные задачи с помощью записных книжек или заданий Spark.
• Конвейеры данных: Вы также можете включить конвейеры данных в автоматизацию CI/CD, используя конвейеры Lakeflow для определения конвейеров данных.
• Инфраструктура: конфигурация инфраструктуры включает определения и информацию о подготовке кластеров, рабочих пространств и хранилища для целевых сред. Изменения инфраструктуры можно проверять и тестировать как часть конвейера CI/CD, обеспечивая согласованность и отсутствие ошибок.

Почему нужно иметь отдельные целевые среды разработки и рабочей среды?

Отдельные среды разработки и продукта позволяют:

• Безопасно изолируйте изменения разработки, чтобы они не оказывали непреднамеренного влияния на продакшн-среду.
• Предотвращение дублирования кода путем настройки ресурсов для применения к определенной целевой среде.
• Упрощение и оптимизация CI/CD с помощью конфигурации, зависящей от среды, как пути к базам данных, настройка оповещений и управление доступом.
• Повторное использование рабочих процессов в командах и средах.

Используйте целевые объекты для определения сред развертывания пакета. См цели.

Как сделать пакеты программ едиными в моей организации?

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

Существует много повторений в моих пакетах, таких как те же определения кластера. Как лучше всего справиться с этим?

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

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

Databricks рекомендует вам:

• Переход от ручного развертывания к надежной автоматизации с помощью рабочих процессов, интегрированных с Git.
• Перед развертыванием пакета в вашем CI/CD конвейере, выполните проверку с помощью databricks bundle validate.
• Разделите шаги развертывания, чтобы убедиться, что изменения проверяются и преднамеренные.
• Параметризуйте среды (разработка, промежуточное хранение, продакшн) с переопределениями для изоляции изменений.
• Запустите тесты интеграции после развертывания, чтобы ловить проблемы рано.
• Используйте GitHub Actions, Azure DevOps или GitLab CI для инициации развертываний при комите или слиянии Pull Request.
• Отслеживайте, что развернуто, где и когда, чтобы каждое развертывание сопоставлялось с версией коммита и пакета.

Как перенести развертывание пакета из каталога /Workspace/Shared?

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

1. Измените для цели значение root_path с /Workspace/Shared/... на выделенное расположение, например /Workspace/Users/${workspace.current_user.userName}/.bundle/${bundle.name}/${bundle.target} или папку команды. Это поле задаётся в целевом объекте в разделе workspace, например workspace.root_path.
2. Убедитесь, что в пакете определен раздел permissions, чтобы нужные учетные записи сохраняли доступ в новом расположении. Если такого правила нет, добавьте правило, которое предоставляет команде-владельцу CAN_MANAGE, а группе users — CAN_VIEW, если ресурсы должны оставаться доступными для просмотра всем.
3. Повторно разверните с помощью databricks bundle deploy -t <target> или позвольте конвейеру CI/CD развернуть это изменение. Чтобы сначала ознакомиться с изменениями, запустите databricks bundle plan -t <target>.

Для рабочих развертываний выполняйте развертывание от имени субъекта-службы в путь, принадлежащий команде. См. Определить идентичность запуска для рабочих процессов Декларативных Автоматизационных Пакетов и режимов развертывания Декларативных Автоматизационных Пакетов.

Можно ли перенести существующие задания, конвейеры, панели мониторинга и другие объекты Databricks в пакет?

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

См. статью "Перенос существующих ресурсов в пакет".

Как протестировать пакет итеративно?

Вы можете ускорить разработку с помощью итеративных развертываний и запусков:

• Проверка перед развертыванием
• Поэтапное развертывание
• Выполняйте только необходимое
• Изменение и повторение

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