AWS Athena Partition Projection 이란?

AWS Athena 사용중 Partition Projection을 통해 테이블 조회 쿼리 실행 시간이 3~5분에서 5초로 절감되는 케이스가 있었습니다. 오늘은 비교적 최근에 나온 이 기능에 대해 간단히 설명하는 포스팅입니다.

---

AWS S3에 적재된 대규모 로그 데이터를 쿼리하기 위해 AWS Athena에서 테이블을 생성해 S3의 경로를 지정하고 테이블을 만들어 쿼리하게 됩니다.

데이터의 양이 많은 경우 데이터 저장 방식을 Parquet로 개선하고, S3의 저장 경로를 Athena가 파티셔닝할 수 있게 Key에 Partition 구분자를 두어 쿼리가 실행될 때 Scan 되는 데이터의 양을 줄여 속도를 개선시키게 됩니다.

Athena Partition Doc : https://docs.aws.amazon.com/athena/latest/ug/partitions.html

Partitioning Data in Athena - Amazon Athena

이렇게 정의된 파티션은 AWS Glue나 Hive Metadata에서 테이블의 모든 파티션을 구성하는 S3 Key의 파일들을 매핑하게 되는데, 일반적인 상황보다 훨씬 고도로 세분화되고 장기적으로 누적된 거대한 파티션을 가진 테이블이 존재한다면 어떨까요?

s3://Bucket/LogName/LogType={LOGTYPE}/Year={YYYY}/Month={MM}/Day={DD}/Hour={HH} 형태로 쪼개어진 로그에 대한 파티셔닝 테이블이 존재한다고 가정합시다. 각 로그는 Parquet로 적재되며 시간당 수십MB에서 GB까지 적재되는 대형 로그라고 가정합니다.

예를들어 LogType이 100가지라면 로그가 1년 쌓이는 것으로 100 x 24 x 365 = 876,000개의 파티션이 테이블에 추가되어야 합니다.

하지만 AWS Athena는 Glue를 사용하는 경우 테이블당 최대 1천만개, 계정당 최대 2천만개까지만 허용합니다.
Glue를 사용하지 않는 경우는 고작 테이블당 2만개만 허용됩니다. Quota 증가를 요청하 수 있지만 이 역시 무한대로 늘려주지 않습니다.

파티션은 단순히 수량에만 제한이 있는것이 아니라 이렇게 거대한 파티셔닝 테이블은 파티션 메타데이터에 엑세스하는것부터 Athena 쿼리 실행 속도에 크게 악영향을 끼칩니다.

위의 예로든것 같은 테이블은 1시간의 단일 파티션만 검색하는 단순 SELECT 쿼리에서는 실행시간이 10초이내에 수행되었지만, 동일한 검색조건에 단순히 Partition Key의 범위를 5시간으로 넓히는 것 만으로 수행시간이 5분으로 증가하게 됩니다. 재미있게도, 1시간 범위 쿼리를 UNION으로 묶어 5시간을 조회하면 역시 10초만에 수행됩니다. 쿼리는 느려짐이 Log 파일의 Read량과 관계가 없다는 의미가 됩니다.

우리는 이런 문제점을 해결해야 합니다.

AWS에서는 2020년 6월 Athena에 Projection Partition이라는 새 기능을 발표했습니다.
https://aws.amazon.com/ko/about-aws/whats-new/2020/06/amazon-athena-supports-partition-projection/

Amazon Athena, Partition Projection 지원 추가

프로젝션 파티션은 간단히 말해, S3의 Key에 Placeholder를 사전에 구성해 테이블의 파티션을 생성하는 기능입니다. 쿼리를 사용할 때 사전에 추가된 파티션 메타데이터에서 S3 파일을 찾아 읽는것이 아닌, Key의 Placeholder 부분에 해당하는 조건절을 구문 분석해 즉시 Key에 접근해 파일을 읽습니다.

