Visualizzazione JOB

La visualizzazione INFORMATION_SCHEMA.JOBS contiene metadati quasi in tempo reale su 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 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 in cluster da project_id e user_email. La colonna query_info contiene informazioni aggiuntive sui 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:
  • inserted_row_count: il numero di righe inserite.
  • deleted_row_count: il numero di righe eliminate.
  • updated_row_count: il numero di righe che sono state aggiornate.
Per tutti gli altri job, il valore è 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:
  • REQUESTED: è stata richiesta la creazione del job.
  • LONG_RUNNING: la richiesta di query è stata eseguita oltre un timeout definito dal sistema specificato dal campo timeoutMs in QueryRequest. Di conseguenza, è stata considerata un'operazione a lunga esecuzione per la quale è stato creato un job.
  • LARGE_RESULTS: i risultati della query non possono rientrare nella riga la risposta corretta.
  • OTHER: il sistema ha stabilito che la query deve essere eseguita come un lavoro.
job_id STRING L'ID del job, se ne è stato creato uno. In caso contrario, l'ID query di una query che utilizza la modalità di query breve. 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 ulteriori informazioni, 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 interno, ad esempio la valutazione di un'istruzione di job dello script o l'aggiornamento di una vista materializzata.
labels RECORD Array di etichette applicate al job sotto forma di 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 vista JOBS_BY_PROJECT contiene la query colonna.
referenced_tables RECORD Array di tabelle a cui fa riferimento il job. Viene 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:
  • RESERVATION_ADMIN_PROJECT: il nome del progetto Google Cloud che gestisce la prenotazione
  • RESERVATION_LOCATION: il luogo della prenotazione
  • RESERVATION_NAME: il nome della prenotazione
edition STRING La versione associata alla prenotazione assegnata a questo job. Per ulteriori informazioni sulle versioni, consulta 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 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 delle 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 i prezzi fissi, non ti verranno addebitati i byte e questo campo è solo 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 ulteriori informazioni, 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 è 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 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 delle query è superiore alla soglia interna del sistema.
Per un job di query riuscito, il campo resource_warning può essere compilato. Con resource_warning, puoi ottenere ulteriori punti dati per ottimizzare le query e configurare 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 hash STRING in esadecimale che ignora commenti, valori dei parametri, funzioni UDF e letterali.
Questo campo viene visualizzato per le query GoogleSQL riuscite che non sono hit della cache.
query_info.performance_insights RECORD Approfondimenti sul rendimento del job.
query_info.optimization_details STRUCT Le ottimizzazioni basate sulla cronologia per il job.
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 con più istruzioni

Un job di query con più istruzioni è un job di query che utilizza la procedura lingua. 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 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 secondari. Ciascuno dei job secondari di un job di query con più istruzioni ha un parent_job_id che rimanda al job di query con più istruzioni stesso. Sono inclusi i valori di riepilogo per tutti i job secondari eseguiti nell'ambito di questo job. Per questo motivo, se esegui una query su INFORMATION_SCHEMA.JOBS per trovare un riepilogo dei job di query, devi escludere il tipo di istruzione SCRIPT, altrimenti alcuni valori come total_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 regione
[PROJECT_ID.]`region-REGION`.INFORMATION_SCHEMA.JOBS[_BY_PROJECT] Livello progetto REGION
Sostituisci quanto segue:

  • (Facoltativo) PROJECT_ID: l'ID del tuo progetto Google Cloud. Se non viene 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
 Sostituisci 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 dell'utilizzo dei job con i dati di fatturazione

Per i progetti che utilizzano la fatturazione on demand, puoi usare 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: la data più recente da aggregare (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 sulle tabelle con sicurezza a livello di riga. La query fornita conteggia il numero di job interessati come jobs_using_row_level_security, ma non ha 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 tiene traccia del tipo di modello creato, pertanto la query fornita presuppone che tutte le istruzioni CREATE_MODEL stiano creando i tipi di modelli con fatturazione più elevata.

  • Le procedure Apache Spark utilizzano un modello di prezzi simile, ma gli addebiti vengono registrati come SKU con pagamento a consumo della versione Enterprise di BigQuery. INFORMATION_SCHEMA.JOBS monitora questo utilizzo come total_bytes_billed, ma non può determinare quale SKU rappresenta l'utilizzo.

Calcolare l'utilizzo medio degli slot

Il seguente esempio calcola l'utilizzo medio dello slot per tutte le query negli ultimi 7 giorni per un determinato progetto. Tieni presente che questo calcolo è più accurato per i progetti che hanno un utilizzo costante degli slot durante la settimana. Se il progetto non ha un utilizzo degli slot coerente, questo numero potrebbe essere inferiore alle aspettative.

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 di una determinata prenotazione con WHERE reservation_id = "…". Questo 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 registra anche l'utilizzo totale degli slot dei job secondari. 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 i singoli job, utilizza total_slot_ms / TIMESTAMP_DIFF(end_time, start_time, MILLISECOND).

Carica la cronologia dei job

L'esempio seguente elenca tutti gli utenti o gli account di servizio che hanno inviato un job di caricamento batch per un determinato progetto. Poiché non è specificato alcun limite di tempo, questa query analizza tutta la cronologia disponibile (ad es. 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         |
+--------------+
| abc@xyz.com  |
+--------------+
| def@xyz.com  |
+--------------+

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 in modo da poter determinare la quantità di quota giornaliera dei 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-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  | bob@example.com  | Column 'generate_metadata_snapshot' has mismatched type...|
| examplejob_2  | 2020-10-11 00:00:00 UTC  | bob@example.com  | Column 'generate_metadata_snapshot' has mismatched type...|
+---------------+--------------------------+------------------+-----------------------------------------------------------+

Esegui una query sull'elenco dei job a lunga esecuzione

L'esempio seguente mostra l'elenco dei job a esecuzione prolungata in stato RUNNING o PENDING da 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 | abc@example.com  |
| examplejob_2  | QUERY    | PENDING | 2023-05-01 02:05:47.925000 UTC | 2023-05-01 02:05:47.998000 UTC | xyz@example.com  |
+---------------+----------+---------+--------------------------------+--------------------------------+------------------+

Query che utilizzano la modalità ottimizzata per le query a breve termine

L'esempio seguente mostra un elenco di query eseguite in modalità ottimizzata per query brevi per le quali 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 modalità ottimizzata per le query brevi 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-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 modalità ottimizzata per query brevi per le quali 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 il disclaimer per la 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     |
+---------------------+--------------+

Suddivisione oraria dei byte elaborati

L'esempio seguente mostra i byte totali fatturati per i job di query, in intervalli di un'ora:

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 faceva 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 di entrambi gli esempi è simile al seguente:

+--------------+---------------------------------+-----------------------+---------------+
| job_id       | query                           | user_email            | total_slot_ms |
+--------------+---------------------------------+--------------------------+------------+
| examplejob_1 | SELECT ... FROM dataset.table1  | bob@example.com       | 80,000        |
| examplejob_2 | SELECT ... FROM dataset.table2  | alice@example.com     | 78,000        |
| examplejob_3 | SELECT ... FROM dataset.table3  | charles@example.com   | 75,000        |
| examplejob_4 | SELECT ... FROM dataset.table4  | tina@example.com      | 72,000        |
+--------------+---------------------------------+-----------------------+---------------+

Visualizzare i dettagli di un avviso relativo a una risorsa

Se ricevi il messaggio di errore Risorse superate, puoi richiedere informazioni sulle query in un intervallo di tempo:

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;

Monitorare gli avvisi sulle 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 ci sono modifiche al 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 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 valore 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.