Planteamiento y casos de uso
Que un conjunto de datos tenga valores no significa que esté fresco. La respuesta debe convertir una fecha límite de disponibilidad de negocio en indicadores medibles y ubicar el retraso en la ingesta, transporte, procesamiento o publicación.
Lo que evalúa el entrevistador
- Si se distinguen los tiempos de evento, llegada, finalización de procesamiento y disponibilidad para consultas.
- Si los conjuntos de datos, particiones y usos comerciales reciben los SLO adecuados.
- Si se conservan las evidencias de linaje, ejecución, calidad y frescura.
- Si se separa una tarea exitosa de los datos utilizables.
- Si existen rutas de supresión de alertas, escalamiento, backfill y reproducción.
- Si un incumplimiento de frescura se vincula con el impacto en el usuario downstream.
Aclaraciones antes de responder
- ¿Cuál es la fecha límite del negocio, la frecuencia de actualización y la zona horaria?
- ¿La frescura comienza con la creación del evento, la llegada de datos o la disponibilidad para consultas?
- ¿Qué particiones, campos e informes están en la ruta crítica?
- ¿Qué retraso, brecha y ventana de backfill son aceptables?
- ¿Puede el upstream proporcionar la hora del evento, el ID de lote y metadatos de reintento?
- Ante un incumplimiento, ¿deben congelarse los informes, mostrar una etiqueta de estado de datos o continuar?
Estructura de respuesta de 30 segundos
“Definiría la frescura consultable frente a la fecha límite comercial y registraría los tiempos de evento, llegada y servicio por separado. Para cada conjunto de datos crítico, calcularía un SLI de frescura a nivel de partición y combinaría linaje, estado de ejecución, recuentos de filas y aserciones de calidad para localizar el retraso. Las alertas separarían la advertencia del incumplimiento para que un trabajo exitoso no oculte una brecha. La recuperación utilizaría reintentos, backfill, reproducción y etiquetado downstream, guiando las mejoras según el impacto en el usuario y el presupuesto de SLO”.
Análisis detallado paso a paso
Paso 1: Definir la semántica del tiempo. Establecer el tiempo de evento frente al tiempo consultable y gestionar eventos tardíos, zonas horarias y horario de verano en lugar de basarse únicamente en la hora de finalización del trabajo.
Paso 2: Definir SLI y SLO. Por ejemplo, medir la fracción de particiones consultables antes de la fecha límite, con diferentes objetivos para informes críticos y datos exploratorios.
Paso 3: Recopilar evidencia de ejecución. Almacenar metadatos de ejecución, particiones de entrada y salida, linaje, recuentos de filas, comprobaciones de nulos y aserciones de calidad vinculadas a una versión del conjunto de datos.
Paso 4: Localizar el retraso. Dividir el retraso de extremo a extremo en ingesta, transporte, puesta en cola, cómputo y publicación; distinguir la ausencia en upstream de un fallo en downstream.
Paso 5: Diseñar alertas. Las advertencias utilizan el tiempo restante y la tendencia, mientras que los incumplimientos utilizan el impacto real. Desduplicar por conjunto de datos y partición, y asignar silenciamiento, escalamiento y propiedad.
Paso 6: Recuperar y reproducir. Utilizar lotes idempotentes, puntos de control y backfills acotados, luego volver a ejecutar las particiones afectadas y publicar el estado de los datos y la hora de actualización.
Paso 7: Mejorar el sistema. Monitorear el consumo de presupuesto, la proporción de causas raíz y las alertas falsas, y luego modificar la programación, capacidad, particionamiento o compromisos del producto.
Ejemplo de respuesta de alta calidad
“El informe de ingresos tiene una fecha límite de negocio local de las 08:00. Defino como fresco que la partición diaria sea consultable a las 08:15 y mido por separado el retraso de evento a llegada. El monitoreo lee particiones de entrada y salida, linaje, recuentos de filas y aserciones de calidad de los metadatos de ejecución; una ejecución exitosa con una partición faltante sigue siendo un riesgo de frescura. Antes de las 08:00 advertimos según el tiempo restante, y después de las 08:15 escalamos según el impacto en el informe. La recuperación realiza backfill de forma idempotente por ID de lote y etiqueta el estado del informe. Las revisiones desglosan el uso del presupuesto por causas de ingesta, transporte y cómputo”.
Errores comunes
- Monitorear solo el éxito del trabajo → las brechas de particiones quedan ocultas → verificar las particiones consultables y la fecha límite del negocio.
- Utilizar solo la hora de fin de procesamiento → los eventos tardíos se interpretan mal → conservar los tiempos de evento, llegada y servicio.
- Asignar un solo umbral a cada conjunto de datos → las prioridades desaparecen → clasificar por uso y ruta crítica.
- Alertar sin responsable o escalamiento → nadie actúa → vincular una ventana, un responsable y una acción de recuperación.
- Sobrescribir durante el backfill → los duplicados o versiones no quedan claros → registrar el lote idempotente, el rango y la versión.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Qué pasa si el upstream no tiene tiempo de evento?
Utilizar el tiempo de llegada como una métrica temporal y claramente delimitada, y solicitar al upstream que agregue el tiempo de evento y metadatos de lote.
Pregunta de seguimiento 2: ¿Qué pasa si los datos tardíos no tienen un impacto actual en el usuario?
Monitorear juntos el SLI técnico y el impacto en el usuario, y decidir el consumo de presupuesto frente al compromiso de negocio.
Pregunta de seguimiento 3: ¿Cómo se previenen las tormentas de alertas?
Agregar causas raíz a través del linaje y luego aplicar ventanas de advertencia, desduplicación, silenciamiento y escalamiento.
Pregunta de seguimiento 4: ¿Qué debe hacer el downstream durante el backfill?
Publicar el estado de los datos y la hora de actualización, congelar o etiquetar los informes críticos y evitar que los resultados incompletos se traten como definitivos.
Pregunta de seguimiento 5: ¿Cómo se valida que el SLO refleja las necesidades del negocio?
Entrevistar a los usuarios de los informes, comparar los incumplimientos con el retraso en las decisiones o el impacto en los clientes, y recalibrar la ventana periódicamente.
Pregunta de seguimiento 6: ¿Qué pasa si los datos tardíos modifican particiones históricas?
Definir una ventana de backfill y una semántica de versiones, registrar el rango de recálculo y notificar a los cachés downstream y modelos incrementales.
Pregunta de seguimiento 7: ¿Qué mejora es la más importante?
Solucionar la causa raíz que consume la mayor parte del presupuesto en las rutas críticas de los usuarios antes de añadir más paneles.