Usar visualizações materializadas

Neste documento, você encontra mais informações sobre as visualizações materializadas e como usá-las. Antes de ler este documento, veja Introdução às visualizações materializadas e Criar visualizações materializadas.

Consultar visualizações materializadas

É possível consultar visualizações materializadas diretamente, da mesma forma que consulta tabelas ou visualizações padrão. As consultas nas visualizações materializadas são sempre consistentes com as consultas nas tabelas base da visualização, mesmo que elas tenham sido alteradas desde a última atualização da visualização materializada. As consultas não acionam automaticamente uma atualização materializada.

Funções exigidas

Para ter as permissões necessárias para consultar uma visualização materializada, peça ao administrador para conceder a você o papel do IAM Leitor de dados do BigQuery (roles/bigquery.dataViewer) na tabela base da visualização materializada e na própria visualização materializada. Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Esse papel predefinido contém as permissões necessárias para consultar uma visualização materializada. Para conferir as permissões exatas necessárias, expanda a seção Permissões necessárias:

Permissões necessárias

As seguintes permissões são necessárias para consultar uma visualização materializada:

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

Essas permissões também podem ser concedidas com funções personalizadas ou outros papéis predefinidos.

Essas permissões são necessárias para consultas para que você possa se beneficiar do ajuste inteligente.

Para mais informações sobre os papéis do IAM no BigQuery, consulte Introdução ao IAM.

Atualizações incrementais

As atualizações incrementais ocorrem quando o BigQuery combina os dados da visualização em cache com os novos dados para fornecer resultados de consulta consistentes enquanto ainda usa a visualização materializada. Para visualizações materializadas de tabela única, isso é possível se a tabela base não tiver sido alterada desde a última atualização ou se apenas novos dados foram adicionados. Para visualizações JOIN, apenas as tabelas do lado esquerdo da JOIN podem ter dados anexados. Se uma das tabelas no lado direito de um JOIN tiver mudado, a visualização não poderá ser atualizada de forma incremental.

Se a tabela base tiver atualizações ou exclusões desde a última atualização ou se as tabelas base da visualização materializada no lado direito da JOIN tiverem mudado, o BigQuery não vai usar atualizações incrementais e, em vez disso, reverterá automaticamente para a consulta original. Para mais informações sobre mesclagens e visualizações materializadas, consulte Mesclagens. Confira a seguir exemplos do console do Google Cloud, da ferramenta de linha de comando bq e das ações da API que podem causar uma atualização ou exclusão:

  • Declarações de linguagem de manipulação de dados (DML, na sigla em inglês) UPDATE, MERGE ou DELETE
  • Truncamento
  • Expiração da partição

As seguintes operações de metadados também impedem que uma visualização materializada seja atualizada de forma incremental:

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

Se uma visualização materializada não puder ser atualizada de forma incremental, os dados armazenados em cache não serão usados pelas consultas até que a visualização seja atualizada de forma automática ou manual. Para detalhes sobre por que um job não usou dados de visualização materializada, consulte Entender por que as visualizações materializadas foram rejeitadas. Além disso, as visualizações materializadas não podem ser atualizadas de forma incremental se a tabela base tiver acumulado mudanças não processadas por um período maior do que o intervalo de viagem no tempo da tabela.

Alinhamento de partições

Se uma visualização materializada for particionada, o BigQuery garante que as partições sejam alinhadas com as partições da coluna de particionamento da tabela base. Alinhado significa que os dados de uma partição específica da tabela base contribuem para a mesma partição da visualização materializada. Por exemplo, uma linha da partição 20220101 da tabela base contribuiria apenas para a partição 20220101 da visualização materializada.

Quando uma visualização materializada é particionada, o comportamento descrito nas Atualizações incrementais ocorre para cada partição individual de forma independente. Por exemplo, se os dados forem excluídos em uma partição da tabela base, o BigQuery ainda poderá usar as outras partições da visualização materializada sem precisar de uma atualização completa de toda a visualização materializada.

As visualizações materializadas com junções internas só podem ser alinhadas com uma das respectivas tabelas base. Se uma das tabelas base não alinhadas for alterada, ela afetará toda a visualização.

Ajuste inteligente

O BigQuery regrava automaticamente consultas para usar visualizações materializadas sempre que possível. A regravação automática melhora o desempenho e o custo da consulta, além de não alterar os resultados. As consultas não acionam automaticamente uma atualização materializada. Para que uma consulta seja regravada, a visualização materializada precisa atender às seguintes condições:

  • Pertencer ao mesmo conjunto de dados que uma das tabelas base
  • Usar o mesmo conjunto de tabelas base que a consulta
  • Incluir todas as colunas que estão sendo lidas
  • Incluir todas as linhas que estão sendo lidas

O ajuste inteligente não é compatível com:

Exemplos de ajustes inteligentes

Veja o seguinte exemplo de consulta de visualização 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 a seguir mostram consultas e por que elas foram ou não regravadas automaticamente usando esta visualização.

Query Regravar? 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 visualização precisa incluir todas as colunas que estão sendo lidas. A visualização 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 visualização precisa incluir todas as colunas que estão sendo lidas.s A visualização não inclui "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 visualização precisa incluir todas as colunas que estão sendo 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 visualização precisa incluir todas as linhas que estão sendo lidas. "promo_id" não é uma saída, por isso o filtro mais restritivo não pode ser aplicado à visualização.
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE CAST(sold_datetime AS DATE) >= '2020-01-01'
Não A visualização precisa incluir todas as linhas que estão sendo lidas. O filtro de visualização para datas a partir de 2021, mas a consulta lê as datas a partir 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

