Flux de travail CI/CD 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 flux de travail CI/CD recommandés 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 tâches et des configurations d'espace de travail avec des bundles d'automatisation déclaratifs en 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 les ensembles d'automatisation déclarative ou Terraform.
  • AWS : GitHub Actions et packages d'automatisation déclarative ou Terraform.
  • GCP : Cloud Build et automatisation déclarative avec Bundles 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 des bundles d'automatisation déclarative pour déployer du code, des tâches et une infrastructure en tant qu’unité unique. Évitez la gestion en silo des notebooks, des bibliothèques et des flux de travail.

Ensembles d’automatisation déclarative pour CI/CD

Les automatisations déclaratives (anciennement connues sous le nom de Databricks Asset Bundles) offrent une approche puissante et unifiée pour gérer le code, les flux de travail et 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 bundles Automation déclaratifs, essayez un didacticiel : Développer un travail avec des bundles d’automatisation déclarative ou développer des pipelines avec des bundles Automation déclaratifs.

Gestion des sources

Les bundles vous permettent de contenir facilement tous les éléments ( code source, artefacts de build et fichiers de configuration) et de les localiser dans le même référentiel de code source, mais vous pouvez également 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 pour simplifier le partage des flux de travail et des meilleures pratiques, Databricks vous recommande d’utiliser un référentiel unique pour la configuration du code et de l’offre groupée.

De plus, Databricks recommande une stratégie de branchement basée sur les jonctions pour réduire les conflits de fusion et garantir que la branche principale est toujours dans un état déployable et utilise toujours des artefacts avec version, tels que les hachages de validation Git, lors du chargement vers Databricks ou le stockage externe pour garantir la traçabilité et les fonctionnalités de restauration.

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

Flux de travail CI/CD avec bundles

Un flux de travail simple recommandé à l’aide de bundles Automation déclaratifs est 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 Dépendances de bibliothèques d’offres groupées d'automatisation déclaratives.

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, OpenSharing pour la gouvernance des données et les bundles Automation déclaratifs 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. Delta Lake fournit des transactions ACID et des déplacements temporels pour le contrôle de version des données, tandis que le Registre de modèles MLflow 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 d’automatisation déclaratifs garantissent un déploiement atomique de ces composants dans les environnements de développement, de staging 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 aborde la complexité du CI/CD ML via MLOps Stacks, un cadre de niveau production qui combine des lots d'automatisation déclaratifs, des workflows 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 scientifiques des données envoient du code ML, qui exécute des tests unitaires et se déploie sur un espace de travail intermédiaire 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 d'automatisation déclarative. 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 des tableaux de bord dans des 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.