Data Quality con Expectations

1. ¿Qué son las Expectations?

Una Expectation es una regla de calidad de datos que declaras directamente en un dataset de Lakeflow.

Por ejemplo:

@dp.expect("valid_amount", "amount > 0")

Esta regla comprueba que todos los tickets tengan un importe positivo.

Lo interesante es que Lakeflow permite decidir qué hacer cuando un registro incumple la regla, además de medir cuántos registros pasan o fallan. Databricks on AWS

2. Los tres comportamientos: warn, drop y fail

3. Simulador: ¿qué sucede con nuestros tickets?

Imagina que recibimos estos cuatro tickets desde Kafka.

Importante: fail no significa necesariamente que todos los flows independientes del pipeline se detengan. En modo Triggered puede fallar únicamente el flow afectado; en Continuous también se detienen sus dependientes. Databricks on AWS

4. El código real en Lakeflow

Volvemos a nuestra tabla Silver de tickets, que creamos en la lección anterior.

from pyspark import pipelines as dp
from pyspark.sql import functions as F

@dp.table(name="silver_tickets")
@dp.expect("valid_ticket_id", "ticket_id IS NOT NULL")
@dp.expect_or_drop("valid_amount", "amount > 0")
def silver_tickets():
    return (
        spark.readStream.table("bronze_deserialized_tickets")
        .select(
            "ticket_id",
            "pharmacy_id",
            "amount",
            "kafka_timestamp"
        )
    )

En este ejemplo asumimos que bronze_deserialized_tickets contiene los datos ya deserializados de Avro. Así nos concentramos exclusivamente en las reglas de calidad.

Tenemos dos expectativas distintas:

• valid_ticket_id: registra si falta un identificador, pero conserva ese ticket.

• valid_amount: descarta tickets cuyo importe sea cero, negativo o nulo.

Un detalle fundamental: si un ticket incumple ambas reglas, se descarta por valid_amount aunque valid_ticket_id tenga política warn.

Si quisiéramos que un identificador nulo detuviera la actualización, sustituiríamos @dp.expect por @dp.expect_or_fail.

5. ¿Dónde veo las métricas de calidad?

Lakeflow registra métricas como:

Las dos primeras corresponden a una expectativa concreta. dropped_records contabiliza los registros descartados por las expectativas del flow, evitando contar dos veces una misma fila que incumple varias reglas. Databricks on AWS

Puedes consultar las métricas de dos maneras:

Opción A. Interfaz de Databricks

Entra en Jobs & Pipelines → tu pipeline → selecciona Silver → Data quality. Verás los resultados de las expectativas cuando las métricas estén disponibles.

Opción B. Consultar el Event Log con SQL

SELECT
    timestamp,
    origin.flow_name,
    from_json(
        details:flow_progress.data_quality
            :expectations::STRING,
        'ARRAY<STRUCT<
            name: STRING,
            dataset: STRING,
            passed_records: BIGINT,
            failed_records: BIGINT
        >>'
    ) AS expectations
FROM event_log('<pipeline-id>')
WHERE event_type = 'flow_progress'
ORDER BY timestamp DESC
LIMIT 20;

Sustituye <pipeline-id> por el identificador real. La disponibilidad de métricas depende del tipo de flow, de que haya registros procesados y de la configuración de métricas. Las violaciones con política fail no generan las métricas habituales del lote fallido.

Databricks on AWS+1

6. ¿Qué haría en vuestra Data Platform?

En una arquitectura Bronze → Silver → Gold, propondría esta distribución inicial:

Atención: son ejemplos de políticas, no reglas de negocio confirmadas. Especialmente para los tickets, debemos averiguar cómo se representan las devoluciones y cancelaciones antes de descartar importes negativos.

Una estrategia más robusta es implementar una tabla de cuarentena que guarde los registros inválidos y el motivo del rechazo, en lugar de perderlos definitivamente. Databricks documenta este patrón. Databricks on AWS

7. Mini ejercicio

Qué debes recordar: Expectations no son simples filtros. Son reglas declarativas con comportamiento configurable y métricas de calidad integradas en Lakeflow.

En la lección 8 abordaremos uno de los temas más interesantes: cómo mantener una tabla Silver actualizada cuando un cliente cambia sus datos, utilizando AUTO CDC, SCD Type 1 y SCD Type 2.