Athena는 S3에 있는 데이터를 바로 SQL로 질의하는 완전관리형(Serverless) 쿼리 서비스. 클러스터 만들 필요 없고, 스캔한 데이터 양만큼 과금되며, Glue Data Catalog의 스키마를 읽어 schema-on-read 방식으로 동작
1) 언제 쓰나요?
- 로그/이벤트/CSV/JSON/Parquet 같은 파일이 S3에 쌓여 있고, 그걸 즉석 분석하고 싶을 때
- ETL 없이 빠르게 Ad-hoc 분석/리포팅이 필요할 때
- 대시보드(QuickSight) 의 데이터 소스로 가볍게 쓰고 싶을 때
- 운영 DB에 부담 주지 않고 대용량 조회/탐색할 때
2) 핵심 개념 3가지
- S3 Data Lake: 원천 데이터는 S3에 그대로 저장.
- Glue Data Catalog: 테이블/컬럼 같은 메타데이터(스키마) 저장소. Athena가 여기 정의를 보고 파일을 읽는다.
- Schema-on-read: 파일을 읽을 때 스키마를 적용(변환/적재 없이 바로 SQL).
Athena 엔진은 Presto/Trino 계열이라 표준 ANSI SQL을 대부분 사용 가능
3) 비용 구조
-
쿼리 1번마다 스캔한 데이터 바이트 기준으로 과금(리전별 단가 상이).
-
스캔량 줄이는 게 = 비용/성능 최적화의 전부라고 봐도 돼요:
- 열 지향 포맷(Parquet/ORC) 사용
- 압축(ZSTD/Snappy) 적용
- Partitioning(예:
dt=YYYY-MM-DD,region=KR) - Projection/Predicate로 필요한 파티션/컬럼만 읽기
4) 자주 쓰는 기능
- 표준 SQL: JOIN/Window/CTE/서브쿼리 지원
- CTAS / INSERT INTO / UNLOAD: 쿼리 결과를 Parquet 등으로 S3에 저장(간단 ETL)
- View/Materialized View: 재사용/가속
- Partition 관리:
ALTER TABLE ADD PARTITION,MSCK REPAIR TABLE, Partition Projection(동적 파티션) - Federated Query: 커넥터로 RDS, DynamoDB 등 외부 데이터소스도 SQL로 질의
- Apache Iceberg 테이블 지원: 데이터 레이크에서 ACID/증분에 유리
5) 5분 퀵스타트
-
S3에 샘플 로그(예:
s3://my-bucket/logs/dt=2025-10-10/...) 업로드 -
콘솔의 Athena → Query editor에서 Workgroup과 Query result location(S3) 설정
-
테이블 생성(DDL): (Glue에 등록)
CREATE EXTERNAL TABLE logs ( ts string, user_id string, action string, meta map<string,string> ) PARTITIONED BY (dt string) STORED AS PARQUET LOCATION 's3://my-bucket/logs/'; -
파티션 로드
MSCK REPAIR TABLE logs; -- 또는 ALTER TABLE logs ADD PARTITION (dt='2025-10-10') LOCATION 's3://.../dt=2025-10-10/'; -
질의
SELECT dt, action, count(*) AS cnt FROM logs WHERE dt BETWEEN '2025-10-01' AND '2025-10-10' GROUP BY 1,2 ORDER BY 1,2;
6) 성능/비용 최적화 치트시트
- 열 지향 포맷: CSV/JSON → Parquet/ORC로 바꾸면 스캔량이 수~십배 감소
- 컬럼 프루닝:
SELECT *금지, 필요 컬럼만 선택 - 파티션 프루닝:
WHERE dt='2025-10-10'처럼 파티션 키에 조건 걸기 - 작은 파일 병합: 수백만 개 소파일 대신 수십~수백 MB 단위로 묶기
- CTAS/INSERT INTO로 정규화/필드 정리/압축된 테이블 재작성
- Workgroup 쿼터: 스캔 바이트 한도와 ACL로 비용 통제
- Result Reuse/캐시(가능한 경우): 같은 쿼리 반복 비용 절감
7) 보안/거버넌스
- IAM + Lake Formation: DB/테이블/컬럼 단위 접근 제어
- 암호화: S3 객체 SSE-KMS, 쿼리 결과/스캔 임시파일 암호화
- 프라이빗 액세스: S3 VPC Gateway Endpoint로 사설 경로 사용
- 감사: CloudTrail(API), CloudWatch Logs(쿼리·실패 내역), S3 Access Logs 활용
8) 자주 만나는 함정
- 스키마/SerDe 불일치: 컬럼 타입이 실제 데이터와 다르면
HIVE_BAD_DATA등 에러 → 샘플링 후 정확히 매핑 - JSON 파싱: 라인 구분 JSON인지(한 줄 한 레코드) 확인. 중첩 JSON은
json_extract/json_extract_scalar, 가능하면 Parquet로 변환 - 파티션 누락: 새로운 경로를 만들었는데 조회가 안 되면 파티션 추가/REPAIR 필요
- 권한: 결과 버킷/데이터 버킷 권한 부족으로 실패하기 쉬움 → 버킷 정책/IAM 재확인
9) 다른 서비스와 비교
| 요구사항 | 추천 |
|---|---|
| 즉석 SQL, 운영 부담 0, 파일 기반 분석 | Athena |
| 페타바이트급 웨어하우스, 복잡 ETL/조인/머터뷰 | Redshift / Redshift Serverless |
| 파이프라인/머신러닝/대규모 변환 | EMR(Spark) |
| 검색/로그 탐색, 실시간 인덱싱 | OpenSearch Service |
10) 실전 패턴 예시
- 로그 분석 파이프라인: Firehose → S3(Partition/Parquet) → Athena → QuickSight
- 데이터 레이크 ETL: Athena CTAS로 정제 테이블 생성 → Glue Crawler/Jobs → 다운스트림
- 운영 통합 조회: Federated Query로 RDS/DynamoDB + S3를 한 번에 JOIN
11) 미니 레시피 모음
-
CSV → Parquet 변환(CTAS)
CREATE TABLE logs_parquet WITH ( format='PARQUET', write_compression='ZSTD', partitioned_by=ARRAY['dt'], external_location='s3://my-bucket/logs_parquet/' ) AS SELECT ts, user_id, action, meta, dt FROM logs WHERE dt >= '2025-10-01'; -
쿼리 결과 S3로 내보내기(UNLOAD)
UNLOAD (' SELECT user_id, count(*) AS cnt FROM logs WHERE dt = ''2025-10-10'' GROUP BY 1 ') TO 's3://my-bucket/export/users_20251010/' WITH (format='PARQUET');
요약
- 클러스터 없이 S3 데이터에 바로 SQL → 빠른 분석/운영 단순.
- 비용은 스캔량 기반이므로 Parquet/압축/파티션이 생명.
- Glue Catalog + Partition + CTAS 조합으로 가볍게도, 제법 탄탄하게도 데이터 레이크를 운영 가능
`•.¸¸.•´´¯`••._.• 🎀 𝒸𝓇𝒶𝓏𝓎 𝓅𝓈𝓎𝒸𝒽💞𝓅𝒶𝓉𝒽 🎀 •._.••`¯´´•.¸¸.•`