Prompt y contexto
Esta pregunta de ingeniería de datos evalúa la evolución a largo plazo de contratos de eventos. El objetivo no es recitar definiciones de compatibilidad hacia atrás o hacia adelante, sino derivar un plan seguro a partir de lectores y escritores reales, el formato de serialización, los datos históricos y el orden de despliegue. Debes explicar los objetivos de compatibilidad, la semántica de los campos, el registro y las pruebas, la operación con dos versiones y las condiciones para la limpieza final.
Qué evalúa el entrevistador
- Si distingues entre el esquema de writer, el esquema de reader y las combinaciones que ocurren durante el despliegue.
- Si eliges restricciones hacia atrás (backward), hacia adelante (forward), completas (full) o transitivas (transitive) según el orden de despliegue de los consumidores.
- Si sabes manejar campos obligatorios, cambios en enumeraciones, valores predeterminados, valores desconocidos y reproducciones históricas.
- Si la gobernanza mediante registros, las pruebas de contrato, el monitoreo, la reversión (rollback) y la propiedad forman parte del proceso de lanzamiento.
Preguntas aclaratorias para hacer
Enumera el formato del evento, el topic o la tabla, cada productor y consumidor, los suscriptores externos o entre equipos y la velocidad de actualización de cada consumidor. Aclara si fulfillment_mode tiene un significado nuevo o si se puede derivar sin pérdida de información a partir del status antiguo, y si la nueva enumeración permite valores desconocidos. Pregunta también si los eventos históricos deben reproducirse, si el data lake almacena cargas útiles sin procesar, quién es el propietario de la política de compatibilidad y si dos versiones pueden ejecutarse brevemente en paralelo.
Marco para una respuesta de 30 segundos
Elaboraría el inventario de consumidores y el orden de despliegue de readers y writers, elegiría la dirección de compatibilidad y la aplicaría mediante un registro. Agregaría el nuevo campo como opcional o con un valor predeterminado estable, usaría una representación de enumeración extensible y haría que los productores escriban tanto los campos antiguos como los nuevos mientras los consumidores migran según sus capacidades. Definiría los mapeos y el comportamiento ante valores desconocidos para la reproducción, y luego validaría mediante pruebas de contrato, muestras de reproducción y monitoreo en tiempo de ejecución. Eliminaría los campos o versiones antiguos solo después de que todos los consumidores hayan migrado y la ventana de retención haya finalizado.
Análisis detallado paso a paso
1. Trazar la matriz de reader/writer y el objetivo de compatibilidad
Enumera writer antiguo con reader antiguo, writer antiguo con reader nuevo, writer nuevo con reader antiguo y writer nuevo con reader nuevo. Si los consumidores pueden actualizarse primero, necesitas compatibilidad hacia adelante; si los productores se actualizan primero, necesitas compatibilidad hacia atrás; un despliegue continuo suele requerir ambas durante la transición. La reproducción histórica a lo largo de muchas versiones también exige comprobaciones transitivas en lugar de comparar únicamente con el esquema más reciente.
2. Hacer que la semántica de los campos sea extensible de forma segura
No hagas que un nuevo campo sea inmediatamente obligatorio para todos los readers antiguos. Con formatos como Avro, utiliza una unión con tipo nulo (nullable union) o un valor predeterminado cuando corresponda; con JSON, define la diferencia entre campos ausentes, nulos y desconocidos. Al extender una enumeración, asegúrate de que los consumidores antiguos tengan una rama segura para valores desconocidos en lugar de asumir que solo llegarán los valores actuales. Si el status antiguo no puede mapearse sin pérdida de información, agrega una nueva versión del evento o un campo paralelo en lugar de cambiar silenciosamente el significado.
3. Usar un registro y pruebas de contrato para bloquear lanzamientos incompatibles
Registra los esquemas por asunto o tipo de evento y define la nomenclatura, el nivel de compatibilidad y el propietario. Valida los nuevos esquemas durante las compilaciones del productor. En el CI del consumidor, deserializa muestras reales antiguas y nuevas y valida el comportamiento del negocio. Prueba valores predeterminados, enumeraciones desconocidas, semántica de tiempo y unidades, nulos y el comportamiento tras la eliminación de campos, no solo el éxito del análisis sintáctico (parsing). Una comprobación fallida bloquea el lanzamiento en lugar de convertirse en un error de consumidor en producción.
4. Desplegar con escritura dual y por etapas
Lanza primero los consumidores que puedan leer ambos formatos. Luego, haz que los productores completen el nuevo campo mientras conservan el antiguo. Monitorea las versiones de los consumidores, los errores de parseo, el uso de valores predeterminados y el retraso (lag) de eventos; las canalizaciones de datos también deben verificar los tipos de tablas, las particiones y los reprocesamientos (backfills). En caso de una enumeración o estructura incompatible, crea un nuevo tipo de evento o topic, utiliza un puente (bridge) para publicar en ambos y asigna a cada ruta un propietario y una fecha de retiro.
5. Definir las condiciones de reproducción, reversión y limpieza
Analiza los eventos históricos con su esquema de writer y luego utiliza un mapeo versionado explícito para crear el modelo actual. No apliques silenciosamente el valor predeterminado de hoy a un hecho de ayer. Conserva los esquemas antiguos y nuevos, el código de conversión y las instantáneas de muestra. Durante la reversión de un productor, verifica que la versión antigua pueda leer los eventos ya escritos. Elimina los campos antiguos o los topics puente solo después de que todos los consumidores hayan migrado, las lecturas del campo antiguo lleguen a cero, las comprobaciones de reproducción y calidad sean exitosas y la ventana de notificación se haya cerrado.
Ejemplo de una respuesta sólida
Elaboraría un inventario de la docena de consumidores y las diversas canalizaciones de datos, trazaría las cuatro combinaciones de reader/writer durante el despliegue continuo y determinaría si fulfillment_mode se deriva sin pérdida de información a partir del status antiguo o si es un hecho nuevo. Si se puede derivar, haría que el campo sea opcional con un valor predeterminado estable y conservaría el status antiguo; la enumeración incluiría una rama segura para valores desconocidos. Desplegaría consumidores capaces de leer ambos formatos y luego haría que los productores realicen escrituras duales mientras el registro impone la compatibilidad. El CI probaría eventos antiguos y nuevos, campos faltantes, enumeraciones desconocidas y reproducción histórica, mientras que el monitoreo de producción rastrearía fallos de parseo, uso de valores predeterminados, versiones de consumidores y calidad de las tablas. Si la estructura es verdaderamente incompatible, crearía una nueva versión del evento y conectaría ambas rutas mediante un puente. Solo después de que todos los consumidores migren, las lecturas del campo antiguo lleguen a cero, la validación de reproducción sea exitosa y la ventana de reversión se cierre, eliminaría el campo antiguo y el puente.
Errores comunes
- Decir “habilitar compatibilidad hacia atrás” sin enumerar el orden de despliegue de productores y consumidores.
- Agregar un campo obligatorio sin un valor predeterminado, sin una regla para campos faltantes o sin una ruta segura para los readers antiguos.
- Extender una enumeración de modo que los consumidores antiguos lancen excepciones o traten un valor desconocido como un estado de negocio incorrecto.
- Comprobar únicamente si un esquema se registra en lugar de probar muestras antiguas reales, reproducción, tipos de tablas y resultados de negocio.
- Sobrescribir el significado de un campo de manera que la reproducción histórica se interprete incorrectamente.
- Mantener escrituras duales y código puente para siempre sin un propietario, monitoreo, fecha de retiro o condición de reversión.
Preguntas de seguimiento y respuestas
¿Cómo eliges la compatibilidad hacia atrás, hacia adelante o completa?
Utiliza el orden de despliegue y el comportamiento de consumo. Un despliegue donde los productores van primero requiere que los readers antiguos lean datos nuevos, por lo que se prioriza la compatibilidad hacia atrás. Un despliegue donde los consumidores van primero requiere que los readers nuevos lean datos antiguos, por lo que se prioriza la compatibilidad hacia adelante. Si el orden no está controlado o ambas direcciones deben funcionar, utiliza compatibilidad completa. Para todas las versiones históricas, utiliza transitiva y confirma las reglas reales del formato.
¿Por qué un campo nuevo debería tener generalmente un valor predeterminado?
Los eventos antiguos no lo contienen, por lo que leer datos antiguos requiere un comportamiento explícito. Un valor predeterminado permite que el reader analice el evento, pero debe significar desconocido o no proporcionado en lugar de fingir que es un hecho histórico. Si no hay un valor predeterminado significativo, utiliza un tipo nullable, una nueva versión del evento o un reprocesamiento explícito.
¿Cómo manejas una nueva enumeración durante la reproducción histórica?
Conserva el esquema de writer, analiza primero la semántica original y mapea hacia el modelo actual mediante una conversión versionada. Envía los valores no mapeables a cuarentena o a procesamiento manual con un motivo; no descartes el evento ni apliques silenciosamente el estado predeterminado actual.
¿Cuándo se puede eliminar el campo antiguo?
Después de que todos los productores y consumidores hayan migrado, las lecturas y escrituras del campo antiguo sean cero, las pruebas de reproducción, calidad y contrato hayan sido exitosas, se hayan cerrado las ventanas de notificación a clientes o suscriptores externos y los materiales de reversión y auditoría sigan disponibles. Elimínalo por etapas.