Un productor añade un campo y la integración deja de funcionar. En otra ocasión, todos los campos siguen siendo válidos, pero un importe cambia de unidad y el informe multiplica sus cifras. Evolucionar un esquema exige comprobar tanto la lectura técnica como el significado del dato.
La compatibilidad no es una etiqueta única. Depende de qué versión escribe, cuál lee, qué formato se utiliza y durante cuánto tiempo convivirán datos y aplicaciones de versiones diferentes.
1. Identifica a los consumidores que pueden verse afectados
Incluye procesos diarios, aplicaciones, informes y trabajos que releen el histórico. Un consumidor que no se ejecutó esta semana puede volver a utilizar datos antiguos durante una recuperación.
Registra qué campos utiliza y qué supone sobre ellos: presencia, tipo, valores permitidos, unidad y tratamiento de ausencias. Un parser que admite campos desconocidos puede convivir con una ampliación que otro consumidor estricto rechaza.
El contrato de datos debe conservar esas expectativas y el responsable de cada parte. No deduzcas compatibilidad únicamente de que una consulta de prueba devuelve filas.
2. Distingue dirección y alcance de la compatibilidad
La documentación de evolución de esquemas de Confluent distingue compatibilidad hacia atrás, hacia delante y comprobaciones transitivas. También indica que los detalles cambian entre Avro, JSON Schema y Protobuf.
Un lector nuevo que puede interpretar datos anteriores resuelve una dirección. Un lector antiguo que puede consumir datos nuevos resuelve otra. Comprobar solo la versión inmediatamente anterior no demuestra compatibilidad con todas las versiones conservadas en el histórico.
Define qué combinaciones necesita tu operación. Si un reprocesamiento recorre varios años, conserva muestras representativas de los esquemas que realmente encontrará.
3. Revisa cambios de significado aunque el tipo no cambie
| Cambio propuesto | Pregunta que debe responder la revisión |
|---|---|
| Añadir un campo | ¿Cómo lo trata un consumidor que no lo conoce? |
| Retirar un campo | ¿Qué consumidores todavía lo necesitan? |
| Cambiar un tipo | ¿Qué valores históricos dejan de representarse? |
| Introducir un valor de estado | ¿El lector tiene una conducta definida para valores nuevos? |
| Cambiar una unidad | ¿Se puede distinguir el significado antes y después? |
| Modificar un valor por defecto | ¿La ausencia conserva el mismo significado? |
Por ejemplo, mantener un campo entero y pasar de céntimos a unidades monetarias no es un cambio inocuo. La validación estructural puede aceptarlo mientras el consumidor interpreta otra cantidad.
Tampoco conviertas automáticamente un campo ausente en cero. Puede representar información todavía no disponible, un caso no aplicable o un error de extracción.
4. Diseña la transición antes de publicar
Cuando sea necesario mantener dos representaciones, define cuál es la referencia y cómo se comprueba su correspondencia. Añadir temporalmente un campo nuevo junto al anterior puede facilitar la transición, pero requiere evitar que ambos diverjan.
Acuerda la secuencia de actualización de consumidores y productores. Conserva una condición verificable para retirar la representación antigua: consumidores identificados, pruebas pasadas y periodos de convivencia cumplidos.
La compatibilidad técnica no autoriza una retirada sin coordinación. Un consumidor puede seguir utilizando el campo antiguo aunque el registro de esquemas permita eliminarlo.
5. Prueba lectura, cálculo y reprocesamiento
Utiliza muestras anteriores y nuevas con valores límite, ausencias y estados desconocidos. Comprueba la salida que necesita el negocio, además de que el mensaje se deserialice sin error.
Repite una carga histórica con la nueva lógica en un entorno de validación. Verifica qué versión del esquema y de la transformación interpreta cada lote. El backfill debe conservar esa procedencia para explicar diferencias.
Incluye el caso inverso durante la convivencia: una versión antigua del consumidor recibe un dato nuevo. Si esa combinación está prohibida, el sistema debe impedirla o fallar de forma localizable, no producir silenciosamente un resultado distinto.
6. Conserva una salida ante errores
Define cómo detener nuevas emisiones o volver a una versión compatible sin perder los datos ya publicados. La reversión de código no convierte automáticamente los mensajes nuevos al formato anterior.
Registra las versiones que circularon y qué consumidores las procesaron. Esa evidencia permite delimitar una corrección en lugar de reconstruir todo el histórico sin necesidad.
Si estás preparando cambios en una plataforma de ingeniería de datos, comparte con Nexeus Big Data productores, consumidores y muestras de versiones existentes. Con ese mapa se puede diseñar una transición cuya compatibilidad se pruebe en ambos extremos.