Day 3 - 쿼리·탐색: Athena, Redshift, EDA 기초

Amazon Athena: S3를 SQL로 쿼리

데이터를 수집·카탈로그화했다면 이제 읽고 이해할 차례다. 모델을 만들기 전 데이터 사이언티스트는 반드시 데이터를 들여다본다 — 이것이 EDA(Exploratory Data Analysis)다.

Athena는 S3에 저장된 데이터를 서버리스 SQL로 쿼리하는 서비스다. Presto/Trino 엔진 기반이고 클러스터 프로비저닝이 전혀 없다. Glue Data Catalog의 테이블 정의를 그대로 사용한다.

• 서버리스: 인프라 관리 없음. 쿼리할 때만 동작.
• schema-on-read: 데이터를 옮기지 않고 S3에 둔 채로 쿼리.
• 과금 = 스캔한 데이터량: 쿼리가 스캔한 바이트당 과금($5/TB). 스캔량 최소화가 곧 비용 절감이다.

-- Glue Catalog에 등록된 테이블을 바로 쿼리
SELECT customer_id, AVG(amount) AS avg_amount
FROM ml_datalake.transactions
WHERE year = '2026' AND month = '06'   -- 파티션 필터로 스캔량 감소
GROUP BY customer_id
ORDER BY avg_amount DESC
LIMIT 100;

위 쿼리에서 WHERE year='2026' AND month='06'는 파티션 프루닝을 일으켜 해당 파티션의 Parquet만 스캔한다.

스캔량을 줄이는 3대 레버

세 레버는 곱해진다. CSV 풀스캔 대비 잘 설계된 Parquet 쿼리가 수십 배 저렴해지는 이유다.

Athena 비용이 "스캔한 데이터량"에 비례한다는 점은 ML 데이터 준비에 직접 영향을 준다. CSV로 풀스캔하면 비싸고 느리지만, 잘 파티셔닝된 Parquet은 같은 쿼리가 훨씬 낮은 비용으로 돈다. ML 피처를 뽑는 쿼리를 자주 돌린다면 이 차이가 누적된다.

Athena는 ML 워크플로의 빠른 피처 탐색에 적합하다. SageMaker가 학습 데이터로 Parquet을 S3에서 읽기 전에, 분석가가 Athena로 "타깃 분포는? 클래스 불균형은?"을 SQL로 확인한다. 또 Athena CTAS(CREATE TABLE AS SELECT)로 쿼리 결과를 Parquet으로 S3에 저장해 학습 데이터셋을 직접 만들 수도 있다.

-- CTAS로 학습용 데이터셋을 Parquet으로 생성
CREATE TABLE ml_datalake.churn_training
WITH (format = 'PARQUET', external_location = 's3://ml-datalake/curated/churn/')
AS
SELECT customer_id, tenure, monthly_charges, churned
FROM ml_datalake.transactions
WHERE year = '2026';

Amazon Redshift: 데이터웨어하우스

Redshift는 페타바이트급 데이터웨어하우스(OLAP)다. 데이터를 Redshift 내부 노드에 적재(또는 Redshift Serverless)하고, MPP(Massively Parallel Processing)로 복잡한 분석 쿼리를 고속 처리한다.

Redshift Spectrum은 둘의 다리다 — Redshift에서 S3의 데이터를 외부 테이블로 직접 쿼리할 수 있다. 자주 쓰는 데이터(핫)는 Redshift 내부에, 차가운 데이터는 S3에 두고 Spectrum으로 조인한다.

ML 통합 측면에서 Redshift ML도 있다. SQL CREATE MODEL 문으로 Redshift 안에서 SageMaker Autopilot을 호출해 모델을 학습·추론할 수 있다. 데이터를 옮기지 않고 SQL만으로 예측 컬럼을 만든다.

-- Redshift ML: SQL로 모델 학습 (내부적으로 SageMaker Autopilot 호출)
CREATE MODEL churn_predictor
FROM (SELECT tenure, monthly_charges, churned FROM transactions)
TARGET churned
FUNCTION predict_churn
IAM_ROLE 'arn:aws:iam::123456789012:role/RedshiftMLRole'
SETTINGS (S3_BUCKET 'ml-datalake-redshiftml');

헷갈리기 쉬운 비교 — "임시 탐색/간헐적 쿼리 + 관리 부담 최소 + 데이터를 S3에 그대로"면 Athena. "반복적인 고성능 BI 쿼리 + 복잡한 조인 + 지속적 워크로드"면 Redshift. "Redshift에서 S3 차가운 데이터를 조인"이면 Redshift Spectrum. "데이터 이동 없이 SQL로 ML"이면 Redshift ML.

EDA(탐색적 데이터 분석) 기초

데이터를 쿼리할 수 있게 됐으니 이제 이해할 차례다. EDA는 모델링 전에 데이터의 구조·품질·관계를 파악하는 과정이며, 피처 엔지니어링·데이터 정제의 근거를 제공한다.

import pandas as pd
 
df = pd.read_parquet("s3://ml-datalake/curated/churn/train.parquet")
 
