impala, 임팔라 엔진의 데이터 검색

# RDBMS와 임팔라의 아키텍처 및 패러다임 차이

[RDBMS가 잘 하는 것  — 지금 이 순간, 동시에, 정확하게]

RDBMS는 주로 온라인 트랜잭션 처리(OLTP)에 최적화되어 있습니다. 

은행의 계좌 이체나 전자상거래의 주문 처리처럼, 수많은 사용자가 동시다발적으로 소수의 레코드를 삽입, 갱신, 삭제하는 환경에서

데이터의 무결성과 엄격한 ACID(원자성, 일관성, 고립성, 지속성) 정합성을 보장하는 데 목적이 있습니다. 

이를 위해 RDBMS는 구조적으로 연산 장치와 저장 장치가 강하게 결합된 단일 서버 환경을 지향하며, 

성능 향상을 위해 고가의 하드웨어를 도입하는 수직적 확장(Scale-up)에 의존합니다. 

데이터는 레코드 전체를 하나의 연속된 디스크 블록에 기록하는 행 기반(Row-oriented) 스토리지를 사용합니다.

 

[임팔라가 잘 하는 것 — 쌓인 과거 데이터를 대규모로 분석]

반면, 임팔라는 온라인 분석 처리(OLAP)를 목적으로 설계된 분산 SQL 엔진입니다. 

트랜잭션의 갱신이 아닌, 페타바이트급으로 누적된 과거의 방대한 이력 데이터를 대상으로 복잡한 다차원 집계와 분석을 수행하는 데 특화되어 있습니다. 

아키텍처 측면에서 데이터의 물리적 저장소(HDFS, S3)와 연산 엔진(임팔라 데몬)이 완벽히 분리되어 있으며, 

저렴한 범용 하드웨어를 수천 대 규모로 병렬 연결하는 수평적 확장(Scale-out)을 통해 성능을 확보합니다.

 

 

# 왜 임팔라는 인덱스(INDEX) 개념을 사용하지 않는가? 

[인덱스가 잘 맞는 상황]

RDBMS에서 널리 사용되는 B-트리(B-Tree) 구조의 인덱스는 수백만 건의 데이터 중 특정 조건을 만족하는 

단 하나의 레코드를 빠르게 찾아내는 포인트 쿼리(Point Query)에 고도로 최적화되어 있습니다. 

그러나 임팔라가 구동되는 데이터 웨어하우스 환경에서는 특정 고객 한 명의 정보를 찾는 것보다, 

지난 1년간의 전체 판매 데이터를 지역별로 스캔하여 그룹화하고 합산을 내는 등 대규모 데이터 집단에 대한 광범위한 스캔 연산이 주를 이룹니다.

 

[임팔라가 다루는 상황]

대규모 데이터 스캔 시 인덱스를 경유하게 되면, 디스크의 물리적 헤드가 데이터의 파편화된 위치를 찾아 사방으로 이동해야 하는 

무작위 입출력(Random I/O)이 기하급수적으로 발생하여 전체 시스템 성능이 심각하게 저하됩니다. 

대용량 데이터 처리에 있어서는 디스크를 처음부터 끝까지 연속적으로 읽어 들이는 순차 입출력(Sequential I/O)이 하드웨어 대역폭을 극대화하는 가장 빠른 방법입니다.

 

[분산 환경에서 인덱스 유지 자체가 너무 비싸다.]

더욱이 수천 대의 노드에 페타바이트 단위의 데이터가 지속적으로 유입되는 분산 환경에서, 전역 인덱스 트리를 유지하고 동기화하는 작업은 

쓰기가 발생할 때마다 엄청난 지연(Write Penalty)과 메타데이터 병목을 유발합니다. 유지보수 비용이 이득보다 훨씬 큽니다.

따라서 임팔라는 인덱스의 유지보수 비용과 무작위 입출력의 비효율성을 제거하는 트레이드오프를 취했습니다.

---

# 그럼 어떻게 효율적으로 데이터를 찾나? 

1. 데이터 스토리지 및 접근 최적화

파티셔닝 (Partitioning) 및 파티션 프루닝 (Partition Pruning):

1:

파티셔닝은 데이터를 특정 컬럼(예: 연도, 월, 일, 지역 등)의 값을 기준으로 여러 개의 독립적인 물리적 디렉토리로 나누어 저장하는 메커니즘입니다.

