Top requêtes BigQuery par complexité

Pourquoi c'est important

Les requêtes à slots élevés affectent tout le monde dans votre projet. Sous la tarification à la demande, elles rivalisent pour votre allocation de slots par quota (typiquement 2 000 slots). Sous la tarification Editions, elles consomment directement votre capacité réservée. Identifier et optimiser les requêtes complexes améliore les performances pour tous les utilisateurs et réduit les coûts sous les deux modèles de facturation.

Comment ça fonctionne

Le nombre approximatif de slots est calculé en divisant total_slot_ms par le temps d'exécution en millisecondes. Une requête utilisant 1 000 slot-millisecondes pendant 1 seconde a utilisé environ 1 slot en moyenne. Cette métrique capture le parallélisme et le poids computationnel de chaque requête.

Requête SQL

-- Queries ranked by average slot consumption (most compute-heavy first)

DECLARE lookback_days INT64 DEFAULT 14;

WITH jobs AS (
  SELECT
    user_email,
    query,
    project_id,
    start_time,
    end_time,
    total_slot_ms,
    COALESCE(total_bytes_billed, 0) AS bytes_billed,
    TIMESTAMP_DIFF(end_time, start_time, MILLISECOND) AS duration_ms,
    ROW_NUMBER() OVER (PARTITION BY job_id ORDER BY end_time DESC) AS rn
  FROM `your-project`.`region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
  WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL lookback_days DAY)
    AND job_type = 'QUERY' AND state = 'DONE' AND total_slot_ms IS NOT NULL
)
SELECT
  user_email,
  query,
  project_id,
  start_time,
  end_time,
  ROUND(SAFE_DIVIDE(total_slot_ms, duration_ms), 0) AS avg_slots,
  ROUND(duration_ms / 1000, 1) AS duration_sec,
  ROUND(bytes_billed / POW(1024, 4) * 6.25, 2) AS on_demand_cost_usd
FROM jobs
WHERE rn = 1
...

Explication de la requête

La formule centrale est SAFE_DIVIDE(total_slot_ms, duration_ms). Si une requête a utilisé 10 000 slot-millisecondes pendant 100 millisecondes, son nombre approximatif de slots est 100 — ce qui signifie qu'elle a utilisé environ 100 slots simultanément. Des nombres plus élevés indiquent plus de parallélisme et une demande computationnelle plus importante.

Points clés

• lightbulb

  Les requêtes avec >500 slots sont considérées comme très complexes et peuvent bénéficier d'une réécriture.

• lightbulb

  Un nombre élevé de slots avec peu d'octets facturés suggère des opérations intensives en calcul : JOINs complexes, fonctions de fenêtrage ou DISTINCT sur de grands ensembles de données.

• lightbulb

  Un nombre élevé de slots avec beaucoup d'octets facturés indique des problèmes de volume de données et de calcul — les plus grandes cibles d'optimisation.

• lightbulb

  Comparez le nombre de slots au temps d'exécution : si les slots sont élevés mais l'exécution rapide, la requête est parallèle efficacement mais gourmande en ressources.

Meilleures pratiques

1. 1

   Simplifiez les JOINs multi-directionnels en pré-agrégeant ou en utilisant des tables intermédiaires.

2. 2

   Remplacez COUNT(DISTINCT ...) exact par APPROX_COUNT_DISTINCT() lorsque la précision n'est pas critique.

3. 3

   Évitez les sous-requêtes corrélées — réécrivez-les sous forme de JOINs ou de fonctions de fenêtrage.

4. 4

   Utilisez le clustering sur les clés de JOIN pour réduire les opérations de shuffle.

Guides associés