Athena 완벽 정리

"S3에 있는 데이터를 SQL로 바로 분석하고 싶다"는 시나리오가 나오면 무조건 Athena를 떠올리세요! 서버리스라 인프라 관리가 필요 없고, 스캔한 데이터 양만큼만 비용을 내는 것이 핵심입니다. 🚀

Amazon Athena 완전 정리 (DEA-C01 시험 핵심)

들어가며

DEA-C01 시험의 Domain 1: Data Ingestion and Transformation (34%) 과 Domain 3: Data Operations and Support (22%) 에서 자주 등장하는 서비스가 바로 Amazon Athena입니다.

"S3에 있는 데이터를 SQL로 바로 분석하고 싶다"는 시나리오가 나오면 Athena를 떠올리면 됩니다. 서버리스라 인프라 관리가 필요 없고, 스캔한 데이터 양만큼만 비용을 내는 것이 핵심입니다.

이 글에서는 시험 대비 관점에서 핵심 내용을 정리해보겠습니다.

---

Amazon Athena란?

Athena의 기본 개념부터 정리합니다.

| 항목 | 내용 | | --- | --- | | 정의 | S3 데이터를 표준 SQL로 분석하는 서버리스 인터랙티브 쿼리 서비스 | | 인프라 관리 | 불필요 (서버리스) | | 과금 방식 | 스캔한 데이터 TB당 $5.00 | | 쿼리 엔진 | Apache Presto 기반 | | 메타데이터 관리 | AWS Glue Data Catalog 연동 | | 시각화 통합 | Amazon QuickSight |

시험에서 자주 등장하는 핵심 포인트입니다.

"S3 데이터를 서버리스 SQL로 분석" → Amazon Athena 비용은 스캔한 데이터 양에 비례하므로 적게 스캔할수록 저렴합니다

---

지원 데이터 포맷과 비용 효율

Athena가 지원하는 포맷을 이해하면 비용 최적화 문제도 풀 수 있습니다.

| 포맷 | 유형 | 특징 | 비용 효율 | | --- | --- | --- | --- | | CSV / TSV | 행 기반 | 단순하고 범용적이지만 대용량에 비효율적 | 낮음 | | JSON | 반구조화 | 중첩 데이터 지원, 로그에 적합 | 낮음 | | Parquet | 컬럼 기반 | 컬럼 단위 스캔, 압축 효율 높음 | 높음 | | ORC | 컬럼 기반 | Parquet과 유사, 분할 처리 가능 | 높음 | | Avro | 행 기반 (분할 가능) | 스키마 진화 지원, 스트리밍 데이터에 적합 | 중간 |

시험에서 "Athena 비용을 줄이려면?"이라는 질문이 나오면 Parquet 또는 ORC 포맷이 정답입니다. 컬럼형 포맷은 쿼리에 필요한 컬럼만 스캔하므로 데이터 스캔량이 줄어들고 비용이 절감됩니다.

---

비용 최적화 5가지 전략

Athena 비용 최적화는 시험에 자주 출제되는 시나리오 주제입니다.

| 전략 | 설명 | | --- | --- | | 컬럼형 포맷 사용 | Parquet이나 ORC로 변환하여 필요한 컬럼만 스캔 | | 데이터 압축 | 압축 적용 시 스캔 데이터 양 감소 | | 파티셔닝 | S3 데이터를 날짜, 지역 등으로 파티션 분리하여 관련 파티션만 스캔 | | CTAS | SELECT 결과로 새 테이블 생성하여 CSV를 Parquet으로 변환하거나 요약 테이블 생성 | | 쿼리 결과 재사용 | 동일 쿼리 결과를 캐싱하고 재활용하여 재스캔 방지 |

시험에서 비용 절감 시나리오가 나오면 파티셔닝 + Parquet 포맷 + 데이터 압축 조합이 자주 정답입니다.

!Athena 비용 최적화 전략 5가지

AWS Glue와의 연동

Athena와 Glue의 일반적인 연동 패턴입니다.

주요 특징은 다음과 같습니다.

Glue Crawler가 S3를 스캔하여 테이블 스키마를 자동 생성 Athena는 Glue Data Catalog를 메타데이터 저장소로 활용 S3에 새 파티션이 직접 추가됐을 때는 MSCK REPAIR TABLE 명령으로 메타데이터를 동기화

Athena와 Glue Data Catalog의 조합은 AWS의 표준 서버리스 데이터 레이크 쿼리 패턴입니다.

---

Workgroups를 통한 비용 제어와 접근 관리

Workgroup은 쿼리 실행을 논리적 그룹으로 분리하여 관리하는 기능입니다.

