Day 5 - Week 2 종합 — 데이터 수집·저장 복습

전체 데이터 파이프라인 한눈에

이번 주 서비스들을 따로 외우기보다 "raw 데이터가 들어와 학습 가능한 데이터셋이 되기까지"의 흐름 위에 얹는 것이 시험 대비에 효율적이다.

[소스]
  │  ① 수집(ingestion)
  ├─ 스트리밍 ──> Kinesis Data Streams / Firehose ─┐
  └─ 배치 ──────> DMS / DataSync / 직접 업로드 ─────┤
                                                   v
                                          ┌──────────────────┐
                                          │   S3 데이터 레이크 │  ② 저장
                                          │  (단일 진실 공급원)│
                                          └──────────────────┘
                                                   │  ③ 카탈로그·변환
                                          Glue Crawler → Data Catalog
                                          Glue ETL Job (정제·포맷 변환)
                                                   │  ④ 쿼리·탐색
                                          Athena (서버리스 SQL, EDA)
                                                   │
                                                   v
                                          SageMaker 학습 (Parquet, Pipe mode)

핵심은 S3가 중심이라는 점이다. 모든 서비스가 S3를 입출력으로 삼고, 학습도 결국 S3에서 데이터를 읽는다.

이 구조가 "데이터 레이크"의 전형이다. 데이터웨어하우스가 정형 데이터를 미리 스키마에 맞춰 적재(schema-on-write)하는 반면, 데이터 레이크는 raw 데이터를 일단 S3에 그대로 쌓고 읽을 때 스키마를 적용한다(schema-on-read). ML은 정형·반정형·비정형 데이터를 모두 다루고 어떤 피처가 유용할지 미리 모르기 때문에, "일단 다 모아두고 나중에 해석하는" 데이터 레이크 모델이 잘 맞는다.

수집: 스트리밍 vs 배치

데이터가 들어오는 모양에 따라 도구가 갈린다. 헷갈리기 쉬운 판별이다.

Kinesis 두 형제의 차이를 구분해야 한다. Data Streams는 컨슈머를 직접 붙여 실시간 처리하고 샤드를 관리한다(유연·저지연). Firehose는 완전관리형으로 버퍼링 후 S3/Redshift에 자동 적재한다(코드 없이 적재만 원할 때).

import boto3
kinesis = boto3.client("kinesis")
 
# Kinesis Data Streams에 실시간 이벤트 적재
kinesis.put_record(
    StreamName="clickstream",
    Data=b'{"user_id": "u123", "event": "click", "ts": "2026-06-25T10:00:00Z"}',
    PartitionKey="u123",     # 같은 키는 같은 샤드 → 순서 보장
)

"실시간이지만 코드 없이 S3에 그냥 쌓기만"이면 Firehose, "실시간 스트림을 여러 앱이 각자 처리하고 재생(replay)도 필요"하면 Data Streams다. PartitionKey는 같은 키의 레코드를 같은 샤드로 보내 순서를 보장한다 — 사용자별 이벤트 순서가 중요할 때 user_id를 키로 쓴다.

⚠️ 함정: 순서를 지키려고 샤드를 1개로 줄이는 선택은 오답이다. 순서는 샤드 내부에서 보장되므로, PartitionKey를 잘 고르면 샤드를 여러 개 두고도 키 단위 순서를 지킬 수 있다. 샤드를 1개로 줄이면 전체 처리량만 깎인다.

저장: 포맷·파티셔닝

수집한 데이터는 그대로 두지 않고 학습에 유리하게 가공한다. 어제 본 저장 전략의 요지를 다시 묶으면 이렇다.

이 다섯 가지가 Athena 쿼리 비용(스캔량 과금)과 SageMaker 학습 속도를 동시에 좌우한다.

흔한 저장 실수와 증상

카탈로그·변환: Glue

raw 데이터를 학습 가능한 형태로 만드는 ETL의 중심이 AWS Glue다.

# Glue PySpark ETL: CSV를 정제해 파티셔닝된 Parquet으로 저장
from awsglue.context import GlueContext
from pyspark.context import SparkContext
 
glueContext = GlueContext(SparkContext.getOrCreate())
df = glueContext.create_dynamic_frame.from_catalog(
    database="ml_datalake", table_name="raw_events"
).toDF()
 
df.write.partitionBy("year", "month").mode("overwrite") \
    .parquet("s3://ml-datalake/curated/events/")

