Schema Drift en ETL: cuando los datos cambian y el código no se entera

Sat, 10 Oct 2026 00:00:00 +0200

Cada mañana, un ETL recibe un CSV, convierte la edad a entero y carga los clientes. Ayer funcionaba con este fichero:

id,name,age
1,John,25
2,Mary,30

Hoy, el proveedor añade el país:

id,name,age,country
1,John,25,USA
2,Mary,30,UK

Unos días después, llega otra sorpresa:

id,name,age,country
1,John,25,USA
2,Mary,unknown,UK

Una columna adicional puede ser inocua si seleccionamos campos por nombre y permitimos extras. Si desempaquetamos cada fila en tres variables, puede romper la carga. unknown puede provocar un error al convertir la edad, convertirse silenciosamente en nulo o hacer que una inferencia posterior trate toda la columna como texto.

La compatibilidad depende del contrato y del código. Incluso el último caso puede ser un incumplimiento de datos puntuales, sin que el proveedor haya cambiado el esquema declarado. La pregunta es: si sabemos qué versión del código procesó un fichero, ¿podemos saber también qué estructura tenían los datos y cuándo dejaron de ser compatibles con nuestro ETL?

Detectar un cambio no es aprobarlo

Schema Drift describe la divergencia entre la estructura esperada y la observada: columnas nuevas, campos ausentes o tipos diferentes. En un CSV, cuyos valores son texto, los tipos observados dependen de cómo los interpretamos.

Schema Evolution es gestionar esa evolución: acordar versiones, decidir qué cambios admitimos y adaptar consumidores. Añadir un campo opcional puede conservar compatibilidad; eliminar una clave que necesitamos normalmente la rompe.

Un Data Contract recoge el acuerdo entre productor y consumidor: campos, tipos, nulabilidad, formatos, unidades, expectativas de calidad y condiciones de entrega. Para hacerlo operativo necesitamos comprobaciones y una política ante incumplimientos. Registrar un cambio, aceptarlo y transformar los datos son decisiones distintas.

Por ejemplo, podemos admitir columnas nuevas, rechazar la ausencia de id y poner en cuarentena filas con edades inválidas. Esa política debe quedar versionada: «el fichero se pudo leer» aporta menos información que «cumplió el contrato 2.1».

Git cuenta solo una parte de la historia

Git permite identificar el código desplegado, pero no registra automáticamente qué envió un proveedor externo. Imaginemos esta secuencia, donde A, B y C representan estructuras observadas, no contratos ya aprobados:

Fecha de recepción	Esquema recibido	Versión ETL
01/09	Schema A	v1.0
12/09	Schema B	v1.0
15/09	Schema B	v1.1
20/09	Schema C	v1.1
25/09	Schema C	v1.2

Si v1.0 solo soportaba A y v1.1 solo A y B, entre el 12 y el 15, y entre el 20 y el 25, hay lotes potencialmente afectados. Las franjas del diagrama marcan esos periodos de revisión; no demuestran por sí mismas una incompatibilidad. Debemos consultar contratos, validaciones y resultados de cada ejecución.

Por cada lote conviene guardar:

Código ejecutado: commit Git o artefacto inmutable, además de una etiqueta legible.
Esquema observado y contrato aplicado: identificadores de versiones y sus descriptores.
Identidad del fichero: origen, identificador del lote y hash del contenido; si existe, versión del objeto almacenado.
Recepción y procesamiento: fechas separadas, con zona horaria y un identificador de ejecución.
Resultado: comprobaciones, rechazos y salidas producidas.

También hay dos relojes: cuándo cambió el origen y cuándo lo detectamos. Una inspección nocturna solo demuestra lo observado esa noche. Si no hay eventos del proveedor ni ficheros históricos, quizá podamos acotar el cambio entre dos observaciones, pero no asignarle una hora exacta.

El historial de metadatos tampoco conserva automáticamente el contenido original. Para reproducir el cálculo hacen falta los datos, las dependencias y la configuración del ETL, sujetos a la política de retención correspondiente.

Los fallos que dejan el pipeline en verde

Un importe pasa de euros a céntimos: 19.95 se convierte en 1995. Ambos pueden ser números válidos. Una lista de columnas y tipos no detecta el cambio de unidad; hacen falta unidades declaradas, reglas de negocio o una comparación estadística que señale el salto.

