Components of the Impala Server

Impala의 주 목적은 빠르고 효율적인 SQL-On-Hadoop 오퍼레이션을 제공하는 것입니다. 특히, Impala는 Hive에서 사용하는 테이블 메타 정보를 보관 관리하는 Metastore을 직접 참조하기 때문에, Hive가 정의한 테이블에 로드된 데이터가 Impala에서 지원되는 데이터 유형, 파일 포멧 및 압축 코덱인 경우 해당 테이블을 직접 접속하여 사용할 수 있습니다.

Overview of Impala Metadata and the Metastore

Impala는 Hive Metastore라는 데이터베이스에 테이블 메타 정보를 유지관리하며, 다음과 같은 데이터 파일의 특성에 대한 다른 메타데이터 정보를 추적관리합니다: 

• HDFS내의 블록 위치 정보

많은 양의 데이터나 많은 파티션이 있는 테이블에 대해서 테이블의 모든 메타정보를 회수하는데 많은 시간이 소요될 수도 있기 때문에, Impala는 이와 같은 대량 동기화 문제를 개선하기 위해서 개별 Impala 노드에는 동일한 테이블에 대한 메타 정보를 재사용 용도로 캐시하고 있습니다. 테이블내의 메타 정보나 데이터가 변경된 경우, 클러스터의 다른 모든 Impala 데몬들은 해당 테이블에 대한 쿼리를 실행하기 전에 최신 메타 정보를 갱신해야 합니다. Impala 1.2 이상에서는 Impala에서 수행된 모든 DDL 및 DML 문에 의한 메타데이터 갱신은 Catalogd 데몬을 통해 자동으로 모든 클러스터내의 Impala 데몬에 동기화됩니다. 하지만, Hive를 통해 변경사항이 발생한 경우, 메타정보가 Catalog 데몬을 통해 동기화되지 않습니다. 

기존 테이블에 새로운 데이터 파일이 추가된 경우 Refresh 문을 수행해야 합니다. 또한, 전체가 새로운 테이블이거나 특정 테이블이 삭제된 경우, HDFS Rebalance 오퍼레이션이 수행되거나, 테이터 파일이 삭제된 경우 INVALIDATE METADATA 문을 수행해야 합니다. INVALIDATE METADATA 문이 실행되면 Metastore에서 관리하는 모든 테이블에 대한 메타정보를 회수합니다. 만일 Impala 외부에서 변경된 특정한 테이블를 알고 있는 경우에는 "REFRESH table_name" 문을 수행하여 해당 테이블에 대한 최신 메터 정보로 전체 Impala 데몬에게 동기화할 수 있습니다. 

How Impala Uses HDFS

Impala는 주 스토리지 컴포넌트로 분산 파일 시스템인 HDFS를 사용하기 때문에, 개별 데이터 노드의 하드웨어 또는 네트워크 장애를 방지하기 위해 HDFS에서 제공하는 Reliable 기능을 그대로 활용합니다. Impala 테이블 데이터는 HDFS 파일 형식 및 압축 코덱을 사용한 HDFS내의 데이터 파일을 의미합니다. 신규 테이블에 매핑된 신규 파일 디렉터리내에 새로운 데이터가 존재하는 경우, Impala는 파일 이름에 관련 없이 해당 파일 모두를 읽습니다. 새로운 데이터는 Impala에서 관리되는 명명규칙에 의해 새로운 파일로 추가됩니다. 

How Impala Uses HBase

HBase는 Impala 데이터 저장 매체로 HDFS로 대체할 수 있으며, HBase는 HDFS 상위 층에 구축된 데이터베이스 스토리지입니다. Impala에서 테이블을 정의하고 HBase에 동일한 테이블로 매핑함으로써, Impala를 통해 HBase 테이블내의 데이터에 대해 쿼리를 수행할 수 있으며, 심지어 Impala / HBase테이블에 조인 쿼리를 수행할 수 있습니다. 

