Day 4 - 데이터 포맷과 모델링

다섯 가지 포맷 한눈에

같은 데이터라도 어떤 파일 포맷으로 저장하느냐에 따라 쿼리 속도가 100배, 비용이 10배 차이 난다. 데이터 분석가가 "왜 이 쿼리가 5분이나 걸리죠?"라고 물으면, 답은 종종 "데이터가 CSV로 저장돼 있어서"다. CSV를 Parquet으로 바꾸는 한 줄짜리 변환이 가장 효과적인 최적화일 때가 많다.

오늘은 데이터 엔지니어가 매일 마주하는 파일 포맷들 — CSV, JSON, Parquet, ORC, Avro — 을 비교하고, 그 차이의 본질인 컬럼형(columnar) vs 행형(row-based) 저장을 이해하며, 시간이 지나며 데이터 구조가 바뀌는 현실을 다루는 스키마 진화(schema evolution)를 본다.

크게 세 부류다. 텍스트 기반(CSV/JSON)은 사람이 읽기 쉽고 호환성이 좋지만 비효율적이다. 컬럼형 바이너리(Parquet/ORC)는 분석 쿼리에 최적화돼 있다. 행형 바이너리(Avro)는 쓰기와 스키마 진화에 강해 스트리밍·이벤트에 쓰인다.

💡 관련 이론: 포맷 선택은 워크로드 따라간다. "쓰기가 잦고 한 레코드 전체를 자주 다루는가(write-heavy)" → 행형(Avro). "읽기 위주로 특정 컬럼만 집계하는가(read-heavy, analytical)" → 컬럼형(Parquet/ORC). 이 한 줄이 시험에서 포맷을 고르는 기준이다.

컬럼형 vs 행형: 차이의 본질

이것이 오늘의 핵심이다. 같은 표를 디스크에 어떻게 늘어놓느냐의 차이다.

원본 테이블
  id | name  | amount
  1  | Kim   | 100
  2  | Lee   | 200
  3  | Park  | 300

행형(row-based) 저장 — CSV, Avro
  [1,Kim,100][2,Lee,200][3,Park,300]
  한 행을 통째로 모아둔다

컬럼형(columnar) 저장 — Parquet, ORC
  [1,2,3][Kim,Lee,Park][100,200,300]
  같은 컬럼끼리 모아둔다

SELECT SUM(amount) 같은 분석 쿼리를 예로 든다. 행형은 amount를 읽으려면 id·name까지 전부 스캔해야 한다. 컬럼형은 [100,200,300] 블록만 읽으면 끝이다. 필요한 컬럼만 읽으므로 I/O가 극적으로 줄어든다. 이를 컬럼 프루닝(column pruning)이라 한다.

게다가 같은 컬럼은 데이터 타입과 값이 비슷해 압축이 훨씬 잘 된다. amount 컬럼은 전부 숫자라 효율적으로 압축되지만, 행 단위로 섞인 타입은 그렇지 않다.

-- Athena 비용은 "스캔한 데이터량"에 비례한다
-- CSV: amount만 필요해도 모든 컬럼을 스캔 → 비싸고 느림
-- Parquet: amount 컬럼만 스캔 → 싸고 빠름
SELECT region, SUM(amount)
FROM orders          -- Parquet이면 region, amount 두 컬럼만 읽음
GROUP BY region;

반대로 OLTP처럼 "한 행 전체를 읽거나 쓰는" 작업은 행형이 유리하다. 컬럼형은 한 행을 재구성하려면 여러 컬럼 블록을 모아야 하기 때문이다.

컬럼형 포맷은 컬럼 프루닝 외에도 프레디킷 푸시다운(predicate pushdown)과 파티션 프루닝으로 빨라진다. Parquet은 데이터 블록마다 min/max 등 통계를 저장해, WHERE amount > 500 같은 조건에 안 맞는 블록을 아예 읽지 않고 건너뛴다. 컬럼 프루닝(가로로 덜 읽기) + 프레디킷 푸시다운(세로로 덜 읽기)의 결합이 OLAP 성능의 핵심이다.

Parquet이 분석의 사실상 표준인 이유

AWS 분석 스택(Athena, Redshift Spectrum, Glue, EMR)에서 Parquet이 기본 권장 포맷이다. 이유를 정리하면:

• 컬럼 프루닝: 필요한 컬럼만 읽어 I/O·비용 절감 (Athena는 스캔량 과금)
• 강한 압축: 같은 데이터를 CSV 대비 훨씬 작게 저장 → 스토리지 비용↓
• 내장 통계: 블록별 min/max로 프레디킷 푸시다운
• 스키마 내장: 파일 자체가 스키마를 포함해 자기 기술적(self-describing)

