Aller au contenu principal
Dernière mise à jour le

Workflows CI/CD sur Databricks

Le CI/CD (fonctionnalités d’intégration et de livraison continues (CI/CD)) est devenu un pilier de la Data Engineering des données et de l'analytique modernes, 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 des exigences CI/CD diverses, façonnées par vos préférences organisationnelles, les workflows existants et votre environnement technologique spécifique, et fournit un cadre flexible qui prend en charge diverses options CI/CD.

Cette page décrit les workflows CI/CD recommandés pour vous aider à concevoir et à créer des pipelines CI/CD robustes et personnalisés qui correspondent à vos besoins et contraintes uniques. En tirant parti de ces insights, vous pouvez accélérer vos initiatives en matière de data engineering et d'analytique, 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, quelles que soient les spécificités de l'implémentation. Les meilleures pratiques universelles suivantes s'appliquent à toutes les préférences organisationnelles, workflows de développeurs et environnements cloud, et garantissent la cohérence des diverses implémentations, que votre équipe privilégie le développement basé sur les Notebooks ou les workflows Infrastructure-as-Code. Adoptez ces principes comme garde-fous tout en adaptant les spécificités à la pile technologique et aux processus de votre organisation.

  • Mettez tout sous contrôle de version.

    • Stockez les Notebooks, les scripts, les définitions d'infrastructure (IaC) et les configurations de Job 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 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 pour Scala.
    • Validez la fonctionnalité du notebook et du workflow avec des outils, tels que Databricks CLI bundle validate.
    • Utilisez des tests d'intégration pour les workflows et les pipelines de données, tels que chispa pour les DataFrames Spark.

  • Employer l'infrastructure en tant que code (IaC)

    • Définissez les clusters, les jobs et les configurations du workspace avec Declarative Automation Bundles YAML ou Terraform.
    • Paramétrisez plutôt que de coder en dur des paramètres spécifiques à l'environnement, tels que la taille des clusters et les secrets.

  • Isoler les environnements

    • Maintenez des workspaces séparés pour le développement, la préproduction et la production.
    • Utilisez MLflow Model Registry pour la gestion des versions de modèles dans tous les environnements.

  • Choisissez les outils qui correspondent à votre écosystème cloud :

    • Azure : Azure DevOps et Bundles d'automatisation déclarative ou Terraform.
    • AWS : GitHub Actions et Declarative Automation Bundles ou Terraform.
    • GCP : Cloud Build et Declarative Automation Bundles ou Terraform.

  • Surveiller et automatiser les restaurations

    • Suivez les taux de réussite des déploiements, les performances des Jobs et la couverture des tests.
    • Implémentez des mécanismes de restauration automatisés pour les déploiements ayant échoué.

  • Unifier la gestion des asset

    • Utilisez les Declarative Automation Bundles pour déployer du code, des Jobs et l'infrastructure comme une unité unique. Évitez la gestion cloisonnée des Notebooks, des bibliothèques et des workflows.
remarque

Databricks recommande la fédération d'identité de Workload pour l'authentification CI/CD. La fédération d'identité de Workload élimine le besoin de secrets Databricks, ce qui en fait le moyen le plus sécurisé d'authentifier vos flux automatisés auprès de Databricks. Voir Activez la fédération d'identité de Workload dans CI/CD.

Declarative Automation Bundles pour CI/CD​

Les Declarative Automation Bundles (anciennement connus sous le nom de Databricks Asset Bundles) offrent une approche puissante et unifiée pour gérer le code, les workflows et l'infrastructure au sein de l'écosystème Databricks et sont recommandés pour vos pipelines CI/CD. En regroupant ces éléments dans une seule unité définie en YAML, les bundles simplifient le déploiement et garantissent la cohérence entre les environnements. Cependant, pour les utilisateurs habitués aux workflows CI/CD traditionnels, l'adoption des bundles peut nécessiter un changement de mentalité.

Par exemple, les développeurs Java ont l'habitude de créer des fichiers JAR avec Maven ou Gradle, d'exécuter des tests unitaires avec JUnit et d'intégrer ces étapes dans des pipelines CI/CD. De même, les développeurs Python empaquettent souvent le code dans des roues (wheels) et le testent avec pytest, tandis que les développeurs SQL se concentrent sur la validation des requêtes et la gestion des notebooks. Avec les bundles, ces workflows convergent vers un format plus structuré et prescriptif, mettant l'accent sur le regroupement du code et de l'infrastructure pour un déploiement transparent.

