Usa vistas materializadas

En este documento, se proporciona información adicional sobre las vistas materializadas y cómo usarlas. Antes de leer este documento, familiarízate con las secciones Introducción a las vistas materializadas y Crea vistas materializadas.

Consulta vistas materializadas

Puedes consultar tus vistas materializadas de la misma manera que consultas una tabla normal o una vista estándar. Las consultas de las vistas materializadas siempre son coherentes con las consultas de las tablas base de la vista, incluso si esas tablas cambiaron desde la última vez que se actualizó la vista materializada. La consulta no activa automáticamente una actualización materializada.

Nota: Si borras una tabla base sin borrar primero la vista materializada, las consultas sobre la vista materializada fallarán. Debes volver a crear la vista materializada después de volver a crear la tabla base para consultarla de nuevo.

Roles obligatorios

Para obtener los permisos que necesitas a fin de consultar una vista materializada, pídele a tu administrador que te otorgue el rol de IAM Visualizador de datos de BigQuery (roles/bigquery.dataViewer) en la tabla base de la vista materializada y la vista materializada en sí. Para obtener más información sobre cómo otorgar roles, consulta Administra 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 son necesarios, expande la sección Permisos requeridos:

Permisos necesarios

Se requieren los siguientes permisos para consultar una vista materializada:

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

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

Estos permisos son necesarios para las consultas para beneficiarse del ajuste inteligente.

Para obtener más información sobre los roles de IAM en BigQuery, consulta Introducción a IAM.

Actualizaciones incrementales

Las actualizaciones incrementales se producen cuando BigQuery combina los datos de la vista almacenada en caché con datos nuevos para proporcionar resultados de consultas coherentes mientras se sigue usando la vista materializada. En el caso de las vistas materializadas de una sola tabla, esto es posible si la tabla base no se modifica desde la última actualización o si solo se agregaron datos nuevos. Para las vistas JOIN, solo las tablas del lado izquierdo de JOIN pueden tener datos agregados. Si cambió una de las tablas del lado derecho de un JOIN, la vista no se puede actualizar de forma incremental.

Si la tabla base tuvo actualizaciones o eliminaciones desde la última actualización o si las tablas base de la vista materializada del lado derecho de JOIN cambiaron, BigQuery no usa actualizaciones incrementales y, en su lugar, vuelve a la consulta original de forma automática. Para obtener más información sobre uniones y vistas materializadas, consulta Uniones. Los siguientes son ejemplos de la consola de Google Cloud, la herramienta de línea de comandos de bq y las acciones de la API que pueden causar una actualización o eliminación:

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

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

• Cambiar el vencimiento de la partición
• Actualizar o descartar una columna

Si una vista materializada no se puede actualizar de forma incremental, las consultas no usan sus datos almacenados en caché hasta que la vista se actualice de forma automática o manual. Para obtener detalles sobre por qué un trabajo no usó datos de vistas materializadas, consulta Comprende por qué se rechazaron las vistas materializadas. Además, las vistas materializadas no se pueden actualizar de forma incremental si su tabla base acumuló cambios sin procesar durante un período mayor que el intervalo de viaje en el tiempo de la tabla.

Alineación de particiones

Si una vista materializada está particionada, BigQuery se asegura de que sus particiones estén alineadas con las particiones de la columna de partición de la tabla base. Alineados significa que los datos de una partición particular 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 contribuiría solo a la partición 20220101 de la vista materializada.

Cuando se particiona una vista materializada, el comportamiento descrito en Actualizaciones incrementales se produce para cada partición individual de forma independiente. Por ejemplo, si los datos se borran en una partición de la tabla base, BigQuery aún puede usar las otras particiones de la vista materializada sin requerir una actualización completa de toda la vista materializada.

Las vistas materializadas con uniones internas solo se pueden alinear con una de sus tablas base. Si una de las tablas base no alineadas cambia, afecta a 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 y el costo de la consulta, y no cambia los resultados de la consulta. La consulta no activa automáticamente una actualización materializada. Para que una consulta se reescriba, la vista materializada debe cumplir con las siguientes condiciones:

• Pertenece al mismo conjunto de datos que una de sus tablas base.
• Usar el mismo conjunto de tablas base que la consulta.
• Incluir todas las columnas que se leen.
• Incluir todas las filas que se leen.

El ajuste inteligente no es compatible con lo siguiente:

• Vistas materializadas que hacen referencia a vistas lógicas
• Vistas materializadas con unir todo o unión externa izquierda
• Vistas materializadas no incrementales:

Ejemplos de ajuste inteligente

Considera 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 por qué esas consultas se reescriben de forma automática con esta vista o no:

