Presto Query 최적화

1. Select 문 최적화 - 필요한 컬럼만 사용, 와일드 카드(*) 사용 금지

2. Group by 최적화 - 카디널리티(Cardinality)가 큰 컬럼 순서대로 선언

• Group By를 한 컬럼을 기반으로, 행들을 워커 노드에 배포합니다. 이 때, 카디널리티가 높은(=컬럼에 중복되는 값이 적은) 순서대로 컬럼을 선언하면, 행들을 더 고르게 워커에 배포하게 되어 성능 향상을 기대할 수 있습니다. 또한, Group by 절에 문자열 대신 숫자를 사용하면 메모리를 적게 사용해서 성능 향상을 기대할 수 있습니다.

3. Order by 최적화 - LIMIT 절을 함께 사용

• Order by를 사용하면 모든 행을 1개의 워커노드에 전송하여 정렬을 수행해야하므로 메모리 부담이 될 수 있습니다. 보통 Order by는 상위 or 하위 N개를 조회할 때 사용하므로, LIMIT 절을 사용하면 정렬 작업이 각각 워커노드에서 수행된 이후에 1개의 워커노드로 모이기 때문에 정렬 비용을 크게 줄일 수 있습니다.

4. Join 최적화 - 큰 테이블을 Join 왼쪽에 선언

• Presto는 Join은 기본적으로 Broad Cast Join입니다. 이는, 오른쪽 테이블은 모든 워커노드에 복사하여 배포하고, 왼쪽 테이블를 스트리밍하여 조인을 수행합니다. 따라서, 오른쪽에 등장하는 테이블 크기가 작을 수록, 메모리 사용이 적어지고 조회가 더 빨리 수행됩니다.

5. Join 최적화(2) - distributed hash join 사용

• Distributed Hash Join은 Join 왼쪽, 오른쪽 테이블이 둘다 커서 'Exceeded max memory xxGB'오류가 표시될 때 사용하면 좋습니다. 이 Join 방법은 왼쪽, 오른쪽 테이블 전부를 Join key의 해시값을 기준으로 나누어 워커노드에 배포합니다. 따라서, 메모리 오류를 해결할 수도 있습니다. 다만, 네트워크를 통해 전송되는 데이터 수가 많아짐으로, 느려질 수는 있습니다.

6. 근사 함수 사용 최적화 - distinct 대신 approx_distinct 사용

• 정확한 값이 필요하지 않을 때, 근사 함수를 사용하면 성능을 개선할 수 있습니다. approx_distinct 경우 전체 문자열 대신 값의 고유 해시를 계산하여 메모리 사용을 최소화하고 유일한 값을 계산합니다. 단, 단점은 2.3%의 표준 오류가 있다는 것입니다.

7. Like 최적화 - LIKE 여러개 대신 Regexp_like 사용

• 일반적으로 Like를 여러 번 사용하는 것보다, Regexp_like를 사용하는 것이 빠릅니다.

 

참조 : https://aws.amazon.com/ko/blogs/korea/top-10-performance-tuning-tips-for-amazon-athena/