Visualizzazione OFFERTE DI LAVORO
La vista INFORMATION_SCHEMA.JOBS
contiene metadati quasi in tempo reale su tutti i job BigQuery nel progetto corrente.
Ruolo richiesto
Per ottenere l'autorizzazione necessaria per eseguire query sulla visualizzazione INFORMATION_SCHEMA.JOBS
, chiedi all'amministratore di concederti il ruolo IAM Visualizzatore risorse BigQuery (roles/bigquery.resourceViewer
) nel progetto.
Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.
Questo ruolo predefinito contiene l'autorizzazione
bigquery.jobs.listAll
necessaria per
eseguire query sulla visualizzazione INFORMATION_SCHEMA.JOBS
.
Potresti anche ottenere questa autorizzazione con ruoli personalizzati o altri ruoli predefiniti.
Per ulteriori informazioni sulle autorizzazioni BigQuery, consulta Controllo dell'accesso con IAM.
Schema
I dati sottostanti sono partizionati in base alla colonna creation_time
e raggruppati in cluster
in base a project_id
e user_email
. La colonna query_info
contiene
informazioni aggiuntive sui job di query.
La visualizzazione INFORMATION_SCHEMA.JOBS
ha lo schema seguente:
Nome colonna | Tipo di dati | Valore |
---|---|---|
bi_engine_statistics |
RECORD |
Se il progetto è configurato per utilizzare BI
Engine, questo campo contiene BiEngineStatistics.
Altrimenti NULL .
|
cache_hit |
BOOLEAN |
Indica se i risultati della query di questo job provenivano da una cache.
Se hai un job di istruzione
multi-query, cache_hit per la query principale è
NULL .
|
creation_time |
TIMESTAMP |
(Colonna di partizionamento) Ora di creazione di questo job. Il partizionamento si basa sull'ora UTC di questo timestamp. |
destination_table |
RECORD |
Tabella di destinazione per i risultati, se presenti. |
end_time |
TIMESTAMP |
L'ora di fine di questo job, in millisecondi trascorsi dall'epoca. Questo campo rappresenta
il momento in cui il job entra nello stato DONE . |
error_result |
RECORD |
Dettagli di eventuali errori come oggetti ErrorProto. |
job_creation_reason.code |
STRING |
Specifica il motivo generale per cui è stato creato un job. I valori possibili sono:
|
job_id |
STRING |
L'ID del job, se è stato creato un job. In caso contrario, l'ID query di una query che utilizza la modalità di creazione dei job facoltativa. Ad esempio, bquxjob_1234 . |
job_stages |
RECORD |
Fasi
della query del job.
Nota: i valori di questa colonna sono vuoti per le query che leggono da tabelle con criteri di accesso a livello di riga. Per saperne di più, consulta le best practice per la sicurezza a livello di riga in BigQuery. |
job_type |
STRING |
Il tipo di lavoro. Può essere QUERY , LOAD , EXTRACT ,
COPY o NULL . Un valore NULL indica un job
in background.
|
labels |
RECORD |
Array di etichette applicate al job come coppie chiave-valore. |
parent_job_id |
STRING |
ID del job principale, se presente. |
priority |
STRING |
La priorità di questo job. I valori validi includono INTERACTIVE e
BATCH . |
project_id |
STRING |
(Colonna di clustering) L'ID del progetto. |
project_number |
INTEGER |
Il numero del progetto. |
query |
STRING |
Testo della query SQL. Solo la visualizzazione JOBS_BY_PROJECT ha la colonna
query. |
referenced_tables |
RECORD |
Array di tabelle a cui fa riferimento il job. Compilato solo per i job di query che non sono hit della cache. |
reservation_id |
STRING |
Nome della prenotazione principale assegnata a questo job,
nel formato
RESERVATION_ADMIN_PROJECT:RESERVATION_LOCATION.RESERVATION_NAME .In questo output:
|
edition |
STRING |
L'edizione associata alla prenotazione assegnata a questo job. Per ulteriori informazioni sulle versioni, vedi Introduzione alle versioni di BigQuery. |
session_info |
RECORD |
Dettagli sulla sessione in cui è stato eseguito questo job, se presente. |
start_time |
TIMESTAMP |
L'ora di inizio di questo job, in millisecondi dall'epoca. Questo campo rappresenta l'ora in cui il job passa dallo stato PENDING a RUNNING o DONE . |
state |
STRING |
Stato di esecuzione del job. Gli stati validi includono PENDING , RUNNING e
DONE .
|
statement_type |
STRING |
Il tipo di istruzione di query. Ad esempio, DELETE , INSERT ,
SCRIPT , SELECT o UPDATE . Consulta QueryStatementType
per l'elenco dei valori validi.
|
timeline |
RECORD |
Cronologia delle query del job. Contiene snapshot dell'esecuzione della query. |
total_bytes_billed |
INTEGER |
Se il progetto è configurato per utilizzare i prezzi
on demand, questo campo contiene il totale dei byte fatturati per il
job. Se il progetto è configurato per utilizzare i prezzi
a tariffa fissa, non ti vengono addebitati i byte e questo campo è
solo informativo.
Nota: i valori di questa colonna sono vuoti per le query che leggono da tabelle con criteri di accesso a livello di riga. Per saperne di più, consulta le best practice per la sicurezza a livello di riga in BigQuery. |
total_bytes_processed |
INTEGER |
Byte totali elaborati dal job. Nota: i valori di questa colonna sono vuoti per le query che leggono da tabelle con criteri di accesso a livello di riga. Per saperne di più, consulta le best practice per la sicurezza a livello di riga in BigQuery. |
total_modified_partitions |
INTEGER |
Il numero totale di partizioni modificate dal job. Questo campo viene
compilato per i lavori LOAD e QUERY .
|
total_slot_ms |
INTEGER |
Millisecondi dello slot per il job per tutta la sua durata nello stato RUNNING ,
inclusi i tentativi. |
transaction_id |
STRING |
ID della transazione in cui è stato eseguito questo job, se presente. (Anteprima) |
user_email |
STRING |
(Colonna di clustering) Indirizzo email o account di servizio dell'utente che ha eseguito il job. |
query_info.resource_warning |
STRING |
Il messaggio di avviso visualizzato se l'utilizzo delle risorse durante l'elaborazione della query supera la soglia interna del sistema. Un job di query riuscito può avere il campo resource_warning compilato. Con resource_warning , ottieni punti dati aggiuntivi per ottimizzare le query e configurare il monitoraggio delle tendenze di rendimento di un insieme equivalente di query utilizzando query_hashes .
|
query_info.query_hashes.normalized_literals |
STRING |
Contiene gli hash della query. normalized_literals è un hash
STRING esadecimale che ignora commenti, valori dei parametri, UDF e valori letterali.
Il valore hash cambia quando le visualizzazioni sottostanti cambiano o se la query fa riferimento implicitamente
a colonne, ad esempio SELECT * , e lo schema della tabella cambia.
Questo campo viene visualizzato per le query GoogleSQL riuscite che non sono hit della cache. |
query_info.performance_insights |
RECORD |
Informazioni sul rendimento per il lavoro. |
query_info.optimization_details |
STRUCT |
Le ottimizzazioni basate sulla cronologia per il job. |
transferred_bytes |
INTEGER |
Byte totali trasferiti per le query cross-cloud, ad esempio i job di trasferimento cross-cloud BigQuery Omni. |
materialized_view_statistics |
RECORD |
Statistiche delle viste materializzate considerate in un job di query. (Anteprima) |
metadata_cache_statistics |
RECORD |
Statistiche sull'utilizzo dell'indice delle colonne di metadati per le tabelle a cui viene fatto riferimento in un job di query. |
search_statistics |
RECORD |
Statistiche per una query di ricerca. |
query_dialect |
STRING |
Questo campo sarà disponibile a maggio 2025.
Il dialetto della query utilizzato per il job. I valori validi includono:
Questo campo viene compilato solo per i job di query. La selezione predefinita del dialetto della query può essere controllata dalle impostazioni di configurazione. |
continuous |
BOOLEAN |
Indica se il job è una query continua. |
continuous_query_info.output_watermark |
TIMESTAMP |
Rappresenta il punto fino al quale la query continua ha elaborato correttamente i dati. |
vector_search_statistics |
RECORD |
Statistiche per una query di ricerca vettoriale. |
Quando esegui una query su INFORMATION_SCHEMA.JOBS
per trovare un costo riepilogativo
dei job di query, escludi il tipo di istruzione SCRIPT
,
altrimenti alcuni valori potrebbero essere conteggiati due volte. La riga SCRIPT
include
valori di riepilogo per tutti i job secondari eseguiti nell'ambito di questo job.
Job di query con più istruzioni
Un job di query con più istruzioni è un job di query che utilizza il linguaggio
procedurale.
I job di query con più istruzioni spesso definiscono variabili con DECLARE
o hanno istruzioni di flusso di controllo come IF
o WHILE
. Quando esegui una query su
INFORMATION_SCHEMA.JOBS
, potresti dover riconoscere la differenza tra un
job di query con più istruzioni e altri job. Un job di query con più istruzioni ha le
seguenti caratteristiche:
statement_type
=SCRIPT
reservation_id
=NULL
Job figlio
Ogni job secondario di una query multi-istruzione ha un parent_job_id
che punta
al job di query multi-istruzione stesso. Sono inclusi i valori di riepilogo per tutti
i job secondari eseguiti nell'ambito di questo job.
Se esegui una query su INFORMATION_SCHEMA.JOBS
per trovare un costo riepilogativo dei job di query,
devi escludere il tipo di istruzione SCRIPT
. In caso contrario, alcuni valori come
total_slot_ms
potrebbero essere conteggiati due volte.
Conservazione dei dati
Questa visualizzazione contiene i job attualmente in esecuzione e la cronologia dei job degli ultimi 180 giorni.
Ambito e sintassi
Le query su questa visualizzazione devono includere un qualificatore di regione. La tabella seguente spiega l'ambito della regione per questa visualizzazione:
Nome vista | Ambito risorsa | Ambito regione |
---|---|---|
[PROJECT_ID.]`region-REGION`.INFORMATION_SCHEMA.JOBS[_BY_PROJECT] |
Livello progetto | REGION |
-
(Facoltativo)
PROJECT_ID
: l'ID del tuo Google Cloud progetto. Se non specificato, viene utilizzato il progetto predefinito. -
REGION
: qualsiasi nome della regione del set di dati. Ad esempio:`region-us`
.
Esempi
Per eseguire la query su un progetto diverso da quello predefinito, aggiungi l'ID progetto nel seguente formato:
`PROJECT_ID`.`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
PROJECT_ID
: l'ID del progetto.REGION_NAME
: la regione del progetto.
Ad esempio, `myproject`.`region-us-central1`.INFORMATION_SCHEMA.JOBS
.
Confrontare l'utilizzo dei job on demand con i dati di fatturazione
Per i progetti che utilizzano i prezzi on demand,
puoi utilizzare la visualizzazione INFORMATION_SCHEMA.JOBS
per esaminare
gli addebiti per il calcolo in un determinato periodo.
Per i progetti che utilizzano i prezzi basati sulla capacità (slot),
puoi utilizzare il INFORMATION_SCHEMA.RESERVATIONS_TIMELINE
per esaminare gli addebiti di calcolo in un determinato periodo.
La seguente query produce aggregati stimati giornalieri dei TiB fatturati e degli addebiti risultanti. La sezione Limitazioni spiega quando queste stime potrebbero non corrispondere alla fattura.
Solo per questo esempio, devono essere impostate le seguenti variabili aggiuntive. Possono essere modificati qui per facilità d'uso.
START_DATE
: la prima data da aggregare (inclusa).END_DATE
: l'ultima data da aggregare (inclusa).PRICE_PER_TIB
: il prezzo on demand per TiB utilizzato per le stime della fattura.
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;
Limitazioni
BigQuery nasconde alcune statistiche per le query sulle tabelle con sicurezza a livello di riga. I conteggi delle query forniti conteggiano il numero di job interessati come
jobs_using_row_level_security
, ma non hanno accesso all'utilizzo fatturabile.I prezzi di BigQuery ML per le query on demand dipendono dal tipo di modello creato.
INFORMATION_SCHEMA.JOBS
non tiene traccia del tipo di modello creato, pertanto la query fornita presuppone che tutte le istruzioni CREATE_MODEL creassero i tipi di modello con fatturazione più elevata.Le procedure Apache Spark utilizzano un modello di prezzi simile, ma gli addebiti vengono segnalati come SKU con pagamento a consumo di BigQuery Enterprise.
INFORMATION_SCHEMA.JOBS
monitora questo utilizzo cometotal_bytes_billed
, ma non può determinare a quale SKU si riferisce l'utilizzo.
Calcolare l'utilizzo medio degli slot
Il seguente esempio calcola l'utilizzo medio degli slot per tutte le query negli ultimi 7 giorni per un determinato progetto. Tieni presente che questo calcolo è più preciso per i progetti che hanno un utilizzo coerente degli slot durante la settimana. Se il tuo progetto non ha un utilizzo coerente degli slot, questo numero potrebbe essere inferiore al previsto.
Per eseguire la query:
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();
Il risultato è simile al seguente:
+------------+ | avg_slots | +------------+ | 3879.1534 | +------------+
Puoi controllare l'utilizzo di una prenotazione specifica con
WHERE reservation_id = "…"
. Può essere utile per determinare la percentuale di utilizzo
di una prenotazione in un determinato periodo di tempo. Per i job di script, il job principale
segnala anche l'utilizzo totale degli slot dei job secondari. Per evitare il doppio conteggio,
utilizza WHERE statement_type != "SCRIPT"
per escludere il job principale.
Se invece vuoi controllare l'utilizzo medio degli slot per singoli
job, utilizza total_slot_ms / TIMESTAMP_DIFF(end_time, start_time, MILLISECOND)
.
Conteggio delle query attive recenti per priorità della query
L'esempio seguente mostra il numero di query, raggruppate per priorità (interattiva o batch), avviate nelle ultime 7 ore:
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;
Il risultato è simile al seguente:
+-------------+-------------+ | priority | active_jobs | +-------------+-------------+ | INTERACTIVE | 2 | | BATCH | 3 | +-------------+-------------+
Il campo priority
indica se una query è INTERACTIVE
o BATCH
.
Visualizzare la cronologia dei job di caricamento
L'esempio seguente elenca tutti gli utenti o i service account che hanno inviato un job di caricamento batch per un determinato progetto. Poiché non è stato specificato alcun limite di tempo, questa query esegue la scansione di tutta la cronologia disponibile.
SELECT user_email AS user, COUNT(*) num_jobs FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE job_type = 'LOAD' GROUP BY user_email;
Il risultato è simile al seguente:
+--------------+ | user | +--------------+ | abc@xyz.com | | xyz@xyz.com | | bob@xyz.com | +--------------+
Recupera il numero di job di caricamento per determinare la quota giornaliera di job utilizzata
Il seguente esempio restituisce il numero di job per giorno, set di dati e tabella in modo da determinare la quantità di quota giornaliera per i job utilizzata.
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 | +-------------+------------+-------------+----------+-----------------+
Recupera gli ultimi job non riusciti
Il seguente esempio mostra gli ultimi tre job non riusciti:
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;
I risultati dovrebbero essere simili ai seguenti:
+------------+--------------------------+------------------+-------------------------------------+ | 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...| +------------+--------------------------+------------------+-------------------------------------+
Esegui query sull'elenco dei job a lunga esecuzione
L'esempio seguente mostra l'elenco dei job a esecuzione prolungata che si trovano nello stato RUNNING
o PENDING
per più di 30 minuti:
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;
Il risultato è simile al seguente:
+--------+----------+---------+--------------------------------+--------------------------------+------------------+ | 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 | +--------+----------+---------+--------------------------------+--------------------------------+------------------+
Query che utilizzano la modalità di creazione dei job facoltativa
L'esempio seguente mostra un elenco di query eseguite in modalità di creazione dei job facoltativa per le quali BigQuery non ha creato job.
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;
I risultati dovrebbero essere simili ai seguenti:
+-----------+ | job_id | | +-----------+ | bquxjob_1 | | bquxjob_2 | | bquxjob_3 | +-----------+
Il seguente esempio mostra informazioni su una query eseguita in modalità di creazione facoltativa del job per la quale BigQuery non ha creato un 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
Nota: il campo job_id
contiene l'queryId
della query quando non è stato creato un job per questa query.
I risultati dovrebbero essere simili ai seguenti:
+-----------+----------------+-------------+-----------+--------------------------+--------------------+---------------------+---------------+-------+----------------------+ | 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'esempio seguente mostra un elenco di query eseguite in modalità di creazione dei job facoltativa per le quali BigQuery ha creato job.
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
I risultati dovrebbero essere simili ai seguenti:
+-----------+--------------------------+ | job_id | job_creation_reason_code | +-----------+--------------------------+ | bquxjob_1 | LARGE_RESULTS | | bquxjob_2 | LARGE_RESULTS | | bquxjob_3 | LARGE_RESULTS | +-----------+--------------------------+
Byte elaborati per identità utente
L'esempio seguente mostra i byte totali fatturati per i job di query per utente:
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 l'avvertenza relativa alla colonna total_bytes_billed
nella
documentazione dello schema per le visualizzazioni JOBS
.
I risultati dovrebbero essere simili ai seguenti:
+---------------------+--------------+ | user_email | bytes_billed | +---------------------+--------------+ | bob@example.com | 2847932416 | | alice@example.com | 1184890880 | | charles@example.com | 10485760 | +---------------------+--------------+
Ripartizione oraria dei byte elaborati
L'esempio seguente mostra i byte totali fatturati per i job di query, a intervalli orari:
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;
Il risultato è simile al seguente:
+-------------------------+--------------+ | 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 | +-------------------------+--------------+
Job di query per tabella
L'esempio seguente mostra quante volte ogni tabella sottoposta a query in my_project
è stata referenziata da un job di query:
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;
Il risultato è simile al seguente:
+------------+------------+----------+----------------+ | project_id | dataset_id | table_id | num_references | +------------+------------+----------+----------------+ | my_project | dataset1 | orders | 58 | | my_project | dataset1 | products | 40 | | other_proj | dataset1 | accounts | 12 | +------------+------------+----------+----------------+
Numero di job di query SQL precedenti per progetto
Il campo "query_dialect" in INFORMATION_SCHEMA sarà disponibile a maggio 2025. Il seguente esempio mostra quanti job di query SQL precedente vengono eseguiti dai progetti.
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;
Numero di partizioni modificate dai job di query e di caricamento per tabella
L'esempio seguente mostra il numero di partizioni modificate dalle query con istruzioni DML e dai job di caricamento per tabella. Tieni presente che questa query non mostra
il total_modified_partitions
per i job di 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
Numero medio di slot per millisecondo utilizzati da un job
Il seguente esempio mostra come calcolare il numero medio di slot utilizzati da un job durante l'esecuzione. Questo può essere utile per risolvere i problemi relativi alle query lente e confrontare l'esecuzione lenta di una query con l'esecuzione più rapida della stessa query. Il confronto di questo valore con le dimensioni totali della prenotazione e il numero medio di job simultanei eseguiti all'interno del progetto o della prenotazione può aiutarti a capire se più query erano in competizione per gli slot contemporaneamente durante l'esecuzione.
Un numero medio di slot più elevato significa più risorse allocate al job, il che in genere si traduce in un'esecuzione più rapida.
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'
Sostituisci JOB_ID
con il job_id
che stai esaminando.
Il risultato sarà simile al seguente:
+------------------+ | avg_slots_per_ms | +------------------+ | 17.0 | +------------------+
Query più costose per progetto
L'esempio seguente elenca le query più costose in my_project
in base al tempo di utilizzo
dello slot:
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
Puoi anche elencare le query più costose in base ai dati elaborati con il seguente esempio:
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
Il risultato per entrambi gli esempi è simile al seguente:
+-----------+---------------------------------+-----------------------+---------------+ | 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 | +-----------+---------------------------------+-----------------------+---------------+
Visualizzare i dettagli di un avviso relativo alle risorse
Se ricevi il messaggio di errore Risorse superate, puoi chiedere informazioni sulle query in un intervallo di tempo:
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;
Monitorare gli avvisi relativi alle risorse raggruppati per data
Se ricevi un messaggio di errore Risorse superate, puoi monitorare il numero totale di avvisi relativi alle risorse raggruppati per data per sapere se sono state apportate modifiche al carico di lavoro:
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;
Stima dell'utilizzo e del costo degli slot per le query
L'esempio seguente calcola gli slot medi e massimi per ogni job utilizzando estimated_runnable_units
.
Il reservation_id
è NULL
se non hai prenotazioni.
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;
Il risultato, ad esempio, è simile al seguente:
+-----------+-----------+----------------+---------------+----------------------+----------+-----------------+--------------------+--------------+--------------------------------+--------------------+--------------------------+ |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 | +-----------+-----------+----------------+---------------+----------------------+----------+-----------------+--------------------+--------------+--------------------------------+--------------------+--------------------------+
Visualizzare informazioni sul rendimento delle query
L'esempio seguente restituisce tutti i job di query che hanno approfondimenti sul rendimento del tuo progetto negli ultimi 30 giorni, insieme a un URL che rimanda al grafico di esecuzione della query nella 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 );
Visualizza job di aggiornamento dei metadati
L'esempio seguente elenca i job di aggiornamento dei metadati nelle ultime sei ore:
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;
Sostituisci REGION_NAME con la tua regione.
Analizzare il rendimento nel tempo per query identiche
Il seguente esempio restituisce i 10 job più lenti degli ultimi 7 giorni che hanno eseguito la stessa query:
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;
Sostituisci JOB_ID
con qualsiasi
job_id
che ha eseguito la query che stai analizzando.
I primi 5 job che hanno scansionato più byte oggi
Il seguente esempio mostra come trovare i cinque job che hanno analizzato il maggior numero di byte in un'organizzazione per il giorno corrente. Puoi filtrare ulteriormente in
statement_type
per cercare informazioni aggiuntive come caricamenti, esportazioni
e query.
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;
Il risultato è simile al seguente:
+--------------+--------------+---------------------------+ | 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 | +--------------+--------------+---------------------------+
Visualizza job in attesa o in esecuzione
SELECT job_id, creation_time, query FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_USER WHERE state != 'DONE';
Il risultato è simile al seguente:
+--------------+---------------------------+---------------------------------+ | 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 | +--------------+---------------------------+---------------------------------+
Visualizza la media dei job simultanei in esecuzione insieme a un determinato job nello stesso progetto
Il seguente esempio mostra come calcolare il numero medio di job in esecuzione contemporaneamente a un job di query specifico nello stesso progetto.
Questo calcolo aiuta a determinare se un numero maggiore di job simultanei all'interno dello stesso progetto ha causato problemi di contesa degli slot. Raccogli questi dati quando risolvi i problemi relativi alle query lente o quando confronti le esecuzioni di query lente e veloci.
Se vengono eseguite molte più query simultanee del previsto, verifica se sono stati avviati più job, se i dati sottoposti a query sono cambiati o entrambe le cose.
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
Sostituisci quanto segue:
JOB_ID
: l'ID job della query che stai analizzandoREGION_NAME
: la regione del progetto
Il risultato è simile al seguente:
+-------------------------+ | average_concurrent_jobs | +-------------------------+ | 2.8 | +-------------------------+
Recuperare i byte elaborati dai job di esportazione
L'esempio seguente calcola il valore total_bytes_processed
per i tipi di job EXTRACT
. Per informazioni sulle quote per i job di esportazione, vedi
Norme sulle quote per i job di esportazione.
I byte totali elaborati possono essere utilizzati per monitorare l'utilizzo aggregato e verificare che i job di esportazione rimangano al di sotto del limite di 50 TB al giorno:
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;
Visualizzare l'utilizzo dei job di copia
Per informazioni sui lavori di copia, vedi Copiare una tabella. L'esempio seguente mostra l'utilizzo dei lavori di 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;
Visualizzare l'utilizzo delle tabelle BigLake per Apache Iceberg nell'ottimizzazione dello spazio di archiviazione BigQuery
Il seguente esempio mostra l'utilizzo della tabella BigLake Iceberg nell'ottimizzazione dello spazio di archiviazione di 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(%)";
Ottenere l'utilizzo della tabella BigLake Iceberg nei metadati della tabella di esportazione BigQuery
L'esempio seguente mostra l'utilizzo di 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;
Corrispondenza del comportamento di utilizzo degli slot dai grafici delle risorse amministrative
Per esplorare il comportamento di utilizzo degli slot in modo simile alle informazioni nei grafici delle risorse amministrative, esegui una query sulla visualizzazione INFORMATION_SCHEMA.JOBS_TIMELINE
.