1) SCHEDULE_RANDOM_REPLICA Query Option (CDH 5.7 이상)
"SCHEDULE_RANDOM_REPLICA" 쿼리 옵션은 각 HDFS 데이터 블록을 처리하는 호스트를 설정할 때 활용되는 알고리즘입니다. 이 옵션은 HDFS 캐싱 기능을 사용하지 않은 테이블과 파티션에만 적용됩니다.
Default: false
HDFS 캐시 복제본이 있는 경우, Impala는 캐시된 데이터 블록을 처리할 호스트를 임의로 선택합니다.
"SCHEDULE_RANDOM_REPLICA"은 HDFS 캐싱을 사용하지 않은 테이블과 파티션에 적용되는 쿼리 옵션입니다. 기본 동작 방식으로 Impala는 요청받은 쿼리에 대해 개별 호스트에서 실행될 작업량을 예측한 뒤, 가장 적은 워크로드를 가진 호스트를 선택합니다. 이 알고리즘은 여러 데이터 블록을 처리할 호스트로 동일한 호스트가 선택된 경우 발생될 CPU 핫스팟을 줄이기 위한 용도로 개발되었습니다. 그러나 데이터 구조와 쿼리의 조합에 의해 여전히 CPU 핫스팟이 발생할 수 있습니다. "SCHEDULE_RANDOM_REPLICA" 옵션을 활용화 하면, Impala는 CPU 핫스팟 발생 확률을 경감하기 위해 HDFS 캐시가 적용되지 않은 블록에 대해 스케쥴링 알고리즘을 임의 선택 방식으로 분산시킬 수 있습니다. 이 쿼리 옵션은 CDH 5.7 / Impala 2.5 이상 버전에 적용할 수 있습니다.
이 기법은 캐시된 HDFS 데이터 블록의 핫스팟을 경감하기 위한 용도로도 활용 가능합니다. 즉, 하나 이상의 호스트에 데이터 블록들이 캐시되도록 구성한 뒤에 CPU 부하가 존재하는 경우 "SCHEDULE_RANDOM_REPLICA" 쿼리 옵션을 사용하면 됩니다.
2) Avoiding CPU Hotspots for HDFS Cached Data
빈번하게 참조되는 테이블이나 파티션에 대한 I/O 사용률 및 메모리-대-메모리 복사를 최소화하여 성능을 개선하도록 Impala의 HDFS 캐싱 기능을 사용할 수 있습니다. 일부 고객사에서 이 기능을 사용하더라도 괄목할만한 성능 개선이 되지 않은 경우를 종종 목격할 수 있었습니다. 그 이유는 테이블 내의 데이터를 읽는 작업이 클러스터 전역의 데이터 노드에서 병렬 처리 되는 I/O 집약적인 작업에서 특정 호스트내에 메모리를 참조하도록 변경됨으로써 핫스팟이 발생하였기 때문입니다. 즉, I/O 사용률은 감소하였지만 특정 호스트에 집중되어 있는 데이터 블록을 처리하도록 CPU 부하가 증가되었기 때문입니다. 이와 같은 핫스팟 현상을 피하기 위해서, HDFS 캐싱을 사용한 테이블에 대해 CREATE TABLE이나 ALTER TABLE 문에서 WITH REPLICATION 절을 사용해야 합니다. 이 절은 사용하면 하나 이상의 호스트에 관련된 데이터 블록을 캐쉬하기 때문에, 캐시내의 데이터를 참조하는 경우 CPU 부하를 분산시킬 수 있습니다.
WITH REPLICATION 절을 사용하더라도 일부 상황에서는 캐시된 HDFS 데이터를 처리하는 경우에 높은 CPU 부하와 함께 핫스팟이 발생할 수 있습니다. CDH 5.7 및 Impala 2.5 이상 버전에서는 HDFS 캐시 데이터가 모든 호스트에 더 잘 분포할 수 있도록 스케쥴링 방식이 개선되었습니다. 하나 이상의 호스트가 특정 데이터 블록용 캐시 복제본을 가지고 있는 경우, Impala는 현재 처리중인 쿼리에 대해 가장 부하가 적은 노드에서 블록을 처리하도록 합니다. 즉, 로드-기반 스케쥴링 알로그즘하에서 핫스팟이 지속적으로 발생하는 경우, CPU 로드를 분산되도록 "SCHEDULE_RANDOM_REPLICA=TRUE" 쿼리 옵션을 사용할 수 있습니다. 이 설정은 스케쥴링 알고리즘에서 가장 적은 부하를 가지는 호스트를 결정하기 어려운 경우, 캐시된 데이터 블록을 처리하는 호스트 선택을 랜덤하게 수행하기 위한 옵션입니다.
3) NUM_SCANNER_THREADS Query Option
각 쿼리에 사용되는 Scanner 쓰레드(개별 호스트 별)의 최대수로, 기본 값으로 Impala는 사용 가능한(core당 하나의 쓰레드) 모든 core를 사용합니다. 부하가 높은 클러스터에서 리소스-집약적인 쿼리를 사용하는 경우 이 값을 낮게 설정할 수 있습니다. 또한 기본 값으로 Impala 자체가 높은 값으로 자동 설정하기 때문에 이 옵션의 값을 높게 설정하는 것은 의미가 없습니다.
Type: numeric
Default: 0
"MAX_NUM_RUNTIME_FILTERS" 쿼리 옵션은 각 쿼리에서 생성할 수 있는 runtime flter의 상한 수를 정의합니다.
Type: integer
Default: 10
"RUNTIME_BLOOM_FILTER_SIZE" 쿼리 옵션에 따라, 각 필터는 Plan Fragment 당 1에서 16 메가바이트를 더 사용하기 때문에, Runtime filter는 쿼리에 메모리 사용에 대한 부하가 좀더 발생합니다. 이 값은 Plan Fragment 당 5 이하로 설정하는 것이 일반적입니다.
Impala는 각 필터의 효율성을 평가하여 필터에서 가장 많은 수의 파티션이나 row를 제거하고 유지하려고 합니다. 따라서, 이 설정 값은 필터 생성에서 발생가능한 과도한 메모리 오버 헤드로 인한 잠재적인 문제를 보호하는 동시에 쿼리에 대해 높은 수준의 최적화를 제공합니다.
5) RUNTIME_FILTER_WAIT_TIME_MS Query Option (CDH 5.7 이상)
"RUNTIME_FILTER_WAIT_TIME_MS" 쿼리 옵션은 런타임 필터링 기능에 관련된 설정 옵션입니다. 즉, 각 Scan 노드가 다른 Plan Fragment에 의해 생성된 Run-time filter를 대기하는 시간(Millisecond)을 설정입니다.
Type: integer
Default: 0 (Impalad 시작 옵션에 적용된 값이 사용됨)
6) RUNTIME_FILTER_MIN_SIZE Query Option (CDH 5.8 이상)
"RUNTIME_FILTER_MIN_SIZE" 쿼리 옵션은 런타임 필터링 기능에 관련된 설정 옵션입니다. 이 옵션은 Planner에서 계산된 추정치(Estimate)의 값과 상관없이 필터에 대한 최소 크기를 정의합니다. 또한, 이 값은 "RUNTIME_BLOOM_FILTER_SIZE" 쿼리 옵션 값보다는 항상 우선되며, 플터 크기는 가장 유사한 2 거듭 제곱으로 반올림됩니다.
Type: integer
Default: 0 (Impalad 시작 옵션에 적용된 값이 사용됨)
7) RUNTIME_FILTER_MAX_SIZE Query Option (CDH 5.8 이상)
"RUNTIME_FILTER_MAX_SIZE" 쿼리 옵션은 런타임 필터링 기능에 관련된 설정 옵션입니다. 이 옵션은 Planner에서 계산된 추정치(Estimate)의 값과 상관없이 필터에 대한 최대 크기를 정의합니다. 또한, 이 값은 "RUNTIME_BLOOM_FILTER_SIZE" 쿼리 옵션 값보다는 우선됩되며, 필터 크기는 가장 유사한 2 거듭제곱으로 반올림됩니다.
Type: integer
Default: 0 (Impalad 시작 옵션에 적용된 값이 사용됨)
runtime filtering 기능은 주로 리소스를 많이 사용하고 오래 실행되는 쿼리에 적용되기 때문에 주로 큰 파티션 및 테이블에 대해 오래 실행되는 쿼리를 튜닝하는 용도로 다른 쿼리 옵션과 함께 적용하십시오(3번 옵션부터 7번 옵션까지 버전별로 지원되는 옵션을 함께 사용).
8) 기타 Impala Daemon 옵션
- Default : 12
| +DEFINE_int32(datastream_ | ||
| + "elapse before a plan fragment will time-out trying to send the initial row batch."); |
- Default: 120000
| +DEFINE_int32(accepted_cnxn_ | ||
| + "(Advanced) The size of the post-accept, pre-setup connection queue for Impala " | ||
| + "internal connections"); |
- Default: 10000
참고:
- http://www.cloudera.com/documentation/enterprise/latest/topics/impala_perf_hdfs_caching.html#hdfs_caching
- http://www.cloudera.com/documentation/enterprise/latest/topics/impala_schedule_random_replica.html
'Big DATA > Impala' 카테고리의 다른 글
| Impala - Statestore와 Coordinator간의 연결 불량 (0) | 2019.11.19 |
|---|---|
| [Impala JDBC 인증 설정] WAS에서 JDBC 연결 시 kerberos 통합? (0) | 2017.08.16 |
| Impala Timeout (0) | 2017.01.24 |
| Using Impala through a Proxy for High Availability (0) | 2017.01.24 |
| Components of the Impala Server (0) | 2017.01.16 |