Les sections suivantes explorent comment les développeurs peuvent adapter leurs workflows pour exploiter efficacement les bundles.

Pour commencer rapidement avec les Declarative Automation Bundles, essayez un tutoriel : Développer un job avec des Declarative Automation Bundles ou Développer des pipelines avec des Declarative Automation Bundles.

Contrôle de source​

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 repository de code source, mais vous pouvez également séparer les fichiers de configuration du bundle des fichiers liés au code. Le choix dépend du workflow de votre équipe, de la complexité du projet et des exigences CI/CD, mais pour simplifier les workflows et le partage des meilleures pratiques, Databricks vous recommande d'utiliser un seul repository pour le code et la configuration du bundle.

De plus, Databricks recommande une stratégie de Branching basée sur le tronc afin de minimiser les conflits de Merge et de s'assurer que la Branch principale est toujours dans un état déployable, et d'utiliser toujours des artefacts versionnés, tels que les hachages de commit Git, lors de l'upload vers Databricks ou un stockage externe afin de garantir la traçabilité et les capacités de restauration.

Pour plus d'informations sur ces bonnes pratiques, consultez Contrôle de code source.

Workflow CI/CD avec des bundles​

Un workflow simple recommandé utilisant les Declarative Automation Bundles est le suivant :

  1. Compiler et tester le code

    • Déclenché sur une pull request ou un commit vers la Branch principale.
    • Compilez le code et exécutez les tests unitaires.
    • Générez un fichier versionné, par exemple, my-app-1.0.jar.

  2. Upload et stockez le fichier compilé, tel qu'un JAR, dans un volume Databricks Unity Catalog.

    • Stockez le fichier compilé dans un volume Unity Catalog Databricks ou un repository d'artefacts comme AWS S3 ou Azure Blob Storage.
    • Utilisez un schéma de versioning lié aux hachages de commit Git ou au versioning sémantique, par exemple, dbfs:/mnt/artifacts/my-app-${{ github.sha }}.jar.

  3. Validez le bundle

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

  4. Déployer le bundle

    • Utilisez databricks bundle deploy pour déployer le bundle vers un environnement de préproduction ou de production.
    • Référencez la bibliothèque compilée upload dans databricks.yml. Pour des information sur le référencement des bibliothèques, consultez Declarative Automation Bundles library dependencies.

CI/CD pour le Machine Learning​

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

  • Coordination multi-équipes : les data scientists, les ingénieurs et les équipes MLOps utilisent souvent des outils et des workflows différents. Databricks unifie ces processus avec MLflow pour le suivi d'expérimentation, OpenSharing pour la gouvernance des données et les Bundles d'automatisation déclaratifs pour l'infrastructure-as-code.
  • Gestion des versions des données et des modèles : les Pipelines de ML nécessitent le suivi non seulement du code, mais aussi des schémas de données d'entraînement, des distributions de caractéristiques et des artefacts de modèle. Delta Lake fournit des Transactions ACID et du time travel pour le versioning des données, tandis que MLflow Model Registry gère la lignée des modèles.
  • Reproductibilité entre les environnements : les modèles ML dépendent de combinaisons spécifiques de données, de code et d'infrastructure. Les Declarative Automation Bundles 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 monitoring continus : les modèles se dégradent en raison de la drift des données. Les Lakeflow Jobs permettent des pipelines de réentraînement automatisées, tandis que MLflow s'intègre à Prometheus et au Monitoring de la qualité des données Databricks pour le suivi des performances.

Piles MLOps pour ML CI/CD​

Databricks aborde la complexité du ML CI/CD par le biais des MLOps Stacks, un framework de niveau production qui combine des Declarative Automation Bundles, des workflows CI/CD préconfigurés et des Template de projet ML modulaires. Ces piles appliquent les meilleures pratiques tout en permettant une flexibilité pour la collaboration multi-équipes entre les rôles de Data Engineering, Data Science et MLOps.

L'équipe

Responsabilités

Exemple de composants de bundle

Exemples d'artefacts

Data engineers

Créez des pipelines ETL, appliquez la qualité des données

LakeFlow Pipelines YAML, politiques de cluster

etl_pipeline.yml, feature_store_job.yml

Data Scientists

Développez la logique d'entraînement du modèle, validez les métriques

Projets MLflow, workflows basés sur des Notebooks

train_model.yml, batch_inference_job.yml

