Vous avez optimisé vos requêtes, partitionné vos tables, clusteré vos colonnes, mais vos runs dbt continuent de ralentir aux heures de pointe. Les dashboards timeout. Vos stakeholders se plaignent. Que se passe-t-il ?

Le coupable est souvent la contention de slots (trop de requêtes en compétition pour trop peu de capacité de calcul). La plupart des analytics engineers n’ont qu’une vague idée de ce que sont réellement les slots, et encore moins de comment les gérer.

Cet article explique le modèle de calcul de BigQuery depuis les bases, couvre les niveaux de tarification Editions, et fournit des stratégies pratiques pour gérer les slots dans les workflows dbt. À la fin, vous comprendrez non seulement ce que sont les slots, mais comment architecturer vos projets pour que vos pipelines s’exécutent de manière fiable.

Nous ne couvrirons pas les calculs de prix ici (c’est l’article de demain). Aujourd’hui, on se concentre sur la compréhension de la mécanique.

Qu’est-ce qu’un slot BigQuery ?

Un slot BigQuery est une unité de calcul virtuelle. Voyez-le comme une combinaison de CPU, mémoire et ressources réseau regroupées ensemble. Quand vous exécutez une requête, BigQuery assemble une équipe de ces slots pour traiter votre demande en parallèle.

Plus il y a de slots disponibles, plus BigQuery peut effectuer de travail simultanément. Les requêtes complexes bénéficient de plus de slots. La haute concurrence (beaucoup d’utilisateurs qui requêtent en même temps) bénéficie de plus de slots. Le piège : les slots ne sont pas illimités, et quand la demande dépasse l’offre, les requêtes ralentissent.

Comment les requêtes utilisent les slots

Quand vous soumettez une requête SQL, BigQuery ne l’exécute pas ligne par ligne. Au lieu de cela, il :

1. Parse votre SQL et crée un plan d’exécution
2. Décompose le plan en étapes (unités logiques de travail)
3. Divise chaque étape en opérations qui peuvent s’exécuter en parallèle
4. Assigne des slots pour exécuter ces opérations
5. Redistribue les résultats intermédiaires entre les étapes
6. Réassigne dynamiquement les slots au fur et à mesure de la progression de la requête

C’est pourquoi BigQuery peut traiter des téraoctets en quelques secondes. Ce n’est pas une machine qui travaille dur ; ce sont des milliers de slots qui travaillent ensemble.

┌─────────────────────────────────────────────────────────────┐
│                      Votre requête SQL                      │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                     Plan d'exécution                        │
│  ┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐   │
│  │ Étape 1 │ -> │ Étape 2 │ -> │ Étape 3 │ -> │ Étape 4 │   │
│  │ (Scan)  │    │(Filtre) │    │ (Agg)   │    │ (Tri)   │   │
│  └─────────┘    └─────────┘    └─────────┘    └─────────┘   │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│            Les slots exécutent les étapes en parallèle      │
│    [Slot 1] [Slot 2] [Slot 3] ... [Slot N]                  │
└─────────────────────────────────────────────────────────────┘

Que se passe-t-il quand les slots sont épuisés

Si une étape de requête a besoin de 2 000 slots mais que seulement 1 000 sont disponibles, BigQuery n’échoue pas. Au lieu de cela :

• Il utilise tous les 1 000 slots disponibles
• Les unités de travail restantes sont mises en file d’attente
• À mesure que les slots terminent leurs tâches, ils prennent le travail en attente
• La requête se termine, juste plus lentement qu’elle aurait pu

C’est la contention de slots. Votre requête s’exécute toujours, mais elle prend plus de temps car elle attend des ressources. Aux heures de pointe (quand tout le monde exécute des rapports et que vos jobs dbt transforment des données), la contention peut transformer une requête de 30 secondes en une requête de 5 minutes.

Deux façons d’obtenir des slots

BigQuery propose deux modèles de tarification fondamentaux :

La tarification à la demande 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 pas de planification, et fonctionne bien pour les charges de travail imprévisibles.

