La couche de cache de Looker Studio s’intercale entre le visiteur et BigQuery. Comprendre son fonctionnement change la façon dont on configure les plages de dates, les modes d’identification et les planifications d’actualisation — des décisions qui paraissent cosmétiques mais qui ont un impact significatif sur le volume de requêtes et les coûts.
Fonctionnement du cache
Chaque composant graphique dans Looker Studio possède son propre cache indépendant. La clé de cache est une combinaison de :
- Les dimensions et métriques du graphique
- La plage de dates appliquée au graphique
- Les valeurs de filtres actifs
Toute modification de l’un de ces paramètres provoque un échec du cache, déclenchant une nouvelle requête BigQuery. Un tableau de bord avec 10 graphiques où quelqu’un modifie le filtre de campagne génère 10 nouvelles requêtes — une par graphique — car la clé de cache de chaque graphique inclut désormais la nouvelle valeur du filtre.
Le paramètre de fraîcheur des données par défaut pour les connexions BigQuery est de 12 heures. Cela signifie que Looker Studio ne soumettra pas de nouvelle requête BigQuery pour le même graphique avec les mêmes paramètres pendant une fenêtre de 12 heures. Ce délai est configurable jusqu’à 1 minute (pour les besoins en données quasi temps réel) ou peut être augmenté. Plus la fenêtre de fraîcheur est longue, plus les requêtes sont servies depuis le cache plutôt que depuis BigQuery.
Pourquoi « 30 derniers jours » coûte plus cher que « Ce mois-ci »
C’est un détail subtil mais à fort impact. Les plages de dates dynamiques comme « 30 derniers jours » ou « 7 derniers jours » génèrent des requêtes différentes chaque jour car les bornes de dates évoluent. Aujourd’hui, « 30 derniers jours » correspond au 26 février - 27 mars. Demain, ce sera le 27 février - 28 mars. Des bornes de dates différentes = une clé de cache différente = un échec de cache chaque jour.
Les plages de périodes fixes comme « Ce mois-ci » ou « Ce trimestre » conservent les mêmes bornes jusqu’au changement de période. « Ce mois-ci » reste le 1er mars - 27 mars toute la journée jusqu’à la fin mars. Tout visiteur qui ouvre le même tableau de bord ce jour-là obtient un succès de cache après que la première personne l’a chargé (à condition que les identifiants correspondent — voir ci-dessous).
L’implication pratique : si votre tableau de bord a une plage de dates par défaut de « 30 derniers jours » et que 50 personnes l’ouvrent au cours d’une journée de travail, la première personne subit un échec de cache (1 requête BigQuery par graphique), et tout le monde bénéficie d’un succès de cache. Mais le lendemain matin, les bornes de dates changent, le cache devient obsolète, et la première personne de la journée déclenche à nouveau des requêtes fraîches.
Avec « Ce mois-ci », le cache reste chaud tout le mois. Quiconque ouvre le tableau de bord le 15 mars bénéficie du cache constitué par quiconque l’a ouvert le 1er mars.
Utilisez des bornes de dates fixes partout où le cas d’usage métier le permet. Là où les utilisateurs ont réellement besoin de fenêtres glissantes, acceptez l’échec de cache quotidien comme le coût de cette fonctionnalité.
Identifiants du propriétaire vs identifiants du visiteur
Ce paramètre a l’impact le plus important sur le comportement du cache et doit orienter l’architecture de vos tableaux de bord.
Identifiants du propriétaire : tous les visiteurs accèdent à BigQuery via l’identité du propriétaire du tableau de bord. Un seul cache est partagé entre tous les visiteurs — plus efficace, moins de requêtes au total, coûts BigQuery réduits. La première personne à ouvrir le tableau de bord avec une combinaison de filtres donnée paie le coût de la requête ; tout le monde partage ensuite ce succès de cache.
Identifiants du visiteur : la session de chaque visiteur crée son propre cache, distinct de celui de tous les autres visiteurs. Si 50 personnes ouvrent le même tableau de bord, il y a jusqu’à 50 caches indépendants. La première personne de chaque session subit un échec de cache. Cela génère significativement plus de requêtes BigQuery que les identifiants du propriétaire.
Le compromis porte sur le contrôle d’accès. Les identifiants du propriétaire signifient que chaque visiteur voit exactement les données que le propriétaire peut voir, sans filtrage par ligne selon l’identité du visiteur. Si le tableau de bord présente des données que tout le monde devrait pouvoir consulter (métriques agrégées du site web, KPI à l’échelle de l’entreprise), les identifiants du propriétaire sont le bon choix.
Les identifiants du visiteur sont nécessaires quand différents visiteurs doivent voir des données différentes : chaque commercial ne voyant que ses comptes, chaque directeur régional ne voyant que sa région. Le volume de requêtes et les coûts plus élevés sont le prix de ce filtrage par visiteur. Dans ce cas, envisagez si les politiques d’accès par ligne BigQuery constituent une implémentation plus propre que la séparation par identifiants.
Il y a aussi un risque de dépendance organisationnelle avec les identifiants du propriétaire : si le propriétaire des identifiants quitte l’organisation, chaque rapport utilisant ses identifiants tombe en panne simultanément. Looker Studio Pro atténue ce risque avec la propriété organisationnelle, mais sur l’offre gratuite, utilisez un compte de service dédié comme propriétaire des identifiants plutôt qu’un compte personnel.
Préchauffage du cache
Le premier visiteur d’un tableau de bord après l’actualisation des données subit toujours un échec de cache. Pour les tableaux de bord utilisés par des équipes dirigeantes ou largement partagés en début de journée de travail, cette expérience du premier chargement est importante. Le préchauffage résout ce problème.
Le schéma : après la fin de l’actualisation planifiée des données, ouvrez le tableau de bord avant le premier utilisateur réel de la journée. Déclenchez les combinaisons de filtres courantes — la plage de dates par défaut, les filtres de segments les plus utilisés. Looker Studio remplit le cache pour chaque graphique. Les 50 visiteurs suivants obtiennent des réponses depuis le cache.
Vous pouvez automatiser cela avec un script de navigateur sans interface ou un équivalent de curl qui accède à l’URL du rapport. L’automatisation n’a pas besoin de faire quoi que ce soit avec le résultat ; elle doit simplement déclencher les requêtes pour que le cache soit alimenté. Planifiez son exécution 5 à 10 minutes après la fin de votre pipeline BigQuery.
Une version plus sophistiquée : identifiez les 5 à 10 combinaisons de filtres qui représentent 80 % de l’utilisation du tableau de bord (vérifiez INFORMATION_SCHEMA.JOBS pour les patterns de requêtes), et préchauffez spécifiquement ces combinaisons.
Configuration de la durée du cache
La fraîcheur des données est configurable par source de données dans Looker Studio. Accessible via les paramètres de la source de données :
- 12 heures (par défaut) : adapté aux données mises à jour quotidiennement. Équilibre fraîcheur et réduction des requêtes.
- 1 heure : utile quand les données sont mises à jour plusieurs fois par jour et que les visiteurs attendent des données du jour même.
- 1 minute : quasi temps réel, mais désactive essentiellement le cache pour la plupart des cas d’usage. Chaque visiteur déclenchera des requêtes.
- Intervalles personnalisés : à définir en alignement avec votre planification de pipeline. Si votre pipeline dbt tourne à 6h et 18h, une fenêtre de fraîcheur de 12 heures garantit que les visiteurs voient toujours les données de la dernière exécution terminée.
Définissez la fenêtre de fraîcheur sur la durée d’obsolescence acceptable la plus longue pour chaque source de données. Pour un tableau de bord KPI affichant les ventes de la veille, 24 heures convient. Pour un tableau de bord de monitoring opérationnel, 1 heure ou moins est logique. Des paramètres de fraîcheur mal calibrés (une actualisation horaire sur des données mises à jour quotidiennement) gaspillent simplement des requêtes à vérifier une fraîcheur qui n’existe pas.
Interaction du cache avec BI Engine
Le cache de résultats de Looker Studio et BI Engine servent des objectifs différents et fonctionnent ensemble plutôt qu’en concurrence :
- Cache Looker Studio : stocke les résultats des requêtes. Retourne des résultats identiques pour des requêtes identiques sans toucher BigQuery.
- BI Engine : accélère les requêtes qui atteignent BigQuery. Les traite depuis des données en mémoire plutôt que depuis le stockage.
Un succès de cache dans Looker Studio est préférable à un succès de BI Engine, car le succès de cache n’exécute aucune requête BigQuery. Mais pour les échecs de cache — nouvelles combinaisons de filtres, premiers chargements après actualisation, scénarios avec identifiants du visiteur — BI Engine garantit que la requête qui s’exécute se termine en millisecondes plutôt qu’en secondes.
Les deux couches sont complémentaires. Optimisez le comportement du cache de Looker Studio (plages de dates fixes, fenêtres de fraîcheur appropriées, identifiants du propriétaire là où c’est possible) pour réduire le volume total de requêtes. Activez BI Engine pour minimiser la latence et le coût des requêtes qui atteignent effectivement BigQuery.