JOBS 视图

INFORMATION_SCHEMA.JOBS 视图包含当前项目中所有 BigQuery 作业的近乎实时元数据。

所需角色

如需获得查询 INFORMATION_SCHEMA.JOBS 视图所需的权限,请让您的管理员为您授予项目的 BigQuery Resource Viewer (roles/bigquery.resourceViewer) IAM 角色。如需详细了解如何授予角色,请参阅管理对项目、文件夹和组织的访问权限

此预定义角色可提供 bigquery.jobs.listAll 权限,查询 INFORMATION_SCHEMA.JOBS 视图需要该权限。

您也可以使用自定义角色或其他预定义角色来获取此权限。

如需详细了解 BigQuery 权限,请参阅使用 IAM 进行访问权限控制

架构

底层数据按 creation_time 列进行分区,并按 project_iduser_email 进行聚簇。 query_info 列包含有关查询作业的详细信息。

INFORMATION_SCHEMA.JOBS 视图具有如下架构:

列名 数据类型
bi_engine_statistics RECORD 如果项目配置为使用 BI Engine SQL 接口,则此字段包含 BiEngineStatistics。否则为 NULL
cache_hit BOOLEAN 查询此作业的查询结果是否来自缓存。 如果您有多查询语句作业,则父查询的 cache_hitNULL
creation_time TIMESTAMP (分区列)此作业的创建时间。分区基于相应时间戳的世界协调时间 (UTC)。
destination_table RECORD 结果的目标(如有)。
dml_statistics RECORD 如果作业是具有 DML 语句的查询,则值是包含以下字段的记录:
  • inserted_row_count:已插入的行数。
  • deleted_row_count:已删除的行数。
  • updated_row_count:已更新的行数。
对于所有其他作业,值为 NULL
INFORMATION_SCHEMA.JOBS_BY_USERINFORMATION_SCHEMA.JOBS_BY_PROJECT 视图中存在此列。
end_time TIMESTAMP 此作业的结束时间(从纪元开始计算,以毫秒为单位)。此字段表示作业进入 DONE 状态的时间。
error_result RECORD 作为 ErrorProto 对象的任何错误的详细信息。
job_creation_reason.code STRING 指定创建作业的简要原因。
可能的值包括:
  • REQUESTED:请求创建作业。
  • LONG_RUNNING:查询请求运行超出 QueryRequest 中的 timeoutMs 字段指定的系统定义超时时间。因此,查询被视为为其创建作业的长时间运行的操作。
  • LARGE_RESULTS:查询的结果无法放入内嵌响应中。
  • OTHER:系统已确定需要将查询作为作业执行。
job_id STRING 作业的 ID(如果已创建作业)。否则,该值是使用短查询模式的查询的 ID。例如 bquxjob_1234
job_stages RECORD 作业的查询阶段

注意:对于从具有行级访问权限政策的表中读取的查询,此列的值为空。如需了解详情,请参阅 BigQuery 中行级安全性的最佳实践

job_type STRING 作业的类型。可以是 QUERYLOADEXTRACTCOPYNULLNULL 值表示内部作业,例如脚本作业语句评估或物化视图刷新。
labels RECORD 作为键值对应用于作业的标签数组。
parent_job_id STRING 父级作业的 ID(如有)。
priority STRING 此作业的优先级。 有效值包括 INTERACTIVEBATCH
project_id STRING (聚簇列)项目的 ID。
project_number INTEGER 项目编号。
query STRING SQL 查询文本。只有 JOBS_BY_PROJECT 视图具有查询列。
referenced_tables RECORD 作业引用的数组。仅针对非缓存命中的查询作业进行填充。
reservation_id STRING 分配给此作业的主要预留的名称,格式为 RESERVATION_ADMIN_PROJECT:RESERVATION_LOCATION.RESERVATION_NAME
在此输出中:
  • RESERVATION_ADMIN_PROJECT:管理预留的 Google Cloud 项目的名称
  • RESERVATION_LOCATION:预留的位置
  • RESERVATION_NAME:预留的名称
