HIVE

Hive Metastore는 Hive의 메타데이터를 중앙 집중식으로 저장하고 관리하는 핵심 서비스 컴포넌트이다. 메타데이터는 데이터 자체가 아닌 데이터에 대한 구조적 정보를 의미하며, 여기에는 데이터베이스와 테이블의 스키마(열 이름, 데이터 타입), 테이블의 물리적 위치(예: HDFS 경로), 파티션 정보, SerDe(직렬화/역직렬화) 형식 등이 포함된다. 이 메타데이터는 관계형 데이터베이스에 저장되며, 주로 MySQL이나 PostgreSQL이 백엔드 저장소로 사용된다.

Hive Metastore는 클라이언트(예: Hive CLI, JDBC 드라이버)와 실행 엔진(MapReduce, Tez, Spark)이 데이터의 구조와 위치를 조회할 수 있는 단일 진실 공급원 역할을 한다. 쿼리가 실행되기 전에, Hive는 Metastore에 접속하여 해당 테이블이 존재하는지, 어떤 열을 가지고 있는지, 데이터가 HDFS의 어디에 저장되어 있는지 등의 정보를 먼저 확인한다. 이 덕분에 사용자는 복잡한 파일 경로를 직접 알 필요 없이 SQL과 유사한 HiveQL만으로 데이터를 조회할 수 있다.

Metastore의 아키텍처는 크게 세 가지 모드로 운영될 수 있다.

원격 모드는 가장 일반적인 프로덕션 아키텍처로, 메타데이터 접근에 대한 높은 가용성, 보안, 확장성을 제공한다. 또한 Spark SQL이나 AWS Glue와 같은 다른 데이터 처리 엔진들도 Hive Metastore와 호환되는 프로토콜을 통해 메타데이터를 읽고 쓸 수 있어, 하둡 에코시스템 내에서 통합된 데이터 카탈로그의 기반이 된다.

HiveQL은 Hive의 주요 쿼리 언어로, 사용자가 SQL과 유사한 구문을 사용하여 Hadoop에 저장된 대규모 데이터를 분석할 수 있게 해준다. 이 언어는 표준 SQL의 일부 기능을 포함하지만, Hadoop 환경의 특수성을 반영하여 확장되었다. HiveQL은 DDL을 사용하여 데이터베이스와 테이블을 생성 및 관리하고, DML을 사용하여 데이터를 로드, 내보내기, 쿼리한다. 특히, 사용자 정의 함수를 지원하여 복잡한 데이터 처리 로직을 구현할 수 있다.

HiveQL 쿼리의 실행은 다양한 백엔드 실행 엔진에 의해 처리된다. 초기 Hive는 MapReduce 프레임워크를 기본 실행 엔진으로 사용했다. 이 방식은 높은 확장성과 내결함성을 제공했지만, 중간 결과를 디스크에 쓰는 과정에서 발생하는 오버헤드로 인해 대화형 쿼리에는 지연 시간이 길다는 단점이 있었다.

성능 개선을 위해 Hive는 Apache Tez와 Apache Spark와 같은 더 빠른 실행 엔진을 지원하기 시작했다. Apache Tez는 작업을 일반적인 비순환 그래프로 표현하여 작업 간 데이터 전송을 최적화하고, 메모리 내 처리 비율을 높여 MapReduce 대비 성능을 크게 향상시켰다. Apache Spark 엔진을 통합하면, Spark의 인메모리 컴퓨팅 능력을 활용하여 반복적인 쿼리와 복잡한 분석 작업의 속도를 더욱 높일 수 있다.

사용자는 쿼리의 특성과 클러스터 환경에 따라 적절한 실행 엔진을 선택할 수 있다. 실행 엔진의 진화는 Hive가 배치 처리뿐만 아니라 대화형 쿼리와 실시간 분석에 가까운 성능을 제공하는 데 기여했다.

SerDe는 Serializer/Deserializer의 약자로, Hive가 HDFS에 저장된 다양한 형식의 데이터 파일을 읽고 쓸 때 사용하는 핵심 컴포넌트입니다. Hive 테이블의 데이터는 기본적으로 텍스트 파일 형태로 저장되지만, JSON, CSV, Avro, Parquet, ORC 등 복잡한 구조를 가진 파일도 처리해야 합니다. SerDe는 이러한 파일 형식과 Hive의 내부 데이터 표현 형식(행 객체) 사이의 변환을 담당합니다. Deserializer는 저장소로부터 데이터를 읽어 Hive가 이해할 수 있는 Java 객체로 변환하고, Serializer는 Hive의 내부 데이터를 저장소에 쓰기 적합한 바이트 스트림으로 변환합니다.

