Лучшие практики и рекомендуемые рабочие процессы CI/CD на Databricks

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

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

Основные принципы CI/CD

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

• Управление версиями всего
  • Храните записные книжки, скрипты, определения инфраструктуры (IaC) и конфигурации заданий в Git.
  • Используйте стратегии ветвления, такие как Gitflow, которые соответствуют стандартным средам разработки, промежуточного тестирования и развёртывания в рабочей среде.
• Автоматизация тестирования
  • Реализуйте модульные тесты для бизнес-логики с помощью библиотек, таких как pytest для Python и ScalaTest для Scala .
  • Проверьте функциональные возможности записных книжек и рабочих процессов с помощью таких средств, как bundle validate CLI Databricks.
  • Используйте тесты интеграции для рабочих процессов и конвейеров данных, например chispa для кадров данных Spark.
• Использование инфраструктуры в качестве кода (IaC)
  • Определите кластеры, задачи и конфигурации рабочих областей с помощью Databricks Asset Bundles в формате YAML или Terraform.
  • Параметризуйте вместо жестко закодированных параметров, специфичных для среды, таких как размер кластера и конфиденциальные данные.
• Изоляция сред
  • Поддержание отдельных сред для разработки, промежуточного тестирования и эксплуатации.
  • Используйте реестр моделей MLflow для управления версиями моделей в разных средах.
• Выберите средства, соответствующие облачной экосистеме:
  • Azure: Azure DevOps и Databricks Asset Bundles или Terraform.
  • AWS: GitHub Actions и Databricks Asset Bundles или Terraform.
  • GCP: Cloud Build и Databricks Asset Bundles или Terraform.
• Следите и автоматизируйте откаты
  • Отслеживайте показатели успешного развертывания, производительность заданий и покрытие тестов.
  • Реализуйте механизмы автоматического отката для неудачных развертываний.
• Объединение управления ресурсами
  • Используйте пакеты ресурсов Databricks для развертывания кода, заданий и инфраструктуры в виде единой единицы. Избегайте разложенного управления записными книжками, библиотеками и рабочими процессами.

Замечание

Databricks рекомендует федерацию удостоверений рабочих процессов для аутентификации CI/CD. Федерация удостоверений рабочей нагрузки исключает необходимость использования секретов Databricks, что делает её самым безопасным способом аутентификации автоматизированных потоков Databricks. См. статью "Включить федерацию удостоверений рабочей нагрузки" в CI/CD.

Пакеты ресурсов Databricks для CI/CD

Пакеты активов Databricks предлагают мощный унифицированный подход к управлению кодом, рабочими процессами и инфраструктурой в экосистеме Databricks и рекомендуется для конвейеров CI/CD. Объединяя эти элементы в единую единицу, определяемую YAML, пакеты упрощают развертывание и обеспечивают согласованность между средами. Однако для пользователей, привыкших к традиционным рабочим процессам CI/CD, внедрение пакетов может потребовать смены мышления.

Например, разработчики Java используются для создания JAR с помощью Maven или Gradle, выполнения модульных тестов с помощью JUnit и интеграции этих шагов в конвейеры CI/CD. Аналогичным образом разработчики Python часто пакетируют код в wheel-пакеты и тестируют с помощью pytest, в то время как разработчики SQL сосредоточены на проверке запросов и управлением записными книжками. Благодаря пакетам эти рабочие процессы конвергентируются в более структурированном и предписательном формате, подчеркивая объединение кода и инфраструктуры для простого развертывания.

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

Чтобы быстро приступить к работе с Databricks Asset Bundles, попробуйте учебное пособие: разработка задания с Databricks Asset Bundles или разработка декларативных конвейеров Lakeflow с Databricks Asset Bundles.

Рекомендации по управлению исходным кодом CI/CD

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

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

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

Один репозиторий для кода и конфигурации

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

Плюсы	Минусы
Все связанные артефакты, код и конфигурации YAML версионируются вместе, что уменьшает накладные расходы на координацию. Один pull request может обновить как скомпилированный файл сборки, так и соответствующую конфигурацию пакета. Конвейер CI/CD может создавать, тестировать, проверять и развертывать из одного репозитория.	С течением времени репозиторий может быть переполнен как файлами кода, так и файлами конфигурации. Для изменений кода и пакета требуется координируемый выпуск.

Пример: код Python в пакете

В этом примере есть файлы Python и файлы пакета в одном репозитории:

databricks-dab-repo/
├── databricks.yml               # Bundle definition
├── resources/
│   ├── workflows/
│   │   ├── my_pipeline.yml      # YAML pipeline def
│   │   └── my_pipeline_job.yml  # YAML job def that runs pipeline
│   ├── clusters/
│   │   ├── dev_cluster.yml      # development cluster def
│   │   └── prod_cluster.yml     # production def
├── src/
│   ├── dlt_pipeline.ipynb       # pipeline notebook
│   └── mypython.py              # Additional Python
└── README.md

