Use vistas materializadas

Este documento fornece informações adicionais sobre as vistas materializadas e como as usar. Antes de ler este documento, familiarize-se com a Introdução às vistas materializadas e Crie vistas materializadas.

Consulte vistas materializadas

Pode consultar as suas vistas materializadas diretamente, da mesma forma que consulta uma tabela normal ou uma vista padrão. As consultas em vistas materializadas são sempre consistentes com as consultas nas tabelas base da vista, mesmo que essas tabelas tenham sido alteradas desde a última atualização da vista materializada. A consulta não aciona automaticamente uma atualização materializada.

Funções necessárias

Para receber as autorizações de que precisa para consultar uma vista materializada, peça ao seu administrador que lhe conceda a função de IAM Visualizador de dados do BigQuery (roles/bigquery.dataViewer) na tabela base da vista materializada e na própria vista materializada. Para mais informações sobre a atribuição de funções, consulte o artigo Faça a gestão do acesso a projetos, pastas e organizações.

Esta função predefinida contém as autorizações necessárias para consultar uma vista materializada. Para ver as autorizações exatas que são necessárias, expanda a secção Autorizações necessárias:

Autorizações necessárias

São necessárias as seguintes autorizações para consultar uma visualização materializada:

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

Também pode conseguir estas autorizações com funções personalizadas ou outras funções predefinidas.

Estas autorizações são necessárias para as consultas de modo a beneficiar da ajustagem inteligente.

Para mais informações sobre as funções de IAM no BigQuery, consulte o artigo Introdução ao IAM.

Atualizações incrementais

As atualizações incrementais ocorrem quando o BigQuery combina os dados da vista em cache com novos dados para fornecer resultados de consultas consistentes, enquanto continua a usar a vista materializada. Para vistas materializadas de tabela única, isto é possível se a tabela base não tiver sido alterada desde a última atualização ou se apenas tiverem sido adicionados novos dados. Para as vistas JOIN, apenas as tabelas no lado esquerdo do JOIN podem ter dados anexados. Se uma das tabelas no lado direito de um JOIN tiver sido alterada, não é possível atualizar a vista de forma incremental.

Se a tabela base tiver atualizações ou eliminações desde a última atualização, ou se as tabelas base da vista materializada no lado direito do JOIN tiverem sido alteradas, o BigQuery não usa atualizações incrementais e, em vez disso, reverte automaticamente para a consulta original. Para mais informações sobre as junções e as vistas materializadas, consulte o artigo Junções. Seguem-se exemplos de ações da Trusted Cloud consola, da ferramenta de linhas de comando bq e da API que podem provocar uma atualização ou uma eliminação:

  • Instruções de linguagem de manipulação de dados (DML) UPDATE, MERGE ou DELETE
  • Truncagem
  • Expiração da partição

As seguintes operações de metadados também impedem que uma vista materializada seja atualizada incrementalmente:

  • Alterar a validade da partição
  • Atualizar ou eliminar uma coluna

Se não for possível atualizar uma vista materializada de forma incremental, as consultas não usam os respetivos dados em cache até que a vista seja atualizada automaticamente ou manualmente. Para ver detalhes sobre o motivo pelo qual uma tarefa não usou dados de vistas materializadas, consulte o artigo Compreenda por que motivo as vistas materializadas foram rejeitadas. Além disso, as vistas materializadas não podem ser atualizadas incrementalmente se a respetiva tabela base tiver acumulado alterações não processadas durante um período superior ao intervalo de deslocamento no tempo da tabela.

Alinhamento de partições

Se uma vista materializada for particionada, o BigQuery garante que as respetivas partições estão alinhadas com as partições da coluna de partição da tabela base. Alinhado significa que os dados de uma determinada partição da tabela base contribuem para a mesma partição da vista materializada. Por exemplo, uma linha da partição 20220101 da tabela base contribuiria apenas para a partição 20220101 da vista materializada.

