Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 3 de 5
Streaming tables y materialized views
Una materialized view almacena el resultado de una consulta batch declarativa y el servicio intenta actualizarla incrementalmente cuando cambian sus dependencias.
- Duración
- 17 min aprox.
- Objetivo
- Una materialized view almacena el resultado de una consulta batch declarativa y el servicio intenta actualizarla incrementalmente cuando cambian sus dependencias.
- Siguiente paso
- Continuar con la siguiente lección
Ver detalles del módulo
Spark Declarative Pipelines en Lakeflow
Declara datasets y dependencias para que Lakeflow gestione el grafo y la ejecución incremental sobre el framework actual de Spark.
- Crear tablas streaming y materialized views
- Comparar declarativo con Structured Streaming
- Distinguir Spark Declarative Pipelines de la oferta gestionada Lakeflow
03OperaciónStreaming tables y materialized views
Una materialized view almacena el resultado de una consulta batch declarativa y el servicio intenta actualizarla incrementalmente cuando cambian sus dependencias.
+
Streaming tables y materialized views
Una materialized view almacena el resultado de una consulta batch declarativa y el servicio intenta actualizarla incrementalmente cuando cambian sus dependencias.
A diferencia de una vista lógica, la salida se materializa para servir consultas rápidas. La definición suele usar `spark.read.table` porque describe el resultado completo correcto. El motor decide si puede aplicar cambios incrementales o si necesita recomputar según consulta y origen.
Es apropiada para joins, agregaciones y modelos gold donde el resultado puede cambiar por actualizaciones upstream. No promete que toda consulta sea siempre incremental; diseño de claves, filtros y operaciones influye en el plan de refresh y debe observarse en el event log.
Modelo mental
Una materialized view almacena el resultado de una consulta declarativa y lo actualiza cuando cambian sus dependencias. A diferencia de una vista lógica, no recalcula para cada lector; a diferencia de una streaming table, su consulta se formula sobre relaciones batch y describe el estado completo deseado. El motor intenta mantenerla incrementalmente cuando el plan y las fuentes lo permiten, pero el contrato no promete que todas las transformaciones eviten recomputación. Esto la hace adecuada para agregados, joins y productos gold cuya semántica es una instantánea consistente. El autor debe razonar sobre frescura del refresh, coste de actualización y capacidad de incrementalización. Una materialized view independiente creada desde SQL sigue usando un pipeline administrado por detrás, mientras un proyecto Lakeflow agrupa muchos objetos bajo una misma frontera operativa. Cambiar la definición puede alterar el plan y desencadenar refresh más amplio.
Resultado persistido de una consulta declarativa batch que el pipeline refresca para mantenerlo sincronizado con sus dependencias de datos.
Ofrece lecturas rápidas y consistentes para productos complejos sin recalcular toda la consulta por consumidor.Capacidad del motor para transformar cambios upstream en cambios equivalentes del resultado sin recomputar completamente la consulta declarada.
Determina coste y duración de refresh, pero depende del plan y no debe asumirse como garantía universal.Identidad derivada de la definición y plan que ayuda a detectar cuándo cambió la lógica mantenida por una vista materializada.
Permite explicar refresh completos y relacionar variaciones de coste con despliegues concretos del código.from pyspark import pipelines as dp
from pyspark.sql import functions as F
@dp.materialized_view(name="customer_order_metrics")
def customer_order_metrics():
orders = spark.read.table("orders_silver")
return (
orders.groupBy("customer_id")
.agg(
F.countDistinct("order_id").alias("orders"),
F.sum("amount").alias("lifetime_value"),
F.max("event_ts").alias("last_order_at"),
)
)Consulta el event log para confirmar si las actualizaciones concretas usan refresh incremental.
Puntos clave
- La definición expresa el resultado completo, aunque el refresh pueda ser incremental.
- Una materialized view almacena datos; una vista estándar recalcula al consultar.
- El event log permite verificar modo y coste del refresh en vez de asumirlo.
Evita
- Usar `readStream` por reflejo en una materialized view que describe un resultado completo cambiante.
- Prometer refresh incremental para cualquier UDF o consulta sin observar el plan real.
Recuerdo activo