예를 들어, 매출 테이블을 날짜 단위(base_date)로 파티셔닝하면, 

HDFS 상에는 '/user/hive/warehouse/sales/base_date=2022-01-01'과 같은 형태의 계층적 디렉토리가 생성됩니다. 

주목할 점은 파티션 기준이 되는 컬럼(Partition Key) 자체는 파케이 파일 내부에 없습니다. 

그 값은 디렉토리 이름(base_date=2022-01-01)으로 이미 표현되어 있기 때문에, Impala/Hive가 쿼리 시 디렉토리명에서 파티션 값을 읽어와 자동으로 붙여줍니다.

 

 

2:

파티션 프루닝은 '프루닝(가지치기)'이라는 단어 뜻 그대로, 쿼리 실행 트리를 구성할 때 불필요한 가지를 쳐내는 과정입니다. 

질의(Query) 분석 단계에서 조건절(WHERE)을 평가하여 질의와 무관한 파티션 디렉토리를 스캔 대상에서 원천적으로 배제하는 기술입니다.

옵티마이저는 쿼리의 조건절(WHERE 절)에 명시된 파티션 키 조건(예:base_date=2022-01-01)을 평가하여,

이 조건과 일치하지 않는 파티션 디렉토리 경로는 스캔계획에서 제외하고,

조건에 해당하는 파티션 디렉토리에 대해서만 데이터 블록의 물리적 위치(DataNode)를 파악하고, 각 익스큐터 노드에 읽기(Scan) 작업을 할당합니다.

 

그러나, 주요 문제점들: 

 

🔴  오버 파티셔닝과 스몰 파일 문제입니다.

데이터를 잘게 쪼갤수록 프루닝 효율이 좋아질 것이라 착각하기 쉽지만, 이는 분산 아키텍처에서 치명적인 안티 패턴입니다.

하둡 생태계에서 파일의 위치 정보와 디렉토리 구조는 네임노드(HDFS NameNode)의 힙 메모리에서 관리되므로, 

파일 수가 늘어나면 네임노드의 메모리가 고갈되어 전체 클러스터가 마비될 수 있습니다.

또한, 임팔라 카탈로그 서버가 이 거대한 메타데이터를 로드하고 각 임팔라 데몬에 동기화하는 데 엄청난 지연이 발생합니다.

⇒ 파티션당 최소 크기가 보장되도록 파티션을 조절해야 한다.(이상적인 파케이 파일 크기는 128MB ~ 1GB 수준)

 

🔴 OOM으로 인한 쿼리 실패

증상: 갑자기 쿼리 실패, "Memory limit exceeded" 에러

원인: 대용량 JOIN, 동적 파티션 삽입, 집계 쿼리

결과: 배치 파이프라인 전체 중단

⇒ MEM_LIMIT 설정 필수, 동적 파티션은 날짜별로 쪼개서 실행, 무거운 변환 작업은 Spark에게 넘기고 임팔라는 조회 전용으로 역할 분리

 

🔴  데이터 스큐(Data Skew) 현상과 분산 아키텍처의 한계입니다.

증상: 쿼리가 99% 완료된 상태에서 한참 걸림

원인: 서울 데이터가 전체의 70%, 특정 카테고리 집중

결과: 전체 쿼리 완료 시간 = 가장 느린 Executor 기준

 

파티션 키를 잘못 선정하면 특정 파티션에 데이터가 비정상적으로 몰리는 데이터 스큐(Data Skew)가 발생합니다.

임팔라와 같은 대용량 병렬 처리(MPP) 시스템의 핵심은 다수의 노드가 작업을 균등하게 나누어 동시에 처리하는 것입니다. 

특정 날짜나 특정 지역에 전체 데이터의 80%가 집중되어 있다면, 해당 파티션을 스캔하고 연산하는 소수의 익스큐터 노드에만 부하가 집중됩니다.

⇒ 파티션 설계 시 데이터 분포 반드시 사전 분석, 스큐가 심한 컬럼은 파티션 키에서 제외 등 물리적 데이터 분포의 균형을 맞추는 것이 중요하다.

 

컬럼형 스토리지 (Columnar Storage):

