Ansicht JOBS
Die Ansicht INFORMATION_SCHEMA.JOBS
enthält die Echtzeitmetadaten zu allen BigQuery-Jobs im aktuellen Projekt.
Erforderliche Berechtigung
Zum Abfragen der Ansicht INFORMATION_SCHEMA.JOBS
benötigen Sie die IAM-Berechtigung (Identity and Access Management) bigquery.jobs.listAll
für das Projekt.
Jede der folgenden vordefinierten IAM-Rollen enthält die erforderliche Berechtigung:
- BigQuery-Administrator
- BigQuery-Ressourcen-Administrator
- BigQuery-Ressourcenbearbeiter
- BigQuery-Ressourcenbetrachter
Weitere Informationen zu BigQuery-Berechtigungen finden Sie unter Zugriffssteuerung mit IAM.
Schema
Die zugrunde liegenden Daten werden nach der Spalte creation_time
partitioniert und nach project_id
und user_email
geclustert.
Die Ansicht INFORMATION_SCHEMA.JOBS
hat das folgende Schema:
Spaltenname | Datentyp | Wert |
---|---|---|
creation_time |
TIMESTAMP |
(Partitionierungsspalte) Erstellungszeit dieses Jobs. Die Partitionierung basiert auf der UTC-Zeit dieses Zeitstempels. |
project_id |
STRING |
(Clustering-Spalte) ID des Projekts |
project_number |
INTEGER |
Nummer des Projekts. |
user_email |
STRING |
(Clustering-Spalte) E-Mail-Adresse oder Dienstkonto des Nutzers, der den Job ausgeführt hat. |
job_id |
STRING |
ID des Jobs, z. B. bquxjob_1234 . |
job_type |
STRING |
Typ des Jobs. Kann QUERY , LOAD , EXTRACT , COPY oder null sein. Der Jobtyp null gibt einen internen Job an, z. B. die Auswertung einer Anweisung des Skriptjobs oder die Aktualisierung der materialisierten Ansicht. |
statement_type |
STRING |
Typ der Abfrageanweisung, sofern gültig. Beispiel:
SELECT , INSERT , UPDATE ,
DELETE oder SCRIPT .
Eine Liste der gültigen Werte finden Sie unter QueryStatementType. |
priority |
STRING |
Die Priorität dieses Jobs Zulässige Werte: INTERACTIVE
aud BATCH . |
start_time |
TIMESTAMP |
Startzeit dieses Jobs. |
end_time |
TIMESTAMP |
Endzeit dieses Jobs. |
query |
STRING |
SQL-Abfragetext. Hinweis: Nur die Ansicht JOBS_BY_PROJECT hat die Spalte query . |
state |
STRING |
Ausführungsstatus des Jobs. Gültige Statuswerte sind PENDING , RUNNING und DONE . |
reservation_id |
STRING |
Name der primären Reservierung, die diesem Job gegebenenfalls zugewiesen ist Wenn Ihr Job in einem Projekt ausgeführt wurde, das einer Reservierung zugewiesen ist, hat er das Format RESERVATION_ADMIN_PROJECT:RESERVATION_LOCATION.RESERVATION_NAME .
In dieser Ausgabe gilt:
|
total_bytes_processed |
INTEGER |
Gesamtzahl der vom Job verarbeiteten Byte. |
total_slot_ms |
INTEGER |
Slotmillisekunden für den Job über seine gesamte Dauer |
error_result |
RECORD |
Fehlerdetails (falls vorhanden) als ErrorProto . |
cache_hit |
BOOLEAN |
Ob die Abfrageergebnisse dieses Jobs aus einem Cache stammen. |
destination_table |
RECORD |
Zieltabelle für etwaige Ergebnisse |
referenced_tables |
RECORD |
Array aus Tabellen, auf die der Job verweist. Wird nur für Abfragejobs ausgefüllt. |
labels |
RECORD |
Array aus Labels, die als Strings in der Form key , value auf den Job angewendet werden. |
timeline |
RECORD |
Abfragezeitachse des Jobs. Enthält Snapshots der Abfrageausführung. |
job_stages |
RECORD |
Abfragephasen des Jobs |
total_bytes_billed |
INTEGER |
Wenn das Projekt für die Verwendung von On-Demand-Preisen konfiguriert ist, enthält dieses Feld die Gesamtzahl der für den Job in Rechnung gestellten Byte. Wenn das Projekt für die Verwendung von Pauschalpreisen konfiguriert ist, werden Ihnen keine Byte in Rechnung gestellt. Dieses Feld dient nur zur Information. |
parent_job_id |
STRING |
ID des übergeordneten Jobs, sofern vorhanden. |
transaction_id |
STRING |
ID der Transaktion, in der dieser Job ausgeführt wurde (falls vorhanden). (Vorschau) |
session_info |
RECORD |
Details zur Sitzung, in der dieser Job ausgeführt wurde, sofern vorhanden. (Vorschau) |
dml_statistics |
RECORD |
Wenn der Job eine Abfrage mit einer DML-Anweisung ist, ist der Wert ein Eintrag mit den folgenden Feldern:
Bei allen anderen Jobs lautet der Wert Diese Spalte ist in den Ansichten |
bi_engine_statistics |
RECORD |
Wenn das Projekt für die Verwendung der BI Engine-SQL-Schnittstelle konfiguriert ist, dann enthält dieses Feld BiEngineStatistics. Andernfalls NULL .
|
total_modified_partitions |
INTEGER |
Gesamtzahl der Partitionen, die der Job geändert hat. Dieses Feld wird für LOAD - und QUERY -Jobs ausgefüllt.
|
Datenaufbewahrung
Diese Ansicht enthält aktuell ausgeführte Jobs und den Jobverlauf der letzten 180 Tage.
Bereich und Syntax
Für Abfragen dieser Ansicht muss ein Regions-Qualifier verwendet werden. Wenn Sie keinen regionalen Qualifier angeben, werden Metadaten aus allen Regionen abgerufen. In der folgenden Tabelle wird der Regionsbereich für diese Ansicht erläutert:
Ansichtsname | Ressourcenbereich | Regionsbereich |
---|---|---|
[PROJECT_ID.]`region-REGION`.INFORMATION_SCHEMA.JOBS[_BY_PROJECT] |
auf Projektebene | REGION |
- Optional:
PROJECT_ID
: die ID Ihres Cloud-Projekts. Wenn keine Angabe erfolgt, wird das Standardprojekt verwendet. REGION
: ist ein beliebiger Dataset-Regionsname. Beispiel:region-us
Wenn Sie INFORMATION_SCHEMA.JOBS
abfragen, um eine Zusammenfassung der Kosten für Abfragejobs zu erhalten, schließen Sie die Anweisung SCRIPT
aus. Andernfalls könnten einige Werte zweimal gezählt werden. Die Zeile SCRIPT
enthält zusammenfassende Werte für alle untergeordneten Jobs, die im Rahmen dieses Jobs ausgeführt wurden.
Beispiele
Wenn Sie die Abfrage für ein anderes Projekt als Ihr Standardprojekt ausführen möchten, fügen Sie die Projekt-ID im folgenden Format hinzu:
`PROJECT_ID`.`region-REGION_NAME`.INFORMATION_SCHEMA.JOBSDabei gilt:
PROJECT_ID
: die ID des Projekts.REGION_NAME
: Region für Ihr Projekt
z. B. `myproject`.`region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
.
Im folgenden Beispiel wird die durchschnittliche Slot-Auslastung für alle Abfragen in den letzten sieben Tagen für ein bestimmtes Projekt berechnet. Beachten Sie, dass diese Berechnung am besten für Projekte mit gleichbleibender Slot-Nutzung im Wochenverlauf funktioniert. Wenn Ihr Projekt keine konsistente Slot-Nutzung aufweist, ist diese Zahl möglicherweise niedriger als erwartet.
Das geht so:
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 end_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) AND CURRENT_TIMESTAMP();
Das Ergebnis sieht etwa so aus:
+------------+ | avg_slots | +------------+ | 3879.1534 | +------------+
Sie können die Nutzung einer bestimmten Reservierung mit WHERE reservation_id = "…"
prüfen. Dies kann hilfreich sein, um die prozentuale Nutzung einer Reservierung über einen bestimmten Zeitraum zu ermitteln. Bei Skriptjobs meldet der übergeordnete Job auch die gesamte Slot-Nutzung seiner untergeordneten Jobs. Verwenden Sie zur Vermeidung einer doppelten Zählung WHERE statement_type != "SCRIPT"
, um den übergeordneten Job auszuschließen.
Wenn Sie stattdessen die durchschnittliche Slot-Auslastung für einzelne Jobs prüfen möchten, verwenden Sie total_slot_ms / TIMESTAMP_DIFF(end_time, start_time, MILLISECOND)
.
Beispiel: Jobverlauf laden
Im folgenden Beispiel werden alle Nutzer oder Dienstkonten aufgelistet, die einen Batch-Ladejob für ein bestimmtes Projekt gesendet haben. Da keine Zeitgrenze angegeben ist, durchsucht diese Abfrage den gesamten verfügbaren Verlauf (z. B. die letzten 30 Tage).
SELECT DISTINCT(user_email) AS user FROM `region-us`.INFORMATION_SCHEMA.JOBS WHERE job_type = 'LOAD';
Das Ergebnis sieht etwa so aus:
+--------------+ | user | +--------------+ | abc@xyz.com | +--------------+ | def@xyz.com | +--------------+
Beispiel: Pro Nutzeridentität verarbeitete Byte
Das folgende Beispiel zeigt die Gesamtzahl der Byte, die für Abfragejobs pro Nutzer in Rechnung gestellt werden.
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;
Die Ergebnisse sollten so aussehen:
+---------------------+--------------+
| user_email | bytes_billed |
+---------------------+--------------+
| bob@example.com | 2847932416 |
| alice@example.com | 1184890880 |
| charles@example.com | 10485760 |
+---------------------+--------------+
Beispiel: Stündliche Aufschlüsselung der verarbeiteten Byte
Das folgende Beispiel zeigt die Gesamtzahl der für Abfragejobs in Rechnung gestellten Byte in stündlichen Intervallen.
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
Das Ergebnis sieht etwa so aus:
+-------------------------+--------------+ | 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 | +-------------------------+--------------+