TUTORIEL | Les vues matérialisées avec BigQuery

En arrivant dans le monde de la Big Data en tant que consultant, j’ai été tout de suite confronté à l’un des problèmes majeurs de cette discipline : l’optimisation des requêtes SQL. En effet, pour minimiser les coûts liés à la consommation de ressources matérielles et optimiser les temps de réponse, il faudra passer par quelques améliorations dans nos requêtes, voire dans notre architecture, comme nous allons l’étudier juste après. Car oui, des requêtes trop gourmandes peuvent faire grimper très rapidement la consommation énergétique du processeur, et donc la facture par la même occasion… Pour améliorer cela, différentes solutions d’optimisation s’offrent à nous. Parmi elles, il existe une technique très efficace :  les vues matérialisées.

Avant de présenter d’entrer dans le vif du sujet, précisons tout d’abord ce qu’est BigQuery, l’environnement cloud dans lequel nous allons étudier les vues matérialisées.

BigQuery est une solution OLAP (Online Analytical Processing) qui permet de stocker des ensembles volumineux de données et lancer des requêtes sur ces derniers, sans matériel ni infrastructures adaptées, de manière ultra-rapide grâce à la puissance de traitement de l’infrastructure de Google.

Qu’est-ce qu’une vue matérialisée?

Une vue matérialisée est une vue dont les données sont matérialisées, c’est-à-dire précalculées et stockées. Étant donné que les données sont précalculées, l’interrogation d’une vue matérialisée est plus rapide que l’exécution d’une requête sur la table de base de la vue. Cette différence de performance peut être significative lorsqu’une requête est exécutée fréquemment ou est suffisamment complexe, permettant un gain de performance relativement important lorsqu’elles sont bien utilisées.

Dans quel cas une vue matérialisée est-elle plus utile qu’une vue simple?

L’utilisation des vues matérialisées se justifie lorsque vous devez interroger les données les plus récentes tout en réduisant la latence et les coûts par réutilisation des résultats précédemment calculés.

Vous pouvez utiliser les vues matérialisées en tant que pseudo-index (une vue simple), ce qui vous permet d’accélérer les requêtes adressées à la table de base sans mettre à jour les workflows existants. De manière générale, dans la mesure du possible et si vous n’exécutez pas de calculs arbitrairement complexes, utilisez les vues matérialisées.

Comment fonctionne une vue matérialisée dans BigQuery?

Une vue matérialisée est toujours cohérente avec la table de base. Si une table de base est modifiée via une mise à jour, une fusion, une troncation ou une expiration de la partition, BigQuery invalidera les parties concernées de la vue matérialisée et relira intégralement la partie correspondante de la table de base.

Si une requête ou une partie d’une requête sur la table source peut être résolue en interrogeant la vue matérialisée, BigQuery réécrira (réacheminera) la requête de façon à utiliser la vue matérialisée pour améliorer les performances et/ou l’efficacité.

Créer une vue matérialisée dans BigQuery

Ci-dessous un exemple tiré du site officiel de Google Cloud Platform (GCP) :

Démo time !

Dans cette première capture d’écran (CP1) nous faisons la démonstration de requêter une table avant la création d’une vue matérialisée pour cette dernière.

Nous constatons trois choses:

• La taille des données qui seront traitées par cette requête est équivalent à +/- 1.5 Mo (En haut à droite “This query will process 1.5 MiB when run”).
• Dans le plan d’exécution de la requête nous remarquons qu’il y a une lecture de notre table de base (En bas à gauche, là où il est écrit “READ”).
• Le temps de lecture de la table (L’opération “READ”) a pris 203 ms.

Jusqu’ici c’est le comportement normal et attendu.

Essayons maintenant d’utiliser une vue matérialisée pour optimiser cette requête (voir CP2). Le résultat est plutôt beau gosse 😊

Trois choses ont changé :

• La taille des données calculées a baissé drastiquement, nous sommes passés de 1.5 Mo à 1.1 Ko de données traitées (en haut à droite).
• L’apparition d’un nouveau bloc “READ” (en bas à gauche), ce qui veut dire que le moteur de BigQuery a modifié la requête en arrière-plan et par conséquent le plan d’exécution a changé pour inclure la vue matérialisée dans nos traitements.
• Le temps de lecture de la table n’a pris que 4ms (au lieu des 203ms de base).

Dans cet article, nous avons vu l’utilité des vues matérialisées et leur impact sur les performances de nos requêtes SQL. En général, ce n’est pas chose aisée de détecter le besoin d’une vue matérialisée. Mais, quand la décision d’en créer une est prise, alors généralement les économies en termes d’argent et d’énergie,  et les gains de temps sont ensuite considérables.