Tiering de Cloud Storage pour BigQuery

L’optimisation des coûts de stockage pour un data lake BigQuery implique trois dimensions en interaction : le tiering par fréquence d’accès, la facturation physique vs logique, et la sélection du modèle de tarification. La bonne combinaison peut réduire les coûts de 3 à 5 fois par rapport aux configurations par défaut.

Niveaux de stockage par fréquence d’accès

Cloud Storage propose quatre niveaux avec des coûts décroissants mais des pénalités de récupération croissantes. Le bon niveau dépend de la fréquence à laquelle les données sont interrogées, pas de leur importance.

Pour les tables BigLake adossées à Cloud Storage, le niveau affecte directement les coûts de stockage et de requête. Une requête BigLake sur des données Coldline paye les frais de récupération en plus des coûts de calcul BigQuery. Cela fait du choix de niveau une décision d’optimisation des coûts qui affecte votre facture BigQuery, pas seulement votre facture Cloud Storage.

Correspondance entre niveaux et ancienneté des données

Une stratégie de tiering pratique segmente les données par fréquence d’accès, qui correspond généralement à l’ancienneté :

Données chaudes (0-90 jours) : stockez dans des tables BigQuery natives ou des tables BigLake Iceberg sur Cloud Storage de classe Standard. Il s’agit de votre fenêtre analytique active — les tableaux de bord, les requêtes ad-hoc et les transformations dbt accèdent régulièrement à ces données. Le coût du stockage Standard est justifié par l’absence de frais de récupération.

Données tièdes (90 jours à 1 an) : migrez vers des tables BigLake sur Cloud Storage Nearline. Ces données sont interrogées occasionnellement — revues trimestrielles, comparaisons année sur année, investigation d’incidents spécifiques. L’économie de 50 % sur le stockage compense largement les faibles frais de récupération pour des requêtes peu fréquentes.

Données froides (1+ an) : tables BigLake sur Coldline, interrogées uniquement en cas de besoin. L’analyse historique, les audits réglementaires et les requêtes de conformité accèdent à ce niveau. À 0,004 $/Go/mois, stocker un téraoctet coûte 4 $/mois — pratiquement gratuit comparé au maintien en stockage Standard à 20 $/mois.

Archive (conformité uniquement) : données dont la conservation est légalement requise mais que vous ne prévoyez jamais d’interroger. Le stockage Archive à 0,0012 $/Go/mois avec des frais de récupération de 0,05 $/Go. À réserver au vrai stockage froid où la durée minimale de 365 jours et les frais de récupération élevés sont acceptables.

Politiques de cycle de vie

Les politiques de cycle de vie Cloud Storage automatisent les transitions entre niveaux. Vous définissez des règles, et Google déplace les objets automatiquement. Cela élimine la nécessité de gérer manuellement les données ou d’écrire des scripts de migration planifiés.

{
  "lifecycle": {
    "rule": [
      {
        "action": { "type": "SetStorageClass", "storageClass": "NEARLINE" },
        "condition": { "age": 30, "matchesStorageClass": ["STANDARD"] }
      },
      {
        "action": { "type": "SetStorageClass", "storageClass": "COLDLINE" },
        "condition": { "age": 90, "matchesStorageClass": ["NEARLINE"] }
      },
      {
        "action": { "type": "Delete" },
        "condition": { "age": 365 }
      }
    ]
  }
}

Cette configuration déplace les objets de Standard vers Nearline à 30 jours, de Nearline vers Coldline à 90 jours, et les supprime à 365 jours. Ajustez la durée de rétention pour les exigences de conformité — certaines industries imposent 3, 5 ou 7 ans de rétention des données.

Un détail important : les politiques de cycle de vie opèrent sur des objets individuels, pas sur des partitions BigQuery. Si vous utilisez des tables BigLake avec un partitionnement de style Hive, les fichiers de données de chaque partition sont des objets distincts dans Cloud Storage. Les politiques de cycle de vie niveautent donc naturellement les données par ancienneté lorsque vos partitions sont basées sur des dates — les fichiers des partitions plus anciennes vieillissent et sont déplacés vers des niveaux moins coûteux automatiquement.

Autoclass pour les tables Iceberg

Pour les tables BigLake Iceberg, activez Autoclass sur le bucket sous-jacent plutôt que d’écrire des règles de cycle de vie manuelles. Autoclass déplace automatiquement les fichiers de données et de métadonnées vers les classes de stockage optimales en fonction des patterns d’accès réels, pas seulement de l’ancienneté.

# Activer Autoclass sur un bucket
gcloud storage buckets update gs://data-lake-bronze \
    --enable-autoclass \
    --autoclass-terminal-storage-class=ARCHIVE

