Impala, 임팔라의 기본 개념 및 메커니즘

# 기술의 탄생 배경과 목적

 MPP(Massively Parallel Processing) 구조와 In-Memory 처리 방식

 

아파치 임팔라(Apache Impala)가 고안된 역사적 배경은 하둡 생태계 초기 데이터 처리의 근간이었던 맵리듀스 프레임워크의 태생적인 한계에서 출발합니다.
맵리듀스는 일괄 처리(Batch Processing)와 결함 허용성에 최적화된 구조를 가졌으나, 
각 연산 단계마다 중간 연산 결과물을 물리적 디스크에 기록하고 다음 단계에서 이를 다시 읽어오는 과정이 필수적이었습니다.
이러한 디스크 입출력 병목 현상은 쿼리의 응답 시간을 분 단위 혹은 시간 단위로 지연시켰으며, 
데이터 분석가들이 실시간에 가까운 속도로 데이터를 탐색하는 대화형 질의를 수행하는 데 치명적인 장애물로 작용했습니다.

임팔라의 핵심 설계 철학은 맵리듀스 엔진을 완전히 배제하고, 분산된 노드의 메모리 상에서 직접 연산을 처리하는 것입니다. 
분산 파일 시스템(HDFS)에 저장된 데이터에 데몬 프로세스가 직접 접근하여 연산을 수행함으로써 중간 데이터의 디스크 기록을 생략했습니다.
결론적으로 임팔라는 하둡의 막대한 스토리지 확장성을 그대로 유지하는 동시에, 
기업 단위에서 요구하는 저지연(Low-latency) 데이터 분석의 한계를 극복하기 위한 학술적, 실무적 요구에 의해 탄생한 하둡 네이티브 분산 SQL 엔진으로 정의할 수 있습니다.

 

# 핵심 구조 및 동작 원리 

Impala Components

임팔라 클러스터는 논리적으로 세 가지 핵심 컴포넌트인 

임팔라 데몬(Impalad), 상태 저장소 데몬(Statestored), 그리고 카탈로그 데몬(Catalogd)으로 구성되며, 

이들이 유기적으로 상호작용하여 HDFS 상의 데이터에 대한 초저지연 연산을 수행합니다.

 

임팔라 데몬(Impalad)은 별도의 독립된 서버(자체적인 데이터 노드)에 생성되는 것이 아니라, 

HDFS의 데이터노드(DataNode) 데몬이 구동되고 있는 바로 그 동일한 물리적 서버(Worker Machine) 위에 코로케이션(Co-location) 형태로 설치되고 실행됩니다. 

즉, 하나의 물리적 서버 안에서 HDFS 데이터노드 프로세스와 임팔라 데몬 프로세스가 동시에 백그라운드에서 동작하는 대칭적 토폴로지를 구성합니다.

 

이러한 코로케이션 아키텍처를 채택한 근본적인 이유는 앞선 단계에서 지속적으로 강조한 데이터 지역성(Data Locality)을 극대화하기 위함입니다. 

만약 임팔라 데몬이 HDFS 데이터노드와 분리된 별도의 서버에 존재한다면, 

질의를 수행할 때마다 페타바이트급의 데이터가 네트워크 스위치를 타고 연산 서버로 이동해야 하며 이는 치명적인 네트워크 병목을 유발합니다.

 

임팔라 데몬을 HDFS 데이터노드와 동일한 서버에 배치하면 숏서킷 로컬 읽기(Short-circuit Local Read)라는 고도화된 메커니즘을 사용할 수 있습니다. 

코디네이터 노드가 질의를 분산시킬 때, 특정 데이터 블록을 자신의 로컬 디스크에 보유하고 있는 임팔라 데몬에게 해당 연산을 할당합니다. 

지시를 받은 임팔라 데몬은 네트워크 소켓을 통하지 않고 운영체제의 파일 시스템 커널을 통해 자신이 위치한 서버의 하드 디스크에서 직접 데이터를 메모리로 긁어옵니다. 

이는 데이터의 물리적 이동 거리를 제로(0)에 가깝게 수렴시켜 네트워크 I/O 비용을 완전히 제거하는 분산 시스템 설계입니다.

 

📌 catalogd: 

