L’Architecture Fondamentale : Séparation du Stockage et du Calcul
L’innovation distinctive de BigQuery est la séparation complète entre l’endroit où vos données résident et l’endroit où les requêtes s’exécutent. Vos tables vivent dans Colossus, le système de fichiers distribué de Google, stockées dans un format en colonnes appelé Capacitor. Vos requêtes s’exécutent séparément via Dremel, un moteur de requêtes distribué qui parallélise le travail sur des milliers de processeurs virtuels. Le réseau Jupiter (6+ petabits/seconde de bande passante) les connecte. Cela importe parce que cela signifie que les coûts de stockage et de calcul sont indépendants. Une table massive interrogée une fois coûte bien moins qu’une petite table interrogée en permanence.
Contrairement aux data warehouses traditionnels (Snowflake, Redshift) où vous provisionnez et gérez des ressources, BigQuery alloue automatiquement des unités de calcul virtuelles appelées slots selon la complexité des requêtes. Les clients on-demand ont accès à jusqu’à 2 000 slots partagés. Pour les workloads prévisibles, vous réservez des slots dédiés.
Pourquoi le Stockage en Colonnes Change Tout
Capacitor stocke chaque colonne séparément sur disque. Quand vous exécutez SELECT user_id, event_date FROM events, BigQuery ne lit que ces deux colonnes. Les 47 autres colonnes ? Jamais touchées. Jamais facturées.
BigQuery facture pour les données scannées, pas pour les données retournées.
Cela rend SELECT * catastrophiquement coûteux. Une table avec 100 colonnes coûte environ 100 fois plus à scanner entièrement que de sélectionner une seule colonne. Ajouter LIMIT 1000 ne réduit pas les coûts — BigQuery scanne quand même le dataset entier avant d’appliquer la limite. Ce modèle en colonnes explique pourquoi le partitionnement et le clustering fonctionnent si bien : ils permettent à BigQuery d’ignorer complètement la lecture de colonnes et de blocs.
Les implications de coût sont immédiates et concrètes. La différence entre une requête qui sélectionne explicitement 5 colonnes et un scan de la totalité des 87 colonnes d’un modèle de base représente une réduction de coût de 94 %. Pour les équipes exécutant des jobs dbt quotidiens, cela se traduit par des milliers d’euros d’économies mensuelles.
Calcul : Slots et Ordonnancement Équitable
Un slot BigQuery est une unité de calcul virtuelle combinant CPU, mémoire et capacité réseau. Quand vous soumettez une requête, BigQuery la décompose en étapes, divise ces étapes en unités de travail parallèles, et alloue des slots pour les exécuter. Les requêtes complexes utilisent plus de slots. La haute concurrence (de nombreuses requêtes s’exécutant simultanément) nécessite plus de slots. Quand la demande dépasse la capacité en slots, les requêtes font la queue et ralentissent.
La tarification on-demand vous donne accès à un pool partagé d’environ 2 000 slots globalement. La tarification par capacité (BigQuery Editions) vous permet de réserver des slots dédiés. La différence clé : l’on-demand a des performances variables aux heures de pointe ; les slots réservés garantissent la capacité.
L’ordonnancement équitable est la façon dont BigQuery distribue les slots quand plusieurs requêtes sont en compétition. Il divise les slots équitablement entre les projets en premier, puis entre les jobs au sein de chaque projet. Cela a des implications architecturales : si vous exécutez dbt en production et des requêtes ad-hoc d’analystes dans le même projet, ils se disputent le même pool de slots. Séparez-les dans différents projets affectés à différentes réservations, et ils sont isolés.
Le Modèle de Coûts
Votre facture BigQuery provient de trois catégories :
- Calcul (85-90 % des dépenses) : octets scannés par requête, facturés à 6,25 $/TiB
- Stockage (10-15 % des dépenses) : données stockées, facturées à 0,02 $/Go/mois pour le stockage actif
- Insertions en streaming (généralement négligeables) : 0,01 $ par 200 Mo
Comme les octets scannés dominent la facture, la hiérarchie d’optimisation est claire. Réduire la taille de scan de 50 % économise bien plus que réduire le stockage de 50 %. Le partitionnement et le clustering réduisent directement la taille de scan en aidant BigQuery à ignorer les blocs de données non pertinents. Sélectionner des colonnes spécifiques plutôt que SELECT * réduit la taille de scan. Les modèles incrémentaux plutôt que les rafraîchissements complets réduisent la taille de scan.
Cela signifie également que vos choix de conception de tables ont des conséquences immédiates sur les coûts. Les tables larges dénormalisées avec de nombreuses colonnes ne sont pas intrinsèquement mauvaises — mais les scanner sans discernement devient rapidement coûteux. Un seul analyste exécutant des requêtes SELECT * non filtrées sur une table de 10 To peut générer une facture de 5 000 $/mois rien que pour les travaux ad-hoc.
Le Stockage Est Séparé du Calcul pour une Raison
Parce que le stockage et le calcul sont indépendants, vous pouvez les optimiser séparément. Une table de 100 Go stockée pendant un an coûte 240 $ annuellement en stockage (0,02 $/Go/mois). Si cette table est interrogée une fois, le coût de calcul dépend entièrement du nombre de colonnes sélectionnées et du fait que la table soit partitionnée/clusterisée. Si vous sélectionnez une seule colonne sans partitionnement, vous pourriez scanner toute la table (20-50 Go selon la compression). Avec partitionnement et clustering, vous pourriez ne scanner que 100 Mo.
La même table peut coûter 0,60 $ en calcul (requête optimisée) ou 375 $ (requête non optimisée). Le coût de stockage ne change jamais.
Le stockage long terme ajoute une autre couche. Les données passent automatiquement à la tarification long terme après 90 jours consécutifs sans modification, tombant à 0,01 $/Go/mois : une réduction de 50 % ne nécessitant aucun effort. Pour les tables d’archivage, c’est une économie gratuite.
Datasets et Régions : Des Décisions Permanentes
Les datasets sont les conteneurs logiques de BigQuery. Ils n’apparaissent pas dans la hiérarchie GCP standard mais constituent l’unité principale pour le contrôle d’accès. Chaque table hérite des permissions de son dataset parent. Plus important encore, la localisation est définie à la création du dataset et ne peut pas être modifiée par la suite. Un dataset créé dans US reste dans US pour toujours. Le déplacer nécessite d’exporter les données, créer un nouveau dataset dans la bonne région, recharger tout, et mettre à jour toutes les références.
Cette immutabilité crée la « catastrophe du mélange de régions » : un seul dataset mal placé bloque les jointures inter-régions et corrompt l’intégralité de votre pipeline de requêtes. BigQuery n’autorise pas les jointures entre régions. La règle est absolue : tous les datasets joints dans une seule requête doivent se trouver au même endroit. Choisissez votre région une fois, documentez-la bien en évidence, appliquez-la dans les revues de code.
La Frontière de Projet et l’Isolation des Quotas
Les projets forment l’unité organisationnelle fondamentale. Chaque projet a son propre compte de facturation, ses propres quotas, et ses propres allocations de slots. La tarification on-demand donne à chaque projet accès à jusqu’à 2 000 slots concurrents, avec 20 000 partagés dans une organisation.
Cette frontière est architecturale, pas cosmétique. Elle permet des patterns puissants : une équipe data centrale gère les données brutes dans un projet ; les équipes de département interrogent ces données depuis leurs propres projets, avec les coûts de calcul imputés à leurs budgets. Elle empêche une requête de développement incontrôlée de priver les dashboards de production de ressources (ils sont dans des projets différents avec des quotas différents).
Pour la même raison, séparer dev et prod dans différents projets est une bonne pratique pour les équipes avec plusieurs personnes. Un projet partagé signifie que les travaux de développement ad-hoc sont en compétition avec les pipelines de production pour le même pool de slots.
Notes Associées
Voir BigQuery Partitioning vs Clustering Decision Framework, Slots et réservations BigQuery, et Modèle de coûts BigQuery pour une couverture plus approfondie des composants architecturaux spécifiques.