Bonnes pratiques et flux de travail CI/CD recommandés sur Databricks

CI/CD (Intégration continue et livraison continue) est devenu une pierre angulaire de l’ingénierie et de l’analytique modernes des données, car il garantit que les modifications de code sont intégrées, testées et déployées rapidement et de manière fiable. Databricks reconnaît que vous pouvez avoir diverses exigences CI/CD mises en forme par vos préférences organisationnelles, les flux de travail existants et un environnement technologique spécifique, et fournit un framework flexible qui prend en charge différentes options CI/CD.

Cette page décrit les meilleures pratiques pour vous aider à concevoir et à créer des pipelines CI/CD robustes et personnalisés qui s’alignent sur vos besoins et contraintes uniques. En tirant parti de ces insights, vous pouvez accélérer vos initiatives d’ingénierie et d’analytique des données, améliorer la qualité du code et réduire le risque d’échecs de déploiement.

Principes fondamentaux de CI/CD

Les pipelines CI/CD efficaces partagent des principes fondamentaux indépendamment des spécificités de l’implémentation. Les meilleures pratiques universelles suivantes s’appliquent aux préférences organisationnelles, aux flux de travail des développeurs et aux environnements cloud, et garantissent la cohérence entre différentes implémentations, que votre équipe hiérarchise le premier développement de notebooks ou les workflows d’infrastructure en tant que code. Adoptez ces principes comme garde-fous en adaptant les spécificités à l'ensemble technologique et aux processus de votre organisation.

• Contrôle de version pour tout
  • Stocker des notebooks, des scripts, des définitions d’infrastructure (IaC) et des configurations de travaux dans Git.
  • Utilisez des stratégies de branchement, telles que Gitflow, qui sont alignées sur les environnements de développement, de préproduction et de déploiement de production standard.
• Automatiser les tests
  • Implémentez des tests unitaires pour la logique métier à l’aide de bibliothèques, telles que pytest pour Python et ScalaTest .
  • Validez les fonctionnalités de notebook et de flux de travail avec des outils, tels que la commande bundle validate de l’interface CLI Databricks.
  • Utilisez des tests d’intégration pour les flux de travail et les pipelines de données, tels que chispa pour les DataFrames Spark.
• Utiliser l’infrastructure en tant que code (IaC)
  • Définissez des clusters, des travaux et des configurations d’espace de travail avec Databricks Asset Bundles YAML ou Terraform.
  • Paramétrez au lieu de coder en dur des paramètres spécifiques à l’environnement, tels que la taille du cluster et les secrets.
• Isoler les environnements
  • Conservez des espaces de travail distincts pour le développement, la préproduction et la production.
  • Utilisez le Registre de modèles MLflow pour le contrôle de version des modèles entre les environnements.
• Choisissez des outils qui correspondent à votre écosystème cloud :
  • Azure : Azure DevOps et Databricks Asset Bundles ou Terraform.
  • AWS : GitHub Actions et Databricks Asset Bundles ou Terraform.
  • BPC : Build cloud et packs de ressources Databricks ou Terraform.
• Surveiller et automatiser les restaurations
  • Suivez les taux de réussite du déploiement, les performances du travail et la couverture des tests.
  • Implémentez des mécanismes de restauration automatisée pour les déploiements ayant échoué.
• Unifier la gestion des ressources
  • Utilisez databricks Asset Bundles pour déployer du code, des travaux et une infrastructure en tant qu’unité unique. Évitez la gestion en silo des notebooks, des bibliothèques et des flux de travail.

Paquets de ressources Databricks pour CI/CD

Databricks Asset Bundles offre une approche puissante et unifiée de la gestion du code, des flux de travail et de l’infrastructure au sein de l’écosystème Databricks et sont recommandées pour vos pipelines CI/CD. En regroupant ces éléments dans une seule unité définie par YAML, les bundles simplifient le déploiement et garantissent la cohérence entre les environnements. Toutefois, pour les utilisateurs habitués aux flux de travail CI/CD traditionnels, l’adoption de bundles peut nécessiter un changement d’état d’esprit.