La tarification basée sur la capacité (via BigQuery Editions) vous permet de réserver vos propres slots dédiés. Vous payez pour les slots eux-mêmes, indépendamment de la quantité de données scannées. Cela vous donne des performances prévisibles et (pour les charges de travail lourdes) coûte souvent moins cher qu’à la demande.

Le reste de cet article se concentre sur la tarification basée sur la capacité, car c’est là que réside la complexité (et les opportunités d’optimisation).

La hiérarchie des réservations

Le modèle de capacité de BigQuery comporte trois couches : les engagements, les réservations et les assignments. Comprendre cette hiérarchie est essentiel pour gérer efficacement les slots.

Engagements : Acheter de la capacité

Un engagement est un achat de capacité de calcul pour une durée minimale. Vous dites essentiellement : “Je paierai pour X slots pendant au moins Y temps.”

Les engagements sont optionnels lorsque vous utilisez BigQuery Editions, mais ils offrent des remises significatives :

• Engagement 1 an : 20% de remise
• Engagement 3 ans : 40% de remise

Sans engagement, vous payez le tarif standard pay-as-you-go pour votre édition. Les engagements sont pertinents quand vous avez des charges de travail prévisibles et stables.

Contraintes clés :

• Les engagements sont régionaux (les slots en us ne peuvent pas exécuter de jobs en eu)
• Les engagements ne peuvent pas être déplacés entre projets après création
• Disponibles uniquement pour les éditions Enterprise et Enterprise Plus

Réservations : Créer des pools de slots

Une réservation est un pool de slots réservé pour des charges de travail spécifiques. Voyez-la comme un “bucket” qui contient une partie de votre capacité engagée.

Pourquoi créer plusieurs réservations ? L’isolation. Vous pourriez créer :

• Une réservation prod avec 500 slots pour les pipelines de production
• Une réservation bi avec 300 slots pour les requêtes des dashboards
• Une réservation dev avec 100 slots pour le travail de développement

Chaque réservation fonctionne indépendamment. Les jobs dans dev ne voleront pas les slots de prod, donc vos pipelines de production ont toujours les ressources dont ils ont besoin.

Assignments : Connecter les projets aux réservations

Un assignment lie un projet Google Cloud (ou dossier, ou organisation) à une réservation. Une fois assigné, tous les jobs BigQuery de ce projet utilisent les slots de cette réservation.

La hiérarchie compte :

• L’assignment de projet remplace l’assignment de dossier
• L’assignment de dossier remplace l’assignment d’organisation
• Pas d’assignment signifie que le projet utilise la tarification à la demande

Vous pouvez aussi assigner par type de job. BigQuery supporte plusieurs types d’assignments :

Cela signifie que vous pourriez assigner les jobs QUERY d’un projet à une réservation tandis que ses jobs PIPELINE utilisent une autre.

Le projet d’administration

Bonne pratique : créez un projet d’administration dédié qui contient tous vos engagements et réservations. Ce projet n’exécute pas de requêtes et ne stocke pas de données ; il gère uniquement la capacité.

Nommez-le quelque chose d’évident comme bq-votreentreprise-admin. Cette approche :

• Centralise la facturation des ressources de calcul
• Simplifie la gestion de la capacité
• Garde vos projets de données propres

