Cómo una gran empresa de transporte ferroviario de carga escaló la creación de canalizaciones con Genie Code

Una de las redes ferroviarias más grandes de Canadá abarca aproximadamente 20,000 millas de ruta a lo largo de Canadá y hacia los Estados Unidos, lo que respalda el movimiento de más de 250 mil millones de dólares canadienses en mercancías al año. Para una organización que opera a esa escala, modernizar un patrimonio de datos con décadas de antigüedad nunca iba a ser un ejercicio de una tabla a la vez.

Con cientos de pipelines en marcha, una creciente demanda de analítica en tiempo real y AI, y un profundo conocimiento institucional arraigado en los sistemas heredados, la empresa necesitaba una forma de escalar la modernización sin escalar el esfuerzo de desarrollo manual.

Usando Databricks Genie Code, Unity Catalog, Agent Skills personalizados y una aplicación de Streamlit creada en Databricks Apps, el equipo convirtió el desarrollo de pipelines en una fábrica repetible. Un breve prompt de YAML ahora puede generar código de ingesta listo para producción basado en metadatos de catálogo en vivo y alineado con las convenciones de la empresa de forma predeterminada, incluyendo definiciones de tablas, lógica de carga histórica, lógica de ingesta de streaming, lógica de merge incremental y pruebas automatizadas.

El resultado es más del 90% de automatización para la ingesta de nuevas tablas, la entrega de pipelines reducida de días a minutos y un programa de modernización que puede escalar con el negocio en lugar de estar limitado por el ancho de banda de los desarrolladores.

Modernización de un patrimonio de datos complejo a escala empresarial

Al igual que muchas grandes empresas, la compañía construyó su patrimonio analítico a lo largo de décadas a través de sistemas mainframe, almacenes de datos heredados, plataformas ETL empresariales y dispositivos de propósito específico. A medida que la empresa avanzaba hacia una arquitectura de lakehouse moderna, el desafío era mayor que la sola migración: el equipo necesitaba simplificar y estandarizar cómo se construían los pipelines, preservando al mismo tiempo la lógica de negocio crítica en una gran infraestructura heredada.

Antes de la automatización, construir un pipeline para una sola tabla requería un esfuerzo de varios días. Los equipos tenían que inspeccionar los esquemas de origen, definir la lógica de negocio en una hoja de cálculo de mapeo de origen a destino (Source-to-Target Mapping), construir la lógica de ingesta histórica y de streaming, escribir pipelines de merge incremental, implementar transformaciones posteriores y crear cobertura de pruebas para casos como la evolución del esquema, cambios de nombre de columnas, conversiones de tipos (type casts) y eliminaciones lógicas (soft deletes).

Ese trabajo era manejable para una tabla; no lo era para cientos. La verdadera limitación era el esfuerzo manual requerido para traducir la lógica heredada en pipelines de lakehouse de manera repetitiva y consistente.

La empresa necesitaba modernizar no solo sus pipelines, sino el proceso de construcción de cientos de ellos.

Databricks como motor de modernización

La solución se centró en dos capacidades que funcionan juntas: Genie Code con Agent Skills personalizados para generar artefactos de ingesta listos para producción, y una Databricks App para mapear campos de origen a tablas de lakehouse de destino y generar lógica de transformación.

Juntos, crearon un flujo de trabajo de extremo a extremo, desde el descubrimiento de metadatos hasta el código generado, todo dentro de Databricks. Genie Code sirve como el socio autónomo de AI, mientras que un Agent Skill personalizado codifica los patrones de ingesta y la lógica de merge de la empresa. Unity Catalog proporciona introspección de esquemas en las capas raw, histórica y de preparación, mientras que Databricks Apps respalda la experiencia de mapeo de origen a destino. Los pipelines resultantes utilizan PySpark, Spark SQL y Delta Lake, y están diseñados para ejecutarse a través de Lakeflow Jobs.

Este enfoque permitió al equipo ampliar Genie Code con sus propios estándares de ingesta y convenciones de pipelines. Las convenciones de auditoría, la lógica de deduplicación, las protecciones de merge por secuencia de cambios, la reconciliación de eliminaciones lógicas y los patrones de prueba se integran directamente en el proceso de generación en lugar de depender de que cada desarrollador los aplique manualmente.

Agregar determinismo a un flujo de trabajo probabilístico es la clave. Elegimos automatizar lo que sabemos que es correcto y dejamos la capa de interpretación como opcional. El LLM ayuda mientras piensas. El framework garantiza que la explicabilidad esté integrada.—Dinesh Chandrasekaran, líder de datos y AI en una empresa líder de transporte y logística canadiense

