Top requêtes BigQuery par durée

Pourquoi c'est important

Le temps d'exécution compte au-delà du coût. Une requête s'exécutant pendant 30 minutes bloque un pipeline de données, retarde les actualisations de tableau de bord ou oblige un analyste à changer de contexte. Sous la tarification Editions, les requêtes longues consomment également plus d'heures-slots (facturation minimum de 1 minute). Réduire la durée des requêtes améliore à la fois le coût et la productivité.

Comment ça fonctionne

La requête calcule le temps d'exécution comme TIMESTAMP_DIFF entre end_time et start_time. Elle calcule également un ratio secondes-par-Gio : des valeurs élevées indiquent des requêtes lentes par rapport à la quantité de données qu'elles traitent, suggérant un potentiel d'optimisation.

Requête SQL

-- Slowest queries ranked by wall-clock execution time

DECLARE lookback_days INT64 DEFAULT 7;

WITH jobs AS (
  SELECT
    user_email,
    query,
    project_id,
    start_time,
    end_time,
    TIMESTAMP_DIFF(end_time, start_time, SECOND) AS duration_sec,
    COALESCE(total_bytes_billed, 0) AS bytes_billed,
    total_slot_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
),
deduplicated AS (
  SELECT *, ROW_NUMBER() OVER (PARTITION BY query ORDER BY bytes_billed DESC) AS qrn
  FROM jobs WHERE rn = 1
)
SELECT
  user_email,
  query,
  project_id,
  start_time,
  duration_sec,
  ROUND(SAFE_DIVIDE(total_slot_ms, duration_sec * 1000), 0) AS avg_slots,
...

Explication de la requête

Deux niveaux de déduplication : d'abord par job_id pour supprimer les entrées de job dupliquées, puis par texte de requête pour ne montrer que l'exécution la plus coûteuse de chaque requête unique. La métrique sec_per_gib divise le temps d'exécution par les octets facturés — des valeurs élevées signifient que la requête est lente par rapport à la quantité de données qu'elle lit.

Points clés

• lightbulb

  Les requêtes de plus de 10 minutes analysent probablement des tables non partitionnées ou effectuent des shuffles coûteux.

• lightbulb

  Un sec_per_gib élevé signifie que la requête est limitée par le calcul (JOINs complexes, tris, fonctions de fenêtrage) plutôt que par les I/O.

• lightbulb

  Un sec_per_gib faible signifie que la requête analyse beaucoup de données rapidement — elle pourrait bénéficier de la pruning de partitions.

• lightbulb

  Les requêtes longues dans les pipelines peuvent cascader des retards à toutes les dépendances en aval.

Meilleures pratiques

1. 1

   Définissez des limites de timeout pour empêcher les requêtes incontrôlables de consommer des ressources indéfiniment.

2. 2

   Pour les pipelines ETL, décomposez les requêtes monolithiques longues en transformations plus petites et étagées.

3. 3

   Utilisez EXPLAIN PLAN pour identifier les étapes les plus lentes et les optimiser spécifiquement.

4. 4

   Envisagez des fonctions d'agrégation approximatives (APPROX_QUANTILES, APPROX_TOP_COUNT) pour les requêtes exploratoires.

Guides associés