Remediación de un lakehouse empresarial: estabilizar pipelines y endurecer la entrega

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.

Técnicas de Delta Lake y Databricks operadas

El endurecimiento se hizo sobre un lakehouse ya en producción —contexto de remediación, no green-field—, así que cada técnica se aplicó sin poder rehacer la plataforma desde cero. Lo concreto que se operó:

• Carga incremental por MERGE idempotente. El framework de ingesta hace upserts por clave primaria y compara por una columna de última actualización (tipo watermark) para no pisar datos más nuevos con una corrida más vieja; si una tabla no tiene PK definida, la carga falla de forma explícita en lugar de adivinar.
• Layout de datos. Liquid clustering (CLUSTER BY) en las tablas nuevas y migración de las existentes; OPTIMIZE ZORDER BY sobre la clave primaria —vía funciones helper— donde el clustering no aplicaba; optimizeWrite y autoCompact fijados por propiedad de tabla, para que el layout no dependa de recordarlo en cada escritura.
• Mantenimiento automatizado. Un job semanal de VACUUM recorre dinámicamente las tablas Delta del catálogo, con una lista de excepciones y un DRY RUN previo que muestra qué se va a borrar antes de borrarlo.
• Optimización del costo de cómputo. Autoscaling, instancias spot con fallback a on-demand, disk cache de Databricks, broadcast joins puntuales donde el plan lo justifica, y políticas de cluster con elastic disk —el costo se ajusta sin sacrificar la repetibilidad.
• Ingesta en tiempo real. Structured Streaming desde Azure Event Hubs con checkpoints, para las fuentes que llegan como flujo y no como lote.

Límites honestos. El runtime es estándar, sin Photon. No hay time travel estricto: el historial se usa para auditoría con DESCRIBE HISTORY, y los “restore” se resuelven por reproceso, no por versión Delta. Y no se usó Auto Loader ni Change Data Feed. Nombrar esos límites es parte del encuadre: la remediación endureció lo que había, no incorporó todo lo que la plataforma ofrece.

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: 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.