Отдельные репозитории для кода и конфигурации

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

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

Пример: проект и пакет Java

В этом примере проект Java и его файлы находятся в одном репозитории, а файлы пакета находятся в другом репозитории.

Репозиторий 1. Файлы Java

Первый репозиторий содержит все файлы, связанные с Java:

java-app-repo/
├── pom.xml                  # Maven build configuration
├── src/
│   ├── main/
│   │   ├── java/            # Java source code
│   │   │   └── com/
│   │   │       └── mycompany/
│   │   │           └── app/
│   │   │               └── App.java
│   │   └── resources/       # Application resources
│   └── test/
│       ├── java/            # Unit tests for Java code
│       │   └── com/
│       │       └── mycompany/
│       │           └── app/
│       │               └── AppTest.java
│       └── resources/       # Test-specific resources
├── target/                  # Compiled JARs and classes
└── README.md

• Разработчики пишут код приложения в src/main/java или src/main/scala.
• Модульные тесты хранятся в src/test/java или src/test/scala.
• В запросе на вытягивание или фиксации конвейеры CI/CD:
  • Скомпилируйте код в JAR-файл, например target/my-app-1.0.jar.
  • Отправьте JAR-файл в том каталога Databricks Unity. См. загрузить JAR.

Репозиторий 2. Пакеты файлов

Второй репозиторий содержит только файлы конфигурации пакета:

databricks-dab-repo/
├── databricks.yml               # Bundle definition
├── resources/
│   ├── jobs/
│   │   ├── my_java_job.yml  # YAML job dev
│   │   └── my_other_job.yml # Additional job definitions
│   ├── clusters/
│   │   ├── dev_cluster.yml  # development cluster def
│   │   └── prod_cluster.yml # production def
└── README.md

• Конфигурация пакета databricks.yml и определения заданий поддерживаются независимо.

• Databricks.yml ссылается на загруженный JAR-артефакт, например:

  - jar: /Volumes/artifacts/my-app-${{ GIT_SHA }}.)jar
  

Рекомендуемый рабочий процесс CI/CD

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

1. Компиляция и проверка кода

   • Активируется при pull request или коммите в главной ветке.
   • Компилируйте код и запустите модульные тесты.
   • Выведите файл с версиями, например my-app-1.0.jar.

2. Отправьте и сохраните скомпилированный файл, например JAR-файл, в том каталога Databricks Unity.

   • Сохраните скомпилированный файл в томе каталога Databricks Unity или репозитории артефактов, например AWS S3 или хранилище BLOB-объектов Azure.
   • Используйте схему управления версиями, привязанную к хэшам фиксации Git или семантической версии, например dbfs:/mnt/artifacts/my-app-${{ github.sha }}.jar.

3. Проверка пакета

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

4. Развертывание пакета

   • Используйте databricks bundle deploy для развертывания пакета в промежуточной или рабочей среде.
   • Ссылка на отправленную скомпилированную библиотеку в databricks.yml. Дополнительные сведения о ссылках на библиотеки см. в разделе "Зависимости библиотеки наборов ресурсов Databricks".

CI/CD для машинного обучения

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

• Координация с несколькими командами: специалисты по обработке и анализу данных, инженеры и команды MLOps часто используют различные инструменты и рабочие процессы. Databricks объединяет эти процессы с MLflow для отслеживания экспериментов, Delta Sharing для управления данными и Databricks Asset Bundles для инфраструктуры как код.
• Управление версиями данных и моделей: конвейеры машинного обучения требуют отслеживания не только кода, но и схем данных обучения, дистрибутивов функций и артефактов модели. Databricks Delta Lake предоставляет транзакции ACID и возможность временного перемещения для управления версиями данных, а Реестр моделей MLflow осуществляет управление родословной моделей.
• Воспроизводимость в средах: модели машинного обучения зависят от конкретных данных, кода и сочетаний инфраструктуры. Пакеты ресурсов Databricks обеспечивают атомарное развертывание этих компонентов в средах разработки, промежуточной и рабочей с определениями YAML.
• Непрерывная переобучение и мониторинг: модели ухудшаются из-за смещения данных. Автоматизация переобучающих потоков в Lakeflow, в то время как MLflow интегрируется с Prometheus и Lakehouse Monitoring для отслеживания производительности.

Стеки MLOps для CI/CD процессов машинного обучения

Databricks обращается к сложности CI/CD с помощью MLOps Stacks, производственной платформы, которая объединяет пакеты ресурсов Databricks, предварительно настроенные рабочие процессы CI/CD и модульные шаблоны проектов машинного обучения. Эти стеки применяют лучшие практики, обеспечивая гибкость для совместной работы с несколькими командами в области проектирования данных, Data Science и ролей MLOps.