Une règle critique : les slots inactifs ne peuvent être partagés qu’entre les réservations du même projet d’administration. Si vous utilisez plusieurs projets d’administration, leurs slots restent complètement isolés.

 flowchart LR
      C[/"1000 slots (1 an)"/]

      C -->|"assigné à"| R1["Réservation: prod<br/>500
  slots"]
      C -->|"assigné à"| R2["Réservation:
  analytics<br/>300 slots"]
      C -->|"assigné à"| R3["Réservation: dev<br/>200
  slots"]

      R1 -->|"utilisé par"| P1([Projet: dbt-prod])
      R2 -->|"utilisé par"| P2([Projet: looker-prod])
      R3 -->|"utilisé par"| P3([Projet: analytics-dev])

BigQuery Editions expliqué

En mars 2023, Google a remplacé l’ancien modèle de tarification forfaitaire par BigQuery Editions. Il existe maintenant trois niveaux, chacun conçu pour différents types de charges de travail.

Édition Standard

Standard est le niveau d’entrée, conçu pour les requêtes ad-hoc et le travail de développement.

Caractéristiques clés :

• Maximum 1 600 slots (limite stricte, sans exception)
• Autoscaling uniquement (pas de slots de base)
• Pas de partage de slots inactifs entre réservations
• Pas de BigQuery ML
• Pas de VPC Service Controls
• Maximum 10 réservations par projet d’administration
• Assignments au niveau projet uniquement (pas de dossier ou organisation)

Idéal pour : Environnements de développement, travail de proof-of-concept, petites équipes avec des charges de requêtes légères.

Attention : Le plafond de 1 600 slots est strict. Si votre charge de travail dépasse cela, vous devrez passer à Enterprise.

Édition Enterprise

Enterprise est le niveau principal, adapté à la plupart des charges de travail de production.

Caractéristiques clés :

• Pas de limite stricte de slots (soumis au quota)
• Slots de base + autoscaling
• Partage des slots inactifs activé
• BigQuery ML inclus
• VPC Service Controls supporté
• Requêtes continues supportées
• Jusqu’à 200 réservations par projet d’administration
• Assignments au niveau projet, dossier ou organisation
• Engagements 1 an et 3 ans disponibles (remise de 20%/40%)

Idéal pour : Pipelines de données de production, charges de travail BI, équipes exécutant dbt à grande échelle.

Édition Enterprise Plus

Enterprise Plus est pour les charges de travail critiques avec des exigences strictes de conformité ou de disponibilité.

Tout ce qui est dans Enterprise, plus :

• Récupération après sinistre gérée (failover cross-région)
• Clés de chiffrement gérées par le client (CMEK)
• Contrôles de conformité via Assured Workloads (FedRAMP, CJIS, IL4, ITAR)
• SLA de 99,99% (vs. 99,9% pour Standard)

Idéal pour : Industries réglementées, services financiers, santé, charges de travail gouvernementales.

Comparaison des fonctionnalités

À la demande reste une option

Vous n’êtes pas obligé de choisir une édition. La tarification à la demande reste disponible avec une parité de fonctionnalités équivalente à Enterprise Plus (sauf la récupération après sinistre). Vous payez par téraoctet scanné, avez accès à environ 2 000 slots partagés, et n’avez pas à vous soucier de la planification de capacité.

Le compromis est que les performances peuvent varier selon la demande régionale, et les coûts peuvent exploser avec des requêtes inefficaces.

Beaucoup d’organisations utilisent une approche hybride : Editions pour les charges de travail de production prévisibles, à la demande pour le développement et l’analyse ad-hoc.

Slots de base vs. Autoscaling

Dans les éditions Enterprise et Enterprise Plus, vous configurez les réservations avec deux types de capacité : de base et autoscaling.

Slots de base

Les slots de base 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 aux slots de base comme votre capacité “toujours active”. Si votre run dbt de production a besoin de 200 slots chaque matin à 6h, les slots de base garantissent que ces slots sont prêts et en attente.

Slots autoscaling

Les slots autoscaling sont alloués à la demande au fur et à mesure que votre charge de travail croît. Vous définissez un maximum, et BigQuery scale automatiquement (vers le haut et vers le bas).

Comportements clés :

• Scale par multiples de 50 slots.
• Scale vers le haut presque instantanément.
• Scale vers le bas après une fenêtre minimale de 60 secondes.
• Soumis à la disponibilité de capacité régionale.
• Facturé par seconde pendant l’allocation.

La fenêtre d’autoscaling de 60 secondes

Un détail important : quand BigQuery scale vers le haut, il garde 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 causerait des cycles constants de scale-up/scale-down, nuisant aux performances et compliquant la facturation.

Exemple de timeline :

12:00:00 - Requête nécessite 100 slots → Scale à 100
12:00:05 - Requête terminée → Toujours à 100 (fenêtre active)
12:01:00 - Fenêtre expire, pas de nouvelle demande → Scale à 0
12:01:02 - Nouvelle requête nécessite 50 slots → Scale à 50
12:01:03 - Requête terminée → Toujours à 50 (nouvelle fenêtre)
12:02:03 - Fenêtre expire → Scale à 0

Cela a des implications pour dbt, qui exécute de nombreuses requêtes séquentielles. Chaque requête qui déclenche l’autoscaling démarre une nouvelle fenêtre de 60 secondes.

Priorité d’utilisation des slots

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

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

flowchart TB
      Q[Requête soumise] --> B{Slots de base<br/>disponibles ?}
      B -->|Oui| UB[Utiliser base]
      B -->|Non| I{Slots inactifs<br/>disponibles ?}
      I -->|Oui| UI[Emprunter inactifs]
      I -->|Non| A{Marge<br/>autoscale ?}
      A -->|Oui| UA[Scale up]
      A -->|Non| W[Mettre en file]

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

Quand utiliser les slots de base

Définissez un baseline quand :

• Vous avez des charges de travail prévisibles et stables
• Les jobs sont critiques pour le SLA et ne peuvent pas attendre l’autoscale
• Vous combinez avec des engagements pour des remises

Un pattern courant : analysez votre utilisation de slots sur 30 jours, identifiez votre P50 (médiane), et définissez-le comme baseline. L’autoscaling gère les pics.

Fair scheduling : Comment les slots sont distribués

Quand plusieurs requêtes sont en compétition pour la même réservation, BigQuery utilise le fair scheduling pour distribuer les slots équitablement.

L’algorithme

Le fair scheduling fonctionne en deux étapes :

1. Diviser les slots également entre les projets qui exécutent des jobs dans la réservation
2. Diviser la part de chaque projet entre ses jobs

C’est crucial : la première division est par projet, pas par nombre de requêtes.

Exemple de scénario

Considérez une réservation avec 1 000 slots :

• Projet A exécute 1 requête complexe
• Projet B exécute 20 requêtes simples

Comment les slots sont-ils distribués ?

La seule requête du Projet A obtient 500 slots. Les 20 requêtes du Projet B se partagent 500 slots (25 chacune).

La leçon : l’architecture des projets compte. Si vous exécutez dbt de production et des requêtes ad-hoc d’analystes dans le même projet, ils sont en compétition pour le même pool de slots. Séparez-les dans différents projets (assignés à différentes réservations) et ils sont isolés.

flowchart TB
    subgraph Reservation["Réservation : 1 000 slots"]
        subgraph PA["Projet A : 500 slots"]
            QA[Requête 1<br/>500 slots]
        end

        subgraph PB["Projet B : 500 slots"]
            QB1[R1: 25]
            QB2[R2: 25]
            QB3[R3: 25]
            QBN["... 20 requêtes au total ..."]
        end
    end

Priorité de contention lors des contraintes régionales

Quand une région entière est sous pression de capacité (rare, mais possible), BigQuery priorise les demandes :

1. Slots baseline/engagés Enterprise Plus & Enterprise
2. Slots autoscalés Enterprise Plus
3. Slots autoscalés Enterprise
4. Édition Standard et à la demande

Les utilisateurs Standard et à la demande ressentent la pression en premier.

Partage des slots inactifs

Une des fonctionnalités clés de l’édition Enterprise est le partage des slots inactifs : les slots inutilisés d’une réservation deviennent automatiquement disponibles pour les autres.

Comment ça fonctionne

Supposons que vous ayez deux réservations :

• prod : 500 slots de base, utilise actuellement 200
• dev : 100 slots de base, utilise actuellement 150

Les 300 slots inactifs de prod peuvent être empruntés par dev, lui donnant accès à jusqu’à 400 slots au total (100 de base + 300 empruntés).

Le piège : si prod a besoin de récupérer ses slots, il les reprend instantanément. Les jobs dans dev utilisant la capacité empruntée peuvent ralentir ou être mis en file d’attente.

Conditions requises pour le partage des slots inactifs

Les réservations peuvent partager des slots inactifs uniquement si elles :

• Sont dans le même projet d’administration
• Sont dans la même région
• Utilisent la même édition

Les slots autoscalés ne sont PAS partageables ; seuls les slots de base et engagés participent au partage.

Configuration

Chaque réservation a un paramètre ignore_idle_slots :

• false (par défaut) : Participe au partage (peut emprunter et prêter)
• true : Isolé, utilise uniquement sa propre capacité

Quand désactiver le partage

Envisagez de désactiver le partage des slots inactifs pour :

• Tests de proof-of-concept : Vous voulez voir comment une réservation performe avec exactement sa capacité allouée
• Isolation stricte des charges de travail : Exigences réglementaires ou de sécurité
• Planification de capacité : Comprendre les besoins réels en slots avant d’optimiser

Pour la plupart des cas d’usage en production, laissez le partage activé. Il améliore l’utilisation globale et aide les charges de travail non critiques sans nuire aux critiques.

dbt et les slots BigQuery

Si vous exécutez dbt sur BigQuery, la gestion des slots nécessite une considération supplémentaire. Le pattern d’exécution de dbt (nombreuses instructions SQL séquentielles) interagit avec les slots différemment qu’une seule requête complexe.

Pourquoi dbt est gourmand en calcul

Un run dbt typique peut exécuter des centaines de modèles. Chaque modèle est un job BigQuery séparé. Chaque job :

• Demande des slots
• Déclenche potentiellement l’autoscaling
• Garde les slots autoscalés pendant le minimum de 60 secondes
• Se termine, libère les slots, puis le modèle suivant démarre

Pour l’exécution séquentielle, vous pourriez avoir un job en cours à la fois, mais chacun peut déclencher une nouvelle fenêtre d’autoscale. Pour l’exécution parallèle (threads > 1), plusieurs jobs sont en compétition pour la capacité de votre réservation.

Les runs dbt lourds (surtout les full refreshes) peuvent consommer une capacité de slots significative.

Limitations actuelles de dbt

À ce jour, dbt-bigquery utilise un seul projet pour :

1. Exécuter les requêtes (détermine quels slots de réservation sont utilisés)
2. Stocker les tables de sortie

Il n’y a pas de moyen natif de dire “exécute ce modèle en utilisant la réservation X.” Les issues GitHub #2918, #3708, et #1228 suivent les demandes de sélection de réservation à l’exécution, mais ce n’est pas encore implémenté.

Solution de contournement : Séparer les projets par charge de travail

La solution pratique est d’utiliser plusieurs projets GCP, chacun assigné à une réservation appropriée.

jaffle_shop:
  target: prod
  outputs:

    # Runs de production haute priorité
    prod:
      type: bigquery
      method: service-account
      project: mycompany-dbt-prod      # Assigné à la réservation 'prod' (500 slots)
      dataset: analytics
      threads: 8

    # Jobs batch/backfill
    batch:
      type: bigquery
      method: service-account
      project: mycompany-dbt-batch     # Assigné à la réservation 'batch' (200 slots)
      dataset: analytics
      threads: 4

    # Développement
    dev:
      type: bigquery
      method: service-account
      project: mycompany-dbt-dev       # Tarification à la demande
      dataset: dev_adrienne
      threads: 4

Puis exécutez avec la cible appropriée :

# Run incrémental de production
dbt run --target prod --select state:modified+

# Full refresh backfill
dbt run --target batch --full-refresh

# Itération de développement
dbt run --target dev --select my_model

Bonnes pratiques pour dbt + slots

1. Utilisez les modèles incrémentaux de manière agressive

Les modèles incrémentaux ne traitent que les données nouvelles/modifiées, réduisant drastiquement la consommation de slots par rapport aux full refreshes.

2. Dimensionnez correctement vos threads

Plus de threads signifie plus de jobs concurrents et une demande de slots plus élevée. Adaptez votre paramètre threads à la capacité de votre réservation. Si vous avez 200 slots et exécutez 16 threads de modèles complexes, vous aurez de la contention.

3. Envisagez le mode à la demande pour le dev

Le travail de développement est imprévisible. La tarification à la demande signifie que vous ne gaspillez pas de capacité réservée sur des commandes dbt run sporadiques.

4. Définissez des baselines réalistes pour la production

Si votre run dbt de production s’exécute à 6h tous les matins et utilise régulièrement 300 slots pendant 45 minutes, définissez le baseline à 300. Vous aurez une capacité garantie quand vous en avez besoin.

5. Surveillez l’utilisation des slots par modèle

dbt labellise automatiquement les jobs. Requêtez INFORMATION_SCHEMA pour trouver vos modèles les plus coûteux :

SELECT
  (SELECT value FROM UNNEST(labels) WHERE key = 'dbt_invocation_id') AS invocation,
  (SELECT value FROM UNNEST(labels) WHERE key = 'dbt_model') AS model,
  COUNT(*) AS job_count,
  SUM(total_slot_ms) / 1000 / 60 AS total_slot_minutes,
  AVG(SAFE_DIVIDE(total_slot_ms,
    TIMESTAMP_DIFF(end_time, start_time, MILLISECOND))) AS avg_slots
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
  AND (SELECT value FROM UNNEST(labels) WHERE key = 'dbt_invocation_id') IS NOT NULL
GROUP BY invocation, model
ORDER BY total_slot_minutes DESC
LIMIT 20;

Cela fait ressortir les modèles qui consomment le plus de slot-time, ce qui en fait des candidats prioritaires pour l’optimisation.

Surveiller l’utilisation de vos slots

Avant de prendre des décisions de capacité, comprenez votre utilisation actuelle. BigQuery fournit de l’observabilité via les vues INFORMATION_SCHEMA et des outils intégrés.

Tables clés INFORMATION_SCHEMA

Exemple de requête : Slots moyens par job

Cette requête montre vos jobs les plus intensifs en slots sur les 7 derniers jours :

SELECT
  job_id,
  user_email,
  SAFE_DIVIDE(total_slot_ms,
    TIMESTAMP_DIFF(end_time, start_time, MILLISECOND)) AS avg_slots,
  TIMESTAMP_DIFF(end_time, start_time, SECOND) AS runtime_seconds,
  total_bytes_processed / POW(10, 9) AS gb_processed,
  reservation_id
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
  AND job_type = 'QUERY'
  AND state = 'DONE'
ORDER BY total_slot_ms DESC
LIMIT 25;

Utilisation horaire des slots

Voyez comment votre utilisation de slots varie au cours de la journée :

SELECT
  TIMESTAMP_TRUNC(period_start, HOUR) AS hour,
  SUM(period_slot_ms) / 1000 / 3600 AS slot_hours
FROM `region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE_BY_PROJECT
WHERE period_start > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
  AND (statement_type != 'SCRIPT' OR statement_type IS NULL)
GROUP BY hour
ORDER BY hour;

L’outil Slot Estimator

Le Slot Estimator intégré de BigQuery est utile pour la planification de capacité.

Pour y accéder :

1. Allez dans la console BigQuery
2. Cliquez sur Capacity management dans la navigation de gauche
3. Sélectionnez l’onglet Slot estimator

Ce qu’il montre :

• Utilisation des slots sur les 30 derniers jours
• Périodes de pic d’utilisation
• Percentiles de latence des jobs (P90, P95, etc.)
• Modélisation de l’impact sur les performances (et si vous ajoutiez 200 slots ?)
• Recommandations de coût optimal

Utilisez l’estimateur avant d’acheter des engagements ou d’ajuster les baselines. Il est basé sur votre utilisation historique réelle.

Intégration Cloud Monitoring

Pour une observabilité continue, BigQuery expose des métriques vers Cloud Monitoring :

• bigquery.googleapis.com/slots/allocated
• bigquery.googleapis.com/slots/available
• bigquery.googleapis.com/job/num_in_flight

Vous pouvez créer des dashboards montrant l’utilisation des slots en temps réel et configurer des alertes pour la contention de slots.

Idées reçues courantes

Plusieurs aspects des slots BigQuery sont fréquemment mal compris.

”Plus de slots signifie toujours des requêtes plus rapides”

Pas nécessairement. Les requêtes simples qui scannent peu de données peuvent ne pas bénéficier d’un parallélisme supplémentaire. Une requête scannant 1 Go pourrait s’exécuter en 2 secondes avec 100 slots ou 500 slots. L’overhead de coordination peut l’emporter sur les bénéfices du parallélisme.

Avant d’ajouter des slots, optimisez votre SQL. Le partitioning, le clustering, et éviter SELECT * offrent souvent de meilleurs gains que le calcul brut.

”Les réservations garantissent la capacité”

Partiellement vrai. Les slots de base sont garantis (ils sont toujours alloués à votre réservation). Mais les slots autoscaling sont en 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.

”Les slots inactifs sont de la capacité gratuite”

Le partage des slots inactifs est puissant, mais les slots empruntés peuvent être récupérés instantanément. Un job utilisant de la capacité empruntée peut ralentir en cours d’exécution si la réservation propriétaire a besoin de récupérer ses slots.

Ne comptez pas sur les slots inactifs pour les charges de travail critiques au SLA. Utilisez-les pour le dev, le traitement batch, ou les charges de travail qui peuvent tolérer des performances variables.

”L’édition Standard est la moins chère”

Pas toujours. L’édition Standard ne supporte pas les engagements, donc vous ne pouvez pas obtenir la remise de 20-40%. Pour les charges de travail stables et prévisibles, l’édition Enterprise avec un engagement d’1 an coûte souvent moins cher que le tarif pay-as-you-go de Standard.

De plus, le plafond de 1 600 slots de Standard peut vous forcer à passer à un niveau plus cher si votre charge de travail croît.

”1 000 slots = 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, ou toute combinaison entre les deux.

La concurrence réelle dépend de la complexité des requêtes, de la disponibilité des slots, et de la dynamique du fair scheduling.

Points clés à retenir

• Les slots sont des unités de calcul virtuelles (CPU + mémoire + réseau) qui traitent vos requêtes en parallèle
• Les réservations créent des pools de slots isolés pour différentes charges de travail
• Les assignments lient les projets aux réservations, déterminant quels slots ils utilisent
• Les éditions (Standard, Enterprise, Enterprise Plus) offrent différents ensembles de fonctionnalités et limites de capacité
• Les slots de base fournissent une capacité garantie ; l’autoscaling fournit de la flexibilité
• Le fair scheduling divise les slots également entre les projets d’abord, puis entre les jobs de chaque projet
• Le partage des slots inactifs permet aux réservations d’emprunter de la capacité inutilisée (mais elle est préemptible)
• Les utilisateurs dbt devraient utiliser des projets séparés pour différentes priorités de charge de travail (la sélection native de réservation n’est pas encore disponible)
• Surveillez avant d’optimiser : Utilisez INFORMATION_SCHEMA et le Slot Estimator pour comprendre votre utilisation réelle

Et ensuite

L’article de demain, “Tarification à la demande vs. Editions : Quand changer”, couvre les calculs de coûts. Nous passerons en revue les calculs de prix réels, l’analyse du seuil de rentabilité, et un framework de décision pour choisir votre modèle de tarification.

En attendant, commencez à explorer votre utilisation de slots :

-- Résumé rapide de l'utilisation des slots sur les 7 derniers jours
SELECT
  DATE(creation_time) AS date,
  COUNT(*) AS job_count,
  SUM(total_slot_ms) / 1000 / 60 / 60 AS total_slot_hours,
  AVG(SAFE_DIVIDE(total_slot_ms,
    TIMESTAMP_DIFF(end_time, start_time, MILLISECOND))) AS avg_slots_per_job
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
  AND job_type = 'QUERY'
GROUP BY date
ORDER BY date;

Comprendre votre utilisation actuelle est la première étape vers son optimisation.

Pour aller plus loin

Documentation Google Cloud

• Comprendre les slots
• BigQuery Editions
• Introduction à l’autoscaling des slots
• Gestion des charges de travail avec les réservations

Ressources communautaires

• Blog Google : Bonnes pratiques de gestion des charges de travail
• GitHub : bigquery-slot-analysis