Surveillance de l'utilisation des slots BigQuery

Les décisions d’allocation des slots nécessitent de comprendre l’utilisation actuelle. BigQuery fournit de l’observabilité via les vues INFORMATION_SCHEMA, un Slot Estimator intégré et une intégration avec Cloud Monitoring.

Tables INFORMATION_SCHEMA clés

Ce sont vos outils principaux pour comprendre la consommation de slots :

La vue JOBS_TIMELINE est particulièrement précieuse pour la planification de capacité car elle montre votre pattern de concurrence réel — pas seulement l’utilisation agrégée des slots, mais comment elle évolue seconde par seconde tout au long de la journée.

Identifier les jobs les plus gourmands en slots

Cette requête montre vos jobs les plus consommateurs de 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;

Le calcul avg_slots (total des slot-millisecondes divisé par le temps d’horloge) vous donne le nombre moyen de slots utilisés par chaque job. C’est le nombre dont vous avez besoin pour la planification de capacité. Un job avec un avg_slots de 500 fonctionnant pendant 30 minutes nécessite une réservation capable de fournir au moins 500 slots pendant cette fenêtre.

La colonne reservation_id indique quelle réservation a servi le job. Si elle est nulle, le job s’est exécuté en tarification on-demand. Cela vous aide à vérifier si les jobs atterrissent dans les bonnes réservations.

Utilisation horaire des slots

Voyez comment votre utilisation des slots varie tout au long 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;

Cette requête révèle votre pattern d’utilisation quotidien. La plupart des équipes observent des pics clairs pendant les heures ouvrables et des creux la nuit. La différence entre les pics et les creux détermine la quantité de capacité baseline vs. autoscaling dont vous avez besoin.

Si votre utilisation est relativement stable (ex. ETL tournant 24h/24), une allocation avec un baseline important et un autoscaling minimal est économique. Si l’utilisation est multipliée par 5 pendant les heures de bureau, un baseline plus faible avec une marge d’autoscaling généreuse est plus judicieux.

Résumé rapide de l’utilisation des slots

Un aperçu rapide de votre consommation de slots récente :

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;

Observez la tendance de total_slot_hours sur les jours. Si elle augmente régulièrement, votre workload s’étend et vous devez planifier la capacité en conséquence. La métrique avg_slots_per_job indique si vous exécutez de nombreuses petites requêtes (faible moyenne) ou moins de grandes requêtes (haute moyenne) — cela oriente votre configuration d’autoscaling.

L’outil Slot Estimator

Le Slot Estimator est utile pour la planification de capacité avant de s’engager sur un achat.

Pour y accéder :

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

Ce qu’il montre :

• L’utilisation des slots sur les 30 derniers jours
• Les périodes d’utilisation maximale
• Les percentiles de latence des jobs (P90, P95, etc.)
• La modélisation de l’impact sur les performances (“que se passerait-il si vous ajoutiez 200 slots ?”)
• Les recommandations optimales en termes de coût

La modélisation de l’impact sur les performances permet de simuler l’ajout ou la suppression de slots pour projeter l’effet sur la latence des jobs. Elle est basée sur 30 jours d’utilisation historique. Utilisez-la avant d’acheter des engagements ou d’ajuster les baselines.

Intégration Cloud Monitoring

Pour une observabilité continue et en temps réel, BigQuery expose des métriques dans Cloud Monitoring :

• bigquery.googleapis.com/slots/allocated — nombre de slots actuellement utilisés
• bigquery.googleapis.com/slots/available — nombre de slots disponibles dans la réservation
• bigquery.googleapis.com/job/num_in_flight — nombre de jobs actuellement en cours

Avec ces métriques, vous pouvez :

• Construire des tableaux de bord montrant l’utilisation des slots en temps réel aux côtés de la capacité des réservations
• Configurer des alertes pour la contention de slots (ex. lorsque les slots alloués approchent les slots disponibles pendant plus de 5 minutes)
• Suivre les tendances d’utilisation sur des semaines et des mois pour la planification de capacité

Une configuration d’alerte pratique : déclenchez un avertissement lorsque slots/allocated dépasse 80 % de slots/available pendant plus de 10 minutes pendant les heures ouvrables. Cela vous donne une alerte précoce de contention avant qu’elle n’impacte les performances des requêtes.

Surveillance spécifique à dbt

Lors de l’exécution de dbt sur BigQuery, combinez la surveillance des slots avec les labels de jobs de dbt pour comprendre quels modèles pilotent la consommation de slots :

SELECT
  (SELECT value FROM UNNEST(labels) WHERE key = 'dbt_model') AS model,
  COUNT(*) AS runs,
  AVG(SAFE_DIVIDE(total_slot_ms,
    TIMESTAMP_DIFF(end_time, start_time, MILLISECOND))) AS avg_slots,
  MAX(SAFE_DIVIDE(total_slot_ms,
    TIMESTAMP_DIFF(end_time, start_time, MILLISECOND))) AS peak_slots,
  SUM(total_slot_ms) / 1000 / 60 AS total_slot_minutes
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_model') IS NOT NULL
GROUP BY model
ORDER BY total_slot_minutes DESC
LIMIT 20;

La colonne peak_slots révèle quels modèles ont la demande de pointe la plus élevée. Si un modèle atteint 800 slots en pic tandis que tout le reste reste sous 200, ce modèle est votre moteur d’autoscaling. L’optimiser (meilleur partitionnement, incrémental au lieu de full refresh, SQL plus efficace) pourrait vous permettre de réduire votre maximum d’autoscaling.

Exécutez ces requêtes avant d’effectuer des changements de capacité, puis à nouveau après pour mesurer l’impact.