Comment une grande compagnie de fret ferroviaire a mis à l'échelle la création de pipelines avec Genie Code

L'un des plus grands réseaux ferroviaires du Canada s'étend sur environ 20 000 milles de voies à travers le Canada et jusqu'aux États-Unis, transportant chaque année plus de 250 milliards de dollars canadiens de marchandises. Pour une organisation opérant à cette échelle, la modernisation d'un patrimoine de données vieux de plusieurs décennies ne pouvait pas se faire table par table.

Avec des centaines de pipelines en cours d'exécution, une demande croissante d'analyses en temps réel et d'IA, et une connaissance institutionnelle approfondie ancrée dans les systèmes existants, l'entreprise avait besoin d'un moyen de mettre à l'échelle la modernisation sans pour autant multiplier les efforts de développement manuel.

En utilisant Databricks Genie Code, Unity Catalog, des Agent Skills personnalisées et une application Streamlit intégrée sur Databricks Apps, l'équipe a transformé le développement de pipelines en une usine reproductible. Un court prompt YAML peut désormais générer un code d'ingestion prêt pour la production, basé sur les métadonnées du catalogue en temps réel et aligné par défaut sur les conventions de l'entreprise, y compris les définitions de tables, la logique de chargement historique, la logique d'ingestion en continu (streaming), la logique de fusion (merge) incrémentielle et les tests automatisés.

Le résultat est une automatisation de plus de 90 % pour l'ingestion de nouvelles tables, des délais de livraison de pipelines réduits de plusieurs jours à quelques minutes, et un programme de modernisation capable de s'adapter à la croissance de l'entreprise au lieu d'être limité par la bande passante des développeurs.

Moderniser un patrimoine de données complexe à l'échelle de l'entreprise

Comme beaucoup de grandes entreprises, la société a construit son patrimoine analytique sur plusieurs décennies à travers des systèmes mainframes, des entrepôts de données existants, des plateformes ETL d'entreprise et des appliances dédiées. Alors que l'entreprise évoluait vers une architecture lakehouse moderne, le défi dépassait la simple migration : l'équipe devait simplifier et standardiser la construction des pipelines tout en préservant la logique métier critique sur un vaste parc existant.

Avant l'automatisation, la création d'un pipeline pour une seule table nécessitait plusieurs jours de travail. Les équipes devaient inspecter les schémas sources, définir la logique métier dans un tableur de mappage source-cible (Source-to-Target Mapping), concevoir la logique d'ingestion historique et en continu, écrire des pipelines de fusion incrémentielle, implémenter des transformations en aval et créer une couverture de test pour des cas tels que l'évolution des schémas, le renommage des colonnes, les conversions de types (type casts) et les suppressions logiques (soft deletes).

Ce travail était gérable pour une seule table, mais pas pour des centaines. La véritable contrainte résidait dans l'effort manuel requis pour traduire de manière répétée et cohérente la logique existante en pipelines lakehouse.

L'entreprise devait moderniser non seulement ses pipelines, mais aussi le processus de création de centaines de pipelines.

Databricks comme moteur de modernisation

La solution s'est articulée autour de deux capacités fonctionnant de concert : Genie Code avec des Agent Skills personnalisées pour générer des artefacts d'ingestion prêts pour la production, et une Databricks App pour mapper les champs sources vers les tables lakehouse cibles et générer la logique de transformation.

Ensemble, ils ont créé un flux de travail de bout en bout, de la découverte des métadonnées au code généré, le tout au sein de Databricks. Genie Code sert de partenaire d'IA autonome, tandis qu'une Agent Skill personnalisée encode les modèles d'ingestion et la logique de fusion de l'entreprise. Unity Catalog fournit l'introspection des schémas à travers les couches brutes, historiques et de préparation, tandis que Databricks Apps prend en charge l'expérience de mappage source-cible. Les pipelines qui en résultent utilisent PySpark, Spark SQL et Delta Lake, et sont conçus pour s'exécuter via des Lakeflow Jobs.

Cette approche a permis à l'équipe d'étendre Genie Code avec ses propres normes d'ingestion et conventions de pipeline. Les conventions d'audit, la logique de déduplication, les protections de fusion basées sur la séquence de changement (change-sequence merge guards), la réconciliation des suppressions logiques (soft-deletes) et les modèles de test sont directement intégrés au processus de génération, plutôt que de dépendre de l'application manuelle de chaque développeur.