Esa filosofía se convirtió en el núcleo de todo el enfoque: usar AI donde el razonamiento y el descubrimiento importan, y usar patrones estrictos donde la consistencia y la reproducibilidad son lo más importante.

De un prompt corto a pipelines listos para producción

Un desarrollador comienza con un prompt de YAML compacto. En el caso más simple, ese prompt puede ser de tan solo dos líneas para la ingesta raw. Para un pipeline de tabla completo, incluye entradas principales como los nombres de las tablas de origen y destino, claves primarias, lógica de deduplicación y comportamiento de actualización.

A partir de ahí, Genie Code sigue un flujo de trabajo estructurado. Analiza y valida el prompt, descubre esquemas de capas históricas y de confianza a través de los metadatos de Unity Catalog, empareja automáticamente las columnas con el origen, identifica los requisitos de conversión de tipos y cambio de nombre, resuelve patrones de transformación, genera los artefactos solicitados utilizando los patrones estándar de la empresa y valida cada salida frente a las invariantes empresariales requeridas. Esas invariantes incluyen la cobertura de claves primarias, la ubicación de columnas de auditoría, merges protegidos por secuencia de cambios, deduplicación compatible con REFRESH y cobertura de conjuntos de pruebas.

Según el modo, el flujo de trabajo admite una sola tabla, varias tablas en una sola solicitud o una ejecución masiva impulsada por un archivo CSV o Excel almacenado en un volumen de Unity Catalog. En la práctica, el flujo de trabajo puede generar seis salidas listas para producción: DDL, carga histórica, ingesta de streaming raw, primer merge incremental, merge incremental continuo y un conjunto de pruebas automatizadas.

Cada notebook generado sigue las mismas convenciones empresariales para columnas de auditoría, deduplicación, merges con detección de secuencia de cambios y reconciliación de eliminaciones lógicas.

Los Agent Skills hicieron reutilizables los estándares empresariales

Una parte clave de la arquitectura fue el Agent Skill personalizado, que le brinda a Genie Code una forma reutilizable de aplicar los estándares de ingesta, las convenciones de nomenclatura y los patrones de pipelines de la empresa.

La habilidad tiene control de versiones como cualquier otra base de código. Incluye un punto de entrada SKILL.md y archivos de patrones de soporte para el descubrimiento de catálogos, convenciones, ingesta raw, cargas históricas, merges incrementales y generación de pruebas. Esa estructura permite a la empresa mantener su lógica de generación de forma centralizada y, al mismo tiempo, ponerla a disposición de los desarrolladores a través de Genie Code.

La habilidad es una sola carpeta cargada en workspace/.assistant/skills/lakehouse-ingestion/.


Contiene un punto de entrada SKILL.md más siete archivos de patrones, uno por tipo de artefacto:

El frontmatter SKILL.md es lo que utiliza Genie Code para decidir cuándo cargar la habilidad:

En lugar de documentar los estándares en un solo lugar y pedir a cada desarrollador que los interprete manualmente, el equipo codificó esos estándares en el propio flujo de trabajo. El agente se encarga de la recopilación de contexto y la orquestación. La habilidad garantiza que los artefactos generados sigan los mismos patrones en todo momento.

Un desarrollador inicia la generación de código con un breve prompt de YAML dentro de una sesión de Genie Code. El mínimo es de dos líneas solo para la ingesta raw. Un pipeline completo requiere seis.

Ejemplo mínimo, genera solo el notebook de ingesta raw:

Ejemplo completo, genera el pipeline completo de seis artefactos para una tabla:

Los seis artefactos se ejecutan en este orden en tiempo de ejecución:

Basado en Unity Catalog, gobernado de forma predeterminada

Otro principio de diseño clave fue basar la generación de código en metadatos en tiempo real en lugar de suposiciones estáticas.

Genie Code utiliza Unity Catalog para inspeccionar esquemas en tablas sin procesar, históricas y de preparación en tiempo real. Este enfoque basado en metadatos elimina la necesidad de una capa de descubrimiento independiente y le brinda al agente el contexto que necesita para generar mapeos, inferir transformaciones y validar los campos requeridos antes de que se emita el código.

