Looker Studio propose deux modes de connexion pour BigQuery : les connexions en temps réel (requêtes en direct à chaque interaction) et le mode extract (un instantané statique interrogé localement). La plupart des rapports tirent parti de la combinaison des deux.
Connexions en temps réel
Une connexion en temps réel interroge BigQuery à chaque interaction. Lorsqu’un utilisateur ouvre le tableau de bord, Looker Studio lance une requête par graphique. Lorsqu’il modifie un filtre de date, tous les graphiques se rechargent avec de nouvelles requêtes. Les données sont toujours à jour.
Les coûts s’accumulent rapidement. Un tableau de bord de 10 graphiques consulté par 30 membres de l’équipe chaque matin représente 300 chargements de page, soit 3 000 requêtes BigQuery avant 9h. Si une seule requête de graphique analyse 10 Go, cela représente 30 000 Go traités avant midi. À 6,25 $ par To en facturation à la demande, les montants sont significatifs pour un tableau de bord que les équipes pensaient être « gratuit ».
Les connexions en temps réel sont le bon choix lorsque :
- La fraîcheur des données est essentielle (monitoring opérationnel, reporting quasi-temps réel)
- Les utilisateurs ont besoin d’explorer les détails avec des filtres arbitraires
- Les données sous-jacentes sont trop volumineuses ou variées pour le mode extract
Mode extract
Le mode extract crée un instantané statique stocké dans l’infrastructure de Google. Looker Studio exécute une requête pour extraire les données, les stocke, et toutes les interactions ultérieures interrogent l’extract stocké plutôt que BigQuery. Après l’extraction initiale, les interactions sont gratuites et quasi-instantanées.
L’économie s’inverse complètement. Au lieu de payer pour chaque interaction utilisateur, vous payez une fois par cycle de rafraîchissement. Un rapport rafraîchi quotidiennement génère une seule requête BigQuery par jour, indépendamment du nombre de personnes qui le consultent ou des combinaisons de filtres qu’elles explorent.
Les contraintes sont strictes :
- Limite stricte de 100 Mo par extract. Si votre requête retourne plus de 100 Mo de données, l’extraction échoue. Il n’y a pas d’extraction partielle ni de troncature automatique.
- Les planifications de rafraîchissement sont quotidiennes, hebdomadaires ou mensuelles. Aucune option horaire. Si vos données changent plus fréquemment que quotidiennement et que les utilisateurs ont besoin de données actuelles, le mode extract n’est pas adapté.
- Seules les dimensions et métriques présélectionnées sont disponibles. Les utilisateurs ne peuvent pas ajouter de nouveaux champs ni explorer au-delà de ce qui était inclus dans l’extract. Cela est souvent acceptable pour des tableaux de bord KPI fixes, mais cela bloque les cas d’usage exploratoires.
La limite de 100 Mo en pratique
La limite de 100 Mo est plus petite qu’elle ne le semble lorsque vous extrayez des données dimensionnelles. Une table avec 50 colonnes et 200 000 lignes de types de données mixtes peut facilement la dépasser. La solution de contournement consiste à pré-agréger avant d’extraire : au lieu d’extraire des données au niveau ligne, extrayez un résumé journalier qui tient confortablement sous la limite.
C’est une raison supplémentaire pour laquelle les tables pré-agrégées constituent le bon fondement pour les données de tableau de bord, quel que soit le mode de connexion. Avec une source correctement pré-agrégée, même une année de données journalières selon 5 à 10 dimensions tient généralement bien en dessous de 100 Mo.
Si vos données pré-agrégées dépassent réellement 100 Mo et que vous souhaitez tout de même bénéficier d’une économie similaire au mode extract, envisagez de configurer un cache agressif sur votre connexion en temps réel. Un cache de 12 heures sur un tableau de bord qui se rafraîchit chaque matin offre des caractéristiques de coût similaires à un extract, sans la contrainte de taille.
Combiner les deux dans un même rapport
L’approche pratique pour la plupart des rapports consiste à mixer les types de connexion :
Utilisez le mode extract pour :
- Les scorecards KPI affichant les performances du mois précédent
- Les graphiques de tendance qui se mettent à jour une fois par jour
- Tout graphique pour lequel les utilisateurs n’ont pas besoin de filtrer au-delà d’un ensemble fixe de dimensions
Utilisez les connexions en temps réel pour :
- Les tables dans lesquelles les utilisateurs explorent les détails au niveau ligne
- Tout graphique avec des interactions de filtres complexes
- Les données qui changent tout au long de la journée
Looker Studio supporte plusieurs sources de données dans un seul rapport. Un rapport peut avoir certains graphiques pointant vers un extract et d’autres vers une connexion BigQuery en temps réel. L’utilisateur ne perçoit pas la différence — il voit la même interface dans les deux cas.
Le compromis à anticiper : les graphiques issus de différentes sources de données ne peuvent pas partager des filtres automatiquement. Un contrôle de plage de dates sur un graphique extract ne filtrera pas un graphique en connexion en temps réel sauf si vous configurez explicitement le filtrage croisé. Planifiez l’architecture de votre rapport en conséquence.
Implications sur les coûts
Avec les connexions en temps réel, envisagez de définir un nombre maximal d’octets facturés dans la configuration de la connexion BigQuery. Looker Studio l’applique à chaque requête, de sorte qu’une exploration mal configurée qui analyserait une table multi-téraoctets complète échoue avec une erreur plutôt que de générer une facture surprise.
La table INFORMATION_SCHEMA.JOBS vous permet de suivre spécifiquement la contribution de Looker Studio à vos dépenses BigQuery, puisque Looker Studio étiquette ses requêtes avec un label requestor: looker_studio. Si vous observez des coûts inattendus, exécutez :
SELECT user_email, COUNT(*) AS query_count, SUM(total_bytes_processed) / POW(1024, 4) AS total_tb_processedFROM `region-us`.INFORMATION_SCHEMA.JOBSWHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) AND ( SELECT l.value FROM UNNEST(labels) l WHERE l.key = 'requestor' ) = 'looker_studio'GROUP BY 1ORDER BY total_tb_processed DESC;Cela vous indique quels propriétaires de rapports (identifiés par leur email de connexion) génèrent le plus de dépenses BigQuery depuis Looker Studio. En général, un ou deux rapports représentent la majorité des coûts — et ils sont presque toujours candidats au mode extract ou à la pré-agrégation.