Pular para o conteúdo principal

Escolha um tipo de materialização para visualizações de métricas

Esta página descreve como escolher entre materializações agregadas e não agregadas para views de métricas com base nos seus padrões de consulta. Para saber o que é cada tipo e como funciona, consulte Tipos de materializações para views de métricas.

Use a tabela a seguir para encontrar a abordagem correta para sua situação. As seções a seguir respondem a cada pergunta em detalhes.

A situação

Abordagem

Quando se executam os mesmos padrões de consulta com frequência, sabe-se em quais dimensões agrupar.

Materialização agregada

Uma medida não aditiva, como COUNT(DISTINCT), é consultada em uma granularidade fixa.

Materialização agregada com dimensões que correspondem à consulta GROUP BY

O senhor executa consultas ad hoc sobre dados unidos ou filtrados e não pode prever o GROUP BY.

Materialização não agregada

Há tanto dashboards previsíveis quanto queries ad hoc na mesma view de métricas.

Ambos os tipos em conjunto

A sua view de métricas aponta para uma única tabela sem joins ou filtros.

Nenhuma; usar materializações agregadas para padrões conhecidos, ou ignorar a materialização

Materializações agregadas

Uma materialização agregada é uma tabela de respostas pré-construída para um tipo específico de pergunta. Ele atende a queries correspondentes mais rapidamente ao retornar resultados pré-computados em vez de escanear dados de origem.

Os exemplos a seguir usam uma view de métricas em dados de vendas com os campos region, category e order_date, e as medidas total_revenue (SUM), order_count (COUNT) e unique_customers (COUNT(DISTINCT)).

Como faço para acelerar uma consulta que executo com frequência?

Crie uma materialização agregada para ela. Uma consulta que é executada diariamente é uma boa candidata, porque a materialização retorna resultados pré-computados em vez de varrer os dados de origem. Por exemplo, suponha que você execute esta consulta todas as manhãs:

SQL
SELECT region, MEASURE(total_revenue) FROM sales_mv GROUP BY ALL

Caso consulte region e order_date em conjunto com frequência, inclua ambos os campos em uma materialização:

YAML
- name: revenue_by_region_date
type: aggregated
dimensions:
- region
- order_date
measures:
- total_revenue
- order_count

A materialização em um nível mais granular (região *e* data, em vez de apenas a região) significa que qualquer query que agrupe region apenas por, order_date apenas por, ou por ambos, pode usar essa materialização. Incluir medidas aditivas, como order_count, permite que a mesma materialização atenda a queries para essas medidas, assim não é necessário criar uma separada para cada uma.

Como posso saber se uma materialização existente abrange uma nova query?

Compare as dimensões GROUP BY da consulta às dimensões da materialização. Se a materialização não incluir uma dimensão para agrupar, a query não pode usá-la. Por exemplo, suponha que você queira receita por category, mas sua única materialização é o exemplo revenue_by_region_date mostrado anteriormente. Como não inclui category, consultas agrupando por category recorrem a uma materialização não agregada (se uma existir) ou às tabelas de origem.

Se consultar por category com frequência, crie uma materialização separada para isso. Se a consulta for infrequente ou já for rápida o suficiente, não é necessário criar uma. Cada materialização adiciona custo de armazenamento e de refresh.

Como faço para acelerar uma query com uma medida não aditiva?

Crie uma materialização agregada com dimensões que correspondam exatamente às GROUP BY da query. Medidas não aditivas, como COUNT(DISTINCT), não podem ser agregadas a partir de uma materialização de granularidade mais fina, portanto, uma materialização em uma granularidade diferente não ajudará. Por exemplo, suponha que esta consulta é lenta:

SQL
SELECT region, MEASURE(unique_customers) FROM sales_mv GROUP BY ALL

unique_customers utiliza COUNT(DISTINCT), que é não aditivo. A revenue_by_region_date materialização mostrada anteriormente tem dimensões diferentes, portanto não pode atender a esta consulta. Criar uma visualização materializada com dimensões que correspondam:

YAML
- name: customers_by_region
type: aggregated
dimensions:
- region
measures:
- unique_customers

Materializações não agregadas

Uma materialização não agregada é um ponto de partida pré-construído, não uma resposta pré-construída. Ele realiza o trabalho oneroso de junção de tabelas e aplicação de filtros uma vez, para que as consultas possam agregar a partir do resultado da junção, em vez de realizar novamente a junção das tabelas de origem em cada execução.

A agregação ainda ocorre em tempo de consulta, portanto as materializações não agregadas não são tão rápidas quanto as agregadas. Eles são mais rápidos do que refazer as junções a partir das tabelas de origem brutas a cada query.

Os exemplos a seguir utilizam uma view de métricas que faz join em três tabelas e aplica um filtro:

YAML
source: raw_events
filter: event_type = 'purchase'
joins:
- name: customers
source: dim_customers
on: customers.id = source.customer_id
- name: products
source: dim_products
on: products.id = source.product_id

Que tipo deve ser usado para padrões de query imprevisíveis?

Usar uma materialização não agregada. Quando se executam queries ad hoc constantemente e não é possível prever o GROUP BY, é difícil definir materializações agregadas que abranjam os campos corretos. Uma materialização não agregada contorna este problema: ela materializa o dataset unido e filtrado uma vez, e qualquer query pode usá-lo independentemente de seu formato.

YAML
materialized_views:
- name: baseline
type: unaggregated

Devo materializar uma única tabela sem join?

Uma materialização não agregada em uma tabela única sem joins ou filtros duplica a tabela sem benefício. Utilize materializações agregadas para padrões de query conhecidos, ou ignore a materialização completamente.

Posso usar os dois tipos de materialização em conjunto?

Sim. Use uma materialização não agregada como fallback, e materializações agregadas para suas queries de alto tráfego conhecidas. Este padrão se adapta a uma view de métrica que possui joins de alto custo, juntamente com um dashboard de widgets conhecidos. A reescrita de query prefere materializações agregadas (correspondência exata ou de rollup) quando possível e recorre às não agregadas para tudo o mais.

YAML
materialized_views:
- name: baseline
type: unaggregated
- name: revenue_by_region_date
type: aggregated
dimensions:
- region
- order_date
measures:
- total_revenue

Ao criar materializações, segmente primeiro as consultas mais lentas ou com maior tráfego. Adicione mais materializações quando observar queries voltando à origem. Para verificar se uma consulta está usando uma materialização, consulte Verificar se uma consulta está usando visualizações materializadas.