Modèle de coûts BigQuery

Le modèle de coûts de BigQuery découle de son architecture : le stockage et le calcul sont séparés et facturés indépendamment. Le calcul domine (85-90 % des dépenses totales pour la plupart des équipes) ; le stockage représente généralement 10-15 %.

Les Deux Modèles de Tarification

BigQuery propose deux façons de payer le calcul :

On-Demand : Payer par Octet Scanné

La tarification on-demand facture 6,25 $/TiB de données scannées, avec le premier TiB gratuit mensuellement par compte de facturation. Vous avez accès à un pool partagé d’environ 2 000 slots (unités de calcul virtuelles), et BigQuery gère l’allocation automatiquement. Aucune planification de capacité requise.

Le mécanisme critique : vous payez pour les octets lus depuis le stockage, pas pour les octets retournés. Une requête qui scanne une table de 5 To et retourne 10 lignes coûte autant qu’une qui en retourne 10 millions. LIMIT 1000 ne réduit pas votre facture — BigQuery scanne le dataset complet avant d’appliquer la limite. C’est une conséquence directe du moteur de stockage en colonnes de BigQuery.

Editions : Payer par Slot-Heure

La tarification Editions (introduite en juillet 2023, remplaçant l’ancien tarif fixe) facture le temps de calcul plutôt que les données scannées. Un slot est un CPU virtuel avec des ressources mémoire et réseau. Vous configurez un baseline (minimum garanti, toujours facturé) et un maximum (limite supérieure pour l’autoscaling).

Trois niveaux existent :

L’autoscaling opère par incréments de 50 slots avec une fenêtre de facturation minimum de 60 secondes. Une requête utilisant 100 slots pendant 5 secondes est facturée pour 100 slot-minutes, pas 8,3 slot-secondes. Cela rend les Editions relativement coûteuses pour les workloads composés de nombreuses requêtes courtes. Règle pratique : appliquez un multiplicateur de 1,5x aux coûts théoriques en slot-heures pour estimer les dépenses réelles d’autoscaling.

Standard Edition ne dispose pas de BigQuery ML, BI Engine, création de vues matérialisées, et fonctionnalités de sécurité (CMEK, VPC-SC, sécurité au niveau lignes/colonnes). L’on-demand maintient la parité des fonctionnalités avec Enterprise Plus, sauf pour les requêtes continues et la reprise après sinistre gérée.

Le Seuil de Rentabilité Entre les Modèles

Le point de bascule dépend du volume et du profil du workload. 100 slots fonctionnant en continu sur Standard Edition PAYG coûtent 2 920 $/mois, équivalent à traiter 467 Tio en on-demand. Si vous traitez plus de 400-500 Tio mensuellement avec des patterns cohérents, les Editions économisent probablement de l’argent.

Mais les workloads en rafale changent radicalement le calcul. Traiter 20 Tio en moins d’une heure coûte 125 $ en on-demand contre environ 5 $ pour 100 slots Standard pendant une heure — 95 % d’économie.

La requête d’auto-évaluation à exécuter sur vos propres données :

WITH cost_analysis AS (
  SELECT
    DATE_TRUNC(creation_time, MONTH) AS month,
    SUM(total_bytes_billed) / POW(1024, 4) * 6.25 AS on_demand_cost,
    SUM(total_slot_ms) / 1000 / 3600 * 0.06 * 1.5 AS enterprise_cost
  FROM `region-us`.INFORMATION_SCHEMA.JOBS
  WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 90 DAY)
    AND job_type = 'QUERY'
    AND statement_type != 'SCRIPT'
  GROUP BY month
)
SELECT
  month,
  ROUND(on_demand_cost, 2) AS on_demand_usd,
  ROUND(enterprise_cost, 2) AS enterprise_usd,
  ROUND(enterprise_cost / NULLIF(on_demand_cost, 0) * 100, 1) AS editions_pct
FROM cost_analysis
ORDER BY month DESC;

Si editions_pct dépasse 75 %, restez en on-demand. En dessous de 50 %, les Editions méritent une évaluation sérieuse. Entre 50 et 75 % est une zone grise où les besoins de concurrence, la prévisibilité des coûts et les exigences de fonctionnalités devraient guider la décision.

Coûts de Calcul : Où Vivent 85-90 % de la Facture

À 6,25 $/Tio en on-demand, scanner 10 To quotidiennement coûte 1 875 $/mois en calcul. Ces mêmes 10 To stockés coûtent 200 $/mois. Une réduction de 50 % des octets scannés économise 937 $/mois ; une réduction de 50 % du stockage économise 100 $. La hiérarchie d’optimisation est claire.

Trois leviers contrôlent la grande majorité des coûts de calcul :

Sélection des colonnes. Le stockage en colonnes de BigQuery signifie que chaque colonne est stockée et lue séparément. Sélectionner 5 colonnes plutôt que 50 depuis une table large peut réduire les coûts de 90 %. SELECT * est l’un des patterns les plus coûteux dans BigQuery. Sur une table de 5 To avec 10 colonnes de taille égale, SELECT * coûte 31,25 $ tandis que SELECT col1, col2 coûte 6,25 $.

Élagage de partitions. Une table partitionnée avec des filtres appropriés réduit typiquement les octets scannés de 70 à 90 %. La même requête sur la même table peut coûter 17 fois plus selon la façon dont vous filtrez : WHERE event_date = '2024-01-15' ne scanne qu’une partition, tandis que WHERE DATE(event_timestamp) = '2024-01-15' applique une fonction à la colonne de partition, annulant complètement l’élagage. Utilisez require_partition_filter = true pour empêcher les scans accidentels de tables entières.

