[analytics] Amazon Athena
데이터를 옮기지도, 서버를 띄우지도 않고 S3에 바로 SQL을 던지기. 그 편리함과 비용을 줄이는 요령.
One-Line Summary
Athena는 S3에 있는 데이터를 옮기거나 서버를 띄우지 않고, 표준 SQL로 바로 조회하는 서버리스 쿼리 서비스다. 시험에서는 서버리스 / S3 직접 SQL 조회 / 스캔한 데이터량만큼 과금 / Parquet·압축·파티셔닝으로 비용 절감 이 핵심이다. "S3 로그를 가끔·즉석에서 SQL로 분석"이면 Athena다.
Why It Exists
S3에 쌓인 로그·데이터를 분석하려고 매번 데이터베이스로 로드하거나 클러스터를 세우는 것은 과하다. 특히 간헐적·즉석(ad-hoc) 분석에는 상시 인프라가 낭비다.
Athena는 S3를 그 자리에서(in place) SQL로 조회하게 한다. 인프라가 없다.
S3의 로그/CSV/JSON/Parquet
-> (Glue Data Catalog에 테이블 정의)
-> Athena에서 표준 SQL 실행 -> 결과 즉시 반환
과금 = "쿼리가 스캔한 데이터량"
시험 감각:
"S3 데이터를 서버 없이 SQL로 즉석 분석 / 인프라 관리 없이" = Athena.
Abbreviations
| 약어 | 풀네임 | 의미 |
|---|---|---|
Athena | Amazon Athena | S3를 SQL로 조회하는 서버리스 쿼리 서비스(Presto/Trino 기반) |
Presto/Trino | Distributed SQL engine | Athena가 내부적으로 쓰는 분산 SQL 엔진 |
Parquet/ORC | Columnar format | 스캔량을 줄여주는 열 기반 저장 포맷 |
Partition | Partition | 날짜 등으로 S3 경로를 나눠 스캔 범위를 좁히는 구조 |
과금과 비용 최적화 (아주 빈출)
Athena는 쿼리가 스캔한 데이터량(TB) 에 따라 과금된다. 따라서 스캔량을 줄이는 것이 곧 비용 절감이며, 시험에 반복 출제된다.
| 최적화 기법 | 효과 |
|---|---|
| 열 기반 포맷(Parquet/ORC) | 필요한 컬럼만 읽어 스캔량 대폭 감소 |
| 압축(GZIP/Snappy) | 읽는 바이트 감소 |
| 파티셔닝(예: 연/월/일) | 조건에 맞는 파티션만 스캔 |
| 파일 크기 적정화 | 너무 작은 파일 다수는 비효율 |
JSON 원본 전체 스캔 -> 비쌈/느림
같은 데이터를 Parquet + 날짜 파티션 -> 필요한 컬럼·파티션만 스캔 -> 저렴/빠름
시험 감각:
"Athena 쿼리 비용/속도를 개선" = Parquet 변환 + 파티셔닝 + 압축.
Glue Data Catalog와의 관계
Athena는 테이블 스키마를 Glue Data Catalog에서 가져온다. Glue Crawler로 스키마를 자동 등록하면 Athena가 바로 조회한다.
Glue Crawler -> Data Catalog(테이블 정의) -> Athena가 SQL로 조회
Athena vs Redshift (핵심 비교, 빈출)
| 구분 | Athena | Redshift |
|---|---|---|
| 모델 | 서버리스, 인프라 없음 | 프로비저닝된 데이터 웨어하우스(클러스터) |
| 데이터 위치 | S3 그 자리에서 조회 | 웨어하우스로 로드(또는 Spectrum으로 S3) |
| 적합 | 간헐적·즉석 쿼리, 로그 분석 | 빈번한·복잡한 분석 쿼리, BI 대시보드 |
| 과금 | 스캔한 데이터량 | 클러스터 상시 비용(또는 서버리스 RPU) |
시험 감각:
"가끔/즉석/서버리스" = Athena. "상시·복잡·고성능 분석(BI)" = Redshift.
Common Wrong Directions
| 오답 방향 | 왜 부족한가 |
|---|---|
| 즉석 S3 조회면 되는데 Redshift 클러스터 구축 | 상시 비용·운영 부담 → 간헐적이면 Athena |
| 비용 문제를 인스턴스 타입으로 해결하려 함 | Athena는 서버리스 → 비용은 스캔량(Parquet/파티셔닝)으로 |
| S3를 조회하려고 EMR/Glue Job 작성 | 단순 SQL 조회는 Athena |
| 스키마를 매번 수동 정의 | Glue Crawler + Data Catalog 연동 |
| 밀리초급 실시간 대시보드를 Athena로 | Athena는 조회형(초~) → 실시간 스트림은 Flink |
Exam Triggers
| 문제에서 이런 표현이 나오면 | 떠올릴 것 |
|---|---|
| "query data in S3 using standard SQL" | Athena |
| "serverless / no infrastructure to manage" | Athena |
| "occasional / ad-hoc / interactive queries" | Athena |
| "analyze logs stored in S3 (CloudTrail/ALB/VPC Flow Logs)" | Athena |
| "reduce query cost / scan less data" | Parquet + 파티셔닝 + 압축 |
| "frequent complex analytical queries, BI warehouse" | Athena 아님 → Redshift |
Memory Sentence
Athena는 S3를 서버 없이 표준 SQL로 즉석 조회하고, 스캔한 데이터량만큼 과금한다. 비용/속도 개선은 Parquet·파티셔닝·압축. 스키마는 Glue Data Catalog에서. 간헐적·즉석이면 Athena, 상시·복잡·고성능 분석이면 Redshift.
References
댓글
아직 댓글이 없습니다.