Top consultas de BigQuery por duración

Por qué importa

El tiempo de ejecución importa más allá del costo. Una consulta que se ejecuta durante 30 minutos bloquea un pipeline de datos, retrasa actualizaciones del panel o causa que un analista cambie de contexto. Bajo la tarificación Editions, las consultas de larga duración también consumen más horas-slot (facturación mínima de 1 minuto). Reducir la duración de las consultas mejora tanto el costo como la productividad.

Cómo funciona

La consulta calcula el tiempo de ejecución como TIMESTAMP_DIFF entre end_time y start_time. También calcula un ratio segundos por GiB: valores altos indican consultas lentas en relación con la cantidad de datos que procesan, sugiriendo potencial de optimización.

Consulta 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,
...

Explicación de la consulta

Dos niveles de deduplicación: primero por job_id para eliminar entradas de trabajo duplicadas, luego por texto de consulta para mostrar solo la ejecución más costosa de cada consulta única. La métrica sec_per_gib divide el tiempo de ejecución por bytes facturados — valores altos significan que la consulta es lenta en relación con cuántos datos lee.

Puntos clave

• lightbulb

  Las consultas de más de 10 minutos probablemente están analizando tablas no particionadas o realizando shuffles costosos.

• lightbulb

  Un alto sec_per_gib significa que la consulta está limitada por cómputo (JOINs complejos, ordenaciones, funciones de ventana) en lugar de I/O.

• lightbulb

  Un bajo sec_per_gib significa que la consulta está analizando muchos datos rápidamente — podría beneficiarse de la poda de particiones.

• lightbulb

  Las consultas de larga duración en pipelines pueden cascadear retrasos a todas las dependencias aguas abajo.

Mejores prácticas

1. 1

   Establezca límites de tiempo de espera para evitar que consultas descontroladas consuman recursos indefinidamente.

2. 2

   Para pipelines ETL, divida las consultas monolíticas de larga duración en transformaciones más pequeñas y escalonadas.

3. 3

   Use EXPLAIN PLAN para identificar las etapas más lentas y optimizarlas específicamente.

4. 4

   Considere funciones de agregación aproximadas (APPROX_QUANTILES, APPROX_TOP_COUNT) para consultas exploratorias.

Guías relacionadas