Qu’est-ce que BigQuery ?
BigQuery est l’entrepôt de données de Google Cloud. On y charge de gros volumes, on les interroge en SQL, et Google prend en charge la machinerie : pas de serveur à dimensionner, pas de cluster à redémarrer.
Sa particularité tient à la séparation du stockage et du calcul. Les données restent dans un stockage en colonnes répliqué, et la puissance de calcul est mobilisée le temps de la requête avant d’être relâchée. C’est ce qui permet de balayer plusieurs téraoctets en quelques secondes sans payer une infrastructure à l’arrêt le reste du temps.
À quoi sert BigQuery ?
BigQuery sert à répondre à des questions sur des volumes qu’un tableur ou une base transactionnelle ne peuvent pas absorber.
- Réunir dans un même endroit interrogeable les données du site web, du CRM, des campagnes publicitaires et de l’ERP.
- Alimenter des tableaux de bord Looker Studio, Power BI ou Tableau.
- Analyser le détail du comportement produit : BigQuery est la destination de l’export brut de Google Analytics 4, qui donne accès à un niveau de granularité que l’interface ne propose pas.
- Entraîner des modèles simples en SQL avec BigQuery ML, sans déplacer les données vers un autre outil.
Comment fonctionne BigQuery ?
Les tables sont regroupées dans des datasets, rattachés à un projet Google Cloud et à une région. Le stockage est organisé en colonnes : une requête ne lit que les colonnes citées, jamais la ligne entière.
Ce détail commande toute l’économie du service. Un SELECT * sur une table large coûte cher, la même requête réduite à trois colonnes coûte une fraction du prix.
Deux réglages réduisent encore le volume lu. Le partitionnement découpe une table par date, pour ne lire que la période demandée. Le clustering trie physiquement les données selon les colonnes les plus souvent filtrées.
BigQuery sait aussi interroger des données qui ne sont pas stockées chez lui, via des tables externes pointant vers Cloud Storage ou d’autres sources, et il accepte l’insertion en continu par l’API Storage Write.
Combien coûte BigQuery ?
Deux modèles coexistent. À la demande, la facture dépend du volume de données lu par les requêtes, pas du temps d’exécution. En capacité, on réserve des slots, les unités de calcul du service, pour un débit et une dépense prévisibles.
Le stockage est facturé séparément, avec un tarif réduit pour les tables dont le contenu n’a pas changé depuis 90 jours.
Un palier gratuit couvre le premier téraoctet interrogé chaque mois et une petite quantité de stockage. De quoi apprendre et prototyper, pas de quoi faire tourner une équipe analytique.
La mauvaise surprise classique reste la même : un tableau de bord qui rafraîchit toutes les cinq minutes une requête balayant une table entière. La correction passe par le partitionnement, les vues matérialisées et le cache de résultats, pas par une renégociation commerciale.
BigQuery, Snowflake ou Redshift : quelle différence ?
Les trois sont des entrepôts de données en colonnes destinés à l’analyse. Redshift appartient à AWS, Snowflake fonctionne sur les trois grands clouds, BigQuery reste attaché à Google Cloud.
Le mode de facturation les sépare davantage que la technologie. BigQuery à la demande facture les octets lus ; Snowflake et Redshift facturent surtout du temps de calcul provisionné. Selon que l’activité se compose de requêtes rares et lourdes ou de requêtes fréquentes et légères, l’un ou l’autre revient moins cher.
BigQuery n’est pas une base transactionnelle. PostgreSQL et MySQL encaissent des écritures unitaires nombreuses ; BigQuery est conçu pour lire beaucoup et écrire par lots. Employer l’un à la place de l’autre se paie dans les deux sens.
Exemples ou cas d’usage concrets
Un site e-commerce croise les événements de navigation exportés depuis Google Analytics 4, les commandes issues de sa base de production et le coût des campagnes publicitaires. Il obtient une marge par canal d’acquisition, calcul impossible dans les interfaces d’origine prises séparément.
Un éditeur de logiciel collecte les événements générés dans son application pour savoir quelles fonctionnalités sont réellement utilisées, et par quel type de compte. La feuille de route produit s’appuie sur ces chiffres plutôt que sur les demandes les plus bruyantes.
Une direction RH analyse les candidatures reçues sur l’année pour repérer les canaux qui alimentent réellement les recrutements aboutis, et non ceux qui génèrent le plus de volume.
Une équipe scientifique croise des jeux de données publics avec ses propres relevés sur plusieurs années. Les données publiques accessibles depuis BigQuery évitent de les rapatrier au préalable.
Quels profils travaillent sur BigQuery ?
BigQuery figure dans les offres de data analyst, d’analytics engineer et de data engineer, avec un niveau d’exigence très différent selon le poste.
- Data analyst : écrit les requêtes, construit les tableaux de bord, répond aux questions métier. SQL solide, moins de préoccupations d’infrastructure.
- Analytics engineer : modélise les tables exposées aux analystes, généralement avec dbt, et pose les conventions de nommage et de tests.
- Data engineer : gère l’ingestion, le partitionnement, l’orchestration avec Airflow et le coût des traitements.
- Growth ou marketing analyst : exploite l’export Google Analytics 4 et les données publicitaires, souvent sans passer par l’équipe data.
Le SQL reste le ticket d’entrée, et il ne suffit plus à départager les candidats. En entretien, ce qui distingue vraiment un profil confirmé tient à sa conscience du coût : savoir pourquoi une requête a lu 4 téraoctets, et comment la ramener à 40 gigaoctets.