Par exemple, les développeurs Java sont utilisés pour créer des jars avec Maven ou Gradle, exécuter des tests unitaires avec JUnit et intégrer ces étapes dans des pipelines CI/CD. De même, les développeurs Python empaquetent souvent du code dans des roues et testent avec pytest, tandis que les développeurs SQL se concentrent sur la validation des requêtes et la gestion des notebooks. Avec les offres groupées, ces flux de travail convergent vers un format plus structuré et plus prescriptif, mettant en évidence le code et l’infrastructure de regroupement pour un déploiement transparent.

Les sections suivantes expliquent comment les développeurs peuvent adapter leurs flux de travail pour tirer parti efficacement des offres groupées.

Pour commencer rapidement avec les offres groupées de ressources Databricks, essayez un tutoriel : Développer un travail avec des bundles de ressources Databricks ou développer des pipelines déclaratifs Spark Lakeflow avec des bundles de ressources Databricks.

Recommandations en matière de contrôle des sources CI/CD

Le premier choix que les développeurs doivent effectuer lors de l’implémentation de CI/CD est la façon de stocker et de version des fichiers sources. Les bundles vous permettent de contenir facilement tout ( code source, artefacts de build et fichiers de configuration) et de les localiser dans le même référentiel de code source, mais une autre option consiste à séparer les fichiers de configuration groupés des fichiers liés au code. Le choix dépend du flux de travail de votre équipe, de la complexité du projet et des exigences CI/CD, mais Databricks recommande les éléments suivants :

• Pour les petits projets ou le couplage étroit entre le code et la configuration, utilisez un référentiel unique pour la configuration du code et de l’offre groupée pour simplifier les flux de travail.
• Pour les équipes plus grandes ou les cycles de publication indépendants, utilisez des référentiels distincts pour la configuration du code et du bundle, mais établissez des pipelines CI/CD clairs qui garantissent la compatibilité entre les versions.

Que vous choisissiez de colocaliser ou de séparer vos fichiers liés au code de vos fichiers de configuration groupés, utilisez toujours des artefacts avec version, tels que des hachages de validation Git, lors du chargement vers Databricks ou du stockage externe pour garantir la traçabilité et les fonctionnalités de restauration.

Référentiel unique pour le code et la configuration

Dans cette approche, le code source et les fichiers de configuration de bundle sont stockés dans le même référentiel. Cela simplifie les flux de travail et garantit les modifications atomiques.

Exemple : Code Python dans un bundle

Cet exemple contient des fichiers Python et des fichiers groupés dans un dépôt :

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/
│   ├── my_pipeline.ipynb       # pipeline notebook
│   └── mypython.py              # Additional Python
└── README.md

Référentiels distincts pour le code et la configuration

Dans cette approche, le code source réside dans un référentiel, tandis que les fichiers de configuration de bundle sont conservés dans un autre. Cette option est idéale pour les équipes ou projets plus volumineux où des groupes distincts gèrent le développement d’applications et la gestion des flux de travail Databricks.

Exemple : projet et bundle Java

Dans cet exemple, un projet Java et ses fichiers se trouvent dans un référentiel et les fichiers groupés se trouvent dans un autre référentiel.

Référentiel 1 : fichiers Java

Le premier référentiel contient tous les fichiers liés à 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

• Les développeurs écrivent du code d’application dans src/main/java ou src/main/scala.
• Les tests unitaires sont stockés dans src/test/java ou src/test/scala.
• Sur une demande de tirage ou une validation, les pipelines CI/CD :
  • Compilez le code dans un fichier JAR, par exemple target/my-app-1.0.jar.
  • Chargez le fichier JAR sur un volume du catalogue Databricks Unity. Consultez télécharger le JAR.

Référentiel 2 : Fichiers groupés

Un deuxième référentiel contient uniquement les fichiers de configuration du bundle :

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

• La configuration du package databricks.yml et les définitions de tâches sont maintenues indépendamment.

• Le databricks.yml fait référence à l’artefact JAR chargé, par exemple :

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

Flux de travail CI/CD recommandé

Que vous colocalisiez ou séparez vos fichiers de code de vos fichiers de configuration groupés, un flux de travail recommandé serait le suivant :

1. Compiler et tester le code

   • Déclenché lors d’une demande de tirage ou d’une validation de la branche principale.
   • Compilez du code et exécutez des tests unitaires.
   • Sortie d’un fichier versionné, par exemple my-app-1.0.jar.