Clustering. Le clustering trie les données dans les partitions selon jusqu’à quatre colonnes, permettant l’élagage au niveau des blocs. Contrairement au partitionnement, les bénéfices du clustering n’apparaissent pas dans les estimations de dry-run — un dry run peut estimer 50 Go mais la requête réelle scanne 5 Go. L’ordre des colonnes compte : placez votre colonne la plus fréquemment filtrée en premier. L’étude de cas Shopify est instructive : ajouter du clustering sur les colonnes de filtre a réduit les scans de 75 Go à 508 Mo, une amélioration de 150x qui a évité 949 000 $/mois de coûts.

Coûts de Stockage : Moins Importants mais Valant l’Optimisation

Le stockage est disponible en deux modes de facturation :

Facturation logique (par défaut) : 0,02 $/Go/mois pour les données actives, 0,01 $/Go/mois pour le long terme (90+ jours sans modification). Le stockage de remontée dans le temps et de sécurité en cas d’échec est inclus gratuitement.

Facturation physique : 0,04 $/Go/mois pour les données compressées. La remontée dans le temps et la sécurité sont facturées séparément. La facturation physique gagne quand votre ratio de compression dépasse 2:1. Comme les données typiques se compressent 6 à 17 fois, la plupart des organisations économisent en passant. Interrogez INFORMATION_SCHEMA.TABLE_STORAGE pour vérifier vos ratios de compression réels avant de décider.

Les insertions en streaming coûtent 0,01 $ par 200 Mo avec un minimum de 1 Ko par ligne. Le chargement batch via le pool de slots partagé de BigQuery est entièrement gratuit. Pour une table recevant 10 Go quotidiennement, le streaming coûte 15 $/mois tandis que le chargement batch ne coûte rien. À moins d’avoir besoin d’une latence sous la minute, le batch gagne.

Les Erreurs Coûteuses

Double comptage des CTE. BigQuery ne matérialise pas les CTE non récursifs. Chaque référence réexécute le scan sous-jacent. Un CTE référencé deux fois dans la même requête coûte deux fois plus cher. Matérialisez les CTE coûteux dans des tables temporaires quand vous devez les référencer plusieurs fois.

Self-joins. La documentation de Google avertit que ceux-ci « peuvent mettre au carré le nombre de lignes de sortie ». Remplacez-les par des fonctions de fenêtre (LEAD, LAG, ROW_NUMBER) chaque fois que possible — elles accomplissent la plupart des cas d’usage des self-joins avec un seul scan de table.

max_bytes_billed manquant. Sans limites explicites, une seule requête malformée peut scanner des pétaoctets. Configurez cela dans le profiles.yml de dbt comme filet de sécurité :

prod:
  type: bigquery
  maximum_bytes_billed: 107374182400  # 100 Go

Les requêtes dépassant cette limite échouent avant de scanner, interceptant les modèles incrémentaux mal configurés qui exécutent accidentellement des rafraîchissements complets.

La Gouvernance comme Contrôle des Coûts

Pour les organisations avec des utilisateurs analytiques ad-hoc, les contrôles de gouvernance peuvent générer plus d’économies que les optimisations techniques. L’exemple propre de Google : 10 utilisateurs exécutant SELECT * dix fois par mois sur une table de 10 To génèrent plus de 5 000 $ en calcul mensuel en plus de 200 $ en stockage.

Quotas au niveau du projet : les nouveaux projets BigQuery sont soumis par défaut à un quota quotidien de 200 Tio depuis septembre 2025. Définissez des limites par utilisateur et par projet pour empêcher les analystes individuels de monopoliser le budget.

Vues autorisées : plutôt que d’accorder un accès direct aux tables (ce qui permet SELECT *), créez des vues n’exposant que les colonnes nécessaires. Les utilisateurs obtiennent les données dont ils ont besoin sans pouvoir scanner des tables larges entières.

Des comptes de service séparés par intégration (dbt, Looker, Fivetran) permettent l’attribution des coûts par système. Interrogez INFORMATION_SCHEMA.JOBS_BY_PROJECT par user_email pour identifier qui génère les dépenses. Souvent 3 à 5 requêtes ou comptes de service représentent plus de 70 % du calcul.

La Hiérarchie d’Optimisation

1. Patterns de requêtes (minutes à implémenter, impact 80 %+) : arrêtez SELECT *, filtrez toujours sur les colonnes de partition, clusterisez les tables de plus de 64 Mo
2. Modèles incrémentaux (heures, potentiel d’économies 70 %) : passez les grandes tables du rafraîchissement complet à l’incrémental, utilisez insert_overwrite avec copy_partitions: true sur BigQuery
3. Gouvernance (évite les factures surprises) : configurez max_bytes_billed, implémentez des quotas quotidiens, créez des vues autorisées
4. Modèle de tarification (20-40 % d’économies) : évaluez les Editions si vous traitez 400+ Tio mensuellement ou des workloads à forte composante de rafale
5. Stockage (10-30 % d’économies) : évaluez la facturation physique vs logique, définissez des politiques d’expiration sur les tables temporaires, laissez les remises long terme jouer automatiquement

Commencez par interroger INFORMATION_SCHEMA.JOBS_BY_PROJECT pour trouver vos 5 requêtes les plus coûteuses. Pour chacune, vérifiez : utilise-t-elle SELECT * ? Filtre-t-elle sur la colonne de partition ? La table est-elle clusterisée sur les colonnes des clauses WHERE ? Corriger ces trois problèmes sur vos requêtes principales capture probablement la majeure partie des économies disponibles.