| 기능 | 내용 | | --- | --- | | 쿼리 히스토리 분리 | 팀이나 부서별 쿼리 이력 격리 | | 비용 제어 | 워크그룹별 스캔 데이터 한도 설정으로 초과 시 자동 쿼리 중단 | | 접근 권한 관리 | IAM과 연동하여 워크그룹별 사용자 권한 제어 | | 비용 배분 | 부서별 쿼리 비용 추적 가능 |

시험에서 "팀별 Athena 비용을 제한하고 싶다"는 시나리오가 나오면 Workgroup에서 스캔 데이터 한도를 설정하는 것이 정답입니다.

---

Federated Query로 여러 데이터 소스 쿼리

Federated Query를 사용하면 S3뿐만 아니라 다양한 AWS 데이터 소스를 단일 SQL로 쿼리할 수 있습니다.

지원 데이터 소스로는 Amazon RDS, Redshift, DynamoDB, S3 등이 있습니다.

주요 특징은 다음과 같습니다.

ETL 없이 여러 소스를 조인하고 분석 가능 SQL 및 PartiQL 사용 Lambda 기반의 데이터 소스 커넥터로 구현

시험에서 "복잡한 ETL 없이 여러 DB를 SQL로 분석"하는 시나리오가 나오면 Athena Federated Query가 정답입니다.

---

ACID 트랜잭션과 Apache Iceberg

Athena는 ACID 트랜잭션을 지원합니다.

| 기능 | 내용 | | --- | --- | | ACID 지원 | INSERT, UPDATE, DELETE, MERGE 작업의 데이터 일관성 보장 | | 구현 방식 | AWS Glue Data Catalog + Apache Iceberg 테이블 포맷 | | 시간 여행 | 특정 시점의 데이터 조회 가능 | | 스키마 진화 | 진행 중인 쿼리 중단 없이 스키마 변경 가능 | | 데이터 최적화 | OPTIMIZE 명령으로 소형 파일 병합하여 성능 유지 |

시험에서 Athena에서 UPDATE나 DELETE를 지원해야 하는 시나리오가 나오면 Apache Iceberg 테이블 포맷이 필요하다는 것이 핵심 포인트입니다.

---

User Defined Functions (UDFs)

Athena에서는 사용자 정의 함수도 사용할 수 있습니다.

AWS Lambda를 통해 사용자 정의 함수를 생성한 후 SQL에서 호출 복잡한 로직(예: 지리공간 인덱싱)을 캡슐화 가능 표준 SQL만으로는 구현하기 어려운 연산을 Athena에서 실행 가능

---

주요 활용 사례

| 활용 사례 | 설명 | | --- | --- | | 로그 분석 | VPC Flow Logs, ELB 로그, CloudTrail 로그 분석 | | 비용 및 사용량 분석 | AWS Cost & Usage Report를 S3에서 직접 쿼리 | | BI 및 리포팅 | QuickSight, Tableau, Power BI와 연동 | | 데이터 레이크 탐색 | 스키마 없이 S3 원시 데이터 즉시 쿼리 |

---

빠르게 정리하는 핵심 암기 포인트

| 키워드 | 연결 개념 | | --- | --- | | 서버리스 SQL | S3 데이터 직접 쿼리, 인프라 불필요 | | $5/TB | 스캔한 데이터 양만큼 과금 | | Parquet / ORC | 컬럼형 포맷으로 비용 절감의 핵심 | | 파티셔닝 | 관련 데이터만 스캔하여 성능과 비용 최적화 | | Glue Data Catalog | Athena 메타데이터 저장소 | | MSCK REPAIR TABLE | S3 신규 파티션 메타데이터 동기화 | | Workgroups | 팀별 비용 제어 및 접근 관리 | | Federated Query | 여러 데이터 소스 단일 SQL 쿼리 | | Apache Iceberg | ACID 트랜잭션, 시간 여행 지원 | | UDF | Lambda 기반 사용자 정의 함수 |

---

마무리

Amazon Athena는 DEA-C01에서 데이터 레이크 쿼리와 비용 최적화 시나리오 문제의 단골 서비스입니다.

시험에서는 특히 다음 내용을 정확히 구분하는 것이 중요합니다.

Parquet이나 ORC 포맷과 파티셔닝을 통한 비용 절감 Glue Data Catalog와의 연동 패턴 Federated Query를 통한 다중 소스 쿼리 Apache Iceberg를 통한 ACID 트랜잭션 지원

이 개념들만 확실히 정리해두면 DEA-C01 데이터 레이크 쿼리 관련 문제 대부분을 해결할 수 있습니다.**

블로그 목록으로 돌아가기