사용자는 CREATE TABLE 문의 ROW FORMAT 절에 SERDE 키워드를 사용하여 특정 SerDe를 지정할 수 있습니다. Hive는 여러 내장 SerDe를 제공하며, 사용자가 직접 UDF를 개발하듯이 맞춤형 SerDe를 구현하여 확장하는 것도 가능합니다. 몇 가지 주요 내장 SerDe는 다음과 같습니다.

SerDe의 선택은 데이터 처리 성능과 저장 효율성에 직접적인 영향을 미칩니다. 예를 들어, LazySimpleSerDe는 범용적이지만 모든 칼럼을 즉시 메모리에 로드합니다. 반면, ORC나 Parquet와 같은 칼럼 기반 파일 형식용 SerDe는 필요한 칼럼만 선택적으로 읽어 성능을 크게 향상시킵니다. 또한 OPENCSVSERDE는 CSV 파일의 따옴표 처리나 이스케이프 문자를 정확히 다루는 데 특화되어 있습니다. 따라서 데이터의 원본 형식과 분석 쿼리의 패턴에 맞는 적절한 SerDe를 선택하는 것은 Hive 쿼리 튜닝의 중요한 부분입니다.

HIVE는 관계형 데이터베이스와 유사한 논리적 구조로 데이터를 조직한다. 가장 기본적인 데이터 추상화 단위는 테이블이다. 테이블은 행과 열로 구성되며, 각 열은 이름과 데이터 타입을 가진다. 이 구조는 사용자가 익숙한 SQL 문법을 통해 데이터를 질의하고 관리할 수 있게 하는 기반이 된다. 테이블의 물리적 데이터는 HDFS나 Amazon S3와 같은 분산 저장소에 파일 형태로 저장된다.

데이터를 효율적으로 관리하고 쿼리 성능을 높이기 위한 핵심 메커니즘은 파티셔닝이다. 파티셔닝은 테이블의 데이터를 특정 열(예: date, country, department)의 값을 기준으로 디렉토리 계층 구조로 분할하여 저장하는 방식이다. 예를 들어, logs 테이블을 date와 hour 열로 파티셔닝하면, HDFS 상의 경로는 /user/hive/warehouse/logs/date=2023-10-26/hour=14/와 같은 형태가 된다. 이렇게 하면 쿼리가 특정 날짜나 시간 범위의 데이터만 스캔하도록 제한할 수 있어, 불필요한 I/O를 크게 줄일 수 있다.

파티셔닝 외에도 데이터를 더 세분화하는 버켓팅 기법이 존재한다. 버켓팅은 파티션 내에서 또는 파티셔닝 없이 테이블 자체에서, 지정된 열의 해시 함수 값을 기준으로 데이터를 고정된 수의 파일(버켓)으로 나눈다. 이는 데이터 샘플링, 조인 연산 성능 향상, 데이터 스큐를 완화하는 데 유용하다. 파티셔닝과 버켓팅은 함께 사용될 수 있으며, 이를 통해 데이터를 다차원으로 구조화할 수 있다.

파티션 관리는 주로 ALTER TABLE 문을 통해 이루어진다. 새로운 파티션을 추가하거나 삭제하는 작업은 메타데이터 연산으로 처리될 수 있어, 대규모 데이터 이동 없이도 테이블 구조를 유연하게 변경할 수 있다. 그러나 과도한 파티셔닝은 Hive Metastore에 부담을 줄 수 있으며, 많은 수의 작은 파일을 생성하여 네임노드의 메모리와 쿼리 실행 성능에 부정적 영향을 미칠 수 있다[1]. 따라서 파티션 키는 카디널리티가 적당한 열을 신중하게 선택해야 한다.

HIVE는 HDFS에 저장된 데이터를 효율적으로 처리하기 위해 여러 최적화된 파일 형식을 지원한다. 초기에는 텍스트 파일이 주로 사용되었지만, 대규모 데이터 처리에서 성능과 저장 효율성을 극대화하기 위해 ORC와 Parquet 같은 컬럼 기반 저장 형식이 표준으로 자리 잡았다.

