Vista TAREAS
La vista INFORMATION_SCHEMA.JOBS
contiene metadatos casi en tiempo real sobre todos los trabajos de BigQuery del proyecto actual.
Rol necesario
Para obtener el permiso que necesitas para consultar la vista INFORMATION_SCHEMA.JOBS
, pide a tu administrador que te asigne el rol de gestión de identidades y accesos Lector de recursos de BigQuery (roles/bigquery.resourceViewer
) en tu proyecto.
Para obtener más información sobre cómo conceder roles, consulta el artículo Gestionar el acceso a proyectos, carpetas y organizaciones.
Este rol predefinido contiene el permiso bigquery.jobs.listAll
INFORMATION_SCHEMA.JOBS
, que es necesario para consultar la vista bigquery.jobs.listAll
INFORMATION_SCHEMA.JOBS
.
También puedes obtener este permiso con roles personalizados u otros roles predefinidos.
Para obtener más información sobre los permisos de BigQuery, consulta Control de acceso con gestión de identidades y accesos.
Esquema
Los datos subyacentes se particionan por la columna creation_time
y se agrupan en clústeres por project_id
y user_email
. La columna query_info
contiene información adicional sobre los trabajos de consulta.
La vista INFORMATION_SCHEMA.JOBS
tiene el siguiente esquema:
Nombre de la columna | Data type (Dato) | Valor |
---|---|---|
bi_engine_statistics |
RECORD |
Si el proyecto está configurado para usar BI
Engine, este campo contiene BiEngineStatistics.
De lo contrario, NULL .
|
cache_hit |
BOOLEAN |
Indica si los resultados de la consulta de este trabajo procedían de una caché.
Si tienes un trabajo de instrucción de varias consultas, cache_hit de tu consulta principal es NULL .
|
creation_time |
TIMESTAMP |
(Columna de partición) Hora de creación de este trabajo. La partición se basa en la hora UTC de esta marca de tiempo. |
destination_table |
RECORD |
Tabla de destino de los resultados (si corresponde). |
end_time |
TIMESTAMP |
Hora de finalización de este trabajo, en milisegundos desde el inicio del registro de tiempo. Este campo representa la hora en la que el trabajo pasa al estado DONE . |
error_result |
RECORD |
Detalles de los errores como objetos ErrorProto. |
job_creation_reason.code |
STRING |
Especifica el motivo de alto nivel por el que se ha creado un trabajo. Los valores posibles son:
|
job_id |
STRING |
El ID del trabajo si se ha creado uno. De lo contrario, el ID de consulta de una consulta que usa el modo de creación de tareas opcional. Por ejemplo, bquxjob_1234 . |
job_stages |
RECORD |
Fases de la consulta de la tarea.
Nota: Los valores de esta columna están vacíos en las consultas que leen datos de tablas con políticas de acceso a nivel de fila. Para obtener más información, consulta las prácticas recomendadas para la seguridad a nivel de fila en BigQuery. |
job_type |
STRING |
El tipo de trabajo. Puede ser QUERY , LOAD , EXTRACT ,
COPY o NULL . Un valor NULL indica un trabajo en segundo plano.
|
labels |
RECORD |
Matriz de etiquetas aplicadas al trabajo como pares clave-valor. |
parent_job_id |
STRING |
ID del trabajo principal (si lo hay). |
priority |
STRING |
La prioridad de este trabajo. Los valores válidos son INTERACTIVE y BATCH . |
project_id |
STRING |
Columna de clustering: el ID del proyecto. |
project_number |
INTEGER |
El número del proyecto. |
query |
STRING |
Texto de la consulta de SQL. Solo la vista JOBS_BY_PROJECT tiene la columna de consulta. |
referenced_tables |
RECORD |
Matriz de tablas a las que hace referencia la tarea. Solo se rellena en el caso de las consultas que no se han encontrado en la caché. |
reservation_id |
STRING |
Nombre de la reserva principal asignada a este trabajo, con el formato RESERVATION_ADMIN_PROJECT:RESERVATION_LOCATION.RESERVATION_NAME .En este resultado:
|
edition |
STRING |
Edición asociada a la reserva asignada a este trabajo. Para obtener más información sobre las ediciones, consulta Introducción a las ediciones de BigQuery. |
session_info |
RECORD |
Detalles sobre la sesión en la que se ejecutó este trabajo, si la hubiera. |
start_time |
TIMESTAMP |
Hora de inicio de este trabajo, en milisegundos desde la época. Este campo representa la hora en la que la tarea pasa del estado PENDING a RUNNING o DONE . |
state |
STRING |
Estado de ejecución del trabajo. Los estados válidos son PENDING , RUNNING y DONE .
|
statement_type |
STRING |
El tipo de instrucción de consulta. Por ejemplo, DELETE , INSERT , SCRIPT , SELECT o UPDATE . Consulta QueryStatementType
para ver una lista de valores válidos.
|
timeline |
RECORD |
Cronología de la consulta de la tarea. Contiene instantáneas de la ejecución de consultas. |
total_bytes_billed |
INTEGER |
Si el proyecto está configurado para usar los precios bajo demanda, este campo contiene el total de bytes facturados por la tarea. Si el proyecto está configurado para usar precios de tarifa plana, no se te cobrarán los bytes y este campo solo tiene carácter informativo.
Nota: Los valores de esta columna están vacíos en las consultas que leen datos de tablas con políticas de acceso a nivel de fila. Para obtener más información, consulta las prácticas recomendadas para la seguridad a nivel de fila en BigQuery. |
total_bytes_processed |
INTEGER |
Total de bytes procesados por el trabajo. Nota: Los valores de esta columna están vacíos en las consultas que leen datos de tablas con políticas de acceso a nivel de fila. Para obtener más información, consulta las prácticas recomendadas para la seguridad a nivel de fila en BigQuery. |
total_modified_partitions |
INTEGER |
Número total de particiones que ha modificado la tarea. Este campo se rellena en los trabajos LOAD y QUERY .
|
total_slot_ms |
INTEGER |
Milisegundos de ranura de la tarea durante toda su duración en el estado RUNNING , incluidas las reintentos. |
transaction_id |
STRING |
ID de la transacción en la que se ha ejecutado este trabajo (si la hay). Vista previa |
user_email |
STRING |
Columna de clustering: dirección de correo o cuenta de servicio del usuario que ha ejecutado el trabajo. |
query_info.resource_warning |
STRING |
El mensaje de advertencia que aparece si el uso de recursos durante el procesamiento de la consulta supera el umbral interno del sistema. Si una tarea de consulta se completa correctamente, se rellena el campo resource_warning . Con resource_warning , obtienes puntos de datos adicionales para optimizar tus consultas y configurar la monitorización de las tendencias de rendimiento de un conjunto de consultas equivalente mediante query_hashes .
|
query_info.query_hashes.normalized_literals |
STRING |
Contiene el valor hash de la consulta. normalized_literals es un hash hexadecimal STRING que ignora los comentarios, los valores de los parámetros, las funciones definidas por el usuario y los literales.
El valor hash será diferente si cambian las vistas subyacentes o si la consulta hace referencia implícitamente a columnas, como SELECT * , y el esquema de la tabla cambia.
Este campo aparece en las consultas de GoogleSQL que se han realizado correctamente y que no son aciertos de caché. |
query_info.performance_insights |
RECORD |
Estadísticas de rendimiento de la tarea. |
query_info.optimization_details |
STRUCT |
Las optimizaciones basadas en el historial del trabajo. |
transferred_bytes |
INTEGER |
Total de bytes transferidos en consultas entre nubes, como las tareas de transferencia entre nubes de BigQuery Omni. |
materialized_view_statistics |
RECORD |
Estadísticas de las vistas materializadas que se han tenido en cuenta en un trabajo de consulta. Vista previa |
metadata_cache_statistics |
RECORD |
Estadísticas sobre el uso del índice de columnas de metadatos de las tablas a las que se hace referencia en un trabajo de consulta. |
search_statistics |
RECORD |
Estadísticas de una consulta de búsqueda. |
query_dialect |
STRING |
Este campo estará disponible en algún momento de mayo del 2025.
El dialecto de consulta que se ha usado en la tarea. Los valores válidos son los siguientes:
Este campo solo se rellena en las tareas de consulta. La selección predeterminada del dialecto de consulta se puede controlar mediante los ajustes de configuración. |
continuous |
BOOLEAN |
Si el trabajo es una consulta continua. |
continuous_query_info.output_watermark |
TIMESTAMP |
Representa el punto hasta el que la consulta continua ha procesado los datos correctamente. |
vector_search_statistics |
RECORD |
Estadísticas de una consulta de búsqueda de vectores. |
Cuando consulte INFORMATION_SCHEMA.JOBS
para obtener un coste resumido de los trabajos de consulta, excluya el tipo de instrucción SCRIPT
. De lo contrario, algunos valores podrían contabilizarse dos veces. La fila SCRIPT
incluye valores de resumen de todos los trabajos secundarios que se han ejecutado como parte de este trabajo.
Tareas de consulta con varias instrucciones
Un trabajo de consulta con varias instrucciones es un trabajo de consulta que usa el lenguaje de procedimiento.
Los trabajos de consulta con varias instrucciones suelen definir variables con DECLARE
o tener instrucciones de control de flujo, como IF
o WHILE
. Cuando envías una consulta
INFORMATION_SCHEMA.JOBS
, es posible que tengas que distinguir entre una
tarea de consulta con varias instrucciones y otras tareas. Un trabajo de consulta con varias instrucciones tiene las siguientes características:
statement_type
=SCRIPT
reservation_id
=NULL
Tareas secundarias
Cada uno de los trabajos secundarios de un trabajo de consulta con varias instrucciones tiene un parent_job_id
que apunta al trabajo de consulta con varias instrucciones. Esto incluye los valores de resumen de todas las tareas secundarias que se han ejecutado como parte de esta tarea.
Si consultas INFORMATION_SCHEMA.JOBS
para obtener un resumen del coste de las tareas de consulta, debes excluir el tipo de instrucción SCRIPT
. De lo contrario, algunos valores, como total_slot_ms
, podrían contabilizarse dos veces.
Conservación de datos
Esta vista contiene los trabajos que se están ejecutando y el historial de los últimos 180 días.
Ámbito y sintaxis
Las consultas en esta vista deben incluir un calificador de región. En la siguiente tabla se explica el ámbito de la región de esta vista:
Nombre de la vista | Ámbito de los recursos | Ámbito de la región |
---|---|---|
[PROJECT_ID.]`region-REGION`.INFORMATION_SCHEMA.JOBS[_BY_PROJECT] |
Nivel de proyecto | REGION |
-
Opcional:
PROJECT_ID
: el ID de tu Google Cloud proyecto. Si no se especifica, se usa el proyecto predeterminado. -
REGION
: cualquier nombre de región del conjunto de datos. Por ejemplo,`region-us`
.
Ejemplos
Para ejecutar la consulta en un proyecto que no sea el predeterminado, añade el ID del proyecto con el siguiente formato:
`PROJECT_ID`.`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
PROJECT_ID
: el ID del proyecto.REGION_NAME
: la región de tu proyecto.
Por ejemplo, `myproject`.`region-us-central1`.INFORMATION_SCHEMA.JOBS
.
Comparar el uso de tareas bajo demanda con los datos de facturación
En los proyectos que usan los precios bajo demanda, puedes usar la vista INFORMATION_SCHEMA.JOBS
para consultar los cargos por computación durante un periodo determinado.
En los proyectos que usan la tarifa basada en la capacidad (slots), puedes usar el INFORMATION_SCHEMA.RESERVATIONS_TIMELINE
para consultar los cargos de computación durante un periodo determinado.
La siguiente consulta genera agregaciones diarias estimadas de los TiBs facturados y los cargos resultantes. En la sección Limitaciones se explica cuándo es posible que estas estimaciones no coincidan con tu factura.
Solo en este ejemplo, se deben definir las siguientes variables adicionales. Puedes editarlos aquí para que te resulte más fácil usarlos.
START_DATE
: la fecha más antigua para agregar datos (inclusive).END_DATE
: la fecha más reciente para agregar datos (inclusive).PRICE_PER_TIB
: el precio bajo demanda por TiB que se usa para las estimaciones de facturación.
CREATE TEMP FUNCTION isBillable(error_result ANY TYPE) AS ( -- You aren't charged for queries that return an error. error_result IS NULL -- However, canceling a running query might incur charges. OR error_result.reason = 'stopped' ); -- BigQuery hides the number of bytes billed on all queries against tables with -- row-level security. CREATE TEMP FUNCTION isMaybeUsingRowLevelSecurity( job_type STRING, tib_billed FLOAT64, error_result ANY TYPE) AS ( job_type = 'QUERY' AND tib_billed IS NULL AND isBillable(error_result) ); WITH query_params AS ( SELECT date 'START_DATE' AS start_date, -- inclusive date 'END_DATE' AS end_date, -- inclusive ), usage_with_multiplier AS ( SELECT job_type, error_result, creation_time, -- Jobs are billed by end_time in PST8PDT timezone, regardless of where -- the job ran. EXTRACT(date FROM end_time AT TIME ZONE 'PST8PDT') billing_date, total_bytes_billed / 1024 / 1024 / 1024 / 1024 total_tib_billed, CASE statement_type WHEN 'SCRIPT' THEN 0 WHEN 'CREATE_MODEL' THEN 50 * PRICE_PER_TIB ELSE PRICE_PER_TIB END AS multiplier, FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS ) SELECT billing_date, sum(total_tib_billed * multiplier) estimated_charge, sum(total_tib_billed) estimated_usage_in_tib, countif(isMaybeUsingRowLevelSecurity(job_type, total_tib_billed, error_result)) AS jobs_using_row_level_security, FROM usage_with_multiplier, query_params WHERE 1 = 1 -- Filter by creation_time for partition pruning. AND date(creation_time) BETWEEN date_sub(start_date, INTERVAL 2 day) AND end_date AND billing_date BETWEEN start_date AND end_date AND isBillable(error_result) GROUP BY billing_date ORDER BY billing_date;
Limitaciones
BigQuery oculta algunas estadísticas de las consultas sobre tablas con seguridad a nivel de fila. La consulta proporcionada cuenta el número de trabajos afectados como
jobs_using_row_level_security
, pero no tiene acceso al uso facturable.El precio de BigQuery ML para las consultas bajo demanda depende del tipo de modelo que se cree.
INFORMATION_SCHEMA.JOBS
no registra qué tipo de modelo se ha creado, por lo que la consulta proporcionada da por hecho que todas las instrucciones CREATE_MODEL han creado los tipos de modelo con la facturación más alta.Los procedimientos de Apache Spark usan un modelo de precios similar, pero los cargos se registran como SKU de pago por uso de la edición Enterprise de BigQuery.
INFORMATION_SCHEMA.JOBS
registra este uso comototal_bytes_billed
, pero no puede determinar a qué SKU corresponde.
Calcular la utilización media de las ranuras
En el siguiente ejemplo se calcula la utilización media de las ranuras de todas las consultas de los últimos 7 días de un proyecto determinado. Ten en cuenta que este cálculo es más preciso en los proyectos que tienen un uso constante de las ranuras a lo largo de la semana. Si tu proyecto no tiene un uso de ranuras constante, este número puede ser inferior al esperado.
Para ejecutar la consulta, sigue estos pasos:
SELECT SUM(total_slot_ms) / (1000 * 60 * 60 * 24 * 7) AS avg_slots FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE -- Filter by the partition column first to limit the amount of data scanned. -- Eight days allows for jobs created before the 7 day end_time filter. creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 8 DAY) AND CURRENT_TIMESTAMP() AND job_type = 'QUERY' AND statement_type != 'SCRIPT' AND end_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) AND CURRENT_TIMESTAMP();
El resultado es similar al siguiente:
+------------+ | avg_slots | +------------+ | 3879.1534 | +------------+
Puedes consultar el uso de una reserva concreta con
WHERE reservation_id = "…"
. Esto puede ser útil para determinar el porcentaje de uso de una reserva durante un periodo. En el caso de las tareas de secuencias de comandos, la tarea principal también informa del uso total de ranuras de sus tareas secundarias. Para evitar que se contabilicen dos veces, usa WHERE statement_type != "SCRIPT"
para excluir el trabajo principal.
Si quieres consultar la utilización media de las ranuras de trabajos concretos, usa total_slot_ms / TIMESTAMP_DIFF(end_time, start_time, MILLISECOND)
.
Recuento de consultas activas recientes por prioridad de consulta
En el siguiente ejemplo se muestra el número de consultas agrupadas por prioridad (interactivas o por lotes) que se han iniciado en las últimas 7 horas:
SELECT priority, COUNT(*) active_jobs FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 hour) AND job_type = 'QUERY' GROUP BY priority;
El resultado es similar al siguiente:
+-------------+-------------+ | priority | active_jobs | +-------------+-------------+ | INTERACTIVE | 2 | | BATCH | 3 | +-------------+-------------+
El campo priority
indica si una consulta es INTERACTIVE
o BATCH
.
Ver el historial de tareas de carga
En el siguiente ejemplo se muestran todos los usuarios o cuentas de servicio que han enviado un trabajo de carga por lotes de un proyecto concreto. Como no se especifica ningún límite temporal, esta consulta analiza todo el historial disponible.
SELECT user_email AS user, COUNT(*) num_jobs FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE job_type = 'LOAD' GROUP BY user_email;
El resultado es similar al siguiente:
+--------------+ | user | +--------------+ | abc@xyz.com | | xyz@xyz.com | | bob@xyz.com | +--------------+
Obtener el número de tareas de carga para determinar la cuota de tareas diaria utilizada
En el siguiente ejemplo se devuelve el número de tareas por día, conjunto de datos y tabla para que pueda determinar qué parte de la cuota diaria de tareas se ha utilizado.
SELECT DATE(creation_time) as day, destination_table.project_id as project_id, destination_table.dataset_id as dataset_id, destination_table.table_id as table_id, COUNT(job_id) AS load_job_count FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 8 DAY) AND CURRENT_TIMESTAMP() AND job_type = "LOAD" GROUP BY day, project_id, dataset_id, table_id ORDER BY day DESC;
+-------------+------------+-------------+----------+-----------------+ |day | project_id | dataset_id | table_id | load_job_count | +-------------+------------+-------------+----------+-----------------+ | 2020-10-10 | my_project | dataset1 | orders | 58 | | 2020-10-10 | my_project | dataset1 | product | 20 | | 2020-10-10 | my_project | dataset1 | sales | 11 | +-------------+------------+-------------+----------+-----------------+
Obtener las últimas tareas fallidas
En el siguiente ejemplo se muestran los tres últimos trabajos fallidos:
SELECT job_id, creation_time, user_email, error_result FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE error_result.reason != "Null" ORDER BY creation_time DESC LIMIT 3;
Los resultados deberían ser similares a los siguientes:
+------------+--------------------------+------------------+-------------------------------------+ | job_id | creation_time | user_email | error_result | +------------+--------------------------+------------------+-------------------------------------+ | bquxjob_1 | 2020-10-10 00:00:00 UTC | abc@example.com | Column 'col1' has mismatched type...| | bquxjob_2 | 2020-10-11 00:00:00 UTC | xyz@example.com | Column 'col1' has mismatched type...| | bquxjob_3 | 2020-10-11 00:00:00 UTC | bob@example.com | Column 'col1' has mismatched type...| +------------+--------------------------+------------------+-------------------------------------+
Consultar la lista de trabajos de larga duración
En el siguiente ejemplo se muestra la lista de tareas de larga duración que están en estado RUNNING
o PENDING
durante más de 30 minutos:
SELECT job_id, job_type, state, creation_time, start_time, user_email FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE state!="DONE" AND creation_time <= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 MINUTE) ORDER BY creation_time ASC;
El resultado es similar al siguiente:
+-----------+----------+---------+--------------------------------+--------------------------------+------------------+ | job_id | job_type | state | creation_time | start_time | user_email | +-----------+----------+---------+--------------------------------+--------------------------------+------------------+ | bquxjob_1 | QUERY | RUNNING | 2023-05-03 05:07:22.818000 UTC | 2023-05-03 05:07:22.905000 UTC | abc@example.com | | bquxjob_2 | QUERY | PENDING | 2023-05-01 02:05:47.925000 UTC | 2023-05-01 02:05:47.998000 UTC | xyz@example.com | | bquxjob_3 | QUERY | PENDING | 2023-05-01 02:05:47.925000 UTC | 2023-05-01 02:05:47.998000 UTC | abc@example.com | +-----------+----------+---------+--------------------------------+--------------------------------+------------------+
Consultas que usan el modo de creación de tareas opcional
En el siguiente ejemplo se muestra una lista de consultas que se ejecutaron en el modo de creación de tareas opcional para las que BigQuery no creó tareas.
SELECT job_id, FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE TIMESTAMP_TRUNC(creation_time, DAY) = '2024-06-12' AND job_creation_reason.code IS NULL LIMIT 3;
Los resultados deberían tener este aspecto:
+-----------+ | job_id | | +-----------+ | bquxjob_1 | | bquxjob_2 | | bquxjob_3 | +-----------+
En el siguiente ejemplo se muestra información sobre una consulta que se ejecutó en el modo de creación de trabajos opcional y para la que BigQuery no creó ningún trabajo.
SELECT job_id, statement_type, priority, cache_hit, job_creation_reason.code AS job_creation_reason_code, total_bytes_billed, total_bytes_processed, total_slot_ms, state, error_result.message AS error_result_message, FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE TIMESTAMP_TRUNC(creation_time, DAY) = '2024-06-12' AND job_id = '2Lm09bHxDEsoVK8zwzWJomLHU_Ud%1910479b151' -- queryId
Nota: El campo job_id
contiene el queryId
de la consulta cuando no se ha creado ningún trabajo para esta consulta.
Los resultados deberían tener este aspecto:
+-----------+----------------+-------------+-----------+--------------------------+--------------------+---------------------+---------------+-------+----------------------+ | job_id | statement_type | priority | cache_hit | job_creation_reason_code | total_bytes_billed | total_bytes_processed | total_slot_ms | state | error_result_message | +-----------+----------------+-------------+-----------+--------------------------+--------------------+---------------------+---------------+-------+----------------------+ | bquxjob_1 | SELECT | INTERACTIVE | false | null | 161480704 | 161164718 | 3106 | DONE | null | +-----------+----------------+-------------+-----------+--------------------------+--------------------+---------------------+---------------+-------+----------------------+
En el siguiente ejemplo se muestra una lista de consultas que se ejecutaron en el modo de creación de tareas opcional para las que BigQuery creó tareas.
SELECT job_id, job_creation_reason.code AS job_creation_reason_code FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE TIMESTAMP_TRUNC(creation_time, DAY) = '2024-06-12' AND job_creation_reason.code IS NOT NULL AND job_creation_reason.code != 'REQUESTED' LIMIT 3
Los resultados deberían tener este aspecto:
+-----------+--------------------------+ | job_id | job_creation_reason_code | +-----------+--------------------------+ | bquxjob_1 | LARGE_RESULTS | | bquxjob_2 | LARGE_RESULTS | | bquxjob_3 | LARGE_RESULTS | +-----------+--------------------------+
Bytes procesados por identidad de usuario
En el siguiente ejemplo se muestra el total de bytes facturados por los trabajos de consulta por usuario:
SELECT user_email, SUM(total_bytes_billed) AS bytes_billed FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE job_type = 'QUERY' AND statement_type != 'SCRIPT' GROUP BY user_email;
Nota: Consulta la advertencia de la columna total_bytes_billed
en la documentación del esquema de las vistas JOBS
.
Los resultados deberían tener este aspecto:
+---------------------+--------------+ | user_email | bytes_billed | +---------------------+--------------+ | bob@example.com | 2847932416 | | alice@example.com | 1184890880 | | charles@example.com | 10485760 | +---------------------+--------------+
Desglose por horas de los bytes procesados
En el siguiente ejemplo se muestra el total de bytes facturados de los trabajos de consulta en intervalos horarios:
SELECT TIMESTAMP_TRUNC(end_time, HOUR) AS time_window, SUM(total_bytes_billed) AS bytes_billed FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE job_type = 'QUERY' AND statement_type != 'SCRIPT' GROUP BY time_window ORDER BY time_window DESC;
El resultado es similar al siguiente:
+-------------------------+--------------+ | time_window | bytes_billed | +-------------------------+--------------+ | 2022-05-17 20:00:00 UTC | 1967128576 | | 2022-05-10 21:00:00 UTC | 0 | | 2022-04-15 17:00:00 UTC | 41943040 | +-------------------------+--------------+
Tareas de consulta por tabla
En el siguiente ejemplo se muestra cuántas veces se ha hecho referencia a cada tabla consultada en my_project
en un trabajo de consulta:
SELECT t.project_id, t.dataset_id, t.table_id, COUNT(*) AS num_references FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS, UNNEST(referenced_tables) AS t GROUP BY t.project_id, t.dataset_id, t.table_id ORDER BY num_references DESC;
El resultado es similar al siguiente:
+------------+------------+----------+----------------+ | project_id | dataset_id | table_id | num_references | +------------+------------+----------+----------------+ | my_project | dataset1 | orders | 58 | | my_project | dataset1 | products | 40 | | other_proj | dataset1 | accounts | 12 | +------------+------------+----------+----------------+
Número de tareas de consulta de SQL antiguo por proyecto
El campo "query_dialect" de INFORMATION_SCHEMA estará disponible en algún momento de mayo del 2025. En el siguiente ejemplo se muestra cuántos trabajos de consulta de SQL antiguo se ejecutan en proyectos.
SELECT project_id, -- Implicitly defaulted to LegacySQL since the query dialect was not specified -- in the request. COUNTIF(query_dialect = 'DEFAULT_LEGACY_SQL') AS default_legacysql_query_jobs, -- Explicitly requested LegacySQL. COUNTIF(query_dialect = 'LEGACY_SQL') AS legacysql_query_jobs, FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE query_dialect = 'DEFAULT_LEGACY_SQL' OR query_dialect = 'LEGACY_SQL' GROUP BY project_id ORDER BY default_legacysql_query_jobs DESC, legacysql_query_jobs DESC;
Número de particiones modificadas por tareas de consulta y carga por tabla
En el siguiente ejemplo se muestra el número de particiones modificadas por consultas con declaraciones de DML y tareas de carga por tabla. Ten en cuenta que esta consulta no muestra
el total_modified_partitions
de los trabajos de copia.
SELECT destination_table.table_id, SUM(total_modified_partitions) AS total_modified_partitions FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE DATE(creation_time, "America/Los_Angeles") = CURRENT_DATE() GROUP BY table_id ORDER BY total_modified_partitions DESC
Número medio de ranuras por milisegundo que usa un trabajo.
En el siguiente ejemplo se muestra cómo calcular el número medio de ranuras que usa un trabajo durante la ejecución. Esto puede ser útil para solucionar problemas de consultas lentas y comparar la ejecución lenta de una consulta con la ejecución más rápida de la misma consulta. Comparar este valor con el tamaño total de la reserva y el número medio de trabajos simultáneos ejecutados en el proyecto o la reserva puede ayudarte a saber si varias consultas competían por los espacios al mismo tiempo durante la ejecución.
Un número medio de ranuras más alto significa que se asignan más recursos al trabajo, lo que suele dar como resultado una ejecución más rápida.
SELECT ROUND(SAFE_DIVIDE(total_slot_ms,TIMESTAMP_DIFF(end_time, start_time, MILLISECOND)), 1) as avg_slots_per_ms FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE job_id = 'JOB_ID'
Sustituye JOB_ID
por la job_id
que estés investigando.
El resultado será similar al siguiente:
+------------------+ | avg_slots_per_ms | +------------------+ | 17.0 | +------------------+
Consultas más caras por proyecto
En el siguiente ejemplo se muestran las consultas más caras de my_project
por tiempo de uso de ranura:
SELECT job_id, query, user_email, total_slot_ms FROM `my_project`.`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE EXTRACT(DATE FROM creation_time) = current_date() ORDER BY total_slot_ms DESC LIMIT 3
También puede enumerar las consultas más caras por datos procesados con el siguiente ejemplo:
SELECT job_id, query, user_email, total_bytes_processed FROM `my_project`.`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE EXTRACT(DATE FROM creation_time) = current_date() ORDER BY total_bytes_processed DESC LIMIT 3
El resultado de cualquiera de los ejemplos es similar al siguiente:
+-----------+---------------------------------+-----------------------+---------------+ | job_id | query | user_email | total_slot_ms | +-----------+---------------------------------+--------------------------+------------+ | bquxjob_1 | SELECT ... FROM dataset.table1 | bob@example.com | 80,000 | | bquxjob_2 | SELECT ... FROM dataset.table2 | alice@example.com | 78,000 | | bquxjob_3 | SELECT ... FROM dataset.table3 | charles@example.com | 75,000 | +-----------+---------------------------------+-----------------------+---------------+
Obtener detalles sobre una advertencia de recursos
Si aparece el mensaje de error Recursos superados, puedes consultar las consultas en un periodo determinado:
SELECT query, query_info.resource_warning FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE creation_time BETWEEN TIMESTAMP("2022-12-01") AND TIMESTAMP("2022-12-08") AND query_info.resource_warning IS NOT NULL LIMIT 3;
Monitorizar las advertencias de recursos agrupadas por fecha
Si recibes el mensaje de error Recursos superados, puedes monitorizar el número total de advertencias de recursos agrupadas por fecha para saber si hay algún cambio en la carga de trabajo:
WITH resource_warnings AS ( SELECT EXTRACT(DATE FROM creation_time) AS creation_date FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 14 DAY) AND query_info.resource_warning IS NOT NULL ) SELECT creation_date, COUNT(1) AS warning_counts FROM resource_warnings GROUP BY creation_date ORDER BY creation_date DESC;
Estimar el uso y el coste de las ranuras de las consultas
En el siguiente ejemplo se calcula el número medio y máximo de ranuras de cada trabajo mediante estimated_runnable_units
.
El reservation_id
es NULL
si no tienes ninguna reserva.
SELECT project_id, job_id, reservation_id, EXTRACT(DATE FROM creation_time) AS creation_date, TIMESTAMP_DIFF(end_time, start_time, SECOND) AS job_duration_seconds, job_type, user_email, total_bytes_billed, -- Average slot utilization per job is calculated by dividing total_slot_ms by the millisecond duration of the job SAFE_DIVIDE(job.total_slot_ms,(TIMESTAMP_DIFF(job.end_time, job.start_time, MILLISECOND))) AS job_avg_slots, query, -- Determine the max number of slots used at ANY stage in the query. -- The average slots might be 55. But a single stage might spike to 2000 slots. -- This is important to know when estimating number of slots to purchase. MAX(SAFE_DIVIDE(unnest_job_stages.slot_ms,unnest_job_stages.end_ms - unnest_job_stages.start_ms)) AS jobstage_max_slots, -- Check if there's a job that requests more units of works (slots). If so you need more slots. -- estimated_runnable_units = Units of work that can be scheduled immediately. -- Providing additional slots for these units of work accelerates the query, -- if no other query in the reservation needs additional slots. MAX(unnest_timeline.estimated_runnable_units) AS estimated_runnable_units FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS AS job CROSS JOIN UNNEST(job_stages) as unnest_job_stages CROSS JOIN UNNEST(timeline) AS unnest_timeline WHERE DATE(creation_time) BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) AND CURRENT_DATE() AND project_id = 'my_project' AND (statement_type != 'SCRIPT' OR statement_type IS NULL) GROUP BY 1,2,3,4,5,6,7,8,9,10 ORDER BY job_id;
El resultado, por ejemplo, es similar al siguiente:
+-----------+-----------+----------------+---------------+----------------------+----------+-----------------+--------------------+--------------+--------------------------------+--------------------+--------------------------+ |project_id | job_id | reservation_id | creation_date | job_duration_seconds | job_type | user_email | total_bytes_billed | job_avg_slots| query | jobstage_max_slots | estimated_runnable_units | +-----------+-----------+----------------+---------------+----------------------+----------+-----------------+--------------------+--------------+--------------------------------+--------------------+--------------------------+ | project1 | bquxjob1 | reservation1 | 2020-10-10 | 160 | LOAD | abc@example.com | 161480704 | 2890 | SELECT ... FROM dataset.table1 | 2779.1534 | 1000 | | project1 | bquxjob2 | reservation2 | 2020-12-10 | 120 | LOAD | abc@example.com | 161480704 | 2890 | SELECT ... FROM dataset.table1 | 2779.1534 | 1000 | | project1 | bquxjob3 | reservation1 | 2020-12-10 | 120 | LOAD | abc@example.com | 161480704 | 2890 | SELECT ... FROM dataset.table1 | 1279.1534 | 998 | +-----------+-----------+----------------+---------------+----------------------+----------+-----------------+--------------------+--------------+--------------------------------+--------------------+--------------------------+
Ver estadísticas de rendimiento de las consultas
En el siguiente ejemplo, se devuelven todos los trabajos de consulta que tienen estadísticas de rendimiento de tu proyecto en los últimos 30 días, junto con una URL que enlaza al gráfico de ejecución de la consulta en la consola de Google Cloud .
SELECT `bigquery-public-data`.persistent_udfs.job_url( project_id || ':us.' || job_id) AS job_url, query_info.performance_insights FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE DATE(creation_time) >= CURRENT_DATE - 30 -- scan 30 days of query history AND job_type = 'QUERY' AND state = 'DONE' AND error_result IS NULL AND statement_type != 'SCRIPT' AND EXISTS ( -- Only include queries which had performance insights SELECT 1 FROM UNNEST( query_info.performance_insights.stage_performance_standalone_insights ) WHERE slot_contention OR insufficient_shuffle_quota UNION ALL SELECT 1 FROM UNNEST( query_info.performance_insights.stage_performance_change_insights ) WHERE input_data_change.records_read_diff_percentage IS NOT NULL );
Ver tareas de actualización de metadatos
En el siguiente ejemplo se enumeran las tareas de actualización de metadatos de las últimas seis horas:
SELECT * FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE job_id LIKE '%metadata_cache_refresh%' AND creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR) ORDER BY start_time desc LIMIT 10;
Sustituye REGION_NAME por tu región.
Analizar el rendimiento a lo largo del tiempo de consultas idénticas
En el siguiente ejemplo se devuelven los 10 trabajos más lentos de los últimos 7 días que han ejecutado la misma consulta:
DECLARE querytext STRING DEFAULT( SELECT query FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE job_id = 'JOB_ID' LIMIT 1 ); SELECT start_time, end_time, project_id, job_id, TIMESTAMP_DIFF(end_time, start_time, SECOND) AS run_secs, total_bytes_processed / POW(1024, 3) AS total_gigabytes_processed, query FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE query = querytext AND total_bytes_processed > 0 AND creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) ORDER BY 5 DESC LIMIT 3;
Sustituye JOB_ID
por cualquier job_id
que haya ejecutado la consulta que estás analizando.
Los 5 trabajos que han analizado más bytes hoy
En el siguiente ejemplo se muestra cómo encontrar los cinco trabajos que han analizado la mayor cantidad de bytes en una organización durante el día actual. Puedes aplicar más filtros en statement_type
para consultar información adicional, como cargas, exportaciones y consultas.
SELECT job_id, user_email, total_bytes_billed FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_ORGANIZATION WHERE EXTRACT(DATE FROM creation_time) = current_date() ORDER BY total_bytes_billed DESC LIMIT 3;
El resultado es similar al siguiente:
+--------------+--------------+---------------------------+ | job_id | user_email | total_bytes_billed | +--------------+--------------+---------------------------+ | bquxjob_1 | abc@xyz.com | 999999 | | bquxjob_2 | def@xyz.com | 888888 | | bquxjob_3 | ghi@xyz.com | 777777 | +--------------+--------------+---------------------------+
Ver tareas pendientes o en curso
SELECT job_id, creation_time, query FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_USER WHERE state != 'DONE';
El resultado es similar al siguiente:
+--------------+---------------------------+---------------------------------+ | job_id | creation_time | query | +--------------+---------------------------+---------------------------------+ | bquxjob_1 | 2019-10-10 00:00:00 UTC | SELECT ... FROM dataset.table1 | | bquxjob_2 | 2019-10-10 00:00:01 UTC | SELECT ... FROM dataset.table2 | | bquxjob_3 | 2019-10-10 00:00:02 UTC | SELECT ... FROM dataset.table3 | +--------------+---------------------------+---------------------------------+
Ver las tareas con estadísticas de contención de slots
Para ver los trabajos con sus estadísticas de contención de ranuras, ejecuta la siguiente consulta:
SELECT job_id, creation_time, query_info.performance_insights, FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS j, UNNEST(query_info.performance_insights.stage_performance_standalone_insights) i WHERE (j.statement_type != "SCRIPT" OR j.statement_type IS NULL) AND i IS NOT NULL AND i.slot_contention
El resultado muestra diferentes estadísticas de rendimiento sobre los trabajos, incluida la contención de ranuras:
+------------+-------------------------+-------------------------------------------------+----------------------------------------------------------------------------+ | job_id | creation_time | performance_insights.avg_previous_execution_ms | performance_insightsstage_performance_standalone_insights.slot_contention | +------------+-------------------------+-------------------------------------------------+----------------------------------------------------------------------------+ | bquxjob_1 | 2025-08-08 00:00:00 UTC | null | true | | bquxjob_2 | 2025-08-08 00:00:00 UTC | 42689 | true | | bquxjob_3 | 2025-08-08 00:00:00 UTC | 42896 | true | +------------+-------------------------+-------------------------------------------------+----------------------------------------------------------------------------+
Ver el número medio de tareas simultáneas que se ejecutan junto con una tarea concreta en el mismo proyecto
En el siguiente ejemplo se muestra cómo calcular el número medio de tareas que se ejecutan al mismo tiempo que una tarea de consulta específica en el mismo proyecto.
Este cálculo ayuda a determinar si un mayor número de trabajos simultáneos en el mismo proyecto ha provocado problemas de contención de ranuras. Recoge estos datos cuando tengas que solucionar problemas con consultas lentas o comparar ejecuciones de consultas lentas y rápidas.
Si se están ejecutando muchas más consultas simultáneas de lo esperado, comprueba si se han iniciado más trabajos, si han cambiado los datos consultados o ambas cosas.
WITH job_metadata AS ( SELECT creation_time, end_time, job_type FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE job_id = 'JOB_ID' -- If you know the date the job was created, add the following line to speed up the query by providing the date in UTC: -- AND DATE(creation_time) = 'YYYY-MM-DD' ), intervals AS ( SELECT TIMESTAMP_ADD(creation_time, INTERVAL (seconds_offset) SECOND) AS ts, job_type FROM job_metadata, UNNEST (GENERATE_ARRAY(0, IF(TIMESTAMP_DIFF(end_time, creation_time, SECOND) > 0, TIMESTAMP_DIFF(end_time, creation_time, SECOND), 1))) as seconds_offset ), concurrent_jobs AS ( SELECT int.ts, COUNT(*) as concurrent_jobs_count FROM intervals int JOIN `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT j ON int.ts BETWEEN j.creation_time and j.end_time WHERE job_id != 'JOB_ID' AND j.job_type = int.job_type GROUP BY int.ts) SELECT ROUND(AVG(concurrent_jobs_count),1) as average_concurrent_jobs FROM concurrent_jobs
Haz los cambios siguientes:
JOB_ID
: el ID del trabajo de la consulta que está analizandoREGION_NAME
: la región de tu proyecto
El resultado es similar al siguiente:
+-------------------------+ | average_concurrent_jobs | +-------------------------+ | 2.8 | +-------------------------+
Obtener los bytes procesados por las tareas de exportación
En el siguiente ejemplo se calcula el valor de total_bytes_processed
para los tipos de trabajo EXTRACT
. Para obtener información sobre las cuotas de los trabajos de exportación, consulta el artículo Política de cuotas para trabajos de exportación.
El total de bytes procesados se puede usar para monitorizar el uso agregado y verificar que las tareas de exportación no superen el límite de 50 TB al día:
SELECT DATE(creation_time) as day, project_id as source_project_id, SUM(total_bytes_processed) AS total_bytes_processed FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 8 DAY) AND CURRENT_TIMESTAMP() AND job_type = "EXTRACT" GROUP BY day, source_project_id ORDER BY day DESC;
Obtener el uso de las tareas de copia
Para obtener información sobre los trabajos de copia, consulta Copiar una tabla. En el siguiente ejemplo se muestra el uso de los trabajos de copia:
SELECT DATE(creation_time) as day, project_id as source_project_id, CONCAT(destination_table.project_id,":",destination_table.dataset_id,".",destination_table.table_id) as destination_table, COUNT(job_id) AS copy_job_count FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 8 DAY) AND CURRENT_TIMESTAMP() AND job_type = "COPY" GROUP BY day, source_project_id, destination_table ORDER BY day DESC;
Obtener el uso de las tablas de BigLake para Apache Iceberg en la optimización del almacenamiento de BigQuery
En el siguiente ejemplo se muestra el uso de la tabla de Iceberg de BigLake en la optimización del almacenamiento de BigQuery.
SELECT job_id, reservation_id, edition, total_slot_ms, total_bytes_processed, state FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR) AND user_email = "bigquery-adminbot@system.gserviceaccount.com" AND query LIKE "CALL BQ.OPTIMIZE_STORAGE(%)";
Obtener el uso de la tabla Iceberg de BigLake en los metadatos de la tabla de exportación de BigQuery
En el siguiente ejemplo se muestra el uso de Iceberg EXPORT TABLE METADATA FROM
.
SELECT job_id, user_email, start_time, end_time, TIMESTAMP_DIFF(end_time, start_time, SECOND) AS duration_seconds, total_bytes_processed, reservation_id, CASE WHEN reservation_id IS NULL THEN 'PAYG (On-demand)' WHEN reservation_id != '' THEN 'Reservation' ELSE 'Unknown' END AS compute_type, query FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE job_type = 'QUERY' AND end_time IS NOT NULL -- Filter for queries containing the specified pattern (case-insensitive) AND REGEXP_CONTAINS(LOWER(query), r"export table metadata from") ORDER BY start_time DESC LIMIT 3;
Coincidir con el comportamiento de uso de las ranuras de los gráficos de recursos administrativos
Para consultar el comportamiento de uso de los espacios publicitarios de forma similar a la información de los gráficos de recursos administrativos, consulta la vista INFORMATION_SCHEMA.JOBS_TIMELINE
.