Entrevista de Ingeniería de Datos: ¿Cómo diseñarías una canalización auditable de cuarentena para la calidad de los datos?

Problema y Contexto

Un sistema upstream envía 200 millones de eventos de pedidos al día, y alrededor del 0.2% puede tener campos obligatorios faltantes, fallas de parseo o infracciones de reglas de negocio. Los eventos válidos deben continuar hacia las tablas de hechos y las métricas downstream. Los eventos no válidos no pueden desaparecer silenciosamente; tras su reparación deben poder reproducirse a partir de la entrada original sin contar el mismo evento dos veces.

Asuma un diseño por lotes y en streaming con un event_id estable por entrada, una copia sin procesar inmutable, reglas versionadas por esquema y registros de cuarentena que conserven los motivos de falla, las versiones de las reglas y el estado de reintento. El problema de la entrevista se centra en el enrutamiento, la observabilidad y la recuperación en ingeniería de datos, más que en una sola opción de Spark.

Qué Evalúa el Entrevistador

Separar las fallas de parseo, los campos faltantes y las fallas de validación de negocio en clases procesables.
Conservar la evidencia sin procesar, las versiones de las reglas y el linaje para auditoría y reproducción.
Elegir entre fail-fast, drop y redirect/quarantine según el radio de impacto.
Utilizar claves de idempotencia, estado de deduplicación y versiones de salida para evitar el doble conteo.
Diseñar métricas de calidad, umbrales de alerta, flujos de trabajo de reparación y compuertas de reproducción.
Abordar datos tóxicos, PII, retención y control de acceso en el área de cuarentena.

Aclaraciones que Conviene Hacer Primero

¿Es el 0.2% un presupuesto de defectos aceptado, o cualquier incumplimiento debe bloquear la liberación? Esto determina si se usan compuertas por umbral o de tolerancia cero.
¿Pueden los eventos reintentarse, llegar desordenados o duplicarse? De ser así, event_id debe definir el límite de idempotencia.
¿Las fallas de reglas pueden repararse automáticamente, o se requiere aprobación humana? Esto modifica la cola de reproducción y los controles.
¿Pueden las métricas downstream tolerar demoras o correcciones? De no ser así, los datos reparados necesitan particiones de compensación e informes versionados.
¿Contiene la carga útil sin procesar datos personales? Eso cambia los requisitos de cifrado, enmascaramiento, acceso y eliminación.

Estructura de Respuesta en 30 Segundos

Divido la canalización en etapas: sin procesar inmutable, parseo, validación de reglas, válidos y cuarentena. Las fallas de parseo y de reglas producen un registro de cuarentena que contiene el event_id, versiones de esquema y de reglas, códigos de motivo y una referencia a los datos sin procesar; los eventos válidos ingresan a la tabla de hechos mediante una escritura idempotente. El área de cuarentena proporciona colas de reparación, aprobación y reproducción. La reproducción utiliza el mismo event_id y deduplica en el límite del destino. Monitoreo la tasa de validez, las proporciones de códigos de motivo, la antigüedad en cuarentena y el éxito de la reproducción, y luego elijo compuertas de alerta o de bloqueo según el SLO del negocio y la gravedad.

Análisis Detallado Paso a Paso

1. Conservar Primero la Evidencia Sin Procesar

Particione objetos inmutables o logs por lote, origen y hora de recepción, y almacene un checksum. Los trabajos de procesamiento anexan el estado en lugar de sobrescribir la carga útil sin procesar. Esto hace que las actualizaciones de reglas, las correcciones de analizadores sintácticos y las disputas con proveedores sean reproducibles a partir de entradas idénticas. Permisos separados para las capas de datos sin procesar y de cuarentena evitan que los usuarios de soporte editen los hechos directamente.

2. Clasificar las Fallas y Conservar los Motivos