Команда	Обязанности	Примеры компонентов пакета	Примеры артефактов
Инженеры данных	Создание конвейеров ETL, обеспечение качества данных	Декларативные конвейеры Lakeflow YAML, политики кластера	etl_pipeline.yml, feature_store_job.yml
Специалисты по данным	Разработка логики обучения модели, проверка метрик	Проекты MLflow, рабочие процессы на основе записных книжек	train_model.yml, batch_inference_job.yml
Инженеры MLOps	Оркестрация развертываний, мониторинг конвейеров	Переменные среды, панели мониторинга	databricks.yml, lakehouse_monitoring.yml

Сотрудничество в контексте CI/CD для машинного обучения может выглядеть следующим образом:

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

Дополнительные сведения о реализации см. в статье:

• Пакет MLOps Stacks: пошаговое руководство по инициализации и развертыванию пакета.
• Репозиторий MLOps Stacks GitHub: предварительно настроенные шаблоны для обучения, вывода и CI/CD.

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

CI/CD для разработчиков SQL

Разработчики SQL, использующие Databricks SQL для управления таблицами потоковой передачи и материализованными представлениями, могут использовать конвейеры интеграции Git и CI/CD для оптимизации рабочих процессов и поддержания высококачественных конвейеров. Благодаря внедрению поддержки Git для запросов разработчики SQL могут сосредоточиться на написании запросов при использовании Git для управления версиями файлов .sql , что обеспечивает совместную работу и автоматизацию без необходимости глубокого опыта в инфраструктуре. Кроме того, редактор SQL обеспечивает совместную работу в режиме реального времени и легко интегрируется с рабочими процессами Git.

Для рабочих процессов, ориентированных на SQL:

• Файлы SQL управления версиями

  • Храните .sql файлы в репозиториях Git с помощью папок Databricks Git или внешних поставщиков Git, например GitHub, Azure DevOps.
  • Используйте ветви (например, разработку, стейджинг, продакшн) для управления изменениями в среде.

• Интеграция .sql файлов в конвейеры CI/CD для автоматизации развертывания:

  • Валидация изменений синтаксиса и схемы во время пулл-реквестов.
  • Разверните файлы .sql в Databricks SQL рабочих процессах или заданиях.

• Параметризация для изоляции среды

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

    CREATE OR REFRESH STREAMING TABLE ${env}_sales_ingest AS SELECT * FROM read_files('s3://${env}-sales-data')
    

• Планирование и мониторинг обновлений

  • Используйте задачи SQL в задании Databricks для планирования обновлений таблиц и материализованных представлений (REFRESH MATERIALIZED VIEW view_name).
  • Отслеживание истории обновления с использованием системных таблиц.

Рабочий процесс может быть следующим:

1. Разработка: создание и тестирование .sql скриптов локально или в редакторе SQL Databricks, а затем зафиксируйте их в ветви Git.
2. Валидация: Во время pull-реквеста проверяйте синтаксис и совместимость схем с помощью автоматических CI-проверок.
3. Развертывание. При слиянии разверните скрипты .sql в целевой среде с помощью конвейеров CI/CD, например GitHub Actions или Azure Pipelines.
4. Мониторинг. Использование панелей мониторинга Databricks и оповещений для отслеживания производительности запросов и свежести данных.

CI/CD для разработчиков панелей мониторинга

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

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

Для панелей мониторинга в CI/CD:

• databricks bundle generate Используйте команду для экспорта существующих панелей мониторинга в виде JSON-файлов и создания конфигурации YAML, которая включает ее в пакет:

  resources:
    dashboards:
      sales_dashboard:
        display_name: 'Sales Dashboard'
        file_path: ./dashboards/sales_dashboard.lvdash.json
        warehouse_id: ${var.warehouse_id}
  

• Сохраните эти .lvdash.json файлы в репозиториях Git для эффективного отслеживания изменений и совместной работы.

• Автоматически разверните панели мониторинга в конвейерах CI/CD с помощью databricks bundle deploy. Например, шаг GitHub Actions для развертывания:

  name: Deploy Dashboard
    run: databricks bundle deploy --target=prod
  env:
    DATABRICKS_TOKEN: ${{ secrets.DATABRICKS_TOKEN }}
  

• Используйте переменные, например ${var.warehouse_id}, для параметризации конфигураций, таких как хранилища SQL или источники данных, обеспечивая простое развертывание в средах разработки, промежуточной и рабочей среды.

• bundle generate --watch Используйте параметр непрерывной синхронизации файлов JSON локальной панели мониторинга с изменениями, внесенными в пользовательский интерфейс Databricks. Если возникают несоответствия, используйте --force флаг во время развертывания для перезаписи удаленных панелей мониторинга с локальными версиями.

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