따라서 방대한 규모의 파티셔닝이라도 파일을 읽는것이 오래걸리고 느릴 뿐이지 메타데이터를 사용하지 않기 때문에 파티션 제약에서 자유롭습니다. 또한 파티션을 추가하는 행위나 Batch도 필요 없어집니다.

우리는 단순히 프로젝션 파티션을 명시하는 TBLPROPERTIES를 추가한 테이블을 생성하는것 만으로 1초만에 3~5분이 걸리던 쿼리가 5초가 되는 것을 보았습니다. 이런 테이블은 파일을 매핑하는 파티셔닝 과정도 없기 때문에 테이블 생성 쿼리 즉시 테이블이 생성되며 바로 SELECT 쿼리가 동작하게 됩니다.

단, 제약조건 역시 까다로운 편인데 공식 문서는 다음과 같이 제약에 대해서도 설명하고 있으니 숙지하여 사용할지 말지를 결정해야 합니다.

---

고려 사항 및 제한 사항

다음 고려 사항이 적용됩니다.

• 파티션 프로젝션을 사용하면 AWS Glue 또는 외부 Hive 메타스토어에서 수동으로 파티션을 지정할 필요가 없습니다.
• 테이블에서 파티션 프로젝션을 활성화하면 Athena는 AWS Glue 데이터 카탈로그 또는 해당 테이블에 대한 외부 Hive 메타스토어의 파티션 메타데이터를 무시합니다.
• Amazon S3에 투영된 파티션이 없는 경우 Athena는 여전히 파티션을 투영합니다. Athena는 오류를 발생시키지 않지만 데이터는 반환되지 않습니다. 그러나 너무 많은 파티션이 비어 있으면 기존 AWS Glue 파티션에 비해 성능이 느려질 수 있습니다. 예상 파티션의 절반 이상이 비어 ​​있는 경우 기존 파티션을 사용하는 것이 좋습니다.
• 파티션 프로젝션에 대해 정의된 범위 범위를 벗어난 값에 대한 쿼리는 오류를 반환하지 않습니다. 대신 쿼리가 실행되지만 0개의 행을 반환합니다. 예를 들어 2020년에 시작하고 로 정의된 시간 관련 데이터가 'projection.timestamp.range'='2020/01/01,NOW'있는 경우 와 같은 쿼리 는 성공적으로 완료되지만 0개의 행을 반환합니다. SELECT * FROM table-name WHERE timestamp = '2019/02/02'
• 파티션 프로젝션은 Athena를 통해 테이블을 쿼리할 때만 사용할 수 있습니다. Amazon Redshift Spectrum 또는 Amazon EMR과 같은 다른 서비스를 통해 동일한 테이블을 읽는 경우 표준 파티션 메타데이터가 사용됩니다.
• 파티션 프로젝션은 DML 전용 기능이므로 SHOW PARTITIONS Athena에서 프로젝션했지만 AWS Glue 카탈로그 또는 외부 Hive 메타스토어에 등록되지 않은 파티션을 나열하지 않습니다.
• Athena는 보기의 테이블 속성을 파티션 투영을 위한 구성으로 사용하지 않습니다. 이 제한을 해결하려면 보기가 참조하는 테이블의 테이블 속성에서 파티션 프로젝션을 구성하고 활성화하십시오.

---

프로젝션 파티션 생성 방법은 다음 문서에 설명되어 있습니다. Create External Table로 직접 TBLPROPERTIES에 지정해 설정해줄 수도 있습니다.

https://docs.aws.amazon.com/athena/latest/ug/partition-projection-setting-up.html

Setting up Partition Projection - Amazon Athena

이 외에도 Dynamic ID 라는 특수한 프로젝션 파티션도 있는데 이건 열거형이나 숫자, 날짜와 같이 사전에 예측가능한 파티션이 아닌, 유져 ID나 UUID등과 같이 고유한 값으로 생성되는 Key에 적재된 파일을 찾아 쿼리하기 위한 파티션이며 이것을 사용하는 경우 SELECT 쿼리에도 크게 제약이 생기긴 하지만 상황에 따라 유용하게 사용이 가능합니다.