Ejecute primero el parseo de bytes/formato, en segundo lugar las comprobaciones de tipos de esquema y campos obligatorios, y en tercer lugar las reglas de negocio entre campos. Almacene valores estructurados de reason_code como MALFORMED_JSON, MISSING_ORDER_ID o INVALID_CURRENCY. Un registro puede tener múltiples motivos, pero conserve la primera etapa fallida y la versión de la regla para que las reparaciones posteriores sigan siendo explicables.

text

quarantine_record = {
  event_id, source_batch, raw_uri, payload_hash,
  schema_version, rule_version, failed_stage,
  reason_codes, first_seen_at, status
}

Las opciones de archivo de Spark pueden registrar archivos defectuosos o ignorar archivos corruptos, pero continuar con el trabajo no es lo mismo que preservar de forma segura los registros de negocio. El diseño debe enrutar explícitamente los registros recuperables a cuarentena en lugar de simplemente activar un interruptor de ignorar.

3. Elegir Fallar (Fail), Descartar (Drop) o Cuarentena (Quarantine)

Una entrada de infraestructura ilegible, firmas no confiables o corrupción que pudiera contaminar un lote entero deben hacer fallar el lote y conservar una alerta. Un error de un solo registro que se pueda aislar sin afectar a otros eventos debe ponerse en cuarentena para que los datos válidos continúen. Descartar es aceptable solo cuando el registro es irrecuperable, el propietario del negocio acepta la pérdida y se requiere un registro de auditoría; cada descarte debe seguir siendo cuantificable y rastreable.

4. Definir la Escritura Válida Idempotente

Utilice event_id junto con la versión de origen como clave única y escriba en la tabla de hechos mediante un upsert idempotente o un commit log. Antes de reproducir la cuarentena, verifique si el destino ya aceptó el evento y luego elija omitir, actualizar o una versión de compensación. Para hechos corregibles como el monto del pedido, no sobrescriba el historial silenciosamente; emita un evento de corrección y permita que los informes downstream recalculen por versión o tiempo efectivo.

5. Reparar, Aprobar y Reproducir

Las herramientas de reparación crean una nueva carga útil o parche y nunca modifican la capa de datos sin procesar. Registre el operador, el motivo, el hash de entrada y la versión de la regla, y luego dirija el cambio a través de la aprobación. Un worker de reproducción lee el estado de cuarentena y vuelve a ejecutar la cadena de validación completa. Si tiene éxito, mueve atómicamente QUARANTINED a REPLAYED; si falla, incrementa los intentos y programa la próxima ejecución. Los leases o bloqueos de base de datos evitan que dos workers apliquen el mismo evento concurrentemente.

6. Métricas de Calidad y Compuertas de Liberación

Monitoree la ingesta total, la tasa de validez, la proporción de cada reason_code, los percentiles de antigüedad en cuarentena, el éxito de la reproducción, los eventos duplicados y las correcciones downstream. Aplique compuertas por gravedad: una falla de firma puede ser de tolerancia cero, mientras que un campo opcional faltante solo genera una alerta. Incluso el 0.2% debe compararse con las líneas base históricas, la combinación de orígenes y las pérdidas de negocio en lugar de declararse normal. Cuando una compuerta se activa, congele la publicación downstream o revierta a la versión de regla anterior y registre cualquier liberación manual.

7. Retención, Privacidad y Recuperación

Conserve solo los campos mínimos sin procesar necesarios para la reparación, cifre las cargas útiles sensibles y restrinja el acceso. Las solicitudes de retención y eliminación deben mapear desde event_id hacia objetos sin procesar, filas en cuarentena e índices derivados. Realice respaldos de colas, tablas de metadatos y almacenamiento de objetos por separado. Si la escritura en el destino tiene éxito pero la actualización de estado falla, reintente mediante la clave única; si la reproducción está marcada pero la escritura es incierta, recupere a partir de un commit log o una comprobación de la tabla de destino en lugar de inferir el éxito a partir de la respuesta del worker.

Respuesta Modelo de Alta Calidad