ORC는 Hive를 위해 특별히 개발된 컬럼 기반 저장 형식이다. 데이터를 행이 아닌 열 단위로 저장하여, 쿼리가 특정 열만 스캔할 때 불필요한 I/O를 줄인다. 인덱싱과 압축을 적극 활용하며, 프레디케이트 푸시다운 같은 최적화를 지원한다. ORC 파일은 스트라이프, 행 그룹, 푸터로 구성되며, 각 스트라이프 내에 인덱스 데이터가 포함되어 특정 행을 빠르게 찾을 수 있다. Hive와의 통합이 매우 깊어, HiveQL의 대부분의 최적화 기능이 ORC 형식에서 가장 잘 동작한다.

Parquet 역시 컬럼 기반 저장 형식으로, 하둡 생태계 전반에서 널리 채택되었다. 중첩된 데이터 구조를 효율적으로 표현할 수 있는 Dremel 논문의 방식을 구현한다는 점이 특징이다. 이는 복잡한 JSON이나 Avro 스키마를 가진 데이터를 저장하는 데 유리하다. Parquet는 Apache Spark 및 Apache Presto 같은 다른 처리 엔진들과의 상호 운용성이 매우 뛰어나, Hive 외의 도구를 함께 사용하는 환경에서 선호된다. Hive는 Parquet 파일의 메타데이터를 읽고 스키마를 자동으로 추론할 수 있다.

이러한 파일 형식의 선택은 쿼리 패턴과 시스템 환경에 따라 결정된다. 주로 전체 행을 읽는 ETL 작업보다는 특정 컬럼을 집계하거나 필터링하는 분석 쿼리가 많다면 컬럼 기반 형식이 압도적인 성능 이점을 제공한다. 또한, 스냅샷 압축이나 고급 인코딩 기법을 통해 동일 데이터를 텍스트 형식에 비해 훨씬 적은 저장 공간에 담을 수 있어, 저장 비용과 네트워크 전송 시간도 절감된다.

Hive는 사용자가 익숙한 SQL 문법을 통해 Hadoop 클러스터에 저장된 대규모 데이터를 쿼리할 수 있도록 설계되었다. 이를 구현하는 핵심이 HiveQL이다. HiveQL은 ANSI SQL 표준을 기반으로 하여, SELECT, JOIN, GROUP BY, ORDER BY와 같은 대부분의 표준 DML 문을 지원한다. 이로 인해 기존 RDBMS나 데이터 웨어하우스에 익숙한 분석가나 개발자가 비교적 낮은 진입 장벽으로 빅데이터 분석을 시작할 수 있다.

그러나 HiveQL은 전통적인 SQL과 몇 가지 중요한 차이점을 가진다. 가장 큰 차이는 스키마 온 리드와 스키마 온 라이트 접근 방식이다. 일반적인 RDBMS는 데이터를 삽입할 때 스키마를 검증하는 스키마 온 라이트 방식을 사용하지만, Hive는 데이터를 HDFS에 저장할 때는 스키마를 강제하지 않고, 쿼리를 실행할 때 Hive Metastore에 정의된 스키마를 적용하는 스키마 온 리드 방식을 채택한다[2]. 또한, HiveQL은 데이터 웨어하우징 작업에 특화된 확장 구문을 제공하는데, 예를 들어 데이터를 효율적으로 관리하기 위한 PARTITIONED BY, CLUSTERED BY와 같은 DDL 문이 대표적이다.

HiveQL의 쿼리 실행은 내부적으로 MapReduce, Tez, 또는 Spark와 같은 분산 처리 프레임워크로 변환되어 수행된다. 이 변환 과정은 사용자로부터 추상화되어 있어, 복잡한 분산 처리 프로그래밍 지식 없이도 SQL 문장만으로 대용량 데이터 처리가 가능하다. 지원하는 데이터 타입도 기본적인 INT, STRING, TIMESTAMP부터 복합적인 ARRAY, MAP, STRUCT 타입까지 포함하여 반정형 데이터를 처리하는 데 유용하다.

HIVE는 사용자가 SQL과 유사한 HiveQL을 통해 대규모 데이터를 처리할 수 있게 하지만, 내장 함수만으로는 복잡한 비즈니스 로직을 구현하는 데 한계가 있을 수 있다. 이를 극복하기 위해 Hive는 UDF와 UDAF를 지원하여 시스템의 확장성과 유연성을 크게 향상시켰다.

