ServicesÀ proposNotesContact Me contacter →
EN FR
Note

BigQuery BI Engine

Comment BigQuery BI Engine fournit une accélération en mémoire pour les requêtes de dashboards, ce qu'il prend en charge, ce qu'il ignore silencieusement, et comment vérifier qu'il fonctionne réellement.

Planté
bigquerygcpcost optimizationanalytics

BigQuery BI Engine est un service d’analyse en mémoire qui met en cache les données fréquemment consultées dans la RAM. Chaque projet BigQuery bénéficie de 1 Go de capacité gratuitement. Quand une requête compatible arrive, BI Engine la traite depuis le cache en temps sous-seconde plutôt que de lire depuis le stockage. Pour les workloads de dashboards où les mêmes données sous-jacentes sont interrogées avec des filtres légèrement différents tout au long de la journée, cela réduit significativement la latence des requêtes.

Ce que BI Engine Fait Réellement

Les requêtes BigQuery ordinaires lisent depuis Colossus (stockage distribué), mélangent les données via Dremel, et retournent les résultats. L’aller-retour vers le stockage est rapide, mais pas au niveau de la RAM. BI Engine intercepte les requêtes compatibles avant qu’elles n’atteignent la couche de stockage et sert les résultats directement depuis un cache en mémoire dans la même région que vos données.

Le résultat est une latence mesurée en millisecondes plutôt qu’en secondes, et zéro octet traité contre votre quota on-demand pour les requêtes servies depuis le cache.

La capacité payante coûte environ 30 $/mois par Go, jusqu’à un maximum de 250 Go. Pour situer les choses : une table pré-agrégée bien conçue alimentant un dashboard pour 50 personnes peut tenir confortablement dans 2 à 5 Go de capacité BI Engine. L’économie est favorable comparée aux coûts de calcul de ces mêmes requêtes s’exécutant à répétition sur des données brutes.

Configurer une Réservation

Activez-le via Cloud Console :

  1. Aller dans BigQuery > BI Engine
  2. Créer une réservation dans le même projet et la même région que vos données
  3. Définir la capacité en Go
  4. Éventuellement spécifier les tables préférées

Looker Studio, Connected Sheets et les autres outils Google le prennent en charge automatiquement dès qu’une réservation existe. Pas de modification de code côté client requise.

Le paramètre de tables préférées indique à BI Engine quelles tables prioriser lors de la mise en cache quand la mémoire est limitée. Si vous disposez de 5 Go de capacité mais que 20 Go de données sont utilisées par les dashboards, les tables préférées garantissent que les données les plus importantes restent « chaudes ».

Ce que BI Engine Prend en Charge (et Ce qu’il Ne Prend Pas)

BI Engine est sélectif sur ce qu’il accélère. Il fonctionne mieux avec :

  • Les tables plates pré-jointes et pré-agrégées
  • Les agrégations SQL standard (SUM, COUNT, AVG, MIN, MAX)
  • Les jointures INNER et LEFT OUTER avec une grande table de faits joignant jusqu’à 4 tables de dimensions plus petites
  • Les requêtes sur des tables BigQuery natives

Il ne prend pas en charge :

  • Les tables avec caractères génériques (le pattern _TABLE_SUFFIX courant dans les exports bruts GA4)
  • Les tables externes (BigLake, Bigtable, Cloud Storage)
  • Les politiques de sécurité au niveau des lignes
  • Les colonnes JSON
  • Les UDF non-SQL
  • Les requêtes couvrant plus de 4 tables jointes côté dimension

L’implication pratique : BI Engine récompense les mêmes choix de conception de tables que les vues matérialisées et le partitionnement récompensent. Une table plate pré-agrégée dans un dataset BigQuery natif est la cible idéale. Une requête qui joint 6 tables dont une CSV externe n’obtiendra aucun bénéfice BI Engine.

Le Problème du Fallback Silencieux

C’est ce qui surprend la plupart des équipes : quand la capacité de la réservation BI Engine est dépassée, les requêtes reviennent silencieusement à la tarification BigQuery on-demand ordinaire. Pas d’erreur. Pas de file d’attente. La requête s’exécute, le résultat revient, et la seule différence est qu’elle a coûté de l’argent et pris plus de temps.