Glue Data Catalog는 "메타데이터의 단일 진실 공급원" 역할을 한다. 한 번 Crawler로 스키마를 등록하면 Athena, Redshift Spectrum, EMR이 같은 테이블 정의를 공유한다. 데이터(S3)와 메타데이터(Catalog)를 분리해, 여러 쿼리 엔진이 같은 데이터를 각자 다른 방식으로 읽게 하는 것이 데이터 레이크 아키텍처의 핵심 설계다.

쿼리·탐색: Athena

준비된 데이터를 읽고 이해하는 단계다. Athena는 서버리스 SQL로 S3를 직접 쿼리하며 스캔한 데이터량에 과금($5/TB)한다. 그래서 Parquet + 파티셔닝 + 압축이 곧 비용 절감이다. EDA(분포·결측·클래스 불균형·데이터 누수 점검)의 주 무대이며, CTAS로 쿼리 결과를 Parquet 학습 데이터셋으로 바로 만들 수도 있다.

-- 파티션 필터로 스캔량을 줄이며 클래스 불균형 확인
SELECT churned, COUNT(*) AS cnt
FROM ml_datalake.events
WHERE year = '2026' AND month = '06'
GROUP BY churned;

⚠️ 함정: Athena 비용이 스캔량에 비례한다는 점을 잊고 SELECT *로 전체를 풀스캔하면 비싸진다. 필요한 컬럼만 고르고(Parquet의 컬럼 스킵 활용), 파티션 키로 필터하는 습관이 비용을 수십 배 줄인다.

Week 2 한 줄 체크리스트

서비스 오답 매칭 정리

시험에서 오답 보기는 대개 "다른 단계의 서비스"를 슬쩍 끼워 넣는 방식이다. 각 서비스가 어느 단계 소속인지 못 박아두면 걸러진다.

비용 관점으로 다시 본 이번 주

한 번의 저장 설계가 이후 모든 단계의 비용을 좌우한다. Parquet + 날짜 파티셔닝 + 적정 샤딩은 카탈로그·쿼리·학습 세 단계에서 동시에 이득을 낸다.

파이프라인을 망치는 다섯 가지

이번 주 서비스들은 "무엇을 하는가"보다 "어떤 조건일 때 그것이 최선인가"로 물어온다. 서비스 이름과 기능을 외우는 것으로는 부족하고, 지연·관리 부담·비용·데이터 크기라는 네 축에서 비교할 수 있어야 한다.

Week 2를 한 문장으로

"S3에 원본을 불변으로 쌓고, Glue로 카탈로그·변환해 Parquet + 날짜 파티셔닝으로 재배치한 뒤, Athena로 탐색하고 SageMaker가 그대로 학습에 읽는다."

다음 주(Week 3)에는 이렇게 준비한 데이터를 모델이 읽을 수 있게 바꾸는 특성 공학과, 데이터의 편향·품질 점검을 다룬다.

📖 용어

• 데이터 파이프라인 : 소스에서 학습 데이터셋까지 데이터를 옮기고 다듬는 일련의 단계.
• 수집(ingestion) : 외부의 데이터를 AWS 안(주로 S3)으로 들여오는 과정. 스트리밍과 배치로 나뉜다.
• PartitionKey : Kinesis에서 레코드를 어느 샤드로 보낼지 정하는 값. 같은 키는 같은 샤드로 가 순서가 지켜진다.
• 재생(replay) : 보관 기간 안의 스트림 데이터를 처음부터 다시 읽는 것. Data Streams에서만 가능하다.
• 버퍼링(buffering) : Firehose가 일정 크기나 시간만큼 모았다가 한 번에 내보내는 방식.
• schema-on-write : 데이터를 넣는 시점에 스키마를 강제하는 전통 DB 방식. 데이터 레이크와 대비된다.
• Glue Crawler : 저장소를 훑어 스키마와 파티션을 자동으로 알아내 카탈로그에 등록하는 도구.
• Data Catalog : 여러 쿼리 엔진이 공유하는 중앙 테이블 정의 저장소. 데이터 자체는 담지 않는다.
• 샤딩(sharding) : 데이터를 적당한 크기의 여러 파일로 나눠 병렬 읽기가 가능하게 하는 작업.
• 스캔량 과금 : 쿼리가 실제로 읽은 바이트에 비례해 요금이 매겨지는 방식. Athena 설계의 핵심 제약.