Saltar al contenido

Calidad

Menú

Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.

Guardar progreso

Lección 5 de 5

Quarantine pattern y event log

La operación combina enforcement en el pipeline con Data Quality Monitoring para observar frescura, completitud, distribución y drift en activos de Unity Catalog.

17 min aprox.

Detalles

Expectations, cuarentena y event logs

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

Reto observable

Implementa reglas con acciones de observar, aislar y fallar, y demuestra tasas, cuarentena trazable y remediación mediante el event log.

Al terminar podrás
  • Elegir EXPECT, DROP o FAIL
  • Diseñar una cuarentena trazable
  • Consultar métricas en event logs
Prerrequisitos
m18
Última revisión
25 ago 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 combina enforcement en el pipeline con Data Quality Monitoring para observar frescura, completitud, distribución y drift en activos de Unity Catalog.

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. Expectations observan, descartan o fallan registros dentro del pipeline: son enforcement vinculado al código y al update.

Data Quality Monitoring complementa ese contrato sin modificar las tablas monitorizadas ni añadir trabajo al job productor: anomaly detection aprende patrones históricos para freshness y completeness, y data profiling calcula estadísticas y drift. Se ejecuta en serverless con coste propio. Úsalo para descubrir degradaciones transversales; conserva expectations o reconciliaciones cuando una regla debe bloquear o aislar datos.

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.

¿Qué diferencia operacional separa Data Quality Monitoring de una expectation crítica?

Profundiza

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.
Resumen

Puntos clave

  • Expectations aplican acciones; Data Quality Monitoring observa activos.
  • Anomaly detection cubre frescura/completitud; profiling, estadísticas y drift.
  • Cada alerta conserva owner, coste, contexto y criterio de cierre.

Evita

  • Sustituir una regla crítica de enforcement por una anomalía observacional que no bloquea publicación.
  • Activar profiling masivo sin owner, coste serverless o control de acceso a sus tablas métricas.

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 ↗

Módulo 19

Contenido del módulo