Evolución de esquema: qué es y cómo cambiar sin romper consumidores
La evolución de esquema es la capacidad de modificar la estructura de un conjunto de datos —añadir una columna, cambiar un tipo, renombrar un campo— sin que dejen de funcionar los procesos y las personas que los consumen.
El problema aparece porque los datos históricos ya están escritos con la estructura antigua. Un lector nuevo tiene que poder leer ficheros viejos, y un lector viejo tiene que poder seguir leyendo los nuevos durante el tiempo que tarde en actualizarse. Esas dos exigencias son las que dan nombre a los dos tipos de compatibilidad.
Los dos sentidos de la compatibilidad
- Compatibilidad hacia atrás (backward): el código nuevo puede leer datos escritos con el esquema antiguo. Es lo que permite desplegar una versión nueva sin reescribir el histórico.
- Compatibilidad hacia delante (forward): el código antiguo puede leer datos escritos con el esquema nuevo, ignorando lo que no conoce. Es lo que permite que productor y consumidores no tengan que desplegar a la vez.
Cuando se necesitan las dos —y en una plataforma con varios equipos casi siempre se necesitan— la regla práctica es la que sigue.
Qué cambios son seguros y cuáles no
Seguros, se pueden hacer sin coordinar con nadie:
- Añadir una columna con valor por defecto o que admita nulos. Quien no la conoce la ignora; quien la lee obtiene el valor por defecto en los registros antiguos.
- Ampliar un tipo hacia otro que lo contiene: de entero de 32 bits a 64, de decimal corto a largo.
- Añadir un valor nuevo a una enumeración, siempre que los consumidores traten lo desconocido como un caso más y no fallen al encontrarlo.
Rupturas, exigen coordinar despliegues:
- Eliminar una columna o renombrarla. Renombrar es, a efectos del lector, borrar una y crear otra.
- Estrechar un tipo o hacer obligatorio un campo que antes admitía nulos.
- Cambiar el significado de un campo manteniendo el nombre. Es el más dañino de todos porque nada falla: los procesos siguen corriendo y los números salen mal en silencio.
La asimetría es la clave: añadir es barato, quitar y cambiar es caro. Por eso los esquemas de plataformas maduras tienden a crecer y a marcar campos como obsoletos en lugar de eliminarlos.
Qué aporta el formato de tabla
Los formatos de tabla modernos como Iceberg y Delta Lake gestionan esto asignando un identificador interno a cada columna, independiente de su nombre y de su posición en el fichero. Gracias a eso un renombrado deja de ser una ruptura física: el identificador no cambia y los ficheros antiguos siguen siendo legibles sin reescribirlos.
Es una mejora real, pero conviene entender su alcance. Resuelve la lectura, no el contrato: si un consumidor tiene el nombre antiguo escrito en sus consultas, el renombrado le sigue rompiendo. La compatibilidad técnica del fichero y la compatibilidad de la interfaz con quien la usa son cosas distintas.
Dónde vive la decisión
La evolución de esquema deja de ser un asunto técnico en cuanto hay más de un equipo implicado. Lo que hace falta entonces no es una herramienta sino un acuerdo: qué cambios se pueden hacer sin avisar, cuáles requieren preaviso y con cuánta antelación, y durante cuánto tiempo se mantiene un campo obsoleto antes de retirarlo.
Ese acuerdo es exactamente lo que formaliza un contrato de datos, y es la razón por la que los contratos aparecen siempre en organizaciones donde los datos cruzan fronteras de equipo. Sin él, cada cambio de esquema se negocia de cero y alguien se entera cuando su informe ya está roto.
En la guía de arquitectura de datos de Dataprix está el análisis de cómo se sostienen estos acuerdos entre equipos, y en el directorio de plataformas de datos las fichas de los motores y formatos que los soportan.