Slots baseline vs autoscaling dans BigQuery

Au sein des éditions Enterprise et Enterprise Plus, les réservations disposent de deux types de capacité : baseline et autoscaling. Le baseline est toujours alloué ; l’autoscaling est élastique et best-effort.

Slots Baseline

Les slots baseline sont toujours alloués à votre réservation. Ils sont garantis et immédiatement disponibles, et vous les payez que vous les utilisiez ou non.

Pensez au baseline comme à votre capacité « toujours active ». Si votre exécution dbt en production a besoin de 200 slots chaque matin à 6h, le baseline garantit que ces slots sont prêts et disponibles. Pas de délai de démarrage, pas de risque de contraintes de capacité régionale, pas d’incertitude.

La garantie est réelle : les slots baseline ne peuvent pas être préemptés, retardés par la demande régionale, ou échouer dans leur allocation. Ils vous appartiennent. C’est ce qui différencie la tarification par capacité de l’on-demand — vous achetez de la certitude.

L’inconvénient est tout aussi réel : vous payez les slots baseline 24h/24, même à 3h du matin quand rien ne tourne. Cela rend le baseline coûteux pour les workloads qui ne s’exécutent que quelques heures par jour. Une réservation avec 500 slots baseline coûte pareil que ces slots traitent des requêtes pendant 20 heures ou 2 heures.

Slots Autoscaling

Les slots autoscaling sont alloués à la demande à mesure que votre workload croît. Vous définissez un maximum, et BigQuery scale automatiquement à la hausse (et à la baisse).

Comportements clés :

• Scale par multiples de 50 slots. Si vous avez besoin de 75 slots, vous en obtenez 100.
• Scale à la hausse quasi instantanément. Le délai est négligeable pour la plupart des workloads.
• Soumis à la disponibilité de capacité régionale. Lors de rares contraintes régionales, les demandes d’autoscale peuvent être retardées. C’est la différence clé avec le baseline — l’autoscaling est best-effort.
• Facturé à la seconde pendant l’allocation.

L’autoscaling est idéal pour les workloads en rafale. Votre rafraîchissement complet dbt qui s’exécute chaque semaine et nécessite 800 slots pendant 2 heures ? L’autoscaling gère ça sans payer pour 800 slots les 166 autres heures de la semaine.

La Fenêtre d’Autoscale de 60 Secondes

Un détail important qui surprend beaucoup d’équipes : quand BigQuery passe à l’échelle supérieure, il maintient ces slots alloués pendant au moins 60 secondes, même si votre requête se termine en 5 secondes.

Pourquoi ? Pour éviter le thrashing. Sans cette fenêtre, une rafale de requêtes courtes provoquerait des cycles constants de montée/descente en charge, nuisant aux performances et compliquant la facturation.

Exemple de timeline :

12:00:00 - La requête a besoin de 100 slots → Passe à 100
12:00:05 - La requête se termine → Toujours à 100 (fenêtre active)
12:01:00 - La fenêtre expire, pas de nouvelle demande → Passe à 0
12:01:02 - Nouvelle requête a besoin de 50 slots → Passe à 50
12:01:03 - La requête se termine → Toujours à 50 (nouvelle fenêtre)
12:02:03 - La fenêtre expire → Passe à 0

Cela a des implications réelles pour dbt, qui exécute de nombreuses requêtes séquentielles. Chaque requête déclenchant l’autoscaling démarre une nouvelle fenêtre de 60 secondes. Une exécution dbt avec 200 modèles prenant chacun 5 secondes maintient quand même les slots autoscalés pendant les 60 secondes complètes après chaque événement de scaling. Le multiplicateur de coût autoscaling 1,5x tient compte de cette surcharge.

La fenêtre signifie également que les workloads séquentiels serrés (une requête immédiatement après l’autre) maintiennent effectivement les slots autoscalés en continu, ce qui peut approximer le coût des slots baseline. Si vous utilisez constamment de la capacité autoscalée pendant des heures d’affilée, vous avez souvent intérêt à la convertir en baseline.