Apache Parquet와 같은 포맷을 활용하여 데이터를 로우(Row)가 아닌 컬럼(Column) 단위로 연속된 디스크 공간에 저장합니다. 

이는 특정 컬럼만 선별적으로 읽는 분석형 워크로드(OLAP)에서 I/O 대역폭 낭비를 획기적으로 줄여주며,

 동일한 데이터 타입이 연속되므로 압축 효율(Snappy, GZIP 등)과 CPU 캐시 활용도를 극대화합니다.

 

예시: 100개의 컬럼을 가진 1TB 테이블에서 단 3개의 컬럼만 SELECT하는 경우, 전체 테이블을 읽는 대신 30GB 수준의 데이터만 디스크에서 읽어옵니다.

존 맵 (Zone Maps / Min-Max Statistics):

Parquet 파일의 푸터(Footer)에는 각 로우 그룹(Row Group) 단위로 해당 컬럼 데이터의 최솟값(Min)과 최댓값(Max) 정보가 메타데이터로 기록되어 있습니다.

데이터 파일 자체를 열어보지 않고도 파일 메타데이터만으로 스킵(Skip) 여부를 결정합니다.

 

 

2. 비용 기반 옵티마이저 (Cost-Based Optimizer, CBO)와 통계 정보

비용 기반 옵티마이저 (CBO):

RBO (Rule-Based Optimizer) - 규칙 기반 : 항상 작은 테이블을 오른쪽, 인덱스가 있으면 무조건 써라

CBO (Cost-Based Optimizer) - 비용 기반: 실제 통계 정보를 보고 비용을 계산해서 선택

⇒ 임팔라는 CBO를 사용하며, 판단근거가 바로 통계 정보이다.

 

통계 정보 (Statistics):

테이블과 컬럼에 대한 데이터 분포 요약 정보입니다. Hive Metastore에 저장됩니다.

테이블 통계(전체 로우 수, 물리적 크기)와 컬럼 통계(고유값 수(NDV, Number of Distinct Values), Null 개수, 평균/최대 길이 등)로 구성됩니다.

COMPUTE STATS 명령어를 통해 수집되며, 옵티마이저가 연산의 비용을 계산하는 기초 데이터가 됩니다.

 

3. 조인 최적화 (Join Optimization)

조인 전략 (Broadcast vs. Partitioned Join):

결국 JOIN 성능의 핵심은 "얼마나 적은 데이터를 네트워크로 이동시키느냐" 입니다.

 

 

① 브로드캐스트 JOIN (Broadcast Join)

한 테이블이 메모리에 적재될 만큼 작을 때, 

작은 테이블을 클러스터 내의 모든 노드로 복제(Broadcast)하여  노드 간의 데이터 이동 없이 조인을 수행합니다.

 

- 적합한 상황 : 작은 테이블 JOIN 

- 핵심 비용: 작은 테이블 전송

- 위험: 큰 테이블 브로드캐스트 시 OOM

 

②  파티션 / 셔플 조인 (Partitioned / Shuffle Join)

두 테이블 모두 클 때, 조인 키를 기준으로 해시 함수를 적용하여 양쪽 테이블의 데이터를 동일한 노드로 재분배(Shuffle)한 후 조인합니다.

 

- 적합한 상황 : 대용량 테이블 간 JOIN

- 핵심 비용: 두 테이블의 데이터를 네트워크를 통해 여러 노드로 재분배(Shuffle)

- 위험: 데이터 스큐 시 병목

 

4. 런타임 최적화: 런타임 필터 (Runtime Filters) 

Impala 2.5 or higher only

 

임팔라의 런타임 필터는 대용량 분산 처리 환경에서 조인(Join) 성능을 극대화하기 위해 쿼리 실행 중에 동적으로 만들어지는 필터링 기술입니다.

일반적으로 분산 환경에서 두 테이블을 조인할 때는 막대한 양의 데이터가 네트워크를 통해 노드 간에 이동(Shuffle)하게 됩니다. 

런타임 필터는 이 "네트워크를 타는 데이터의 양 자체를 원천적으로 줄여보자"는 아이디어에서 출발합니다.

 

[핵심 구조]

