Exemple : Nous utiliserons un jeu de données fictif avec le nombre de vues par heure pour un ensemble de noms de domaine. Notre objectif
- Nous avons besoin de données agrégées par mois pour chaque nom de domaine,
- Nous avons également besoin de données agrégées par année pour chaque nom de domaine.
- Écrire des requêtes qui lisent et agrègent les données pendant la requête SELECT
- Préparer les données au moment de l’ingestion dans un nouveau format
- Préparer les données au moment de l’ingestion pour une agrégation spécifique.
Table source pour les vues matérialisées
Null.
Vous pouvez créer une vue matérialisée sur une table Null. Ainsi, les données écrites dans la table seront bien prises en compte par la vue, mais les données brutes d’origine seront tout de même rejetées.
Table agrégée mensuelle et vue matérialisée
Target ; dans cet exemple, il s’agira de analytics.monthly_aggregated_data, où nous stockerons la somme des vues par mois et par nom de domaine.
Table agrégée annuelle et vue matérialisée
monthly_aggregated_data.
Nous allons d’abord créer une nouvelle table cible qui stockera la somme des vues, agrégées par année, pour chaque nom de domaine.
FROM utilisera la table monthly_aggregated_data, ce qui signifie que le flux de données sera le suivant :
- Les données arrivent dans la table
hourly_data. - ClickHouse transmettra les données reçues à la première vue matérialisée,
monthly_aggregated_data, - Enfin, les données reçues à l’étape 2 seront transmises à
year_aggregated_data.
Une erreur d’interprétation fréquente lorsqu’on travaille avec des vues matérialisées consiste à croire que les données sont lues depuis la table. Ce n’est pas ainsi que fonctionnent les
vues matérialisées : les données transmises correspondent au bloc inséré, et non au résultat final de votre table.Imaginons, dans cet exemple, que le moteur utilisé dans monthly_aggregated_data soit un CollapsingMergeTree : les données transmises à notre deuxième vue matérialisée year_aggregated_data_mv ne seront pas le résultat final de la table après collapsing, mais le bloc de données avec les champs définis comme dans le SELECT ... GROUP BY.Si vous utilisez CollapsingMergeTree, ReplacingMergeTree, ou même SummingMergeTree, et que vous prévoyez de créer une vue matérialisée en cascade, vous devez comprendre les limitations décrites ici.Données d’exemple
analytics.hourly_data, vous verrez ce qui suit, car le moteur de la table est Null, mais les données ont bien été traitées.
Résultats
sumCountViews, vous verrez sa représentation binaire (dans certains terminaux), car la valeur n’est pas stockée sous forme de nombre, mais comme un type AggregateFunction.
Pour obtenir le résultat final de l’agrégation, vous devez utiliser le suffixe -Merge.
Vous pouvez voir les caractères spéciaux stockés dans AggregateFunction avec cette requête :
Merge pour obtenir la valeur sumCountViews :
AggregatingMergeTree, nous avons défini l’AggregateFunction comme sum, nous pouvons donc utiliser sumMerge. Lorsque nous utilisons la fonction avg avec l’AggregateFunction, nous utiliserons avgMerge, et ainsi de suite.
monthly_aggregated_data, nous pouvons les consulter sous forme agrégée par mois pour chaque nom de domaine :
Combiner plusieurs tables sources en une seule table cible
UNION ALL.
Commencez par créer deux tables sources représentant différents ensembles de métriques :
Target avec le jeu combiné de métriques :
Target. Vous n’avez pas besoin d’inclure explicitement les colonnes manquantes :
Target :
Target :