Evolución de esquemas con Avro y Parquet: esquemas de lector y de escritor, archivos combinados y modos de compatibilidad

Qué es

El lector debe lidiar con registros escritos bajo otra versión de esquema. La especificación de Avro (citada) resuelve el esquema del escritor, que viaja junto con los datos, frente al esquema del lector, que la aplicación espera. Los campos del registro se emparejan por nombre y el orden no importa; un campo del escritor ausente en el lector se ignora; un campo del lector ausente en el escritor toma el valor predeterminado del lector, y sin un valor predeterminado se señala un error. Las promociones van en un solo sentido (int a long, float o double; long a float o double; float a double); string y bytes son intercambiables. Parquet no tiene un paso de resolución: cada archivo lleva su propio esquema, y la documentación de Spark (citada) describe la combinación de los esquemas de archivos que difieren pero son mutuamente compatibles, desactivada por defecto por tratarse de una operación relativamente costosa, y habilitable por lectura con mergeSchema. La documentación de Confluent Schema Registry (citada) nombra los modos de compatibilidad que un registro puede imponer: hacia atrás (backward: los consumidores que usan el esquema nuevo pueden leer datos producidos con el esquema anterior), hacia adelante (forward: los consumidores con el esquema antiguo leen datos nuevos), completa (full: ambas), y las variantes transitivas verificadas contra todas las versiones anteriores; backward es el modo predeterminado porque permite a los consumidores retroceder hasta el comienzo de un topic.

Por qué importa

Un campo renombrado por el productor es, para un lector cuyo esquema no lleva un alias para el nombre antiguo, un campo eliminado y uno añadido (Avro tiene alias de campo, pero la especificación hace que su uso sea opcional); un campo añadido sin valor predeterminado rompe a todo consumidor de datos antiguos; un tipo cambiado de int a string rompe la resolución. Estos fallos aparecen en el momento de la lectura, en consumidores que quien definió el esquema puede no conocer.

Cómo aplicarlo

• Añadir los campos como opcionales con un valor predeterminado (en Avro, una unión con null, valor predeterminado null); nunca eliminar un campo que los consumidores todavía leen.
• Tratar un renombrado como una adición seguida de una eliminación a lo largo de dos releases, escribiendo ambos campos en el medio, a menos que todo lector respete los alias.
• Mantener estables los nombres de columna de Parquet y depender de los nombres, no de las posiciones; habilitar la combinación de esquemas solo para las lecturas que la necesiten, y registrar el esquema vigente en el catálogo de tablas.
• Elegir el modo de compatibilidad según el orden de despliegue: backward cuando los consumidores despliegan primero, forward cuando lo hace el productor, full en cualquiera de los dos casos.
• Para un cambio incompatible, crear un nuevo subject, topic o versión de tabla, y escribir ambos mientras existan lectores antiguos.

Trampas

Un valor predeterminado de Avro debe ser un valor permitido por el esquema del campo; para una unión, debe coincidir con una de las ramas de la unión. Un símbolo de enum desconocido para el lector es un error, a menos que el enum del lector tenga un valor predeterminado. Los archivos Parquet provenientes de herramientas distintas pueden discrepar en los tipos lógicos (marcas de tiempo, decimales) incluso cuando los tipos físicos coinciden.

Qué modo de compatibilidad impone cada regla

Un registro solo impone la dirección que nombra su modo. BACKWARD (el predeterminado de Confluent) comprueba que un esquema de consumidor nuevo lea datos antiguos; permite eliminar campos y añadir campos con valores predeterminados, por lo que registrará un esquema de productor que elimina un campo que los consumidores antiguos todavía leen. FORWARD comprueba que los consumidores antiguos lean datos nuevos; permite añadir campos y eliminar solo los opcionales. FULL comprueba ambas cosas, y las variantes transitivas verifican contra todas las versiones anteriores en lugar de solo la última. El modo se elige según quién despliega primero: si los consumidores despliegan primero, BACKWARD; si lo hacen los productores, FORWARD; si es desconocido o hay muchos consumidores, FULL. La regla "nunca eliminar un campo que los consumidores todavía leen" solo la impone el registro bajo FORWARD o FULL.