athena 튜닝 포인트
사내에서 모처럼 AWS SA를 초청하여 Athena에 대한 Session을 듣고 성능 개선에 대한 노하우를 들었다. 중간에 회의가 있어서 나갔다 오긴 했지만 핵심적인 내용들은 아래와 같아서 메모해 두었다.
Athena와 같은 serverless 서비스들은 그들이 만든 방식대로 사용해야지 가장 효율적이라고 생각한다. 특히나 Hadoop 기반의 파일 시스템 위에서 돌아가는 Data Lake 기반의 SQL 엔진 서비스들을 기존의 방식대로만 쓰면서 "왜 RDS 처럼 빠르게 조회가 되지 않지?" 라고 생각하는 것은 소모적인 일이다.
- 파티션 최하위의 파일 크기를 적절하게 유지해야한다.
- 파일이 너무 많으면 IO 네트워크 자체에 시간이 많이 걸리므로 예를 들어서 파일 숫자가 수 억개가 되면 당연히 느려질 수 밖에 없다.
- 파티션이 1억개라면 파티션을 where 조건에 걸더라도 우선 파티션을 찾아다닌 끝에 파일을 작은 파일들ㅇ르 읽어와야 한다.
- 왼쪽에 큰 테이블을 두자.
- athena가 노드를 할당할 때 왼쪽 테이블을 기준으로 sizing을 한다고 한다. 따라서 작은 테이블이 왼쪽에 있으면 node 사이즈가 작은 것이다.
- 파티션은 int 타입이 좋다.
- athena는 파티션을 스캔할 때 min, max를 기준으로 줄을 세운다. 그래서 예를 들어서 보통 파티션에 많이 쓰이는 연-월-일 등도 string 보다는 int로 만들어두는게 좋다. string이라면 이런 min, max가 효율적으로 먹히지 않을 것이기 때문이다.
- index를 확인하자.
- index 기준으로 scan을 할 것이기 때문에 index가 없다면 index를 잡아주자. 이것은 Glue Catalog에서 잡을 수 있다. 보통 파티션을 이용해서 index를 잡는데, 파티션의 level의 순서를 고려해서 자주 접근하는 단위에서 index를 잡아주는게 좋은 practice이다.
- 불필요한 where 조건은 우선 생략하자.
- 결국 where 조건이 늘어난다는 것은 scan 양이 늘어난다는 것이다. 가능하다면 python 같은 runtime 환경으로 athena 결과물을 가져와서 (awswrangler 를 이용하면 된다) 좀 더 복잡한 조작은 프로그램 안에서 진행하는 것도 고육지책 중에 하나라고 할 수 있다.
적용 후기
-
위 방식 중에서 두 가지를 써보았는데 약간의 개선이 느껴졌다. 하나는 파티션을 int로 타입 캐스팅을 해주어봤고, 그 다음은 큰 테이블을 왼쪽에 두어봤다. join 이나 from 절에서 왼쪽에 위치시켰다. 수치로 증명할 시간까지 되지는 않았지만 약간 빠르다는 생각이 들었다.
-
full scan 을 하는지 하지 않는지도 속도에 중요한 영향을 미친다. 즉, partition이나 index 레벨에서 데이터를 가져온 뒤에 또 다른 where 조건 (예를 들면, 값에 대하여 이상 이하를 filter 한다던지, 동일한 값으로 찾는 조건을 건다던지)가 추가되면 그것은 full scan을 수행해야 한다는 뜻이다. 만약 full scan을 함으로써 시간이 지나치게 증가된다면 where 조건은 partition과 index에 사용된 column 만 사용한 후, python과 같은 프로그램으로 추가 가공하는 것을 권장한다.
-
요즘 우리 팀에서 관리하는 s3 + Glue + Athena가 파티션 과대 문제로 실제로 쓰기가 어려워진 상태가 되었는데, 지금 단계에서 운영되는 파일들을 재조정하기는 어려우므로 지금부터 쌓이는 데이터들을 다른 catalog의 새로운 테이블로 옮겨서 가벼운 파티션 구조를 가져가면 어떨까 한다. 그렇게 해본 뒤 성능 차이가 확인되면 기록해보려고 한다.
