Passer au contenu principal
Ce tutoriel vous montre comment maintenir à jour des rollups pré-agrégés à partir d’une table d’événements à fort volume à l’aide de vues matérialisées. Vous créerez trois objets : une table d’événements bruts, une table de rollup et la vue matérialisée qui alimente automatiquement le rollup.

Quand utiliser ce modèle

Utilisez ce modèle lorsque :
  • Vous avez un flux d’événements uniquement en ajout (clics, vues de page, IoT, logs).
  • La plupart des requêtes sont des agrégations sur des intervalles de temps (par minute/heure/jour).
  • Vous voulez des temps de lecture systématiquement inférieurs à une seconde sans réanalyser toutes les lignes brutes.
1

Créer la table d’événements bruts

Remarques
  • PARTITION BY toYYYYMM(event_time) permet de conserver des partitions de petite taille et faciles à supprimer.
  • ORDER BY (event_time, user_id) prend en charge les requêtes bornées dans le temps + le filtre secondaire.
  • LowCardinality(String) économise de la mémoire pour les dimensions catégorielles.
  • TTL supprime les données brutes après 90 jours (à ajuster selon vos exigences de rétention).
2

Concevoir la table de rollup (agrégée)

Nous effectuerons une préagrégation à une granularité horaire. Choisissez la granularité en fonction de la période d’analyse la plus courante.
Nous stockons des états d’agrégation (par exemple, AggregateFunction(sum, ...)) qui représentent de façon compacte des agrégats partiels et peuvent être fusionnés ou finalisés ultérieurement.
3

Créer une vue matérialisée qui alimente le rollup

Cette vue matérialisée se déclenche automatiquement lors des insertions dans events_raw et écrit des états d’agrégation dans le rollup.
4

Insérer quelques données d’exemple

Insérez quelques données d’exemple :
5

Interroger le rollup

Vous pouvez soit fusionner les états à la lecture, soit les finaliser :

Si vous prévoyez que les lectures porteront toujours sur le rollup, vous pouvez créer une deuxième vue matérialisée qui écrit des valeurs finalisées dans une table MergeTree « simple », avec la même granularité d’1 h. Les états offrent plus de souplesse, tandis que les valeurs finalisées rendent les lectures légèrement plus simples.
6

Filtrez sur les champs de la clé primaire pour des performances optimales

Vous pouvez utiliser la commande EXPLAIN pour voir comment l’index est utilisé pour écarter des données :
Query
Response
Le plan d’exécution de la requête ci-dessus montre que trois types d’index sont utilisés : un index MinMax, un index de partition et un index de clé primaire. Chaque index utilise des champs spécifiés dans notre clé primaire : (bucket_start, country, event_type). Pour obtenir les meilleures performances de filtrage, assurez-vous que vos requêtes utilisent les champs de la clé primaire afin d’écarter les données inutiles.
7

Variantes courantes

  • Granularités différentes : ajoutez un rollup quotidien :
Ensuite, une deuxième vue matérialisée :
  • Compression : appliquez des codecs aux colonnes volumineuses (exemple : Codec(ZSTD(3))) dans la table brute.
  • Contrôle des coûts : concentrez la rétention la plus lourde sur la table brute et conservez des roll-ups de longue durée.
  • Backfilling : lors du chargement de données historiques, insérez dans events_raw et laissez la vue matérialisée créer automatiquement les roll-ups. Pour les lignes existantes, utilisez POPULATE lors de la création de la vue matérialisée si cela s’y prête, ou INSERT SELECT.
8

Nettoyage et rétention

  • Augmentez le TTL des données brutes (par ex., 30/90 jours), mais conservez les agrégats plus longtemps (par ex., 1 an).
  • Vous pouvez également utiliser TTL pour déplacer les anciennes parts vers un stockage moins coûteux si la hiérarchisation par niveaux est activée.
9

Dépannage

  • La vue matérialisée ne se met pas à jour ? Vérifiez que les insertions arrivent bien dans events_raw (et non dans la table de rollup) et que la cible de la vue matérialisée est correcte (TO events_rollup_1h).
  • Requêtes lentes ? Vérifiez qu’elles utilisent bien le rollup (interrogez directement la table de rollup) et que les filtres temporels correspondent à sa granularité.
  • Écarts après backfill ? Utilisez SYSTEM FLUSH LOGS et vérifiez system.query_log / system.parts pour confirmer les insertions et les fusions.
Dernière modification le 25 juin 2026