BigQuery 고급 런타임 사용
BigQuery 고급 런타임은 사용자 작업이나 코드 변경 없이 분석 워크로드를 자동으로 가속화하도록 설계된 성능 향상 기능의 집합입니다. 이 문서에서는 향상된 벡터화 및 짧은 쿼리 최적화를 비롯한 이러한 성능 개선사항을 설명합니다.
역할 및 권한
구성 설정을 지정하는 데 필요한 권한을 얻으려면 관리자에게 프로젝트 또는 조직에 대한 BigQuery 관리자 (roles/bigquery.admin) IAM 역할을 부여해 달라고 요청하세요.
역할 부여에 대한 자세한 내용은 프로젝트, 폴더, 조직에 대한 액세스 관리를 참조하세요.
커스텀 역할이나 다른 사전 정의된 역할을 통해 필요한 권한을 얻을 수도 있습니다.
향상된 벡터화
벡터화된 실행은 CPU 캐시 크기에 맞춰 정렬된 블록의 데이터 열에서 작동하고 단일 명령, 다중 데이터(SIMD) 명령어를 사용하는 쿼리 처리 모델입니다. 향상된 벡터화는 BigQuery의 벡터화된 쿼리 실행을 쿼리 처리의 다음 측면으로 확장합니다.
- Capacitor 스토리지 형식 내에서 특수 데이터 인코딩을 활용하면 인코딩된 데이터에서 필터 평가 작업을 실행할 수 있습니다.
- 전문 인코딩은 쿼리 계획을 통해 전파되므로 인코딩된 상태에서 더 많은 데이터를 처리할 수 있습니다.
- 결정론적 함수와 상수 표현식을 평가하기 위해 표현식 폴딩을 구현하면 BigQuery에서 복잡한 조건자를 상수 값으로 단순화할 수 있습니다.
짧은 쿼리 최적화
BigQuery는 일반적으로 셔플 중간 레이어를 사용하여 분산 환경에서 쿼리를 실행합니다. 짧은 쿼리 최적화는 단일 단계로 실행할 수 있는 쿼리를 동적으로 식별하여 지연 시간과 슬롯 소비를 줄입니다. 쿼리가 단일 단계로 실행될 때 전문화된 인코딩을 더 효과적으로 사용할 수 있습니다. 이러한 최적화는 작업 시작, 유지보수, 결과 검색 지연 시간을 최소화하는 선택적 작업 생성 모드와 함께 사용할 때 가장 효과적입니다.
짧은 쿼리 최적화 사용 자격 요건은 동적이며 다음 요인의 영향을 받습니다.
- 예상 데이터 스캔 크기
- 필요한 데이터 이동량
- 쿼리 필터의 선택성
- 스토리지에 있는 데이터의 유형 및 물리적 레이아웃
- 전체 쿼리 구조
- 이전 쿼리 실행의 이전 통계
고급 런타임 사용 설정
2025년 9월 15일과 2026년 초 사이에 BigQuery는 모든 프로젝트의 기본 런타임으로 고급 런타임을 사용하기 시작합니다. 기존 프로젝트 또는 조직에서 지금 고급 런타임을 사용 설정하려면 ALTER PROJECT 또는 ALTER ORGANIZATION 문을 사용하여 기본 구성을 변경합니다. 문에서 query_runtime 인수를 'advanced'로 설정합니다. 예를 들면 다음과 같습니다.
ALTER PROJECTPROJECT_NAMESET OPTIONS ( `region-LOCATION.query_runtime` = 'advanced' );
다음을 바꿉니다.
PROJECT_NAME: 프로젝트 이름LOCATION: 작업이 고급 런타임을 사용하려고 시도해야 하는 위치입니다.
변경사항이 적용되는 데 몇 분 정도 걸릴 수 있습니다.
고급 런타임을 사용 설정하면 쿼리 작업을 만든 사용자에 관계없이 프로젝트 또는 조직의 적격 쿼리에서 고급 런타임을 사용합니다.
고급 런타임의 영향 추정
고급 런타임의 영향을 추정하려면 다음 SQL 쿼리를 사용하여 실행 시간의 예상 개선이 가장 큰 프로젝트 쿼리를 식별하면 됩니다.
WITH
jobs AS (
SELECT
*,
query_info.query_hashes.normalized_literals AS query_hash,
TIMESTAMP_DIFF(end_time, start_time, MILLISECOND) AS elapsed_ms,
EXISTS(
SELECT 1
FROM UNNEST(JSON_QUERY_ARRAY(query_info.optimization_details.optimizations)) AS o
WHERE JSON_VALUE(o, '$.enhanced_vectorization') = 'applied'
) AS has_advanced_runtime
FROM region-LOCATION.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE EXTRACT(DATE FROM creation_time) > DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
),
most_recent_jobs_without_advanced_runtime AS (
SELECT *
FROM jobs
WHERE NOT has_advanced_runtime
QUALIFY ROW_NUMBER() OVER (PARTITION BY query_hash ORDER BY end_time DESC) = 1
)
SELECT
job.job_id,
100 * SAFE_DIVIDE(
original_job.elapsed_ms - job.elapsed_ms,
original_job.elapsed_ms) AS percent_execution_time_saved,
job.elapsed_ms AS new_elapsed_ms,
original_job.elapsed_ms AS original_elapsed_ms,
FROM jobs AS job
INNER JOIN most_recent_jobs_without_advanced_runtime AS original_job
USING (query_hash)
WHERE
job.has_advanced_runtime
AND original_job.end_time < job.start_time
ORDER BY percent_execution_time_saved DESC
LIMIT 10;
다음을 바꿉니다.
LOCATION: 작업 실적을 측정해야 하는 위치입니다.
고급 런타임이 사용 설정되고 적용된 경우 이 쿼리의 결과는 다음과 비슷할 수 있습니다.
/*--------------+----------------------------+----------------+---------------------*
| job_id | percent_elapsed_time_saved | new_elapsed_ms | original_elapsed_ms |
+--------------+----------------------------+----------------+---------------------+
| sample_job1 | 45.38834951456311 | 225 | 412 |
| sample_job2 | 45.19480519480519 | 211 | 385 |
| sample_job3 | 33.246753246753244 | 257 | 385 |
| sample_job4 | 29.28802588996764 | 1311 | 1854 |
| sample_job5 | 28.18181818181818 | 1027 | 1430 |
| sample_job6 | 25.804195804195807 | 1061 | 1430 |
| sample_job7 | 25.734265734265733 | 1062 | 1430 |
| sample_job8 | 25.454545454545453 | 1066 | 1430 |
| sample_job9 | 25.384615384615383 | 1067 | 1430 |
| sample_job10 | 25.034965034965033 | 1072 | 1430 |
*--------------+----------------------------+----------------+---------------------*/
이 쿼리의 결과는 고급 런타임의 영향에 대한 추정치일 뿐입니다. 슬롯 가용성, 시간 경과에 따른 데이터 변경, 뷰 또는 UDF 정의, 쿼리 파라미터 값의 차이를 포함하되 이에 국한되지 않는 여러 요인이 쿼리 성능에 영향을 줄 수 있습니다.
이 쿼리의 결과가 비어 있으면 고급 런타임을 사용한 작업이 없거나 모든 작업이 최적화된 지 30일이 지난 것입니다.
이 쿼리는 total_slot_ms 및 total_bytes_billed와 같은 다른 쿼리 성능 측정항목에 적용할 수 있습니다. 자세한 내용은 INFORMATION_SCHEMA.JOBS_BY_PROJECT의 스키마를 참조하세요.