Parquet 파일의 작동 방식과 주요 특징|보완 방법 정리

기존 데이터를 저장할 때 행(row) 단위로 저장하는 방법과 다르게, 칼럼(column) 단위로 저장하는 Parquet의 작동 방식과 장점 및 단점 보완 방법을 총 정리합니다. 데이터를 읽고 쓰는 효율성을 높이고 저장 공간을 절약하기 위해 특별히 설계된 Parquet은 최근 빅데이터에서 중요한 구조로 자리 잡았습니다.

 

 

Parquet의 작동 방식

 

Parquet은 칼럼형 저장 구조입니다. 각 칼럼은 추가적인 페이지 단위(기본 단위)로 나뉘며, 각 페이지는 데이터를 압축한 상태로 저장됩니다. 이 구조 덕분에 읽기 성능이 향상되고, 특정 칼럼만 필요할 때 전체 데이터를 로드할 필요가 없습니다.

 

예를 들어, 테이블이 이름(name), 나이(age), 도시(city)라는 칼럼을 포함한다면, Parquet은 다음과 같이 저장합니다:

 

특징	일반 DB 테이블 (Row-Based)	Parquet 파일 (Columnar)
저장 구조	모든 열 데이터를 한 번에 저장	각 열(Column)의 데이터를 따로 저장
데이터 저장 형태	- Row 1: [1, Alice, 25, Seoul] - Row 2: [2, Bob, 30, New York] - Row 3: [3, Charlie, 35, London]	- Column 1 (ID): [1, 2, 3] - Column 2 (Name): [Alice, Bob, Charlie] - Column 3 (Age): [25, 30, 35] - Column 4 (City): [Seoul, New York, London]
읽기 방식	- 전체 행을 읽은 후 필요한 열을 선택	- 필요한 열만 읽음 (예: Age 컬럼만 읽기 가능)
용도	- 트랜잭션 처리에 적합 (읽기/쓰기 균형 필요)	- 분석 및 조회 작업에 적합 (읽기 최적화)
목정	- OLTP(Online Transaction Processing), 트랜잭션 중심 작업에 최적화 - 데이터를 빠르게 추가, 수정, 삭제	- OLAP(Online Analytical Processing), 분석 작업에 최적화 - 대규모 데이터 분석 및 읽기 작업

 

 

이와 같은 작동 방식으로 아래와 같은 때 Parquet 파일을 사용합니다:

 

• 데이터 분석: 빠른 읽기 성능이 필요한 대규모 데이터 분석 작업
• 데이터 웨어하우스: Spark, Hive, AWS Redshift 등의 백엔드 스토리지
• 데이터 아카이빙: 압축된 형태로 대량의 데이터를 보관할 때
• Delta Lake와 함께 사용: Delta Table은 내부적으로 Parquet 파일을 사용하여 성능과 관리성을 높입니다.

DBMS와 Parquet는 상호 보완적으로 DBMS는 은행 거래 시스템과 같이 빠른 트랜잭션 처리가 필요할 때 사용합니다. 반대로 Parquet은 데이터를 저장하고 분석하고 실시간 매출은 분석해야 하는 상황에서 효율적입니다.

 

 

 

Parquet의 주요 특징

구분	설명
컬럼형 스토리지 (Columnar Storage)	- 데이터를 행(row) 단위로 저장하는 대신 컬럼 단위로 저장합니다. - 분석 작업에서는 특정 컬럼에만 접근하는 경우가 많아, 필요한 데이터만 읽을 수 있으므로 속도가 빠르고 비용이 절감됩니다.
압축 및 저장 공간 최적화	- 컬럼 단위로 데이터를 저장하기 때문에, 동일한 데이터 유형끼리 모여 있어 압축 효율이 높습니다. 저장 공간을 절약하면서도 빠른 입출력 속도를 제공합니다.
스키마와 메타데이터 지원	- 데이터를 저장할 때 스키마 정보와 함께 저장되므로, 데이터 구조를 쉽게 이해하고 관리할 수 있습니다. - 메타데이터는 스키마, 열 통계, 범위 등 다양한 정보를 포함하여 빠른 조회를 지원합니다.
빅데이터 분석에 최적화	- Spark, Hive, Impala 등 빅데이터 프레임워크에서 기본적으로 지원하며,  대용량 데이터 분석에 최적화되어 있습니다. - 대규모 읽기 작업(예: 집계, 필터링)에 유리합니다

 