edition STRING 与分配给此作业的预留关联的版本。如需详细了解版本,请参阅 BigQuery 版本简介
session_info RECORD 此作业在其中运行的会话的详细信息(如果有)。
start_time TIMESTAMP 此作业的开始时间(从纪元开始计算,以毫秒为单位)。此字段表示作业从 PENDING 状态转换为 RUNNINGDONE 的时间。
state STRING 作业的运行状态。有效状态包括 PENDINGRUNNINGDONE
statement_type STRING 查询语句的类型。例如 DELETEINSERTSCRIPTSELECTUPDATE。如需查看有效值的列表,请参阅 QueryStatementType
timeline RECORD 作业的查询时间轴。包含查询执行情况的快照。
total_bytes_billed INTEGER 如果项目配置为使用按需价格,则此字段包含作业的总计费字节数。如果项目配置为使用固定价格,则您无需为字节付费,并且此字段仅供参考。

注意:对于从具有行级访问权限政策的表中读取的查询,此列的值为空。如需了解详情,请参阅 BigQuery 中行级安全性的最佳实践

total_bytes_processed INTEGER

作业处理的字节总数。

注意:对于从具有行级访问权限政策的表中读取的查询,此列的值为空。如需了解详情,请参阅 BigQuery 中行级安全性的最佳实践

