Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLecció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.
17 min aprox.
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.
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.
¿Por qué la definición de una materialized view puede usar una lectura batch y seguir actualizándose incrementalmente?
Profundiza
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.Resumen
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.