Planteamiento y alcance
Esta es una pregunta común de diseño en plataformas de datos y analytics engineering. El objetivo es descomponer los "datos confiables" en dimensiones medibles y conectarlas con el uso de los consumidores y la remediación, en lugar de limitarse a enumerar unas cuantas validaciones.
Qué evalúa el entrevistador
- Si distingue entre frescura, completitud, validez, precisión, consistencia y unicidad.
- Si los objetivos reflejan cada producto de datos y consumidor en lugar de un único umbral global.
- Si la detección, las alertas basadas en severidad, el bloqueo downstream y la recuperación se diseñan de manera conjunta.
- Si la evidencia de calidad, las versiones y el linaje se conservan para que las alertas sigan siendo accionables.
Preguntas de clarificación iniciales
Confirme si la entrada es por lotes (batch) o streaming, tiempo de evento versus tiempo de llegada, las tablas o campos utilizados por clientes, finanzas o modelos, el retraso tolerado, las particiones tardías y zonas horarias, y si los consumidores deben bloquearse, degradarse o mostrar la última instantánea confiable durante un incidente.
Estructura de respuesta de 30 segundos
Definiría un contrato de datos según el uso del consumidor y luego configuraría comprobaciones de frescura, volumen, completitud y validez para cada conjunto de datos. El pipeline almacena los resultados de calidad y el linaje, enruta advertencias y fallas bloqueantes a los responsables, y permite que los trabajos downstream lean el estado de calidad. Ante una publicación bloqueada, los consumidores reciben una instantánea confiable con marca de tiempo; la recuperación utiliza backfill, recomputación y conciliación para cerrar el evento.
Respuesta a profundidad
1. Vincular las dimensiones de calidad con el uso
La frescura evalúa cuándo se produjeron los datos utilizables más recientes; la completitud verifica si llegaron los campos o particiones requeridos; el volumen comprueba las filas o bytes esperados; la validez revisa formatos y rangos; la consistencia examina relaciones entre tablas; la unicidad detecta duplicados. Los umbrales deben diferir para liquidaciones financieras, dashboards operativos y entrenamiento offline de modelos.
2. Definir SLAs y SLOs ejecutables
Registre una fecha límite de negocio, retraso máximo, tasa de faltantes tolerada, condición de bloqueo, responsable y tiempo de escalamiento para cada conjunto de datos. Rastree "los datos llegaron pero fallaron la validación" por separado de "el sistema upstream no produjo datos nuevos". Otorgue a los datos tardíos una ventana acotada de backfill; tras expirar, marque la partición como no disponible en lugar de esperar indefinidamente.
3. Almacenar evidencia versionada
Persista la versión de la regla, el lote o partición, el valor observado, el umbral, el tiempo de ejecución, el linaje de entrada y salida, y el resultado. Expectations u otro sistema declarativo pueden definir las validaciones, mientras que un registro de calidad consultable permite auditar las fallas. Evalúe un nuevo umbral frente a líneas base históricas para que un cambio de configuración no oculte una regresión.
4. Diseñar alertas, bloqueos y degradación
Enrute las alertas según el impacto y la severidad a los propietarios de los datos, a la guardia de la plataforma y a los consumidores del negocio. Una partición faltante recuperable puede marcarse como retrasada mientras una instantánea confiable permanece disponible; una falla que pudiera contaminar finanzas o un modelo debe bloquear la publicación. Cada bloqueo necesita condiciones de escalamiento, aprobación y liberación para que los consumidores no puedan simplemente eludirlo.
5. Cerrar el ciclo con backfill y conciliación
Tras corregir el sistema upstream, ejecute el backfill por partición o tiempo de negocio, vuelva a ejecutar las mismas transformaciones y versiones de reglas, y registre un lote de reparación para evitar escrituras duplicadas. Concilie filas de entrada, filas de salida, rechazos, registros tardíos y consumo downstream. Cierre el evento solo después de que las métricas vuelvan a la línea base, y luego ajuste las reglas, umbrales o asignación de responsabilidades en la revisión post-incidente.
Ejemplo de una respuesta sólida
Definiría el contrato según el consumidor. Una tabla de liquidación financiera debe llegar dentro de una hora posterior a su fecha límite diaria con un umbral de completitud obligatorio, mientras que un dashboard exploratorio puede tolerar más retraso. Cada conjunto de datos recibe comprobaciones de frescura, recuento de particiones, campos requeridos, rangos y validaciones cruzadas entre tablas; cada resultado almacena la versión de la regla, la observación, el lote, el linaje y el responsable. Un tiempo de espera de frescura genera primero una advertencia, pero una falla de completitud en datos financieros bloquea la publicación y entrega una instantánea confiable con marca de tiempo. Tras la corrección upstream, realizo un backfill por tiempo de negocio, reutilizo la misma transformación y comprobaciones, concilio entradas, salidas, rechazos y recuentos de consumidores, y cierro el evento solo cuando las métricas se recuperan.
Errores comunes
- Monitorear el éxito del trabajo sin verificar si los datos son frescos, completos y válidos.
- Aplicar un único umbral global a conjuntos de datos con diferentes consumidores y fechas límite.
- Escribir los resultados de calidad únicamente en logs, sin vínculo a lotes, versiones de reglas o linaje.
- Bloquear a todos los consumidores downstream por una falla limitada a un solo conjunto de datos o partición.
- Sobrescribir el historial durante la reparación sin un lote de backfill, conciliación o protección contra duplicados.
- Reportar un solo puntaje que no indica a los consumidores qué dimensión no está disponible.
Preguntas de seguimiento
¿Qué sucede si el trabajo upstream tiene éxito pero no llegan datos nuevos?
Verifique el tiempo de llegada y el tiempo de negocio por separado, luego compare la última partición confiable con la frecuencia de actualización esperada. Un trabajo exitoso demuestra ejecución, no cumplimiento del SLA; un tiempo de espera agotado debe generar un incidente de calidad.
¿Cómo maneja los falsos positivos en las reglas de calidad?
Conserve observaciones, umbrales y versiones de reglas; observe una línea base en modo sombra (shadow mode) antes de aplicarla. Utilice umbrales por niveles y tasas de anomalía, registre el impacto en el consumidor y revise los cambios en lugar de deshabilitar alertas silenciosamente.
¿Debería cada falla bloquear todos los sistemas downstream?
Delimite la respuesta según el linaje y el uso. Una falla que podría contaminar la liquidación financiera o un modelo puede bloquear la publicación relacionada, mientras que un conjunto de datos exploratorio independiente puede usar una versión previa con advertencia. Tanto el alcance como la condición de liberación deben ser auditables.
¿Cómo demuestra que la recuperación no perdió filas?
Concilie lotes, particiones, recuentos de entrada y salida, rechazos, registros tardíos y consumo downstream, y luego tome muestras de conjuntos de claves primarias. Los lotes de reparación deben ser reproducibles y rastreables, y la ejecución repetida debe producir el mismo resultado.