UDF는 사용자 정의 함수로, 가장 기본적인 확장 기능이다. 사용자는 자바와 같은 프로그래밍 언어로 단일 행을 입력받아 단일 값을 반환하는 함수를 작성한 후, Hive에 등록하여 HiveQL 쿼리 내에서 내장 함수처럼 사용할 수 있다. 예를 들어, 문자열을 특정 형식으로 변환하거나 복잡한 수학 연산을 수행하는 로직을 UDF로 만들어 활용한다. UDAF는 사용자 정의 집계 함수로, 여러 행의 데이터를 그룹화하여 단일 집계 결과를 생성하는 함수이다. 표준 SQL의 SUM, AVG와 같은 집계 연산을 넘어서는 사용자 정의 집계 로직, 예를 들어 중앙값 계산이나 사용자별 행동 패턴 집계 등을 구현할 때 사용된다.

이러한 확장 메커니즘은 Hive의 적용 범위를 넓히는 핵심 요소이다. 데이터 처리 파이프라인에서 표준 SQL로 표현하기 어려운 도메인 특화 로직이나 복잡한 알고리즘을 통합해야 할 때, UDF/UDAF를 개발하여 Hive 쿼리 내에 자연스럽게 포함시킬 수 있다. 결과적으로, Hive는 단순한 쿼리 실행 도구를 넘어서, 사용자 맞춤형 데이터 처리 애플리케이션을 구축할 수 있는 플랫폼으로 진화하게 되었다. 이는 기존 맵리듀스 프로그래밍의 복잡성 없이도 하둡 상에서 강력하고 유연한 데이터 처리를 가능하게 하는 중요한 장점이다.

HIVE는 초기에는 맵리듀스를 유일한 실행 엔진으로 사용했지만, 성능과 대화형 쿼리 처리 요구에 따라 Tez와 Apache Spark와 같은 더 빠른 엔진을 지원하도록 진화했다.

초기 Hive는 모든 HiveQL 쿼리를 맵리듀스 작업으로 변환하여 실행했다. 이는 HDFS에 저장된 대규모 데이터를 일괄 처리하는 데 적합했지만, 각 단계의 결과를 디스크에 쓰는 오버헤드로 인해 대화형 쿼리에는 지연 시간이 길다는 단점이 있었다. 이를 극복하기 위해 등장한 Tez는 복잡한 작업(DAG)을 구성하여 중간 데이터를 메모리에 유지하고 불필요한 단계를 제거하는 방식으로 성능을 크게 향상시켰다. Hive on Tez는 특히 여러 단계를 거치는 조인 쿼리에서 뛰어난 성능을 보인다.

Apache Spark를 실행 엔진으로 사용하는 Hive on Spark는 인메모리 데이터 처리를 통해 더 빠른 성능을 제공한다. Spark SQL과의 긴밀한 통합으로 데이터프레임 API를 활용한 복잡한 분석이 가능해졌다. 사용자는 hive.execution.engine 설정을 통해 실행 엔진을 선택할 수 있으며, 클러스터 환경과 작업 특성(예: 일괄 ETL 대 대화형 분석)에 따라 적절한 엔진을 선택한다. 이러한 다중 엔진 지원은 Hive를 단순한 SQL 인터페이스를 넘어 다양한 처리 패러다임을 수용하는 유연한 데이터 처리 플랫폼으로 자리매김하게 했다.

Hive는 사용자가 작성한 HiveQL 쿼리를 효율적으로 실행하기 위해 다양한 최적화 기법을 제공합니다. 이러한 최적화는 쿼리 실행 계획을 분석하고 변환하여 불필요한 데이터 읽기와 계산을 줄이는 것을 목표로 합니다.

주요 최적화 기법으로는 조인 최적화, 필터 푸시다운, 파티션 프루닝 등이 있습니다. 조인 최적화에는 맵 사이드 조인과 리듀스 사이드 조인이 있으며, 특히 작은 테이블을 메모리에 캐시하여 처리하는 맵 조인은 성능 향상에 크게 기여합니다. 필터 푸시다운은 WHERE 절의 조건을 가능한 한 데이터 소스에 가까운 처리 단계로 "밀어내어" 초기 단계에서 불필요한 데이터를 걸러냅니다. 파티션 프루닝은 쿼리 조건에 맞지 않는 HDFS 디렉토리(파티션)를 아예 스캔 대상에서 제외시킵니다. 또한, 칼럼 기반 저장 형식인 ORC나 Parquet를 사용할 경우, 필요한 칼럼만 선택적으로 읽어오는 칼럼 프로젝션이 자동으로 수행됩니다.

