JOBS_TIMELINE 뷰
INFORMATION_SCHEMA.JOBS_TIMELINE 뷰에는 현재 프로젝트에 제출된 모든 작업의 시간 구획별로 거의 실시간에 가까운 BigQuery 메타데이터가 포함됩니다. 이 뷰에는 현재 실행 중인 작업과 완료된 작업이 포함됩니다.
필수 권한
INFORMATION_SCHEMA.JOBS_TIMELINE 뷰를 쿼리하려면 프로젝트에 대한 bigquery.jobs.listAll Identity and Access Management(IAM) 권한이 필요합니다.
사전 정의된 다음 IAM 역할에는 각각 필수 권한이 포함되어 있습니다.
- 프로젝트 소유자
- BigQuery 관리자
BigQuery 권한에 대한 자세한 내용은 IAM으로 액세스 제어를 참조하세요.
스키마
INFORMATION_SCHEMA.JOBS_TIMELINE_BY_* 뷰를 쿼리하면 쿼리 결과에는 모든 BigQuery 작업 실행 내역(초 단위)에 대한 행 하나가 포함됩니다. 각 기간은 1초 간격으로 시작하고 정확히 1초 동안 지속됩니다.
INFORMATION_SCHEMA.JOBS_TIMELINE_BY_* 뷰에는 다음과 같은 스키마가 있습니다.
| 열 이름 | 데이터 유형 | 값 |
|---|---|---|
period_start |
TIMESTAMP |
이 기간의 시작 시간 |
period_slot_ms |
INTEGER |
이 기간 동안 사용된 슬롯(밀리초) |
project_id |
STRING |
(클러스터링 열) 프로젝트의 ID |
project_number |
INTEGER |
프로젝트의 번호 |
user_email |
STRING |
(클러스터링 열) 작업을 실행한 사용자의 이메일 주소 또는 서비스 계정 |
job_id |
STRING |
작업의 ID. 예를 들면 bquxjob_1234입니다. |
job_type |
STRING |
작업의 유형. QUERY, LOAD, EXTRACT, COPY, NULL일 수 있습니다. NULL 값은 백그라운드 작업을 나타냅니다. |
statement_type |
STRING |
유효한 경우 쿼리 문의 유형. 예시: SELECT, INSERT, UPDATE, DELETE. |
priority |
STRING |
이 작업의 우선순위 유효한 값은 INTERACTIVE 및 BATCH입니다. |
parent_job_id |
STRING |
상위 작업의 ID입니다(있는 경우). |
job_creation_time |
TIMESTAMP |
(파티션 나누기 열) 이 작업의 생성 시간 파티션 나누기는 이 타임스탬프의 UTC 시간에 따릅니다. |
job_start_time |
TIMESTAMP |
이 작업의 시작 시간 |
job_end_time |
TIMESTAMP |
이 작업의 종료 시간 |
state |
STRING |
이 기간이 끝날 때 작업 실행 상태 유효한 상태에는 PENDING, RUNNING, DONE이 있습니다. |
reservation_id |
STRING |
이 기간이 끝날 때 이 작업에 할당된 기본 예약의 이름(해당되는 경우) |
edition |
STRING |
이 작업에 할당된 예약과 연결된 버전입니다. 버전에 대한 자세한 내용은 BigQuery 버전 소개를 참조하세요. |
total_bytes_billed |
INTEGER |
프로젝트가 주문형 가격 책정을 사용하도록 구성된 경우 이 필드에는 작업에 대해 청구되는 총 바이트가 포함됩니다. 프로젝트가 정액제를 사용하도록 구성된 경우 바이트 요금이 청구되지 않으며 이 필드는 참고용이 됩니다. 이 필드는 완료된 작업에만 채워지며 작업의 전체 기간 동안 청구된 총 바이트 수를 포함합니다. |
total_bytes_processed |
INTEGER |
작업에서 처리한 총 바이트 이 필드는 완료된 작업에만 채워지며 작업의 전체 기간 동안 처리된 총 바이트 수를 포함합니다. |
error_result |
RECORD |
ErrorProto.
로서 오류 세부정보(해당되는 경우) |
cache_hit |
BOOLEAN |
이 작업의 쿼리 결과가 캐시에서 제공되었는지 여부 |
period_shuffle_ram_usage_ratio |
FLOAT |
선택한 기간의 셔플 사용량 비율 |
period_estimated_runnable_units |
INTEGER |
이 기간에 즉시 예약할 수 있는 작업 단위입니다. 이러한 작업 단위의 추가 슬롯은 예약에 있는 다른 쿼리에 추가 슬롯이 필요하지 않은 한 쿼리를 가속화합니다. |
transaction_id |
STRING |
이 작업이 실행된 트랜잭션의 ID입니다(있는 경우). (미리보기) |
데이터 보관
이 뷰에는 현재 실행 중인 작업과 지난 180일 동안의 작업 기록이 포함되어 있습니다.
범위 및 구문
이 뷰에 대한 쿼리에는 리전 한정자가 있어야 합니다. 리전 한정자를 지정하지 않으면 모든 리전에서 메타데이터가 검색됩니다. 다음 표에는 이 뷰의 리전 범위가 나와 있습니다.
| 뷰 이름 | 리소스 범위 | 리전 범위 |
|---|---|---|
[PROJECT_ID.]`region-REGION`.INFORMATION_SCHEMA.JOBS_TIMELINE[_BY_PROJECT] |
프로젝트 수준 | REGION |
-
선택사항:
PROJECT_ID: Google Cloud 프로젝트의 ID입니다. 지정하지 않으면 기본 프로젝트가 사용됩니다. -
REGION: 모든 데이터 세트 리전 이름입니다. 예를 들면`region-us`입니다.
예시
기본 프로젝트가 아닌 프로젝트에 대해 쿼리를 실행하려면 다음 형식으로 프로젝트 ID를 추가합니다.
`PROJECT_ID`.`region-REGION_NAME`.INFORMATION_SCHEMA.VIEW
`myproject`.`region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE.
다음 예시에서는 마지막 날짜의 슬롯 사용률을 1초마다 계산합니다.
SELECT period_start, SUM(period_slot_ms) AS total_slot_ms, FROM `reservation-admin-project.region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE WHERE period_start BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY) AND CURRENT_TIMESTAMP() GROUP BY period_start ORDER BY period_start DESC;
+---------------------+---------------+ | period_start | total_slot_ms | +---------------------+---------------+ | 2020-07-29 03:52:14 | 122415176 | | 2020-07-29 03:52:15 | 141107048 | | 2020-07-29 03:52:16 | 173335142 | | 2020-07-28 03:52:17 | 131107048 | +---------------------+---------------+
특정 예약에 대한 사용량은 WHERE reservation_id = "…"로 확인할 수 있습니다. 스크립트 작업의 경우 상위 작업은 하위 작업의 총 슬롯 사용량도 보고합니다. 중복 계산이 방지되도록 WHERE statement_type != "SCRIPT"를 사용하여 상위 작업을 제외합니다.
시간 경과에 따른 RUNNING 작업 및 PENDING 작업의 수
기본 프로젝트가 아닌 프로젝트에 대해 쿼리를 실행하려면 다음 형식으로 프로젝트 ID를 추가합니다.
`PROJECT_ID`.`region-REGION_NAME`.INFORMATION_SCHEMA.VIEW
`myproject`.`region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE.
다음 예시에서는 마지막 날짜의 RUNNING 및 PENDING 작업 수를 1초마다 계산합니다.
SELECT period_start, SUM(IF(state = "PENDING", 1, 0)) as PENDING, SUM(IF(state = "RUNNING", 1, 0)) as RUNNING FROM `reservation-admin-project.region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE WHERE period_start BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY) AND CURRENT_TIMESTAMP() GROUP BY period_start;
결과는 다음과 비슷합니다.
+---------------------+---------+---------+ | period_start | PENDING | RUNNING | +---------------------+---------+---------+ | 2020-07-29 03:52:14 | 7 | 27 | | 2020-07-29 03:52:15 | 1 | 21 | | 2020-07-29 03:52:16 | 5 | 21 | | 2020-07-29 03:52:17 | 4 | 22 | +---------------------+---------+---------+
특정 시점의 작업별 리소스 사용량
기본 프로젝트가 아닌 프로젝트에 대해 쿼리를 실행하려면 다음 형식으로 프로젝트 ID를 추가합니다.
`PROJECT_ID`.`region-REGION_NAME`.INFORMATION_SCHEMA.VIEW
`myproject`.`region-us`.INFORMATION_SCHEMA.JOBS.
다음 예시에서는 특정 시점에서 실행되는 모든 작업의 job_id를 1초 동안 사용한 리소스량과 함께 반환합니다.
SELECT job_id, period_slot_ms FROM `reservation-admin-project.region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE_BY_PROJECT WHERE period_start = '2020-07-29 03:52:14' AND (statement_type != 'SCRIPT' OR statement_type IS NULL);
결과는 다음과 비슷합니다.
+------------------+ | job_id | slot_ms | +------------------+ | job_1 | 2415176 | | job_2 | 4417245 | | job_3 | 427416 | | job_4 | 1458122 | +------------------+
관리 리소스 차트의 슬롯 사용 동작 일치
관리 리소스 차트를 사용하여 시간 경과에 따른 조직의 상태, 슬롯 사용량, BigQuery 작업 성능을 모니터링할 수 있습니다. 다음 예시는 관리 리소스 차트에 사용할 수 있는 정보와 비슷하게 INFORMATION_SCHEMA.JOBS_TIMELINE 뷰에서 1시간 간격으로 스롯 사용 타임라인을 쿼리합니다.
DECLARE start_time timestamp DEFAULT TIMESTAMP(START_TIME); DECLARE end_time timestamp DEFAULT TIMESTAMP(END_TIME); WITH snapshot_data AS ( SELECT UNIX_MILLIS(period_start) AS period_start, IFNULL(SUM(period_slot_ms), 0) AS period_slot_ms, DIV(UNIX_MILLIS(period_start), 3600000 * 1) * 3600000 * 1 AS time_ms FROM ( SELECT * FROM `PROJECT_ID.region-US`.INFORMATION_SCHEMA.JOBS_TIMELINE_BY_PROJECT WHERE ((job_creation_time >= TIMESTAMP_SUB(start_time, INTERVAL 1200 MINUTE) AND job_creation_time < TIMESTAMP(end_time)) AND period_start >= TIMESTAMP(start_time) AND period_start < TIMESTAMP(end_time)) AND (statement_type != "SCRIPT" OR statement_type IS NULL) AND REGEXP_CONTAINS(reservation_id, "^PROJECT_ID:") ) GROUP BY period_start, time_ms ), converted_percentiles_data AS ( SELECT time_ms, 100 - CAST(SAFE_DIVIDE(3600000 * 1 * 1 / 1000, COUNT(*)) AS INT64) AS converted_percentiles, FROM snapshot_data GROUP BY time_ms ), data_by_time AS ( SELECT time_ms, IF (converted_percentiles <= 0, 0, APPROX_QUANTILES(period_slot_ms, 100)[SAFE_OFFSET(converted_percentiles)] / 1000) AS p99_slots, SUM(period_slot_ms) / (3600000 * 1) AS avg_slots FROM snapshot_data JOIN converted_percentiles_data AS c USING (time_ms) GROUP BY time_ms, converted_percentiles ) SELECT time_ms, TIMESTAMP_MILLIS(time_ms) AS time_stamp, IFNULL(avg_slots, 0) AS avg_slots, IFNULL(p99_slots, 0) AS p99_slots, FROM ( SELECT time_ms * 3600000 * 1 AS time_ms FROM UNNEST(GENERATE_ARRAY(DIV(UNIX_MILLIS(start_time), 3600000 * 1), DIV(UNIX_MILLIS(end_time), 3600000 * 1) - 1, 1)) AS time_ms ) LEFT JOIN data_by_time USING (time_ms) ORDER BY time_ms DESC;
대기 중인 작업이 있었던 실행 시간의 비율 계산
기본 프로젝트가 아닌 프로젝트에 대해 쿼리를 실행하려면 다음 형식으로 프로젝트 ID를 추가합니다.
`PROJECT_ID`.`region-REGION_NAME`.INFORMATION_SCHEMA.VIEW
`myproject`.`region-us`.INFORMATION_SCHEMA.JOBS입니다.
다음 예에서는 period_estimated_runnable_units 값이 0이 아닌 총 작업 실행 기간의 비율을 나타내는 부동 소수점 값을 반환합니다. 이는 작업에서 더 많은 슬롯을 요청하고 있음을 의미합니다. 값이 크면 작업에 슬롯 경합이 발생했음을 나타내고 값이 작으면 작업이 대부분의 실행 시간 동안 슬롯을 요청하지 않았음을 나타내므로 슬롯 경합이 거의 또는 전혀 없었음을 의미합니다.
결과 값이 큰 경우 슬롯을 더 추가하여 영향을 확인하고 슬롯 경합이 유일한 병목 현상인지 파악할 수 있습니다.
SELECT ROUND(COUNTIF(period_estimated_runnable_units > 0) / COUNT(*) * 100, 1) as execution_duration_percentage FROM `myproject`.`region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE WHERE job_id = 'my_job_id' GROUP BY job_id
쿼리 실행 날짜를 알고 있는 경우 쿼리에 DATE(period_start) = 'YYYY-MM-DD' 절을 추가하여 처리되는 바이트 수를 줄이고 실행 속도를 높입니다. 예를 들면 DATE(period_start) = '2025-08-22'입니다.
결과는 다음과 비슷합니다.
+-------------------------------+ | execution_duration_percentage | +-------------------------------+ | 96.7 | +-------------------------------+