JOBS 뷰

INFORMATION_SCHEMA.JOBS 뷰에는 현재 프로젝트의 모든 BigQuery 작업에 대한 실시간에 가까운 메타데이터가 포함됩니다.

필요한 역할

INFORMATION_SCHEMA.JOBS 뷰를 쿼리하는 데 필요한 권한을 얻으려면 관리자에게 프로젝트에 대한 BigQuery 리소스 뷰어(roles/bigquery.resourceViewer) IAM 역할을 부여해 달라고 요청하세요. 역할 부여에 대한 자세한 내용은 액세스 관리를 참조하세요.

이 사전 정의된 역할에는 INFORMATION_SCHEMA.JOBS 뷰를 쿼리하는 데 필요한 bigquery.jobs.listAll 권한이 포함되어 있습니다.

커스텀 역할이나 다른 사전 정의된 역할을 사용하여 이 권한을 부여받을 수도 있습니다.

BigQuery 권한에 대한 자세한 내용은 IAM으로 액세스 제어를 참조하세요.

스키마

기본 데이터는 creation_time 열로 파티션을 나누고 project_id 및 user_email로 클러스터링됩니다. query_info 열에는 쿼리 작업에 대한 추가 정보가 포함됩니다.

INFORMATION_SCHEMA.JOBS 뷰에는 다음과 같은 스키마가 있습니다.

열 이름	데이터 유형	값
`bi_engine_statistics`	`RECORD`	프로젝트가 BI Engine SQL 인터페이스를 사용하도록 구성된 경우 이 필드에는 BiEngineStatistics가 포함됩니다. 그 외의 경우에는 `NULL`입니다.
`cache_hit`	`BOOLEAN`	이 작업의 쿼리 결과가 캐시에서 제공되었는지 여부 멀티 쿼리 문 작업이 있는 경우 상위 쿼리의 `cache_hit`는 `NULL`입니다.
`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_USER` 및 `INFORMATION_SCHEMA.JOBS_BY_PROJECT` 뷰에 있습니다.
`end_time`	`TIMESTAMP`	작업의 종료 시간입니다(에포크 이후의 경과 시간(밀리초)). 이 필드는 작업이 `DONE` 상태가 되는 시간을 나타냅니다.
`error_result`	`RECORD`	ErrorProto 객체로서의 오류 세부정보입니다.
`job_id`	`STRING`	작업의 ID입니다. 예를 들면 `bquxjob_1234`입니다.
`job_stages`	`RECORD`	작업의 쿼리 단계입니다. 참고: 행 수준 액세스 정책이 적용되는 테이블에서 읽는 쿼리의 경우 이 열의 값이 비어 있습니다. 자세한 내용은 BigQuery의 행 수준 보안 권장사항을 참조하세요.
`job_type`	`STRING`	작업의 유형. `QUERY`, `LOAD`, `EXTRACT`, `COPY`, `NULL`일 수 있습니다. `NULL` 값은 스크립트 작업 문 평가 또는 구체화된 뷰 새로고침과 같은 내부 작업을 나타냅니다.
`labels`	`RECORD`	키-값 쌍으로 작업에 적용된 라벨의 배열
`parent_job_id`	`STRING`	상위 작업의 ID(있는 경우)
`priority`	`STRING`	이 작업의 우선순위. 유효한 값은 `INTERACTIVE` 및 `BATCH`입니다.
`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`: 예약 이름입니다.
`session_info`	`RECORD`	이 작업이 실행된 세션에 대한 세부정보입니다(있는 경우). (미리보기)
`start_time`	`TIMESTAMP`	작업의 시작 시간입니다(에포크 이후의 경과 시간(밀리초)). 이 필드는 작업이 `PENDING` 상태에서 `RUNNING` 또는 `DONE` 상태가 되는 시간을 나타냅니다.
`state`	`STRING`	작업의 실행 상태. 유효한 상태에는 `PENDING`, `RUNNING`, `DONE`이 있습니다.
`statement_type`	`STRING`	쿼리 문의 유형입니다. 예를 들면 `DELETE`, `INSERT`, `SCRIPT`, `SELECT`, `UPDATE`입니다. 유효한 값 목록은 QueryStatementType을 참조하세요.
`timeline`	`RECORD`	작업의 쿼리 타임라인입니다. 쿼리 실행 스냅샷을 포함합니다.
`total_bytes_billed`	`INTEGER`	프로젝트가 주문형 가격 책정을 사용하도록 구성된 경우 이 필드에는 작업에 대해 청구되는 총 바이트가 포함됩니다. 프로젝트가 정액제를 사용하도록 구성된 경우 바이트 요금이 청구되지 않으며 이 필드는 참고용이 됩니다. 참고: 행 수준 액세스 정책이 적용되는 테이블에서 읽는 쿼리의 경우 이 열의 값이 비어 있습니다. 자세한 내용은 BigQuery의 행 수준 보안 권장사항을 참조하세요.
`total_bytes_processed`	`INTEGER`	작업에서 처리한 총 바이트 참고: 행 수준 액세스 정책이 적용되는 테이블에서 읽는 쿼리의 경우 이 열의 값이 비어 있습니다. 자세한 내용은 BigQuery의 행 수준 보안 권장사항을 참조하세요.
`total_modified_partitions`	`INTEGER`	작업에서 수정한 총 파티션 수입니다. 이 필드는 `LOAD` 및 `QUERY` 작업에 채워집니다.
`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`는 주석, 매개변수 값, UDF, 리터럴을 무시하는 16진수 `STRING` 해시입니다. 이 필드는 캐시 적중이 아닌 성공한 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로 변수를 정의하거나 IF 또는 WHILE과 같은 흐름 제어 문을 포함하는 경우가 많습니다. 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입니다.

참고: INFORMATION_SCHEMA 뷰를 쿼리할 위치를 지정해야 합니다. 쿼리 실행 위치는 INFORMATION_SCHEMA 뷰의 리전과 일치해야 합니다.

예시

기본 프로젝트가 아닌 프로젝트에 대해 쿼리를 실행하려면 다음 형식으로 프로젝트 ID를 추가합니다.

`PROJECT_ID`.`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS

다음을 바꿉니다.

PROJECT_ID: 프로젝트 ID
REGION_NAME: 프로젝트 리전

예를 들면 `myproject`.`region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT입니다.

평균 슬롯 사용량 계산

다음 예시에서는 지정된 프로젝트의 지난 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분 넘게 RUNNING 또는 PENDING 상태인 장기 실행 작업 목록을 보여줍니다.

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

사용자 ID당 처리되는 바이트 수

다음 예시는 사용자당 쿼리 작업에 대해 청구되는 총 바이트를 보여줍니다.

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

프로젝트별로 비용이 가장 많이 드는 쿼리

다음 예시에는 슬롯 사용 시간별로 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_id는 NULL입니다.

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;

쿼리 성능 통계 보기

다음 예시에서는 Google Cloud 콘솔의 쿼리 실행 그래프에 연결되는 URL과 함께 지난 30일 동안 프로젝트의 성능 통계가 있는 모든 쿼리 작업을 반환합니다.

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로 바꿉니다.