Day 4 - 데이터 저장 전략: 파티셔닝·포맷 최적화·학습용 준비

파티셔닝: 안 읽을 데이터를 건드리지 않기

같은 데이터라도 어떻게 저장하느냐에 따라 쿼리 비용이 수십 배 차이 나고 학습 속도가 몇 배 갈린다.

파티셔닝은 데이터를 특정 키(보통 날짜)로 폴더로 쪼개 저장하는 것이다. 쿼리가 WHERE 조건으로 필요한 파티션만 읽으면 나머지는 스캔하지 않는다 — 파티션 프루닝(partition pruning)이다.

s3://ml-datalake/events/
 ├─ year=2026/month=05/day=01/part-0000.parquet
 ├─ year=2026/month=06/day=24/part-0000.parquet
 └─ year=2026/month=06/day=25/part-0000.parquet   ← WHERE day='25'면 이것만 스캔

year=, month= 같은 키=값 형식의 폴더 이름을 Hive 스타일 파티셔닝이라 부른다. Glue Crawler와 Athena가 이 규칙을 자동 인식해 파티션 컬럼으로 등록한다.

-- 파티션 키로 필터하면 해당 파티션의 Parquet만 스캔된다
SELECT customer_id, COUNT(*) AS cnt
FROM ml_datalake.events
WHERE year = '2026' AND month = '06' AND day = '25'
GROUP BY customer_id;

파티션 키를 고르는 기준 — 잘못 고르면 효과가 0이다.

파티셔닝의 효과는 "파티션 키를 쿼리 조건에 쓸 때만" 나타난다. 날짜로 파티션했는데 정작 쿼리가 WHERE customer_id = ...로만 필터하면 모든 날짜 파티션을 풀스캔한다. 동시에 너무 잘게 쪼개면(예: 초 단위) 작은 파일이 수백만 개로 늘어 메타데이터 오버헤드와 "small files problem"이 생긴다. 보통 날짜(년/월/일) 또는 지역 같은 중간 카디널리티 컬럼이 적정선이다.

파일 포맷: 행 기반 vs 열 기반

ML 데이터 저장에서 포맷 선택은 비용·속도에 직결된다. 핵심은 행 기반(row-oriented)과 열 기반(columnar)의 차이다.

Parquet이 분석·ML의 사실상 표준인 이유는 셋이다.

1. 열 기반이라 필요한 컬럼만 읽어 I/O가 적다.
2. 컬럼 단위로 압축률이 높다(같은 타입 값이 모여 있어서).
3. 스키마와 통계(min/max)를 파일에 담아 불필요한 블록을 건너뛴다.

import pandas as pd
 
df = pd.read_csv("s3://raw/events.csv")
 
# Parquet으로 변환 + Snappy 압축 (Athena/SageMaker가 빠르게 읽음)
df.to_parquet(
    "s3://ml-datalake/curated/events.parquet",
    engine="pyarrow",
    compression="snappy",
)

압축 코덱 선택

Snappy는 압축률은 중간이지만 압축/해제가 빨라 쿼리·학습처럼 자주 읽는 데이터에 적합하다(Parquet 기본값). Gzip은 압축률이 높아 저장 비용을 줄이지만 CPU를 더 쓴다 — 자주 안 읽는 아카이브에 맞다. ML 학습 데이터는 반복적으로 읽으므로 보통 Snappy + Parquet 조합이 정답이다.

⚠️ 함정: "압축하면 무조건 좋다"가 아니다. CSV/JSON을 Gzip으로 압축하면 파일이 분할 불가능(non-splittable)해져, 여러 워커가 한 파일을 병렬로 나눠 읽지 못한다. Parquet은 내부 블록(row group) 단위로 분할 가능해 분산 학습·쿼리에서 병렬성을 유지한다. 큰 데이터를 다룰 땐 "압축 여부"보다 "분할 가능 포맷인가"가 더 중요하다.

[Gzip CSV 1개 파일]        워커1 ████████████████  워커2 (놀고 있음)
                            → 하나의 워커가 순차로 전부 읽어야 함

[Parquet 여러 샤드]        워커1 ████  워커2 ████  워커3 ████  워커4 ████
                            → row group·파일 단위로 나눠 동시에 읽음

SageMaker 학습용 데이터 준비

저장 전략의 종착점은 "SageMaker 학습 잡이 S3에서 데이터를 얼마나 빠르게 받느냐"다. SageMaker는 S3 데이터를 학습 컨테이너로 전달하는 입력 모드를 제공한다.

[File]      ████ 전체 복사(수십 분) ████ ▶ 학습 시작 ──────────▶
[Pipe]      ▶ 학습 시작 ─── 스트리밍으로 계속 공급 ───────────▶
[FastFile]  ▶ 학습 시작 ─── 필요한 파일만 그때그때 로드 ──────▶

from sagemaker.inputs import TrainingInput
 
