Bonnes pratiques pour les développeurs sur Databricks

Cette page fournit les meilleures pratiques pour votre cycle de vie d’ingénierie et de développement des données, notamment le contrôle de version, la gestion de l’environnement, les outils de développement et les déploiements gérés.

Gestion des sources

Contrôle de version de tous les fichiers

L’automatisation déclarative repose sur l’idée que si quelque chose n’est pas dans le contrôle de version, il n’existe pas. Par conséquent, Databricks vous recommande de gérer les versions de presque tous les fichiers, notamment :

• Tous les blocs-notes et fichiers sources (.py, .sql)
• Fichiers de configuration groupés (databricks.yml et remplacements YAML spécifiques à l’environnement)

Cependant, ne vous engagez pas à :

• créer des artefacts, tels que des fichiers .jar ou .whl. Au lieu de cela, téléchargez des binaires compilés vers les volumes d’Unity Catalog lors de l’intégration continue. Consultez télécharger le JAR.
• Jetons ou informations d’identification. Utilisez la gestion des secrets au niveau de l’espace de travail soutenue par un gestionnaire de secrets cloud (par exemple, AWS Secrets Manager ou Azure Key Vault) et synchronisez les valeurs dans des étendues de secrets Databricks. Consultez Gestion des secrets.
• Exemples et fichiers de données locales comportant des PII. Utilisez .gitignore pour les exclure.

Référentiel unique

Databricks vous recommande d’utiliser un référentiel unique pour l’ensemble de votre code (code source et fichiers de configuration), car il facilite la collaboration, le code et les meilleures pratiques de partage pour les humains et l’IA. Si vous avez plusieurs offres groupées pour des cycles de vie de déploiement distincts, conservez-les dans un seul référentiel.

L’une des exceptions à la recommandation de dépôt unique se trouve dans les secteurs réglementés où plusieurs référentiels sont nécessaires à des fins de confidentialité.

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, utilisez une stratégie de branchement basée sur les jonctions.

Un flux de travail simple serait :

1. Développez localement ou dans l’espace de travail et déployez dans un espace de travail de développement Databricks pour tester les modifications.
2. Créez une branche de fonctionnalité de courte durée pour contrôler les versions et synchronisez régulièrement les modifications apportées à votre espace de travail ou local.
3. Une fois le test terminé, fusionnez la branche de fonctionnalité dans la branche principale.
4. CI/CD déploie automatiquement la branche principale dans un espace de travail intermédiaire et des tests automatisés sont déclenchés.
5. Lorsque les tests intermédiaires et les vérifications réussissent, CI/CD déploie la branche principale dans un espace de travail de production.

Ces étapes sont décrites dans le diagramme suivant :

Configuration de l’espace de travail

Isoler les environnements d’espace de travail

Isolez les environnements d’espace de travail pour réduire l’impact d’un déploiement ayant échoué. Par exemple:

• Petites équipes (jusqu’à 5 ingénieurs données) : commencez par deux espaces de travail (développement et production) dans un compte cloud unique.
• Équipes croissantes (5 ingénieurs de données) : passez à trois espaces de travail (développement, préproduction et production). La préproduction doit être fonctionnellement représentative de la production, avec la même configuration des offres groupées , le même schéma et les mêmes intégrations critiques, même à plus petite échelle.
• Secteurs réglementés (banques, soins de santé, défense) : isolez physiquement les espaces de travail et les comptes cloud pour empêcher les fuites de données. Il est possible de gérer l’isolation à l’aide des périmètres définis par IAM et Unity Catalog au sein d’un seul compte, mais cela offre une posture de sécurité moins robuste.

Pour les espaces de travail de production, utilisez le calcul sans serveur avec des stratégies de réseau lorsque cela est possible. Sinon, configurez des comptes cloud pour utiliser des sous-réseaux privés ou des réseaux virtuels avec des contrôles de sortie et de sécurité réseau étroitement contrôlés.

