Revenir au contenu principal
Solutions

Comment Daikin Applied Americas crée des pipelines de données cohérents à grande échelle avec Genie Code

Utilisez des compétences réutilisables, des modèles en médaillon et des définitions partagées pour livrer plus rapidement des pipelines cohérents et prêts pour la production.

par Trent Lezer et James VanGordon

  • Daikin Applied Americas a repensé son modèle opérationnel d'ingénierie des données pour répondre aux demandes croissantes d'analyses d'entreprise et d'AI.
  • L'équipe a standardisé le développement de pipelines en utilisant des compétences MECE réutilisables, l'architecture médaillon et des définitions métiers partagées.
  • Cette approche permet une livraison plus rapide, une plus grande cohérence et une gouvernance évolutive entre les équipes.

L'ingénierie de données agentique change la façon dont les pipelines sont construits

Daikin Applied Americas (DAA) fabrique et assure la maintenance de systèmes HVAC commerciaux dans toute l'Amérique du Nord. Cela implique de gérer d'importants volumes de données opérationnelles, de fabrication et de service à travers différents systèmes, de la télémétrie des équipements et des données de la chaîne d'approvisionnement aux rapports d'intervention sur le terrain.

L'équipe des données prend en charge les cas d'usage d'analyse et d'AI dans l'ingénierie, les opérations et le service client, qui dépendent tous de pipelines fiables et bien structurés.

À mesure que ces demandes augmentaient, la pression sur l'équipe des données s'est accrue, avec plus de pipelines, plus de cas d'usage et plus de coordination entre les équipes. Pour y remédier, l'équipe a défini un modèle opérationnel plus structuré pour la conception, la construction et la gouvernance des pipelines, et a utilisé Databricks Genie Code pour accélérer l'exécution au sein de ce modèle.

L'équipe a exploité Genie Code comme une approche de l'ingénierie de données assistée par AI. Travailler directement sur des données gouvernées dans Unity Catalog permet de planifier et de générer des pipelines multi-étapes tout au long du workflow. Cela permet aux ingénieurs de passer d'une idée à un pipeline fonctionnel beaucoup plus rapidement, sans changer d'outil ni assembler manuellement des composants.

Cette rapidité a fondamentalement changé la façon de travailler de l'équipe. Des pipelines dont le prototypage prenait auparavant des jours pouvaient être générés en quelques minutes. Les cycles d'itération ont été raccourcis, et les ingénieurs ont passé moins de temps à écrire du code répétitif et plus de temps à affiner la logique et les résultats.

Parallèlement, opérer dans un environnement de données partagé et de grande taille exige de la cohérence. Les pipelines doivent suivre des modèles d'architecture communs, utiliser des définitions partagées et se comporter de manière prévisible d'une équipe à l'autre.

Les grands modèles de langage introduisent un défi structurel dans ce contexte. Lorsque les équipes s'appuient sur des prompts variés ou des instructions vaguement définies, une même requête peut produire des résultats incohérents et entraîner une dérive architecturale au fil du temps.

Pour y remédier, l'équipe DAA s'est concentrée sur la définition de la manière dont l'AI doit fonctionner au sein d'un environnement d'entreprise gouverné, plutôt que de s'appuyer uniquement sur le prompt engineering.

Comme l'explique Trent Lezer, Sr. Director, Data & Analytics chez Daikin Applied Americas : « Genie Code fonctionne mieux lorsqu'il est traité comme un ingénieur junior qui travaille vite mais doit respecter les mêmes contraintes architecturales que tout le monde, sans exemption spéciale "parce que c'est de l'AI". »

Faire évoluer l'ingénierie des données grâce à des compétences réutilisables

Les premières utilisations de Genie Code suivaient un schéma familier : de longs prompts qui tentaient d'encoder des règles d'architecture, des normes de nommage, une logique de transformation et des exigences de documentation dans un seul bloc de texte.

Cette approche n'était pas évolutive. Les instructions variaient d'une équipe à l'autre, les prompts devenaient difficiles à maintenir et des tâches similaires produisaient des résultats incohérents.

Pour y remédier, l'équipe a introduit un framework de compétences MECE (Mutually Exclusive, Collectively Exhaustive). Comme l'explique Trent : « Nous avons mis en œuvre un framework de compétences MECE, chaque compétence définit une aptitude cohérente, les compétences ne se chevauchent pas et l'ensemble couvre tout le cycle de vie du travail d'ingénierie des données. »

Chaque compétence définit une capacité spécifique dans le cycle de vie de l'ingénierie des données. Ensemble, les compétences ne se chevauchent pas et couvrent l'intégralité du workflow. Ces compétences comprennent la conception d'architecture médaillon, la préparation des sources et la définition du grain, les modèles de transformation, l'alignement canonique et les normes de gouvernance.

Au lieu d'intégrer des règles dans les prompts, l'équipe a structuré l'environnement de manière à ce que Genie Code charge les compétences appropriées au moment de l'exécution et les applique lors de la planification et de l'exécution. Cela déplace le comportement de l'interprétation d'instructions ad hoc vers le fonctionnement au sein d'un modèle d'exécution défini.

Du point de vue de la gouvernance, cela change également la façon dont les normes sont appliquées. Comme le note James VanGordon, Solutions Architect chez Databricks : « Le schéma que je vois constamment avec Genie Code est assez simple : les prompts vous permettent de démarrer, mais ils sont un mauvais endroit pour appliquer les normes d'équipe. Si la même règle compte plus d'une fois, elle doit résider dans l'espace de travail en tant que compétence, là où Genie Code peut réellement l'utiliser. »

