BigQuery Editions et la tarification par slots

Le modèle de coût BigQuery propose deux modes de facturation pour le compute : à la demande (facturation par octet scanné) et Editions (facturation par slot-heure). Le point d’équilibre dépend du volume mensuel de scans, du profil des charges de travail et des fonctionnalités propres à certaines éditions.

Le calcul du point d’équilibre

La tarification BigQuery Editions (introduite en juillet 2023, en remplacement de l’ancien modèle à taux fixe) facture le temps de compute en slot-heures plutôt qu’en octets scannés. Trois niveaux existent :

100 slots fonctionnant en continu sur Standard Edition PAYG coûtent 2 920 $ par mois. À 6,25 $ par TiB à la demande, cela équivaut à traiter 467 To. La règle empirique : si vous traitez plus de 400 à 500 To par mois avec des patterns réguliers, les slots permettent probablement de réduire les coûts.

Le calcul change pour les charges de travail en rafale. Traiter 20 To en moins d’une heure :

• À la demande : 125 $ (20 × 6,25 $)
• 100 slots pendant 1 heure (Standard) : ~5 $

Pour les scénarios en rafale, les slots sont rentables même avec de faibles volumes mensuels si les charges se concentrent sur des fenêtres courtes. Une équipe traitant 100 To par mois lors d’une exécution dbt de 4 heures peut réaliser des économies significatives par rapport au mode à la demande, même si 100 To/mois est en dessous du seuil de 400 à 500 To pour les charges continues.

L’autoscaling : l’approche moderne

L’autoscaling est devenu généralement disponible en février 2025. Au lieu de s’engager sur un nombre fixe de slots, vous configurez une plage et BigQuery s’ajuste à l’intérieur.

Décisions de configuration clés :

Slots de base : Réglez à zéro pour les charges de travail avec des périodes d’inactivité. Les slots passent de zéro à pleine capacité instantanément, sans pénalité de démarrage. Vous ne payez que ce que vous utilisez. Cela élimine l’ancien problème de facturation de slots inactifs en dehors des heures de pointe.

Slots maximum : Votre plafond lors des pics de demande. Commencez prudemment et augmentez en fonction des temps d’attente observés. Si des requêtes se mettent en file d’attente, augmentez le maximum.

Taux d’utilisation cible : Visez 60 à 80 % pendant les heures de pointe. Un niveau constamment plus élevé indique un sous-provisionnement (les requêtes s’accumulent et ralentissent). Un niveau constamment plus faible suggère un surprovisionnement (vous payez pour une capacité inutilisée).

Créer une réservation avec autoscaling :

-- Create a reservation with autoscaling
CREATE RESERVATION `project.region-us.prod_reservation`
OPTIONS (
  slot_capacity = 0,  -- baseline
  edition = 'ENTERPRISE',
  autoscale = (
    max_slots = 500
  )
);

-- Create an assignment for your project
CREATE ASSIGNMENT `project.region-us.prod_reservation.prod_assignment`
OPTIONS (
  assignee = 'projects/my-project',
  job_type = 'QUERY'
);

Le pattern avec base à zéro est adapté aux charges de travail par lots comme les exécutions dbt. La réservation reste à zéro slot (zéro coût) jusqu’au démarrage de dbt, monte en charge pour traiter le pipeline, puis redescend à zéro. Les coûts ne s’accumulent que pendant la fenêtre de traitement.

Remises pour engagement d’utilisation (2025)

Google Cloud Next 2025 a introduit des remises pour engagement d’utilisation basées sur les dépenses pour BigQuery :

• Engagement 1 an : 10 % de réduction par rapport au PAYG
• Engagement 3 ans : 20 % de réduction par rapport au PAYG

Contrairement aux engagements traditionnels basés sur les slots, ces remises sont libellées en dollars et flexibles sur les produits BigQuery Editions, Cloud Composer 3 et Data Governance. Cela simplifie la planification de capacité : engagez-vous sur un niveau de dépense mensuel plutôt que d’estimer des nombres de slots.

Un pattern courant : combiner l’engagement pour la capacité de base prévisible avec l’autoscaling pour les pics. Cela permet de bénéficier des remises d’engagement sur les charges régulières (jobs dbt quotidiens, actualisations récurrentes de tableaux de bord) tout en conservant la flexibilité pour les pics (analyses ad hoc, hausses de reporting en fin de mois).