Impala Components

Impala 서버는 분산되어 있으며, MPP(Massively Parallel Processing) 데이터베이스 SQL 엔진이며, CDH 클러스터 내에 세 가지 컴포넌트로 구성되어 있습니다. 

1. Impala Daemon
2. Impala Statestore
3. Impala Catalog Service

부하분산(Load Balancing) 및 고가용성(HA)에 대한 아키텍처 고려사항은 Impala Daemon에게만 적용되어 설계되었습니다. Impala StateStore 및 Catalog 서비스에 장애가 발생하더라도 데이터 유실과 같은 심각한 장애가 발생하지 않기 때문에 해당 컴포넌트에 대해서는 고가용성이 고려되어 설계되지 않았습니다. 만일 Impala StateStore 및 Catalog 서비스에 장애가 발생한 경우, Cloudera Manager를 활용하여 실행중인 Impala Service를 중지하고, 기존에 배포된 Impala StateStore 및 Impala Catalog Server 역할을 삭제한 뒤, 가용한 다른 노드에 해당 컴포넌트(Impala StateStore / Catalog Server) 역할을 추가하여 빠르게 조치할 수 있습니다.  

1. Impala Daemon

코어 Impala 컴포넌트로 클러스터의 개별 DataNode에서 실행되는 impalad 프로세스입니다. 이 Impala Daemon 프로세스는 Impala-shell 명령어, Hue, JDBC나 ODBC에서 전송된 쿼리 요청을 수용하고, 쿼리 실행을 병렬 처리하기 위해 클러스터내의 Impala 데몬 프로세스에게 작업을 분배하고, 데이터 노드의 데이터 파일에 대해 직접 읽기/쓰기 작업을 수행하며, 클라이언트에게 작업 결과를 리턴하기 위해 Coordinator 노드의 Impala 데몬이 분산 처리된 작업 결과를 수집 및 집계하여 작업결과를 회신합니다. 

모든 DataNode 호스트에서 실행 중인 Impala Daemon에게 쿼리 작업을 제출(submit)이 가능하며, 요청을 접수 받은 Impala Daemon은 해당 쿼리에 대한 Coordinator 노드의 역할을 수행하며, 다른 노드에서는 실행된 부분 결과는 Coordinator 노드에서 수집하며, 분산 처리된 결과를 집계하여 최종 수행 결과를 생성합니다. 테스트 환경에서는 특정 Impala 데몬에게 직접 연결하여 요청을 수행할 수도 있으며, 운영 환경에서는 소프트웨어/하드웨어 기반의 부하분산 컴포넌트를 사용하여 JDBC / ODBC 인터페이스를 사용하여 다중 Impala Daemon에게 round-robin 패턴으로 쿼리 요청을 부하분산 시킬 수 있습니다. 

Impala Daemon은 클러스터내에서 정상 동작 중인 다른 Impala Daemon의 health 상태를 확인하기 위해 Statestore와 통신하며, 클러스터 내의 특정 Impala 노드에서 수행된 Create, Alter나 Drop과 같은 오퍼레이션이나 INSERT나 LOAD DATA와 같은 문이 실행될 때 변경사항을 동기화하기 위해서 catalogd 데몬에서 발행된 broadcast 메시지를 수신합니다.  

2. Impala Statestore

Impala Statestore(statestored 프로세스)는 클러스터내의 모든 DataNode상의 Impala Deamon의 health를 체크하는 역할을 담당합니다. 이 statestored 프로세스는 클러스터내에 단일 호스트에만 배포 구성됩니다. 특정 Impala Daemon이 하드웨어, 네트워크 장애 및 소프트웨어 이슈와 같은 이유로 오프라인으로 상태가 변경된 경우, Statstore는 장애가 발생한 노드의 Impala Daemon에게 쿼리 요청이 전달되지 않도록 장애가 발생한 Impala Daemon의 내용을 다른 Impala Daemon에게 공유합니다. 