2. Chargez et stockez le fichier compilé, tel qu’un fichier JAR, dans un volume catalogue Databricks Unity.

   • Stockez le fichier compilé dans un volume Databricks Unity Catalog ou un dépôt d’artefacts comme AWS S3 ou Stockage Blob Azure.
   • Utilisez un schéma de contrôle de version lié aux hachages de validation Git ou au contrôle de version sémantique, par exemple dbfs:/mnt/artifacts/my-app-${{ github.sha }}.jar.

3. Valider l’offre groupée

   • Exécutez databricks bundle validate pour vous assurer que la databricks.yml configuration est correcte.
   • Cette étape garantit que les configurations incorrectes, par exemple, les bibliothèques manquantes, sont interceptées tôt.

4. Déployer l’offre groupée

   • Utilisez databricks bundle deploy pour déployer l'ensemble dans un environnement de préproduction ou de production.
   • Faites référence à la bibliothèque compilée chargée dans databricks.yml. Pour plus d’informations sur le référencement des bibliothèques, consultez les dépendances de bibliothèque Databricks Asset Bundles.

CI/CD pour le Machine Learning

Les projets Machine Learning présentent des défis CI/CD uniques par rapport au développement logiciel traditionnel. Lors de l’implémentation de CI/CD pour les projets ML, vous devrez probablement prendre en compte les éléments suivants :

• Coordination multi-équipe : les scientifiques des données, les ingénieurs et les équipes MLOps utilisent souvent différents outils et workflows. Databricks unifie ces processus avec MLflow pour le suivi des expériences, le partage delta pour la gouvernance des données et les bundles de ressources Databricks pour l’infrastructure en tant que code.
• Contrôle de version des données et des modèles : les pipelines ML nécessitent un suivi non seulement du code, mais également des schémas de données d’apprentissage, des distributions de fonctionnalités et des artefacts de modèle. Databricks Delta Lake fournit des transactions ACID et des déplacements temporels pour le contrôle de version des données, tandis que MLflow Model Registry gère la traçabilité des modèles.
• Reproductibilité entre les environnements : les modèles ML dépendent de combinaisons de données, de code et d’infrastructure spécifiques. Les bundles de ressources Databricks garantissent le déploiement atomique de ces composants dans les environnements de développement, de préproduction et de production avec des définitions YAML.
• Réentraînement et surveillance continus : les modèles se dégradent en raison de la dérive des données. Les travaux Lakeflow permettent de réentraîner automatiquement les pipelines, tandis que MLflow s’intègre à Prometheus et Databricks Data Quality Monitoring pour le suivi des performances.

Piles MLOps pour ML CI/CD

Databricks traite de la complexité du CI/CD ML via mlOps Stacks, une infrastructure de niveau production qui combine des bundles de ressources Databricks, des flux de travail CI/CD préconfigurés et des modèles de projet ML modulaires. Ces piles appliquent les meilleures pratiques tout en offrant la flexibilité nécessaire à une collaboration multi-équipes entre les rôles d’ingénierie des données, de science des données et de MLOps.

La collaboration ML CI/CD pourrait ressembler à ceci :

• Les ingénieurs en données valident les modifications de pipeline ETL dans un ensemble, déclenchant la validation automatisée du schéma et un déploiement intermédiaire.
• Les data scientists soumettent du code ML, qui exécute des tests unitaires et se déploie sur un environnement de préproduction pour les tests d’intégration.
• Les ingénieurs MLOps passent en revue les métriques de validation et favorisent les modèles vérifiés en production à l’aide du Registre MLflow.

Pour plus d’informations sur l’implémentation, consultez :

• MLOps Stacks bundle : instructions pas à pas pour l’initialisation et le déploiement du bundle.
• Référentiel GitHub MLOps Stacks : modèles préconfigurés pour l’entraînement, l’inférence et le CI/CD.

En alignant les équipes avec des offres groupées et des piles MLOps standardisées, les organisations peuvent simplifier la collaboration tout en maintenant l’auditabilité tout au long du cycle de vie du ML.

CI/CD pour les développeurs SQL

