Athena 2편: 성능 최적화 가이드, 비용도 줄이고 속도도 높이자!

AWS Athena는 매우 유용하지만, 무턱대고 사용하면 느려지고 비용도 올라갑니다. Athena는 스캔한 데이터 양을 기준으로 과금하기 때문에, 성능을 최적화하는 것이 곧 비용을 절감하는 길입니다.

이 글에서는 Athena의 쿼리 성능을 높이고, 비용까지 아낄 수 있는 실전 팁을 정리해보겠습니다.

---

1. Parquet, ORC 같은 컬럼 기반 포맷 사용하기

Athena는 CSV나 JSON도 읽을 수 있지만, Parquet 또는 ORC처럼 컬럼 저장 형식을 사용하면 훨씬 빠르고 경제적입니다.

• 장점:
  • 필요한 컬럼만 읽기 때문에 데이터 스캔량 대폭 감소
  • 기본적으로 압축됨
• 변환 방법:
  • Glue ETL 또는 Spark, Pandas 등으로 변환 후 S3 저장

---

2. 파티셔닝 전략 수립하기

S3 내 데이터를 폴더 구조로 나누는 파티셔닝은 Athena 쿼리 성능에 직접적인 영향을 줍니다.

s3://my-logs/year=2024/month=04/day=01/

• 쿼리 예:

SELECT * FROM logs
WHERE year = '2024' AND month = '04';

• 파티션 조건이 쿼리에 포함되어야만 효과가 있습니다.
• Glue 크롤러로 파티션 자동 인식 가능

---

3. unnecessary SELECT * 피하기

필요한 컬럼만 명시적으로 선택하세요. Athena는 SELECT * 로 모든 컬럼을 읽으면 불필요한 I/O 비용이 커집니다.

---

4. 쿼리 결과 저장 위치 설정

Athena는 쿼리 결과를 기본적으로 S3에 저장합니다.

• 저장 위치는 설정 가능하며, **주기적 정리 또는 수명 주기 정책(Lifecycle)**을 설정하는 것이 좋습니다.

---

5. Glue Data Catalog 적극 활용

• 데이터에 대한 스키마를 명확히 정의하면 쿼리 성능 향상
• 파티션 변경 시 MSCK REPAIR TABLE 또는 Glue 크롤러 활용

---

6. 뷰(View) 대신 테이블로 최적화

Athena에서 뷰는 편하지만, 복잡한 뷰는 내부적으로 서브쿼리처럼 작동하므로 성능에 불리할 수 있습니다.

• 가능하다면 결과를 Parquet로 저장해 테이블화하는 것이 훨씬 효율적입니다.

---

7. CTAS (CREATE TABLE AS SELECT) 활용

복잡한 쿼리를 반복 실행하는 대신, 한 번 실행해 결과를 테이블로 저장해두는 방식입니다.

CREATE TABLE new_logs
WITH (format = 'PARQUET') AS
SELECT url, count(*) as cnt
FROM logs
GROUP BY url;

---

마무리

Athena는 사용하기 쉬운 만큼, 성능 튜닝을 소홀히 하면 비용이 기하급수적으로 증가할 수 있습니다. 위에서 소개한 팁을 적용하면 분석 속도는 빨라지고, 비용은 줄어드는 경험을 하게 될 거예요.

다음 글에서는 Glue 크롤러와 Glue 테이블을 연동하여 자동화된 데이터 분석 환경을 구축하는 방법을 소개하겠습니다.

 

1편: https://carpe08.tistory.com/451

3편: https://carpe08.tistory.com/453