Google BigQuery

BigQuery ne vous demande jamais de choisir une taille de machine. Il n’y a pas de grappe à démarrer, pas de serveur à éteindre le soir, pas de fenêtre de maintenance. Vous écrivez du SQL, la plateforme trouve les ressources.

Cette absence de bouton est confortable et trompeuse. Le curseur existe, il est simplement ailleurs : dans la quantité de données que chacune de vos requêtes va lire. Tout le reste en découle.

Le premier modèle facture à la demande, au volume de données traité par requête, avec une franchise mensuelle. Le second réserve de la capacité de calcul sous forme d’unités de traitement, avec une mise à l’échelle automatique et des engagements possibles à l’année. Le premier convient aux usages irréguliers, le second aux plateformes dont la charge est devenue prévisible. Beaucoup d’organisations restent à la demande bien après le point où la capacité réservée serait moins chère, faute d’avoir mesuré.

Dans le modèle à la demande, une seule règle compte, et elle surprend tout le monde : le stockage est en colonnes. Une requête ne lit que les colonnes qu’elle nomme. Écrire une étoile après le mot select revient donc à lire la table entière, y compris les cinquante colonnes dont vous n’aviez pas besoin. C’est la première correction que nous appliquons, et elle divise souvent la facture par plusieurs.

Le second levier est le partitionnement. Une table découpée par date ne lit que les partitions couvertes par le filtre. Une table de trois ans interrogée sur le mois courant lit un trente-sixième des données. On peut même exiger qu’aucune requête ne s’exécute sans filtre de partition, ce qui transforme une facture surprise en message d’erreur. C’est un réglage que nous activons systématiquement sur les grosses tables.

Le regroupement par colonne complète le dispositif à l’intérieur des partitions, sur les colonnes qui servent le plus souvent à filtrer.

Le risque propre au modèle à la demande est simple à énoncer : une seule requête maladroite sur une très grosse table peut coûter cher, immédiatement, sans que personne s’en aperçoive avant la facture. Trois protections existent et sont trop rarement en place.

L’estimation à blanc donne, avant exécution, le volume exact que la requête va lire. C’est gratuit et instantané. Un analyste qui prend l’habitude de regarder ce chiffre avant de lancer ne fait plus d’erreur coûteuse.

Le plafond de volume facturé se fixe requête par requête : au-delà, la requête échoue au lieu de coûter. C’est le garde-fou à mettre dans les outils et les scripts qui tournent sans surveillance.

Les quotas journaliers, enfin, se définissent par utilisateur ou par projet. Ils bornent le pire scénario, celui de la boucle qui relance une requête lourde toutes les minutes.

À cela s’ajoutent deux économies passives. Les résultats identiques sont servis depuis un cache sans être refacturés, et les données non modifiées pendant plusieurs mois basculent automatiquement vers un tarif de stockage réduit.

Beaucoup d’entreprises arrivent sur BigQuery sans l’avoir choisi, par la porte de Google Analytics : l’export brut des événements y atterrit nativement, et c’est le seul moyen d’accéder à la donnée non échantillonnée, non agrégée, avec un historique que l’interface ne conserve pas.

Deux choses à savoir avant de s’y lancer. La structure de ces tables est imbriquée, un événement contenant lui-même une liste de paramètres, ce qui demande une écriture SQL particulière que les équipes découvrent en général au premier essai. Et ces tables grossissent vite, une par jour, ce qui en fait le premier candidat aux mauvaises surprises de facturation si personne n’a filtré sur la date.

Bien traité, c’est un actif considérable : le comportement réel des visiteurs, réconciliable avec vos données de vente, sans les limites de l’interface d’analyse.

Quand la charge est irrégulière. Payer à la lecture est imbattable pour une plateforme sollicitée quelques heures par jour, là où un entrepôt à machines demande de décider d’une taille.

Quand vous êtes déjà chez Google, pour Analytics, la publicité ou le reste de la plateforme. Les données y arrivent sans travail d’intégration.

Et quand personne dans l’équipe ne veut administrer une infrastructure. C’est l’entrepôt qui demande le moins d’exploitation courante du marché.

