¿Qué es Lakeflow Declarative Pipelines?

1. El problema que resuelve

Imagina tu arquitectura actual:

Kafka / Event Hubs

Eventos de tickets

Bronze · Raw events

Silver · Analytical tickets

Gold · KPIs

Con Spark tradicional normalmente tienes que ocuparte de:

Leer los datos y escribir las tablas.
Gestionar las dependencias entre procesos.
Configurar checkpoints para streaming.
Coordinar ejecuciones y recuperaciones.

Lakeflow permite declarar qué tablas quieres obtener y cómo calcularlas. El framework gestiona buena parte de la ejecución, las dependencias y el procesamiento incremental.

2. Imperativo vs declarativo

Enfoque imperativo (Spark tradicional)

python

df = spark.read.table("bronze.tickets")

df_clean = df.filter("amount > 0")

df_clean.write \
    .mode("overwrite") \
    .saveAsTable("silver.tickets")

Aquí le dices a Spark qué acciones debe ejecutar.

Enfoque declarativo (Lakeflow)

python

from pyspark import pipelines as dp

@dp.materialized_view(
    name="silver_tickets"
)
def silver_tickets():
    return (
        spark.read.table("bronze.tickets")
        .filter("amount > 0")
    )

Aquí defines el resultado deseado.

Lakeflow se encarga de materializar y actualizar ese resultado conforme a la configuración del pipeline.

Fíjate en algo importante: no hay ningún .write, .saveAsTable ni .mode("overwrite").

Además, el framework puede determinar que esta tabla depende de bronze.tickets.

3. Los tres conceptos que debes conocer hoy

Pipeline

Conjunto de definiciones de tablas, transformaciones y configuración que Lakeflow ejecuta como unidad.

Streaming Table

Pensada para procesar incrementalmente nuevos registros, por ejemplo eventos que llegan desde Kafka.

Materialized View

Guarda el resultado de una consulta y lo actualiza al refrescarse. Puede utilizar procesamiento incremental cuando es posible o recalcular los resultados si es necesario.

4. Algo importante: Lakeflow no es magia

El hecho de declarar una tabla no significa que todo funcione automáticamente de forma incremental.

Por ejemplo, una Streaming Table que procesa eventos nuevos tiene una semántica diferente de una Materialized View que calcula un agregado sobre datos que pueden cambiar.

Elegir correctamente entre ambas es una de las decisiones arquitectónicas más importantes.

Y un detalle de sintaxis: actualmente Databricks recomienda from pyspark import pipelines as dp en lugar del antiguo import dlt.

Databricks on AWS+1

5. Comprueba si lo has entendido

Tienes una tabla Bronze con tickets. Quieres crear una tabla Silver que contenga únicamente los tickets con amount > 0.

¿Qué tendrías que hacer con Lakeflow?

A. Crear un job que ejecute manualmente un .write cada hora.

B. Declarar una tabla con una función que devuelva el DataFrame filtrado.C. Crear obligatoriamente un proceso Kafka para mover los datos.

¡Correcto!

Defines la transformación y Lakeflow gestiona la materialización y su ejecución.

Documentación oficial: Apache Spark Declarative Pipelines .

En la próxima lección veremos una diferencia fundamental: qué ocurre cuando entra un ticket nuevo, cuando se modifica uno existente y cuando se refresca una Materialized View. Es la base para diseñar correctamente Bronze, Silver y Gold.

Material importado del curso original. Simulaciones conservadas como ejemplos estáticos; para sus controles interactivos, consulta el original.