Visualizzazione JOBS
La visualizzazione INFORMATION_SCHEMA.JOBS
contiene metadati quasi in tempo reale relativi a
tutti i job BigQuery nel progetto corrente.
Ruolo richiesto
Per ottenere l'autorizzazione di cui hai bisogno per eseguire query sulla vista INFORMATION_SCHEMA.JOBS
,
chiedi all'amministratore di concederti
Ruolo IAM Visualizzatore risorse BigQuery (roles/bigquery.resourceViewer
) per il progetto.
Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso.
Questo ruolo predefinito contiene
bigquery.jobs.listAll
, che è
necessaria per eseguire query sulla vista INFORMATION_SCHEMA.JOBS
.
Potresti anche riuscire a ottenere questa autorizzazione con ruoli personalizzati 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
in cluster da project_id
e user_email
. La colonna query_info
contiene
per ottenere altre informazioni
sui tuoi job di query.
La vista INFORMATION_SCHEMA.JOBS
ha il seguente schema:
Nome colonna | Tipo di dati | Valore |
---|---|---|
bi_engine_statistics |
RECORD |
Se il progetto è configurato per utilizzare la BI
Engine SQL Interface, questo campo contiene BiEngineStatistics.
In caso contrario, NULL .
|
cache_hit |
BOOLEAN |
Se i risultati della query per questo job provengono da una cache.
Se disponi di un'istruzione con più query
job, cache_hit per la query principale è
NULL .
|
creation_time |
TIMESTAMP |
(Colonna Partizionamento) Data/ora di creazione del job. Il partizionamento è in base all'ora UTC di questo timestamp. |
destination_table |
RECORD |
Tabella di destinazione per visualizzare eventuali risultati. |
dml_statistics |
RECORD |
Se il job è una query con un'istruzione DML, il valore è un record con
campi seguenti:
NULL .Questa colonna è presente in INFORMATION_SCHEMA.JOBS_BY_USER e
INFORMATION_SCHEMA.JOBS_BY_PROJECT visualizzazioni.
|
end_time |
TIMESTAMP |
L'ora di fine di questo job, in millisecondi dall'epoca. Questo campo rappresenta
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 ne è stato creato uno. Altrimenti, l'ID di una query che utilizza
modalità di query. Ad esempio, bquxjob_1234 . |
job_stages |
RECORD |
Query
fasi del job.
Nota: i valori di questa colonna sono vuoti per le query che leggono dalle tabelle con di accesso a livello di riga. Per saperne di più, consulta le best practice per i livelli di riga e la sicurezza in BigQuery. |
job_type |
STRING |
Il tipo di job. Può essere QUERY , LOAD , EXTRACT ,
COPY o NULL . Un valore NULL
indica un job interno, ad esempio la valutazione di un'istruzione di job dello script
o un aggiornamento della vista materializzata.
|
labels |
RECORD |
Matrice di etichette applicate al job come coppie chiave-valore. |
parent_job_id |
STRING |
ID del job padre, 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 vista JOBS_BY_PROJECT contiene la query
colonna. |
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:
|
session_info |
RECORD |
Dettagli sulla sessione in cui è stato eseguito il job, se presente. |
start_time |
TIMESTAMP |
L'ora di inizio di questo job, in millisecondi dall'epoca. Questo campo rappresenta
di tempo in cui il job passa dallo stato PENDING a
RUNNING o DONE . |
state |
STRING |
Stato del job in esecuzione. Gli stati validi includono PENDING , RUNNING e
DONE .
|
statement_type |
STRING |
Il tipo di istruzione della query. Ad esempio, DELETE , INSERT ,
SCRIPT , SELECT o UPDATE . Vedi QueryStatementType.
per l'elenco dei valori validi.
|
timeline |
RECORD |
Query sequenza temporale del job. Contiene snapshot dell'esecuzione della query. |
total_bytes_billed |
INTEGER |
Se il progetto è configurato per utilizzare on demand
prezzo, questo campo conterrà i byte totali fatturati per
un lavoro. Se il progetto è configurato per utilizzare il modello a costo fisso
, non ti verranno addebitati costi per i byte e questo campo
solo a scopo informativo.
Nota: i valori di questa colonna sono vuoti per le query che leggono dalle tabelle con di accesso a livello di riga. Per saperne di più, consulta le best practice per i livelli di riga e la sicurezza in BigQuery. |
total_bytes_processed |
INTEGER |
Byte totali elaborati dal job. Nota: i valori di questa colonna sono vuoti per le query che leggono dalle tabelle con di accesso a livello di riga. Per saperne di più, consulta le best practice per i livelli di riga e la sicurezza in BigQuery. |
total_modified_partitions |
INTEGER |
Il numero totale di partizioni modificate dal job. Questo campo è
compilato per LOAD e QUERY job.
|
total_slot_ms |
INTEGER |
Millisecondi di slot per il job per l'intera durata nello stato RUNNING ,
inclusi i nuovi tentativi. |
transaction_id |
STRING |
ID della transazione in cui è stato eseguito il job, se presente. (Anteprima) |
user_email |
STRING |
(Colonna clustering) Indirizzo email o account di servizio dell'utente che ha eseguito il job. |
query_info.resource_warning |
STRING |
Il messaggio di avviso che viene visualizzato se l'utilizzo delle risorse durante l'elaborazione delle query supera la soglia interna del sistema. Per un job di query riuscito, il campo resource_warning può essere compilato. Con resource_warning , ottieni punti dati aggiuntivi per ottimizzare le query e impostare il monitoraggio delle tendenze del 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 valore esadecimale
Hash STRING che ignora commenti, valori dei parametri, funzioni definite dall'utente e valori letterali.
Questo campo viene visualizzato per le query GoogleSQL riuscite che non sono hit della cache. |
query_info.performance_insights |
RECORD |
Informazioni sulle prestazioni per il job. |
query_info.optimization_details |
STRUCT |
Le ottimizzazioni basate sulla cronologia per il lavoro. |
transferred_bytes |
INTEGER |
Byte totali trasferiti per le query tra cloud, come i job di trasferimento cross-cloud di BigQuery Omni. |
materialized_view_statistics |
RECORD |
Statistiche di viste materializzate considerate in un job di query. (Anteprima) |
Quando esegui una query su INFORMATION_SCHEMA.JOBS
per trovare un riepilogo dei costi
di job di query, escludi il tipo di istruzione SCRIPT
,
altrimenti alcuni valori potrebbero
essere contati due volte. La riga SCRIPT
include
valori di riepilogo per tutti i job figlio eseguiti come parte di questo job.
Job di query multi-istruzione
Un job di query con più istruzioni è un job di query che utilizza la procedura
lingua.
I job di query multi-istruzione spesso definiscono variabili con DECLARE
o hanno il controllo
istruzioni di flusso come IF
o WHILE
. Quando esegui una query
INFORMATION_SCHEMA.JOBS
, potresti dover riconoscere la differenza tra
un job di query con più istruzioni e altri job. Un job di query a più istruzioni ha
le seguenti caratteristiche:
statement_type
=SCRIPT
reservation_id
=NULL
- Job secondari. Ciascuno dei job figlio di un job di query a più istruzioni ha un
parent_job_id
che punta al job di query con più istruzioni. Questo include i valori di riepilogo per tutti i job figlio eseguiti come parte di questo un lavoro. Per questo motivo, se esegui una query suINFORMATION_SCHEMA.JOBS
per trovare un riepilogo dei job di query, devi escludere il tipo di istruzioneSCRIPT
, altrimenti alcuni valori cometotal_slot_ms
potrebbero essere contati 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 relative a questa vista devono includere un qualificatore regione. La tabella seguente spiega l'ambito della regione per questa visualizzazione:
Nome vista | Ambito risorsa | Ambito della regione |
---|---|---|
[PROJECT_ID.]`region-REGION`.INFORMATION_SCHEMA.JOBS[_BY_PROJECT] |
Livello progetto | REGION |
- (Facoltativo)
PROJECT_ID
: l'ID del tuo progetto Google Cloud. 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 ID progetto nel seguente formato:
`PROJECT_ID`.`region-REGION_NAME`.INFORMATION_SCHEMA.JOBSSostituisci quanto segue:
PROJECT_ID
: l'ID del progetto.REGION_NAME
: la regione del progetto.
Ad esempio, `myproject`.`region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
.
Confronto tra l'utilizzo del job e i dati di fatturazione
Per i progetti che utilizzano la fatturazione on demand, puoi utilizzare la vista INFORMATION_SCHEMA.JOBS
per esaminarli
calcolare gli addebiti in un determinato periodo. La seguente query
genera dati aggregati giornalieri stimati dei TiB fatturati e i risultanti
addebiti. La sezione Limitazioni spiega quando queste stime
potrebbe non corrispondere
alla fattura.
Solo per questo esempio, è necessario impostare le seguenti variabili aggiuntive. Possono essere modificate qui per facilità d'uso.
START_DATE
: la prima data da aggregare (inclusa).END_DATE
: l'ultima data per l'aggregazione (inclusa).PRICE_PER_TIB
: il prezzo on demand per TiB utilizzato per le stime delle fatture.
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 `PROJECT_ID.region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT ) 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 su tabelle con sicurezza a livello di riga. I conteggi delle query forniti il numero di job interessati come
jobs_using_row_level_security
, ma non hanno accesso all'utilizzo fatturabile.I prezzi per le query on demand di BigQuery ML dipendono dal tipo di del modello in fase di creazione.
INFORMATION_SCHEMA.JOBS
non monitora quale tipo di è stato creato, perciò la query fornita presuppone che tutte le istruzioni CREATE_MODEL creavano i tipi di modello con fatturazione più alta.Le procedure Apache Spark utilizzano prezzi simili modello, ma gli addebiti sono riportati come Pagamento a consumo della versione BigQuery Enterprise SKU.
INFORMATION_SCHEMA.JOBS
monitora questo utilizzo cometotal_bytes_billed
, ma non è in grado di determinare quale SKU rappresenta l'utilizzo.
Calcolare l'utilizzo medio degli slot
L'esempio seguente calcola l'utilizzo medio degli slot per tutte le query gli ultimi sette giorni per un determinato progetto. Tieni presente che questo calcolo è e accurato per i progetti con un utilizzo costante degli slot per tutta la settimana. Se il progetto non ha un utilizzo coerente degli slot, questo numero potrebbe essere inferiore del previsto.
Per eseguire la query:
SELECT SUM(total_slot_ms) / (1000 * 60 * 60 * 24 * 7) AS avg_slots FROM `region-us`.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 per una determinata prenotazione con
WHERE reservation_id = "…"
. Può essere utile per determinare la percentuale di utilizzo
di una prenotazione per un determinato periodo di tempo. Per i job di script, anche il job padre
segnala l'utilizzo totale degli slot dai relativi job figlio. Per evitare un doppio conteggio,
utilizza WHERE statement_type != "SCRIPT"
per escludere il job padre.
Se invece vuoi controllare l'utilizzo medio degli slot per singoli
usa total_slot_ms / TIMESTAMP_DIFF(end_time, start_time, MILLISECOND)
.
Cronologia job di caricamento
Nell'esempio seguente sono elencati tutti gli utenti o gli account di servizio che hanno inviato un batch un job di caricamento specifico per un determinato progetto. Poiché non viene specificato alcun limite di tempo, questa query analizza tutta la cronologia disponibile (ad esempio, gli ultimi 30 giorni).
SELECT DISTINCT(user_email) AS user FROM `region-us`.INFORMATION_SCHEMA.JOBS WHERE job_type = 'LOAD';
Il risultato è simile al seguente:
+--------------+ | user | +--------------+ | [email protected] | +--------------+ | [email protected] | +--------------+
Ottieni il numero di job di caricamento per determinare la quota giornaliera di job utilizzata
L'esempio seguente restituisce il numero di job per giorno, set di dati e tabella, che ti consente di determinare quanta quota della quota di job giornaliera viene 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-us.INFORMATION_SCHEMA.JOBS_BY_PROJECT 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
Recupera gli ultimi 10 job non riusciti
L'esempio seguente mostra gli ultimi 10 job non riusciti:
SELECT
job_id,
creation_time,
user_email,
error_result
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE error_result.reason != "Null"
ORDER BY creation_time DESC
LIMIT 10
I risultati dovrebbero essere simili ai seguenti:
+---------------+--------------------------+------------------+-----------------------------------------------------------+
| job_id | creation_time | user_email | error_result |
+---------------+--------------------------+------------------+-----------------------------------------------------------+
| examplejob_1 | 2020-10-10 00:00:00 UTC | [email protected] | Column 'generate_metadata_snapshot' has mismatched type...|
| examplejob_2 | 2020-10-11 00:00:00 UTC | [email protected] | Column 'generate_metadata_snapshot' has mismatched type...|
+---------------+--------------------------+------------------+-----------------------------------------------------------+
Esegui una query sull'elenco dei job a lunga esecuzione
L'esempio seguente mostra l'elenco di job a lunga esecuzione che si trovano in
lo stato RUNNING
o PENDING
per più di 30 minuti:
SELECT
job_id,
job_type,
state,
creation_time,
start_time,
user_email
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
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 |
+---------------+----------+---------+--------------------------------+--------------------------------+------------------+
| examplejob_1 | QUERY | RUNNING | 2023-05-03 05:07:22.818000 UTC | 2023-05-03 05:07:22.905000 UTC | [email protected] |
| examplejob_2 | QUERY | PENDING | 2023-05-01 02:05:47.925000 UTC | 2023-05-01 02:05:47.998000 UTC | [email protected] |
+---------------+----------+---------+--------------------------------+--------------------------------+------------------+
Query che utilizzano la modalità ottimizzata per le query a breve termine
L'esempio seguente mostra un elenco di query eseguite in una query breve ottimizzata per la quale BigQuery non ha creato job.
SELECT
job_id,
FROM
`region-us`.INFORMATION_SCHEMA.JOBS
WHERE
TIMESTAMP_TRUNC(creation_time, DAY) = '2024-06-12'
AND job_creation_reason.code IS NULL
LIMIT
10
I risultati dovrebbero essere simili ai seguenti:
+------------------------------------------+ | job_id | +------------------------------------------+ | 2Lm09bHxDEsoVK8zwzWJomLHU_Ud%1910479b151 | | j9_GVQf28jW2M1_RfTYGRPX1vq--!191047a135f | +------------------------------------------+
L'esempio seguente mostra informazioni su una query eseguita in breve modalità ottimizzata per le query per cui 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-us`.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 il queryId
della query quando un job è stato
non creati 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 | +------------------------------------------+----------------+-------------+-----------+--------------------------+--------------------+-----------------------+---------------+-------+----------------------+ | 2Lm09bHxDEsoVK8zwzWJomLHU_Ud%1910479b151 | SELECT | INTERACTIVE | false | null | 161480704 | 161164718 | 3106 | DONE | null | +------------------------------------------+----------------+-------------+-----------+--------------------------+--------------------+-----------------------+---------------+-------+----------------------+
L'esempio seguente mostra un elenco di query eseguite in una query breve ottimizzata per la quale BigQuery ha creato job.
SELECT
job_id,
job_creation_reason.code AS job_creation_reason_code
FROM
`region-us`.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
10
I risultati dovrebbero essere simili ai seguenti:
+----------------------------------+--------------------------+ | job_id | job_creation_reason_code | +----------------------------------+--------------------------+ | job_LxOEwrJEffcOfjK7GBwWjO3RroOI | 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-us`.INFORMATION_SCHEMA.JOBS
WHERE
job_type = 'QUERY'
AND statement_type != 'SCRIPT'
GROUP BY
user_email;
Nota: consulta le avvertenze per la colonna total_bytes_billed
nella
documentazione sullo schema per le viste JOBS
.
I risultati dovrebbero essere simili ai seguenti:
+---------------------+--------------+
| user_email | bytes_billed |
+---------------------+--------------+
| [email protected] | 2847932416 |
| [email protected] | 1184890880 |
| [email protected] | 10485760 |
+---------------------+--------------+
Analisi oraria dei byte elaborati
L'esempio seguente mostra i byte totali fatturati per i job di query in orari intervalli:
SELECT TIMESTAMP_TRUNC(end_time, HOUR) AS time_window, SUM(total_bytes_billed) AS bytes_billed FROM `region-us`.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 20:00:00 UTC | 10485760 | | 2022-04-15 17:00:00 UTC | 41943040 | +-------------------------+--------------+
Job di query per tabella
L'esempio seguente mostra quante volte ogni tabella è stata sottoposta a query in my_project
fa riferimento a un job di query:
SELECT t.project_id, t.dataset_id, t.table_id, COUNT(*) AS num_references FROM my_project.`region-us`.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 | | my_project | dataset2 | sales | 30 | | other_proj | dataset1 | accounts | 12 | +------------+------------+----------+----------------+
Numero di partizioni modificate da job di query e caricamento per tabella
L'esempio seguente mostra il numero di partizioni modificate dalle query con
Istruzioni DML e job di caricamento, per tabella. Tieni presente che questa query non mostra
total_modified_partitions
per i job di copia.
SELECT destination_table.table_id, SUM(total_modified_partitions) AS total_modified_partitions FROM `region-us`.INFORMATION_SCHEMA.JOBS WHERE DATE(creation_time, "America/Los_Angeles") = CURRENT_DATE() GROUP BY table_id ORDER BY total_modified_partitions DESC
Query più costose per progetto
L'esempio seguente elenca le query più costose in my_project
per slot
Tempo di utilizzo:
SELECT job_id, query, user_email, total_slot_ms FROM `my_project`.`region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE EXTRACT(DATE FROM creation_time) = current_date() ORDER BY total_slot_ms DESC LIMIT 4
Puoi anche elencare le query più costose in base ai dati elaborati nell'esempio seguente:
SELECT job_id, query, user_email, total_bytes_processed FROM `my_project`.`region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE EXTRACT(DATE FROM creation_time) = current_date() ORDER BY total_bytes_processed DESC LIMIT 4
Il risultato per entrambi gli esempi è simile al seguente:
+--------------+---------------------------------+-----------------------+---------------+ | job_id | query | user_email | total_slot_ms | +--------------+---------------------------------+--------------------------+------------+ | examplejob_1 | SELECT ... FROM dataset.table1 | [email protected] | 80,000 | | examplejob_2 | SELECT ... FROM dataset.table2 | [email protected] | 78,000 | | examplejob_3 | SELECT ... FROM dataset.table3 | [email protected] | 75,000 | | examplejob_4 | SELECT ... FROM dataset.table4 | [email protected] | 72,000 | +--------------+---------------------------------+-----------------------+---------------+
Ottieni i dettagli di un avviso relativo alle risorse
Se visualizzi il messaggio di errore Risorse superate, chiedi informazioni sul query in una finestra temporale:
SELECT query, query_info.resource_warning FROM `user_project.region-us`.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 50;
Monitora gli avvisi relativi alle risorse raggruppati per data
Se visualizzi il messaggio di errore Risorse superate, puoi monitorare il numero totale numero di avvisi relativi alle risorse raggruppati per data per sapere se ci sono modifiche alle carico di lavoro:
WITH resource_warnings AS ( SELECT EXTRACT(DATE FROM creation_time) AS creation_date FROM `user_project.region-us`.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 l'utilizzo degli slot e il costo 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-us`.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' 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;
Visualizza informazioni sulle prestazioni per le query
L'esempio seguente restituisce tutti i job di query con insight sulle prestazioni da il tuo progetto negli ultimi 30 giorni, insieme a un URL che rimanda alla query di esecuzione del test 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-us`.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 i job di aggiornamento dei metadati
Nell'esempio seguente sono elencati i job di aggiornamento dei metadati:
SELECT * FROM `region-aws-us-east-1.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;
Analizzare il rendimento nel tempo per query identiche
L'esempio seguente restituisce i primi 10 job più lenti degli ultimi 7 giorni che che hanno eseguito la stessa query:
DECLARE querytext STRING DEFAULT( SELECT query FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT 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-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE query = querytext AND total_bytes_processed > 0 AND creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) ORDER BY 5 DESC LIMIT 10;
Sostituisci JOB_ID
con qualsiasi
job_id
che ha eseguito la query che stai analizzando.
Abbina il comportamento di utilizzo degli slot dai grafici delle risorse amministrative
per esplorare un comportamento di utilizzo degli slot simile a quello delle informazioni nell'amministrazione
dei grafici delle risorse,
INFORMATION_SCHEMA.JOBS_TIMELINE
visualizzazione.