Usar vistas materializadas

En este documento se proporciona información adicional sobre las vistas materializadas y cómo usarlas. Antes de leer este documento, familiarícese con los artículos Introducción a las vistas materializadas y Crear vistas materializadas.

Consultar vistas materializadas

Puedes consultar tus vistas materializadas directamente, de la misma forma que consultas una tabla normal o una vista estándar. Las consultas en vistas materializadas siempre son coherentes con las consultas en las tablas base de la vista, aunque esas tablas hayan cambiado desde la última vez que se actualizó la vista materializada. Las consultas no activan automáticamente una actualización materializada.

Roles obligatorios

Para obtener los permisos que necesitas para consultar una vista materializada, pide a tu administrador que te conceda el rol de gestión de identidades y accesos Lector de datos de BigQuery (roles/bigquery.dataViewer) en la tabla base de la vista materializada y en la propia vista materializada. Para obtener más información sobre cómo conceder roles, consulta el artículo Gestionar el acceso a proyectos, carpetas y organizaciones.

Este rol predefinido contiene los permisos necesarios para consultar una vista materializada. Para ver los permisos exactos que se necesitan, despliega la sección Permisos necesarios:

Permisos obligatorios

Para consultar una vista materializada, se necesitan los siguientes permisos:

  • bigquery.tables.get
  • bigquery.tables.getData

También puedes obtener estos permisos con roles personalizados u otros roles predefinidos.

Estos permisos son necesarios para las consultas si quieres beneficiarte de la configuración inteligente.

Para obtener más información sobre los roles de gestión de identidades y accesos en BigQuery, consulta la introducción a la gestión de identidades y accesos.

Actualizaciones incrementales

Las actualizaciones incrementales se producen cuando BigQuery combina los datos de la vista almacenada en caché con los datos nuevos para proporcionar resultados de consulta coherentes y, al mismo tiempo, usar la vista materializada. En el caso de las vistas materializadas de una sola tabla, esto es posible si la tabla base no ha cambiado desde la última actualización o si solo se han añadido datos nuevos. En las vistas JOIN, solo las tablas de la parte izquierda del JOIN pueden tener datos añadidos. Si ha cambiado una de las tablas de la parte derecha de un JOIN, la vista no se puede actualizar de forma incremental.

Si la tabla base se ha actualizado o se han eliminado datos desde la última actualización, o si las tablas base de la vista materializada situadas a la derecha de JOIN han cambiado, BigQuery no usará actualizaciones incrementales y, en su lugar, volverá automáticamente a la consulta original. Para obtener más información sobre las combinaciones y las vistas materializadas, consulta Combinaciones. A continuación, se muestran ejemplos de acciones de la consola, la herramienta de línea de comandos bq y la API que pueden provocar una actualización o una eliminación: Google Cloud

  • Declaraciones del lenguaje de manipulación de datos (DML) UPDATE, MERGE o DELETE
  • Truncamiento
  • Caducidad de la partición

Las siguientes operaciones de metadatos también impiden que una vista materializada se actualice de forma incremental:

  • Cambiar la caducidad de una partición
  • Actualizar o eliminar una columna

Si una vista materializada no se puede actualizar de forma incremental, las consultas no usarán sus datos almacenados en caché hasta que la vista se actualice automáticamente o manualmente. Para obtener más información sobre por qué no se han usado los datos de una vista materializada en un trabajo, consulta Por qué se han rechazado las vistas materializadas. Además, las vistas materializadas no se pueden actualizar de forma incremental si su tabla base ha acumulado cambios sin procesar durante un periodo superior al intervalo de viaje en el tiempo de la tabla.

Alineación de particiones

Si una vista materializada tiene particiones, BigQuery se asegura de que sus particiones estén alineadas con las de la columna de partición de la tabla base. Alineada significa que los datos de una partición concreta de la tabla base contribuyen a la misma partición de la vista materializada. Por ejemplo, una fila de la partición 20220101 de la tabla base solo contribuiría a la partición 20220101 de la vista materializada.

Cuando se particiona una vista materializada, el comportamiento descrito en Actualizaciones incrementales se produce en cada partición de forma independiente. Por ejemplo, si se eliminan datos de una partición de la tabla base, BigQuery puede seguir usando las otras particiones de la vista materializada sin necesidad de actualizarla por completo.