Quando uma vista materializada é particionada, o comportamento descrito em Atualizações incrementais ocorre para cada partição individual de forma independente. Por exemplo, se os dados forem eliminados numa partição da tabela base, o BigQuery pode continuar a usar as outras partições da vista materializada sem precisar de uma atualização completa de toda a vista materializada.

As vistas materializadas com junções internas só podem ser alinhadas com uma das respetivas tabelas base. Se uma das tabelas base não alinhadas for alterada, afeta toda a vista.

Ajuste inteligente

O BigQuery reescreve automaticamente as consultas para usar vistas materializadas sempre que possível. A reescrita automática melhora o desempenho das consultas e reduz os custos sem alterar os resultados das consultas. A consulta não aciona automaticamente uma atualização materializada. Para que uma consulta seja reescrita através da otimização inteligente, a vista materializada tem de cumprir as seguintes condições:

  • Pertencer ao mesmo projeto que uma das respetivas tabelas base ou o projeto no qual a consulta está a ser executada.
  • Use o mesmo conjunto de tabelas base que a consulta.
  • Inclua todas as colunas que estão a ser lidas.
  • Incluir todas as linhas que estão a ser lidas.

A otimização inteligente não é suportada para o seguinte:

Exemplos de ajuste inteligente

Considere o seguinte exemplo 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

Os exemplos seguintes mostram consultas e por que motivo essas consultas são ou não reescritas automaticamente através desta vista:

Consulta Reescrever? 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
Não A vista tem de incluir todas as colunas que estão a ser lidas. A vista não inclui "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
Sim
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
Não A vista tem de incluir todas as colunas que estão a ser lidas. A vista não inclui o elemento "cliente".
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
sold_datetime= '2021-01-01' AND
promo_id IS NOT NULL
Não A vista tem de incluir todas as colunas que estão a ser lidas. "sold_datetime" não é um resultado (mas "CAST(sold_datetime AS DATE)" é).
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
Sim
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
CAST(sold_datetime AS DATE) >= '2021-01-01' AND
promo_id = 12345
Não A vista tem de incluir todas as linhas que estão a ser lidas. "promo_id" não é um resultado, pelo que não é possível aplicar o filtro mais restritivo à vista.
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE CAST(sold_datetime AS DATE) >= '2020-01-01'
Não A vista tem de incluir todas as linhas que estão a ser lidas. O filtro de visualização para datas em 2021 e posteriores, mas a consulta lê datas de 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
Sim

Compreenda se uma consulta foi reescrita

Para saber se uma consulta foi reescrita pela otimização inteligente para usar uma vista materializada, inspecione o plano de consulta. Se a consulta foi reescrita, o plano de consulta contém um passo READ my_materialized_view, em que my_materialized_view é o nome da vista materializada usada. Para compreender por que motivo uma consulta não usou uma vista materializada, consulte o artigo Compreenda por que motivo as vistas materializadas foram rejeitadas.

Compreenda por que motivo as vistas materializadas foram rejeitadas

Se desativou a atualização automática da vista materializada e a tabela tiver alterações não processadas, a consulta pode ser mais rápida durante vários dias, mas, em seguida, começa a reverter para a consulta original, o que resulta numa velocidade de processamento mais lenta. Para tirar partido das vistas materializadas, ative a atualização automática ou atualize-as manualmente com regularidade e monitorize as tarefas de atualização das vistas materializadas para confirmar que são bem-sucedidas.

Os passos para compreender o motivo pelo qual uma vista materializada foi rejeitada dependem do tipo de consulta que usou:

  • Consulta direta da vista materializada
  • Consulta indireta em que a ajustagem inteligente pode optar por usar a vista materializada

As secções seguintes fornecem passos para ajudar a compreender o motivo pelo qual uma vista materializada foi rejeitada.

Consulta direta de vistas materializadas

