Parquet 저장방식 #2

jaewonnow_·2026년 3월 26일

DataEngineering

목록 보기
19/19

Parquet 파일은

  • binary columnar format
  • row group 단위 압축
  • 파일 일부만 수정 불가
  • 수정시 파일 전체 rewrite 한다

Parquet은 쓰기보다 읽기(분석 쿼리)에 올인한 포맷
그래서 부분 수정(Update)을 포기하고 전체 rewrite를 선택한 것이다. (선택과 집중)

Paquet : row 1개 바뀌어도 parquet 파일 전체 다시 써야 함

특히 Parquet 는 사람이 읽기 편한 파일도 아니다. 그저 컴퓨터 기준 읽기가 가장 최적화된 포맷이다. 그래서 데이터 레이크 구조 자체는 Parquet 파일 형식을 대부분 채택한다.

그러나 사람이 “직접” 보고 의사결정 단계라면 CSV가 편하다

🔎 CSV가 편한 이유 (사람 중심)

1. 눈으로 보기 쉬움

  • nvim, Excel, Google Sheets, Datagrip 다 바로 열림

  • 바이너리 깨짐 없음

  • 구조 직관적

2. 팀 커뮤니케이션에 유리

  • 슬랙에 파일 던지기 쉬움

  • Git diff 가능

-> "이 row가 왜 이렇게 나왔지?" 디버깅 쉬움

3. 빠른 실험

  • 모델 입력 샘플 확인

  • 일부 row 수정

  • 테스트용 가공

  • 수정 가능

그런데도 Parquet를 쓰는 이유 (시스템 중심)

그럼에도 Parquet 를 쓰는 이유는 가장 중요한 '속도'이다.

1️⃣ 컬럼형 포맷 (Columnar Storage) , Column Pruning

Parquet는 컬럼 단위로 저장하는 것을 확인했었다.

→ 여러 칼럼 중에서 메타데이터를 통해 필요한 컬럼만 읽음
→ 대용량에서 큰 속도 차이를 보인다.

SELECT user_id FROM file.parquet

→ user_id 컬럼만 읽음
CSV는 전체 파일 다 읽음

이것이 Column Pruning

2️⃣ 압축 효율 , Compression

CSV: 텍스트 ( 자연어 ) 라 용량 큼

Parquet: 압축 (바이너리 ) + 인코딩 되어있어 용량 작음

특히 같은 값 , 비슷한 값에서 있어서 강한 강점을 보인다.

이것이 Compression. 보통 3~10배 차이 난다고 한다.

3️⃣ 스키마 내장

Parquet는

  • 타입 명확 (INT, FLOAT, STRING)

  • null 처리 명확

  • schema evolution 가능

CSV는

  • 전부 문자열로 시작

  • 타입은 읽는 엔진이 추론

→ 분석 정확성 차이 발생 가능

Parquet에서 “의미”는 어디에 있냐?

Parquet 파일은 운영 방식에 따라 무수히 많아 질 수 있다. 이 파일들에 각각 파일명을 부여하는 것 역시 쉬운 일이 아니고 그렇게 할 필요가 없다. 파일명에 의미를 두지 않기 때문이다. 대신 그 의미를 파일명이 아니라 폴더 경로에 있게 한다.

예시

/gold/sales/date=2026-03-01/part-00000.parquet
/gold/sales/date=2026-03-02/part-00000.parquet

여기서 의미는:

gold 레이어 / sales 테이블 / date 파티션 같은 식으로 논리적 파티션을 구분할 수 있다.

파일명 ( Part-00000 ) 은 중요하지 않다.

배치 데이터 상의 오류라면 해당 Date 에 대한 배치를 다시 돌리면 된다.

실제 Lakehouse 구조 예시

Bronze Layer
/bronze/events/ingest_date=2026-03-04/part-0000.parquet
Silver Layer
/silver/events_clean/date=2026-03-04/part-0000.parquet
Gold Layer
/gold/daily_metrics/date=2026-03-04/part-0000.parquet

이제 기업에서는 PB급 데이터가 존재하고 그 데이터 상에서 우리는 이제 필요한 것만 봐도 속도를 걱정해야 한다. 이를 위해 우리는 더 컴퓨터 친화적으로 데이터를 다뤄야민 저장비용, 속도 면에서 이점을 볼 수 있다. 물론 이 Parquet 를 또 한번 쉽게 다루게 해주는 엔진들 또한 출현하게 되었다.

하나의 데이터 안에서도 컴퓨터가 처리하기 쉬운 쪽, 사람이 처리하기 쉬운 쪽으로 나눠 각자에 맞는 역할을 하는 것이 현대 빅데이터의 올바른 업무 분할이 된 것이다.

profile
0 to 100 Data Engineer

1개의 댓글

comment-user-thumbnail
2026년 3월 28일

맛있네요

답글 달기