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`, `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: `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     |
+-------------------------+--------------+