# 흔한 최적화: 원시 CSV/JSON을 Parquet으로 변환 (Glue/Spark)
df = spark.read.json("s3://raw/events/")
df.write.partitionBy("year","month","day") \
        .parquet("s3://processed/events/")
# 이후 Athena 쿼리가 빨라지고 스캔 비용이 급감

ORC는 Parquet과 거의 동일한 컬럼형 장점을 가지며 Hive/Hadoop 생태계에서 특히 강하다. AWS에서는 둘 다 잘 지원되지만 Parquet이 더 널리 쓰인다.

Avro와 스키마 진화

Avro는 행형 바이너리인데도 중요하게 다뤄진다. 핵심 강점이 스키마 진화이기 때문이다. Avro는 데이터와 함께 스키마를 명시적으로 다루며, 읽을 때의 스키마(reader)와 쓸 때의 스키마(writer)가 달라도 호환되도록 설계됐다. 그래서 스키마가 자주 바뀌는 스트리밍·이벤트 파이프라인(Kafka 등)에서 표준처럼 쓰인다.

스키마 진화란 시간이 지나며 데이터 구조가 바뀌는 현실을 안전하게 다루는 것이다. 예를 들어 주문 이벤트에 나중에 coupon_code 필드가 추가될 수 있다. 이때 옛 데이터와 새 데이터를 모두 읽을 수 있어야 한다.

스키마 진화의 호환성 종류
  하위 호환(backward) : 새 스키마로 옛 데이터를 읽을 수 있다
                        → 필드 삭제, 기본값 있는 필드 추가
  상위 호환(forward)  : 옛 스키마로 새 데이터를 읽을 수 있다
                        → 필드 추가
  완전 호환(full)     : 양방향 모두 가능

안전한 진화의 원칙: 필드를 추가할 땐 기본값(default)을 주고, 함부로 삭제·이름변경하지 않는다. 기본값이 있으면 그 필드가 없는 옛 데이터를 읽어도 기본값으로 채워져 깨지지 않는다.

스키마 진화를 조직 차원에서 강제하는 것이 스키마 레지스트리(Schema Registry)다. 프로듀서가 새 스키마를 등록할 때 기존과 호환되는지 검증해, 호환을 깨는 변경을 배포 전에 차단한다. AWS Glue Schema Registry가 이 역할을 하며, Kinesis·MSK와 통합된다. 데이터 계약(data contract)을 코드로 강제하는 거버넌스 장치다.

포맷 선택 의사결정

시험과 실무에서 포맷을 고르는 흐름이다.

사람이 직접 읽거나 외부와 교환?     → CSV / JSON
분석(집계)용으로 S3에 적재?         → Parquet (AWS 기본 권장)
Hive/Hadoop 생태계 중심 분석?       → ORC
스트리밍·이벤트, 스키마 자주 변경?   → Avro
중첩·반정형 구조(API 응답, 로그)?    → JSON (→ 이후 Parquet 변환)

현실의 전형적 패턴은 "원시 데이터는 JSON/CSV로 들어오지만, 처리 단계에서 Parquet으로 변환해 분석 영역에 적재"하는 것이다. 들어올 때의 편의(텍스트)와 분석할 때의 효율(컬럼형)을 모두 취하는 방법이다.

Parquet 파일 속을 열어보면

"컬럼끼리 모아 저장한다"는 실제로는 3단 구조다. 이 구조를 알면 프루닝과 푸시다운이 왜 되는지, 작은 파일이 왜 나쁜지가 한 번에 설명된다.

Parquet 파일
 ├─ Row Group 1            ← 행을 큰 덩어리로 자른 단위 (기본 128MB)
 │   ├─ Column Chunk: id       ├─ Page ... Page   ← 인코딩·압축의 최소 단위
 │   ├─ Column Chunk: name     ├─ Page ... Page
 │   └─ Column Chunk: amount   ├─ Page ... Page
 ├─ Row Group 2
 │   └─ ...
 └─ Footer                 ← 스키마, 각 컬럼 청크의 위치(오프셋), min/max·null 개수 통계

• 읽는 쪽은 푸터를 먼저 읽는다. 스키마와 통계를 보고 "어느 Row Group 의 어느 컬럼 청크만 필요한지" 정한 뒤, S3 에 그 바이트 범위만 요청한다. 파일 전체를 내려받지 않는다.
• 컬럼 프루닝은 필요한 컬럼 청크만 고르는 것이고, 프레디킷 푸시다운은 min/max 통계로 조건에 안 맞는 Row Group·페이지를 건너뛰는 것이다.
• 통계로 건너뛰려면 값이 정렬돼 있어야 효과가 난다. created_at 으로 정렬해 써 두면 짧은 시간 범위 조회가 대부분의 Row Group 을 건너뛴다. 값이 무작위로 섞여 있으면 모든 Row Group 의 min/max 범위가 조건에 걸려 건너뛸 것이 없다.
• 컬럼 청크 안에서는 딕셔너리 인코딩(반복되는 값을 번호로 치환)과 런 길이 인코딩이 먼저 적용되고, 그 위에 Snappy·GZIP 같은 압축이 걸린다. region 처럼 값 종류가 적은 컬럼이 유난히 잘 줄어드는 이유다.
• ORC 는 같은 생각을 스트라이프(stripe, 기본 64MB) 라는 단위로 구현한다. 개념 대응은 Row Group ≈ 스트라이프다.