Il insiste également sur l'intégration directe des normes dans l'environnement d'exécution : « C'est ce qui rend cela concret plutôt que d'être un simple vœu pieux. Les compétences, le contexte de Unity Catalog et Genie Code fonctionnent au même endroit. Les directives se trouvent là où le travail est créé, et non à l'écart dans un processus de révision dont quelqu'un doit se souvenir plus tard. »

Utiliser l'architecture médaillon pour guider le développement de pipelines

L'équipe a également renforcé le rôle de l'architecture médaillon en tant que framework de gouvernance et de raisonnement. Les couches Bronze, Silver et Gold existaient déjà, mais le changement a consisté à en faire des limites de décision explicites lors de la génération de pipelines, et pas seulement des niveaux de stockage.

Le niveau Bronze représente la vérité brute de la source. Le niveau Silver représente des données nettoyées et conformes. Le niveau Gold représente des analyses prêtes pour l'entreprise.

Pour opérationnaliser cette structure, l'équipe a introduit des points de contrôle entre les couches. Avant que les données ne progressent, des exigences telles que la définition du grain de la source, la validation des jointures et les vérifications de la stabilité des données doivent être satisfaites.

Ces points de contrôle sont appliqués au sein même du workflow de développement, et non comme des étapes de révision en aval. Genie Code fonctionne dans le respect de ces contraintes à mesure que les pipelines sont générés et modifiés.

Cela garantit la cohérence entre les équipes tout en réduisant le risque de raccourcis architecturaux lors d'un développement rapide.

Connecter les pipelines aux concepts métiers

Un défi récurrent dans l'ingénierie des données d'entreprise consiste à aligner les modèles techniques avec le langage métier.

Chez DAA, les parties prenantes pensent en termes d'équipements, de clients, d'événements de service et de contrats, et non en termes de tables, de jointures ou de transformations.

Pour y remédier, l'équipe a ancré la conception des pipelines dans des entités métiers stables. Plutôt que de commencer par des structures techniques, les ingénieurs commencent par identifier ce que représentent les données et comment elles se comportent au fil du temps.

Ce changement améliore les efforts en aval et réduit l'ambiguïté lorsque les ensembles de données sont réutilisés dans différents domaines.

Au fil du temps, les modèles de la couche Silver et les ensembles de données Gold deviennent plus cohérents car ils reposent sur des concepts métiers partagés plutôt que sur des décisions techniques isolées.

Ce qui a changé pour l'équipe

Avec ce modèle opérationnel en place et l'AI intégrée, l'équipe a constaté un changement net dans la manière dont le travail était exécuté.

Le développement de pipelines s'est accéléré, en particulier lors des phases initiales d'exploration et d'itération. Les ingénieurs ont passé moins de temps à écrire du code répétitif et plus de temps à affiner la logique métier.

Les résultats sont également devenus plus cohérents d'une équipe à l'autre. Des cas d'usage similaires suivaient des schémas structurels similaires, améliorant la maintenabilité et la réutilisation.

De plus, la confiance dans les résultats générés a augmenté. Les ingénieurs ont passé moins de temps à valider la correction structurelle et ont pu itérer plus rapidement.

Standardiser la prise de décision au sein du workflow de développement

Pour rendre ces gains reproductibles, l'équipe a standardisé les décisions clés au sein du processus de développement.

Plutôt que de s'appuyer sur des connaissances implicites, les définitions ont été rendues explicites, y compris ce qui qualifie les données Bronze, Silver et Gold, comment le grain de la source est défini, quels modèles de transformation sont réutilisables et comment les entités métiers sont représentées. Cette structure était essentielle pour l'évolutivité. Elle garantit que l'AI fonctionne dans un cadre cohérent d'une équipe à l'autre, même si les cas d'usage évoluent.

Le résultat : ce que cela a débloqué à grande échelle

Le résultat de ce modèle opérationnel n'a pas seulement été des pipelines plus rapides. C'était la capacité de faire évoluer l'ingénierie des données dans un environnement d'entreprise gouverné.

Une livraison plus rapide avec moins de corrections

Les ingénieurs passent moins de temps à corriger des pipelines structurellement incorrects et plus de temps à affiner la logique et les résultats métiers.

Une dérive architecturale réduite entre les équipes

L'application cohérente des compétences et des points de contrôle de gouvernance empêche la divergence entre les équipes travaillant sur des défis de données similaires.

Un alignement plus fort entre l'ingénierie et le métier

Ancrer les pipelines dans des concepts métiers améliore la clarté et réduit les retouches en aval.

Une gouvernance évolutive sans surcharge manuelle

Des garde-fous sont intégrés directement dans le système, réduisant ainsi la dépendance à l'égard d'une application manuelle.

Une confiance accrue dans les résultats générés par l'AI

Parce que des compétences et des points de contrôle définis limitent les résultats, l'AI fonctionne de manière fiable au sein des workflows de production.

Comme le résume Trent : « Le but n'est pas de faire en sorte que l'AI suive plus de règles. C'est de rendre les bonnes règles impossibles à ignorer. »

Conclusion

At Daikin Applied Americas, la combinaison d'un modèle opérationnel structuré et d'un développement assisté par AI a permis à l'équipe des données de se développer plus rapidement tout en maintenant la cohérence, la clarté et le contrôle.

En définissant la manière dont les pipelines doivent être construits et en intégrant ces règles directement dans l'environnement de développement, l'équipe a créé un système dans lequel la rapidité et la gouvernance se renforcent mutuellement plutôt que de se faire concurrence.

En savoir plus sur Genie Code.

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

Recevez les derniers articles dans votre boîte mail

Abonnez-vous à notre blog et recevez les derniers articles directement dans votre boîte mail.