Hive Metastore, HDFS NameNode와 통신하여 데이터베이스 스키마와 물리적 파일 위치 정보를 캐싱하고,
(쿼리 대상이 되는 파케이(Parquet) 파일 등의 물리적 데이터 블록이 어느 데이터노드에 위치해 있는지)
DDL(데이터 정의어) 변경 사항이 발생할 경우 상태 저장소를 통해 클러스터 전체의 메타데이터를 일관되게 동기화합니다.
또한, statestored 를 통해 impala SQL 문에서 메타데이터 변경사항을 클러스터의 모든 코디에 전달합니다. 

 

📌  statestored: 

클러스터 내 모든 임팔라 데몬의 생존 여부(Health Status)를 주기적으로 확인하고  그 결과를 브로드캐스팅하는  통신 중추 역할을 수행합니다. 
catalogd로부터 받은 최신 정보를 클러스터 내의 모든 impalad 노드에 브로캐스트(Broadcast)하여 metadate를 업데이트 합니다.

 

📌  impalad: 

핵심적인 연산 주체는 클러스터의 각 데이터노드(DataNode)에 상주하는 임팔라 데몬(Impalad)입니다. 
임팔라는 구조적으로 완벽한 대칭형 아키텍처를 가지므로, 클라이언트가 클러스터 내 어떤 임팔라 데몬으로 질의를 전송하더라도 

해당 데몬이 그 질의에 대한 코디네이터 노드로 승격됩니다. (처음 질의를 받은 데몬)
코디네이터는 수신된 SQL 문을 구문 분석(Parsing)하고 질의 계획기(Query Planner)를 통해 분산 실행에 최적화된 실행 계획 트리(Execution Plan Tree)를 생성합니다.
연산에 필요한 데이터 블록을 로컬 디스크에 보유하고 있는 다른 임팔라 데몬들을 워커 노드로 지정하여 질의 파편(Query Fragment)을 분산 할당합니다.

각 워커 노드는 자신에게 할당된 HDFS의 로컬 데이터를 메모리로 직접 스캔하고, 필터링, 집계, 혹은 해시 조인(Hash Join) 등의 연산을 수행합니다. 
이때 중간 데이터는 디스크에 기록되지 않고 네트워크를 통해 파이프라인 형태로 다음 단계의 노드나 코디네이터에게 즉각적으로 스트리밍됩니다.

최종적으로 코디네이터 노드는 모든 워커 노드로부터 수집된 부분 연산 결과를 취합하여 클라이언트에게 반환하는 프로세스 라이프사이클을 완성합니다.

 

♣︎ 코디네이터와 워커 

임팔라 클러스터의 각 노드에서 실행되는 impalad 프로세스는 쿼리가 실행될 때 그 역할에 따라 코디네이터와 워커로 나뉩니다.

중요한 점은 어떤 impalad 인스턴스든 코디네이터가 될 수 있으며, 동시에 다른 쿼리에 대해서는 워커로 일할 수도 있다는 것입니다.

• 코디네이터 (Coordinator): 사용자가 SQL 쿼리를 보낼 때 최초로 질의를 수신한 해당 데몬은 코디네이터 노드(Coordinator Node)로 논리적 역할이 승격됩니다.
 쿼리를 분석하여 실행 계획을 세우고, 클러스터의 다른 노드들에 작업을 배분하며, 최종적으로 각 노드에서 처리된 결과를 모아 사용자에게 전달하는 '지휘자' 역할을 수행합니다.

• 워커 (Worker): 코디네이터로부터 쿼리의 일부분(쿼리 조각)을 할당받은 여러 노드들입니다. 
이들은 병렬로 작업을 수행하며, 자신이 맡은 부분의 데이터를 로컬 저장소(HDFS, HBase 등)에서 직접 읽어와 처리한 뒤 그 결과만 코디네이터에게 돌려줍니다.

 

 

분산 질의 실행 파이프라인의 단계별 메커니즘

 

 

단계 1. 질의 수신 및 코디네이터 승격

클라이언트(ODBC, JDBC, CLI)가 클러스터 내 임의의 임팔라 데몬(Impalad)에 SQL 질의를 전송하면,

해당 데몬은 즉각 해당 세션의 코디네이터 노드(Coordinator Node) 로 역할이 승격됩니다. 