Las vistas materializadas con joins internos solo se pueden alinear con una de sus tablas base. Si cambia una de las tablas base no alineadas, se verá afectada toda la vista.

Ajuste inteligente

BigQuery reescribe automáticamente las consultas para usar vistas materializadas siempre que sea posible. La reescritura automática mejora el rendimiento de las consultas y reduce los costes sin cambiar los resultados de las consultas. Las consultas no activan automáticamente una actualización materializada. Para que una consulta se reescriba mediante el ajuste inteligente, la vista materializada debe cumplir las siguientes condiciones:

  • Pertenecer al mismo proyecto que una de sus tablas base o al proyecto en el que se ejecuta la consulta.
  • Usa el mismo conjunto de tablas base que la consulta.
  • Incluye todas las columnas que se están leyendo.
  • Incluye todas las filas que se están leyendo.

La optimización inteligente no está disponible en los siguientes casos:

Ejemplos de ajuste inteligente

Consulta el siguiente ejemplo de consulta de vista materializada:

SELECT
  store_id,
  CAST(sold_datetime AS DATE) AS sold_date
  SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
  CAST(sold_datetime AS DATE) >= '2021-01-01' AND
  promo_id IS NOT NULL
GROUP BY 1, 2

En los siguientes ejemplos se muestran consultas y se explica por qué se reescriben o no automáticamente con esta vista:

Consulta ¿Reescribir? Motivo
SELECT
SUM(net_paid) AS sum_paid,
SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
CAST(sold_datetime AS DATE) >= '2021-01-01' AND
promo_id IS NOT NULL 		No La vista debe incluir todas las columnas que se lean. La vista no incluye "SUM(net_paid)".
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
CAST(sold_datetime AS DATE) >= '2021-01-01' AND
promo_id IS NOT NULL 		Sí
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
CAST(sold_datetime AS DATE) >= '2021-01-01' AND
promo_id IS NOT NULL AND
customer_id = 12345 		No La vista debe incluir todas las columnas que se lean. La vista no incluye "customer".
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
sold_datetime= '2021-01-01' AND
promo_id IS NOT NULL
 No La vista debe incluir todas las columnas que se lean. "sold_datetime" no es un resultado (pero "CAST(sold_datetime AS DATE)" sí lo es).
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
CAST(sold_datetime AS DATE) >= '2021-01-01' AND
promo_id IS NOT NULL AND
store_id = 12345		 Sí
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
CAST(sold_datetime AS DATE) >= '2021-01-01' AND
promo_id = 12345 		No La vista debe incluir todas las filas que se lean. "promo_id" no es un resultado, por lo que no se puede aplicar el filtro más restrictivo a la vista.
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE CAST(sold_datetime AS DATE) >= '2020-01-01'
 No La vista debe incluir todas las filas que se lean. El filtro de vista para fechas del 2021 y posteriores, pero la consulta lee fechas del 2020.
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
CAST(sold_datetime AS DATE) >= '2022-01-01' AND
promo_id IS NOT NULL 		Sí

Saber si se ha reescrito una consulta

Para saber si la optimización inteligente ha reescrito una consulta para usar una vista materializada, inspecciona el plan de consulta. Si la consulta se ha reescrito, el plan de consulta contiene un paso READ my_materialized_view, donde my_materialized_view es el nombre de la vista materializada utilizada. Para saber por qué una consulta no ha usado una vista materializada, consulta Por qué se han rechazado las vistas materializadas.

Por qué se han rechazado las vistas materializadas

Si has inhabilitado la actualización automática de tu vista materializada y la tabla tiene cambios sin procesar, la consulta puede ser más rápida durante varios días, pero después puede volver a la consulta original, lo que provoca una velocidad de procesamiento más lenta. Para aprovechar las ventajas de las vistas materializadas, habilita la actualización automática o actualízalas manualmente con regularidad y monitoriza los trabajos de actualización de las vistas materializadas para confirmar que se completan correctamente.

Los pasos para saber por qué se ha rechazado una vista materializada dependen del tipo de consulta que hayas usado:

  • Consulta directa de la vista materializada
  • Consulta indirecta en la que ajuste inteligente puede elegir usar la vista materializada

En las secciones siguientes se indican los pasos que debe seguir para saber por qué se ha rechazado una vista materializada.

Consulta directa de vistas materializadas

