Tutoriel : Comment déployer en toute sécurité et à grande échelle les modifications de tableaux de bord d'IA/BI avec les Databricks Asset Bundles

L'idée qu'une réunion du conseil d'administration commence par un tableau de bord rempli d'erreurs devrait empêcher les équipes analytiques de dormir la nuit. Il en va de même lorsqu'on découvre après coup qu'un plan d'embauche, un lancement de produit ou une prévision de revenus était basé sur une métrique incorrecte. Ou qu'une équipe de support a émis beaucoup trop de remboursements parce qu'un tableau de bord a mal représenté l'historique d'achat d'un client.

Ces échecs sont rarement causés par une mauvaise analyse. Comme pour tout système de production, ils résultent souvent de la mise à jour manuelle des tableaux de bord à mesure que les modèles de données et les exigences évoluent : sans gestion des versions, sans processus de révision fiable ou sans méthode reproductible pour promouvoir les changements dans les différents environnements.

Cet billet de blog défend une idée simple : les tableaux de bord de production qui pilotent l'activité doivent être gérés avec la même rigueur que le code de production. Étant donné que Databricks AI/BI s'exécute sur la même Data Intelligence Platform que vos pipelines de données et votre couche de gouvernance, les équipes peuvent également appliquer ces mêmes pratiques de production (contrôle de version, configuration spécifique à l'environnement et déploiement contrôlé) aux tableaux de bord.

Pour illustrer cela concrètement, nous présenterons comment les analystes peuvent utiliser les fonctionnalités Databricks de qualité production sans changer leur façon de créer des tableaux de bord au quotidien.

Plus précisément, nous allons vous montrer comment ce flux vous permet de :

• Examinez et approuvez chaque modification apportée à un tableau de bord
• Suivre l'historique d'un tableau de bord et lier les modifications de code aux exigences métier
• Restaurer une version antérieure d'un tableau de bord

Prérequis :

Ce workflow requiert une configuration ponctuelle de l'infrastructure que la plupart des organisations ont déjà mise en place. Si vous ne les avez pas déjà, demandez à votre équipe DevOps ou IT interne de vous aider à effectuer la configuration :

• Au moins deux Databricks workspaces (par exemple, un développement workspace et un production workspace) pour créer, tester et déployer des tableaux de bord
• Dossiers basés sur Git dans Databricks (AWS | Azure | GCP), utilisés pour versionner les définitions de tableaux de bord
• Databricks Asset Bundles (DABs) (AWS | Azure | GCP) configurés pour le projet

Introduction : Un workflow structuré pour le déploiement sécurisé des modifications de tableau de bord.

Nous allons parcourir un scénario réaliste : vous possédez un tableau de bord Performance des ventes utilisé chaque semaine par la direction financière et commerciale. Il s'agissait au départ d'un projet de stagiaire créé directement dans un workspace, mais il a évolué au fil du temps et est maintenant utilisé dans plusieurs examens par les dirigeants.

Un changement de priorités suite à une réunion du conseil d'administration entraîne une nouvelle exigence : le service financier doit désormais suivre les montants des ventes engagées et non engagées, en remplacement d'une seule métrique de ventes agrégée, et le tableau de bord doit refléter cette nouvelle définition avant la prochaine révision des prévisions.

Ces valeurs alimentent directement de réelles décisions commerciales, y compris les calculs de rémunération et de bonus. Prenons donc ce tableau de bord et mettons-le pour la première fois sur un chemin de déploiement rigoureux.

Étape 1 : Ajoutez le tableau de bord dans un Databricks Asset Bundle

Avant de commencer le processus, collaborez avec votre service IT pour configurer certains outils de code de base : un repository Git avec un « Databricks Asset Bundle » vide et des scripts CI/CD pour déployer automatiquement le bundle.

Un repository Git est un outil permettant de suivre les modifications de fichiers. Pour start, nous devons le connecter à Databricks afin de pouvoir suivre les modifications apportées à la configuration du tableau de bord. Depuis l'espace de travail Databricks, créez un dossier Git et collez l'URL du repository dans la boîte de dialogue de configuration. Databricks est ainsi informé de l'existence du repository et nous pouvons y ajouter le tableau de bord à l'étape suivante.

Un Databricks Asset Bundle est un moyen de regrouper des fichiers de code (dans ce cas, un tableau de bord). Si le repository contient déjà un bundle, il est automatiquement détecté et peut être ouvert à l'aide de l'icône flèche. Sinon, un nouveau bundle peut être créé à partir du menu Créer dans le dossier Git.

Dans l'éditeur d'Asset Bundle, vous pouvez ajouter de nouveaux composants et des composants existants au bundle qui est actuellement vide. Pour inclure le tableau de bord, ouvrez le menu Ajouter et sélectionnez Ajouter un tableau de bord existant. Après l'avoir ajouté, vous verrez le tableau de bord apparaître dans le dossier src en tant qu'élément du bundle.

À partir de ce moment, le tableau de bord est géré comme un asset déployable, ce qui facilite la promotion du même tableau de bord dans les Workspaces de développement, de test et de production.

Enfin, validez le tableau de bord dans le dépôt. Cette opération enregistre l'état actuel du tableau de bord comme référence et établit un point de départ clair pour suivre et réviser les modifications futures.

Vous verrez que le tableau de bord a été ajouté au repository, ainsi que quelques fichiers de configuration générés automatiquement (se terminant par .yml). Ces fichiers décrivent la manière dont le tableau de bord doit être déployé dans différents environnements — vous n'avez pas besoin de les modifier.

Ajoutez une courte note décrivant ce que vous avez fait dans le champ message de commit, puis sélectionnez Commit & Push. Cela crée un point de contrôle pour le tableau de bord (un état fonctionnel connu auquel vous pourrez revenir plus tard), afin que les modifications futures puissent être comparées, examinées et déployées en toute sécurité.

Étape 2 : Mettre à jour le tableau de bord

Maintenant que le tableau de bord existant a été committé, vous pouvez commencer à y apporter des modifications sans affecter ce qui est déjà en production et Git suivra les modifications spécifiques que vous avez apportées.

La pratique générale consiste à créer une branche Git, une version du tableau de bord sur laquelle travailler sans affecter les autres. Vous pouvez le faire via le bouton Créer une branche, puis lui donner un nom descriptif comme votre nom, une fonctionnalité ou un numéro de ticket associé à la modification. Considérez cela comme une version privée pour votre mise à jour : vous pouvez modifier, tester et affiner librement le tableau de bord, puis décider séparément quand vos modifications sont prêtes à être examinées et déployées.

Vous pouvez maintenant apporter les modifications au tableau de bord ! Dans ce cas, vous modifierez le chiffre des ventes en haut à gauche pour ajouter des compteurs de ventes non engagées et engagées (bleu et rouge en gras choisis pour la visibilité).

Vous remarquerez que rien ne change dans l'expérience de création : effectuez ces modifications comme vous le feriez normalement à l'aide de l'éditeur d'interface utilisateur du tableau de bord.

Une fois que le tableau de bord semble correct en développement, vous êtes prêt à appliquer les modifications en production. Utilisez le même bouton Git en haut que précédemment pour enregistrer ces modifications avec un court message de commit.

Étape 3 : Examiner la modification

Ensuite, vous profitez d'un autre avantage clé de ce workflow : un endroit où d'autres personnes peuvent examiner les modifications et donner leur avis avant que la modification n'atteigne la production. Le fait de nécessiter l'examen par une deuxième personne est une bonne pratique générale, mais il est tout aussi important de noter que cela crée un espace sans enjeu pour discuter des idées, valider les hypothèses et affiner la modification avant qu'elle n'ait un impact sur le reporting.

Pour start l'examen, créez une Pull Request (PR) dans votre fournisseur Git, qui est essentiellement une page d'examen pour la mise à jour du tableau de bord. L'examinateur peut voir exactement ce qui a changé, laisser des commentaires à traiter et approuver la mise à jour une fois que tout semble correct.

Pendant la révision, le tableau de bord de production reste inchangé. Ce n'est qu'une fois les commentaires pris en compte et la modification approuvée que celle-ci est mise en œuvre.

Bien que les modifications du tableau de bord soient stockées et suivies en tant que fichiers de configuration en arrière-plan, il est souvent difficile de comprendre ce qui a réellement changé. Pour cette raison, la plupart des équipes utilisent une petite automatisation pour déployer automatiquement une version de test temporaire du tableau de bord pour révision chaque fois qu'une PR est ouverte. De cette façon, les réviseurs peuvent voir les métriques, les calculs et les Layouts proposés en contexte avant que quoi que ce soit n'arrive en production, et détecter les problèmes de logique de données ou d'interface utilisateur. Le fait que le développeur ou le réviseur inclue des captures d'écran ou des liens vers le tableau de bord de test directement dans la PR rend également les retours plus rapides et plus fiables.

Les réviseurs peuvent ajouter des commentaires et approuver, lesquels sont enregistrés afin que la modification soit plus facile à comprendre ultérieurement.

Étape 4 : Déployer le tableau de bord en production à l'aide du bundle

Une fois la modification approuvée, vous êtes prêt à déployer le tableau de bord en production.

Les tableaux de bord ont souvent besoin de paramètres différents en production et en développement - par exemple, pointer vers un catalogue ou un schéma de production au lieu d'un dataset de développement, ou utiliser un SQL warehouse différent.

La bonne nouvelle, c'est que ces différences sont attendues et gérées dans le cadre du processus de déploiement.

Lorsque vous avez ajouté le tableau de bord à l'Asset Bundle, Databricks a généré un petit .yml fichier de configuration qui capture ces paramètres spécifiques à l'environnement. Ce fichier vous permet de remplacer des valeurs par environnement sans modifier la logique même du tableau de bord. Dans notre cas, nous avons spécifié que le catalogue que le tableau de bord utilise en production doit être différent de celui en test, en utilisant une valeur ${variable} pour le nom du catalogue.

Enfin, le fichier databricks.yml rassemble toutes les ressources du bundle et définit le catalogue utilisé dans chaque environnement, ce qui facilite la gestion de déploiements cohérents dans les Workspaces de développement, de test et de production.

Une fois la Pull Request approuvée et fusionnée dans la branche principale, votre automatisation de déploiement s'exécute et utilise les valeurs spécifiques à l'environnement définies dans databricks.yml. Le même code de tableau de bord est réutilisé dans les différents Workspaces, tandis que des paramètres tels que le catalogue, le schéma et le warehouse sont appliqués en fonction de l'environnement cible. Cela élimine le besoin de maintenir des copies de tableau de bord distinctes pour chaque workspace et garantit que les modifications se comportent de manière prévisible partout.

Pour la plupart des fournisseurs Git, vous pourrez voir l'automatisation du déploiement sur la pull request afin de pouvoir surveiller le déploiement et confirmer quand il se termine (ou s'il rencontre un problème). En cas de problème, le déploiement s'arrête sans affecter le tableau de bord de production existant pour vous permettre de dépanner. Une fois le déploiement terminé avec succès, le tableau de bord mis à jour est en ligne en production et prêt pour les parties prenantes !

