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 문이 포함된 쿼리인 경우 값은 다음 필드를 포함하는 레코드입니다.
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 형식입니다.이 출력에서 각 항목의 의미는 다음과 같습니다.
|
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=SCRIPTreservation_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입니다.
예시
기본 프로젝트가 아닌 다른 프로젝트에 대해 쿼리를 실행하려면
`PROJECT_ID`.`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS형식으로 프로젝트 ID를 추가합니다. 다음을 바꿉니다.
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 Enterprise 버전 사용한 만큼만 지불하는 SKU로 보고됩니다.
INFORMATION_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분 이상 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 | +------------+------------+----------+----------------+
테이블당 쿼리 및 로드 작업으로 수정된 파티션 수
다음 예시에서는 테이블마다 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_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로 바꿉니다.
관리 리소스 차트의 슬롯 사용 동작 일치
관리 리소스 차트의 정보와 유사한 슬롯 사용 동작을 살펴보려면 INFORMATION_SCHEMA.JOBS_TIMELINE 뷰를 쿼리합니다.