Les coûts théoriques en slot-heures correspondent rarement aux factures BigQuery réelles. Le calcul semble propre sur le papier — 500 slots × 4 heures × 0,06 $/slot-heure = 120 $ — mais les workloads réels interagissent avec les mécanismes d’autoscaling de façon à gonfler les dépenses réelles de 30 à 100 % au-dessus de ces estimations. Cette note explique les deux mécanismes responsables et comment le profil du workload change la surcharge.
La Règle Pratique du 1,5x
Une 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.
Un workload nécessitant théoriquement 1 000 $/mois en slot-heures coûte souvent 1 400 à 1 600 $ en pratique. Ce n’est pas un défaut ou une astuce de facturation — c’est la conséquence prévisible de la façon dont les mécanismes d’autoscaling interagissent avec les patterns de requêtes réels. Le multiplicateur est une estimation ; la surcharge réelle va de 1,2x pour les jobs longs et soutenus à 2x ou plus pour les workloads de requêtes courtes et sporadiques.
Quand la requête de comparaison au seuil de rentabilité applique ce multiplicateur à total_slot_ms, elle tient compte de cette réalité plutôt que de présenter un chiffre théorique flatteur mais inexact.
Pourquoi la Surcharge Existe : Deux Mécanismes
La Fenêtre de Facturation Minimum de 60 Secondes
Quand BigQuery passe à l’échelle supérieure pour traiter une requête, il alloue des slots par incréments de 50. Ces slots restent alloués pendant un minimum de 60 secondes avant que l’autoscaler puisse réduire l’échelle.
Cela signifie qu’une requête de 100 slots se terminant en 5 secondes est facturée pour 100 slot-minutes, pas 8,3 slot-secondes. Le calcul :
- Calcul réellement utilisé : 100 slots × 5 secondes = 500 slot-secondes
- Calcul réellement facturé : 100 slots × 60 secondes = 6 000 slot-secondes
- Facteur de surcharge pour cette requête : 12x
La fenêtre de 60 secondes existe pour éviter le thrashing — des cycles constants de montée/descente en charge qui nuiraient aux performances et déstabiliseraient l’autoscaler. C’est un choix de conception raisonnable, mais il rend les Editions coûteuses pour les workloads composés de nombreuses requêtes courtes. Voir Slots baseline vs autoscaling dans BigQuery pour les mécanismes complets.
Incréments de Scaling de 50 Slots
L’autoscaling opère par multiples de 50 slots. Si votre requête a besoin de 101 slots, vous êtes facturé pour 150. Si une requête nécessite 151 slots, vous êtes facturé pour 200. Cet arrondi à la hausse se produit à chaque événement de scaling et se cumule tout au long de la journée.
Pour un workload où les requêtes ont systématiquement besoin de 51 à 100 slots, vous payez pour 100 slots à chaque événement d’autoscale — jusqu’à 2x le minimum théorique. Sur les workloads où les requêtes nécessitent 201 slots, vous payez pour 250. La surcharge due à l’arrondi est proportionnellement plus faible pour les grands workloads, mais elle ne disparaît jamais.
Comment le Profil du Workload Change le Multiplicateur
Le chiffre de 1,5x est une moyenne. Votre multiplicateur réel dépend fortement du fait que votre workload soit soutenu ou sporadique.
Workloads soutenus (longs, continus) : Jobs ETL traitant des données pendant 4 heures, exécutions dbt enchaînant des centaines de modèles séquentiellement, pipelines batch overnight. La fenêtre de 60 secondes se déclenche peu fréquemment par rapport au temps d’exécution total, et les slots restent alloués en continu parce que de nouvelles requêtes arrivent avant l’expiration de la fenêtre. Multiplicateur : 1,1 à 1,3x. La surcharge est minimale parce que vous payez pour des slots que vous utilisez réellement.
Workloads en rafale (fenêtres de temps concentrées) : Une exécution dbt qui enchaîne 200 modèles séquentiels prenant chacun 10 secondes. Chaque modèle déclenchant l’autoscaling démarre une nouvelle fenêtre de facturation de 60 secondes. L’exécution peut prendre 30 minutes en temps réel mais accumuler 60 minutes de facturation de slots. Multiplicateur : 1,5 à 2x selon la fréquence à laquelle les requêtes atteignent le seuil d’autoscaling.
Workloads sporadiques (nombreuses requêtes courtes et déconnectées) : Exploration BI ad-hoc, analytics interactif, requêtes de dashboards se déclenchant tout au long de la journée avec des intervalles entre elles. Chaque requête est son propre événement d’autoscaling. Une journée de 100 requêtes d’une moyenne de 15 secondes chacune génère 100 fenêtres de facturation de 60 secondes séparées. Calcul théorique : 1 500 secondes de slots. Facturation réelle : 6 000 secondes. Multiplicateur : 2x ou plus. C’est exactement le pattern où la tarification on-demand gagne généralement.
Le Problème des Max Slots
L’autoscaler optimise pour la vitesse des requêtes, pas pour l’efficacité des coûts. Définir max_slots à 1 600 parce que « les workloads de pointe en ont occasionnellement besoin » résulte souvent en des requêtes routinières consommant bien plus de slots que nécessaire.
L’expérience d’une équipe d’ingénierie : quand ils ont configuré max_slots = 1600, BigQuery passait fréquemment à 1 600 slots même pour des requêtes qui s’exécuteraient raisonnablement avec 400. Seul le 99e percentile de leurs requêtes nécessitait réellement cette capacité. L’autoscaler utilise le plafond que vous lui donnez pour minimiser la latence — il ne se retient pas pour réduire votre facture.
L’implication pratique : définissez max_slots à votre utilisation historique P90, pas P99 ou au maximum. Utilisez les requêtes de supervision de l’utilisation des slots pour identifier votre distribution en percentile réelle avant de configurer les réservations :
WITH hourly_slots AS ( SELECT TIMESTAMP_TRUNC(period_start, HOUR) AS hour, SUM(period_slot_ms) / 1000 / 3600 AS slots_consumed FROM `region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE WHERE job_creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY) AND (statement_type != 'SCRIPT' OR statement_type IS NULL) GROUP BY hour)SELECT ROUND(APPROX_QUANTILES(slots_consumed, 100)[OFFSET(50)]) AS p50_slots, ROUND(APPROX_QUANTILES(slots_consumed, 100)[OFFSET(75)]) AS p75_slots, ROUND(APPROX_QUANTILES(slots_consumed, 100)[OFFSET(90)]) AS p90_slots, ROUND(APPROX_QUANTILES(slots_consumed, 100)[OFFSET(99)]) AS p99_slots, ROUND(MAX(slots_consumed)) AS max_slotsFROM hourly_slots;Le P90 est votre cible maximale de réservation. Votre baseline devrait couvrir la charge soutenue — typiquement 60 à 80 % du P50 — pour minimiser la surcharge d’autoscaling tout en maintenant l’efficacité des coûts. Le P99 et le maximum servent à comprendre vos pics réels, pas à définir la capacité permanente.
Les Slots Baseline Évitent la Taxe d’Autoscaling
Les slots baseline sont exemptés du calcul de surcharge d’autoscaling. Vous les payez en continu (ce qui est leur propre coût), mais les requêtes utilisant les slots baseline ne déclenchent pas de fenêtres de facturation de 60 secondes — ces slots sont déjà alloués. Pour les workloads prévisibles exécutant un calcul soutenu, les slots baseline convertissent la surcharge d’autoscaling d’un coût variable en coût fixe.
Le choix stratégique : utiliser le baseline pour la charge stable que vous savez que vous consommerez (où payer en continu est moins cher que la surcharge d’autoscaling), et laisser l’autoscaling gérer les pics réels. Cette approche hybride capture souvent une meilleure efficacité des coûts que le baseline pur ou l’autoscaling pur.
Calibrer Vos Estimations
Quand vous évaluez si les Editions sont pertinentes pour votre workload, tenez compte explicitement du multiplicateur. Exécutez la requête de seuil de rentabilité depuis Modèle de coûts BigQuery contre vos données INFORMATION_SCHEMA avec le facteur de 1,5x intégré :
SUM(total_slot_ms) / 1000 / 3600 * 0.06 * 1.5 AS enterprise_edition_costSi l’estimation résultante bat encore votre coût on-demand, les Editions méritent d’être évaluées. Si elle est dans les 25 % de l’on-demand, la flexibilité et la configuration zéro de l’on-demand gagnent probablement. Le multiplicateur n’est pas une raison d’éviter les Editions — c’est une raison d’utiliser des chiffres réalistes plutôt que des chiffres théoriques.