- 동적 필터링 (Dynamic Filtering): 쿼리를 실행하기 전이 아니라, 실제 데이터를 읽고 있는 도중(런타임)에 실시간으로 필요한 데이터만 골라낼 기준을 만드는 기술입니다.

 

- 블룸 필터 (Bloom Filter) 및 최소-최대 필터 (Min-Max Filter): 아주 적은 메모리만 써서 "내가 찾는 데이터가 대충 여기쯤 있나?(블룸)",
"값의 범위가 어디서부터 어디까지인가?(최소-최대)"를 초고속으로 확인하는 가벼운 거름망입니다.

 

- 필터 푸시다운 (Filter Push-down): 이 거름망을 데이터를 읽어오는 제일 밑바닥(스토리지 스캐너)으로 미리 내려보내서,
처음부터 쓸데없는 데이터가 네트워크를 타고 위로 올라오지 못하게 원천 차단하는 방식입니다.

 

수십억 건의 로그가 쌓여 있는 대용량 팩트 테이블(user_logs)과 수백 건의 메타 정보가 있는 작은 디멘전 테이블(campaign_info)을 조인한다고 가정해 보겠습니다.

 조건은 "2026년 신규 캠페인(ID: 100~150)에서 발생한 로그만 추출"하는 것입니다.

 

1. Build Phase (필터 동적 생성)

임팔라는 먼저 작은 테이블을 읽어 메모리에 해시 테이블을 만듭니다 (Build Side).

동시에, 조건에 해당하는 캠페인 ID(100~150)들을 바탕으로 런타임 필터를 동적으로 생성합니다.

 

- Bloom Filter: "이 ID 집합에 해당 값이 존재하는가?"를 아주 빠르고 가볍게 판별하는 확률형 자료구조.

- Min-Max Filter: "ID가 100 이상 150 이하인가?"를 판별하는 범위 필터.

 

    Bloom Filter 관련 영상 참고 : https://youtu.be/rIl5G2aVfMQ?si=qeu6FyhlnuIp6I7U

 

2. Filter Routing (필터 배포)

각 노드에서 생성된 필터 조각들은 코디네이터 노드로 모여 병합(Aggregation)된 후, 

실제 대용량 팩트 테이블(user_logs)을 읽을 준비를 하는 워커 노드들의 스캐너(Scanner)로 뿌려집니다.

 

3. Probe Phase (필터 적용 및 스캔)

스캐너 노드들이 스토리지(HDFS 등)에서 user_logs 테이블을 읽기 시작합니다 (Probe Side).

이때 네트워크로 데이터를 쏘아 보내기 전, 혹은 메모리에 올리기 직전에 앞서 받은 필터를 적용합니다.

로그 데이터의 캠페인 ID가 필터 조건(100~150)에 맞지 않으면, 그 행(Row)은 조인 연산까지 가지 않고 스캔 단계에서 즉시 버려집니다(Dropped).

 

결과적으로, 수십억 건의 데이터를 전부 네트워크로 전송하여 해시 매칭을 하는 대신, 

필터를 통과한 수백만 건의 데이터만 네트워크를 타게 되므로 CPU, 메모리, I/O 비용이 비약적으로 절감됩니다.

 

 

 

참고;  https://impala.apache.org/docs/build/html/topics/impala_runtime_filtering.html

 

 

---

# 쿼리 계획 확인하기

EXPLAIN 문장은 쿼리가 수행할 논리적 단계의 개요를 제공합니다. 
예를 들어, 작업이 노드 간에 어떻게 분산되고 중간 결과가 최종 결과 집합을 생성하기 위해 어떻게 결합될지에 대한 정보를 포함합니다.
쿼리를 실제로 실행하기 전에 이러한 세부 정보를 확인할 수 있습니다.

 

* EXPLAIN 계획을 아래에서 위로 읽으세요

 

계획의 마지막 부분은 읽을 예상 데이터 양과 같은 저수준 세부 정보를 보여주며, 

이를 통해 파티셔닝 전략의 효과를 판단하고 전체 데이터 크기와 클러스터 크기에 따라 테이블 스캔이 얼마 걸릴지 예측할 수 있습니다.

성능 지향적인 세부 정보가 더 많이 포함된 verbose EXPLAIN 계획을 활성화하세요.

 

 

참고:

https://impala.apache.org/docs/build/asf-site-html/topics/impala_perf_joins.html