Cela signifie que si vos dashboards deviennent subitement lents malgré l’activation de BI Engine, vous avez probablement dépassé votre capacité de réservation. La réservation s’est remplie et tout est retombé vers l’on-demand.

Vous pouvez vérifier si l’accélération s’est réellement déclenchée en interrogeant INFORMATION_SCHEMA.JOBS :

SELECT
  job_id,
  creation_time,
  bi_reservation_usage,
  CASE
    WHEN bi_reservation_usage.slot_ms > 0 THEN 'ACCELERATED'
    ELSE 'NOT_ACCELERATED'
  END AS bi_engine_status
FROM `region-us`.INFORMATION_SCHEMA.JOBS
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  AND job_type = 'QUERY'
ORDER BY creation_time DESC
LIMIT 50;

La vérification plus précise utilise le champ bi_engine_statistics de INFORMATION_SCHEMA.JOBS, qui affiche le mode d’accélération comme FULL, PARTIAL ou DISABLED. PARTIAL signifie que BI Engine a géré une partie de la requête mais est retombé sur l’exécution ordinaire pour le reste — généralement parce qu’une partie de la requête utilise des fonctionnalités non prises en charge.

BI Engine vs Cache Ordinaire

Looker Studio dispose de sa propre couche de cache intégrée qui stocke les résultats de requêtes jusqu’à 12 heures. BI Engine est différent : il met en cache les données en mémoire, pas les résultats. Cette distinction compte parce que :

  • Le cache Looker Studio retourne des résultats identiques pour des requêtes identiques — mêmes dimensions, mêmes filtres, même plage de dates
  • BI Engine accélère n’importe quelle requête compatible sur les données mises en cache, y compris les requêtes avec des valeurs de filtre différentes

Si quelqu’un ouvre un dashboard filtré sur la France et quelqu’un d’autre l’ouvre filtré sur l’Allemagne, le cache de résultats Looker Studio n’aide pas la deuxième personne (filtre différent = cache miss). BI Engine aide les deux, parce que les données de la table sous-jacente sont en mémoire et les deux requêtes de filtre s’exécutent rapidement.

En pratique, vous voulez les deux : BI Engine pour l’accélération et le cache de résultats Looker Studio pour éviter d’exécuter une même requête deux fois pour le même résultat.

Interaction avec les Vues Matérialisées

Si vous utilisez les vues matérialisées comme couches de pré-agrégation pour les dashboards, BI Engine peut accélérer à la fois les requêtes sur les vues matérialisées et les tables de base. Cependant : si votre configuration utilise des tables préférées, vous devez ajouter à la fois la vue matérialisée et ses tables de base à la liste des tables préférées. BI Engine ne découvrira pas automatiquement la relation entre une VM et ses tables de base pour les fins de mise en cache.

Quand BI Engine Est Pertinent

Le calcul de ROI est direct. BI Engine est pertinent quand :

  1. Le volume de requêtes de dashboards est élevé : une équipe de 20 personnes ouvrant le même dashboard 5 fois par jour génère 100+ exécutions de requêtes par page de dashboard, par jour. BI Engine sert la plupart d’entre elles depuis la mémoire.
  2. Les patterns de requêtes sont répétitifs : mêmes tables, mêmes agrégations, valeurs de filtre différentes. C’est le pattern canonique des dashboards.
  3. Les tables tiennent dans la mémoire disponible : une table pré-agrégée avec une ligne par jour par segment est minuscule. La faire tenir dans 1 à 2 Go de capacité BI Engine est trivial.
  4. Vous utilisez déjà des tables pré-agrégées : BI Engine et la pré-agrégation sont multiplicatifs, pas redondants. La pré-agrégation réduit le volume de données ; BI Engine sert le dataset plus petit depuis la RAM.

BI Engine est moins utile pour : les requêtes exploratoires sur de grandes tables brutes, le SQL ad-hoc avec des patterns imprévisibles, ou les workloads dominés par des tables externes et des UDF que BI Engine ne peut pas accélérer.

Le niveau gratuit de 1 Go couvre l’accélération de dashboards de base pour la plupart des petites équipes sans coût supplémentaire.