Por Andrew Tan
El Problema con el Monitoreo de Esquemas
El monitoreo de esquemas se supone que detecta cambios disruptivos. No lo hace.
Un pipeline funciona durante meses sin problemas. Luego, un servicio upstream añade un campo revenue_v2. El antiguo campo revenue todavía existe, pero ahora está obsoleto y siempre es nulo. El pipeline ingiere los nulos felizmente. Sin errores. Todo en verde.
La métrica de negocio está simplemente equivocada.
Esto sucede porque el monitoreo observa cambios estructurales, no semánticos.
Por Qué Falla el Monitoreo
La mayoría de los equipos configuran alertas para nuevas columnas. Cambios de tipo. Campos faltantes. Una persona revisa cada alerta.
Después de la quincuagésima notificación de "nuevo campo opcional", dejas de leer. Tu cerebro aprueba automáticamente. ¿INT a BIGINT? Inofensivo. Aprobar. Seguir adelante.
Los problemas reales se escapan. El problema anterior no era estructural. Era semántico. Apareció un nuevo campo — supuestamente seguro. El campo antiguo existía. No se detectaron cambios disruptivos.
El contrato se rompió. Nadie se dio cuenta.
El monitoreo detecta accidentes. Necesitas algo que detecte mentiras.
Contratos vs. Registros
Un registro de esquemas verifica la estructura. Nombres de campos, tipos, nulabilidad. Importante. No suficiente.
Un contrato de datos verifica promesas.
- ¿Enviaste un número?
- ¿Significa lo que dijiste?
- ¿Es positivo? ¿Está en el rango? ¿Referencialmente intacto?
Piensa en las APIs REST. No solo verificas que el JSON se analice. Verificas que el endpoint haga lo que dicen los documentos. Rompe esa promesa y es un cambio disruptivo, incluso si el JSON es técnicamente válido.
Los pipelines de datos necesitan lo mismo. Los sistemas downstream se construyen sobre promesas implícitas. Cuando esas se rompen, todo se rompe.
Cómo Son los Buenos Contratos
Los equipos que hacen esto bien definen tres cosas para cada conjunto de datos:
Garantías estructurales. Pero con un giro: cualquier desviación es disruptiva. ¿Nuevo campo opcional? Incremento de versión. Suena doloroso. Elimina completamente los "cambios semánticos sigilosos".
Expectativas semánticas. Reglas de negocio como validación. Edad del paciente 0-120. Los códigos de diagnóstico deben existir en la tabla de referencia. Timestamps dentro de las 24 horas de la creación del archivo.
Compromisos del consumidor. Los sistemas downstream declaran dependencias. ¿Cambiar un campo que usan tres pipelines críticos? Alto riesgo. Incluso si parece "seguro" estructuralmente.
Los cambios de esquema pasan de días de coordinación a horas. La deriva semántica silenciosa se reduce a cero.
La Parte Difícil es Organizacional
Los contratos fuerzan conversaciones que la mayoría de las personas no quieren tener.
Los productores deben prometer cosas sobre datos que no controlan completamente. El equipo de CRM no conoce a todos los consumidores downstream. El equipo móvil no sabe cómo ciencia de datos usa sus eventos.
Tres patrones para la propiedad:
Propiedad del productor. El equipo que crea los datos define el contrato. Limpio en teoría. A menudo falla porque los productores optimizan para su conveniencia, no para las necesidades downstream.
Propiedad del consumidor. El downstream define los requisitos. Protege a los consumidores, pero los productores no siempre pueden cumplir. Obtienes contratos en papel que se violan en la práctica.
Mediado por plataforma. Un equipo central media la conversación. Más carga administrativa. Realmente funciona.
Mediado por plataforma con revisiones trimestrales es caro en tiempo de reuniones. Barato comparado con los incidentes.
Comienza Pequeño
No necesitas una plataforma para empezar.
Escribe tres cosas para tus conjuntos de datos críticos:
¿Qué representa esto? No definiciones de campos. El concepto de negocio. "Instantánea diaria de suscripciones activas" difiere de "la tabla tiene customer_id, plan_type, renewal_date."
¿En qué pueden confiar las personas? Nulabilidad, frecuencia de actualización, retención. Lo que todos están asumiendo implícitamente.
¿Qué pasa cuando falla? ¿A quién llamas? ¿Qué tan rápido? ¿Cuál es el rollback?
Comienza con tus tres Assets más críticos. Eso es todo.
Los Contratos También Crean Problemas
Se osifican. Cambiar un contrato requiere coordinación. Ese es el punto — previene cambios disruptivos — pero también ralentiza los buenos cambios. Los equipos evitan proponer cambios debido al costo de coordinación.
Mienten. Un contrato es tan bueno como su validación. Decir "todos los customer_ids deben existir" sin verificarlo? Teatro. La falsa confianza es peor que ninguna.
Desplazan la culpa. El consumidor detecta una violación. Respuesta: "el productor rompió su promesa." Cierto. Inútil. El objetivo es arreglar los datos, no asignar culpas. Necesitas procedimientos de recuperación, no señalar con el dedo.
Las Herramientas
Great Expectations y Soda añadieron características de contrato. No son plataformas completas, pero imponen expectativas semánticas en los límites.
Data Contract Club y AICP están emergiendo. Contratos de primera clase con versionado y validación.
Los catálogos de datos — Collibra, Alation, Atlan — ahora tienen gestión de contratos. Usualmente con mucho flujo de trabajo, poca validación. Mejor para documentos que para aplicación.
En layline.io integramos contratos en los Workflows. Definir movimiento de datos, definir las promesas. Expectativas de esquema, reglas de validación, umbrales de calidad. Aplicado en tiempo de ejecución, no verificado después.
Pero no necesitas herramientas sofisticadas. Un archivo JSON Schema con un paso de validación es un contrato funcional. La práctica organizacional supera a la tecnología.
La Prueba
Elige un data Asset crítico. Algo que dolería si está mal.
Upstream cambia su formato. Técnicamente válido — nuevos campos, mismos tipos. Semánticamente incorrecto. ¿Cuánto tiempo hasta que te des cuenta?
Si la respuesta es "cuando alguien se queje", necesitas contratos.
Si es "lo detectaríamos en el monitoreo", profundiza más. ¿Tu monitoreo detecta cambios semánticos o solo estructurales?
El objetivo no es la calidad de datos perfecta. Es prevenir los problemas estúpidos. Los que provienen de suposiciones que nadie escribió.
Andrew Tan es un emprendedor en serie y fundador de layline.io, construyendo infraestructura de procesamiento de datos empresarial que maneja cargas de trabajo tanto por lotes como en tiempo real a escala.