Pour plus d’informations, consultez Stratégies réseau basées sur le contexte.

Isoler le stockage des données

• Utilisez un metastore Unity Catalog unique et créez des catalogues séparés pour le développement, la préproduction (le cas échéant) et la production, en reflétant l’organisation de votre espace de travail.
• Utilisez des schémas personnels pour chaque développeur dans les catalogues de développement et de préproduction (hors production).
• En mode ISOLATED, lier le catalogue de production à l’espace de travail de production uniquement. Définir le mode d’isolation d’un catalogue sur ISOLATED garantit que les données de production sont inaccessibles depuis des environnements de développement ou de préproduction, même si une identité est mal configurée.
• Réservez des metastores, des comptes ou des régions distincts uniquement pour les organisations ayant des exigences réglementaires, de souveraineté des données ou de plusieurs régions que l’isolation au niveau du catalogue ne peut pas satisfaire.

Traiter les métadonnées de table et de colonne en tant que code

Traitez les commentaires de table et de colonne dans le cadre de votre code. Conservez-les dans des fichiers .sql aux côtés de vos définitions de packages d’automatisation déclarative, et déployez-les au moyen d’une tâche de métadonnées afin que des définitions précises et destinées aux utilisateurs métier soient toujours disponibles. Écrivez des commentaires qui décrivent ce qu’une ligne représente, les unités et les valeurs valides en langage brut plutôt que de répéter le nom de colonne.

Configurer des schémas personnels

Pendant le développement, configurez des bundles pour utiliser un schéma personnel par utilisateur, par exemple dev_${user_name}. Cela empêche les développeurs de remplacer les tables des autres dans un espace de travail partagé.

Utiliser le calcul sans serveur

Utilisez le calcul serverless pour simplifier la gestion des clusters et optimiser les coûts. Voir Connexion à l'informatique sans serveur.

Recommandations CI/CD

Bundles d'Automation 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.

Pour plus d’informations sur l’utilisation de bundles pour les flux de travail CI/CD, consultez flux de travail CI/CD sur Databricks.

Pour plus d’informations sur les bundles Automation déclaratifs, consultez Qu’est-ce que les bundles Automation déclaratifs ?.

Utiliser Terraform uniquement pour les ressources externes

Utilisez Terraform pour définir les ressources suivantes :

• Ressources cloud et externes
• Les actions d’administration que les utilisateurs non privilégiés ne doivent pas effectuer, telles que l’approvisionnement de l’espace de travail ou la configuration réseau cloud

Utilisez des bundles d’automatisation déclaratifs pour toutes les autres ressources Databricks.

Gestion des offres groupées

Créer de petits ensembles groupés

Databricks recommande de développer des bundles petits et ciblés plutôt qu’un seul bundle volumineux.

• Placez tout ce qu’une seule équipe possède dans un bundle.
• Testez et déployez via le même pipeline CI/CD qui partage la même cadence de cycle de vie et de mise en production.
• Chaque bundle doit couvrir tous les environnements d’un projet donné (développement, préproduction, production) plutôt que d’utiliser des bundles distincts par environnement.

Créez des offres groupées distinctes pour :

• Différents produits ou domaines, par exemple « Analytique de facturation » et « Détection des fraudes »
• Limites de propriété ou d’autorisation différentes
• Charges de travail avec des cycles de vie clairement différents
• Cas nécessitant une promotion ou un retour arrière indépendants

Utiliser sync.paths pour synchroniser des dossiers partagés

Lors de la gestion de plusieurs bundles dans un référentiel, utilisez cette option sync.paths pour synchroniser les dossiers partagés à partir de l’extérieur de la racine du bundle. Cela permet à différents projets de partager un dossier de bibliothèque commun, tel que ../common, tout en conservant des identités de déploiement distinctes.

Modéliser les dépendances entre bundles dans le CI/CD

