Entrevista de Ingeniería de Datos: ¿Cómo evolucionar un contrato de datos sin romper a los consumidores?

Pregunta y escenario

Esta es una consigna de evolución de esquemas para niveles de ingeniería de datos mid a senior. El evento alimenta métricas en tiempo real y un lakehouse; los consumidores ejecutan diferentes versiones y no pueden actualizarse todos en un solo día. Asuma una entrega al menos una vez (at-least-once) y eventos reproducibles (replayable). El contrato debe cubrir tipos de campos, semántica, calidad, frescura, propiedad y límites de seguridad.

Lo que el entrevistador está evaluando

• Una respuesta sólida separa "el campo se analiza sintácticamente (parses)" de "el significado de negocio no ha cambiado".
• ¿Puede construir una matriz de compatibilidad entre productores y consumidores en lugar de afirmar que agregar un campo siempre es seguro?
• ¿Utiliza el linaje y la evidencia de uso para identificar columnas, consultas y tableros afectados?
• ¿Puede hacer cumplir el contrato en CI, compuertas de despliegue y en tiempo de ejecución manteniendo una migración reversible?

Preguntas de aclaración que deben hacerse primero

Confirme el formato del evento y el registro (registry), la unidad y rango actual de amount, si los consumidores rechazan campos desconocidos, si los mensajes antiguos se reproducen y qué significa la ausencia de currency. Un cambio de unidad o redondeo constituye una ruptura semántica incluso si el tipo de transferencia (wire type) se analiza sintácticamente; un campo de metadatos opcional tiene una migración diferente. Pregunte también si las versiones de los consumidores son observables, si es aceptable un topic temporal de doble versión y qué ventanas de frescura y reprocesamiento (backfill) aplican.

Un marco de respuesta de 30 segundos

Definiría el contrato incluyendo esquema, semántica de campos, reglas de calidad, frescura, propiedad y restricciones de seguridad, y luego realizaría un inventario del linaje y las capacidades de los consumidores. No cambiaría silenciosamente amount; publicaría una versión o nuevos campos, mantendría legible la proyección anterior, ejecutaría CI de compatibilidad y validación en sombra (shadow validation), y migraría a los consumidores por lotes. La validación en tiempo de ejecución rechazaría o pondría en cuarentena las infracciones con evidencia versionada. Tras la migración mantendría una ventana de desuso (deprecation window) calculada, reconstruiría las proyecciones antiguas a partir de los eventos retenidos y demostraría la equivalencia mediante conciliación y reproducción.

Análisis detallado paso a paso

1. Escribir el límite del contrato. Registre unidades, precisión, nulabilidad, enumeraciones (enums), claves, tiempo del evento, objetivo de frescura, etiquetas de PII, propietarios y aprobación para cambios disruptivos (breaking changes), además de nombres y tipos. OpenMetadata modela esquema, semántica, SLA, seguridad, pruebas de calidad y propiedad como un único objeto gobernado de contrato de datos.
2. Clasificar el cambio. Agregar un campo opcional suele ser retrocompatible para lectores tolerantes; la eliminación, los cambios de tipo, rangos reducidos, cambios de unidad o cambios de opcional a obligatorio son inicialmente disruptivos. Cambiar centavos enteros a dinero decimal altera la semántica, por lo que debe agregarse un campo normalizado o versión en lugar de reemplazar silenciosamente el anterior.
3. Realizar un análisis de impacto. Utilice los metadatos de OpenLineage de Dataset, Job, Run y Schema Facet para encontrar trabajos, tablas posteriores, linaje de columnas y ejecuciones recientes. Para los 40 consumidores, registre la versión del analizador sintáctico, el uso de campos, el comportamiento de reproducción y el propietario de la migración en una matriz de cambios por consumidor.
4. Diseñar la migración. Durante un período delimitado, publique amount_minor y amount_decimal, o publique un evento v2. Los consumidores antiguos continúan leyendo la proyección previa; los nuevos consumidores leen en sombra los nuevos campos. Publique currency como opcional solo cuando se pueda demostrar que un valor por defecto no altera el significado de negocio.
5. Establecer compuertas. CI compara el contrato candidato con la versión registrada en busca de cambios de tipo, obligatoriedad, enum y semántica. Luego, ejecute reproducciones de muestra, aserciones de calidad y pruebas de contrato de consumidores. El ingreso en producción valida las versiones de los eventos; los mensajes no válidos se envían a cuarentena con productor, versión del contrato y motivo.
6. Alternar y revertir. Migre los consumidores en lotes mientras monitorea errores de análisis sintáctico, ausencia de campos, conciliación monetaria, latencia y diferencias de reproducción. Si la nueva proyección es incorrecta, detenga las escrituras de la nueva versión y restaure la ruta de lectura anterior; los eventos retenidos pueden reconstruir la proyección previa. No elimine los campos antiguos hasta que el último consumidor y la ventana de reproducción superen el límite de desuso.
7. Hacerlo atribuible. Los eventos de ejecución de OpenLineage describen trabajos, ejecuciones, entradas y salidas; un Schema Facet registra los campos del conjunto de datos. Incluya la versión del contrato, la revisión de Git y el resultado de la validación en los eventos de linaje para que una investigación posterior pueda identificar qué versión modificó el resultado de qué consumidor.