# 대용량 데이터를 Pipe mode로 스트리밍 입력
train_input = TrainingInput(
    s3_data="s3://ml-datalake/curated/train/",
    input_mode="Pipe",            # File / Pipe / FastFile
    content_type="application/x-parquet",
)
estimator.fit({"train": train_input})

데이터를 S3에 둘 때는 여러 개의 적당한 크기 파일(샤드)로 나누는 것도 중요하다. 단일 거대 파일은 분산 학습에서 여러 인스턴스가 나눠 읽기 어렵다. SageMaker는 ShardedByS3Key 분배 방식으로 파일들을 인스턴스에 나눠 줄 수 있다.

⚠️ 함정: ShardedByS3Key를 켰다고 끝이 아니다. 샤딩은 S3 객체 단위라, 단일 100GB 파일 하나에 걸면 아무 분배도 일어나지 않는다. 데이터가 여러 객체로 나뉘어 있어야 효과가 난다.

ML 학습에서 데이터 입력은 종종 GPU보다 병목이 된다. GPU가 한 배치를 0.1초에 계산하는데 데이터를 읽는 데 0.5초가 걸리면 GPU는 대부분의 시간을 놀게 된다(GPU starvation). Pipe/FastFile mode와 Parquet 같은 효율적 포맷, 적절한 샤딩은 모두 "비싼 GPU를 굶기지 않기" 위한 장치다. 저장 전략이 곧 학습 비용 전략인 이유다.

한 팀이 수 TB의 클릭 로그를 단일 거대 CSV로 S3에 두고 File mode로 학습하다, 매 실험마다 데이터 복사에 40분씩 허비했다. 데이터를 날짜로 파티셔닝한 Parquet 샤드로 재저장하고 Pipe mode로 바꾸자 복사 대기가 사라지고, Athena로 미리 EDA하기도 쉬워졌다. 저장 포맷 하나가 실험 반복 속도를 좌우한 셈이다.

저장 설계 체크리스트

저장 설계가 만드는 차이를 수치로 보기

같은 5TB 데이터셋, 같은 쿼리라도 배치에 따라 읽는 양이 이렇게 달라진다.

• 100개 컬럼 중 5개만 쓰고 한 달치만 조회한다면, 두 레버가 곱해져 스캔량이 극적으로 줄어든다.
• 이 절감은 Athena 요금뿐 아니라 SageMaker 학습의 데이터 로딩 시간에도 그대로 반영된다.

파일 크기와 개수의 균형

입력 모드 선택 흐름

학습 데이터가 인스턴스 디스크에 들어가나?
   │
   ├─ 예 ─── 에폭마다 완전 셔플·랜덤 접근이 중요한가?
   │           ├─ 예 → File mode
   │           └─ 아니오 → File 또는 FastFile
   │
   └─ 아니오 ─ 접근이 순차적인가?
               ├─ 예 → Pipe mode (다운로드 대기 없음)
               └─ 아니오(일부 파일만 랜덤 접근) → FastFile mode

GPU가 노는지 확인하고 대응하기

GPU 사용률이 낮을 때 인스턴스 타입을 더 큰 GPU로 올리는 것은 대부분 오답이다. 병목이 연산이 아니라 입력이면 더 비싼 GPU가 더 오래 놀 뿐이다. 저장 포맷·입력 모드·샤딩을 먼저 본다.

저장 전략 한 줄 판별

다음 글에서는 이번 주 데이터 수집·저장 전체를 종합 복습하며 Week 2를 마무리한다.

📖 용어

• 파티셔닝 : 데이터를 날짜 같은 키로 폴더 단위로 쪼개 저장하는 것. 안 읽을 데이터를 건드리지 않게 한다.
• 파티션 프루닝 : 조건에 해당하는 파티션만 읽고 나머지는 통째로 건너뛰는 최적화.
• small files problem : 파일이 지나치게 잘게 쪼개져 파일당 오버헤드가 처리 시간을 지배하는 현상.
• 행 기반(row-oriented) : 한 행의 값들을 나란히 저장하는 방식. 한 행 전체를 자주 쓰는 작업에 유리.
• 열 기반(columnar) : 같은 컬럼의 값들을 모아 저장하는 방식. 일부 컬럼만 읽는 분석·학습에 유리.
• row group : Parquet 내부에서 데이터를 나누는 블록 단위. 이 덕분에 압축해도 분할 읽기가 가능하다.
• 분할 불가능(non-splittable) : 파일을 중간부터 읽을 수 없어 한 워커가 통째로 처리해야 하는 상태.
• Snappy : 압축률보다 속도를 택한 압축 코덱. 자주 읽는 학습 데이터의 기본 선택.
• 입력 모드(input mode) : S3의 학습 데이터를 컨테이너에 넣는 방식. File·Pipe·FastFile 세 가지.
• Pipe mode : 전체 다운로드를 기다리지 않고 S3에서 흘려보내며 바로 학습을 시작하는 방식.