Entender se uma consulta foi reescrita

Para entender se uma consulta foi reescrita pelo ajuste inteligente para usar uma visualização materializada, inspecione o plano de consulta. Se a consulta foi reescrita, o plano de consulta contém uma etapa READ my_materialized_view, em que my_materialized_view é o nome da visualização materializada usada. Para entender por que uma consulta não usou uma visualização materializada, consulte Entenda por que as visualizações materializadas foram rejeitadas.

Entenda por que as visualizações materializadas foram rejeitadas

Se você tiver desativado a atualização automática da visualização materializada e a tabela tiver mudanças não processadas, a consulta poderá ser mais rápida por vários dias, mas depois reverter para a consulta original, resultando em uma velocidade de processamento mais lenta. Para aproveitar as visualizações materializadas, ative a atualização automática ou faça a atualização manual com frequência e monitore os jobs de atualização de visualização materializada para confirmar o sucesso.

As etapas para entender por que uma visualização materializada foi rejeitada dependem do tipo de consulta que você usou:

  • Consulta direta da visualização materializada
  • Consulta indireta em que o ajuste inteligente pode usar a visualização materializada

As seções a seguir fornecem etapas para ajudar você a entender por que uma visualização materializada foi rejeitada.

Consulta direta de visualizações materializadas

As consultas diretas de visualizações materializadas podem não usar dados armazenados em cache em determinadas circunstâncias. As etapas a seguir podem ajudar você a entender por que os dados da visualização materializada não foram usados:

  1. Siga as etapas em Monitorar o uso da visualização materializada e encontre a visualização materializada de destino no campo materialized_view_statistics da consulta. do Google Analytics.
  2. Se chosen estiver presente nas estatísticas e o valor for TRUE, a visualização materializada será usada pela consulta.
  3. Consulte o campo rejected_reason para ver as próximas etapas. Na maioria dos casos, é possível atualizar manualmente a visualização materializada ou aguardar a próxima atualização automática.

Consulta com ajuste inteligente

  1. Siga as etapas em Monitorar o uso da visualização materializada e encontre a visualização materializada de destino no materialized_view_statistics para a consulta.
  2. Consulte a rejected_reason para ver as próximas etapas. Por exemplo, se o valor rejected_reason for COST, o ajuste inteligente identificou fontes de dados mais eficientes para custo e desempenho.
  3. Se a visualização materializada não estiver presente, tente uma consulta direta da visualização materializada e siga as etapas em Consulta direta de visualizações materializadas.
  4. Se a consulta direta não usar a visualização materializada, a forma da visualização materializada não corresponderá à consulta. Para mais informações sobre o ajuste inteligente e como as consultas são reescritas usando visualizações materializadas, consulte Exemplos de ajuste inteligente.

Perguntas frequentes

Quando devo usar consultas programadas e visualizações materializadas?

As consultas programadas são uma maneira conveniente de executar cálculos arbitrariamente complexos periodicamente. Sempre que a consulta é executada, ela é executada por completo, sem nenhum benefício dos resultados anteriores, e você paga o custo total de computação da consulta. As consultas programadas são ideais quando você não precisa dos dados mais recentes e tem alta tolerância a desatualização deles.

As visualizações materializadas são mais adequadas quando é necessário consultar os dados mais recentes com latência e custo mínimos, reutilizando o resultado calculado anteriormente. É possível usar visualizações materializadas como pseudoíndices, acelerando consultas para a tabela base sem atualizar fluxos de trabalho existentes. A opção --max_staleness permite definir uma inatividade aceitável para visualizações materializadas, fornecendo um desempenho consistentemente alto com custos controlados ao processar conjuntos de dados grandes e que mudam com frequência.

Como orientação geral, sempre que possível e se cálculos arbitrariamente complexos não estiverem sendo executados, use as visualizações materializadas.

Algumas consultas em visualizações materializadas são mais lentas do que as mesmas consultas em tabelas materializadas manualmente. E qual a explicação?

Em geral, uma consulta em uma visualização materializada nem sempre é tão eficiente quanto uma consulta na tabela materializada equivalente. O motivo é que as visualizações materializadas sempre retornam resultados novos e precisam considerar as mudanças nas tabelas base desde a última atualização de visualização.

Imagine esta situação:

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 é executada muito mais lentamente do que esta consulta:
  SELECT * FROM my_dataset.my_materialized_table LIMIT 10
Para fornecer resultados atualizados de maneira consistente, o BigQuery precisa consultar novas linhas na tabela base e mesclá-las na visualização materializada antes de aplicar o predicado "LIMIT 10". Como resultado, a lentidão permanece, mesmo que a visualização materializada esteja totalmente atualizada.

Por outro lado, as agregações nas visualizações materializadas geralmente são tão rápidas quanto as consultas na tabela materializada. Por exemplo, os seguintes URLs:

  SELECT SUM(total_paid) FROM my_dataset.my_mv WHERE date > '2020-12-01'
A velocidade precisa ser assim:
  SELECT SUM(total_paid) FROM my_dataset.my_materialized_table WHERE date > '2020-12-01'