이는 임팔라의 대칭적 아키텍처를 증명하는 첫 단계로, 단일 장애점(SPOF)을 방지하고 질의 유입 부하를 클러스터 전체로 분산시킵니다.

 

단계 2. 구문 분석 및 실행 계획 파편화

코디네이터 내부의 쿼리 플래너(Query Planner) 가 SQL을 추상 구문 트리(AST)로 변환하고,

카탈로그 데몬(Catalogd)으로부터 동기화한 스키마·통계 정보를 바탕으로 유효성을 검증합니다. 

이후 단일 노드 실행 계획을 수립한 뒤, 병렬 실행이 가능한 독립 단위인 쿼리 파편(Query Fragments) 으로 분할합니다. 

이 과정에서 비용 기반 최적화(CBO) 알고리즘이 개입하여 브로드캐스트 조인 또는 파티션드 해시 조인 등 네트워크 셔플링을 최소화하는 조인 전략을 확정합니다.

 

단계 3. 쿼리 파편의 분산 스케줄링

생성된 쿼리 파편들은 쿼리 코디네이터 모듈이 HDFS 네임노드로부터 획득한 블록 위치 메타데이터를 참조하여,

연산 대상 데이터를 로컬 디스크에 보유한 임팔라 데몬들로 스케줄링합니다.

데이터 지역성(Data Locality) 을 극대화하여 연산을 데이터가 있는 곳으로 이동시키는 물리적 제어 과정입니다.

 

단계 4. 로컬 데이터 스캔 및 부분 연산

파편을 할당받은 각 워커 노드의 쿼리 실행기는 코로케이션된 HDFS 데이터노드로부터 숏서킷 로컬 읽기(Short-circuit Local Read) 를 통해

네트워크 스택을 우회하여 데이터를 메모리로 직접 로드합니다.

적재된 데이터는 LLVM JIT 컴파일레이션과 벡터화 연산 파이프라인을 거쳐 조건 필터링 및 로컬 집계(Local Aggregation)가 수행됩니다.

 

단계 5. 중간 결과의 파이프라인 스트리밍

워커 노드의 중간 연산 결과물은 MapReduce와 달리 디스크에 기록되지 않습니다.

메모리 상에서 네트워크 소켓을 통해 코디네이터 노드, 혹은 다단계 조인이 필요한 경우

다음 연산을 담당할 워커 노드의 교환(Exchange) 노드로 직접 스트리밍됩니다. 

이 파이프라인 스트리밍 기법이 디스크 I/O를 원천 제거하는 임팔라 초저지연 성능의 근간입니다.

 

단계 6. 최종 집계 및 결과 반환

코디네이터 노드의 쿼리 실행기가 모든 워커 노드로부터 비동기적으로 유입되는 스트림을 수합하여

최종 병합(Merge) 및 전역 집계(Global Aggregation)를 수행합니다. 

완성된 결과 집합(Result Set)을 클라이언트에 반환하면서 단일 분산 질의의 전체 라이프사이클이 종료됩니다.

 

 

# 질문: 하둡의 맵리듀스 동작과 임팔라의 코디네이터/워커 동작이 비슷한데 왜 맵리듀스를 사용하지 않는걸끼? 

 

많은 곳을 찾아봐도 맵리듀스 동작에 대해서 '쪼개서 연산하고 합쳐서 집계한다'는 내용에 집중한다.
그런데 임팔라의 코디네이터, 워커 노드도 비슷한 동작을 수행한다.
그럼 임팔라의 동작과 차이가 있는건 뭘까 ? 답은 임팔라의 인-메모리 처리 방식에 나와있다.

중요한 것은 맵 노드는 중간결과를 로컬 하드디스크에 저장하고, 리듀스 노드가 디스크에 접근하여 데이터를 읽는다는 것이다.
반면에, 임팔라는 워커노드가 코디네이터 노드의 메모리로 직접 스트리밍한다!

 

맵리듀스 동작

1. fork

인풋 파일은 미리 쪼개져서 분산 파일 시스템에 저장되어 있다고 가정하겠다. 

사용자가 map과 reduce 함수를 정의한 프로그램을 실행시켜서 프로세스를 실행하면 

