※ CDH6 Impala Docs의 Understanding Impala Query Performance 를 번역하였습니다.
Intro
Impala 쿼리에 대한 높은 수준의 성능 고려 사항을 이해하려면, 쿼리에 대한 EXPLAIN 문의 출력을 읽으세요. 실제로 쿼리 자체를 실행하지 않고도 EXPLAIN 계획을 얻을 수 있습니다.
쿼리의 physical performance 특성에 대한 개요를 보려면, 쿼리 실행 직후 impala-shell에서 SUMMARY 문을 실행하십시오. 이 요약된 정보는 가장 많은 시간이 소요된 실행 단계와 각 단계의 메모리 사용량 및 행 수에 대한 추정치를 실제 값과 비교하는 방법을 보여줍니다.
쿼리에 대한 자세한 성능 특성을 이해하려면 쿼리 실행 직후 impala-shell에서 PROFILE 문을 실행하십시오. 이 저수준 정보에는 메모리, CPU, I/O 및 네트워크 사용량 에 대한 물리적 세부 정보가 포함되므로 쿼리가 실제로 실행된 후에만 사용할 수 있습니다.
Using the EXPLAIN Plan for Performance Tuning
EXPLAIN 문은 node 간에 작업을 분산하는 방법과 중간 결과를 결합하여 최종 결과 집합을 생성하는 방법과 같이 쿼리가 수행할 논리적 단계에 대한 개요를 제공합니다. 쿼리를 실제로 실행하기 전에 이러한 세부 정보를 볼 수 있습니다. 이 정보를 사용하여 쿼리가 매우 예기치 않거나 비효율적인 방식으로 작동하지 않는지 확인할 수 있습니다.
[impalad-host:21000] > explain select count(*) from customer_address;
+----------------------------------------------------------+
| Explain String |
+----------------------------------------------------------+
| Estimated Per-Host Requirements: Memory=42.00MB VCores=1 |
| |
| 03:AGGREGATE [MERGE FINALIZE] |
| | output: sum(count(*)) |
| | |
| 02:EXCHANGE [PARTITION=UNPARTITIONED] |
| | |
| 01:AGGREGATE |
| | output: count(*) |
| | |
| 00:SCAN HDFS [default.customer_address] |
| partitions=1/1 size=5.25MB |
+----------------------------------------------------------+
아래에서 위로 EXPLAIN 계획을 읽으십시오.
- 계획의 마지막 부분은 읽을 예상 데이터 양과 같은 낮은 수준의 세부 정보를 보여줍니다. 여기에서 분할 전략의 효율성을 판단하고 총 데이터 크기와 클러스터의 크기를 기반으로 테이블을 스캔하는 데 걸리는 시간을 예측할 수 있습니다.
- 위로 올라가면서 병렬화되고 각 Impala 노드에서 수행되는 작업을 볼 수 있습니다.
- 상위 수준에서는 중간 결과 집합이 결합되어 한 노드에서 다른 노드로 전송될 때 데이터가 어떻게 흐르는지 볼 수 있습니다.
- EXPLAIN_LEVEL 쿼리 옵션에 대한 자세한 내용은 EXPLAIN_LEVEL 쿼리 옵션을 참조하세요. 이 옵션을 사용하면 쿼리의 논리적 또는 물리적 측면을 처리하는 상위 수준 또는 하위 수준 조정을 수행하는지 여부에 따라 EXPLAIN 계획에 표시할 세부 정보의 정도를 사용자 지정할 수 있습니다.
EXPLAIN 계획은 쿼리의 logical 측면과 physical 측면을 나란히 검사하는 데 편의를 위해 성능 조정을 위한 Using the Query Profile for Performance Tuning에도 나옵니다.
EXPLAIN 출력에 표시되는 세부 정보의 양은 EXPLAIN_LEVEL 쿼리 옵션에 의해 제어됩니다. 성능 조정 중에 테이블 및 열 통계의 존재를 다시 확인하거나 CDH 5의 리소스 관리 기능과 함께 쿼리 리소스 사용량을 추정할 때 일반적으로 이 설정을 표준에서 확장으로(또는 1에서 2로) 늘립니다.
Using the SUMMARY Report for Performance Tuning
impala-shell 인터프리터 내의 SUMMARY 명령은 쿼리 실행의 여러 단계에 대한 타이밍에 대한 개요를 쉽게 요약할 수 있도록 합니다. EXPLAIN 계획과 마찬가지로 잠재적인 성능 병목 현상을 쉽게 볼 수 있습니다. PROFILE 출력과 마찬가지로 쿼리가 실행된 후에 사용할 수 있으므로 실제 타이밍 번호가 표시됩니다.
SUMMARY 보고서는 쿼리의 high-level 및 low-level 측면을 나란히 검사하는 데 편의를 위해 성능 조정을 위한 Using the Query Profile for Performance Tuning에도 나옵니다.
예를 들어 다음은 단일 노드 VM에서 집계 함수와 관련된 쿼리입니다. 쿼리의 여러 단계와 해당 타이밍이 쿼리 계획에 사용된 예상 값과 실제 값과 함께 표시됩니다(모든 노드에 대해 롤업됨). 이 경우 AVG() 함수는 각 노드의 데이터 하위 집합에 대해 계산된 다음(단계 01) 모든 노드의 집계 결과가 끝에서 결합됩니다(단계 03). 가장 많은 시간이 소요된 단계와 추정치가 실제 데이터 분포와 크게 다른지 여부를 확인할 수 있습니다. (시간 값을 검사할 때 가장 큰 숫자를 찾는 것보다 마이크로초의 경우 us, 밀리초의 경우 ms와 같은 접미사를 고려하십시오.)
[localhost:21000] > select avg(ss_sales_price) from store_sales where ss_coupon_amt = 0;
+---------------------+
| avg(ss_sales_price) |
+---------------------+
| 37.80770926328327 |
+---------------------+
[localhost:21000] > summary;
+--------------+--------+----------+----------+-------+------------+----------+---------------+-----------------+
| Operator | #Hosts | Avg Time | Max Time | #Rows | Est. #Rows | Peak Mem | Est. Peak Mem | Detail |
+--------------+--------+----------+----------+-------+------------+----------+---------------+-----------------+
| 03:AGGREGATE | 1 | 1.03ms | 1.03ms | 1 | 1 | 48.00 KB | -1 B | MERGE FINALIZE |
| 02:EXCHANGE | 1 | 0ns | 0ns | 1 | 1 | 0 B | -1 B | UNPARTITIONED |
| 01:AGGREGATE | 1 | 30.79ms | 30.79ms | 1 | 1 | 80.00 KB | 10.00 MB | |
| 00:SCAN HDFS | 1 | 5.45s | 5.45s | 2.21M | -1 | 64.05 MB | 432.00 MB | tpc.store_sales |
+--------------+--------+----------+----------+-------+------------+----------+---------------+-----------------+
쿼리의 가장 긴 초기 단계가 초(s) 단위로 측정되는 반면, 더 작은 중간 결과에 대해 작업하는 나중 단계는 밀리초(ms) 또는 나노초(ns)로 측정됩니다. 다음은 PROFILE 출력에 표시되는 보다 복잡한 쿼리의 예입니다.
Operator #Hosts Avg Time Max Time #Rows Est. #Rows Peak Mem Est. Peak Mem Detail
------------------------------------------------------------------------------------------------------------------------
09:MERGING-EXCHANGE 1 79.738us 79.738us 5 5 0 -1.00 B UNPARTITIONED
05:TOP-N 3 84.693us 88.810us 5 5 12.00 KB 120.00 B
04:AGGREGATE 3 5.263ms 6.432ms 5 5 44.00 KB 10.00 MB MERGE FINALIZE
08:AGGREGATE 3 16.659ms 27.444ms 52.52K 600.12K 3.20 MB 15.11 MB MERGE
07:EXCHANGE 3 2.644ms 5.1ms 52.52K 600.12K 0 0 HASH(o_orderpriority)
03:AGGREGATE 3 342.913ms 966.291ms 52.52K 600.12K 10.80 MB 15.11 MB
02:HASH JOIN 3 2s165ms 2s171ms 144.87K 600.12K 13.63 MB 941.01 KB INNER JOIN, BROADCAST
|--06:EXCHANGE 3 8.296ms 8.692ms 57.22K 15.00K 0 0 BROADCAST
| 01:SCAN HDFS 2 1s412ms 1s978ms 57.22K 15.00K 24.21 MB 176.00 MB tpch.orders o
00:SCAN HDFS 3 8s032ms 8s558ms 3.79M 600.12K 32.29 MB 264.00 MB tpch.lineitem l
Using the Query Profile for Performance Tuning
impala-shell 인터프리터에서 사용할 수 있는 PROFILE 명령은 가장 최근 쿼리가 실행된 방법을 보여주는 상세한 저수준 보고서를 생성합니다. 성능 조정을 위한 EXPLAIN 계획 사용에서 설명한 EXPLAIN 계획과 달리 이 정보는 쿼리가 완료된 후에만 사용할 수 있습니다. 각 노드에 대해 읽은 바이트 수, 최대 메모리 사용량 등과 같은 물리적 세부 정보를 보여줍니다. 이 정보를 사용하여 쿼리가 I/O 바운드인지 CPU 바운드인지, 일부 네트워크 조건에서 병목 현상이 발생하는지 여부, 속도 저하가 일부 노드에는 영향을 미치고 다른 노드에는 영향을 미치지 않는지 여부를 확인하고 다음과 같은 권장 구성 설정을 확인할 수 있습니다. 단락 로컬 읽기가 적용됩니다.
기본적으로 프로필 출력의 시간 값은 작업에 소요된 wall-clock 시간을 반영합니다. 시스템 시간 또는 사용자 시간을 나타내는 값의 경우 측정 단위가 ScannerThreadsSysTime 또는 ScannerThreadsUserTime과 같은 메트릭 이름에 반영됩니다. 예를 들어, 다중 스레드 I/O 작업은 wall-clock 시간에 대해 작은 숫자를 표시할 수 있지만 해당 시스템 시간은 각 스레드가 소요한 CPU 시간의 합계를 나타내는 더 큰 값을 나타낼 수 있습니다. 또는 wall-clock 시간 수치는 대기 시간을 계산하기 때문에 더 클 수 있지만 해당 시스템 및 사용자 시간 수치는 작업이 CPU 주기를 적극적으로 사용하는 동안만 시간을 측정합니다.
'개발 > Hadoop eco-system' 카테고리의 다른 글
| [Hadoop] HiveServer2 (0) | 2023.01.13 |
|---|---|
| [HBase] Online Region Merge와 Empty Region Merge에 대해 (0) | 2022.06.30 |
| CDH6 HBase2 X Impala2 쿼리 튜닝 (0) | 2021.11.11 |
| Spark 3.0 한 번에 정리하기 (0) | 2020.12.04 |
| Apache Hadoop (v1 특징, v2 특징, yarn 아키텍처, HDFS, 맵리듀스) (1) | 2020.11.24 |
댓글