Priorité d’Utilisation des Slots

Quand un job s’exécute, BigQuery alloue la capacité dans cet ordre :

1. Slots baseline (garantis, utilisés en premier)
2. Slots inactifs d’autres réservations (si le partage est activé)
3. Slots autoscaling (si baseline + inactifs sont épuisés)
4. File d’attente (si toutes les sources de capacité sont épuisées)

flowchart TB
      Q[Requête soumise] --> B{Baseline<br/>disponible ?}
      B -->|Oui| UB[Utiliser baseline]
      B -->|Non| I{Slots inactifs<br/>disponibles ?}
      I -->|Oui| UI[Emprunter inactifs]
      I -->|Non| A{Marge<br/>autoscale ?}
      A -->|Oui| UA[Monter en charge]
      A -->|Non| W[Mise en file d'attente]

      UB --> RUN[Exécuter]
      UI --> RUN
      UA --> RUN
      W --> WAIT[Attendre des slots]

Cet ordre de priorité compte car il affecte à la fois le coût et la fiabilité. Le baseline est le moins cher (vous le payez déjà). Les slots inactifs sont gratuits pour l’emprunteur (la réservation propriétaire paie déjà). L’autoscaling est le plus coûteux par slot-heure. La mise en file d’attente signifie que votre requête attend.

L’implication : dimensionnez votre baseline pour couvrir vos besoins en régime permanent, laissez le partage de slots inactifs absorber les pics modérés, et utilisez l’autoscaling comme soupape de sécurité pour les vrais pics.

Quand Utiliser le Baseline

Définissez un baseline quand :

• Vous avez des workloads prévisibles et stables qui s’exécutent à des horaires cohérents
• Les jobs sont critiques pour les SLA et ne peuvent pas attendre l’autoscale ou risquer des contraintes de capacité régionale
• Vous combinez avec des engagements pour la réduction de 20 à 40 % (les engagements s’appliquent d’abord aux slots baseline)

Un pattern courant : analysez votre utilisation des slots sur 30 jours, identifiez votre usage P50 (médiane), et définissez-le comme baseline. L’autoscaling gère tout ce qui est au-dessus de la médiane.

Cette approche garantit que la moitié de votre workload s’exécute sur une capacité garantie et à prix réduit, tandis que la partie plus variable utilise le scaling élastique. À mesure que vos workloads se stabilisent et que vous gagnez en confiance sur le pattern, vous pouvez augmenter progressivement le baseline pour capturer davantage de la réduction des engagements.

Quand l’Autoscaling Seul Suffit

Le pur autoscaling (baseline à zéro) fonctionne quand :

• Les workloads sont très variables sans pattern cohérent
• Vous êtes en phase d’exploration et ne connaissez pas encore vos besoins en régime permanent
• Le workload ne s’exécute que pendant des fenêtres spécifiques (quelques heures par jour/semaine)
• Vous utilisez Standard Edition, qui ne prend en charge que l’autoscaling

Le modèle autoscaling-seul de Standard Edition est en fait bien adapté au développement et aux workloads légers précisément parce que vous ne payez rien quand vous êtes inactif. Le compromis est la limite de 1 600 slots et l’absence de réductions sur engagement.

L’Idée Fausse sur la « Garantie de Capacité des Réservations »

C’est partiellement vrai et souvent mal compris. Les slots baseline sont véritablement garantis — ils sont toujours alloués à votre réservation. Mais les slots autoscaling sont best-effort, soumis à la capacité régionale. Lors de rares contraintes régionales, les demandes d’autoscale peuvent être retardées.

Si vous avez besoin d’une capacité garantie, mettez-la dans votre baseline. Ne supposez pas que l’autoscaling livrera toujours les slots que vous demandez instantanément. C’est généralement le cas, mais « généralement » n’est pas « garanti » quand votre SLA en dépend.