이는 마스터 노드, map을 실행할 워커 노드(이하 Mapper 노드), reduce를 실행할 워커 노드(이하 Reducer 노드)들에 복사된다.

 

2. assign map and reduce

마스터 노드는 Mapper워커들에게 mapping 역할을, reducer 노드들에게는 reduce 역할을 수행하라고 지정해준다. 

이 때, mapper 노드의 개수나 reducer 노드의 개수는 사용자가 설정할 수 있다.

 

3,4. read, map, local write

Mapper 노드들은 쪼개어진 데이터 청크를 분산 파일 시스템으로부터 읽어온다. 

그 다음 이 데이터에 Map 함수를 실행하여 Key:Value 형태의 Intermediate 데이터를 생성하고 이를 자기 자신의 로컬 디스크에 저장한다. 

그 다음 Mapper 노드는 마스터 노드에게 Mapping 작업을 모두 완료하였다고 알려준다.

 

5,6 reduce, write

그러면 마스터 노드는 리듀서 노드들에게 reduce를 시작하라고 명령을 내려준다. 

reducer 노드들은 mapper 노드들의 디스크 공간에 저장되어 있는 Intermediate 데이터를 읽어온다. 

그리고 reduce 함수를 실행하여 최종 결과물을 산출한 다음 파일 형태로 데이터를 출력한다

 

 

 

 

# 그럼, 어떤 문제가 발생할 수 있을까? 

다수의 사용자가 동시에 자원 집약적인 질의를 요청하여 클러스터의 총 메모리를 초과하게 되면, 운영체제 수준의 메모리 부족(OOM, Out Of Memory) 현상

이러한 물리적 붕괴를 방어하기 위해 임팔라 아키텍처는 두 가지 다층적 자원 관리 메커니즘을 가동합니다.

- 사전적 예방 기제인 승인 제어(Admission Control)

- 사후적 방어 기제인 메모리 스필링(Memory Spilling)

 

 승인 제어(Admission Control) 

승인 제어는 클러스터의 전체 컴퓨팅 자원을 논리적인 다수의 리소스 풀(Resource Pool)로 분할하고, 

각 사용자 그룹이나 워크로드 특성에 따라 동시 실행 가능한 질의의 수와 최대 할당 가능 메모리 임계치를 엄격하게 규정하는 중앙 통제 시스템입니다.

질의가 인입되면 코디네이터 노드는 즉시 실행에 돌입하지 않고, 비용 기반 옵티마이저(CBO)가 통계 정보를 바탕으로 추정한 해당 질의의 최대 요구 메모리량을 승인 제어기에게 제출합니다. 승인 제어기는 클러스터의 현재 잔여 메모리 상태와 해당 리소스 풀의 할당량을 실시간으로 검토합니다. 

만약 새로운 질의를 당장 실행할 경우 클러스터의 물리적 자원 임계점을 초과할 것이라 수학적으로 판단되면, 

승인 제어기는 해당 질의의 실행을 즉각 보류하고 대기열(Queue)에 적재합니다. 

선행 질의들이 종료되어 가용 메모리가 충분히 확보된 시점에 대기열의 질의를 순차적으로 승인함으로써, 

다중 사용자 환경에서의 물리적 자원 초과를 원천적으로 방어합니다.

 

메모리 스필링(Memory Spilling)

 

승인 제어의 엄격한 통제에도 불구하고, 통계 정보의 부정확성이나 데이터의 극단적인 편향(Data Skew)으로 인해 런타임 도중

실제 메모리 사용량이 옵티마이저의 추정치를 초과하는 예외적인 상황이 발생할 수 있습니다.

초기 임팔라 아키텍처는 노드의 할당 메모리를 초과하면 질의 전체를 즉시 실패(Fail) 처리하는 강경한 정책을 취했습니다.

 

그러나 현대의 임팔라 아키텍처는 노드의 가용 메모리가 고갈될 위기에 직면하면, 메모리에 상주하던 중간 연산 데이터

(해시 테이블이나 집계 버퍼의 일부 파티션)를 일시적으로 로컬 물리 디스크로 밀어내는 메모리 스필링 메커니즘을 작동시킵니다.

