🏗️ 데이터 레이크 구축

왜 이걸 만들까? — 데이터가 사일로에 갇혀 있다면

여러분이 이커머스 회사의 데이터 분석가라고 상상해 보세요.

마케팅팀은 구글 애널리틱스 데이터를 CSV로 내보내고, 물류팀은 배송 기록을 엑셀로 관리하며, 재무팀은 ERP 시스템에서 매출 데이터를 별도로 뽑아 씁니다. "이번 달 카테고리별 매출과 마케팅 비용 대비 수익률을 알고 싶어요"라는 CEO의 질문에 답하려면, 3개 팀에 각각 데이터를 요청하고, 엑셀에서 VLOOKUP으로 합치고, 피벗 테이블을 만들어야 합니다. 이 과정만 이틀이 걸립니다.

데이터 레이크(Data Lake)는 이 문제를 해결합니다.

모든 부서의 데이터를 하나의 중앙 저장소(S3)에 원본 그대로 모으고, 자동화된 파이프라인으로 분석 가능한 형태로 변환한 뒤, SQL 한 줄로 누구나 필요한 인사이트를 뽑아낼 수 있게 합니다.

이 실습에서는 AWS의 서버리스 데이터 서비스를 조합하여 미니 데이터 레이크를 구축합니다:

• S3: 원본 CSV를 저장하는 Raw Zone과 변환된 Parquet를 저장하는 Processed Zone
• Glue Crawler: 데이터의 스키마(컬럼명, 타입)를 자동으로 탐지
• Glue ETL Job: CSV를 고성능 Parquet 형식으로 자동 변환
• Athena: S3에 저장된 데이터를 SQL로 직접 쿼리 (서버 설치 불필요!)

완성하면 "카테고리별 매출 합계"를 SQL 한 줄로 수 초 만에 뽑을 수 있습니다.

이 프로젝트를 통해 배우게 되는 것:

• 데이터 레이크 설계 패턴: Raw/Processed Zone 분리의 이유와 방법
• 스키마 자동 탐지: Glue Crawler가 데이터 구조를 어떻게 추론하는지
• 데이터 형식 최적화: CSV → Parquet 변환이 비용에 미치는 영향
• 서버리스 SQL 분석: Athena로 서버 설치 없이 SQL 쿼리하는 방법
• 파티셔닝 전략: 데이터를 폴더로 분리하여 쿼리 성능을 높이는 기법

아키텍처 개요

데이터 파이프라인 흐름

비용 예측

Step 1: S3 버킷 구조 생성

데이터 레이크의 물리적 기반은 S3 버킷입니다. 데이터의 생명주기에 따라 폴더(접두사)를 나누는 것이 핵심입니다. Raw Zone에는 원본 데이터를 그대로 보관하고, Processed Zone에는 분석에 최적화된 형태로 변환한 데이터를 저장합니다. 이렇게 분리하면 원본이 항상 보존되어, 변환 로직에 문제가 생겨도 언제든 다시 처리할 수 있습니다.

aws s3 mb s3://datalake-lab-ACCOUNT_ID
 
aws s3api put-object --bucket datalake-lab-ACCOUNT_ID --key raw/sales/
aws s3api put-object --bucket datalake-lab-ACCOUNT_ID --key processed/sales/
aws s3api put-object --bucket datalake-lab-ACCOUNT_ID --key athena-results/

Step 2: 샘플 CSV 데이터 업로드

실습에 사용할 매출 데이터 CSV 파일을 만들어 업로드합니다. 실제 기업 데이터와 유사한 구조를 갖추되, 카테고리가 다양해야 이후 집계 쿼리 결과가 의미 있습니다. 데이터가 너무 적으면 Glue Crawler가 스키마를 잘못 추론할 수 있으니 최소 5건 이상 넣으세요.

중간 점검

지금까지의 진행 상황을 확인합니다:

• S3 버킷 datalake-lab-{계정ID}가 생성되었는지
• raw/sales/, processed/sales/, athena-results/ 폴더가 존재하는지
• raw/sales/sales_data.csv 파일이 업로드되어 있는지
• CSV 파일을 클릭하여 "데이터 미리보기"로 한글이 깨지지 않는지

여기까지 완료되었으면, 이제 Glue가 이 데이터를 자동으로 분석하는 단계로 넘어갑니다.

데이터 웨어하우스 vs 데이터 레이크

이 실습을 진행하면서 "데이터 웨어하우스(DW)와 무엇이 다른가?"라는 의문이 들 수 있습니다. 핵심 차이를 이해해 두면 아키텍처 선택에 도움이 됩니다.

이 실습에서 구축하는 것은 S3 기반 데이터 레이크입니다. 별도 서버 없이 필요할 때만 Athena로 쿼리하면 되므로 비용이 매우 저렴합니다.

Step 3: Glue Crawler로 스키마 자동 탐지

Glue Crawler는 S3에 저장된 데이터 파일을 스캔하여 컬럼명, 데이터 타입, 파일 형식을 자동으로 추론합니다. 추론한 결과를 Glue Data Catalog에 테이블로 등록하면, 이후 Athena나 Redshift Spectrum에서 SQL로 바로 쿼리할 수 있습니다. 수동으로 CREATE TABLE 문을 작성할 필요가 없어 대량의 데이터 소스를 빠르게 카탈로깅할 수 있습니다.

aws glue create-database \
  --database-input '{"Name":"datalake_lab_db"}'
 
aws glue create-crawler \
  --name sales-raw-crawler \
  --role AWSGlueServiceRole-lab \
  --database-name datalake_lab_db \
  --table-prefix raw_ \
  --targets '{"S3Targets":[{"Path":"s3://datalake-lab-ACCOUNT_ID/raw/sales/"}]}'
 