Bonus 1 : Et si vous voulez inspecter l'historique ?

Une fois la mise à jour du tableau de bord en ligne, vous devrez peut-être comprendre l'historique des modifications : quoi, quand et pourquoi. L'un des avantages de ce flux est que la modification est désormais traçable. Au lieu d'une modification ponctuelle effectuée directement dans un workspace, elle apparaît comme une séquence de versions enregistrées.

Chaque entrée représente une mise à jour du tableau de bord, ainsi que l'auteur et le timestamp. Vous pouvez ouvrir n'importe quelle entrée pour examiner les modifications et la restaurer si nécessaire.

Bonus 2 : Et si vous devez annuler une modification ?

Même avec un examen et des tests minutieux, des problèmes peuvent toujours survenir, comme un tableau de bord qui ne se charge pas ou une définition de métrique qui s'avère incorrecte.

Étant donné que le tableau de bord est géré via ce workflow, vous pouvez revenir à une version précédente fonctionnelle en utilisant le même processus contrôlé que celui utilisé pour déployer la mise à jour.

Commencez par ouvrir l'historique des modifications du tableau de bord dans le dépôt, puis localisez la mise à jour que vous souhaitez annuler. À partir de là, vous pouvez examiner les modifications pour vous assurer que vous annulez la bonne modification avant de continuer.