메모리 공간을 강제로 확보하여 연산의 흐름을 유지한 뒤, 처리가 진행됨에 따라 디스크에 임시로 기록해 둔 데이터를 다시 메모리로 불러와 남은 연산을 완수합니다.

 

메모리 스필링은 질의의 비정상적인 종료를 막고 완료를 보장한다는 점에서 시스템의 가용성을 극대화하지만, 학술적 관점에서는 매우 치명적인 반대급부를 수반합니다.

임팔라가 그토록 철저하게 회피하고자 했던 디스크 입출력의 굴레를 런타임에 강제로 뒤집어쓰게 되므로,

해당 질의의 응답 지연 시간은 순수 인메모리 연산 대비 수십 배에서 수백 배까지 기하급수적으로 증가하게 됩니다.

결론적으로 메모리 스필링은 초저지연(Low Latency)이라는 엔진의 본질을 일시적으로 희생하여 시스템의 생존(Stability)과 쿼리 완료를 선택한 아키텍처적 타협(Trade-off)의 최후 방어선입니다.

 

# 요약 

< 임팔라 개념 특징 >

- 대량 데이터 처리 분석 엔진 (그룹핑) / 트랜잭션 처리용이 아님. 

- MPP(Massively Parallel Processing) 또는 인메모리 엔진들이 쿼리를 처리. 

    => 인메모리 연산의 한계를 극복하고 디스크 I/O를 최소화하기 위해 스토리지 계층의 물리적 최적화가 필수적으로 수반됨.

    => 이를 달성하기 위해 아파치 파케이 포맷과 물리적 파티셔닝 기술이 도입됨.

- 아파치 파케이(Apache Parquet) 열 지향 파일 포맷 사용.

    => 데이터를 속성(Column) 단위로 모아 저장하여, 질의에 필요한 속성만 선택적으로 디스크에서 읽어 들임(프로젝션 푸시다운).

    => 블록 하단의 존 맵(Zone Map) 메타데이터 통계를 활용하여, 조건에 맞지 않는 데이터 블록의 물리적 스캔 자체를 생략함(데이터 생략 및 조건절 푸시다운).

- 물리적 파티셔닝(Partitioning) 구조 채택.

    => 테라바이트급 이상의 데이터를 생성 일자나 지역 등 특정 기준에 따라 HDFS 상의 독립된 서브 디렉토리로 분할 저장함.

- HDFS에 저장되어 있는 분리된 데이터에 데몬이 직접 접근하여 연산함.

    => 데이터노드의 하드디스크에서 로컬 읽기를 통해 메모리로 직접 가져오며 네트워크 I/O 비용을 원천 생략함.

- 임팔라 데몬(Impalad), 상태 저장소 데몬(Statestored), 그리고 카탈로그 데몬(Catalogd) 컴포넌트 사용

 

< 임팔라 아키텍처 특징>

- 대칭적 아키텍처로 모든 노드의 데몬은 동일한 내부 모듈(플래너, 코디네이터, 실행기) 구조를 가짐.

- 카탈로그 데몬(Catalogd)은 하이브 메타스토어 및 HDFS 네임노드와 통신하여 스키마와 물리적 블록 위치 정보를 자신의 전역 메모리에 캐싱하고 상태 저장소를 통해 동기화함.

- 질의를 수신하여 코디네이터로 승격된 데몬이 분산 실행 계획을 수립하고 다른 워커 노드로 파편화된 질의를 전달함.

- 비용 기반 옵티마이저(CBO)를 통한 실행 계획 최적화.

    => 통계 정보를 바탕으로 네트워크 셔플링 비용을 최소화하는 브로드캐스트 조인 또는 셔플 조인 전략 스케줄링

파티션 프루닝(Partition Pruning) 알고리즘 적용.

    => 쿼리 플래너가 조건절을 분석하여 검색 조건에 부합하지 않는 HDFS 파티션 디렉터리를 디스크 스캔 대상에서 선제적으로 배제하여 초기 I/O 부하를 차단함.

- 연산을 처리한 노드는 중간 결과를 디스크에 기록하지 않고 메모리 상에서 네트워크 소켓을 통해 노드 간 파이프라인 형태로 즉각 스트리밍함.

 

 

참조 : https://impala.apache.org/docs/build/asf-site-html/topics/impala_concepts.html