*Parquet 장점

1. 필요한 데이터만 읽으므로 I/O 비용을 효율적으로 관리할 수 있습니다.
2. 여러 빅데이터 프레임워크와 호환되어, 분산 환경에서 작업할 때 특히 유리합니다.
3. 데이터 크기를 압축을 통해 줄이고 처리 속도를 높이는 데에 최적화되어 있습니다.

 

*Parquet 단점

1. 트랜잭션 관리 부족 : 데이터를 추가, 수정, 삭제할 때 데이터 무결성(Atomicity, Consistency)을 보장하지 않습니다.
2. 동시성 문제: 여러 사용자가 동시에 데이터를 쓰거나 수정하면 충돌이 발생할 수 있습니다.
3. 삭제 및 수정 어려움: 데이터를 삭제하거나 수정하려면 전체 파일을 재작성해야 합니다.

 

데이터를 삭제하거나 업데이트해야 할 경우 일반적으로 재작성(rewrite)을 해야 합니다. Parquet 파일의 특성상, 직접적으로 특정 행만 삭제하거나 수정하는 것은 불가능하기 때문입니다. 따라서 Parquet 파일은 수정이나 삭제가 잦은 경우네는 비효율적입니다.

 

 

Parquet 단점 보완 방법

 

Parquet의 문제점을 해결하기 위해 단독 사용을 최소화하고, 아래의 시스템을 함께 활용합니다.

 

• Delta Lake: ACID 트랜잭션 지원
• Apache Hudi: 업데이트와 삭제 작업 최적화
• Apache Iceberg: 복잡한 테이블 관리에 적합

이 중에서 Delta Lake로 어떻게 문제점들을 해결하는지 정리합니다.

기능	Parquet	Delta Lake
ACID 트랜잭션	지원하지 않음	완전 지원
데이터 변경 (Update)	전체 파일 재작성 필요	효율적인 데이터 변경 가능
데이터 삭제 (Delete)	전체 파일 재작성 필요	특정 조건으로 삭제 가능
동시성 처리	충돌 발생 가능	동시 작업 지원 (Write Isolation)
스키마 진화	제한적	유연한 스키마 변경 지원
시간여행 (Time Travel)	지원하지 않음	지원 (이전 버전 데이터 조회 가능)
데이터 무결성	관리 도구 필요	Delta의 내부 로깅으로 자동 관리

결국 데이터는 Parquet 파일 형식으로 저장하지만,  Delta Lake는 트랜잭션 로그를 별도 관리해서 ACID 트랜잭션과 데이터 관리 기능을 지원합니다. 이 로그는 모든 변경 사항을 기록하고 이 로그를 활용해 데이터를 재구성하거나, 이전 버전을 조회할 수 있습니다.

/path/to/delta_table/
├── part-0001.parquet
├── part-0002.parquet
├── _delta_log/
    ├── 00000000000000000001.json
    ├── 00000000000000000002.json

 

Delta Lake는 로그가 무한히 쌓이는 문제를 방지하기 위해 최적화(Compaction) 및 청소(Cleanup) 메커니즘을 제공합니다.

 

*결론

여러 시스템에서 데이터를 인터페이스로 받아 업데이트가 자주 발생하는 데이터 레이크 환경에서는, 일반적인 Parquet 방식을 단독으로 사용하는 것은 비효율적이고 위험할 수 있습니다.

 

Delta Lake, Apache Hudi, 또는 Apache Iceberg와 같은 ACID 트랜잭션을 지원하는 프레임워크를 활용하면 효율성과 안정성을 확보할 수 있습니다. 데이터 레이크에서의 데이터 관리 요구사항에 따라 적합한 기술을 선택하는 것이 중요합니다.