# 기초 통계
print(df.describe())          # 수치형 분포(평균/표준편차/사분위)
print(df.isnull().mean())     # 컬럼별 결측 비율
print(df["churned"].value_counts(normalize=True))  # 클래스 불균형 확인
print(df.corr(numeric_only=True))  # 피처 상관행렬

상관계수를 어떻게 읽는가 — EDA에서 바로 판단으로 이어지는 표다.

EDA는 1977년 통계학자 John Tukey가 그의 저서 Exploratory Data Analysis에서 정립한 개념이다. 핵심 철학은 "가설을 세우고 검정하기 전에, 먼저 데이터가 스스로 말하게 하라"이다. 박스플롯·히스토그램·산점도 같은 시각화도 Tukey의 유산이다. ML에서 EDA를 건너뛰면 클래스 불균형이나 데이터 누수(data leakage)를 놓쳐 모델이 잘못된 패턴을 학습한다.

⚠️ 함정: EDA 단계에서 가장 위험한 실수는 데이터 누수(data leakage)다. 예를 들어 "결제 완료일"이라는 컬럼이 "구매 여부" 타깃을 사실상 미리 담고 있으면, 검증 정확도는 99%인데 실제 배포에선 무용지물이다. EDA에서 타깃과 비현실적으로 높은 상관(예: 0.99)을 가진 피처가 보이면 누수를 의심해야 한다.

AWS에서 EDA를 수행하는 환경은 보통 SageMaker Studio / 노트북이다. 노트북에서 Athena로 SQL 쿼리하거나, S3의 Parquet을 pandas로 직접 읽어 분석한다. 대규모 데이터는 SageMaker Data Wrangler가 시각적 EDA와 변환을 묶어 제공한다(Week 3에서 깊게 다룸).

[S3 Parquet] ──┬──> Athena SQL (대용량 집계·샘플링)
               ├──> pandas 노트북 (세밀한 분석·시각화)
               └──> Data Wrangler (시각적 EDA + 변환 + 품질 리포트)

도구 선택 요약

Athena 쿼리를 빠르고 싸게 만드는 습관

스캔량 과금이라는 제약은 쿼리 작성 습관까지 바꾼다.

• LIMIT만으로는 스캔량이 줄지 않을 수 있다. 파티션 프루닝이 함께 걸려야 실제로 적게 읽는다.
• CTAS로 만든 Parquet 중간 테이블은 이후 반복 쿼리와 학습 데이터셋 생성 양쪽에 쓰인다.

Redshift를 고르면 따라오는 설계 결정

Athena와 달리 Redshift는 "적재형"이라 데이터 배치 설계가 성능을 좌우한다.

이 설계 부담이 곧 "간헐적 탐색이면 Athena, 반복적 고성능 분석이면 Redshift"라는 판별의 실질적 근거다.

EDA에서 무엇을 그려 보나

⚠️ 함정: EDA를 전체 데이터로 한 뒤 그 결과를 근거로 특성을 고르고, 그다음에 train/test를 나누면 이미 누수가 시작된 것이다. 특성 선택·변환 기준은 분할 이후 train에서만 도출해야 한다. 탐색 목적의 눈으로 보는 것과, 그 통계를 학습에 쓰는 것은 구분해야 한다.

쿼리 도구를 고르는 한 줄 판별

다음 글에서는 이 데이터를 ML 학습에 최적화하는 저장 전략 — 파티셔닝, 포맷 최적화, 학습용 준비 고려사항을 본다.

📖 용어

• Athena : S3의 파일을 옮기지 않고 SQL로 바로 조회하는 서버리스 쿼리 서비스. 스캔한 양만큼 돈을 낸다.
• 스캔량 과금 : 쿼리가 실제로 읽은 바이트 수에 비례해 요금이 매겨지는 방식. Athena 비용 설계의 전부.
• 파티션 프루닝 : WHERE 조건에 맞는 폴더만 읽고 나머지는 아예 건드리지 않는 최적화.
• CTAS : CREATE TABLE AS SELECT. 쿼리 결과를 새 테이블(파일)로 저장하는 구문. 학습셋 생성에 쓴다.
• MPP(대규모 병렬 처리) : 여러 노드가 데이터를 나눠 동시에 계산하는 구조. Redshift의 속도 비결.
• Redshift Spectrum : Redshift에서 S3 데이터를 외부 테이블로 읽어 내부 테이블과 조인하게 해주는 기능.
• Redshift ML : CREATE MODEL SQL로 Autopilot을 호출해 데이터 이동 없이 학습·추론하는 기능.
• EDA(탐색적 데이터 분석) : 모델을 만들기 전 데이터의 분포·결측·이상치·관계를 눈으로 확인하는 단계.
• 왜도(skew) : 분포가 한쪽으로 길게 치우친 정도. 심하면 로그 변환 등으로 펴준다.
• 다중공선성 : 서로 거의 같은 정보를 담은 피처들이 함께 들어가 모델 해석과 안정성을 해치는 현상.