Stratégies de facturation du stockage BigQuery

Le stockage représente 10 à 15 % d’une facture BigQuery typique. Après avoir traité les coûts de calcul — sélection des colonnes, partition pruning, clustering — la facturation du stockage offre des économies de 30 à 50 % via des changements de configuration ponctuels.

Facturation physique vs. logique

En juillet 2023, Google a introduit la facturation en octets physiques comme alternative à la facturation logique par défaut.

Facturation logique (par défaut) : vous payez pour la taille non compressée des données à 0,02 $/Go par mois. Le stockage time travel (7 jours) et le stockage fail-safe (7 jours) sont inclus gratuitement. Ce que vous voyez dans la console BigQuery comme “taille de table” est ce qui vous est facturé.

Facturation physique : vous payez pour les données compressées à 0,04 $/Go par mois. Le tarif par Go est 2x plus élevé, mais comme les données se compressent significativement, la facture totale est généralement bien plus basse. L’inconvénient : le stockage time travel et fail-safe apparaissent comme des postes séparés, facturés au même tarif de 0,04 $/Go.

Le calcul est simple. La facturation physique est gagnante lorsque votre taux de compression dépasse 2:1. Comme le format Capacitor de BigQuery compresse typiquement les données de 6 à 17x, la plupart des organisations réalisent des économies significatives en changeant. Une table de 100 Go logique peut représenter 10 Go physique — à 0,04 $/Go, cela fait 0,40 $/mois contre 2,00 $/mois avec la facturation logique.

Avant de changer, interrogez vos taux de compression réels :

SELECT
  table_schema,
  table_name,
  total_logical_bytes / POW(1024, 3) AS logical_gb,
  total_physical_bytes / POW(1024, 3) AS physical_gb,
  ROUND(total_logical_bytes / total_physical_bytes, 2) AS compression_ratio,
  -- Si ratio > 2, la facturation physique permet des économies
  CASE
    WHEN total_logical_bytes / total_physical_bytes > 2
    THEN 'Passer à la facturation physique'
    ELSE 'Garder la facturation logique'
  END AS recommendation
FROM `project.region-us`.INFORMATION_SCHEMA.TABLE_STORAGE
WHERE total_logical_bytes > 0
ORDER BY total_logical_bytes DESC;

Exécutez cette requête sur tous les datasets. Si la plupart des tables affichent des taux de compression supérieurs à 2:1, passez à la facturation physique au niveau du dataset.

Le compromis du time travel

Avec la facturation physique, le stockage time travel et fail-safe apparaissent comme des charges séparées. Pour les tables avec de nombreuses mises à jour — tables CDC recevant de nombreuses opérations MERGE, par exemple — chaque mise à jour crée une surcharge de time travel. Les versions originales des données sont conservées pendant 7 jours, et ces octets sont facturés à 0,04 $/Go.

Pour les tables en append (logs d’événements, données analytiques), cette surcharge est minimale. Pour les tables avec des taux de mise à jour élevés, le coût du time travel peut partiellement compenser les économies de compression. La requête INFORMATION_SCHEMA ci-dessus capture total_physical_bytes, qui inclut le stockage time travel, donc la comparaison est pertinente à condition de l’exécuter pendant les opérations normales.

Stockage longue durée : la remise gratuite de 50 %

BigQuery fait automatiquement passer les données au stockage longue durée après 90 jours consécutifs sans modification. Le prix passe de 0,02 $/Go à 0,01 $/Go avec la facturation logique — une remise de 50 % ne nécessitant aucune configuration, aucun effort, aucune modification de code.

Ce qui réinitialise le compteur de 90 jours :

• Toute opération DML (INSERT, UPDATE, DELETE, MERGE)
• Les insertions en streaming
• CREATE OR REPLACE TABLE

Ce qui ne réinitialise PAS le compteur :

• Interroger la table (les opérations de lecture sont gratuites à cet égard)
• Créer des vues sur la table
• Exporter des données
• Copier la table

Pour les tables partitionnées, chaque partition est évaluée indépendamment. Une table avec 365 partitions quotidiennes aura environ 275 partitions au tarif longue durée et environ 90 au tarif actif, en supposant que seules les données récentes reçoivent des écritures. C’est l’un des arguments les plus solides en faveur du partitionnement temporel : les partitions anciennes vieillissent naturellement vers un stockage moins cher.

L’insight clé : si vos modèles incrémentaux dbt utilisent insert_overwrite avec un lookback de 3 jours, seules les 3 partitions les plus récentes réinitialisent leur compteur à chaque exécution. Les 362 autres partitions continuent de vieillir vers la tarification longue durée. Les rafraîchissements complets de tables (CREATE OR REPLACE) réinitialisent chaque partition — une raison de plus de préférer les matérialisations incrémentales.

Expiration des tables : prévenir l’accumulation silencieuse

Les tables temporaires, les artefacts ETL, les tables de staging et les expériences de développement s’accumulent silencieusement. L’accumulation de stockage est courante dans les équipes sans politiques d’expiration. Un exemple : 3 000 $/mois pour des tables temporaires qui n’avaient pas été interrogées depuis des mois.

Définissez des valeurs par défaut au niveau du dataset pour les datasets de staging et de développement :

ALTER SCHEMA `project.staging`
SET OPTIONS (
  default_table_expiration_days = 7
);

Chaque nouvelle table créée dans ce dataset expire automatiquement après 7 jours sauf remplacement. C’est la politique unique la plus efficace pour prévenir l’accumulation de stockage dans les environnements hors production.

Remplacez au niveau de la table lorsque vous avez besoin d’une fenêtre de rétention spécifique :

CREATE TABLE `project.staging.temp_analysis`
OPTIONS (
  expiration_timestamp = TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 24 HOUR)
) AS
SELECT * FROM source_table WHERE condition;

Dans dbt, utilisez hours_to_expiration pour les modèles temporaires ou de staging qui n’ont pas besoin de persister :

{{ config(
    materialized='table',
    hours_to_expiration=168  -- 7 jours
) }}

C’est particulièrement utile pour les targets de développement dbt où chaque développeur crée des datasets personnels qui croissent indéfiniment sans politiques d’expiration.

La hiérarchie d’optimisation du stockage

L’optimisation du stockage se situe à la priorité 5 dans la hiérarchie globale d’optimisation des coûts — après les patterns de requêtes, les modèles incrémentaux, la gouvernance et la sélection du modèle de tarification. Le stockage représente 10 à 15 % de la facture BigQuery typique, donc une réduction de 50 % du stockage se traduit par 5 à 7,5 % de réduction des dépenses totales. L’effort est minimal :

1. Exécutez la requête de taux de compression sur tous les datasets (10 minutes)
2. Passez à la facturation physique où le taux de compression dépasse 2:1 (un ALTER SCHEMA par dataset)
3. Définissez des politiques d’expiration sur les datasets de staging et de développement (un ALTER SCHEMA par dataset)
4. Laissez le stockage longue durée fonctionner automatiquement — aucune action requise au-delà de préférer les matérialisations incrémentales aux full-refresh

Ce sont des changements ponctuels avec des économies permanentes.