Vue JOBS
La vue INFORMATION_SCHEMA.JOBS
contient les métadonnées en temps quasi réel sur tous les jobs BigQuery du projet en cours.
Rôle requis
Pour obtenir l'autorisation dont vous avez besoin pour interroger la vue INFORMATION_SCHEMA.JOBS
, demandez à votre administrateur de vous attribuer le rôle IAM Lecteur de ressources BigQuery (roles/bigquery.resourceViewer
) sur votre projet.
Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.
Ce rôle prédéfini contient l'autorisation bigquery.jobs.listAll
, qui est nécessaire pour interroger la vue INFORMATION_SCHEMA.JOBS
.
Vous pouvez également obtenir cette autorisation avec des rôles personnalisés ou d'autres rôles prédéfinis.
Pour plus d'informations sur les autorisations BigQuery, consultez la page Contrôle des accès avec IAM.
Schéma
Les données sous-jacentes sont partitionnées par la colonne creation_time
et mises en cluster par project_id
et user_email
. La colonne query_info
contient des informations supplémentaires sur les jobs de requête.
La vue INFORMATION_SCHEMA.JOBS
présente le schéma suivant :
Nom de colonne | Type de données | Valeur |
---|---|---|
bi_engine_statistics |
RECORD |
Si le projet est configuré pour utiliser BI Engine, ce champ contient BiEngineStatistics.
Sinon, il est défini sur NULL .
|
cache_hit |
BOOLEAN |
Indique si les résultats de requête de cette tâche ont été mis en cache.
Si vous avez un job de requête multi-instruction, la valeur cache_hit pour votre requête parente est NULL .
|
creation_time |
TIMESTAMP |
(Colonne de partitionnement) Heure de création du job. Le partitionnement est basé sur l'heure UTC de cet horodatage. |
destination_table |
RECORD |
Table de destination des résultats (le cas échéant). |
end_time |
TIMESTAMP |
Heure de fin de ce job, en millisecondes depuis l'époque. Ce champ représente l'heure à laquelle le job passe à l'état DONE . |
error_result |
RECORD |
Détails des erreurs sous forme d'objets ErrorProto. |
job_creation_reason.code |
STRING |
Spécifie la raison générale pour laquelle une tâche a été créée. Les valeurs possibles sont les suivantes :
|
job_id |
STRING |
ID de la tâche si une tâche a été créée. Sinon, l'ID de requête d'une requête utilisant le mode de création de tâche facultatif. Par exemple, bquxjob_1234 . |
job_stages |
RECORD |
Étapes de la requête pour le job.
Remarque : Les valeurs de cette colonne sont vides pour les requêtes lues dans des tables présentant des règles d'accès au niveau des lignes. Pour en savoir plus, consultez les Bonnes pratiques en matière de sécurité au niveau des lignes dans BigQuery. |
job_type |
STRING |
Type de la tâche. Il peut s'agir de QUERY , LOAD , EXTRACT , COPY ou NULL . Une valeur NULL indique un job en arrière-plan.
|
labels |
RECORD |
Tableau de libellés appliqués au job en tant que paires clé/valeur. |
parent_job_id |
STRING |
ID de la tâche parente (le cas échéant). |
priority |
STRING |
Priorité de cette tâche. Les valeurs autorisées sont INTERACTIVE et BATCH . |
project_id |
STRING |
(Colonne de clustering) ID du projet. |
project_number |
INTEGER |
Numéro du projet. |
query |
STRING |
Texte de requête SQL. Seule la vue JOBS_BY_PROJECT contient la colonne de requête. |
referenced_tables |
RECORD |
Tableau de tables référencées par le job. Rempli uniquement pour les jobs de requête qui ne sont pas des succès de cache. |
reservation_id |
STRING |
Nom de la réservation principale attribuée à ce job, au format RESERVATION_ADMIN_PROJECT:RESERVATION_LOCATION.RESERVATION_NAME .Dans ce résultat :
|
edition |
STRING |
Édition associée à la réservation attribuée à ce job. Pour en savoir plus sur les éditions, consultez la page Présentation des éditions BigQuery. |
session_info |
RECORD |
Les détails de la session dans laquelle ce job a été exécuté, le cas échéant. |
start_time |
TIMESTAMP |
Heure de début de ce job, en millisecondes depuis l'époque. Ce champ représente l'heure à laquelle le job passe de l'état PENDING à RUNNING ou DONE . |
state |
STRING |
État de fonctionnement de la tâche. Les états valides sont les suivants : PENDING , RUNNING et DONE .
|
statement_type |
STRING |
Type d'instruction de requête. Par exemple, DELETE , INSERT , SCRIPT , SELECT ou UPDATE . Consultez la section QueryStatementType pour obtenir la liste des valeurs valides.
|
timeline |
RECORD |
Chronologie de la requête pour le job. Contient des instantanés de l'exécution des requêtes. |
total_bytes_billed |
INTEGER |
Si le projet est configuré pour utiliser la tarification à la demande, ce champ contient le nombre total d'octets facturés pour le job. Si le projet est configuré pour utiliser la tarification forfaitaire, le nombre d'octets ne vous est pas facturé, et ce champ est fourni à titre d'information seulement.
Remarque : Les valeurs de cette colonne sont vides pour les requêtes lues dans des tables présentant des règles d'accès au niveau des lignes. Pour en savoir plus, consultez les Bonnes pratiques en matière de sécurité au niveau des lignes dans BigQuery. |
total_bytes_processed |
INTEGER |
Nombre total d'octets traités par la tâche. Remarque : Les valeurs de cette colonne sont vides pour les requêtes lues dans des tables présentant des règles d'accès au niveau des lignes. Pour en savoir plus, consultez les Bonnes pratiques en matière de sécurité au niveau des lignes dans BigQuery. |
total_modified_partitions |
INTEGER |
Nombre total de partitions modifiées par le job. Ce champ est renseigné pour les jobs LOAD et QUERY .
|
total_slot_ms |
INTEGER |
Emplacement des millisecondes pour le job sur toute sa durée à l'état RUNNING , y compris les nouvelles tentatives. |
transaction_id |
STRING |
ID de la transaction dans laquelle ce job a été exécuté, le cas échéant. (Aperçu) |
user_email |
STRING |
(Colonne de mise en cluster) Adresse e-mail ou compte de service de l'utilisateur ayant exécuté le job. |
query_info.resource_warning |
STRING |
Message d'avertissement qui s'affiche si l'utilisation des ressources lors du traitement des requêtes dépasse le seuil interne du système. Le champ resource_warning peut être rempli pour tout job de requête réussi. resource_warning vous permet d'obtenir des points de données supplémentaires pour optimiser vos requêtes et configurer la surveillance des tendances de performances d'un ensemble de requêtes équivalent à l'aide de query_hashes .
|
query_info.query_hashes.normalized_literals |
STRING |
Contient les hachages de la requête. normalized_literals est un hachage hexadécimal STRING qui ignore les commentaires, les valeurs de paramètre, les fonctions définies par l'utilisateur et les littéraux.
La valeur du hachage sera différente lorsque les vues sous-jacentes changeront ou si la requête fait référence implicitement à des colonnes, telles que SELECT * , et que le schéma de la table change.
Ce champ apparaît pour les requêtes GoogleSQL réussies qui ne sont pas des succès de cache. |
query_info.performance_insights |
RECORD |
Insights sur les performances du job. |
query_info.optimization_details |
STRUCT |
Les optimisations basées sur l'historique associées au job. |
transferred_bytes |
INTEGER |
Nombre total d'octets transférés pour les requêtes inter-cloud, telles que les tâches de transfert inter-cloud de BigQuery Omni. |
materialized_view_statistics |
RECORD |
Statistiques des vues matérialisées prises en compte dans un job de requête. (Aperçu) |
metadata_cache_statistics |
RECORD |
Statistiques sur l'utilisation de l'index de colonne de métadonnées pour les tables référencées dans un job de requête. |
search_statistics |
RECORD |
Statistiques pour une requête de recherche. |
query_dialect |
STRING |
Ce champ sera disponible en mai 2025.
Dialecte de requête utilisé pour le job. Les valeurs valides sont les suivantes :
Ce champ n'est renseigné que pour les tâches de requête. La sélection par défaut du dialecte de requête peut être contrôlée par les paramètres de configuration. |
continuous |
BOOLEAN |
Indique si le job est une requête continue. |
continuous_query_info.output_watermark |
TIMESTAMP |
Représente le point jusqu'auquel la requête continue a traité les données avec succès. |
vector_search_statistics |
RECORD |
Statistiques pour une requête de recherche vectorielle. |
Lorsque vous interrogez INFORMATION_SCHEMA.JOBS
pour rechercher un coût récapitulatif des tâches de requête, excluez le type d'instruction SCRIPT
, sinon certaines valeurs seront comptabilisées deux fois. La ligne SCRIPT
inclut des valeurs récapitulatives pour toutes les tâches enfants exécutées dans le cadre de cette tâche.
Tâches de requête à plusieurs instructions
Une tâche de requête à plusieurs instructions est une tâche de requête qui utilise le langage procédural.
Les tâches de requête à plusieurs instructions définissent souvent des variables avec DECLARE
ou comportent des instructions de flux de contrôle telles que IF
ou WHILE
. Lorsque vous interrogez INFORMATION_SCHEMA.JOBS
, vous devrez peut-être reconnaître la différence entre une tâche de requête multi-instruction et d'autres tâches. Une tâche de requête à plusieurs instructions présente les caractéristiques suivantes:
statement_type
=SCRIPT
reservation_id
=NULL
Tâches enfants
Chacune des tâches enfants d'une tâche de requête à plusieurs instructions comporte un parent_job_id
pointant vers la tâche de requête à plusieurs instructions elle-même. Cela inclut les valeurs récapitulatives de toutes les tâches enfants exécutées dans le cadre de cette tâche.
Si vous interrogez INFORMATION_SCHEMA.JOBS
pour rechercher un coût récapitulatif des tâches de requête, vous devez exclure le type d'instruction SCRIPT
. Sinon, certaines valeurs telles que total_slot_ms
peuvent être comptabilisées deux fois.
Conservation des données
Cette vue contient les tâches en cours d'exécution et l'historique des tâches des 180 derniers jours.
Champ d'application et syntaxe
Les requêtes exécutées sur cette vue doivent inclure un qualificatif de région. Le tableau suivant explique le champ d'application de la région pour cette vue :
Nom de la vue | Champ d'application de la ressource | Champ d'application de la région |
---|---|---|
[PROJECT_ID.]`region-REGION`.INFORMATION_SCHEMA.JOBS[_BY_PROJECT] |
Niveau Projet | REGION |
-
Facultatif :
PROJECT_ID
: ID de votre projet Google Cloud . Si non spécifié, le projet par défaut est utilisé. -
REGION
: tout nom de région d'ensemble de données. Par exemple,`region-us`
.
Exemples
Pour exécuter la requête sur un projet autre que celui par défaut, ajoutez l'ID du projet en respectant le format suivant :
`PROJECT_ID`.`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
PROJECT_ID
: ID du projet.REGION_NAME
: région de votre projet
Par exemple, `myproject`.`region-us-central1`.INFORMATION_SCHEMA.JOBS
.
Comparer l'utilisation des jobs à la demande aux données de facturation
Pour les projets utilisant la tarification à la demande, vous pouvez utiliser la vue INFORMATION_SCHEMA.JOBS
pour examiner les frais de calcul sur une période donnée.
Pour les projets utilisant la tarification basée sur la capacité (emplacements), vous pouvez utiliser la vue INFORMATION_SCHEMA.RESERVATIONS_TIMELINE
pour examiner les frais de calcul sur une période donnée.
La requête suivante génère une estimation quotidienne de vos Tio facturés et des frais qui en résultent. La section Limites explique dans quels cas ces estimations peuvent ne pas correspondre à votre facture.
Pour cet exemple uniquement, les variables supplémentaires suivantes doivent être définies. Vous pouvez les modifier ici pour plus de facilité.
START_DATE
: date la plus ancienne à agréger (incluse).END_DATE
: date la plus récente à agréger (incluse).PRICE_PER_TIB
: prix à la demande par Tio utilisé pour les estimations de factures.
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;
Limites
BigQuery masque certaines statistiques relatives aux requêtes effectuées sur les tables sécurisées au niveau des lignes. La requête fournie comptabilise le nombre de tâches concernées comme
jobs_using_row_level_security
, mais n'a pas accès à l'utilisation facturable.Les tarifs des requêtes à la demande de BigQuery ML dépendent du type de modèle créé.
INFORMATION_SCHEMA.JOBS
ne suit pas le type de modèle créé. Par conséquent, la requête fournie suppose que toutes les instructions CREATE_MODEL créaient les types de modèles les plus élevés.Les procédures Apache Spark utilisent un modèle de tarification similaire, mais les frais sont signalés en tant que code SKU de paiement à l'usage de l'édition BigQuery Enterprise.
INFORMATION_SCHEMA.JOBS
suit cette utilisation en tant quetotal_bytes_billed
, mais ne peut pas déterminer le code SKU représenté par l'utilisation.
Calculer l'utilisation moyenne des emplacements
Dans l'exemple suivant, on calcule l'utilisation moyenne des emplacements pour toutes les requêtes effectuées au cours des sept derniers jours sur un projet donné. Notez que ce calcul est plus précis pour les projets dont l'utilisation des emplacements est cohérente pendant la semaine. Si l'utilisation des emplacements n'est pas cohérente dans votre projet, ce nombre peut être inférieur à celui attendu.
Pour exécuter la requête, procédez comme suit :
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();
Le résultat ressemble à ce qui suit :
+------------+ | avg_slots | +------------+ | 3879.1534 | +------------+
Vous pouvez vérifier l'utilisation d'une réservation spécifique à l'aide de WHERE reservation_id = "…"
. Cela peut vous aider à déterminer le pourcentage d'utilisation d'une réservation sur une période donnée. Pour les tâches de script, la tâche parente indique également l'utilisation totale des emplacements par ses tâches enfants. Pour éviter de comptabiliser deux fois, utilisez WHERE statement_type != "SCRIPT"
pour exclure la tâche parente.
Si vous préférez vérifier l'utilisation moyenne des emplacements pour des tâches individuelles, utilisez total_slot_ms / TIMESTAMP_DIFF(end_time, start_time, MILLISECOND)
.
Nombre de requêtes actives récentes par priorité de requête
L'exemple suivant affiche le nombre de requêtes, regroupées par priorité (interactive ou par lot), qui ont été lancées au cours des sept dernières heures :
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;
Le résultat ressemble à ce qui suit :
+-------------+-------------+ | priority | active_jobs | +-------------+-------------+ | INTERACTIVE | 2 | | BATCH | 3 | +-------------+-------------+
Le champ priority
indique si une requête est INTERACTIVE
ou BATCH
.
Afficher l'historique des jobs de chargement
Dans l'exemple suivant, on répertorie tous les utilisateurs ou comptes de service ayant envoyé une tâche de chargement par lot sur un projet donné. Comme aucune limite de temps n'est spécifiée, cette requête analyse l'intégralité de l'historique disponible.
SELECT user_email AS user, COUNT(*) num_jobs FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE job_type = 'LOAD' GROUP BY user_email;
Le résultat ressemble à ce qui suit :
+--------------+ | user | +--------------+ | abc@xyz.com | | xyz@xyz.com | | bob@xyz.com | +--------------+
Obtenir le nombre de tâches de chargement pour déterminer le quota quotidien de jobs déjà utilisé
L'exemple suivant renvoie le nombre de jobs par jour, par ensemble de données et par table, afin de pouvoir déterminer le taux d'utilisation du quota quotidien de jobs.
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 | +-------------+------------+-------------+----------+-----------------+
Obtenir les derniers jobs ayant échoué
L'exemple suivant montre les trois derniers jobs ayant échoué :
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;
Le résultat doit ressembler à ce qui suit :
+------------+--------------------------+------------------+-------------------------------------+ | 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...| +------------+--------------------------+------------------+-------------------------------------+
Interroger la liste des jobs de longue durée
L'exemple suivant montre la liste des jobs de longue durée à l'état RUNNING
ou PENDING
pendant plus de 30 minutes :
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;
Le résultat ressemble à ce qui suit :
+--------+----------+---------+--------------------------------+--------------------------------+------------------+ | 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 | +--------+----------+---------+--------------------------------+--------------------------------+------------------+
Requêtes utilisant le mode de création de job facultatif
L'exemple suivant présente une liste de requêtes exécutées en mode de création de job facultatif, pour lesquelles BigQuery n'a pas créé de jobs.
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;
Les résultats doivent se présenter sous la forme suivante :
+-----------+ | job_id | | +-----------+ | bquxjob_1 | | bquxjob_2 | | bquxjob_3 | +-----------+
L'exemple suivant présente des informations sur une requête exécutée en mode de création de job facultatif, pour laquelle BigQuery n'a pas créé de job.
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
Remarque : Le champ job_id
contient le queryId
de la requête lorsqu'aucun job n'a été créé pour cette requête.
Les résultats doivent se présenter sous la forme suivante :
+-----------+----------------+-------------+-----------+--------------------------+--------------------+---------------------+---------------+-------+----------------------+ | 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 | +-----------+----------------+-------------+-----------+--------------------------+--------------------+---------------------+---------------+-------+----------------------+
L'exemple suivant présente une liste de requêtes exécutées en mode de création de job facultatif, pour lesquelles BigQuery a créé des jobs.
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
Les résultats doivent se présenter sous la forme suivante :
+-----------+--------------------------+ | job_id | job_creation_reason_code | +-----------+--------------------------+ | bquxjob_1 | LARGE_RESULTS | | bquxjob_2 | LARGE_RESULTS | | bquxjob_3 | LARGE_RESULTS | +-----------+--------------------------+
Octets traités par identité d'utilisateur
L'exemple suivant montre le nombre total d'octets facturés pour les jobs de requête par utilisateur.
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;
Remarque : Consultez la mise en garde concernant la colonne total_bytes_billed
dans la documentation de schéma pour les vues JOBS
.
Les résultats doivent se présenter sous la forme suivante :
+---------------------+--------------+ | user_email | bytes_billed | +---------------------+--------------+ | bob@example.com | 2847932416 | | alice@example.com | 1184890880 | | charles@example.com | 10485760 | +---------------------+--------------+
Répartition horaire des octets traités
L'exemple suivant montre le nombre total d'octets facturés pour les tâches de requête, à intervalles horaires.
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;
Le résultat ressemble à ce qui suit :
+-------------------------+--------------+ | 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 | +-------------------------+--------------+
Jobs de requête par table
L'exemple suivant indique combien de fois chaque table interrogée dans my_project
a été référencée par une tâche de requête :
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;
Le résultat ressemble à ce qui suit :
+------------+------------+----------+----------------+ | project_id | dataset_id | table_id | num_references | +------------+------------+----------+----------------+ | my_project | dataset1 | orders | 58 | | my_project | dataset1 | products | 40 | | other_proj | dataset1 | accounts | 12 | +------------+------------+----------+----------------+
Nombre de jobs de requêtes en ancien SQL par projet
Le champ "query_dialect" dans INFORMATION_SCHEMA sera disponible en mai 2025. L'exemple suivant montre le nombre de tâches de requête en ancien SQL exécutées par les projets.
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;
Nombre de partitions modifiées par tâche de requête et de chargement par table
L'exemple suivant montre le nombre de partitions modifiées par table par les requêtes avec des instructions LMD et des tâches de chargement. Notez que cette requête n'affiche pas le champ total_modified_partitions
pour les tâches de copie.
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
Nombre moyen d'emplacements par milliseconde utilisés par un job
L'exemple suivant montre comment calculer le nombre moyen d'emplacements utilisés par un job tout au long de son exécution. Cela peut être utile pour résoudre les problèmes de requêtes lentes et comparer une exécution lente d'une requête à une exécution plus rapide de la même requête. Comparer cette valeur à la taille totale de la réservation et au nombre moyen de jobs simultanés exécutés dans le projet ou la réservation peut vous aider à comprendre si plusieurs requêtes étaient en concurrence pour des emplacements en même temps lors de l'exécution.
Un nombre moyen d'emplacements plus élevé signifie que davantage de ressources sont allouées au job, ce qui se traduit généralement par une exécution plus rapide.
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'
Remplacez JOB_ID
par le job_id
que vous examinez.
Le résultat doit ressembler à ce qui suit :
+------------------+ | avg_slots_per_ms | +------------------+ | 17.0 | +------------------+
Requêtes les plus coûteuses par projet
L'exemple suivant liste les requêtes les plus coûteuses au sein du projet my_project
, ce coût étant exprimé en durée d'utilisation des emplacements :
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
Vous pouvez également lister les requêtes les plus coûteuses sur la base des données traitées, à l'aide de l'exemple suivant :
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
Le résultat pour l'un ou l'autre exemple est semblable à celui-ci :
+-----------+---------------------------------+-----------------------+---------------+ | 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 | +-----------+---------------------------------+-----------------------+---------------+
Obtenir des détails sur un avertissement de ressource
Si le message d'erreur Ressources dépassées s'affiche, vous pouvez examiner les requêtes concernées sur une période donnée :
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;
Surveiller les avertissements de ressources regroupés par date
Si vous recevez un message d'erreur Ressources dépassées, vous pouvez surveiller le nombre total d'avertissements de ressources regroupés par date pour savoir si la charge de travail a été modifiée :
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;
Estimer l'utilisation des emplacements et le coût des requêtes
L'exemple suivant calcule le nombre moyen et le nombre maximal d'emplacements pour chaque job à l'aide de estimated_runnable_units
.
La valeur de reservation_id
est NULL
si vous n'avez aucune réservation.
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 project_id = 'my_project' AND (statement_type != 'SCRIPT' OR statement_type IS NULL) AND DATE(creation_time) BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) AND CURRENT_DATE() GROUP BY 1,2,3,4,5,6,7,8,9,10 ORDER BY job_id;
Le résultat de l'exemple ressemble à ce qui suit :
+-----------+-----------+----------------+---------------+----------------------+----------+-----------------+--------------------+--------------+--------------------------------+--------------------+--------------------------+ |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 | 8293 | | project1 | bquxjob2 | reservation2 | 2020-12-10 | 120 | LOAD | abc@example.com | 161480704 | 2890 | SELECT ... FROM dataset.table1 | 2779.1534 | 8768 | | project1 | bquxjob3 | reservation1 | 2020-12-10 | 120 | LOAD | abc@example.com | 161480704 | 2890 | SELECT ... FROM dataset.table1 | 1279.1534 | 8738 | +-----------+-----------+----------------+---------------+----------------------+----------+-----------------+--------------------+--------------+--------------------------------+--------------------+--------------------------+
Afficher les insights sur les performances des requêtes
L'exemple suivant renvoie tous les jobs de requête qui ont généré des insights sur les performances de votre projet au cours des 30 derniers jours, ainsi qu'une URL renvoyant au graphique d'exécution de la requête dans la console 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 );
Afficher les jobs d'actualisation des métadonnées
L'exemple suivant répertorie les jobs d'actualisation des métadonnées au cours des six dernières heures :
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;
Remplacez REGION_NAME par votre région.
Analyser les performances au fil du temps pour les requêtes identiques
L'exemple suivant renvoie les 10 jobs les plus lents au cours des 7 derniers jours pour une même requête :
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;
Remplacez JOB_ID
par n'importe quel job_id
ayant exécuté la requête que vous souhaitez analyser.
Les 5 jobs ayant analysé le plus d'octets aujourd'hui
L'exemple suivant montre comment localiser les cinq tâches ayant analysé le plus d'octets au sein d'une organisation sur la journée en cours. Vous pouvez appliquer davantage de filtres sur statement_type
pour rechercher des informations supplémentaires, telles que des chargements, des exportations et des requêtes.
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;
Le résultat ressemble à ce qui suit :
+--------------+--------------+---------------------------+ | 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 | +--------------+--------------+---------------------------+
Afficher les jobs en attente ou en cours d'exécution
SELECT job_id, creation_time, query FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_USER WHERE state != 'DONE';
Le résultat ressemble à ce qui suit :
+--------------+---------------------------+---------------------------------+ | 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 | +--------------+---------------------------+---------------------------------+
Afficher le nombre moyen de jobs simultanés exécutés en même temps qu'un job spécifique dans le même projet
L'exemple suivant montre comment calculer le nombre moyen de jobs exécutés en même temps qu'un job de requête spécifique dans le même projet.
Ce calcul permet de déterminer si l'augmentation du nombre de jobs simultanés dans un même projet a entraîné des problèmes de conflit de slots. Collectez ces données lorsque vous résolvez des problèmes de requêtes lentes ou que vous comparez des exécutions de requêtes lentes et rapides.
Si le nombre de requêtes simultanées exécutées est beaucoup plus élevé que prévu, vérifiez si davantage de jobs ont été démarrés, si les données interrogées ont changé ou les deux.
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
Remplacez les éléments suivants :
JOB_ID
: ID du job de la requête que vous analysezREGION_NAME
: région de votre projet
Le résultat ressemble à ce qui suit :
+-------------------------+ | average_concurrent_jobs | +-------------------------+ | 2.8 | +-------------------------+
Obtenir le nombre d'octets traités par les jobs d'exportation
L'exemple suivant calcule la valeur total_bytes_processed
pour les types de jobs EXTRACT
. Pour en savoir plus sur les quotas des jobs d'exportation, consultez la page Règles de quota pour les jobs d'exportation.
Le nombre total d'octets traités peut être utilisé pour surveiller l'utilisation globale et vérifier que les jobs d'exportation restent inférieurs à la limite de 50 To par jour :
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;
Consulter l'utilisation des tâches de copie
Pour en savoir plus sur les jobs de copie, consultez la section Copier une table. L'exemple suivant fournit des informations sur l'utilisation de tâches de copie:
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;
Obtenir l'utilisation des tables BigLake pour Apache Iceberg dans l'optimisation du stockage BigQuery
L'exemple suivant montre comment utiliser une table BigLake Iceberg pour optimiser le stockage 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(%)";
Obtenir l'utilisation des tables BigLake Iceberg dans les métadonnées des tables d'exportation BigQuery
L'exemple suivant montre comment utiliser EXPORT TABLE METADATA FROM
Iceberg.
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;
Établir le comportement d'utilisation des emplacements à partir des graphiques de ressources d'administration
Pour explorer le comportement d'utilisation des emplacements de manière similaire aux informations des graphiques de ressources d'administration, interrogez la vue INFORMATION_SCHEMA.JOBS_TIMELINE
.