Lorsque le bundle B dépend de ressources publiées par le bundle A, modélisez cette dépendance dans votre couche CI/CD ou d’orchestration plutôt que de regrouper les deux dans un seul bundle.

• Définissez le flux de travail de déploiement et de publication de Bundle A comme prérequis explicite pour Bundle B. Configurez votre pipeline de sorte que Bundle B ne démarre qu’après le succès du déploiement de Bundle A et la réussite de toutes les vérifications de validation requises.
• Transmettez en aval les identificateurs ou emplacements des ressources publiées comme entrées du pipeline, et faites échouer immédiatement le processus si des ressources en amont sont manquantes. Cela garantit Cela garantit qu'une offre groupée B ne se déploie jamais dans un état partiellement publié.

Pour plus d’informations sur le partage d’offres groupées, consultez Partage de bundles et de fichiers groupés.

Modèles de bundle personnalisés

Utilisez des modèles Declarative Automation Bundles personnalisés comme point de départ par défaut pour les nouveaux projets afin que chaque projet hérite des mêmes garde-fous - autorisations, balisage, stratégies de cluster, câblage CI/CD et lignes de base d’instance , sans que chaque équipe résolve à partir de zéro.

Les modèles doivent encoder des conventions partagées et durables telles que la gouvernance, les valeurs par défaut des performances, la disposition de l’environnement et les limites de quota. Évitez la logique métier spécifique à l’application, les secrets ou la configuration ponctuelle dans les modèles.

Paramétrez uniquement les entrées censées varier selon l’équipe, le projet ou l’environnement :

• Nom du projet ou de l’application
• Paramètres de l’espace de travail cible
• Noms de catalogue ou de schéma
• Identificateurs de service principal
• Planifications et paramètres de notification

Conservez les garde-fous de plateforme et les valeurs par défaut partagées fixes dans le modèle plutôt que de les paramétrer.

Pour obtenir des informations sur les modèles de bundle personnalisés et sur la façon de les créer, consultez Modèles de projet pour les bundles d’automatisation déclarative.

Prévoir des retours en arrière et des correctifs urgents

Conservez des lots suffisamment petits afin de pouvoir effectuer un retour en arrière ciblé sur un seul lot, plutôt que de coordonner un retour en arrière sur de nombreuses charges de travail sans rapport.

Pendant un incident :

1. Rétablissez l'offre groupée affectée à la dernière version stable connue.
2. Utilisez un correctif d’urgence uniquement pour des corrections urgentes et de portée limitée qui ne peuvent pas attendre le cycle de promotion habituel.
3. Fusionnez n’importe quel correctif logiciel vers la branche principale immédiatement après la validation afin que la jonction reste la seule source de vérité.

Développement général

Utiliser les principaux de service ou OIDC

Utilisez des principaux de service pour toutes les automatisations sans développement pour dissocier les flux de travail automatisés des comptes d’utilisateur individuels et garantir que les travaux continuent à s’exécuter lorsque les utilisateurs internes quittent. Consultez Principaux de service.

• Utilisez des identités de service distinctes pour le déploiement et l’exécution. Un principal de service de déploiement dédié pour les déploiements groupés doit disposer d’un accès minimal aux données. Chaque tâche de production ou pipeline doit avoir son propre principal de service utilisé pour l’exécution, limité aux seules données et ressources nécessaires à cette charge de travail. Cette séparation garantit que les déploiements restent sécurisés lorsque vous effectuez une rotation ou un renforcement des autorisations d’accès aux données et évitez de combiner les modifications d’infrastructure apportées à l’accès aux données de production.
• Secteurs réglementés : utilisez la fédération d’identités de charges de travail (OIDC) pour le CI/CD. Cela élimine les secrets de longue durée dans GitHub Actions ou Azure DevOps. Consultez Activer la fédération des identités de charge de travail dans CI/CD.

Utiliser les outils de développement Databricks

Développez dans l’interface utilisateur de l’espace de travail Databricks à l’aide de Dossiers Git ou dans un IDE local. Si vous utilisez Visual Studio Code ou un fork compatible, installez l’extension Databricks officielle pour :

