파티션이 아주 많은 테이블에 대해 조건 없이 SELECT * FROM <table> LIMIT 100 을 실행하면 실행 단계가 아니라 컴파일 단계에서 수백 초가 걸린다. HiveServer2 로그의 PerfLogger 에는 semanticAnalyze 나 Calculating column stats 가 수백 초로 찍힌다. hive.cbo.enable=false 로 두면 즉시 결과가 나온다.
WHERE 절에 파티션 조건이 없으면 파티션 프루닝이 걸리지 않으므로 컴파일 단계에서 테이블의 모든 파티션 메타데이터를 메타스토어에서 읽는다. 파티션이 수만 ~ 수십만 건이면 이 조회 자체가 병목이 된다.
여기에 CBO(Cost-Based Optimizer)가 얹히면 비용이 더 커진다. CBO 는 실행 계획을 고르기 위해 테이블·파티션·컬럼 통계를 함께 읽고 계산하므로, 파티션 수와 컬럼 수에 비례해 컴파일 시간이 늘어난다. hive.cbo.enable=false 로 빨라지는 것은 이 통계 수집·계산 경로를 통째로 건너뛰기 때문이며, 문제의 원인이 CBO 라기보다 프루닝 없이 전체 파티션을 대상으로 CBO 가 도는 것이 원인이다.
LIMIT 은 컴파일이 끝난 뒤 적용되는 절이므로 컴파일 비용을 줄여 주지 않는다.
SELECT * FROM <db>.<table>
WHERE <partition_column> = '<value>'
LIMIT 100;
데이터를 확인하려는 목적이라면 아무 파티션 하나만 지정하면 된다. 파티션 목록은 메타데이터만 읽는 명령으로 빠르게 얻을 수 있다.
SHOW PARTITIONS <db>.<table>;
집계도 조인도 없는 단순 조회는 실행 엔진을 거치지 않고 클라이언트가 직접 파일을 읽게 할 수 있다.
SET hive.fetch.task.conversion=more;
SET hive.limit.optimize.enable=true;
컴파일 때마다 통계를 계산하지 않도록 사전에 수집해 둔다. 파티션 테이블은 조회 대상 파티션 단위로 돌리는 편이 부담이 적다.
ANALYZE TABLE <db>.<table> PARTITION (<partition_column>='<value>') COMPUTE STATISTICS;
ANALYZE TABLE <db>.<table> PARTITION (<partition_column>='<value>') COMPUTE STATISTICS FOR COLUMNS;
SET hive.metastore.try.direct.sql=true;
메타스토어 백엔드 DB 가 느리면 이 단계가 그대로 지연으로 나타나므로, PARTITIONS · PARTITION_KEY_VALS 계열 테이블에 대한 질의 성능과 DB 자원 상태도 함께 본다.
SET hive.cbo.enable=false; 는 세션 단위로 급할 때만 쓰는 임시 조치다. CBO 를 끄면 조인 순서와 필터 배치 최적화가 사라져 다른 쿼리가 느려진다. 전역 설정으로 내리지 않는다.
CREATE INDEX 계열의 Hive 인덱스 기능은 제거됐다. hive.optimize.index.filter 는 그 인덱스가 아니라 ORC·Parquet 의 내장 인덱스를 이용한 조건 푸시다운을 켜는 설정이므로 켜 두는 쪽이 일반적으로 이롭다.hive.stats.fetch.partition.stats 는 Hive 3 계열에서 더 이상 쓰이지 않는 것으로 보인다 — 확인 필요. 설정해도 반응이 없다면 CDP 의 Hive 버전 기준 설정 목록을 먼저 대조한다.