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:

  • RESERVATION_ADMIN_PROJECT: der Name des Google Cloud-Projekts, das die Reservierung verwaltet
  • RESERVATION_LOCATION: der Standort der Reservierung
  • RESERVATION_NAME: der Name der Reservierung
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, valueauf 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:

  • inserted_row_count: Die Anzahl der eingefügten Zeilen.
  • deleted_row_count: Die Anzahl der gelöschten Zeilen.
  • updated_row_count: Die Anzahl der aktualisierten Zeilen.

Bei allen anderen Jobs lautet der Wert NULL.

Diese Spalte ist in den Ansichten INFORMATION_SCHEMA.JOBS_BY_USER und INFORMATION_SCHEMA.JOBS_BY_PROJECT vorhanden.

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
Dabei gilt:

  • 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.JOBS
Dabei 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     |
+-------------------------+--------------+