Рабочие процессы CI/CD в Databricks

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

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

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

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

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

Note

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

Декларативные пакеты автоматизации для CI/CD

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

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

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

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

Управление исходным кодом

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

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

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

Рабочий процесс 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. Развертывание пакета

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

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

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

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

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

Team Responsibilities Примеры компонентов пакета Примеры артефактов
Инженеры данных Создание конвейеров 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 стэков, организации могут упростить совместную работу, сохраняя проверяемость на протяжении всего жизненного цикла машинного обучения.

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 с помощью декларативных пакетов автоматизации. Эта возможность позволяет разработчикам панелей мониторинга:

  • Панели мониторинга управления версиями, которые обеспечивают возможность аудита и упрощают совместную работу между командами.
  • Автоматизируйте развертывание мониторинговых панелей вместе с работами и конвейерами во всех средах для полной интеграции.
  • Уменьшите ошибки вручную и убедитесь, что обновления применяются последовательно в разных средах.
  • Поддерживайте высококачественные рабочие процессы аналитики при соблюдении рекомендаций 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.

  • Last updated on