
Parquet 파일은
Parquet은 쓰기보다 읽기(분석 쿼리)에 올인한 포맷
그래서 부분 수정(Update)을 포기하고 전체 rewrite를 선택한 것이다. (선택과 집중)
Paquet : row 1개 바뀌어도 parquet 파일 전체 다시 써야 함
특히 Parquet 는 사람이 읽기 편한 파일도 아니다. 그저 컴퓨터 기준 읽기가 가장 최적화된 포맷이다. 그래서 데이터 레이크 구조 자체는 Parquet 파일 형식을 대부분 채택한다.
그러나 사람이 “직접” 보고 의사결정 단계라면 CSV가 편하다
nvim, Excel, Google Sheets, Datagrip 다 바로 열림
바이너리 깨짐 없음
구조 직관적
슬랙에 파일 던지기 쉬움
Git diff 가능
-> "이 row가 왜 이렇게 나왔지?" 디버깅 쉬움
모델 입력 샘플 확인
일부 row 수정
테스트용 가공
수정 가능
그럼에도 Parquet 를 쓰는 이유는 가장 중요한 '속도'이다.
Parquet는 컬럼 단위로 저장하는 것을 확인했었다.
→ 여러 칼럼 중에서 메타데이터를 통해 필요한 컬럼만 읽음
→ 대용량에서 큰 속도 차이를 보인다.
SELECT user_id FROM file.parquet
→ user_id 컬럼만 읽음
CSV는 전체 파일 다 읽음
이것이 Column Pruning
CSV: 텍스트 ( 자연어 ) 라 용량 큼
Parquet: 압축 (바이너리 ) + 인코딩 되어있어 용량 작음
특히 같은 값 , 비슷한 값에서 있어서 강한 강점을 보인다.
이것이 Compression. 보통 3~10배 차이 난다고 한다.
Parquet는
타입 명확 (INT, FLOAT, STRING)
null 처리 명확
schema evolution 가능
CSV는
전부 문자열로 시작
타입은 읽는 엔진이 추론
→ 분석 정확성 차이 발생 가능
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 를 또 한번 쉽게 다루게 해주는 엔진들 또한 출현하게 되었다.
하나의 데이터 안에서도 컴퓨터가 처리하기 쉬운 쪽, 사람이 처리하기 쉬운 쪽으로 나눠 각자에 맞는 역할을 하는 것이 현대 빅데이터의 올바른 업무 분할이 된 것이다.
맛있네요