Evolución de esquemas y compatibilidad con versiones anteriores

Los esquemas de extracción no son estáticos. Los requisitos empresariales evolucionan, aparecen nuevos tipos de documentos y usted descubre campos que debería haber capturado desde el principio. Cambiar un esquema en una canalización activa crea un problema de compatibilidad con versiones anteriores: los registros extraídos existentes usan el esquema antiguo, mientras que los nuevos usan el esquema nuevo. Gestionar esta transición de forma segura es en lo que consiste la evolución de esquemas.

Asigne un número de versión a cada esquema y guárdelo junto a cada registro extraído. Cuando cambie el esquema, incremente la versión. Esto le permite consultar registros por versión del esquema, ejecutar migraciones en registros antiguos y mantener una lógica de validación independiente para cada versión. Un simple campo de cadena schema_version en cada modelo de salida es suficiente.

Los cambios aditivos son seguros: añadir un campo Optional o un campo con un valor predeterminado no rompe el código de extracción antiguo ni los registros existentes. Los cambios incompatibles son arriesgados: cambiar el nombre de un campo, cambiar su tipo de string a int o eliminarlo romperá los consumidores posteriores. Prefiera siempre los cambios aditivos. Cuando no se pueda evitar un cambio incompatible, cree una nueva versión principal del esquema y realice la migración de forma controlada.

Incluya la versión del esquema en la tabla de resultados de extracción para saber siempre qué versión produjo cada registro. Una columna jsonb que almacene todos los datos extraídos, junto con una columna de texto schema_version, es un patrón habitual. Esto le permite escribir consultas que tengan en cuenta la versión y migrar de forma selectiva los registros antiguos durante periodos de poco tráfico.

Escriba un script de migración para cada transición entre versiones del esquema. El script debe leer los registros antiguos, transformarlos al formato nuevo y volver a escribirlos con la nueva versión. Ejecute las migraciones en lotes pequeños y dentro de transacciones para que un fallo no deje la base de datos en un estado parcialmente migrado. Mantenga siempre disponible el esquema antiguo hasta verificar que la migración se ha completado.

Durante una migración de esquema, realice una validación paralela: extraiga datos con el esquema antiguo y el nuevo simultáneamente para una muestra de los documentos entrantes. Compare los resultados para verificar que el esquema nuevo captura todo lo que capturaba el antiguo, además de los campos nuevos. Retire el esquema antiguo únicamente después de que la validación paralela muestre una paridad estable en una muestra estadísticamente significativa.

Use indicadores de funcionalidades para controlar cuándo su canalización cambia del esquema antiguo al nuevo. Esto le permite desplegar gradualmente el esquema nuevo para un porcentaje del tráfico, supervisar las tasas de error y revertirlo al instante si algo sale mal, sin volver a desplegar el código. Funcionan tanto servicios de indicadores como LaunchDarkly como una simple fila en la base de datos.

Los consumidores posteriores que leen datos extraídos deben gestionar correctamente varias versiones del esquema. Use una unión discriminada en el código del consumidor que seleccione la lógica de análisis adecuada basándose en el campo schema_version. Esto es más sólido que escribir cadenas condicionales de if-else y resulta más fácil de ampliar cuando llegue la versión 3.

Antes de desplegar un esquema nuevo, ejecútelo con todo su conjunto de pruebas de regresión: una colección seleccionada de documentos representativos con resultados esperados conocidos. Compare las puntuaciones F1 de cada campo entre el esquema antiguo y el nuevo. Una regresión en la puntuación F1 de cualquier campo significa que la descripción del esquema nuevo confundió al modelo; corrija la descripción del campo antes de ponerlo en producción.

Cuando una versión del esquema deje de utilizarse para nuevas extracciones, puede marcarla como obsoleta. La obsolescencia significa dejar de aceptar registros nuevos en esa versión, mantener los registros antiguos legibles y programar una fecha de retirada en la que los registros antiguos se migrarán o archivarán. Documente la obsolescencia en un registro de cambios para que todos los consumidores sepan que deben actualizar su código de análisis.

Cada cambio de esquema debe ir acompañado de una entrada en el registro de cambios que describa qué ha cambiado, por qué, las instrucciones de migración y el impacto previsto. Comparta las entradas del registro de cambios con todos los equipos que consumen datos extraídos antes de desplegar el cambio. Muchos desastres de migración de esquemas no se deben a fallos técnicos, sino a que los consumidores no fueron informados de que se acercaba un cambio.

Compruebe su comprensión de la evolución de esquemas y la compatibilidad con versiones anteriores en las canalizaciones de extracción.

En esta lección ha aprendido que el control de versiones de esquemas almacena un identificador de versión junto a cada registro extraído para poder migrarlos de forma selectiva; los cambios aditivos son seguros, mientras que cambiar el nombre o el tipo de los campos requiere una migración cuidadosa; y la validación paralela permite verificar el esquema nuevo antes de retirar el antiguo. A continuación, mediremos la latencia de los LLM con las métricas TTFT y TPOT.