total_modified_partitions INTEGER 作业修改的分区总数。系统会针对 LOADQUERY 作业填充此字段。
total_slot_ms INTEGER 处于 RUNNING 状态的作业在其整个时间段内的槽毫秒数,包括重试。
transaction_id STRING 此作业在其中运行的事务的 ID(如果有)。(预览版
user_email STRING (聚簇列)运行作业的用户的电子邮件地址或服务账号。
query_info.resource_warning STRING 查询处理期间的资源用量超出系统内部阈值时出现的警告消息。
成功的查询作业会填充 resource_warning 字段。借助 resource_warning,您可以获得更多数据点来优化查询,并使用 query_hashes 对等效的一组查询的性能趋势设置监控。
query_info.query_hashes.normalized_literals STRING 包含查询的哈希值。normalized_literals 是一个十六进制 STRING 哈希值,忽略注释、参数值、UDF 和字面量。
系统会对非缓存命中的成功 GoogleSQL 查询显示此字段。
query_info.performance_insights RECORD 作业的性能数据分析
query_info.optimization_details STRUCT 作业的基于历史记录的优化
transferred_bytes INTEGER 跨云查询(例如 BigQuery Omni 跨云转移作业)转移的总字节数。
materialized_view_statistics RECORD 查询作业中考虑的具体化视图的统计信息。(预览版

当您查询 INFORMATION_SCHEMA.JOBS 以查找查询作业的汇总费用时,请排除 SCRIPT 语句类型,否则某些值会被重复计算。SCRIPT 行包含在此作业中执行的所有子作业的汇总值。

多语句查询作业

多语句查询作业是指使用过程语言的查询作业。多语句查询作业通常使用 DECLARE 定义变量,或者包含 IFWHILE 等控制流语句。在查询 INFORMATION_SCHEMA.JOBS 时,您可能需要了解多语句查询作业与其他作业的区别。多语句查询作业具有以下特征:

  • statement_type = SCRIPT
  • reservation_id = NULL
  • 子作业。多语句查询作业的每个子作业都有一个 parent_job_id,指向多语句查询作业本身。其中包含在此作业中执行的所有子作业的汇总值。因此,如果您查询 INFORMATION_SCHEMA.JOBS 以查找查询作业的汇总费用,则应排除 SCRIPT 语句类型,否则某些值(例如 total_slot_ms)可能会被计入两次。

数据保留

此视图包含当前正在运行的作业和过去 180 天的作业历史记录。

范围和语法

针对此视图的查询必须包含区域限定符。下表说明了此视图的区域范围:

视图名称 资源范围 区域范围
[PROJECT_ID.]`region-REGION`.INFORMATION_SCHEMA.JOBS[_BY_PROJECT] 项目级 REGION
替换以下内容:

  • 可选:PROJECT_ID:您的 Google Cloud 项目的 ID。如果未指定,则使用默认项目。
+ REGION:任何数据集区域名称。 例如 region-us

示例

如需对非默认项目运行查询,请按以下格式添加项目 ID:

`PROJECT_ID`.`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
替换以下内容:

  • PROJECT_ID:项目的 ID。
  • REGION_NAME:项目的区域。

例如 `myproject`.`region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT

将作业用量与结算数据进行比较

对于使用按需结算方式的项目,您可以使用 INFORMATION_SCHEMA.JOBS 视图查看给定时间段内的计算费用。以下查询会生成您的结算 TiB 每日估算汇总和产生的费用。限制部分说明了这些估算值何时可能与您的账单不符。

仅对于本示例,必须设置以下附加变量。可以在此处进行修改,以方便使用。

  • START_DATE:汇总计算所涵盖的最早日期(包括该日期)。
  • END_DATE:汇总计算所涵盖的最晚日期(包括该日期)。
  • PRICE_PER_TIB:用于估算账单的每 TiB 按需价格
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

限制

  • 对于对具有行级安全性的表的查询,BigQuery 会隐藏某些统计信息。提供的查询将受影响的作业数计为 jobs_using_row_level_security,但无权访问计费用量。

  • BigQuery ML 按需查询的价格取决于要创建的模型类型。INFORMATION_SCHEMA.JOBS 不会跟踪已创建的模型类型,因此提供的查询假定所有 CREATE_MODEL 语句都是创建费用更高的模型类型。

  • Apache Spark 过程使用相似价格模式,但费用会报告为BigQuery 企业版随用随付 SKUINFORMATION_SCHEMA.JOBS 会将此用量作为 total_bytes_billed 进行跟踪,但无法确定相应用量代表哪个 SKU。

计算平均槽利用率

以下示例会计算指定项目在过去 7 天内所有查询的平均槽利用率。请注意,此计算对于在一周内槽使用量一致的项目最为准确。如果项目的槽使用量不一致,则此数字可能会低于预期。

要运行查询,请执行以下操作:

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();

结果类似于以下内容:

+------------+
| avg_slots  |
+------------+
| 3879.1534  |
+------------+

您可以使用 WHERE reservation_id = "…" 检查特定预留的使用率。这可能有助于确定预留在一段时间内的使用百分比。对于脚本作业,父级作业还会报告其子作业的总体槽使用量。为了避免重复计算,请使用 WHERE statement_type != "SCRIPT" 排除父作业。

如果您希望查看各个作业的平均槽利用率,请使用 total_slot_ms / TIMESTAMP_DIFF(end_time, start_time, MILLISECOND)

加载作业历史记录

以下示例会列出针对指定项目提交批量加载作业的所有用户或服务账号。由于未指定时间边界,因此该查询会扫描所有可用历史记录(例如,过去 30 天)。

SELECT
  DISTINCT(user_email) AS user
FROM
  `region-us`.INFORMATION_SCHEMA.JOBS
WHERE
  job_type = 'LOAD';

结果类似于以下内容:

+--------------+
| user         |
+--------------+
| abc@xyz.com  |
+--------------+
| def@xyz.com  |
+--------------+

获取加载作业数量以确定每天使用的作业配额

以下示例按天、数据集和表返回作业数,以便确定使用的每日作业配额量。

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

获取最近 10 个失败的作业

以下示例展示了最近 10 个失败的作业:

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

结果应如下所示:

+---------------+--------------------------+------------------+-----------------------------------------------------------+
| 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...|
+---------------+--------------------------+------------------+-----------------------------------------------------------+

查询长时间运行的作业列表

以下示例展示了运行时间超过 30 分钟且处于 RUNNINGPENDING 状态的长时间运行作业的列表:

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;

结果类似于以下内容:

+---------------+----------+---------+--------------------------------+--------------------------------+------------------+
| 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  |
+---------------+----------+---------+--------------------------------+--------------------------------+------------------+

使用短查询优化模式的查询

以下示例展示了在短查询优化模式下执行且 BigQuery 没有为其创建作业的查询列表。

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

结果应如下所示:

+------------------------------------------+
| job_id                                   |
+------------------------------------------+
| 2Lm09bHxDEsoVK8zwzWJomLHU_Ud%1910479b151 |
| j9_GVQf28jW2M1_RfTYGRPX1vq--!191047a135f | 
+------------------------------------------+

以下示例展示了在短查询优化模式下执行且 BigQuery 没有为其创建作业的查询的相关信息。

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

注意:如果没有为此查询创建作业,job_id 字段会包含该查询的 queryId

结果应如下所示:

+------------------------------------------+----------------+-------------+-----------+--------------------------+--------------------+-----------------------+---------------+-------+----------------------+
| 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                 |
+------------------------------------------+----------------+-------------+-----------+--------------------------+--------------------+-----------------------+---------------+-------+----------------------+

以下示例展示了在短查询优化模式下执行且 BigQuery 为其创建了作业的查询列表。

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

结果应如下所示:

+----------------------------------+--------------------------+
| job_id                           | job_creation_reason_code |
+----------------------------------+--------------------------+
| job_LxOEwrJEffcOfjK7GBwWjO3RroOI | LARGE_RESULTS            |
+----------------------------------+--------------------------+

每个用户身份处理的字节数

以下示例展示了每个用户的查询作业结算的总字节数:

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;

注意:请参阅 JOBS 视图的架构文档中的 total_bytes_billed 列的注意事项。

结果应如下所示:

+---------------------+--------------+
| user_email          | bytes_billed |
+---------------------+--------------+
| bob@example.com     | 2847932416   |
| alice@example.com   | 1184890880   |
| charles@example.com | 10485760     |
+---------------------+--------------+

已处理的字节数的每小时明细

以下示例显示了查询作业按小时间隔计费的总字节数:

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;

结果类似于以下内容:

+-------------------------+--------------+
| 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     |
+-------------------------+--------------+

每个表的查询作业数

以下示例展示了查询作业引用 my_project 中查询的每个表的次数:

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;

结果类似于以下内容:

+------------+------------+----------+----------------+
| 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             |
+------------+------------+----------+----------------+

每个表由查询和加载作业修改的分区数

以下示例展示了每个表中使用 DML 语句和加载作业的查询修改的分区数。请注意,此查询不显示复制作业的 total_modified_partitions

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

费用最高的查询(按项目)

以下示例按槽使用时间列出了 my_project 中费用最高的查询:

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

您还可以使用以下示例按处理的数据量列出费用最高的查询:

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

任一示例的结果如下所示:

+--------------+---------------------------------+-----------------------+---------------+
| 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        |
+--------------+---------------------------------+-----------------------+---------------+

获取有关资源警告的详细信息

如果您收到超出资源数错误消息,则可以在时间段内查看查询:

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;

监控按日期分组的资源警告

如果您收到超出资源数错误消息,则可以监控按日期分组的资源警告总数,以了解工作负载是否存在任何更改:

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;

估算查询的槽用量和费用

以下示例使用 estimated_runnable_units 计算每个作业的平均槽数和槽数上限。

如果您没有任何预留,则 reservation_idNULL

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;

查看查询的性能数据分析

以下示例会返回过去 30 天内具有项目中性能数据分析的所有查询作业,以及链接到 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
  );

查看元数据刷新作业

以下示例列出了元数据刷新作业:

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;

分析相同查询在一段时间内的表现

以下示例会返回过去 7 天内运行同一查询的前 10 个最慢的作业:

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;

JOB_ID 替换为运行您要分析的查询的任何 job_id

匹配管理资源图表中的槽用量行为

如需探索与管理资源图表中的信息类似的槽用量行为,请查询 INFORMATION_SCHEMA.JOBS_TIMELINE 视图