Statestore의 용도는 문제가 발생한 경우 이를 지원하는 기능을 하기 때문에 Impala 클러스터내의 일반적인 동작에는 중요한 역할을 담당하지 않습니다. Statestore가 실행되지 않거나 문제가 발생을 하더라도 Impala Daemon은 정상 동작하며, 장애가 발생한 Statestore가 다시 온라인 상태로 변경이 되면, Impala Daemon은 다시 Statestore와 연결이 되어 전체 클러스터내의 Impala Daemon의 모니터링 기능을 수행합니다. 

Impala StateStore 컴포넌트가 Impala 클러스터링 환경에서의 기능 및 역할을 간략하게 설명하면 다음과 같습니다:

• Impala StateStore가 중지가 되어 있더라도 Impala 데몬에서 실행되는 쿼리 수행에 영향도가 없습니다.

• 그리나, StateStore에 장애가 발생하여 OFF 상태인 경우, 전역 상태 변경사항이 Impala 클러스터링내에 공유되지 않습니다. 하지만, StatStore가 다시 Online 상태로 변경되면 다시 정상 동작을 재개합니다.

• StateStore의 주 역할은 다음과 같습니다:

1. Cluster Membership: Impala 데몬들의 health checking 정보를 공유합니다.

2. Metadata 갱신: Catalog 서버에서 발생된 메타데이터 변경사항을 Impala 데몬에게 공유합니다.

3. Admission Control State: Impala Admission Control이 Out Of Sync로 동작됩니다.

3. Impala Catalog Service

Catalog Service(catalogd)는 Impala SQL 문에서 발생한 메타데이터의 변경사항을 클러스터내의 모든 Data Node에게 전파하는 역할을 담당합니다. 이 카탈로그 데몬은 클러스터내에 Standalone으로 배포하도록 설계되었습니다. 또한, Catalogd에서 발생한 요청은 Statestore 데몬을 통해 전파되기 때문에 statestored / catalogd 서비스를 동일한 호스트에 배포 구성하는 것을 권장합니다. 

Impala를 통해 메타데이터가 변경된 경우에는 REFRESH와 INVALIDATE METADATA 문을 수행할 필요가 없습니다. Hive을 통해 테이블을 생성하거나 데이터를 로딩하는 경우에는 Impala 쿼리를 수행하기 전에 Impala 노드에서 REFRESH나 INVALIDATE METADATA를 수행해야 합니다.    

• Impala를 통해 CREATE TABLE, INSERT나 다른 테이블 변경과 데이터 변경 오퍼레이션에 대해서는 REFRESH와 INVALIDATE METADATA 문을 실행할 필요가 없습니다. 

• Hive나 HDFS에서 직접 데이터 파일을 조작하는 경우에 특정 하나의 Impala 노드에서 REFRESH와 INVALIDATE METADATA문을 실행해야 합니다.

메타데이터 로딩 및 캐싱의 기본 동작 방식은 비동기방식으로 실행 시점에 수행되기 때문에, Impala는 즉시 SQL 요청을 수용할 수 있습니다. 모든 메타데이터를 로딩한 뒤에 요청을 처리하도록 변경하기 위해서는 catalogd 구성 옵션을 다음과 같이 설정하십시오:

load_catalog_in_background=false

Impala Catalog 서비스에 장애가 발생한 경우에는 다음과 같이 동작합니다:

• Impala 데몬의 로컬 캐쉬내에 보관된 메타데이터를 활용하여 select 쿼리에 대해서는 정상 동작합니다.
• 신규로 변경된 메타데이터가 Impala 데몬의 로컬 캐쉬에 반영되지 않습니다.
• DML 오퍼레이션이 작동하지 않습니다.
• 신규 파티션을 생성하는 INSERT 문은 실패되지만 데이터는 정확하게 입력됩니다.

참고자료: https://www.cloudera.com/documentation/enterprise/5-8-x/topics/impala_components.html