Parquet 파일 마스터하기: 구조, 활용 사례, 그리고 주요 장점

Parquet 파일은 데이터를 행이 아닌 열 단위로 저장합니다. Apache Parquet 프로젝트에서는 이를 "효율적인 데이터 저장 및 검색을 위해 설계된 오픈 소스 열 지향 데이터 파일 형식"이라고 설명합니다. 이 한 가지 설계 방식의 차이 덕분에 파일 크기가 더 작고, 쿼리 속도가 더 빠르며, 더블 클릭으로 열기는 더 어렵습니다.
Parquet 파일이란 무엇인가요?
Parquet는 Apache 프로젝트로 관리되는 표 형식 데이터용 파일 형식입니다. 공식 문서에 따르면 이 형식은 "대용량의 복잡한 데이터를 처리하기 위해 고성능 압축 및 인코딩 스키마를 제공"합니다. 또한 이 형식은 "많은 프로그래밍 언어와 분석 도구에서 지원"된다고 덧붙입니다.
가장 결정적인 특징은 방향성입니다. CSV는 한 번에 한 행씩 기록합니다. 즉, 첫 번째 레코드의 모든 필드를 기록한 다음 두 번째 레코드의 모든 필드를 기록하는 방식입니다. 반면 Parquet는 한 번에 한 열씩 기록합니다. 첫 번째 열의 모든 값을 기록한 다음 두 번째 열의 모든 값을 기록합니다.
단순히 기술적인 차이처럼 들릴 수 있지만, 여기에는 두 가지 큰 결과가 따릅니다. 단일 열에 있는 값들은 서로 유사한 경향이 있어, 여러 유형이 섞여 있는 행 단위보다 훨씬 더 잘 압축됩니다. 또한 90개 열 중 3개 열만 필요한 쿼리를 실행할 때, 모든 행을 스캔하여 대부분을 버리는 대신 필요한 3개 열만 읽을 수 있습니다.
이 형식은 공식적으로 규격화되어 있습니다. Apache 문서에 따르면 "parquet-format 리포지토리는 데이터의 구조화 및 저장 방식을 정의하는 Parquet 파일 형식의 공식 사양을 호스팅"합니다.
Parquet 파일의 구조
엔벨로프(Envelope)
모든 Parquet 파일은 동일한 4바이트로 시작하고 끝납니다. 사양서에 따르면 시작 부분에 "4바이트 매직 넘버 'PAR1'"이 있고, 맨 끝에도 동일한 매직 넘버가 있습니다.
그 사이에는 데이터가 위치하며, 끝부분 근처에는 메타데이터가 있습니다. 닫는 매직 넘버 바로 앞에는 "파일 메타데이터의 바이트 단위 길이를 나타내는 4바이트(리틀 엔디안)"가 있습니다. 이 값은 리더에게 메타데이터 블록을 찾기 위해 뒤로 얼마나 이동해야 하는지 알려줍니다.
행 그룹(Row group)과 열 청크(Column chunk)
엔벨로프 내부에서 데이터는 두 번 분할됩니다. 사양서에서는 이 테이블을 "N개의 열이 있으며, M개의 행 그룹으로 분할된" 파일로 설명합니다.
행 그룹은 가로 슬라이스, 즉 행들의 묶음입니다. 각 행 그룹 내에서 각 열의 값들은 열 청크로 함께 저장됩니다. 따라서 90개의 열과 10개의 행 그룹이 있는 파일은 900개의 열 청크를 가지며, 각 청크는 단일 열의 연속된 값들로 구성됩니다.
이러한 이중 분할 덕분에 선택적 읽기가 가능해집니다. 쿼리는 일치하는 행을 포함할 가능성이 없는 행 그룹 전체를 건너뛴 다음, 남은 행 그룹에서 필요한 열 청크만 읽을 수 있습니다.
메타데이터가 끝에 위치하는 이유
헤더가 있을 것이라 예상하는 사람들에게는 이것이 의외일 수 있습니다. Apache 문서에서는 그 이유를 직접 설명합니다. "단일 패스 쓰기를 허용하기 위해 파일 메타데이터는 데이터 다음에 기록됩니다."
대규모 데이터 세트를 스트리밍하는 작성기는 모든 청크를 기록하기 전까지는 각 청크의 최종 바이트 위치를 알 수 없습니다. 메타데이터를 마지막에 배치하면 헤더를 수정하기 위해 다시 앞으로 돌아갈 필요가 전혀 없습니다.
읽기 패턴도 이 구조를 따릅니다. 문서에 따르면 파일 메타데이터에는 "모든 열 청크의 시작 위치"가 포함되어 있습니다. 또한 "리더는 먼저 파일 메타데이터를 읽어 관심 있는 모든 열 청크를 찾도록 설계되었습니다"라고 덧붙입니다.
Parquet의 용도
일반적으로 다음 네 가지 상황 중 하나에서 .parquet 파일을 접하게 됩니다.
데이터 웨어하우스 내보내기. 현대적인 웨어하우스에서 대형 테이블을 내보낼 때, 파일 크기를 관리하기 쉽기 때문에 이 형식이 기본값으로 자주 사용됩니다.
데이터 레이크 스토리지. 클라우드 오브젝트 스토리지에 있는 파일들이 이 형식을 흔히 사용합니다. 엔진이 모든 데이터를 다운로드하지 않고도 필요한 열의 하위 세트만 읽을 수 있기 때문입니다.
팀 간 데이터 전달. 데이터 엔지니어가 1년 치 거래 내역을 보낼 때, 몇 배는 더 클 CSV 대신 이 형식을 선택하는 경우가 많습니다.
분석 도구 간 상호 호환. 이 형식은 여러 언어와 도구에서 지원되므로, 중간에 변환 단계 없이 시스템 간에 이동할 수 있습니다.
공통적인 핵심은 크기입니다. CSV를 전송하기에 부담스러워지는 시점에서 Parquet는 당연한 선택이 됩니다.
Parquet vs CSV
| Parquet | CSV | |
|---|---|---|
| 방향성 | 열 지향 | 행 지향 |
| 텍스트 에디터에서 읽기 가능 여부 | 불가능 (바이너리 형식) | 가능 |
| 일반적인 파일 크기 | 열 압축을 통해 더 작음 | 동일한 데이터 대비 더 큼 |
| 일부 열만 읽기 | 해당 열 청크만 읽음 | 파일 전체를 읽음 |
| 데이터 타입 | 파일 메타데이터에 포함됨 | 파일을 여는 도구에 의해 유추됨 |
| 더블 클릭으로 열기 | 일반적으로 불가능 | 보통 스프레드시트에서 열림 |
| 가장 적합한 용도 | 대형 테이블, 반복적인 쿼리 | 소형 테이블, 빠른 확인, 범용적인 공유 |
데이터 타입 처리 방식은 주목할 만합니다. CSV는 00123이 숫자인지 문자열인지 알지 못하기 때문에, 가져올 때 앞에 붙은 0이나 날짜가 깨지는 경우가 많습니다. 반면 Parquet는 메타데이터에 타입을 기록하므로, 기록한 값 그대로 다시 읽어올 수 있습니다.
이 비교에서 행 지향 방식에 대한 내용은 CSV 설명서에서 반대 방향의 관점으로 다루고 있습니다. 탭으로 구분되는 변형 형식은 TSV 분석에서 다룹니다.
주요 장점
실질적으로 배가되는 압축률. 유사한 값을 서로 이웃하게 저장하면 인코더가 처리할 수 있는 여지가 훨씬 많아집니다. Apache 문서에서는 이를 "고성능 압축 및 인코딩 스키마" 덕분이라고 설명합니다.
열 정리(Column pruning). 90개 열 중 3개 열만 읽을 때, 90개 열 전체가 아닌 대략 3개 열만큼의 I/O 비용만 발생합니다.
행 그룹 건너뛰기. 메타데이터가 각 행 그룹에 무엇이 있는지 기록하므로, 리더는 데이터에 접근하기도 전에 전체 슬라이스를 건너뛸 수 있습니다.
유지되는 데이터 타입. 스키마가 파일 내부에 함께 이동하므로 날짜는 날짜로 유지되고 식별자는 앞에 붙은 0을 그대로 유지합니다.
단일 패스 쓰기. 메타데이터가 끝에 위치하므로 매우 큰 파일도 스트림 형태로 기록할 수 있습니다.
광범위한 지원. 문서에 언급된 대로 "많은 프로그래밍 언어와 분석 도구"에서 지원하므로, 호환성 문제로 막힐 일이 거의 없습니다.
Parquet의 한계
Parquet는 저장과 검색을 해결해 줍니다. 하지만 파일에 실제로 무엇이 들어 있는지에 대한 의문은 해결해 주지 못합니다.
바이너리 형식이므로 눈으로 바로 훑어볼 수 없습니다. CSV를 열어 매출 열이 총매출인지 순매출인지 확인하는 데는 5초면 충분합니다. 하지만 바이너리 파일은 내용을 조금이라도 보려면 먼저 도구가 필요합니다.
또한 소규모 데이터에는 적합하지 않습니다. 200행짜리 조회용 테이블의 경우, 메타데이터 오버헤드와 도구 사용의 번거로움이 압축으로 얻는 이점보다 큽니다. 이럴 때는 CSV가 더 나은 형식이며, 이를 인정하는 것이 Parquet를 잘 활용하는 방법 중 하나입니다.
그리고 데이터의 품질을 보장하지는 않습니다. 완벽한 타입으로 정의되고 효율적으로 압축된 엉터리 데이터가 파일에 담길 수도 있습니다. 중복된 레코드, 두 가지 통화가 섞여 있는 통화 열, 3월에 스키마가 변경된 고객 ID 등이 그 예입니다. 이 형식은 데이터의 재현성을 보장할 뿐, 정확성을 보장하지는 않습니다.
엔지니어가 아닌 사용자가 Parquet 파일을 다루는 방법
이 부분이 실제 업무에서의 공백입니다. 대부분의 비즈니스 도구는 스프레드시트를 전제로 하므로, .parquet 파일은 CSV처럼 쉽게 열리지 않습니다.
가장 실용적인 방법은 변환 단계를 거치는 것입니다. 파일을 생성한 사람에게 실제로 필요한 열만 CSV나 Excel로 추출해 달라고 요청하거나, Parquet를 지원하는 도구를 사용해 직접 변환하세요. 압축의 이점은 사라지겠지만, 데이터를 로컬 컴퓨터로 가져와 범위를 좁힌 후에는 크게 상관없는 문제입니다.
그 이후부터는 일반적인 분석 작업입니다. Powerdrill Bloom의 요금제 페이지에는 Excel, CSV, PDF 및 문서 업로드 기능이 나열되어 있으므로, 변환된 추출 파일을 바로 업로드할 수 있습니다. 쿼리를 작성하는 대신 자연어로 질문을 던질 수 있습니다. CSV AI assistant가 이 과정을 지원하며, 데이터를 직접 내보내는 것보다 가져오는 것이 더 나은 경우에는 data connectors를 활용할 수 있습니다.
기억해야 할 차이점은 Parquet가 여러분의 작업 이전 단계에서 결정된 저장 방식이라는 점입니다. 이는 분석 도구가 아니며, 파일이 여러분의 책상에 도달했을 때 다른 형식으로 변환하는 것은 임시방편이 아니라 지극히 정상적인 과정입니다.
결론
Parquet는 파일 끝부분에 스키마와 인덱스가 있는 열 지향 저장 방식입니다. 이러한 설계 덕분에 압축률, 선택적 읽기, 신뢰할 수 있는 데이터 타입을 얻을 수 있으며, 이것이 대용량 데이터에서 기본 형식으로 자리 잡은 이유입니다.
하지만 가시성은 제공하지 않습니다. 저장이 아닌 해답이 필요한 사람에게 파일이 전달되는 순간, 유용한 다음 단계는 대개 범위를 좁혀 추출한 데이터와 질문을 준비하는 것입니다.
현재 그러한 단계에 계신다면, 변환된 파일로 Powerdrill Bloom을 사용해 보고, 먼저 차트로 변환하는 작업부터 시작해 보세요.
자주 묻는 질문
Parquet 파일은 어떤 용도로 사용되나요?
Parquet는 대규모 표 형식 데이터 세트를 효율적으로 저장하는 데 사용됩니다. 데이터 웨어하우스 내보내기, 데이터 레이크 스토리지, 팀 간 데이터 전달, 분석 도구 간 상호 호환 등에 흔히 사용됩니다. 압축률이 뛰어나고 선택한 열만 읽을 수 있도록 지원하기 때문입니다.
Parquet가 CSV보다 더 나은가요?
반복적으로 쿼리하는 대형 테이블의 경우 그렇습니다. 크기가 더 작고, 데이터 타입을 보존하며, 열 정리를 지원하기 때문입니다. 반면 빠르게 확인하거나 널리 공유해야 하는 소형 테이블의 경우, 텍스트 형식이라 어디서나 쉽게 열리는 CSV가 더 편리합니다.
Excel에서 Parquet 파일을 열 수 있나요?
Parquet는 텍스트가 아닌 바이너리 형식이므로 더블 클릭으로는 열 수 없습니다. 일반적으로 CSV나 Excel로 먼저 변환하거나, Parquet를 직접 읽을 수 있는 도구를 사용하는 방식을 취합니다.
Parquet 메타데이터는 왜 파일 끝에 저장되나요?
Apache 문서에서는 "단일 패스 쓰기"를 허용하기 위해 메타데이터가 데이터 다음에 기록된다고 설명합니다. 대규모 데이터 세트를 스트리밍하는 작성기는 최종 청크 위치를 미리 알 수 없으므로, 메타데이터를 마지막에 기록하여 헤더를 다시 수정하는 번거로움을 피합니다.
Parquet에서 행 그룹(row group)이란 무엇인가요?
행 그룹은 테이블의 가로 슬라이스입니다. 사양서에서는 파일의 열이 "M개의 행 그룹으로 분할"되어 있으며, 각 열은 각 그룹 내에서 별도의 청크로 저장된다고 설명합니다. 이러한 레이아웃 덕분에 리더는 필요하지 않은 그룹과 열을 모두 건너뛸 수 있습니다.