Saltar al contenido
Lakehouse LabLakehouse LabPreparación Databricks Data Engineer
Módulo 19 · Lección

Quarantine pattern y event log

Contenido abierto

Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.

Lección 5 de 5

Quarantine pattern y event log

La operación de calidad convierte métricas del event log en tasas, alertas sostenidas y decisiones de detener, degradar o remediar.

Duración
17 min aprox.
Objetivo
La operación de calidad convierte métricas del event log en tasas, alertas sostenidas y decisiones de detener, degradar o remediar.
Siguiente paso
Continuar con el laboratorio
Ver detalles del módulo

Expectations, cuarentena y event logs

Haz visibles las decisiones de calidad y separa observación, descarte, fallo y remediación.

Al terminar podrás
  • Elegir EXPECT, DROP o FAIL
  • Diseñar una cuarentena trazable
  • Consultar métricas en event logs
Ver fuentes y revisión

Metadatos editoriales

Última revisión
21 jul 2026
Nivel
Professional
Ruta relacionada
pipelines
Dominios blueprint
Data Transformation, Cleansing, and Quality · Monitoring
Estado
Revisión editorial interna
Fuentes principales
Manage data quality with pipeline expectations · Databricks · Pipeline event log schema · Databricks
Reportar un error
05
Decisión de diseño

Quarantine pattern y event log

La operación de calidad convierte métricas del event log en tasas, alertas sostenidas y decisiones de detener, degradar o remediar.

Mostrar prerrequisitos
Dificultad
Professional
Prerrequisitos
m18
Reportar un error en esta lección

Un conteo absoluto de inválidos confunde crecimiento de volumen con degradación. La tasa `failed / (passed + failed)` por expectation, flow y ventana permite comparar. Para reglas críticas, una sola violación puede fallar; para calidad gradual, un umbral sostenido durante varias actualizaciones evita ruido.

La alerta incluye filas de muestra seguras, enlace al update y owner. Si la tasa aumenta después de un despliegue, se decide rollback; si procede de un productor concreto, se aísla por `source_system`. La remediación se verifica con el mismo indicador hasta cerrar el incidente.

Modelo mental

Operar calidad significa convertir eventos y reglas en decisiones sostenidas. Los contadores de una expectation se transforman en tasas usando passed más failed como denominador, se agregan por update y se comparan con baselines y SLO. Una sola fila inválida puede ser crítica si afecta identidad; millones pueden ser tolerables si pertenecen a un campo opcional durante una migración acordada. Por eso alertas combinan severidad, proporción, volumen absoluto, duración y segmento. El event log muestra qué ocurrió dentro del pipeline; una tabla de calidad estable conserva tendencias, owners y estado de incidente. El ciclo completo incluye detectar, contener, diagnosticar, remediar, reingresar y prevenir recurrencia. Cambiar una expectation de drop a warn para hacer verde un Job no resuelve el problema: consume o redefine un riesgo y requiere aprobación del contrato.

Tasa de violación

Proporción de registros fallidos respecto al total evaluado para una regla, update y población comparables claramente identificados.

Normaliza volúmenes, pero debe acompañarse de conteo absoluto y criticidad para valorar el impacto real.
Presupuesto de calidad

Cantidad acordada de incumplimiento tolerable durante una ventana antes de detener, degradar o escalar el producto.

Hace explícito el equilibrio entre disponibilidad y corrección y evita decisiones improvisadas durante incidentes.
Modo degradado

Estado operativo definido que mantiene parte del servicio mientras etiqueta, limita o retrasa resultados afectados por una anomalía conocida.

Puede preservar utilidad sin presentar datos incompletos como normales, siempre que consumidores comprendan la señal.
SQLTasa de violación por regla
SELECT
  window_start,
  flow_name,
  expectation_name,
  failed_records,
  passed_records,
  failed_records / NULLIF(failed_records + passed_records, 0) AS failure_rate
FROM main.ops.pipeline_expectation_metrics
WHERE window_start >= current_timestamp() - INTERVAL 24 HOURS
ORDER BY failure_rate DESC;

Define el umbral y la duración mínima de incumplimiento en el runbook, no dentro de una consulta ad hoc.

Puntos clave

  • Normaliza por volumen y conserva numerador/denominador.
  • Segmenta por fuente o versión para localizar el origen de una regresión.
  • Una alerta se cierra cuando el indicador y los datos reparados vuelven al objetivo.

Evita

  • Alertar solo por conteo y generar falsos positivos cuando el volumen crece.
  • Mostrar payload con PII en la notificación en vez de enlazar a una vista restringida.

Recuerdo activo

¿Por qué es mejor alertar por tasa que solo por número de fallos?

Borrador privado · solo en este navegador
5 lecciones pendientes

Fuente revisada · vista externa

Lakeflow Declarative Pipelines examples

Lakeflow Declarative Pipelines examples · commit 1d8b163

python/Retail Sales.py

Lectura en GitHub

Este notebook se abre desde su fuente revisada

El repositorio no permite republicar su contenido dentro de Lakehouse Lab. Conservamos la misma experiencia lateral, la ruta exacta y el commit auditado, y dejamos la lectura en GitHub para respetar la autoría.

Autor
Databricks
Licencia
No verificada
Formato
repository
Ver notebook en GitHub