cloudera.com CDH 5.1.x 메뉴얼을 요약한 글입니다.
<Tuning Impala for Performance>
이에 앞서 Hardware Requirements 가 충족 됨을 사전 확인해야 한다.
특히 Memory 에 대해서는 128 GB 혹은 그 이상이 추천되며, 이상적으로는 256GB 이상을 추천한다.
만약 쿼리 수행 중 중간 결과가 어느 노드의 임팔라가 가용 가능한 메모리를 다 소진하게 되면
해당 쿼리는 취소된다.
일반적으로 중간 결과들은 원본 데이타보다 작아지고, 일 또한 병렬로 수행되기 때문에
임팔라는 각 노드의 가용 가능한 메모리보다 더 큰 데이타에 대해 질의나 조인을 수행할 수 있다.
성능에 영향을 미치는 요소
- Partitioning
- Performance Considerations for Join Queries
- Table Statistics and Column Statistics
- Testing Impala Performance
- Benchmarking Impala Queries
- Controlling Resource Usage
<Impala Performance Guidelines and Best Practices>
Choose the appropriate file format for the data
Parquet file format 이 가장 좋은 성능을 내며,
이는 columnar storage layout 과 Compression, Encoding, 대형의 I/O request size 와
어우려져 가장 좋은 퍼포먼스를 낸다
참고 : Using the Parquet File Format with Impala Tables
http://www.cloudera.com/content/cloudera/en/documentation/cdh5/latest/Impala/Installing-and-Using-Impala/ciiu_parquet.html#parquet
Avoid data ingestion processes that produce many small files
일반적으로 hdfs 에 적재할 때 text format 이나 avro 같은 row 단위 사이즈를 사용하게 된다.
이후 Impala 에서는 더 효과적인 Parquet 으로 컨버트 할 수 있다.
이는 INSERT ... SELECT 구문을 이용해 이루어지며 복수의 DATA files 로 분할된다.
만약 수십메가의 Parquet files 로 데이타 준비가 가능하다면 Impala 에서의 컨버트는 불필요하다.
Choose partitioning granularity based on actual data volume.
파티셔닝의 경우 각각의 파티션이 최소 1GB 를 사용하도록 한다.
이를 통해 HDFS bulk I/O 와 Impala distributed queries 의 장점을 누릴 수 있다.
과도한 분할 (Over-partitioning) 은 쿼리 플래닝에 시간을 더 소모하게 되며,
보통 한 테이블의 이상적인 파티션 숫자는 30,000 미만이다.
Use smallest appropriate integer types for partition key columns.
파티션 키 컬럼에 사용된 데이타는 hdfs 상에서 디렉토리 형태로 만들어진다.
Partition key 값에 대해 적절한 데이타 타입과 사이즈의 사용으로 메모리 절약이 가능하다.
Choose an appropriate Parquet block size
기본적으로 임팔라는 INSERT ... SELECT 에 대해 1GB 블록 사이즈의 Parquet files 을 생성한다.
해당 파일은 단일 노드에서 수행될 수 있게 되어 있다.
만약 Parquet 테이블 안에 적은 수의 데이타 파일이 있거나, 쿼리에 의해 하나의 파티션만
엑세스 되는 경우 여러가지의 이유로 성능 저하를 겪을 수 있다.
각각의 데이타 파일은 한 데이타 노드의 한 싱글코어에서 처리된다.
100-node, 16-core 머신이라 하면 1600 데이타 파일에 대해 동시 처리가 가능하다.
때문에 많은 수의 files 과 하나의 거대한 파일 간에 밸런스를 찾아야 한다.
이는 Bulk I/O 와 Parallel processing 간의 문제이기도 하다.
이러한 이유로 INSERT ... SELECT 수행에 앞서 PARQUET_FILE_SIZE 를 셋팅해
사이즈를 조정하는게 가능하다.
적절한 값을 찾기 위해서는 벤치마킹이 필요하다.
Gather statistics for all tables used in performance-critical or high-volume join queries.
COMPUTE STATS 를 이용해 통계를 수집한다.
Performance Considerations for Join Queries
http://www.cloudera.com/content/cloudera/en/documentation/cdh5/latest/Impala/Installing-and-Using-Impala/ciiu_perf_joins.html#perf_joins
Minimize the overhead of transmitting results back to the client.
Verify that your queries are planned in an efficient logical manner.
Verify performance characteristics of queries.
<Performance Consideration for Join Queries>
조인 성능을 개선하기 위한 가장 간단한 방법은 join 과 연관 된 테이블에 대해 COMPUTE STATS 구문을 사용하는 것이다.
그러면 Impala 는 각 테이블의 사이즈를 베이스로 자동으로 최적화 한다.
위 방법 외에도 STRAIGHT_JOIN 키워드를 이용하여 조인 순서를 고정할 수 있다.
STRAIGHT_JOIN 을 사용하는 경우 옵티마이저에 의존하는게 아니라 수동으로 조인 순서를 지정해야 한다.
메뉴얼 ORDERING 을 위해서 다음을 참고한다.
- 가장 큰 테이블을 지정한다. 이 테이블은 각 임팔라 노드의 디스크로부터 읽어들여지며,
이 데이타의 사이즈는 쿼리 수행중의 메모리 사용 측면에서 크지 않을 것이다.
- 다음으로 가장 작은 테이블을 지정한다. 이 테이블은 네트워크를 통해 전부 전송된다.
조인 쿼리의 각 단계의 결과 셋의 사이즈를 작게 만들길 원한다면, 가장 많이 사용되는
접근으로 가장 작은 테이블을 먼저 조인하는 것이다. 이를 통해 큰 테이블과의 조인 후에도
작은 사이즈로 남게 된다.
- 다음으로 가장 작은 테이블과 조인한다. 다른 테이블이 있다면 이 과정이 반복된다.
- 만약 BIG, MEDIUM, SMALL, TINY 테이블이 있다면 조인 오더는 다음과 같이 된다.
BIG, TINY, SMALL, MEDIUM
Broadcast joins
기본으로 사용되며, 우측 테이블은 좌측 테이블과 비교하여 작은 사이즈의 테이블로 간주 된다.
그리고 그 컨텐츠는 다른 노드로 전파된다.
Partitioned join (Partitioned table 과 상관 없음)
크기가 비등비등한 대형 테이블 간의 조인에 적합하다.
일정 비율의 각 테이블이 패러렐로 수행될 수 있도록 알맞은 다른 노드로 보내진다.
Broadcast joins 과 Partitioned join 은 Optimizer 가 stats 를 기반으로 선택한다.
Hints
http://www.cloudera.com/content/cloudera/en/documentation/cdh5/latest/Impala/Installing-and-Using-Impala/ciiu_hints.html#hints
How Joins Are Processed when Statistics Are Unavailable
가용 가능한 통계를 이용해 순서를 조정한다.
통계정보 없는 테이블은 zero-size 테이블로 간주된다.
Overriding Join Reordering with STRAIGHT_JOIN
select straight_join x from medium join small join (select * from big where c1 < 10) as big
where medium.id = small.id and small.id = big.id;
<How Impala Uses Statistics for Query Optimization>
COMPUTE STATS (TABLE)
SHOW TABLE STATS (TABLE)
SHOW COLUMN STATS (TABLE)
COMPUTE STATS
TABLE, 파티션과 컬럼에 대한 통계정보를 수집한다.
증분으로 통계를 적용하고 싶다면 다음과 같이 사용한다. (사실 상 수동 셋팅)
ALTER TABLE ANALYSIS_DATA SET TBLPROPERTIES('numRows'='new_value');
COMPUTE STATS 를 사용하면 테이블, 컬럼 다 수집 된다.
<Using HDFS Caching with Impala>
HDFS cache 는 Linux OS cache 를 이용하는 것보다
checksumming 과 memory-to-memory 복사와 연관 된 부하를 줄일 수 있다.
자주 엑세스 되는 데이타를 메모리에 영구적으로 pinned 할 수 있다.
이는 테이블이나 파티션이 자주 엑세스 되고 그 사이즈가 HDFS cache 전체에 적재 될 정도로
작은 경우 유용하다.
http://www.cloudera.com/content/cloudera/en/documentation/cdh5/latest/Impala/Installing-and-Using-Impala/ciiu_perf_hdfs_caching.html#hdfs_caching_etl_unique_1
<Understanding Impala Query Performance - EXPLAIN Plans and Query Profiles>
explain select count(*) from customer_address;
쿼리 수행 후 summary;
쿼리 수행 후 profile;