Hive는 이러한 최적화를 위해 비용 기반 최적화 엔진을 도입하기도 했습니다. CBO는 테이블 통계 정보(행 수, 칼럼의 고유값 수 등)와 쿼리 조건을 바탕으로 여러 실행 계획의 예상 비용을 계산하고 가장 효율적인 계획을 선택합니다. 실행 엔진으로 Tez나 Spark를 사용할 경우, 이들 엔진이 제공하는 DAG 기반 실행 모델과 메모리 내 처리 덕분에 중간 결과물을 디스크에 쓰는 횟수를 줄이는 추가적인 최적화가 가능해집니다.

HDFS는 HIVE의 기본 저장소 역할을 한다. HIVE는 데이터를 HDFS에 파일 형태로 저장하며, 메타스토어는 이 데이터 파일들의 물리적 위치와 테이블 스키마 정보를 매핑하여 관리한다. 이 구조 덕분에 사용자는 SQL과 유사한 HiveQL로 데이터를 조회할 수 있지만, 실제 데이터 처리는 HDFS의 분산 저장 및 내결함성 특성을 그대로 활용한다. HIVE는 데이터를 HDFS에 로드하고, 파티션을 생성하며, 쿼리 결과를 다시 HDFS에 저장하는 모든 작업을 HDFS 클라이언트로서 수행한다.

실행 계층에서 HIVE는 YARN을 리소스 관리자로 사용한다. 사용자가 제출한 HiveQL 쿼리는 컴파일되어 일련의 맵리듀스 또는 Tez 작업으로 변환된 후, YARN 애플리케이션 마스터로 제출된다. YARN은 클러스터의 자원(CPU, 메모리)을 할당하고, 작업을 실행할 컨테이너를 노드 매니저를 통해 실행한다. 이를 통해 HIVE는 하둡 클러스터의 자원을 다른 애플리케이션(예: Spark)과 효율적으로 공유하며 운영된다.

HIVE와 하둡의 통합은 다음 표와 같이 요약할 수 있다.

이러한 연동 구조는 HIVE를 하둡 에코시스템의 핵심 데이터 웨어하우스 솔루션으로 자리잡게 했다. 데이터는 HDFS에 안정적으로 저장되고, 복잡한 분석 쿼리는 YARN의 관리 하에 대규모 병렬 처리로 실행된다.

HIVE는 Hadoop 생태계의 핵심 데이터 웨어하우스 도구로 자리 잡았지만, Spark와 Presto 같은 새로운 처리 엔진의 등장으로 그 역할과 협력 관계가 진화했다.

세 시스템은 대규모 데이터 처리라는 공통 목표를 가지지만, 설계 철학과 최적화된 워크로드가 다르다. Hive는 높은 SQL 호환성과 안정적인 배치 처리에 강점을 보이며, 메타데이터 관리의 중심인 Hive Metastore를 통해 생태계에 통합성을 제공한다. 반면, Spark는 인메모리 처리를 통한 반복적 알고리즘과 실시간에 가까운 배치 처리에, Presto는 대화형 쿼리와 낮은 지연 시간의 ad-hoc 분석에 특화되었다. 이들은 종종 혼합 아키텍처에서 협업하며, 예를 들어 Hive Metastore에 정의된 테이블을 Spark나 Presto가 직접 조회하여 처리하는 패턴이 일반적이다.

실행 엔진 측면에서 Hive는 초기 MapReduce에 의존했지만, 성능 개선을 위해 Tez나 Spark를 실행 엔진으로 선택할 수 있게 진화했다. 특히 Hive on Spark는 HiveQL의 편의성과 Spark 실행 엔진의 속도를 결합한다. Presto는 자체적인 분산 질의 엔진을 사용하며, HDFS나 Amazon S3에 저장된 데이터를 Hive Metastore의 메타데이터를 참조하여 직접 읽는다. 주요 차이점을 비교하면 다음과 같다.