Consulta	¿Se reescribe?	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 leen. 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 leen. 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 leen. “sold_datetime” no es un resultado (pero “CAST(sold_datetime AS DATE”) 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 leen. “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 leen. La vista filtra las fechas de 2021 y posteriores, pero la consulta lee fechas desde 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í

Comprende si una consulta se reescribió

A fin de comprender si una consulta se reescribió mediante el ajuste inteligente para usar una vista materializada, inspecciona el plan de consultas. Si se reescribió la consulta, el plan de consultas contendrá un paso READ my_materialized_view, en el que my_materialized_view es el nombre de la vista materializada que se usó. Para comprender por qué una consulta no usó una vista materializada, consulta Comprende por qué se rechazaron las vistas materializadas.

Comprende por qué se rechazaron las vistas materializadas

Si inhabilitaste la actualización automática de tu vista materializada y la tabla tiene cambios sin procesar, la consulta podría ser más rápida durante varios días, pero luego comenzará a revertirse a la consulta original, lo que ralentizará la velocidad de procesamiento. Para beneficiarte de las vistas materializadas, habilita la actualización automática o realiza actualizaciones manuales con regularidad, y supervisa los trabajos de actualización de vistas materializadas para confirmar que se realicen correctamente.

Los pasos para comprender por qué se rechazó una vista materializada dependen del tipo de consulta que usaste:

• Consulta directa de la vista materializada
• Consulta indirecta en la que el ajuste inteligente podría elegir usar la vista materializada

En las siguientes secciones, se proporcionan pasos para ayudarte a comprender por qué se rechazó una vista materializada.

Consulta directa de vistas materializadas

Es posible que las consultas directas de vistas materializadas no usen datos almacenados en caché en ciertas circunstancias. Los siguientes pasos pueden ayudarte a comprender por qué no se usaron los datos de vistas materializadas:

1. Sigue los pasos que figuran en Supervisa el uso de las vistas materializadas y busca la vista materializada de destino en el campo materialized_view_statistics para la consulta.
2. Si chosen está presente en las estadísticas y su valor es TRUE, la consulta usa la vista materializada.
3. Revisa el campo rejected_reason para encontrar los próximos pasos. En la mayoría de los casos, puedes actualizar de forma manual la vista materializada o esperar la siguiente actualización automática.

Consulta con ajuste inteligente

1. Sigue los pasos que figuran en Supervisa el uso de las vistas materializadas y busca la vista materializada de destino en materialized_view_statistics para la consulta.
2. Revisa rejected_reason para encontrar los próximos pasos. Por ejemplo, si el valor rejected_reason es COST, el ajuste inteligente identificó fuentes de datos más eficientes para el costo y el rendimiento.
3. Si la vista materializada no está presente, prueba una consulta directa de la vista materializada y sigue los pasos que figuran en Consulta directa de vistas materializadas.
4. Si la consulta directa no usa la vista materializada, la forma de la vista materializada no coincidirá. Para obtener más información sobre el ajuste inteligente y cómo se reescriben las consultas con vistas materializadas, consulta Ejemplos de ajuste inteligente.

Preguntas frecuentes

¿Cuándo debo usar las consultas programadas en comparación con las vistas materializadas?

Las consultas programadas son una forma conveniente de ejecutar cálculos arbitrarios complejos de forma periódica. Cada vez que se ejecuta la consulta, se ejecuta por completo, sin beneficiarse de los resultados anteriores, y pagas el costo de procesamiento completo de la consulta. Las consultas programadas son ideales cuando no necesitas los datos más recientes y tienes una alta tolerancia a la inactividad de los datos.

Las vistas materializadas son más adecuadas cuando necesitas consultar los datos más recientes con latencia y costo minimizados mediante la reutilización del resultado calculado anteriormente. Puedes usar vistas materializadas como seudo-índices, lo que acelera las consultas en la tabla base sin actualizar ningún flujo de trabajo existente. La opción --max_staleness te permite definir la obsolescencia aceptable para las vistas materializadas, lo que proporciona un rendimiento alto y coherente con costos controlados cuando se procesan conjuntos de datos grandes que cambian con frecuencia.

Como regla general, siempre que sea posible y si no ejecutas cálculos arbitrarios complejos, usa vistas materializadas.

Algunas consultas sobre vistas materializadas son más lentas que las mismas sobre tablas materializadas de forma manual. ¿Por qué pasa eso?

En general, una consulta en una vista materializada no siempre es tan eficaz como una consulta en la tabla materializada equivalente. El motivo es que las vistas materializadas siempre muestran resultados actualizados y deben tener en cuenta los cambios en sus tablas base desde la última actualización de la vista.

Considera la siguiente 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, la siguiente consulta:

  SELECT * FROM my_dataset.my_mv LIMIT 10

generalmente se ejecuta mucho más lento que esta consulta:

  SELECT * FROM my_dataset.my_materialized_table LIMIT 10

Para proporcionar resultados actualizados de manera coherente, BigQuery debe consultar filas nuevas en la tabla base y combinarlas en la vista materializada antes de aplicar el predicado “LIMIT 10”. Como resultado, la lentitud permanece, incluso si la vista materializada está completamente actualizada.

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

  SELECT SUM(total_paid) FROM my_dataset.my_mv WHERE date > '2020-12-01'

Debe ser tan rápido como lo siguiente:

  SELECT SUM(total_paid) FROM my_dataset.my_materialized_table WHERE date > '2020-12-01'