Primero confirmaría el presupuesto aceptable de defectos, la entrega duplicada o tardía, y si las correcciones de pedidos pueden esperar a los reportes. La canalización mantiene una capa inmutable sin procesar y luego ejecuta el parseo, el esquema y las reglas de negocio por etapas. Los errores recuperables a nivel de registro van a cuarentena; las fallas de infraestructura o de seguridad bloquean el lote. Una fila en cuarentena almacena la clave de idempotencia, la referencia a los datos sin procesar, la versión de la regla, el código de motivo y el estado. Los eventos válidos se escriben de forma idempotente en la tabla de hechos. La reparación crea una nueva carga útil y requiere aprobación; la reproducción vuelve a ejecutar la cadena de validación completa y marca atómicamente el éxito. Las métricas cubren la tasa de validez, motivos, antigüedad en cuarentena, tasa de reproducción y efectos de duplicados, con compuertas basadas en la gravedad. Esto evita que una pequeña porción defectuosa bloquee el lote sin ocultar anomalías como datos saludables.

Errores Comunes

Habilitar ignoreCorruptFiles y declarar éxito → el trabajo continúa pero los registros pueden desaparecer → enrute los registros recuperables a una cuarentena con códigos de motivo.
Almacenar fallas en una tabla editable → la evidencia sin procesar puede alterarse → mantenga los datos sin procesar inmutables y cree nuevas versiones de reparación.
Reinsertar eventos reproducidos directamente → las métricas downstream cuentan doble → utilice un límite de unicidad mediante event_id y un commit log.
Bloquear todo el lote por cada error → una pequeña porción defectuosa destruye la frescura → elija fallar (fail) o poner en cuarentena (quarantine) según la etapa y la gravedad.
Contar solo el total de fallas → las regresiones de orígenes y reglas quedan ocultas → desglose las métricas por motivo, versión de esquema, origen y tiempo.
Omitir la validación después de la reparación → el parche puede introducir un segundo defecto → la reproducción debe ejecutar la cadena de validación completa.

Preguntas de Seguimiento y Respuestas

La tasa de cuarentena salta del 0.2% al 8%. ¿Continúa publicando?

Primero divida por motivo y origen. Si un proveedor tiene un campo faltante recuperable, pause ese origen y continúe con los demás. Si falla el parseo o la validación de firmas, congele la publicación downstream y revierta la versión de la regla. Los umbrales deben reflejar las pérdidas del negocio y las líneas base históricas, no solo el porcentaje absoluto.

¿Cómo evita que la reproducción modifique un pedido ya liquidado?

Separe los eventos originales y los de corrección, y conserve columnas de versión o tiempo efectivo en la tabla de hechos. Una instantánea de liquidación fija su generación de entrada. Un evento reparado pasa por un flujo de trabajo de compensación donde las reglas financieras deciden si se crea un ajuste en lugar de sobrescribir silenciosamente el monto liquidado.

El área de cuarentena contiene PII. ¿Cómo puede investigar el equipo de soporte?

Muestre campos enmascarados y códigos de motivo de forma predeterminada. Otorgue acceso autorizado de corta duración a la carga útil sin procesar y registre cada evento de auditoría. Las solicitudes de eliminación siguen event_id a través de objetos sin procesar, filas en cuarentena e índices derivados, conservando después solo un resumen (digest) de auditoría irreversible.

Un worker falla tras escribir en el destino pero antes de cambiar el estado de cuarentena. ¿Qué sucede?

Al reintentar, compruebe la tabla de destino y el commit log mediante la clave de idempotencia. Si está presente, repare solo el estado; no repita el efecto secundario. Si no está presente, envíe de nuevo. Utilice transiciones de estado condicionales y reintentables para que nunca se asuma un resultado desconocido como éxito o falla.

¿Cuándo se debe descartar un registro en lugar de conservarlo?

Solo cuando sea irrecuperable, ninguna regla de cumplimiento requiera su retención y el propietario del negocio acepte explícitamente la pérdida. Incluso entonces, conserve un conteo auditable, motivo, lote y versión de política, y exponga el descarte en los informes de calidad.