Quand il vaut mieux autre chose

Si vos données et vos applications sont ailleurs, le transfert entre clouds a un coût et une latence qui pèsent vite dans la balance. Snowflake fonctionne sur les trois clouds, Fabric a sa place sur une organisation Microsoft.

Si votre usage consiste à modifier des lignes en permanence, ce n’est pas le terrain de l’outil : il est conçu pour ajouter et lire massivement, pas pour se substituer à une base transactionnelle.

Et pour de l’apprentissage automatique lourd sur des données non tabulaires, Databricks reste plus adapté, même si BigQuery sait entraîner des modèles directement en SQL.

Nous construisons le socle : organisation des projets et des jeux de données, partitionnement et regroupement des tables, droits d’accès, et les garde-fous de coût dès le premier jour plutôt qu’après la première facture.

Nous reprenons des plateformes existantes dont le coût est parti à la dérive. L’analyse des journaux d’exécution identifie en quelques heures les requêtes responsables, et le correctif tient le plus souvent en trois gestes : nommer les colonnes, partitionner, exiger le filtre.

Nous exploitons enfin l’export Google Analytics pour en faire autre chose qu’une réserve de données inertes : réconciliation avec les ventes, modèles de transformation avec dbt, restitution dans Power BI ou dans les outils Google.

Comment est facturé BigQuery ?

Deux modèles coexistent. Le premier facture à la demande, au volume de données traité par requête, avec une franchise mensuelle : il convient aux usages irréguliers. Le second réserve de la capacité de calcul sous forme d’unités de traitement, avec mise à l’échelle automatique et engagements possibles à l’année : il devient moins cher dès que la charge est prévisible. Beaucoup d’organisations restent à la demande longtemps après le point de bascule, faute d’avoir mesuré leur consommation réelle.

Pourquoi éviter SELECT * dans BigQuery ?

Parce que le stockage est en colonnes : une requête ne lit, et ne facture, que les colonnes qu’elle nomme. Écrire une étoile revient donc à lire la table entière, y compris les colonnes inutiles à l’analyse. Sur une table large, la différence de coût entre nommer trois colonnes et tout lire se compte en facteur, pas en pourcentage. C’est la première correction à appliquer sur une facture qui dérape.

Comment éviter une requête BigQuery très coûteuse ?

Trois protections existent. L’estimation à blanc donne gratuitement, avant exécution, le volume exact que la requête va lire. Le plafond de volume facturé se fixe par requête : au-delà, la requête échoue au lieu de coûter, ce qui est indispensable dans les scripts qui tournent sans surveillance. Les quotas journaliers par utilisateur ou par projet bornent enfin le pire scénario. À cela s’ajoute le partitionnement des tables, avec l’option d’exiger qu’aucune requête ne s’exécute sans filtre de partition.

Faut-il partitionner ses tables BigQuery ?

Oui, dès que la table grossit et qu’elle porte une date. Une table découpée par date ne lit que les partitions couvertes par le filtre : trois ans d’historique interrogés sur le mois courant représentent un trente-sixième des données lues, donc facturées. Le regroupement par colonne complète le dispositif à l’intérieur des partitions, sur les colonnes qui servent le plus souvent à filtrer.

Pourquoi exporter Google Analytics vers BigQuery ?

Parce que c’est le seul moyen d’accéder aux événements bruts, non échantillonnés et non agrégés, avec un historique que l’interface ne conserve pas. Deux points de vigilance : la structure des tables est imbriquée, un événement contenant lui-même une liste de paramètres, ce qui demande une écriture SQL particulière ; et ces tables, créées une par jour, grossissent vite, ce qui en fait le premier candidat aux mauvaises surprises de facturation si personne ne filtre sur la date.

• Snowflake, l’entrepôt à entrepôts virtuels, et son modèle de coût opposé.
• Snowflake ou Databricks, les critères qui tranchent entre les deux autres candidats.
• dbt, pour structurer et tester les transformations qui tournent dessus.
• Panorama des technologies sur lesquelles nous intervenons.

Sources — documentation officielle de l’éditeur, consultée le 22 août 2026 : tarification, tables partitionnées, estimation avant exécution.