Escolher um tipo de materialização para view de métricas
Esta página descreve como selecionar entre materializações agregadas e não agregadas para views de métricas com base nos seus padrões de query. Para 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 a sua situação. As seções a seguir respondem a cada pergunta em detalhes.
Sua situação | Abordagem |
|---|---|
Você executa os mesmos padrões de query com frequência e sabe por quais dimensões agrupa. | |
Você query uma medida não aditiva, como | Materialização agregada com dimensões que correspondem às da query |
É possível executar queries ad hoc sobre dados unidos ou filtrados e não é possível prever o | |
Possui dashboards previsíveis e query ad hoc na mesma view de métricas. | |
Sua view de métricas aponta para uma única tabela, sem joins ou filtros. | Nenhuma; use materializações agregadas para padrões conhecidos ou ignore 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, retornando resultados pré-computados em vez de escanear dados de origem.
Os exemplos a seguir usam uma view de métricas em dados de ventas com os campos region, category e order_date, e as medidas total_revenue (SUM), order_count (COUNT) e unique_customers (COUNT(DISTINCT)).
Como acelerar uma query que executo com frequência?
Crie uma materialização agregada para ela. Uma query que o senhor executa diariamente é uma boa candidata, pois a materialização retorna resultados pré-computados em vez de examinar os dados de origem. Por exemplo: suponha que o senhor execute esta query todas as manhãs:
SELECT region, MEASURE(total_revenue) FROM sales_mv GROUP BY ALL
Se você consulta region e order_date comumente juntos, inclua ambos os campos em uma materialização:
- name: revenue_by_region_date
type: aggregated
dimensions:
- region
- order_date
measures:
- total_revenue
- order_count
Materializar em um nível de detalhe mais fino (região e data em vez de apenas região) significa que qualquer query que agrupa por region sozinho, order_date sozinho, ou ambos pode usar esta materialização. Incluir medidas aditivas como order_count permite que a mesma materialização atenda a queries para essas medidas, então você não precisa criar uma separada para cada.
Como saber se uma materialização existente cobre uma nova query?
Compare as GROUP BY dimensões da query com as dimensões da materialização. Se a materialização não incluir uma dimensão pela qual agrupar, a query não poderá usá-la. Por exemplo, suponha que queira a receita por category, mas sua única materialização seja o exemplo revenue_by_region_date mostrado anteriormente. Como não inclui category, as queries que agrupam por category recorrem a uma materialização não agregada (se existir) ou às tabelas de origem.
Se você fizer consultas por category com frequência, crie uma materialização separada para isso. Se a query for infrequente ou já for rápida o suficiente, não crie uma. Cada materialização adiciona custo de armazenamento e refresh.
Como faço para acelerar uma query com uma medida não aditiva?
Crie uma materialização agregada cujas dimensões correspondam exatamente à GROUP BY da query. Medidas não aditivas, como COUNT(DISTINCT), não podem ser agregadas a partir de uma materialização mais granular, portanto, uma materialização com granularidade diferente não ajudará. Por exemplo, suponha que esta query seja lenta:
SELECT region, MEASURE(unique_customers) FROM sales_mv GROUP BY ALL
unique_customers usa COUNT(DISTINCT), que não é aditivo. A materialização revenue_by_region_date mostrada anteriormente tem dimensões diferentes, portanto, não pode atender a esta query. Crie uma materialização com dimensões que correspondam:
- 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 executa o trabalho dispendioso de unir tabelas e aplicar filtros uma vez, para que as consultas possam agregar a partir do resultado da junção, em vez de unir novamente as tabelas de origem a cada execução.
A agregação ainda ocorre no momento da query, portanto, as materializações não agregadas não são tão rápidas quanto as agregadas. Elas são mais rápidas do que refazer a junção das tabelas de origem brutas a cada query.
Os exemplos a seguir usam uma view de métricas que join três tabelas e aplica um filtro:
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 devo usar para padrões de query imprevisíveis?
Use uma materialização não agregada. Quando você executa queries ad hoc constantemente e não consegue prever o GROUP BY, é difícil definir materializações agregadas que cubram 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 sua forma.
materialized_views:
- name: baseline
type: unaggregated
Devo materializar uma única tabela sem joins?
Uma materialização não agregada em uma única tabela sem *joins* ou filtros duplica a tabela sem benefício. Use materializações agregadas para padrões de *query* conhecidos ou pule a materialização completamente.
Posso usar ambos os tipos de materialização juntos?
Sim. Use uma materialização não agregada como fallback e materializações agregadas para suas consultas de alto tráfego conhecidas. Este padrão se encaixa em uma view de métricas que tem joins caros, juntamente com um painel de widgets conhecidos. A reescrita de query prefere materializações agregadas (correspondência exata ou de rollup) quando possível e usa o fallback para não agregada para todo o resto.
materialized_views:
- name: baseline
type: unaggregated
- name: revenue_by_region_date
type: aggregated
dimensions:
- region
- order_date
measures:
- total_revenue
Ao criar materializações, direcione primeiro suas queries mais lentas ou com maior tráfego. Adicione mais materializações quando observar que as queries estão voltando para a origem. Para verificar se uma query utiliza uma materialização, consulte Verificar se uma query está usando visualizações materializadas.