À partir des détails de la modification, suivez le lien pour revenir à la page de révision. Pour annuler la mise à jour, sélectionnez Inverser. Cela crée une nouvelle modification d'« annulation » qui inverse uniquement cette mise à jour spécifique, restaurant la logique précédente du tableau de bord tout en conservant le reste de l'historique intact.

Une fois la modification mergée dans la branch principale, la même automatisation qui a déployé le tableau de bord en production l'annulera. Cela signifie que vous pouvez réagir à une panne ou à un problème de calcul à fort impact en quelques minutes, sans contourner les contrôles que vous avez déjà mis en place.

Bonus 3 : Que se passe-t-il si vos sources de données sont mises à jour ?

La plupart des tableaux de bord sont étroitement liés à leurs sources de données, ce qui signifie que les mises à jour d'un tableau de bord sont souvent étroitement liées aux mises à jour dans les pipelines. La bonne nouvelle, c'est que les Asset Bundles sont conçus pour regrouper les composants connexes en un seul package.

Cela garantit qu'une modification du modèle de données en amont ne vous surprenne jamais et, lorsque les modifications de la visualisation nécessitent des mises à jour du modèle de données, vous pouvez déployer les deux modifications en un seul déploiement.

Conclusion

Considérer les tableaux de bord d'IA/BI comme des produits de données de qualité production est essentiel pour prendre des décisions commerciales fiables et pour l'atténuation des risques. Dans ce workflow, un petit ensemble d'étapes supplémentaires rend les modifications du tableau de bord visibles, révisables et réversibles, sans changer la façon dont vous créez les tableaux de bord au quotidien.