Es posible que las consultas directas de vistas materializadas no usen datos almacenados en caché en determinadas circunstancias. Sigue estos pasos para saber por qué no se han usado los datos de la vista materializada:

  1. Sigue los pasos que se indican en Monitorizar el uso de vistas materializadas y busca la vista materializada de destino en el campo materialized_view_statistics de la consulta.
  2. Si chosen está presente en las estadísticas y su valor es TRUE, la consulta usa la vista materializada.
  3. Consulta el campo rejected_reason para ver los pasos siguientes. En la mayoría de los casos, puede actualizar manualmente la vista materializada o esperar a la siguiente actualización automática.

Consultar con ajuste inteligente

  1. Sigue los pasos que se indican en Monitorizar el uso de vistas materializadas y busca la vista materializada de destino en el materialized_view_statistics de la consulta.
  2. Consulta la rejected_reason para ver los pasos siguientes. Por ejemplo, si el valor de rejected_reason es COST, significa que la optimización inteligente ha identificado fuentes de datos más eficientes para el coste y el rendimiento.
  3. Si la vista materializada no está presente, prueba a hacer una consulta directa de la vista materializada y sigue los pasos que se indican en Consulta directa de vistas materializadas.
  4. Si la consulta directa no usa la vista materializada, la forma de la vista materializada no coincide con la consulta. Para obtener más información sobre la optimización inteligente y cómo se reescriben las consultas mediante vistas materializadas, consulta los ejemplos de optimización inteligente.

Preguntas frecuentes

¿Cuándo debo usar consultas programadas en lugar de vistas materializadas?

Las consultas programadas son una forma cómoda de ejecutar cálculos arbitrariamente complejos de forma periódica. Cada vez que se ejecuta la consulta, se ejecuta por completo, sin aprovechar los resultados anteriores, y pagas el coste de computación completo de la consulta. Las consultas programadas son ideales cuando no necesitas los datos más recientes y tienes bastante margen para ver datos no actualizados.

Las vistas materializadas son más adecuadas cuando necesitas consultar los datos más recientes con una latencia y un coste mínimos reutilizando el resultado calculado anteriormente. Puedes usar las vistas materializadas como pseudoíndices, lo que acelera las consultas a la tabla base sin tener que actualizar ningún flujo de trabajo. La --max_stalenessopción te permite definir una obsolescencia aceptable para tus vistas materializadas, lo que te proporciona un rendimiento alto y constante con costes controlados al procesar conjuntos de datos grandes que cambian con frecuencia.

Como norma general, siempre que sea posible y no realices cálculos arbitrariamente complejos, utiliza vistas materializadas.

Algunas consultas en vistas materializadas son más lentas que las mismas consultas en tablas materializadas manualmente. ¿A qué se debe?

Por lo general, una consulta en una vista materializada no siempre tiene el mismo rendimiento que una consulta en la tabla materializada equivalente. Esto se debe a que las vistas materializadas siempre devuelven resultados actualizados y deben tener en cuenta los cambios realizados en sus tablas base desde la última actualización de la vista.

Veamos esta situación:

CREATE MATERIALIZED VIEW my_dataset.my_mv AS
SELECT date, customer_id, region, SUM(net_paid) as total_paid
FROM my_dataset.sales
GROUP BY 1, 2, 3;

CREATE TABLE my_dataset.my_materialized_table AS
SELECT date, customer_id, region, SUM(net_paid) as total_paid
FROM my_dataset.sales
GROUP BY 1, 2, 3;

Por ejemplo, esta consulta: 

  SELECT * FROM my_dataset.my_mv LIMIT 10
 suele ejecutarse mucho más lentamente que esta consulta: 
  SELECT * FROM my_dataset.my_materialized_table LIMIT 10
 Para ofrecer resultados actualizados de forma constante, BigQuery debe consultar las filas nuevas de la tabla base y combinarlas en la vista materializada antes de aplicar el predicado "LIMIT 10". Por lo tanto, la lentitud persiste, aunque la vista materializada esté totalmente actualizada.

Por otro lado, las agregaciones de vistas materializadas suelen ser tan rápidas como las consultas en la tabla materializada. Por ejemplo, lo siguiente: 

  SELECT SUM(total_paid) FROM my_dataset.my_mv WHERE date > '2020-12-01'
 Debería ser tan rápido como esto: 
  SELECT SUM(total_paid) FROM my_dataset.my_materialized_table WHERE date > '2020-12-01'