⚠️ 함정: 컬럼형이라고 무조건 빠르지 않다. 파일이 아주 작으면 푸터·메타데이터를 읽는 고정 비용이 이득보다 커진다. 몇 KB 짜리 Parquet 수만 개는 큰 CSV 몇 개보다 느릴 수 있다. 컬럼형으로 바꾸는 것과 파일을 충분히 크게 묶는 것은 한 세트다.

압축 코덱과 "분할 가능" 여부

포맷과 압축은 별개의 선택이다. .json.gz 는 "JSON 포맷 + GZIP 압축"이고, Parquet 은 파일 안에서 페이지 단위로 압축한다.

• 분할 가능(splittable) 이란 큰 파일 하나를 여러 작업자가 나눠 동시에 읽을 수 있다는 뜻이다.
• 압축된 텍스트 파일(CSV·JSON 을 GZIP 으로 묶은 것)은 대부분 처음부터 순서대로 풀어야 해서 나눠 읽지 못한다. 10GB 짜리 .csv.gz 하나는 작업자 한 명이 끝까지 읽는다.
• Parquet·ORC 는 Row Group·스트라이프 단위로 독립 압축되므로 어떤 코덱을 써도 파일을 나눠 읽을 수 있다.
• 그래서 텍스트를 압축해 둘 때는 "거대한 파일 하나"가 아니라 적당한 크기의 여러 파일로 나누는 것이 병렬성에 유리하다. 파일 수가 곧 동시에 일할 수 있는 작업자 수의 상한이 된다.
• Athena 는 압축을 풀기 전 크기, 즉 S3 에 저장된 압축된 바이트를 스캔량으로 잰다. 압축만 해도 요금이 줄고, 컬럼형까지 가면 읽는 컬럼만큼만 잰다.

포맷별로 허용되는 스키마 변경 (Athena 기준)

"스키마 진화에 강하다"는 말은 포맷마다 내용이 다르다. Athena 는 스키마를 읽는 시점에 적용(schema-on-read)하므로, 테이블 정의를 바꿨을 때 옛 파일이 어떻게 해석되는지가 관건이다.

• 갈리는 원리는 "컬럼을 이름으로 찾는가, 위치(순서)로 찾는가" 다.
  • 이름으로 찾으면 순서가 바뀌거나 중간에 끼어들어도 안전하지만, 이름을 바꾸면 옛 파일에서 그 컬럼을 못 찾아 NULL 이 된다.
  • 위치로 찾으면 이름은 자유롭게 바꿔도 되지만, 중간에 컬럼을 넣거나 빼면 뒤 컬럼이 전부 한 칸씩 밀린다.
• Athena 의 기본값은 Parquet 은 이름으로, ORC 는 위치로 읽는다. SerDe 속성(parquet.column.index.access, orc.column.index.access)으로 반대로 바꿀 수 있다.
• CSV 는 헤더가 있어도 위치로 해석된다. 그래서 "CSV 원본 중간에 컬럼이 추가됐더니 값이 엉뚱한 컬럼에 들어간다"는 사고가 난다.
• 어떤 포맷이든 끝에 추가는 안전하다. 실무 규칙이 "새 컬럼은 맨 뒤에, 기본값(또는 NULL 허용)으로"인 이유다.

Glue Schema Registry 의 호환 모드

레지스트리는 새 스키마 버전을 등록할 때 정해 둔 호환 규칙으로 검사하고, 어기면 등록을 거부한다. AWS Glue Schema Registry 는 Avro, JSON(JSON Schema), Protobuf 를 지원하고 별도 요금이 없으며, Apache Kafka·Amazon MSK·Kinesis Data Streams·Managed Service for Apache Flink·Lambda 와 연동된다.

• AWS 가 권장하는 기본 선택은 BACKWARD 다. 새 코드로 올린 소비자가 스트림에 남아 있는 옛 메시지도 읽을 수 있어야 하기 때문이다.
• 모드는 배포 순서를 정해 준다. BACKWARD 는 소비자를 먼저 올려도 안전하고(새 소비자가 옛 데이터를 읽음), FORWARD 는 프로듀서를 먼저 올려도 안전하다(옛 소비자가 새 데이터를 읽음). 어느 쪽을 먼저 배포할지 통제할 수 없으면 FULL 이다.
• _ALL 이 붙지 않은 모드는 바로 앞 버전하고만 비교한다. 보존 기간이 긴 스트림을 처음부터 다시 읽을 일이 있으면 v1 로 쓴 메시지를 v5 소비자가 읽어야 하므로 _ALL 이 필요하다.
• BACKWARD 에서 "필수 필드 추가"가 거부되는 이유: 옛 메시지에는 그 필드가 없는데 새 소비자는 반드시 있어야 한다고 믿기 때문이다. 선택 필드로 바꾸면 통과한다.