aws glue start-crawler --name sales-raw-crawler

Step 4: Glue ETL Job으로 Parquet 변환

CSV는 사람이 읽기 편하지만, 분석에는 비효율적입니다. Parquet은 열 기반(Columnar) 저장 방식으로, 특정 컬럼만 조회할 때 다른 컬럼 데이터를 읽지 않아도 됩니다. 또한 데이터 타입에 맞는 효율적인 압축이 자동으로 적용됩니다. Glue ETL Job은 이 변환을 자동으로 수행합니다.

Step 5: Athena로 데이터 쿼리

Athena는 S3에 저장된 데이터를 서버 설치 없이 SQL로 직접 쿼리할 수 있는 서버리스 서비스입니다. 스캔한 데이터 1TB당 $5가 과금되므로, Parquet + 파티션 구조가 비용 절감에 얼마나 효과적인지 직접 비교해 볼 수 있습니다.

핵심 개념 확인

트러블슈팅 가이드

완성 후 테스트 가이드

전체 파이프라인이 정상 동작하는지 아래 체크리스트로 검증하세요:

1. Raw Zone 확인: S3 raw/sales/ 경로에 원본 CSV 파일이 존재하는지
2. Data Catalog 확인: Glue → 테이블에서 raw_sales의 스키마가 CSV 헤더와 일치하는지
3. Parquet 변환 확인: S3 processed/sales/ 경로에 .parquet 파일이 카테고리별 폴더에 생성되었는지
4. SQL 쿼리 성공: Athena에서 SELECT * FROM raw_sales LIMIT 5; 실행 시 데이터가 정상 반환되는지
5. 집계 쿼리 성공: 카테고리별 매출 합계 쿼리가 올바른 결과를 반환하는지
6. 비용 비교: CSV 테이블 vs Parquet 테이블에서 동일 쿼리의 "스캔된 데이터" 크기 차이 기록
7. 파티션 필터 효과: WHERE category = '전자기기' 조건 쿼리의 스캔량이 전체 조회보다 줄어드는지 확인
8. Glue 비용 확인: Glue 콘솔 → ETL 작업 → 실행 기록에서 DPU 사용 시간 확인

Athena 유용한 쿼리 모음

실습에서 활용할 수 있는 다양한 분석 쿼리를 정리합니다:

-- 1. 전체 매출 합계
SELECT SUM(quantity * price) AS total_revenue FROM raw_sales;
 
-- 2. 카테고리별 매출 순위
SELECT category, SUM(quantity * price) AS revenue,
       RANK() OVER (ORDER BY SUM(quantity * price) DESC) AS rank
FROM raw_sales GROUP BY category;
 
-- 3. 일별 주문 건수 추이
SELECT order_date, COUNT(*) AS order_count
FROM raw_sales GROUP BY order_date ORDER BY order_date;
 
-- 4. 평균 단가가 가장 높은 카테고리
SELECT category, AVG(price) AS avg_price
FROM raw_sales GROUP BY category ORDER BY avg_price DESC LIMIT 1;
 
-- 5. Parquet 테이블의 파티션 필터 (비용 절감 효과 체감)
SELECT * FROM processed_sales WHERE category = '전자기기';

각 쿼리를 실행할 때마다 "스캔된 데이터" 크기를 기록하여 CSV vs Parquet의 비용 차이를 비교해 보세요.

확장 아이디어

1. 스케줄링 자동화: EventBridge 규칙으로 Glue Crawler와 ETL Job을 매일 자정에 자동 실행하도록 스케줄링
2. 데이터 품질 검증: Glue Data Quality 룰을 추가하여 price > 0, quantity > 0 등 데이터 유효성 자동 검증
3. Lake Formation 접근 제어: AWS Lake Formation으로 테이블/컬럼 단위 세분화된 접근 권한 관리
4. QuickSight 대시보드 연결: Amazon QuickSight를 Athena에 연결하여 매출 추이 시각화 대시보드 구축
5. 멀티 소스 통합: 마케팅 데이터(JSON), 물류 데이터(CSV)를 추가 업로드하고 Athena JOIN 쿼리로 크로스 분석

실습 후 사고 실험

이 실습에서는 10건의 CSV 데이터를 사용했습니다. 하지만 실제 기업 환경에서는 어떨까요?

시나리오 1: 데이터가 1억 건이라면?

• S3에 1TB의 CSV 데이터가 있다면, Athena로 전체 스캔 시 비용은 $5/쿼리
• Parquet으로 변환하면 300GB로 압축 → 같은 쿼리가 $1.5/쿼리
• category 파티셔닝 + 특정 카테고리만 조회하면 → $0.15/쿼리 (10배 절감!)

시나리오 2: 매일 새로운 데이터가 추가된다면?

• EventBridge로 매일 자정에 Glue Crawler + ETL Job을 자동 실행
• 날짜(order_date) 기반 파티셔닝을 추가하면 최근 데이터만 효율적으로 조회
• S3 수명 주기 정책으로 90일 이상 된 데이터를 Glacier로 자동 이전하여 스토리지 비용 90% 절감

시나리오 3: 여러 부서가 같은 데이터를 사용한다면?

• AWS Lake Formation으로 테이블/컬럼 단위 접근 제어
• 마케팅팀은 매출 데이터만, 물류팀은 배송 데이터만 접근 허용
• 모든 쿼리 이력이 CloudTrail에 자동 기록되어 감사 추적 가능

이런 확장 시나리오를 머릿속에 그려보면, 데이터 레이크의 실질적 가치를 더 깊이 이해할 수 있습니다.

학습 정리

리소스 정리