Una fecha cambia de 2026-10-09 a 09/10/2026. Si el contrato exige un formato, podemos rechazarla. Si el esquema dice únicamente «texto», todo parece correcto; un parser permisivo puede además confundir día y mes en fechas ambiguas.

La Coruña aparece como La CoruÃ±a por una interpretación incorrecta de bytes. Sigue siendo texto, e incluso puede estar almacenado después en un fichero UTF-8 perfectamente válido. Fijar la codificación ayuda, pero no repara una corrupción previa. Este tema conecta con los errores de codificación y Unicode.

Estos problemas requieren combinar estructura, semántica y Data Quality. Un rango de edades, una moneda explícita o un catálogo de localidades detectan cosas que el análisis del esquema no cubre. Y una distribución diferente puede reflejar un cambio real del negocio: una alerta pide investigar, no corregir automáticamente.

Qué aporta cada herramienta

OpenMetadata: memoria compartida del ecosistema

OpenMetadata centraliza metadatos de activos, propietarios y relaciones. Su historial de versiones incluye cambios de esquema y otros metadatos. Usa versiones mayores y menores; eliminar una columna es un ejemplo documentado de cambio incompatible. Esa clasificación del catálogo no reemplaza la compatibilidad específica de nuestro consumidor.

Las alertas de observabilidad permiten vigilar columnas añadidas, eliminadas o actualizadas, resultados de pruebas y estados de pipelines. Podemos filtrar eventos y enviarlos a correo, canales de chat o webhooks. Sus pruebas de tablas comprueban, entre otras cosas, columnas esperadas y recuentos; el perfilado aporta métricas adicionales.

Encaja cuando varios equipos necesitan un catálogo común sobre bases de datos, almacenamiento, pipelines y analítica. Exige desplegar la plataforma y configurar ingestión y conectores. Un cambio que todavía no se ha ingerido queda fuera de su conocimiento: para controlar cada CSV al recibirlo necesitamos instrumentar esa entrada.

OpenLineage: unir datos, código y ejecuciones

OpenLineage define un estándar abierto de trazabilidad. Un job identifica el trabajo lógico; un run, una ejecución concreta; un dataset, una entrada o salida. Las facets añaden metadatos a esas entidades y a las entradas o salidas de una ejecución.

La facet de esquema describe campos y tipos. La facet de ubicación del código admite información del repositorio y versión. Si nuestro productor de eventos las rellena, podemos relacionar un run con sus datasets y con el código ejecutado. Hay que emitir la referencia efectiva del artefacto desplegado, no asumir que coincide con la rama actual.

Los clientes e integraciones publican eventos que un backend recibe y conserva. OpenLineage no inspecciona por sí solo un CSV ni decide si un cambio es compatible. Hace falta un lector o integración que aporte el esquema y un sistema que compare observaciones, almacene el historial y alerte. Su utilidad aumenta cuando queremos seguir el impacto a través de varios motores.

DataHub: catálogo e historial, con diferencias entre ediciones

DataHub ofrece historial de esquemas para revisar campos añadidos, eliminados y cambios de tipo. Esa capacidad está disponible en Core, su versión abierta, y en Cloud. El catálogo y el linaje permiten estudiar dependencias, siempre que ingiramos esos metadatos.

Los Data Contracts agrupan aserciones sobre un activo. La comparación oficial de Core y Cloud incluye contratos en ambas ediciones; en Core podemos ejecutar comprobaciones fuera de DataHub y publicar sus resultados, por ejemplo desde dbt o Great Expectations.

Las Schema Assertions nativas pertenecen a DataHub Cloud Observe. Permiten exigir que el esquema contenga determinadas columnas y tipos o que coincida exactamente. Se evalúan ante cambios del esquema ingerido; los tipos comparados son de alto nivel. Cloud añade monitorización nativa y detección de anomalías. Tener el modelo abierto de aserciones no implica disponer del ejecutor comercial.

Es una opción para organizaciones con múltiples fuentes y necesidades de gobierno y descubrimiento. La operación del catálogo y sus ingestas tiene más coste que incorporar una librería a un ETL pequeño.

Frictionless: empezar por el fichero que acaba de llegar