따라서 현대의 데이터 플랫폼에서는 Hive를 장기적, 대규모 배치 작업과 메타데이터 허브로, Spark를 복잡한 데이터 변환과 머신러닝 파이프라인으로, Presto를 빠른 탐색적 데이터 분석과 리포트 생성에 사용하는 협업 구조가 흔히 발견된다.

HIVE는 대규모 로그 데이터를 저장, 처리, 분석하는 데 널리 사용되는 핵심 도구이다. 특히 웹 서버 로그, 애플리케이션 로그, 센서 로그와 같이 매일 테라바이트 또는 페타바이트 단위로 생성되는 반정형 또는 구조화된 데이터를 HDFS에 저장하고, 친숙한 SQL 문법(HiveQL)을 통해 분석 작업을 수행하는 데 적합하다. 사용자는 복잡한 맵리듀스 프로그램을 작성할 필요 없이, 로그 파일을 HIVE 테이블로 정의하고 집계, 필터링, 조인 쿼리를 실행하여 유의미한 인사이트를 도출할 수 있다.

일반적인 로그 분석 파이프라인은 먼저 플럼이나 카프카 같은 수집 도구로 로그를 HDFS에 적재하는 것으로 시작한다. 이후 HIVE는 이 로그 파일들을 외부 테이블로 매핑하여, 마치 관계형 데이터베이스를 조회하듯이 쿼리할 수 있게 한다. 로그 데이터는 시간에 따라 지속적으로 누적되는 특징이 있으므로, 파티셔닝과 버켓팅 기능을 활용하여 데이터를 연, 월, 일 또는 특정 키 값으로 물리적으로 구분한다. 이는 쿼리 성능을 극적으로 향상시키는 핵심 기법이다.

효율적인 저장과 빠른 쿼리를 위해 로그 데이터는 주로 ORC나 Parquet 같은 칼럼 기반 파일 형식으로 변환하여 사용한다. 또한 사용자 정의 함수(UDF)를 작성하여 로그 문자열 파싱, IP 주소 기반 지리 정보 조회, 사용자 에이전트 분석 등 복잡한 비즈니스 로직을 쿼리 내에 직접 적용할 수 있다. 이러한 특징들 덕분에 HIVE는 전통적인 데이터 웨어하우스 솔루션에 비해 훨씬 낮은 비용으로 확장 가능한 대규모 로그 분석 인프라의 중심에 서게 되었다.

HIVE는 하둡 기반의 대규모 데이터를 저장하고 분석하기 위한 데이터 웨어하우스 인프라로 널리 사용된다. 기존의 관계형 데이터베이스 관리 시스템(RDBMS)이 처리하기 어려운 페타바이트 규모의 정형 및 반정형 데이터를 HDFS에 저장하고, 익숙한 SQL 문법(HiveQL)을 통해 배치 처리 방식으로 분석 쿼리를 실행하는 데 적합하다. 이는 기업이 ETL(추출, 변환, 적재) 파이프라인의 결과물이나 오랜 기간 축적된 역사적 데이터를 중앙 집중식으로 관리하고, 의사 결정 지원을 위한 복잡한 리포트 생성 및 분석 작업을 수행하는 전형적인 데이터 웨어하우징 시나리오에 부합한다.

Hive의 데이터 웨어하우징 적용은 몇 가지 핵심 기능에 기반한다. 첫째, 메타스토어(Metastore)를 통해 테이블 스키마, 데이터 위치, 파티션 정보 등을 중앙에서 관리하여 데이터에 대한 통합된 카탈로그 뷰를 제공한다. 둘째, 파티셔닝과 버켓팅을 지원하여 대용량 테이블의 쿼리 성능을 극대화한다. 마지막으로, ORC나 Parquet 같은 칼럼 기반 저장 형식을 사용하면 압축률과 읽기 효율이 높아져 저장 비용을 절감하고 분석 속도를 개선할 수 있다.

이러한 특성으로 인해 Hive는 특히 변경이 빈번하지 않고 주로 읽기 위주의 분석 작업이 수행되는 데이터 마트나 엔터프라이즈 데이터 웨어하우스의 핵심 구성 요소로 자리 잡았다. 다만, 낮은 지연 시간의 대화형 쿼리가 필요한 경우에는 Presto나 Apache Impala 같은 다른 도구와의 연동이 보완책으로 고려된다.