Igual de importante es que todos los artefactos generados permanecen dentro del espacio de trabajo de Databricks y funcionan dentro del mismo modelo de gobernanza que el resto de la plataforma de datos. Los controles de acceso, las políticas de metadatos y el historial de revisiones siguen siendo nativos de Databricks. Esa combinación de base en metadatos y ejecución gobernada ayudó al equipo a cerrar una brecha común en la adopción de la AI empresarial: avanzar más rápido sin introducir inconsistencias ni debilitar los controles.

Supervisión humana donde importa

La empresa no abordó esto como un problema de generación completamente automatizado y sin intervención. Antes de que se genere el código, los diseñadores de datos utilizan una aplicación de Databricks para inspeccionar cómo deben mapearse los campos de los sistemas de origen heredados a las tablas de destino del lakehouse.

Este paso, llamado mapeo de origen a destino (Source-to-Target Mapping), captura la lógica de negocio que no debe adivinarse ni automatizarse a ciegas. Desarrollada con Databricks Apps basadas en Streamlit, la aplicación escanea las tablas del sistema de origen, precompleta los mapeos de columnas y permite a los diseñadores de datos revisar y perfeccionar la lógica de transformación en el navegador.

Cada edición se registra en un historial de cambios, y el mapeo final se puede exportar y utilizar como entrada para el flujo de trabajo de generación. Esto aceleró el proceso sin eliminar la revisión de expertos en las partes del flujo de trabajo donde la interpretación del negocio sigue siendo importante. Los diseñadores de datos pudieron centrarse en la intención de la transformación y la lógica de negocio, mientras que Genie Code y el marco de generación se encargaron de los patrones de implementación repetibles.

Determinista por diseño

Una de las decisiones más importantes en la arquitectura fue mantener la capa de razonamiento inteligente y adaptativa, al tiempo que se lograba que el código del pipeline emitido fuera determinista.

Genie Code se encarga de las partes del flujo de trabajo que se benefician del razonamiento agéntico: interpretar prompts, descubrir esquemas, seleccionar la ruta de generación adecuada y estructurar la secuencia correcta de acciones. Pero el código PySpark generado en sí se basa en reglas y es reproducible. Las sentencias de combinación (merge), las ventanas de deduplicación, la ubicación de las columnas de auditoría, las conversiones de tipo (type casts) y los patrones de prueba se definen mediante plantillas explícitas e invariantes.

Para la empresa, eso era esencial. En la generación de pipelines de producción, pequeñas variaciones en la lógica de combinación (merge), las ventanas de deduplicación o la ubicación de las columnas de auditoría pueden generar riesgos en la calidad de los datos descendentes (downstream). La emisión determinista hizo que el sistema fuera lo suficientemente confiable como para usarse a escala empresarial y lo suficientemente consistente como para preservar los estándares de ingeniería que tanto costó conseguir.

Resultados: del rendimiento de los desarrolladores al rendimiento de la modernización

El impacto fue inmediato y práctico:

• Más del 90% de automatización para la ingesta de nuevas tablas en el Databricks Lakehouse
• Tiempo de desarrollo de pipelines reducido de días por tabla a minutos
• Soporte para modos de generación única, múltiple y por lotes en solicitudes ad hoc, migraciones por lotes y esfuerzos de modernización a escala de sprint
• Aplicación consistente de estándares empresariales en cada artefacto generado, sin requerir una revisión de cumplimiento manual

Lo que cambió no fue solo la productividad de los desarrolladores. La empresa aumentó el rendimiento del propio programa de modernización.

En lugar de tratar cada migración de tablas como un proyecto de ingeniería a medida, el equipo creó un sistema repetible para traducir los activos heredados en pipelines de lakehouse gobernados a escala.

Mirando hacia el futuro

La empresa ve esto como la base para una automatización de la modernización más amplia. El equipo ahora está explorando una arquitectura de habilidades más modular para la orquestación, la transformación, la lógica de negocio y la observabilidad; extender el descubrimiento más allá de Unity Catalog hacia el catálogo de datos empresarial más amplio; evaluar la conversión asistida por AI de la lógica heredada de DataStage, COBOL y procedimientos almacenados a PySpark; y utilizar capacidades emergentes de agentes en segundo plano para admitir el triaje de pipelines de rutina, actualizaciones de DBR y reparación de discrepancias de esquemas.

El objetivo a largo plazo va más allá de una generación de código más rápida. Consiste en crear un modelo de modernización que se escale continuamente, incluso a medida que la complejidad heredada, la demanda comercial y el alcance de la plataforma sigan creciendo.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original