En gérant les tableaux de bord avec Git et Databricks Asset Bundles, les équipes établissent un flux de travail routinier et prévisible pour les mises à jour : effectuer la modification, la réviser, la tester et la déployer. Le même processus s'applique, que la mise à jour soit un petit ajustement visuel ou une modification significative de la logique métier.

Avec la bonne discipline de déploiement en place, les modifications de tableau de bord cessent d'être une source de risque et deviennent une source d'insights fiable qui évolue avec l'entreprise, même dans des situations à fort enjeu comme une réunion du conseil d'administration.

En savoir plus + Prochaines étapes

Si cela vous a inspiré et que vous souhaitez en savoir plus sur les éléments de ce workflow, voici quelques ressources pour aller plus loin :

• « Stratégie de branche » (AWS | Azure | GCP)
  Découvrez comment les modifications sont fusionnées et déployées à l'aide d'un modèle de branche qui suit les meilleures pratiques.
• Databricks asset Bundles (AWS | Azure | GCP)
  Découvrez comment les asset Bundles sont utilisés pour packager et déployer les Ressources Databricks de manière cohérente entre les environnements.
• CI/CD pour le déploiement automatisé sur Databricks (AWS | Azure | GCP)
  Découvrez comment implémenter le CI/CD avec les scripts de démarrage Github Actions (AWS | Azure | GCP)
• Utilisation des Asset Bundles from the Databricks Workspace UI (AWS | Azure | GCP)
  Découvrez comment créer, modifier et déployer des bundles directement depuis l'espace de travail.
• Dossiers basés sur Git dans Databricks (AWS | Azure | GCP)
  Découvrez comment l'intégration Git fonctionne dans Databricks et comment le contrôle de version s'intègre dans les flux de travail d'analytiques quotidiens.

Si vous êtes prêt à passer à l'étape suivante avec Databricks AI/BI, vous pouvez choisir l'une des options suivantes :

• Édition gratuite et Essai : bénéficiez d'une expérience pratique en vous inscrivant à notre édition gratuite ou version d'essai.
• Documentation : Explorez les détails dans notre documentation.
• Page web : Visitez notre page web pour en savoir plus.
• Démos : Regardez nos vidéos de démo, faites des visites de produits et suivez des tutoriels pratiques pour voir l'IA/la BI en action.
• Formation : Démarrez avec une formation produit gratuite via la Databricks Academy.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original