Respuesta de muestra de alta calidad

No trataría esto como una simple adición de campo. En primer lugar, incluiría en el contrato la unidad, la precisión y las reglas de redondeo de amount, y luego inspeccionaría el linaje para saber si los 40 consumidores lo utilizan como centavos enteros, un valor de visualización o una clave de agregación. El modelo de contrato de datos de OpenMetadata cubre esquema, semántica, SLA, seguridad, pruebas de calidad y propiedad, lo que evita que una verificación de tipo "el analizador sintáctico lo acepta" se confunda con una garantía de negocio.

Registraría una versión v2 o una versión de doble campo compatible: retener amount_minor, agregar amount_decimal con precisión explícita y agregar el campo opcional currency. CI ejecutaría verificaciones de compatibilidad; las pruebas de contrato de consumidores cubrirían campos desconocidos, ausencia de moneda, reproducción de mensajes antiguos y límites de precisión. Calcularía en sombra la nueva proyección, migraría los consumidores en lotes y rechazaría eventos sin una versión de contrato válida en el ingreso, poniendo en cuarentena las fallas con una alerta.

Durante la transición monitorearía la conciliación monetaria, la ausencia de campos, los errores de análisis sintáctico, la latencia y las diferencias de reproducción. Cualquier discrepancia detiene las escrituras de la nueva versión, restaura la ruta de lectura anterior y reconstruye a partir de los eventos retenidos. Solo después de que todos los consumidores migren, se cierre la ventana de reproducción y las métricas de desuso lleguen a cero, eliminaría el campo anterior. Los metadatos de Job, Run, Dataset y Schema Facet de OpenLineage llevarían las versiones del contrato y los resultados de validación para que el análisis de impacto y la auditoría sigan siendo reproducibles.

Errores comunes

• Verificar solo si el JSON se analiza sintácticamente → tratar la compatibilidad de tipos como compatibilidad semántica → incluir unidades, precisión, nulabilidad y rangos en el contrato y revisarlos por separado.
• Publicar porque es "solo un campo nuevo" → los analizadores sintácticos estrictos o las verificaciones de campos obligatorios fallan → realizar un inventario de consumidores y usar una versión o doble campo cuando sea necesario.
• Monitorear registros solo después de producción → los datos erróneos ya son difíciles de recuperar → establecer compuertas en CI, reproducir muestras y poner en cuarentena en tiempo de ejecución.
• Eliminar el campo antiguo inmediatamente → los consumidores rezagados o que reproducen eventos pierden su ruta de lectura → establecer una ventana de desuso que cubra a los consumidores y la reproducción.
• Tratar el linaje como un catálogo estático → no se puede responder qué ejecución se vio afectada → conectar Job, Run, Dataset, Schema Facet, versión y evidencia de validación.

Preguntas de seguimiento y respuestas

¿Qué sucede si un consumidor heredado no puede actualizarse?

Mantenga una proyección antigua compatible o una capa de traducción para que los nuevos eventos también generen la vista previa. Asigne a ese consumidor un propietario, una fecha límite y un presupuesto de error (error budget). No congele el contrato indefinidamente ni permita que el traductor altere silenciosamente el significado monetario.

¿Qué sucede si falta la moneda y no se puede inferir de manera segura?

Trátelo como una violación del contrato o un estado desconocido explícito; no invente un valor predeterminado plausible. Ponga en cuarentena el evento y notifique al productor. Si el negocio lo permite, publique un valor explícito de "moneda no especificada" y exclúyalo o agrúpelo en las métricas posteriores.

¿Cómo demuestra que la reversión no duplicó el conteo de dinero?

Utilice el ID de evento, la versión del contrato y la versión de la proyección como claves de idempotencia. Reproduzca ambas proyecciones y compare los agregados por pedido y moneda. Conserve muestras de diferencias, reglas de redondeo e instantáneas de entrada; reanude las escrituras de la nueva versión solo después de que se supere la conciliación.