Comparaison des fonctionnalités par édition

Au-delà du prix, les éditions diffèrent par leurs capacités. Choisir un niveau inférieur pour économiser peut éliminer des fonctionnalités requises pour certaines charges de travail.

Standard Edition :

• Maximum 1 600 slots
• Pas de BigQuery ML
• Pas de vues matérialisées avec actualisation automatique
• Idéal pour : les environnements de développement, l’analyse ad hoc, les charges sensibles au coût

Enterprise Edition :

• Slots illimités (avec le quota approprié)
• BigQuery ML inclus
• Accélération BI Engine
• Recherche en texte intégral
• SLA à 99,99 %
• Idéal pour : les charges de production, les pipelines ML, les environnements BI intensifs

Enterprise Plus :

• Tout ce qu’offre Enterprise
• Reprise après sinistre multi-région
• Certifications de conformité (FedRAMP, CJIS, IL4)
• Idéal pour : les secteurs réglementés, les charges critiques nécessitant une DR

Nuance importante : La tarification à la demande maintient une parité fonctionnelle avec Enterprise Plus (à l’exception des requêtes continues et de la reprise après sinistre managée). Si vous avez besoin de fonctionnalités de conformité mais une utilisation imprévisible, la tarification à la demande peut être plus économique que les slots Enterprise Plus. Ne choisissez pas Enterprise Plus uniquement pour ses fonctionnalités si la tarification à la demande vous offre les mêmes sans engagement de capacité.

Cadre de décision

Examinez ces questions dans l’ordre :

1. Quel est votre volume de scans mensuel ? Si moins de 400 To/mois avec des charges uniformément réparties, la tarification à la demande est probablement moins chère. Exécutez la requête d’auto-évaluation depuis Modèle de coût BigQuery sur vos propres données INFORMATION_SCHEMA.JOBS.

2. Les charges sont-elles en rafale ou continues ? Les charges en rafale (tout s’exécute dans une fenêtre de 4 heures) favorisent nettement les slots. Les charges continues et uniformément réparties tout au long de la journée favorisent la tarification à la demande, sauf si le volume est très élevé.

3. Avez-vous besoin de fonctionnalités exclusives à certaines éditions ? BigQuery ML, BI Engine, l’actualisation automatique des vues matérialisées et les fonctionnalités de conformité varient selon l’édition. Vérifiez si la tarification à la demande (qui inclut toutes les fonctionnalités) couvre vos besoins avant de vous engager sur une édition.

4. Pouvez-vous prévoir vos dépenses de base ? Si vous pouvez prévoir de manière fiable une dépense mensuelle minimale, les remises pour engagement apportent des économies supplémentaires. Si les dépenses sont très variables, l’autoscaling PAYG est plus sûr.

5. Avez-vous besoin d’isoler les charges de travail ? Les slots permettent des affectations de réservation qui isolent les équipes les unes des autres. La tarification à la demande utilise un pool de slots partagé où la charge de travail intensive d’une équipe peut ralentir les requêtes d’une autre.

Surveiller l’utilisation des slots

Une fois sur Editions, il est nécessaire de surveiller l’utilisation des slots. Un sous-provisionnement provoque la mise en file d’attente des requêtes. Un surprovisionnement signifie payer pour des slots inactifs.

Interrogez votre pattern d’utilisation des slots :

SELECT
  TIMESTAMP_TRUNC(period_start, HOUR) AS hour,
  reservation_id,
  AVG(slot_assigned) AS avg_slots_assigned,
  MAX(slot_assigned) AS max_slots_assigned,
  AVG(slot_assigned) / MAX(slot_assigned) AS utilization_ratio
FROM `region-us`.INFORMATION_SCHEMA.RESERVATIONS_TIMELINE
WHERE period_start > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
GROUP BY 1, 2
ORDER BY 1 DESC;

Si le taux d’utilisation reste en dessous de 0,5, votre maximum est trop élevé. Si des requêtes se mettent fréquemment en file d’attente (visible dans INFORMATION_SCHEMA.JOBS via pending_units), votre maximum est trop bas. Ajustez chaque semaine jusqu’à trouver l’équilibre optimal.