ServicesÀ proposNotesContact Me contacter →
EN FR
Note

Looker Studio + BigQuery Performance — Hub

Carte des notes de jardin sur l'optimisation des dashboards Looker Studio alimentés par BigQuery : BI Engine, mode extract, pièges du blending, mise en cache, identifiants et décisions de mise à niveau.

Planté
bigqueryanalyticscost optimization

Chaque graphique dans un dashboard Looker Studio génère sa propre requête BigQuery. Une page avec 10 graphiques et un filtre de date déclenche 10 requêtes au chargement ; les 10 se réexécutent lors des changements de filtre. Les problèmes de performance et de coûts dans Looker Studio sont généralement traités dans la couche BigQuery, pas dans la configuration Looker Studio.

Le modèle à deux couches

L’optimisation des performances opère sur deux couches qui interagissent :

  1. Couche BigQuery : Comment les données sont structurées, partitionnées, matérialisées et accédées
  2. Couche Looker Studio : Mode de connexion, mise en cache, paramètres d’identifiants, nombre de graphiques et blending

La plupart des efforts d’optimisation doivent aller dans la couche BigQuery. Une table pré-agrégée bien structurée avec BI Engine activé a plus d’impact que n’importe quelle configuration Looker Studio.

Techniques d’optimisation

Infrastructure

  • BigQuery BI Engine : 1 Go gratuit d’accélération en mémoire pour les requêtes compatibles. Looker Studio le récupère automatiquement. Repli silencieux sur la tarification à la demande quand la capacité est dépassée — vérifiez INFORMATION_SCHEMA.JOBS pour confirmer qu’il fonctionne réellement.

  • Partitionnement et clustering : Partitionnez les tables par la colonne de date utilisée dans le filtre de plage de dates du dashboard. Définissez « Utiliser [champ] comme dimension de plage de dates » dans Looker Studio pour mapper le contrôle de date directement sur la colonne de partition. Activez require_partition_filter pour éviter les scans complets de table accidentels. Regroupez par les colonnes les plus fréquemment utilisées comme filtres.

  • Vues matérialisées : Mise en cache des agrégations précalculées que BigQuery rafraîchit incrémentialement. Utile pour les agrégations exécutées à plusieurs reprises par plusieurs dashboards. Si vous utilisez BI Engine, ajoutez à la fois la vue matérialisée et ses tables de base à la liste des tables préférées.

Mode de connexion

  • Extract vs. connexion live : Le mode extract crée un instantané statique avec des interactions gratuites après la requête initiale, mais a une limite stricte de 100 Mo et des planifications de rafraîchissement uniquement quotidien/hebdomadaire/mensuel. Les connexions live sont en temps réel mais coûtent de l’argent à chaque interaction. La plupart des rapports bénéficient de la combinaison des deux : extract pour les tableaux de bord KPI stables, live pour les tables de détail exploratoires.

Éviter les pièges

  • Pièges du blending de données : Les sources blendées interrogent BigQuery séparément et se joignent côté client. Des clés de jointure manquantes ou incorrectes créent silencieusement des produits cartésiens. L’erreur « This chart requested too much data » est le signe révélateur. Pré-joignez les données dans BigQuery en utilisant SQL plutôt que le blending dans Looker Studio autant que possible.

  • Gestion des dates : WHERE DATE(timestamp_col) = '2026-01-01' force un scan complet car BigQuery ne peut pas pousser la fonction vers la partition. Utilisez des colonnes de type DATE et filtrez directement sur la colonne sans la envelopper dans une fonction.

  • Champs calculés : Poussez les regex lourds, les instructions CASE complexes et les transformations de date vers les vues BigQuery ou les modèles dbt. Les champs calculés Looker Studio devraient être limités aux ratios simples et au formatage d’affichage. Les champs calculés complexes sur de grands datasets atteignent le timeout de requête de 6 minutes.

  • Nombre de tuiles du dashboard : Chaque graphique génère au moins une requête. Limitez les pages à 10-15 widgets. Répartissez le contenu sur plusieurs pages (seule la page active se charge). Combinez les tableaux de bord en tables uniques autant que possible. Désactivez le cross-filtering sur les graphiques qui n’en bénéficient pas.

Mise en cache et contrôle des coûts

  • Mécanismes de mise en cache : Chaque graphique a son propre cache indexé sur les dimensions, métriques, plage de dates et filtres. « Les 30 derniers jours » génère une nouvelle requête chaque jour (les limites de dates se déplacent). « Ce mois » conserve son cache pendant tout le mois. Définissez la fraîcheur des données à la durée de stale la plus longue acceptable pour votre cas d’utilisation.

  • Suivi des coûts : Looker Studio étiquette ses requêtes avec requestor: looker_studio. Interrogez INFORMATION_SCHEMA.JOBS pour suivre les dépenses par propriétaire de rapport et identifier les rapports coûteux à optimiser.

SELECT
  user_email,
  COUNT(*) AS query_count,
  SUM(total_bytes_processed) / POW(1024, 4) AS total_tb_processed,
  SUM(total_bytes_processed) / POW(1024, 4) * 6.25 AS estimated_cost_usd
FROM `region-us`.INFORMATION_SCHEMA.JOBS
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND (
    SELECT l.value
    FROM UNNEST(labels) l
    WHERE l.key = 'requestor'
  ) = 'looker_studio'
GROUP BY 1
ORDER BY estimated_cost_usd DESC;
  • Octets maximum facturés : Configuré dans les paramètres de connexion BigQuery. Les requêtes qui dépasseraient la limite échouent sans frais — un garde-fou utile contre les requêtes de dashboard incontrôlées.

Sécurité et identifiants

  • Identifiants et sécurité : Les identifiants du propriétaire partagent un seul cache entre tous les viewers (efficace, coût réduit) mais expose les données à tous les viewers y compris les audiences publiques. La vulnérabilité LeakyLooker (Tenable, mars 2026) a démontré une exfiltration de données sans clic via des rapports publics utilisant les identifiants du propriétaire. Utilisez des comptes de service dédiés pour les dashboards de production plutôt que des comptes personnels. Utilisez les identifiants du viewer pour les données sensibles ou quand un filtrage au niveau des lignes par identité du viewer est requis.

Quand l’optimisation n’est pas suffisante

Looker Studio a des limites strictes qu’aucune optimisation ne peut contourner : un timeout de requête de 6 minutes, une limite d’extract de 100 Mo, une limite de visualisation de 5 000 lignes par graphique, 5 sources de données par blend, et une dégradation des performances au-delà de 25 tuiles. Il manque aussi une couche sémantique et une sécurité native au niveau des lignes.

Looker Studio Pro (9 $/utilisateur/projet/mois) ajoute la propriété organisationnelle et l’intégration IAM mais fait tourner le même moteur de requête avec les mêmes limites.

Voir Limites Looker Studio et la voie de mise à niveau pour savoir quand évaluer Looker Enterprise, Lightdash, Metabase ou d’autres alternatives — et le framework de sélection d’outils BI pour comment prendre cette décision.