Les développeurs SQL utilisant Databricks SQL pour gérer les tables de diffusion en continu et les vues matérialisées peuvent tirer parti de l’intégration Git et des pipelines CI/CD pour rationaliser leurs flux de travail et gérer des pipelines de haute qualité. Avec l’introduction de la prise en charge de Git pour les requêtes, les développeurs SQL peuvent se concentrer sur l’écriture de requêtes tout en tirant parti de Git pour contrôler leurs .sql fichiers, ce qui permet la collaboration et l’automatisation sans avoir besoin d’une expertise approfondie de l’infrastructure. En outre, l’éditeur SQL permet une collaboration en temps réel et s’intègre en toute transparence aux flux de travail Git.

Pour les flux de travail centrés sur SQL :

• Fichiers SQL de contrôle de version

  • Stockez des fichiers .sql dans des référentiels Git à l’aide de dossiers Git Databricks ou de fournisseurs Git externes, par exemple GitHub, Azure DevOps.
  • Utilisez des branches (par exemple, développement, préproduction, production) pour gérer les modifications spécifiques à l’environnement.

• Intégrer des .sql fichiers dans des pipelines CI/CD pour automatiser le déploiement :

  • Validez les modifications de syntaxe et de schéma pendant les pull requests.
  • Déployez des fichiers .sql dans des flux de travail ou des travaux Databricks SQL.

• Paramétrer pour l’isolation de l’environnement

  • Utilisez des variables dans des .sql fichiers pour référencer dynamiquement des ressources spécifiques à l’environnement, telles que des chemins de données ou des noms de tables :

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

• Planifier et surveiller les actualisations

  • Utilisez des tâches SQL dans un travail Databricks pour planifier les mises à jour des tables et des vues matérialisées (REFRESH MATERIALIZED VIEW view_name).
  • Surveillez l’historique des actualisations à l’aide de tables système.

Un flux de travail peut être :

1. Développer : écrivez et testez .sql des scripts localement ou dans l’éditeur SQL Databricks, puis validez-les dans une branche Git.
2. Valider : Lors d’une demande de tirage, validez la compatibilité de la syntaxe et du schéma à l’aide de vérifications automatisées de l’intégration continue.
3. Déployer : lors de la fusion, déployez les scripts .sql dans l’environnement cible à l’aide de pipelines CI/CD, par exemple GitHub Actions ou Azure Pipelines.
4. Moniteur : Utilisez des tableaux de bord et des alertes Databricks pour suivre les performances des requêtes et la fraîcheur des données.

CI/CD pour les développeurs de tableaux de bord

Databricks prend en charge l’intégration de tableaux de bord dans des flux de travail CI/CD à l’aide de Bundles de ressources Databricks. Cette fonctionnalité permet aux développeurs de tableaux de bord de :

• Les tableaux de bord de contrôle de version, qui garantissent l’audit et simplifient la collaboration entre les équipes.
• Automatisez les déploiements de tableaux de bord, de tâches et de pipelines dans les différents environnements, pour un alignement de bout en bout.
• Réduisez les erreurs manuelles et assurez-vous que les mises à jour sont appliquées de manière cohérente entre les environnements.
• Conservez des flux de travail d’analytique de haute qualité tout en respectant les meilleures pratiques CI/CD.

Pour les tableaux de bord dans CI/CD :

• Utilisez la databricks bundle generate commande pour exporter des tableaux de bord existants en tant que fichiers JSON et générer la configuration YAML qui l’inclut dans le bundle :

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

• Stockez ces .lvdash.json fichiers dans les référentiels Git pour suivre les modifications et collaborer efficacement.

• Déployez automatiquement les tableaux de bord dans les pipelines CI/CD avec databricks bundle deploy. Par exemple, l’étape GitHub Actions pour le déploiement :

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

• Utilisez des variables, par exemple ${var.warehouse_id}, pour paramétrer des configurations telles que des entrepôts SQL ou des sources de données, ce qui garantit un déploiement transparent entre les environnements de développement, de préproduction et de production.

• Utilisez l’option bundle generate --watch pour synchroniser en continu les fichiers JSON du tableau de bord local avec les modifications apportées dans l’interface utilisateur Databricks. En cas de disparités, utilisez l’indicateur --force pendant le déploiement pour remplacer les tableaux de bord distants par des versions locales.

Pour plus d’informations sur les tableaux de bord dans les offres groupées, consultez la ressource de tableau de bord. Pour plus d’informations sur les commandes groupées, consultez bundle le groupe de commandes.