Choisir un type de matérialisation pour les vues métriques
Cette page décrit comment choisir entre les matérialisations agrégées et non agrégées pour les vues de métriques en fonction de vos modèles de query. Pour savoir ce qu'est chaque type et comment il fonctionne, consultez Types de matérialisations pour les vues de métriques.
Utilisez le tableau suivant pour trouver l'approche appropriée à votre situation. Les sections suivantes répondent à chaque question en détail.
Votre situation | Approche |
|---|---|
Vous exécutez souvent les mêmes modèles de query et savez quelles dimensions vous utilisez pour le regroupement. | |
Vous interrogez une mesure non additive, telle que | Matérialisation agrégée avec des dimensions qui correspondent à celle de la requête |
Vous exécutez des requêtes ad hoc sur des données jointes ou filtrées et ne pouvez pas prédire le | |
Vous avez à la fois des tableaux de bord prévisibles et des queries ad hoc sur la même vue métrique. | |
Votre vue métrique pointe vers une table unique sans jointures ni filtres. | Ni l'une ni l'autre; utilisez des matérialisations agrégées pour les modèles connus, ou ignorez la matérialisation. |
Matérialisations agrégées
Une matérialisation agrégée est une table de réponses pré-construite pour un type de question spécifique. Il traite les requêtes correspondantes plus rapidement en renvoyant des résultats précalculés au lieu d'analyser les données sources.
Les exemples suivants utilisent une vue de métrique sur les données de Ventes avec les champs region, category et order_date, et les mesures total_revenue (SUM), order_count (COUNT) et unique_customers (COUNT(DISTINCT)).
Comment puis-je accélérer une query que j'exécute fréquemment ?
Créez une matérialisation agrégée pour celle-ci. Une query que vous exécutez quotidiennement est une bonne candidate, car la matérialisation renvoie des résultats précalculés au lieu de scanner les données sources. Par exemple, supposez que vous exécutez cette query chaque matin :
SELECT region, MEASURE(total_revenue) FROM sales_mv GROUP BY ALL
Si vous query couramment region et order_date ensemble, incluez les deux champs dans une seule matérialisation :
- name: revenue_by_region_date
type: aggregated
dimensions:
- region
- order_date
measures:
- total_revenue
- order_count
La matérialisation à un niveau de granularité plus fin (région et date au lieu de la région seule) signifie que toute query regroupant par region seule, order_date seule, ou les deux peut utiliser cette matérialisation. L'inclusion de mesures additives telles que order_count permet à la même matérialisation de servir les queries pour ces mesures, vous n'avez donc pas besoin d'en créer une séparée pour chaque.
Comment savoir si une matérialisation existante couvre une nouvelle query ?
Comparez les GROUP BY dimensions de la query aux dimensions de la matérialisation. Si la matérialisation n'inclut pas une dimension par laquelle vous groupez, la query ne peut pas l'utiliser. Par exemple, supposez que vous vouliez des revenus par category, mais que votre seule matérialisation est l'exemple revenue_by_region_date montré précédemment. Comme elle n'inclut pas category, les requêtes regroupées par category reviennent à une matérialisation non agrégée (si elle existe) ou aux tables sources.
Si vous effectuez fréquemment des requêtes par category, créez une matérialisation distincte pour cela. Si la requête est peu fréquente ou déjà suffisamment rapide, n'en créez pas. Chaque matérialisation ajoute un coût de stockage et de refresh.
Comment puis-je accélérer une query avec une mesure non additive ?
Créez une matérialisation agrégée dont les dimensions correspondent exactement aux GROUP BY de la query. Les mesures non additives, telles que COUNT(DISTINCT), ne peuvent pas être agrégées à partir d'une matérialisation plus fine, donc une matérialisation à un niveau de granularité différent ne sera pas utile. Par exemple, supposons que cette requête est lente :
SELECT region, MEASURE(unique_customers) FROM sales_mv GROUP BY ALL
unique_customers utilise COUNT(DISTINCT), qui n’est pas additif. La matérialisation revenue_by_region_date présentée précédemment a des dimensions différentes, elle ne peut donc pas servir cette query. Créez une matérialisation avec des dimensions qui correspondent :
- name: customers_by_region
type: aggregated
dimensions:
- region
measures:
- unique_customers
Matérialisations non agrégées
Une matérialisation non agrégée est un point de départ pré-établi, pas une réponse pré-établie. Il effectue le travail coûteux de jointure des tables et d'application des filtres une seule fois, de sorte que les query peuvent agréger à partir du résultat joint au lieu de re-joindre les tables sources à chaque exécution.
L'agrégation se produit toujours au moment de la query, de sorte que les matérialisations non agrégées ne sont pas aussi rapides que les matérialisations agrégées. Ils sont plus rapides que de rejoindre les tables source brutes à chaque query.
Les exemples suivants utilisent une vue de métrique qui joint trois tables et applique un filtre :
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
Quel type dois-je utiliser pour les modèles de query imprévisibles ?
Utilisez une matérialisation non agrégée. Lorsque vous exécutez constamment des requêtes ad hoc et que vous ne pouvez pas prévoir le GROUP BY, il est difficile de définir des matérialisations agrégées qui couvrent les bons champs. Une matérialisation non agrégée contourne ce problème : elle matérialise le dataset joint et filtré une seule fois, et toute query peut l'utiliser quelle que soit sa forme.
materialized_views:
- name: baseline
type: unaggregated
Dois-je matérialiser une table unique sans jointures ?
Une matérialisation non agrégée sur une seule table, sans jointures ni filtres, duplique la table sans aucun avantage. Utilisez des matérialisations agrégées pour les modèles de query connus, ou ignorez entièrement la matérialisation.
Puis-je utiliser les deux types de matérialisation ensemble ?
Oui. Utilisez une matérialisation non agrégée comme fallback, et des matérialisations agrégées pour vos queries à fort trafic connues. Ce modèle correspond à une vue métrique qui comporte des jointures coûteuses ainsi qu’un dashboard de widgets connus. La réécriture de la query préfère les matérialisations agrégées (correspondance exacte ou en cumul) lorsque cela est possible et utilise la matérialisation non agrégée pour tout le reste en tant que fallback.
materialized_views:
- name: baseline
type: unaggregated
- name: revenue_by_region_date
type: aggregated
dimensions:
- region
- order_date
measures:
- total_revenue
Lors de la création de matérialisations, ciblez d'abord vos queries les plus lentes ou celles avec le trafic le plus élevé. Ajoutez davantage de matérialisations lorsque vous observez que les requêtes se replient vers la source. Pour vérifier si une query utilise une matérialisation, consultez Vérifier qu'une query utilise des vues matérialisées.