Frictionless permite describir, leer y validar datos tabulares desde Python. Puede inspeccionar un CSV, inferir nombres y tipos, guardar un descriptor de esquema y validar otra entrega contra él. Es una pieza útil si queremos comprobar archivos cerca del punto de recepción, sin desplegar primero un catálogo.

Este ejemplo usa Frictionless 5.20.0, contrastado con las referencias de Resource, Schema y validación. Ejecútalo en un directorio de trabajo nuevo: crea tres ficheros.

python3 -m venv .venv
source .venv/bin/activate
python -m pip install frictionless==5.20.0

from pathlib import Path
from frictionless import Resource, Schema

Path("clientes.csv").write_text(
 "id,name,age,country\n1,John,25,USA\n2,Mary,30,UK\n",
 encoding="utf-8",
)
Path("clientes-cambio.csv").write_text(
 "id,name,age,country\n1,John,25,USA\n2,Mary,unknown,UK\n",
 encoding="utf-8",
)

original = Resource(path="clientes.csv", encoding="utf-8")
original.infer()
print([(field.name, field.type) for field in original.schema.fields])
original.schema.to_json("clientes.schema.json")

report = Resource(
 path="clientes-cambio.csv",
 encoding="utf-8",
 schema=Schema("clientes.schema.json"),
).validate()

print(report.valid)
print(report.flatten(["rowNumber", "fieldNumber", "type"]))

Se infieren id y age como integer, y name y country como string. El segundo fichero devuelve False y [[3, 3, 'type-error']]: la tercera fila, contando la cabecera, contiene una edad incompatible.

El detalle decisivo es validar contra el esquema anterior. Si inferimos de nuevo sobre cada entrega y aceptamos lo inferido, podemos normalizar el problema como un nuevo tipo. La inferencia es una propuesta, no un contrato: depende de la muestra y de la configuración del detector. Identificadores como 00123 deberían declararse como texto cuando ese significado importe.

Frictionless también valida restricciones y admite comprobaciones adicionales. El historial, la política de compatibilidad, el registro de runs y las alertas tendríamos que implementarlos o integrarlos. Para JSON tabular puede aprovechar sus lectores; para documentos anidados necesitamos definir cómo representar objetos, arrays y campos opcionales.

whylogs: observar el contenido mediante perfiles

whylogs genera perfiles compactos con propiedades estadísticas, valores ausentes y métricas configurables. Podemos conservar perfiles de distintos lotes, compararlos y aplicar restricciones para investigar cambios de distribución, rangos o proporciones de nulos.

El perfil ayuda a ver, por ejemplo, que los importes saltaron de escala. No demuestra que ahora estén en céntimos. También registra propiedades por columna que permiten observar cambios de tipos o presencia, pero un perfil no sustituye un contrato ni decide la compatibilidad de un esquema. Las estadísticas resumidas o aproximadas requieren interpretar la señal.

La librería funciona localmente. El almacenamiento histórico, las comparaciones periódicas y el envío de alertas necesitan una aplicación o integración; el servicio comercial WhyLabs es una opción adicional. Los perfiles reducen la necesidad de conservar valores crudos, aunque eso no garantiza por sí solo que todo metadato sea inocuo desde el punto de vista de la confidencialidad.

Comparar responsabilidades, no solo marcar casillas

En esta tabla, «integración» significa que hay que proporcionar o conectar esa pieza. La complejidad es una valoración orientativa para este caso de uso, no una medida de rendimiento.

Herramienta	Objetivo principal	Cambios de esquema	Historial de esquemas	Trazabilidad de ejecuciones	Análisis estadístico	Despliegue	Software abierto
OpenMetadata	Catálogo y observabilidad	Sobre metadatos ingeridos; pruebas y alertas configuradas	Versiones de activos y metadatos	Linaje y pipelines mediante conectores; detalle por lote requiere instrumentación	Perfilado configurable	Plataforma e ingestas: mayor complejidad	Sí; servicios comerciales adicionales
OpenLineage	Estándar de eventos de linaje	Transporta esquema; comparación en integración/backend	Depende del backend y los eventos conservados	Jobs, runs, datasets y facets emitidos	Puede transportar métricas; cálculo externo	Instrumentación más backend	Sí
DataHub	Catálogo y gobierno	Historial en Core; Schema Assertions nativas en Cloud Observe	Disponible en Core y Cloud	Linaje y metadatos de trabajos según integración	Perfiles ingeridos; anomalías nativas en Cloud	Plataforma en Core o servicio Cloud	Core abierto; Cloud comercial
Frictionless	Describir y validar ficheros	Inferencia y validación contra esquema; comparación histórica a integrar	Descriptores exportables; registro a construir	Asociación con runs a construir	Estadísticas básicas y comprobaciones; no monitor estadístico continuo	Librería/CLI: menor complejidad	Sí, MIT
whylogs	Perfiles de datos	Señales por columna; comparación y contrato a integrar	Perfiles almacenables; versionado estructural a integrar	Asociación con runs a integrar	Su función central	Librería: menor complejidad; monitorización adicional	Sí; WhyLabs es un servicio adicional

