Incremental Refresh y gestión del estado

Objetivo: entender cómo Lakeflow actualiza datos sin recalcularlo todo, cuándo necesita hacerlo y cómo afecta a los costes.

1. Dos formas diferentes de procesar incrementalmente

Imagina que tenemos 10 millones de tickets en Bronze y llegan 1.000 tickets nuevos.

La diferencia fundamental:

• Streaming Table: procesa incrementalmente las entradas pendientes.

• Materialized View: mantiene actualizado el resultado de una consulta, utilizando incremental refresh cuando es posible.

Databricks on Google Cloud+1

2. Código: una Materialized View incremental

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

@dp.materialized_view(name="gold_sales")
def gold_sales():
    return (
        spark.read.table("silver_tickets")
        .groupBy("pharmacy_id")
        .agg(
            F.sum("amount").alias("total_sales")
        )
    )

Fíjate en algo sorprendente: no hay ninguna instrucción explícita para hacer incremental refresh.

Lakeflow analiza la consulta, los cambios en las fuentes y su coste estimado para decidir cómo refrescar el resultado.

Pero hay una condición importante: el refresco incremental de Materialized Views requiere Serverless. En compute clásico, estas vistas se recalculan completamente. Databricks on Google Cloud

3. Simulador: incremental vs full recompute

4. ¿Cuándo hace Lakeflow un Full Recompute?

Aunque utilices una Materialized View, Lakeflow puede recalcularlo todo si:

• La consulta contiene operaciones que no admiten procesamiento incremental.

• Los cambios en la fuente impiden un refresco incremental seguro.

• El optimizador estima que recalcular resulta más eficiente.

• Ejecutas explícitamente un Full Refresh.

En general, consultas deterministas y agregaciones sencillas favorecen el procesamiento incremental. Databricks on Google Cloud

Por eso no basta con declarar una Materialized View: hay que comprobar cómo se está actualizando realmente.

5. ¿Cómo saber si tu MV se actualiza incrementalmente?

En Databricks, abre tu pipeline y consulta la columna Incrementalization de la tabla correspondiente.

Puede mostrar:

También puedes inspeccionar el Event Log:

SELECT
    timestamp,
    message
FROM event_log(
    TABLE(dev_catalog.demo_lakeflow.gold_sales)
)
WHERE event_type = 'planning_information'
ORDER BY timestamp DESC;

Verás técnicas como GROUP_AGGREGATE, ROW_BASED o FULL_RECOMPUTE. Databricks on Google Cloud

6. ¿Qué pasa si cambiamos el código?

Este punto es especialmente importante en producción.

Supongamos que Silver es una Streaming Table y cambiamos:

.filter("amount > 0")

por:

.filter("amount >= 0")

¿Se reprocesan automáticamente los 10 millones de tickets anteriores?

No. Una actualización normal de una Streaming Table procesa los nuevos registros. Los anteriores ya están escritos.

En cambio, una Materialized View debe mantener el resultado conforme a su definición actual, por lo que puede necesitar recalcular todos los datos.

Precaución: nunca hagas un Full Refresh de una Bronze conectada directamente a Kafka sin comprobar antes la retención. Si Kafka ya eliminó eventos antiguos, no podrás reconstruirlos desde allí.

Databricks on Google Cloud+1

7. Mini ejercicio

Qué debes recordar:

• Streaming Tables usan checkpoints para continuar el procesamiento.

• Materialized Views pueden actualizar resultados de forma incremental.

• Incremental refresh de MVs requiere Serverless.

• Full Refresh no es una operación inocua, especialmente cuando hay fuentes con retención limitada.

En la lección 12 aprenderemos a recuperarnos de fallos reales sin duplicar eventos ni perder información.