As consultas diretas de vistas materializadas podem não usar dados em cache em determinadas circunstâncias. Os passos seguintes podem ajudar a compreender por que motivo os dados da vista materializada não foram usados:

  1. Siga os passos em Monitorize a utilização da visualização materializada e encontre a visualização materializada de destino no campo materialized_view_statistics para a consulta.
  2. Se chosen estiver presente nas estatísticas e o respetivo valor for TRUE, a consulta usa a vista materializada.
  3. Reveja o campo rejected_reason para encontrar os passos seguintes. Na maioria dos casos, pode atualizar manualmente a vista materializada ou aguardar pela próxima atualização automática.

Consulta com otimização inteligente

  1. Siga os passos em Monitorize a utilização da visualização materializada e encontre a visualização materializada de destino no materialized_view_statistics para a consulta.
  2. Reveja o rejected_reason para encontrar os passos seguintes. Por exemplo, se o valor de rejected_reason for COST, significa que a otimização inteligente identificou origens de dados mais eficientes para o custo e o desempenho.
  3. Se a vista materializada não estiver presente, experimente uma consulta direta da vista materializada e siga os passos em Consulta direta de vistas materializadas.
  4. Se a consulta direta não usar a vista materializada, a forma da vista materializada não corresponde à consulta. Para mais informações sobre a otimização inteligente e como as consultas são reescritas através de vistas materializadas, consulte os exemplos de otimização inteligente.

Perguntas frequentes

Quando devo usar consultas agendadas em vez de vistas materializadas?

As consultas agendadas são uma forma conveniente de executar cálculos arbitrariamente complexos periodicamente. Cada vez que a consulta é executada, é executada na totalidade, sem qualquer vantagem dos resultados anteriores, e paga o custo de computação total da consulta. As consultas agendadas são ideais quando não precisa dos dados mais recentes e tem uma elevada tolerância para dados desatualizados.

As vistas materializadas são mais adequadas quando precisa de consultar os dados mais recentes com latência e custo minimizados através da reutilização do resultado calculado anteriormente. Pode usar as vistas materializadas como pseudoíndices, acelerando as consultas à tabela base sem atualizar fluxos de trabalho existentes. A --max_staleness opção permite-lhe definir um nível de desatualização aceitável para as suas vistas materializadas, oferecendo um desempenho consistentemente elevado com custos controlados ao processar conjuntos de dados grandes e que mudam com frequência.

Como regra geral, sempre que possível e se não estiver a executar cálculos arbitrariamente complexos, use vistas materializadas.

Algumas consultas em vistas materializadas são mais lentas do que as mesmas consultas em tabelas materializadas manualmente. Porquê?

Em geral, uma consulta sobre uma vista materializada nem sempre tem o mesmo desempenho que uma consulta sobre a tabela materializada equivalente. O motivo é que as vistas materializadas devolvem sempre resultados atualizados e têm de ter em conta as alterações às respetivas tabelas base desde a última atualização da vista.

Considere este cenário:

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 exemplo, esta consulta:

  SELECT * FROM my_dataset.my_mv LIMIT 10
normalmente, é executado muito mais lentamente do que esta consulta:
  SELECT * FROM my_dataset.my_materialized_table LIMIT 10
Para fornecer resultados consistentemente atualizados, o BigQuery tem de consultar novas linhas na tabela base e uni-las na vista materializada antes de aplicar o predicado "LIMIT 10". Como resultado, a lentidão permanece, mesmo que a vista materializada esteja totalmente atualizada.

Por outro lado, as agregações em vistas materializadas são normalmente tão rápidas quanto as consultas na tabela materializada. Por exemplo, o seguinte:

  SELECT SUM(total_paid) FROM my_dataset.my_mv WHERE date > '2020-12-01'
Deve ser tão rápido como isto:
  SELECT SUM(total_paid) FROM my_dataset.my_materialized_table WHERE date > '2020-12-01'