Estas herramientas se complementan. Frictionless puede validar la entrada; whylogs perfilarla; OpenLineage transportar la relación con la ejecución; y un catálogo conservar el contexto compartido. No necesitamos las cinco para empezar.

¿Hace falta un LLM?

Un LLM puede ayudar a interpretar un cambio o proponer una transformación. Muchos controles básicos se resuelven con inferencia de tipos, reglas, expresiones regulares y análisis estadístico, con resultados fáciles de revisar.

Incorporarlo introduce coste de infraestructura, latencia y resultados que no necesariamente son deterministas. También exige decidir qué datos o metadatos puede recibir y validar las transformaciones propuestas. Existen modelos locales: evitar un servicio externo cambia las necesidades de infraestructura, pero no elimina estos problemas. Una sugerencia de conversión nunca debería convertirse automáticamente en una nueva regla de negocio.

Una arquitectura ligera que podríamos construir

Una librería Python independiente del motor ETL podría inspeccionar CSV/JSON y mantener metadatos históricos sin ejecutar transformaciones. Es una propuesta conceptual:

CSV / JSON → Inspección → Esquema observado + validación
 ↓
 Registro de versiones
 ↓
 Lote + hash + run + commit + fechas
 ↓
 Cambio desconocido → Alerta → Revisión

Primero normalizaríamos el descriptor y generaríamos una huella estructural. Habría que decidir si el orden de columnas importa, cómo representar tipos anidados y qué propiedades entran en la huella. Guardaríamos también la versión del algoritmo y sus opciones de inferencia, para no confundir un cambio de detector con uno de los datos. La huella del esquema y el hash del fichero cumplen funciones diferentes.

Después registraríamos observaciones inmutables: mismo esquema en varios lotes no significa mismo contenido. El contrato aprobado tendría su propio identificador. Una estructura desconocida activaría una revisión; una conocida aún necesitaría validación de filas y reglas semánticas.

Con las asociaciones entre lotes, runs y código podríamos consultar qué ejecuciones combinaron Schema C con v1.1. Esos lotes serían candidatos a revisión, no pruebas automáticas de resultados incorrectos. Una política explícita decidiría si detener la carga, aislar filas o continuar con una alerta. Una base SQLite podría servir de inicio local; coordinación entre procesos y retención pedirían decisiones adicionales.

Poder reconstruir lo que ocurrió

Versionar el código es necesario, pero no basta para explicar un pipeline. También necesitamos conocer los datos recibidos, su estructura, el contrato aplicado y el resultado de cada ejecución. Los catálogos, los eventos de linaje y las librerías de validación y perfilado cubren partes distintas de esa historia.

Si mañana cambia un fichero sin avisar, ¿podrías identificar qué lotes se procesaron con cada esquema y versión del ETL, y justificar cuáles necesitan revisarse?

Créditos del artículo

La idea y la supervisión editorial de este artículo son de José Pérez. Su elaboración se ha apoyado en IA, con la participación detallada en estos créditos.

Metadato	Valor
Edición	José Pérez
Investigación	Asistida por IA
Redacción	OpenAI Codex
Modelo	GPT-6
Tiempo de generación	No registrado
Revisión humana	Pendiente
Fuentes verificadas	Sí

La verificación de fuentes se realizó con asistencia de IA, contrastando las afirmaciones técnicas con documentación oficial. La revisión humana del texto final está pendiente de confirmación del autor.

Schema Evolution el josiete.com