Un slot BigQuery est une unité de calcul virtuelle regroupant CPU, mémoire et ressources réseau. Lorsqu’une requête s’exécute, BigQuery assemble des slots pour la traiter en parallèle. Plus il y a de slots disponibles, plus le travail parallèle est important. Lorsque la demande dépasse l’offre, les requêtes ralentissent.
Les slots sont le fondement du modèle de capacité BigQuery. Les BigQuery Editions, les réservations, le baseline et l’autoscaling, et le fair scheduling sont tous des mécanismes pour gérer l’allocation des slots.
Comment les requêtes utilisent les slots
Lorsque vous soumettez une requête SQL, BigQuery ne l’exécute pas ligne par ligne. À la place, il :
- Analyse votre SQL et crée un plan d’exécution
- Décompose le plan en étapes (unités logiques de travail)
- Divise chaque étape en tâches pouvant s’exécuter en parallèle
- Affecte des slots pour exécuter ces tâches
- Mélange les résultats intermédiaires entre les étapes
- Réaffecte les slots dynamiquement au fur et à mesure de la requête
C’est pourquoi BigQuery peut traiter des téraoctets en quelques secondes. Ce n’est pas une seule machine qui travaille dur ; ce sont des milliers de slots travaillant ensemble.
┌─────────────────────────────────────────────────────────────┐│ Votre requête SQL │└─────────────────────────────────────────────────────────────┘ │ ▼┌─────────────────────────────────────────────────────────────┐│ Plan d'exécution ││ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ││ │ Étape 1 │ -> │ Étape 2 │ -> │ Étape 3 │ -> │ Étape 4 │ ││ │ (Scan) │ │ (Filtre)│ │ (Agréga)│ │ (Tri) │ ││ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │└─────────────────────────────────────────────────────────────┘ │ ▼┌─────────────────────────────────────────────────────────────┐│ Les slots exécutent les étapes en parallèle ││ [Slot 1] [Slot 2] [Slot 3] ... [Slot N] │└─────────────────────────────────────────────────────────────┘Chaque étape du plan d’exécution représente une unité logique de travail — un scan de table, un filtre, une agrégation, un tri. BigQuery divise chaque étape en de nombreuses unités de travail parallèles et les distribue sur les slots disponibles. Au fur et à mesure que les slots terminent leur travail assigné, ils prennent en charge la prochaine unité. Cette réaffectation dynamique est essentielle : BigQuery ne partitionne pas statiquement le travail au départ. Il rééquilibre continuellement au fur et à mesure de la progression de la requête.
L’étape de mélange entre les étapes est là où les résultats intermédiaires transitent entre les slots. Une étape de scan peut lire des données sur des centaines de slots, puis mélanger les résultats vers un ensemble plus petit de slots pour l’agrégation. C’est le même pattern MapReduce que le moteur Dremel utilise depuis ses débuts — simplement abstrait derrière le concept de slot.
Contention de slots
Lorsqu’une étape de requête nécessite 2 000 slots mais que seulement 1 000 sont disponibles, BigQuery utilise les 1 000 et met en file d’attente les unités de travail restantes. Les slots prennent en charge le travail en attente au fur et à mesure qu’ils se libèrent. La requête se termine, mais plus lentement.
C’est la contention de slots. BigQuery dégrade de manière progressive — pas d’échec brutal, pas de timeout, pas de message d’erreur — ce qui rend la contention facile à rater jusqu’à ce qu’elle devienne sévère. Des tableaux de bord rapides le matin et lents l’après-midi, ou des exécutions dbt qui prennent 20 minutes le week-end et 90 minutes en semaine, sont des symptômes typiques.
Deux façons d’obtenir des slots
BigQuery offre deux modèles de tarification fondamentaux qui déterminent comment vous accédez aux slots :
La tarification on-demand vous donne accès à un pool partagé d’environ 2 000 slots. Vous payez par téraoctet de données scannées, et BigQuery alloue dynamiquement des slots depuis ce pool partagé. C’est simple, ne nécessite aucune planification et fonctionne bien pour les workloads imprévisibles. L’inconvénient : ces 2 000 slots sont partagés avec d’autres utilisateurs on-demand dans la même région, donc les performances peuvent varier selon la demande régionale.
La tarification basée sur la capacité (via les BigQuery Editions) vous permet de réserver vos propres slots dédiés. Vous payez pour les slots eux-mêmes, quel que soit le volume de données scanné. Cela vous donne des performances prévisibles et — pour les workloads intensifs — coûte souvent moins cher que l’on-demand. Le compromis est que vous vous engagez sur une capacité que vous utilisez ou non (bien que l’autoscaling atténue cela).
Le BigQuery Cost Model couvre les calculs de tarification en détail, y compris les calculs de point d’équilibre entre les deux modèles. L’insight clé ici est architectural, pas financier : l’on-demand offre des performances variables depuis un pool partagé, tandis que la tarification basée sur la capacité offre des ressources dédiées avec un comportement prévisible.
Une progression courante : commencer en on-demand, surveiller l’utilisation des slots au fur et à mesure que les workloads croissent, et migrer vers la tarification basée sur la capacité lorsque la contention devient un problème ou lorsque les calculs de coût le favorisent. Les outils de surveillance identifient quand ce moment arrive.
Plus de slots ne signifie pas toujours des requêtes plus rapides
Des slots supplémentaires n’améliorent pas toujours les performances. Les requêtes simples scannant de petits volumes de données peuvent ne pas bénéficier d’un parallélisme supplémentaire. Une requête scannant 1 Go peut s’exécuter en 2 secondes avec 100 ou 500 slots, là où la surcharge de coordination dépasse les bénéfices du parallélisme.
Le partitionnement et le clustering et l’abandon de SELECT * offrent souvent des gains plus importants qu’ajouter des slots. La requête la plus coûteuse d’un projet scanne typiquement 10 fois plus de données que nécessaire, plutôt que d’être simplement sous-dotée en slots.
Une idée reçue courante est que 1 000 slots signifient 1 000 requêtes concurrentes. Les slots sont partagés entre tous les jobs d’une réservation via le fair scheduling. 1 000 slots peuvent exécuter 1 requête à 1 000 slots, ou 100 requêtes à 10 slots chacune. La concurrence réelle dépend de la complexité des requêtes et de la dynamique du fair scheduling.