Ajouter du déterminisme à un flux de travail probabiliste est la clé. Nous avons choisi d'automatiser ce que nous savons être correct, et nous laissons la couche d'interprétation optionnelle. Le LLM vous aide dans votre réflexion. Le framework garantit que l'explicabilité est intégrée dès le départ.—Dinesh Chandrasekaran, Data & AI Leader au sein d'une entreprise canadienne de transport et de logistique de premier plan

Cette philosophie est devenue centrale dans toute notre approche : utiliser l'IA là où le raisonnement et la découverte sont essentiels, et utiliser des modèles stricts là où la cohérence et la reproductibilité importent le plus.

D'un court prompt à des pipelines prêts pour la production

Un développeur commence par un prompt YAML compact. Dans le cas le plus simple, ce prompt peut ne faire que deux lignes pour une ingestion brute. Pour un pipeline de table complet, il comprend des entrées clés telles que les noms des tables source et cible, les clés primaires, la logique de déduplication et le comportement de rafraîchissement.

À partir de là, Genie Code suit un flux de travail structuré. Il analyse et valide le prompt, découvre les schémas des couches historiques et de confiance grâce aux métadonnées de Unity Catalog, associe automatiquement les colonnes avec la source, identifie les besoins de conversion de type (type-cast) et de renommage, résout les modèles de transformation, génère les artefacts demandés à l'aide des modèles standard de l'entreprise et valide chaque sortie par rapport aux invariants requis par l'entreprise. Ces invariants incluent la couverture des clés primaires, le positionnement des colonnes d'audit, les fusions protégées par séquence de changement, la déduplication prenant en compte REFRESH et la couverture de la suite de tests.

Selon le mode, le flux de travail prend en charge une seule table, plusieurs tables dans une seule requête ou une exécution en bloc pilotée par un fichier CSV ou Excel stocké dans un volume Unity Catalog. En pratique, le flux de travail peut générer six sorties prêtes pour la production : le DDL, le chargement historique, l'ingestion en continu brute, la première fusion incrémentielle, la fusion incrémentielle continue et une suite de tests automatisés.

Chaque notebook généré suit les mêmes conventions d'entreprise pour les colonnes d'audit, la déduplication, les fusions prenant en compte la séquence de changement et la réconciliation des suppressions logiques (soft-deletes).

Les Agent Skills rendent les normes d'entreprise réutilisables

Un élément clé de l'architecture était l'Agent Skill personnalisée, qui offre à Genie Code un moyen réutilisable d'appliquer les normes d'ingestion, les conventions de nommage et les modèles de pipeline de l'entreprise.

La compétence (skill) est versionnée comme n'importe quelle autre base de code. Elle comprend un point d'entrée SKILL.md et des fichiers de modèles de support pour la découverte de catalogue, les conventions, l'ingestion brute, les chargements historiques, les fusions incrémentielles et la génération de tests. Cette structure permet à l'entreprise de maintenir sa logique de génération de manière centralisée tout en la mettant à la disposition des développeurs via Genie Code.

L'Agent Skill est un dossier unique importé dans workspace/.assistant/skills/lakehouse-ingestion/.


Il contient un point d'entrée SKILL.md ainsi que sept fichiers de modèles, un par type d'artefact :

Le frontmatter SKILL.md est ce que Genie Code utilise pour décider quand charger la compétence (skill) :

Au lieu de documenter les normes à un seul endroit et de demander à chaque développeur de les interpréter manuellement, l'équipe a encodé ces normes directement dans le flux de travail. L'agent gère la collecte de contexte et l'orchestration. La compétence garantit que les artefacts générés suivent les mêmes modèles à chaque fois.

Un développeur lance la génération de code avec un court prompt YAML au sein d'une session Genie Code. Le minimum est de deux lignes pour l'ingestion brute uniquement. Un pipeline complet en nécessite six.

Exemple minimal, génère uniquement le notebook d'ingestion brute :

Exemple complet, génère le pipeline complet à six artefacts pour une table :

Les six artefacts s'exécutent dans cet ordre lors de l'exécution :

Ancré dans Unity Catalog, gouverné par défaut

Un autre principe de conception clé consistait à ancrer la génération de code dans des métadonnées en temps réel plutôt que dans des hypothèses statiques.

Genie Code utilise Unity Catalog pour inspecter les schémas des tables brutes, historiques et de préparation en temps réel. Cette approche basée sur les métadonnées élimine le besoin d'une couche de découverte distincte et donne à l'agent le contexte nécessaire pour générer des mappages, déduire des transformations et valider les champs requis avant l'émission du code.