Ingénieurs MLOps

Orchestrer les déploiements, superviser les pipelines

Variables d'environnement, tableaux de bord de monitoring

databricks.yml, lakehouse_monitoring.yml

L'équipe

Responsabilités

Exemple de composants de bundle

Exemples d'artefacts

Data engineers

Créez des pipelines ETL, appliquez la qualité des données

LakeFlow Pipelines YAML, politiques de cluster

etl_pipeline.yml, feature_store_job.yml

Data Scientists

Développez la logique d'entraînement du modèle, validez les métriques

Projets MLflow, workflows basés sur des Notebooks

train_model.yml, batch_inference_job.yml

Ingénieurs MLOps

Orchestrer les déploiements, superviser les pipelines

Variables d'environnement, tableaux de bord de monitoring

databricks.yml, lakehouse_monitoring.yml

La collaboration ML CI/CD pourrait ressembler à :

  • Les data engineers commit les modifications de pipeline ETL dans un bundle, triggering 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 dans un workspace de préproduction pour les tests d'intégration.
  • Les ingénieurs MLOps examinent les métriques de validation et promeuvent les modèles validés en production à l'aide du registre MLflow.

Pour plus de détails sur l'implémentation, voir :

En alignant les équipes sur des offres standardisées et des piles MLOps, les organisations peuvent simplifier la collaboration tout en maintenant la traçabilité tout au long du cycle de vie ML.

CI/CD pour les développeurs SQL​

Les développeurs SQL utilisant Databricks SQL pour gérer les tables de streaming et les vues matérialisées peuvent exploiter l'intégration Git et les pipelines CI/CD pour rationaliser leurs workflows et maintenir des pipelines de haute qualité. Avec l'introduction de la prise en charge Git pour les queries, les développeurs SQL peuvent se concentrer sur l'écriture de queries tout en tirant parti de Git pour le contrôle de version de leurs fichiers .sql, ce qui permet la collaboration et l'automatisation sans nécessiter une expertise approfondie de l'infrastructure. De plus, l'éditeur SQL permet une collaboration en temps réel et s'intègre parfaitement aux workflows Git.

Pour les workflows centrés sur SQL :

  • Contrôle de version des fichiers SQL

    • Stocker .sql fichiers dans des repositories Git à l'aide de dossiers Git Databricks ou de fournisseurs Git externes, par exemple, GitHub, Azure DevOps.
    • Utilisez des branches (par exemple, développement, staging, production) pour gérer les changements spécifiques à l'environnement.

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

    • Valider la syntaxe et les modifications de schéma lors des pull requests.
    • Déployer .sql fichiers vers les workflows ou Jobs Databricks SQL.

  • Paramétrer pour l'isolation des environnements

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

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

  • Planifiez et surveillez les refresh

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

Un workflow peut être :

  1. Développer : Écrire et tester des scripts .sql localement ou dans l'éditeur Databricks SQL, puis les commit sur une Branch Git.
  2. Valider : pendant une pull request, validez la syntaxe et la compatibilité du schéma à l'aide de contrôles CI automatisés.
  3. Déployer : Après Merge, déployer le fichier .sql des scripts vers l'environnement cible à l'aide de pipelines CI/CD, par exemple, GitHub Actions ou Azure Pipelines.
  4. Surveillez : utilisez les tableaux de bord et les 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 les workflows CI/CD à l'aide de Declarative Automation Bundles. Cette fonctionnalité permet aux développeurs de tableaux de bord de :

  • Tableaux de bord à contrôle de version, ce qui garantit la traçabilité et simplifie la collaboration entre les équipes.
  • Automatisez les déploiements de tableaux de bord ainsi que des Jobs et des pipelines dans tous les 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 dans les environnements.
  • Maintenez des flux de travail analytique de haute qualité tout en respectant les meilleures pratiques de CI/CD.

Pour les tableaux de bord dans CI/CD :

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

    YAML
    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 des repository Git pour suivre les modifications et collaborer efficacement.

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

    YAML
    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 comme les SQL Warehouse ou les sources de données, afin d'assurer 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 de Databricks. Si des écarts se produisent, utilisez l'indicateur --force pendant le déploiement pour écraser les tableaux de bord distants avec les versions locales.

Pour des informations sur les tableaux de bord dans les bundles, consultez la Ressource de tableau de bord. Pour plus de détails sur les commandes de bundle, consultez le groupe de commandesbundle.

Sur cette page