Tema representativo de entrevista

Entrevista de Ingeniería de Datos: Cómo implementar de forma segura el renombramiento de un campo de evento

DatosDifícil
Equipo editorial de Offer.ccPublicado Actualizado

Pregunta

Un evento de pedido debe renombrar `total_cents` a `amount_minor` y admitir monedas distintas al USD. Doce consumidores se despliegan de manera independiente y 90 días son reproducibles. ¿Cómo enviaría a producción el cambio de nombre y de significado?

Planteamiento y contexto

Esta migración cambia tanto el nombre de un campo como su significado: total_cents asume USD, mientras que amount_minor debe funcionar con una moneda explícita. Un alias de Avro puede ayudar en la resolución de nombres, pero no puede demostrar que los "centavos" se migraron correctamente a "unidades monetarias menores".

Qué evalúa el entrevistador

  • Expandir los lectores antes de que los productores pueblen el nuevo campo.
  • Separar la compatibilidad estructural de la semántica de los importes.
  • Preservar los esquemas antiguos y las transformaciones para la reproducción (replay) de 90 días.
  • Retirar basándose en evidencia de los consumidores en lugar de una fecha del calendario.

Aclaraciones antes de responder

Confirme el formato, el modo del registry, el comportamiento ante campos desconocidos, la representación del importe, la disponibilidad de la moneda, el consumidor más lento y el ciclo de reproducción. Pregunte si hay disponible un topic v2 cuando ambos significados no se puedan representar de forma compatible.

Una estructura de respuesta de 30 segundos

Agregue primero los campos opcionales amount_minor y currency. Actualice cada consumidor para que prefiera los nuevos campos y recurra a total_cents como respaldo, validando la igualdad para los eventos en USD. Luego, pueble de forma dual en los productores y evite que la nueva lógica de negocio lea el campo antiguo. Preserve los esquemas y transformaciones históricos más allá de los 90 días. Elimine el campo antiguo solo después de que los productores dejen de escribirlo, los consumidores y las dependencias offline dejen de leerlo, y una reproducción completa de 90 días pase con éxito con el nuevo esquema.

Análisis detallado paso a paso

La fase uno es aditiva. La compatibilidad del registry y una matriz de lectores/escritores en CI bloquean las versiones no válidas. Los consumidores obtienen soporte de lectura dual antes de que se desplieguen los nuevos productores.

La fase dos realiza el poblado dual. USD requiere amount_minor == total_cents y currency == USD; los eventos no-USD pueblan únicamente la nueva semántica verídica. Rastree la cobertura, el uso del valor de respaldo (fallback) y las discrepancias por versión del productor, consumidor y moneda.

La fase tres detiene la dependencia de negocio del campo antiguo mientras preserva la capacidad de reproducción. El reproductor elige las transformaciones según el ID del esquema del escritor en lugar de interpretar el historial con los valores predeterminados actuales. Si un solo subject no puede expresar ambos significados de forma segura, use un topic v2 y un traductor explícito.

Retire solo después de que todos los productores detengan las escrituras antiguas, el fallback llegue a cero, transcurra la ventana completa de reproducción y se inventaríen los trabajos offline. Mantenga un esquema de reversión (rollback) y una versión de transformación listos para desplegar.

Ejemplo de respuesta sólida

Utilizaría el patrón expandir-migrar-contraer: agregar campos y actualizar lectores, escribir de forma dual y conciliar, y luego retirar el campo antiguo solo cuando la evidencia demuestre que todas las dependencias lo han abandonado. Los alias solo resuelven el renombramiento; la semántica de las monedas necesita pruebas de contrato e invariantes en tiempo de ejecución.

El campo antiguo se mantiene durante una ventana de reproducción completa. Si las escrituras duales en USD discrepan, congele el despliegue y mantenga total_cents como autoritativo para ese lote en USD mientras se repara el productor. Los eventos no-USD deben mantener amount_minor + currency como autoritativo; pause la ingestión de nuevos eventos no-USD o enrútelos a un topic v2 en lugar de inventar un valor en centavos. Tras el retiro, ambos campos nuevos se convierten en invariantes obligatorios en tiempo de ejecución. La eliminación por contrato comienza solo después de que se hayan cerrado las rutas online, offline y de reproducción.

Errores comunes

  • Renombrar el campo en un solo commit del esquema.
  • Tratar un alias como una conversión de importe.
  • Desplegar los productores antes que los consumidores.
  • Leer el historial antiguo con la moneda predeterminada actual.
  • Pasar por alto a los consumidores offline y de reproducción.

Preguntas de seguimiento

¿Por qué es insuficiente un alias?

Ayuda a resolver el nombre de un campo; no demuestra que los centavos y la unidad menor de otra moneda tengan un significado equivalente.

¿Cuándo se requiere un topic v2?

Cuando los significados antiguo y nuevo no se pueden representar de forma inequívoca bajo el contrato de compatibilidad requerido.

¿Qué ocurre si las escrituras duales discrepan?

Para las escrituras duales en USD, detenga el despliegue, mantenga total_cents como autoritativo para el lote afectado, aísle por versión del productor, corrija y reproduzca. Para no-USD, mantenga amount_minor + currency como autoritativo y pause la ingestión o use un topic v2; nunca recurra a un valor de centavos inventado.

¿Cuándo se puede eliminar el campo antiguo?

Después de que se detengan las escrituras antiguas, el fallback sea cero, transcurra la ventana de reproducción completa y el inventario offline esté limpio.

Fuentes públicas

Preguntas relacionadas