Cliente. Una compañía agroindustrial de gran escala con una plataforma de datos empresarial —un lakehouse sobre Azure Databricks— que cargaba deuda técnica acumulada: pipelines que fallaban en producción, esquemas que se movían sin aviso y despliegues que daban miedo tocar.
Enfoque
Este caso recorre un solo eslabón del método —el de ingeniería de datos— y lo recorre entero. No es un greenfield ni un modelo canónico nuevo: es remediación. La plataforma ya existía y producía valor; el trabajo fue devolverle confiabilidad a algo que la había perdido por desgaste.
La tesis que gobierna el trabajo es la de la calidad de datos como condición, no como adorno: sin datos confiables solo se automatizan errores más rápido. Un pipeline que corre pero entrega un dataset corrupto a un modelo de ML no es un pipeline que funciona a medias —es un pasivo que se propaga aguas abajo sin que nadie lo note hasta que la decisión ya se tomó. Estabilizar la base es lo que permite que todo lo que se apoya encima —analítica, features, modelos— deje de heredar el ruido.
El problema detectado
El lakehouse arrastraba deuda técnica sobre la entrega y sobre los datos. Tres síntomas concretos:
- Pipelines frágiles. Las cargas incrementales sobre Delta Lake fallaban de forma intermitente y costaba reconstruir por qué; una corrida buena y una mala no eran distinguibles a simple vista.
- Schema-drift silencioso. Las fuentes cambiaban de forma —una columna que aparece, un tipo que muta— sin que el pipeline lo detectara. El dato seguía fluyendo, pero ya no significaba lo mismo.
- Despliegues sin red. No había una cadena de entrega que validara un cambio antes de que llegara a producción. Cada modificación era un acto de fe.
El problema declarado era “se nos rompen los pipelines”. El problema real era anterior: no había mecanismos que hicieran visible la degradación —ni del esquema, ni del dato, ni del despliegue— antes de que impactara en lo que se construía encima.
Relevamiento funcional
Sin un dominio funcional nuevo que mapear, el relevamiento fue un diagnóstico de la deuda técnica del lakehouse: dónde estaba el riesgo y qué lo hacía invisible.
- Qué pipelines fallaban y por qué. Distinguir la falla transitoria (un reintento la resuelve) de la falla estructural (el esquema cambió, la partición no existe, la idempotencia se rompió) para no tratar a todas igual.
- Dónde estaba el schema-drift. Identificar en qué fronteras Bronze→Silver→Gold se colaba el cambio de forma sin control, y qué tablas downstream lo absorbían sin chistar.
- Qué no estaba cubierto por validación. Mapear qué transformaciones llegaban a producción sin ninguna verificación de que el dato resultante fuera el esperado.
Documentar la deuda fue tan parte del trabajo como remediarla: un riesgo que no se nombra no se puede priorizar.
Construcción de la solución técnica
La remediación operó sobre la arquitectura medallón existente, sin reescribirla, devolviéndole garantías capa por capa:
- Estabilización Bronze/Silver/Gold. Endurecimiento de las cargas incrementales sobre Delta Lake para que la ingesta a escala fuera repetible: corridas idempotentes y un comportamiento predecible ante el reproceso, de modo que reejecutar dejara de ser riesgoso.
- CI/CD sobre la entrega. Una cadena de entrega con GitHub Actions que valida los cambios antes de que toquen producción, convirtiendo el despliegue de un acto de fe en un paso verificado.
- Frameworks de validación de datos. Verificaciones sobre el dato resultante de cada transformación, para cortar el dataset corrupto en origen en lugar de descubrirlo aguas abajo.
- Detección de schema-drift. Mecanismos que hacen visible el cambio de forma de las fuentes en el momento en que ocurre, antes de que se propague silenciosamente por las capas Silver y Gold.
El efecto conjunto fue reducir el riesgo de despliegue: cada cambio pasa por una red que lo atrapa antes de que el costo lo pague producción.
Capa de información y datos
El producto de la remediación no es solo “pipelines que corren”: son datos confiables y reproducibles para lo que se construye encima.
- Datasets versionados. Las salidas Gold quedan reproducibles —se puede volver a generar un dataset y obtener el mismo resultado— lo que da trazabilidad a la analítica que se apoya en ellos.
- Features estables para ML. Pipelines de features que dejan de heredar el schema-drift y el ruido de las cargas, de modo que un modelo entrena sobre una base que no se mueve bajo sus pies entre una corrida y la siguiente.
- Analítica sin sobresaltos. Con la entrega validada y el drift bajo vigilancia, el consumo downstream deja de absorber sorpresas que nadie introdujo a propósito.
Cómo se condujo el trabajo
El trabajo se ejecutó entre septiembre de 2025 y enero de 2026, en modalidad remota, sobre la plataforma del cliente. Lo concreto y verificable:
- El hardening de la entrega se hizo con GitHub Actions: la validación de cambios dejó de depender de la disciplina manual y pasó a ser un paso obligatorio de la cadena.
- La validación de datos y la detección de schema-drift se materializaron como workflows reproducibles —no como revisiones ad hoc que se degradan con el cansancio—, de modo que la misma verificación corre igual hoy y dentro de tres meses.
- El alcance fue deliberadamente acotado a la remediación: estabilizar lo que existía y endurecer la entrega, no reescribir la plataforma. Ser honesto sobre ese límite es parte de la entrega.
Qué prueba este caso
- Data engineering de operación, no de pizarrón: estabilizar un lakehouse con deuda técnica en producción, sobre Databricks/Spark/Delta a escala, es un oficio distinto al de diseñar uno nuevo.
- Disciplina de entrega: CI/CD, validación de datos y detección de schema-drift como workflows reproducibles que reducen el riesgo de despliegue, no como buenas intenciones.
- Honestidad de alcance: un engagement de remediación encuadrado como lo que fue —estabilización de deuda técnica—, sin inflarlo a greenfield ni adjudicarle métricas que no se midieron.