Autoclass est plus intelligent que les règles de cycle de vie statiques parce qu’il répond aux patterns d’accès réels :

• Une partition de 6 mois qui est soudainement interrogée (parce qu’un analyste examine un problème historique) est automatiquement déplacée vers un niveau plus chaud
• Les fichiers de métadonnées auxquels Iceberg accède fréquemment restent en stockage Standard même si les fichiers de données migrent vers Coldline
• Le flag --autoclass-terminal-storage-class contrôle jusqu’où les objets peuvent refroidir (la valeur par défaut est Nearline ; réglez sur Archive pour des économies maximales sur les données vraiment dormantes)

Le compromis : Autoclass facture de petits frais de gestion (0,0025 $/1 000 objets/mois) et ne peut pas être combiné avec des règles de cycle de vie manuelles sur le même bucket. Pour la plupart des buckets data lake avec des patterns d’accès variés, Autoclass est plus simple et moins coûteux que tenter de prédire la fréquence d’accès avec des règles statiques.

Facturation physique dans BigQuery

Pour les données stockées directement dans BigQuery (tables natives, pas BigLake), le passage de la facturation logique à la facturation physique réduit souvent considérablement les coûts de stockage.

Facturation logique (par défaut) : vous payez pour la taille logique non compressée de vos données. 0,02 $/Go/mois pour les données actives, 0,01 $/Go/mois pour les données long terme (non modifiées depuis 90+ jours).

Facturation physique : vous payez pour les octets physiques compressés sur disque. 0,04 $/Go/mois pour les données actives, 0,02 $/Go/mois pour les données long terme. Le stockage time travel et fail-safe est facturé séparément.

Le calcul dépend de votre taux de compression. La compression en colonnes de BigQuery atteint typiquement une réduction de 3 à 4 fois sur les données analytiques. Une table qui fait 100 Go en logique peut faire 25 Go en physique. En facturation logique, cela coûte 2 $/mois. En facturation physique, 1 $/mois. L’économie de 50 % se cumule sur l’ensemble de votre entrepôt.

-- Vérifier les taux de compression avant de basculer
SELECT
  table_schema,
  table_name,
  ROUND(total_logical_bytes / POW(1024, 3), 2) AS logical_gb,
  ROUND(total_physical_bytes / POW(1024, 3), 2) AS physical_gb,
  ROUND(total_logical_bytes / NULLIF(total_physical_bytes, 0), 1)
    AS compression_ratio
FROM `region-us`.INFORMATION_SCHEMA.TABLE_STORAGE
WHERE total_logical_bytes > 0
ORDER BY total_logical_bytes DESC
LIMIT 20;

Si votre taux de compression dépasse 2:1, la facturation physique permet d’économiser de l’argent. Étant donné que les données typiques se compriment de 6 à 17 fois, la plupart des organisations bénéficient du basculement. La facturation physique est configurée au niveau du dataset, pas par table.

Combiné avec la tarification du stockage long terme (réduction de 50 % pour les données non modifiées depuis 90 jours), les datasets matures dans BigQuery peuvent coûter environ 0,005 $/Go/mois. C’est moins cher que la plupart des stockages objets compte tenu des capacités de requête incluses.

Les trois dimensions ensemble

L’optimisation des coûts de stockage opère sur trois dimensions en interaction :

1. Tiering de stockage : segmentez les données par fréquence d’accès. Données chaudes dans BigQuery ou Cloud Storage Standard ; données froides dans Nearline/Coldline.

2. Facturation physique : faites basculer les datasets BigQuery vers la facturation physique une fois que vous avez vérifié que les taux de compression dépassent 2:1.

3. Modèle de tarification : les projets de pipeline avec des patterns de requêtes prévisibles bénéficient de la tarification Editions avec des slots autoscaler. Les projets analytiques avec des requêtes ad-hoc imprévisibles fonctionnent mieux avec la tarification à la demande et des quotas de coûts journaliers.

N’appliquez pas le même modèle de tarification aux deux cas d’usage. Un pipeline dbt de production qui exécute les mêmes transformations quotidiennement a un profil de slots prévisible. Une équipe analytique qui explore des données de manière ad-hoc a un profil par rafales et imprévisible. Séparez-les dans des projets BigQuery distincts avec des configurations de tarification différentes, et optimisez chacun indépendamment.

La combinaison du tiering Cloud Storage pour le data lake, de la facturation physique pour le stockage BigQuery natif, et d’une tarification de calcul appropriée réduit typiquement les coûts totaux de stockage de 60 à 80 % par rapport au maintien de tout en configuration par défaut.