레지스트리를 쓰면 메시지마다 스키마 전체를 실어 보내지 않는다. 직렬화기가 스키마를 레지스트리에 등록(또는 조회)하고 메시지에는 스키마 버전 식별자만 붙인다. 소비자의 역직렬화기가 그 식별자로 스키마를 가져와 해석한다. Avro 메시지가 JSON 보다 작아지는 이유가 필드 이름을 매번 싣지 않기 때문이다.

포맷을 바꾸는 세 가지 방법

"JSON 을 Parquet 으로 변환"은 어디서 하느냐에 따라 제약이 다르다.

-- Athena CTAS: 원시 JSON 테이블을 날짜 파티션의 Parquet 테이블로
CREATE TABLE events_parquet
WITH (
  format            = 'PARQUET',
  write_compression = 'SNAPPY',
  partitioned_by    = ARRAY['dt'],
  external_location = 's3://datalake/processed/events/'
) AS
SELECT user_id, event_type, amount, dt     -- 파티션 컬럼은 SELECT 의 마지막에
FROM events_raw_json
WHERE dt = '2026-06-25';

• Firehose 변환에서 Glue 테이블 스키마에 없는 속성은 결과에서 빠진다. 스키마를 먼저 맞춰 두지 않으면 조용히 데이터가 줄어든다.
• 변환 실패 레코드는 버려지지 않고 S3 의 오류 접두사로 떨어진다. 포맷 변환을 켰다면 그 경로를 모니터링해야 한다.

파일 포맷과 테이블 포맷은 다른 층이다

• 파일 포맷(Parquet, ORC, Avro)은 파일 하나의 내부 배치를 정한다.
• 테이블 포맷(Apache Iceberg 등)은 "어떤 파일들의 모음이 지금 이 테이블인가"를 메타데이터로 관리한다. 데이터 파일 자체는 대개 Parquet 이다.
• 테이블 포맷이 더해 주는 것은 행 단위 수정·삭제, 스냅샷(시간 여행), 컬럼 이름 변경 같은 안전한 스키마 진화다. 위 표에서 Parquet 이 못 하던 "컬럼 이름 변경"이 Iceberg 에서 되는 이유는 컬럼을 이름이 아닌 고유 ID 로 추적하기 때문이다.
• 지문이 "S3 데이터 레이크에서 레코드 단위 업데이트·삭제, ACID 트랜잭션"을 요구하면 파일 포맷 선택이 아니라 테이블 포맷(레이크하우스) 문제다.

지문 단서 → 포맷 판별표

다음 글에서는 Week 1에서 다룬 기초들 — 역할·파이프라인, 배치/스트리밍, 서비스 지도, 데이터 포맷 — 을 한데 엮어 복습한다.

📖 용어

• 행형 / 컬럼형 : 한 행을 통째로 붙여 저장하는 방식과, 같은 컬럼 값끼리 모아 저장하는 방식.
• 컬럼 프루닝 : 쿼리에 필요한 컬럼만 골라 읽는 것. 컬럼형 포맷에서만 효과가 크다.
• 프레디킷 푸시다운 : WHERE 조건을 파일 읽기 단계로 내려보내, 조건에 안 맞는 블록을 아예 읽지 않는 것.
• Row Group / 스트라이프 : Parquet 과 ORC 가 행을 큰 덩어리로 묶는 단위. 덩어리마다 통계가 붙는다.
• 푸터(footer) : Parquet 파일 끝에 있는 메타데이터. 스키마와 컬럼 위치, 통계가 들어 있다.
• 분할 가능(splittable) : 큰 파일 하나를 여러 작업자가 나눠 동시에 읽을 수 있는 성질.
• 스키마 진화 : 필드 추가·삭제처럼 시간이 지나며 바뀌는 데이터 구조를 옛 데이터와 함께 안전하게 다루는 것.
• 하위 호환 / 상위 호환 : 새 스키마로 옛 데이터를 읽을 수 있음 / 옛 스키마로 새 데이터를 읽을 수 있음.
• 스키마 레지스트리 : 스키마 버전을 한곳에 모아 두고, 호환 규칙을 어기는 새 버전의 등록을 막는 저장소.
• SerDe : 직렬화기·역직렬화기. 파일의 바이트를 테이블의 행으로(또는 반대로) 바꾸는 규칙.