Tout aussi important, tous les artefacts générés restent au sein de l'espace de travail Databricks et fonctionnent selon le même modèle de gouvernance que le reste de la plateforme de données. Les contrôles d'accès, les politiques de métadonnées et l'historique des révisions restent natifs à Databricks. Cette combinaison d'ancrage des métadonnées et d'exécution gouvernée a permis à l'équipe de combler une lacune courante dans l'adoption de l'AI en entreprise : avancer plus vite sans introduire d'incohérences ni affaiblir les contrôles.

L'intervention humaine là où elle compte

L'entreprise n'a pas traité cela comme un problème de génération entièrement automatisé sans intervention. Avant que le code ne soit généré, les concepteurs de données utilisent une application Databricks pour inspecter la manière dont les champs des systèmes sources existants doivent être mappés vers les tables du lakehouse cibles.

Cette étape, appelée mappage source-cible (Source-to-Target Mapping), capture la logique métier qui ne doit pas être devinée ou automatisée à l'aveugle. Développée avec Databricks Apps basées sur Streamlit, l'application analyse les tables du système source, pré-remplit les mappages de colonnes et permet aux concepteurs de données de réviser et d'affiner la logique de transformation dans le navigateur.

Chaque modification est suivie dans un journal des modifications, et le mappage final peut être exporté et utilisé comme entrée pour le flux de travail de génération. Cela a permis d'accélérer le processus sans éliminer l'examen par des experts des parties du flux de travail où l'interprétation métier reste essentielle. Les concepteurs de données ont pu se concentrer sur l'intention de transformation et la logique métier, tandis que Genie Code et le framework de génération géraient les modèles d'implémentation reproductibles.

Déterministe par conception

L'une des décisions les plus importantes de l'architecture a été de maintenir la couche de raisonnement intelligente et adaptative tout en rendant déterministe le code du pipeline émis.

Genie Code gère les parties du flux de travail qui bénéficient d'un raisonnement agentique : interprétation des prompts, découverte des schémas, sélection du bon chemin de génération et assemblage de la séquence d'actions correcte. Mais le code PySpark généré lui-même est basé sur des règles et reproductible. Les instructions de fusion (merge), les fenêtres de déduplication, le placement des colonnes d'audit, les conversions de types (type casts) et les modèles de test sont tous définis via des modèles explicites et des invariants.

Pour l'entreprise, c'était essentiel. Dans la génération de pipelines de production, de petites variations dans la logique de fusion, les fenêtres de déduplication ou le placement des colonnes d'audit peuvent créer des risques pour la qualité des données en aval. L'émission déterministe a rendu le système suffisamment fiable pour être utilisé à l'échelle de l'entreprise et suffisamment cohérent pour préserver des normes d'ingénierie durement acquises.

Résultats : de la productivité des développeurs à la productivité de la modernisation

L'impact a été immédiat et concret :

• Plus de 90 % d'automatisation pour l'ingestion de nouvelles tables dans le Databricks Lakehouse
• Temps de développement des pipelines réduit de quelques jours par table à quelques minutes
• Prise en charge des modes de génération unique, multiple et en masse pour les demandes ad hoc, les migrations par lots et les efforts de modernisation à l'échelle des sprints
• Application cohérente des normes d'entreprise sur chaque artefact généré, sans nécessiter d'examen de conformité manuel

Ce qui a changé, ce n'est pas seulement la productivité des développeurs. L'entreprise a augmenté le rendement du programme de modernisation lui-même.

Au lieu de traiter chaque migration de table comme un projet d'ingénierie sur mesure, l'équipe a créé un système reproductible pour traduire les actifs existants en pipelines lakehouse gouvernés à grande échelle.

Perspectives d'avenir

L'entreprise y voit le fondement d'une automatisation plus large de la modernisation. L'équipe explore désormais une architecture de compétences plus modulaire pour l'orchestration, la transformation, la logique métier et l'observabilité ; étendre la découverte au-delà de Unity Catalog au catalogue de données plus large de l'entreprise ; évaluer la conversion assistée par AI de la logique existante DataStage, COBOL et des procédures stockées vers PySpark ; et utiliser les capacités émergentes des agents d'arrière-plan pour prendre en charge le tri de routine des pipelines, les mises à niveau DBR et la réparation des non-correspondances de schémas.

L'objectif à long terme va au-delà d'une génération de code plus rapide. Il s'agit de créer un modèle de modernisation qui évolue en continu, même si la complexité existante, la demande commerciale et la portée de la plateforme continuent de croître.

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