Planteamiento y alcance
Esta pregunta evalúa si un ingeniero de datos puede convertir un acuerdo de datos entre equipos en una interfaz verificable y evolutiva. Supongamos que un equipo de pagos publica eventos de pedidos utilizados por paneles financieros, características de riesgo e informes de operaciones; los tipos de campo, el significado comercial, los umbrales de calidad y las ventanas de disponibilidad no están acordados, por lo que un pequeño cambio puede convertirse en un incidente aguas abajo.
Es adecuada para roles de ingenieros de datos, ingenieros de plataformas de datos y gobernanza de productos de datos. Concéntrate en los límites del contrato, la propiedad, la compatibilidad de versiones, la validación y el manejo de fallos en lugar de una elección particular de Kafka, almacén de datos o proveedor. Indica qué garantiza el productor, qué pueden asumir los consumidores y cómo bloquear o degradar el servicio cuando la garantía no se puede cumplir.
Qué evalúa el entrevistador
Una respuesta sólida separa un contrato de datos de un simple esquema: el contrato también describe la semántica de los campos, las aserciones de calidad, los datos sensibles, los niveles de servicio, la propiedad y las reglas de cambio. Deriva un contrato mínimo a partir de las necesidades del consumidor, explica el límite entre las verificaciones previas al despliegue y la monitorización en tiempo de ejecución, y utiliza políticas de compatibilidad para adiciones, obsolescencias y cambios semánticos. También designa al responsable de las notificaciones, el límite de aislamiento, la ruta de reversión y la estrategia de reproducción cuando se infringe un contrato.
Preguntas aclaratorias para hacer
- ¿El activo es un flujo de eventos, una tabla, un archivo o una característica de modelo? ¿Qué nivel de frescura y latencia se permiten?
- ¿Qué consumidores dependen de él y qué campos, semántica temporal, precisión y retención necesitan?
- ¿Qué significa "correcto" en este caso: obligatoriedad, unicidad, rangos, enumeraciones, reglas entre campos y conciliación?
- ¿Qué campos contienen datos personales o financieros y quién aprueba el acceso, el enmascaramiento y el uso permitido?
- ¿El cambio es retrocompatible, requiere escrituras duales o debe rechazarlo una puerta de enlace de despliegue? ¿Se puede retrasar, aislar o revertir una infracción?
Un marco de respuesta de 30 segundos
"Haría que los consumidores indiquen primero sus necesidades de negocio y luego dividiría el contrato en estructura, semántica, calidad, frescura, seguridad y responsabilidad. Cada contrato tiene un propietario, versión, estado y política de cambios. Los productores ejecutan comprobaciones de esquema y calidad antes del despliegue; los consumidores monitorizan la frescura y la disponibilidad en la ingesta. Los cambios compatibles se envían directamente, mientras que los cambios disruptivos utilizan una nueva versión, migración de doble vía y una ventana de obsolescencia. Una comprobación fallida aísla los datos erróneos, notifica al propietario y conserva la entrada sin procesar reproducible. Validaría el diseño con la tasa de defectos por cambio, el lugar donde se detectan por primera vez las infracciones y el tiempo de recuperación."
Respuesta paso a paso
Paso 1: Delimitar el contrato a partir de los casos de uso de los consumidores
Enumera los campos y las decisiones que los consumidores realmente necesitan en lugar de copiar cada columna de una tabla de productor. Para cada campo, registra el significado comercial, la unidad, la zona horaria, la nulabilidad y el origen; por ejemplo, si total_amount son centavos o dólares y si created_at es la hora del evento o la hora de escritura. Mantén los detalles de implementación interna fuera de la promesa compartida.
Paso 2: Definir la estructura, la semántica y las aserciones de calidad
La estructura cubre nombres de campos, tipos, obligatoriedad y anidamiento. La semántica cubre enumeraciones, unidades, ventanas de tiempo y definiciones de cálculo. Las aserciones de calidad cubren nulos, unicidad, rangos, distribuciones y relaciones entre campos. OpenMetadata separa esquema, semántica, seguridad, aserciones comerciales, SLA y estado; esa estratificación evita que "el campo existe" se confunda con "los datos son confiables".
Paso 3: Hacer explícitas la frescura, la seguridad y la propiedad
Define la frecuencia de actualización, la latencia máxima, la retención y las ventanas de disponibilidad. Asigna un propietario del productor, un contacto de respaldo y un canal de soporte para el consumidor. Agrega etiquetas de clasificación, políticas de acceso y restricciones de uso permitido para campos sensibles. El límite debe ser aplicable: el productor garantiza el cumplimiento del contrato, mientras que el consumidor sigue validando sus propias derivaciones comerciales.
Paso 4: Elegir reglas de control de versiones y compatibilidad
Separa la versión del contrato de la versión de implementación del producto de datos. Agregar un campo opcional suele ser compatible; eliminar un campo, cambiar su tipo, reducir una enumeración o cambiar la semántica temporal es de alto riesgo. Publica una nueva versión o capa de traducción para cambios disruptivos, realiza escrituras duales mientras los consumidores migran, establece una fecha límite y retira la versión anterior solo después de que el uso y la ventana de obsolescencia lleguen a cero. Un modo de compatibilidad de registro de esquemas no puede ocultar un cambio semántico.
Paso 5: Colocar el contrato en la puerta de enlace de despliegue
Almacena el contrato en el control de versiones y revísalo en pull requests. La CI debe validar el formato del contrato y luego ejecutar comprobaciones de estructura, calidad y compatibilidad contra muestras o datos paralelos (shadow data) antes de publicar. Los contratos de datos de Confluent pueden expresar restricciones de integridad, metadatos, reglas de migración y etiquetas de datos sensibles, lo que ilustra por qué las reglas ejecutables son más sólidas que los recordatorios en la documentación. Una puerta fallida bloquea el despliegue o desvía los datos erróneos a cuarentena.
Paso 6: Diseñar la protección en tiempo de ejecución y la recuperación
Monitoriza la frescura, los valores faltantes, la desviación de enumeraciones, la latencia, los errores de los consumidores y el estado del contrato después del despliegue. Conserva la carga útil sin procesar, la versión y el resultado de la validación para su posterior reproducción. Un panel de control o servicio de características puede usar temporalmente la última instantánea de confianza con una etiqueta de obsolescencia; la liquidación, la autorización y otras acciones irreversibles deben detenerse y alertar. Las alertas deben apuntar a un propietario y una ruta de escalamiento, no solo decir "problema de datos".
Paso 7: Ejercitar el diseño con un cambio
Supongamos que un evento de pedido cambia amount de un entero de centavos a un objeto con importe y moneda. Identifica a los consumidores, publica una nueva versión, realiza escritura dual, reproduce muestras y concilia los resultados antiguos y nuevos antes de dar de baja la versión anterior. Si refunded cambia de "reembolso iniciado" a "reembolso completado", es un cambio semántico disruptivo aunque su tipo no haya cambiado. El ejercicio demuestra que el contrato cubre el significado, no solo la forma de los campos.
Paso 8: Revisar si el contrato funciona
Haz un seguimiento de la proporción de cambios disruptivos bloqueados por las puertas de enlace, el lugar donde se detectan por primera vez los incidentes, el tiempo desde la infracción hasta la recuperación, los consumidores restantes en versiones antiguas y los conjuntos de datos sin propietario. Si los incidentes siguen apareciendo primero en los paneles de control aguas abajo, las comprobaciones son demasiado tardías o las aserciones son demasiado débiles. Si el contrato contiene muchos campos sin usar, reduce sus límites. Versiona y mantén el contrato a medida que cambien el uso comercial y los consumidores; no es un documento único e inmutable.
Compensaciones de diseño y límites
Un mayor nivel de detalle puede proporcionar una protección más sólida, pero también eleva el costo de los cambios para productores y consumidores. Yo incluiría las suposiciones entre equipos que afectan las decisiones de negocio o que no se pueden reproducir en el contrato obligatorio, manteniendo los campos experimentales como opcionales. Establece umbrales de calidad según el caso de uso: los datos de liquidación pueden requerir una exhaustividad estricta, mientras que el análisis exploratorio puede aceptar retrasos con una etiqueta explícita de confianza o frescura. No dupliques cada regla de gobernanza en un solo archivo; vincula la aprobación de acceso, los requisitos de retención y la documentación del producto de datos para evitar fuentes de verdad paralelas.
¿Cuándo se debe rechazar un despliegue?
Me negaría a marcar una versión como activa cuando el significado de los campos no sea claro, falte un propietario crítico, un cambio disruptivo carezca de plan de migración o una aserción de calidad no pueda ejecutarse en ningún límite. Puede permanecer en borrador mientras los consumidores confirman sus suposiciones y el productor proporciona muestras y evidencia de reproducción.
¿Cómo resuelves los conflictos entre consumidores?
Separa las garantías compartidas de las necesidades específicas de cada consumidor. Mantén el contrato compartido pequeño, estable y verificable. Si un consumidor necesita mayor precisión o menor latencia, proporciona un producto de datos derivado o un SLA escalonado en lugar de obligar a todos los consumidores a asumir el mismo costo. Cada excepción necesita un propietario, una fecha de vencimiento y una condición de salida.
Plan de implementación y evidencia
Comienza con un conjunto de datos de alto impacto que tenga un conjunto limitado de consumidores: registra a los consumidores, escribe el contrato mínimo, ejecuta comprobaciones de muestras en CI y luego agrega monitorización de frescura y calidad en el límite de producción. Después de la primera migración, revisa los cambios bloqueados, los falsos positivos, el tiempo de recuperación y los comentarios de los consumidores antes de expandir a más temas o tablas. La evidencia permite ajustar las aserciones antes de instalar una gran plataforma de gobernanza sin usuarios.
¿Cuáles son los criterios de salida del piloto?
Define criterios de salida: varios ciclos de despliegue pasan la puerta de enlace, las infracciones se detectan antes de contaminar aguas abajo, los consumidores completan la migración y el propietario responde dentro del plazo acordado. Si no se cumplen los criterios, reduce el alcance o revisa el contrato en lugar de presentar un piloto fallido como un éxito de la plataforma.
¿Cómo demuestras que la mejora es real?
Compara los cambios disruptivos antes y después del piloto, la ubicación de la primera detección, el recuento de reversiones y el tiempo de recuperación, segmentados por conjunto de datos y consumidor. Si los incidentes disminuyen mientras que la frecuencia de despliegue también se reduce, incluye el rendimiento de cambios y el tiempo de espera. Si las puertas bloquean muchos cambios pero los falsos positivos son altos, mejora las aserciones y las muestras en lugar de desactivar la puerta.
Errores comunes y preguntas de seguimiento
Llamar contrato de datos a los tipos de campo
Los tipos y la obligatoriedad protegen la forma, no la moneda, la semántica temporal, la calidad, la frescura, el acceso o la propiedad. Sin esas garantías, los consumidores pueden recibir datos estructuralmente válidos pero semánticamente incorrectos.
Hacer que los consumidores absorban todas las disputas
Los consumidores pueden monitorizar sus propios resultados, pero no pueden asumir la responsabilidad de la definición compartida ni del despliegue del productor. El contrato debe establecer las garantías del productor, las suposiciones del consumidor y la ruta de escalamiento entre ellos.
Alertar solo en tiempo de ejecución
Para cuando los datos erróneos llegan a una capa compartida, varios sistemas aguas abajo pueden haberse contaminado. Mueve las comprobaciones de estructura y compatibilidad hacia la izquierda (shift left); utiliza la monitorización en tiempo de ejecución y la cuarentena para las aserciones de negocio que no puedan determinarse antes del despliegue.
¿Cómo clasificas y migras un cambio disruptivo?
Evalúa el impacto en el consumidor, no solo la diferencia en el esquema (schema diff). Eliminar un campo, cambiar un tipo, reducir una enumeración o cambiar una unidad o definición temporal puede romper a los consumidores. Publica una nueva versión o capa de traducción, valida ambas vías, notifica a los propietarios y elimina la versión anterior solo después de que el uso sea cero y la ventana de obsolescencia haya transcurrido.
La comprobación falla pero el negocio debe continuar. ¿Qué haces?
Separa la visualización reversible de las acciones irreversibles. Una ruta de visualización puede utilizar la última instantánea de confianza con una etiqueta explícita de obsolescencia. Las decisiones de liquidación, autorización y riesgo deben poner en cuarentena los datos erróneos, pausar la acción afectada y preservar la entrada sin procesar. Reproduce, concilia y obtén la aceptación del consumidor antes de levantar la cuarentena.
¿Cómo evitas que un contrato se convierta en un documento abandonado?
Intégralo en la revisión de código, las puertas de CI, los metadatos del catálogo y el estado en tiempo de ejecución. Vincula cada contrato a un propietario, un contacto de respaldo, una lista de consumidores y la hora de la última validación. Revisa la tasa de infracciones, la ubicación de detección y el tiempo de recuperación, y retira las entradas que no tengan consumidores o no se puedan hacer cumplir.