• Compétences de l’agent spécifique à Databricks
• Accès au catalogue Unity et au système de fichiers
• Capacités de développement à distance pour exécuter des charges de travail sur les ressources de calcul Databricks

Pour plus d’informations, consultez l’extension Databricks pour Visual Studio Code.

Réduire la logique métier dans les notebooks

Ne traitez pas les blocs-notes comme conteneur principal pour la logique métier. Utilisez-les uniquement pour l’exploration et la visualisation.

• Python : placez la logique principale dans des modules importables dans src/ ou src/py/, et appelez ces fonctions depuis des notebooks.
• SQL : conservez les requêtes dans des fichiers .sql dans src/ ou src/sql/, et référencez ces fichiers à partir de tâches et de pipelines plutôt que d’intégrer le SQL directement dans les notebooks.

Utilisez les notebooks uniquement comme couches légères d’orchestration et de visualisation qui appellent le code sous-jacent. Cette approche facilite le test et la réutilisation.

Lors de la migration d’un projet comportant de nombreux notebooks, effectuez cette migration de manière incrémentielle. Extrayez un module réutilisable ou un fichier SQL à la fois et utilisez des bundles Automation déclaratifs pour placer les ressources migrées sous le même flux de travail de déploiement et de test que le reste du projet.

Transmettre le contexte dynamiquement

Évitez les variables statiques pour les dépendances de tâche. Utilisez des références de valeur dynamique comme {{tasks.<task_key>.values.<value_key>}} pour passer le contexte d’exécution entre les tâches d’un travail en plusieurs étapes.

Test et observabilité

Implémenter des couches de test

Utilisez trois couches de test qui correspondent à la façon dont vos offres groupées évoluent vers la production :

1. Tests unitaires : conservez la logique métier dans des modules importables src/ et couvrez-la avec pytest ou un framework équivalent. Exécutez-les à chaque pull request afin que les échecs bloquent la fusion.
2. Validation du lot : exécutez bundle validate localement. Dans CI, préférez bundle deploy à un espace de travail hors production pour intercepter les problèmes de mappage de ressources et YAML avant le déploiement de la production.
3. Tests d’intégration en préproduction : après le déploiement vers la préproduction, exécutez des travaux de bout en bout avec des vérifications d’achèvement et des assertions critiques de qualité des données, telles que le nombre de lignes ou les attentes de schéma.

Considérez « tous les tests réussissent sur la branche principale et sur l’environnement de préproduction » comme le critère de validation pour promouvoir les artefacts en production.

Pour les pipelines déclaratifs Spark Lakeflow, utilisez les fonctionnalités de développement et de validation intégrées plutôt que les exécutions de notebook ad hoc. Testez la logique de pipeline sur de petits jeux de données représentatifs qui incluent des enregistrements avec des erreurs et utilisez le mode de développement pour valider les modifications avant de mettre à jour les tables de production.

Considérez la journalisation comme faisant partie du déploiement

Pour les charges de travail déployées par les bundles Automation déclaratifs, traitez les métriques et la journalisation dans le cadre du contrat de déploiement plutôt que d’un élément défini indépendamment par chaque projet.

• Émettez des journaux structurés de manière cohérente entre les travaux, les pipelines et les tâches. Incluez le nom de l’offre groupée, l’environnement cible, le nom de la charge de travail, l’identificateur d’exécution et tout identificateur métier nécessaire pour suivre les échecs.
• Suivez un ensemble standard de métriques opérationnelles pour chaque charge de travail de production : état d’exécution, durée, nombre de nouvelles tentatives et indicateurs de débit ou de fraîcheur, le cas échéant.
• Encoder ces conventions dans les bibliothèques partagées, les définitions de charge de travail réutilisables ou les modèles de bundle afin que les équipes n’aient pas à recréer des modèles d’observabilité pour chaque projet.