본문 바로가기

CLOUDERA

Cloudera Impala Architecture ( CDH 5.1.X )

http://www.cloudera.com 번역한 글입니다.


<IMPALA>


- A COLUMNAR STORAGE LAYOUT

- IMPALA 는 HDFS 혹은 HBASE 에 저장 되어 있는 데이타에 쿼리(질의) 한다.

- SQL Syntax (Hive SQL), ODBC driver, UI (HUE 에서 제공)



<ARCHITECTURE>



( http://www.cloudera.com/ 에서 가져온 이미지 입니다.)



Hive Metastore - Impala 에 사용 가능한 데이터에 대한 정보를 저장

 어떤 데이타베이스를 사용할 수 있고 그 구조가 어떻게 되는지를 가진다.

 

Cloudera Impala - DataNodes 에 구성 되며, 쿼리를 실제 수행하는 주체.



Impala 를 사용하는 실행되는 쿼리들은 다음과 같이 수행된다.


1. User application 에서 ODBC, JDBC 를 통해 Impala 로 SQL queries 를 전달한다.

 User application 은 클러스터의 어느 impalad 와 연결 된다.

 이 impalad 는 Query 의 cordinator 가 된다.

 

2. Impala 는 query 를 parse 하고 Cluster 에서 impalad 에 의해 어떤 tasks 가 

 수행되어야 하는지 결정하기 위해 분석한다.


3. 데이타를 제공하기 위해 HDFS 나 HBase 가 local impalad 로부터 엑세스 된다.


4. impalad 는 coordinating impalad 로 데이타를 리턴한다.

 이 impalad 는 결과를 client 로 리턴한다.


부연으로 impalad 는 Cloudera Manager 상에서 Impala Daemon 으로 표현된다.

또 n 개로 구성되며, 일반적으로 HDFS 의 Data Node 수와 동일하게 구성한다.



<Primary Impala Features>


- SELECT joins, 집계 함수를 포함하는 HiveQL 의 대부분의 SQL-92 features

- HDFS and HBase storage

 HDFS file formats : Text file, SequenceFile, RCFile, Avro file and Parquet

 Compression codecs: Snappy, Gzip, Deflate, BZIP

- Common Hive interface

 JDBC driver

 ODBC driver

 Hue Beeswax, New Cloudera Impala Query UI

- Impala command-line interface

- Keroberos authentication



<Impala Concepts and Architecture>


Impala daemons 은 statestore 를 통해 일관적인 커뮤니케이션을 하며,

어떤 노드가 정상 상태이고 새로운 일을 받아 들일 수 있는지 확인한다.


또 statestore 는 catalog 로부터 브로드캐스팅 된 메시지를 수신한다. ( 1.2 에서 소개 됨 )

이 메시지는 어느 impala node 에서 creates, alters, 혹은 어떤 타입의 오브젝트에 대한 drops,

혹은 INSERT 나 LOAD DATA 를 Impala 를 통해 수행할 때 브로드 캐스팅 된다.


이는 1.2 이전의 REFRESH 나 INVALIDATE METADATA 와 같은 statements 와 같은

노드 간 메타데이타의 조정을 위한 백그라운드 커뮤니케이션 비용을 줄여준다.



<The Impala Statestore>


Cluster 의 모든 Impala daemons 에 대해 Health 체크를 한다.

process 의 이름은 statestored 이며 클러스터에서 하나의 노드에 존재하면 된다. (하나의 프로세스)

만약 Impala node 가 하드웨어, 네트워크, 소프트웨어 등의 이유로 오프라인 되면

statyestore 는 모든 다른 노드에 대해 이를 전파하여 쿼리가 사용 불가능한 노드에 대해

요청을 하는 것을 방지한다.


Statestore 가 오프라인이 되도 Impala Cluster 의 정상 수행에는 크리티컬하지 않다.

만약 이 프로세스가 offline 이 되도, 다른 노드는 평소와 같이 수행된다.

클러스터는 다만 Statestore 가 오프라인 인 상태에서 다른 노드들이 페일되는 경우

Less rodust 하다.

Statestore가 다시 온라인이 되면, 다른 노드와 다시 통신을 시작하여 모니터링 기능을 재수행한다.



<The Impala Catalog Service>


Cluster 내 모든 노드에 대한 Impala SQL statements 로부터

메타데이타를 중계한다.


물리적으로 catalogd 라는 프로세스 이름을 가진다. 또 이는 클러스터 내의 한 노드의

하나의 프로세스만 필요하다.

Request 가 statestore daemon 을 통해 전달되기에 statestored 와 catalogd 는 같은 노드에 구성한다.


이 콤포넌트는 1.2 에서 소개되었고, REFRESH 와 INVALIDATE METADATA statements 의 필요성을 줄여준다.


이를테면, 만약 CREATE DATABASE, DROP DATABASE, CREATE TABLE, ALTER TABLE, DROP TABLE 을 한 Iimpala node 에서 수행하자고 하자.

그러면 다른 모든 노드에서는 해당 테이블에 대해 QUERY 하기 전에 INVALIDATE METADATA 를 수행해야 한다.

이를 통해 스키마 오브젝트에 변경이 있음을 알 수 있다. 


마찬가지로 INSERT 구문을 한 노드에서 수행하면, REFRESH table_name 을 Query 하기 전에 다른 모든 노드에 수행해야 한다. 

이 과정을 통해 새로이 추가 된 데이타 파일을 인식하게 된다.

catalog service 는 impala 를 통해 수행 된 statements 로 메타데이타에 변경이 생긴 경우,

REFRESH 나 INVALIDATE METADATA 를 수행해야 할 필요성을 줄여준다.


그러나 HIVE 를 통해 테이블 생성, 데이타 로드 등을 했을 때는 여전히 

IMPALA 에서 쿼리를 수행하기에 앞서 REFRESH 나 INVALIDATE METADATA 를 수행해야 한다.



<Impala SQL 의 특징>


- Impala SQL 은 쿼리와 상대적으로 적은 DML 에 포커싱되어있다.

이를테면 UPDATE 와 DELETE 가 없다. Stale Data 는 일반적으로 버려진다.

(DROP TABLE, ALTER TABLE ... DROP PARTITION) 혹은 (INSERT OVERWRITE)

- 모든 데이타 로딩은 INSERT 로 이루어진다.

 INSERT INTO 와 INSERT OVERWRITE 두 가지 타입이 있는데, 후자의 경우

 해당 테이블 혹은 테이블의 파티션의 모든 컨텐츠를 초기화 한다.

 하나의 VALUE 를 입력하는 INSERT INTO 는 없다.

- Impala table 이 아닌 다른 환경에서 데이타를 만들어 Impala 에서 사용하는게

 가능하다. 

- Delimiter 를 사용한 External table 생성이 가능하다.

- Impala 가 대량의 데이터를 읽기에 데이타 길이에 대한 제약은 느슨하다.

- 파티션 테이블을 지원한다.



<How Impala Works with Hive>


Impala 는 table 정의를 전통적인 RDBMS - MySQL 이나 PostgreSQL 데이타베이스에 저장한다. (metastore)

Hive 도 이런 종류의 데이타를 저장한다.

때문에 , Impala 는 Hive 로 정의되거나 저장 된 데이타를 엑세스 할 수 있다.

(Impala 가 지원하는 포맷에 한해)




<Overview of Impala Metadata and the Metastore>


Impala 는 metastore 라는 중앙 데이터베이스에서 정보를 관리한다.

또한 데이타 파일의 메타데이타를 low-level 에서 추적한다.


그렇기에 큰 사이즈나 많은 수의 파티션을 가진 테이블을 탐색하게 되면, 메타데이타의

탐색으로 많은 시간을 소모하며 이는 수 분 단위까지 갈 수 있다.


그래서 각 implala node 는 추후 동일 테이블에 대해 메타데이타를 재사용하기 위해

캐시한다.


만약 테이블 정의나 데이타가 변경되면, 다른 Impala daemons 은 

다른 쿼리를 수행하기에 앞서 최신의 metadata 로 업데이트 해,

불필요해진 캐시 된 메타데이타를 대체한다.


Impala 1.2 이상의 버전에서는, 

Impala 를 통해 수행되는 모든 DDL 과 DML 에 대해

메타데이타가 자동으로 업데이트 된다.


그리고 이는 catalogd daemon 을 통해 이루어진다.


Hive 를 통해 수동으로 가한 DDL 이나 DML 은 , 혹은 HDFS 에 직접 가한 변경에 대해서는,

여전히 REFRESH 나 INVALIDATE METADATA 구문을 사용해야 한다. 

(새로운 전체 테이블에 대해, 테이블 삭제 이후, HDFS rebalance, datafile 삭제)


INVALIDATE METADATA 명령은 metastore 에서 추적되는 모든 테이블에 대해 메타데이타를 찾는다.

만약 Impala 외부에서 가해진 변경에 대해 알고 있다면 REFRESH table_name 을 

변경 된 테이블에 대해 각기 수행하면 된다.



<Cluster Sizing Guidelines for Impala>


Impala 는 클러스터 노드의 하드웨어 스펙과 무관하게 일을 균등 배분한다.

특정 호스트의 CPU, MEMORY, I/O, NETWORK 등의 부하로 인해 클러스터의

비일관적인 퍼포먼스, 전체적인 속도 저하를 겪을 수 있다.



- 해당 문서의 표에 의하면 64 GB RAM, 12.2 TB hard drives, 2x E5-2630L 12 cores total, 10 GB network) 기준으로

500GB 의 데이타를 동시성 100 Queries 를 10개의 데이타 노드로 처리할 수 있다. (20초 안에 처리 가정)