Hive 와 Impala 는 같은 데이터, 같은 메타스토어를 보면서도 성격이 정반대인 엔진이다. 하나를 고르는 문제가 아니라 어느 작업을 어디로 보낼지 나누는 문제다. 사내 교육 자료나 설계 검토에서 한 장으로 정리해야 할 때 쓰도록 요점만 모았다.
| 항목 | Hive | Impala |
|---|---|---|
| 실행 방식 | 쿼리를 Tez(과거에는 MapReduce) DAG 으로 바꿔 YARN 에 제출 | 데몬이 상주하며 직접 실행. YARN 을 거치지 않음 |
| 시작 지연 | 컨테이너 기동 때문에 수 초 이상 | 수십 밀리초 |
| 중간 결과 | 디스크 경유 비중이 큼 | 메모리 중심 |
| 메모리 부족 시 | 디스크로 흘려 끝까지 감 | 질의 실패 또는 spill 설정에 의존 |
| 내결함성 | 태스크 단위 재시도 | 재시도 없음. 노드가 죽으면 질의 실패 |
| 적합한 작업 | 장시간 배치 ETL, 대용량 조인 | 대화형 조회, BI 도구 백엔드 |
| 동시성 | 큐 기반. 많은 작업을 쌓아 둠 | Admission Control 로 제한 |
| UDF | Java · Python 등 폭넓음 | C++ · Java UDF, 제약이 큼 |
| 트랜잭션 | ACID 관리 테이블 지원 | ACID 테이블 읽기 중심, 쓰기 제약 |
둘 다 Hive Metastore 를 본다. 그래서 Hive 로 만든 테이블이 Impala 에도 보이고 그 반대도 된다. 다만 Impala 는 메타데이터를 자체 캐시에 들고 있다. Hive 쪽에서 테이블을 만들거나 파티션을 추가하면 Impala 는 즉시 알지 못한다.
-- 새 테이블·새 파티션 등 메타데이터 변화 반영
INVALIDATE METADATA db.tbl;
-- 파일만 바뀐 경우 (더 가볍다)
REFRESH db.tbl;
CDP 계열에서는 메타스토어 알림을 구독해 자동으로 반영하는 옵션이 있지만, 외부에서 HDFS 에 파일을 직접 떨어뜨린 경우는 여전히 REFRESH 가 필요하다.
Impala 의 강점은 Parquet 같은 열 지향 형식에서 나온다. 텍스트나 행 지향 형식으로 두면 Impala 를 써도 빨라지지 않는다.
통계도 중요하다. Impala 는 통계가 없으면 조인 순서를 잘못 고른다.
COMPUTE STATS db.tbl;
Hive 는 Tez 의 동적 파티션 가지치기와 벡터화를 켜야 제 성능이 난다.
적재와 변환은 Hive 로 돌린다. 몇 시간짜리 작업이 중간에 노드 하나 빠졌다고 통째로 실패하면 곤란하기 때문이다.
조회는 Impala 로 보낸다. BI 도구나 사람이 붙는 자리에서는 초 단위 응답이 필요하고, 실패하면 다시 누르면 된다.
Kudu 테이블은 사실상 Impala 전용이다. Hive 에서 Kudu 테이블을 다루려면 스토리지 핸들러 설정이 별도로 필요하다.
Hive 장표에는 메타스토어와 HiveServer2, 실행 엔진(Tez), 관리·외부 테이블 구분, ACID 테이블을 담는다.
Impala 장표에는 Coordinator · Executor · Catalog Server · StateStore 라는 네 구성 요소와 메타데이터 캐시, Admission Control 을 담는다.
비교 장표에는 위의 표와 "배치는 Hive, 조회는 Impala" 라는 한 줄 결론을 둔다.
INVALIDATE METADATA 와 REFRESH 의 차이.