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

Dimensiones y contratos de calidad

Contenido abierto

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

Lección 1 de 5

Dimensiones y contratos de calidad

Las expectations convierten reglas de calidad en métricas y acciones declarativas: observar, descartar o fallar la actualización.

Duración
17 min aprox.
Objetivo
Las expectations convierten reglas de calidad en métricas y acciones declarativas: observar, descartar o fallar la actualización.
Siguiente paso
Continuar con la siguiente lección
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
01
Modelo mental

Dimensiones y contratos de calidad

Las expectations convierten reglas de calidad en métricas y acciones declarativas: observar, descartar o fallar la actualización.

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

`expect` conserva tanto filas válidas como inválidas y registra métricas; es útil durante adopción o para reglas informativas. `expect_or_drop` elimina las filas que incumplen y permite continuar. `expect_or_fail` detiene el flow y revierte atómicamente la actualización afectada cuando aceptar datos incorrectos sería peor que retrasar publicación.

La acción se elige por impacto y capacidad de remediación, no por severidad nominal. Un `order_id` nulo puede ir a cuarentena si el resto del pipeline debe continuar; una violación de unicidad en un saldo regulado puede justificar fallo. Toda regla necesita owner, definición y umbral operativo.

Modelo mental

Una expectation es una regla booleana aplicada a cada fila que combina observación con una política de respuesta. La misma expresión puede conservar filas y registrar métricas, descartar las inválidas o fallar la actualización. La elección no expresa severidad estética, sino el daño de publicar el dato y la capacidad de remediarlo. `warn` —comportamiento de retención— sirve para medir y explorar; `drop` evita contaminar el target cuando perder esas filas está aceptado y existe trazabilidad; `fail` protege invariantes cuya violación invalida todo el resultado. En una actualización fallida, la transacción del flow se revierte, pero el alcance sobre flows paralelos y dependientes varía según el modo del pipeline. Además, las métricas de `fail` tienen limitaciones porque el update no se confirma como una ejecución normal. La regla necesita nombre estable, owner, umbral y ruta de investigación.

Expectation

Restricción nombrada basada en una expresión booleana que evalúa calidad durante el procesamiento y registra o aplica una acción configurada.

Integra controles de calidad con métricas y transacciones del pipeline en lugar de depender de comprobaciones posteriores aisladas.
Retain, drop, fail

Tres políticas que respectivamente conservan y miden, excluyen filas inválidas, o abortan la actualización al detectar una violación.

Permiten alinear cada regla con impacto, remediación y disponibilidad, evitando usar una única respuesta para toda anomalía.
Lógica de tres valores

Semántica SQL donde una expresión con null puede resultar unknown en vez de verdadero o falso explícito.

Obliga a formular constraints de nulabilidad cuidadosamente para no clasificar datos de forma distinta a la intención.
PySparkTres acciones de calidad diferenciadas
from pyspark import pipelines as dp

@dp.table(name="orders_silver")
@dp.expect("known_currency", "currency IN ('EUR', 'USD', 'GBP')")
@dp.expect_or_drop("valid_order_id", "order_id IS NOT NULL")
@dp.expect_or_fail("non_negative_amount", "amount >= 0")
def orders_silver():
    return spark.readStream.table("orders_bronze")

Aplicar tres acciones al mismo dataset solo es correcto si negocio ha decidido explícitamente el tratamiento de cada violación.

Puntos clave

  • `expect` mide sin eliminar; `expect_or_drop` continúa sin la fila; `expect_or_fail` aborta el flow afectado.
  • Los nombres de expectation deben ser estables y describir el contrato.
  • Fallar una actualización protege el target, pero puede consumir el presupuesto de frescura.

Evita

  • Usar `expect_or_fail` para toda anomalía y convertir una fila reparable en una caída completa del flow.
  • Usar `expect` para una clave obligatoria y permitir que inválidos lleguen silenciosamente a consumidores.

Recuerdo activo

¿Qué acción conserva filas inválidas pero produce métricas?

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