Parquet란?

파케이는 데이터 엔지니어링을 하다보면 굉장히 자주 접하는 포맷이다. ㅇ케이는 데이터 엔지니어링을 하다보면 굉장히 자주 접하는 포맷이다. 무엇인지는 알고있지만 정확히 알고 넘어가기 위해 따로 공부를 진행했다.

Parquet란?

파케이는 아파치에서 관리하는 오픈 소스 데이터 파일 형식이다. 자세히 알기 위해 공식문서의 내용을 참고했다.

Apache Parquet is an open source, column-oriented data file format designed for efficient data storage and retrieval. It provides high performance compression and encoding schemes to handle complex data in bulk and is supported in many programming language and analytics tools.

파케이는 효율적인 데이터 저장 및 검색을 위해 디자인된 컬럼 지향 데이터 파일 포맷이다. 복잡한 대량의 데이터를 다루기 위해 높은 압축률과 인코딩 체계를 지원하고 다양한 프로그래밍 언어와 분석 도구에서 사용 가능하다.

Parquet 주요 특징

파케이의 주요 특징은 다음 3가지가 대표적이다. 1.높은 압축률 2.분산처리에 최적화 파케이는 어떤 구조로 저장되어 있길래 이와 같은 특징을 가지는 것일까?

Parquet의 구조

파케이의 높은 압축률과 분산 처리의 강점은 구조에서 비롯되는데, 크게 Header,Block,Footer로 나뉜다.

Header

헤더에 저장된 데이터는 간단하다. 4Byte 길이의 'PAR1'가 저장되어 있는데, Magic Number 라고 부르며 해당 파일이 Parquet 형식임을 나타내는 것이다.

Block

블록에는 각 RowGroup을 저장한다. RowGroup은 ColumnChunk로 구성되어 있으며 각 Chunk는 Page 단위로 데이터를 기록하게 된다. RowGroup 내에서는 각 Column의 Min,Max,NullValueCount 값을 가지고 있는데, 해당 값을 통해서 PredictPushDown(RowGroupSkip)에 활용하게 된다.(해당 내용은 따로 다루겠다.) 각 Page는 단일 컬럼의 내용만 기록되어있는데, 이것이 높은 압축률의 핵심이다. 단일 컬럼의 내용은 동일한 데이터 타입으로 이뤄져 있을 것이다. 또 비슷한 내용들일 것이기 때문이다.

Footer

풋터에는 버전,스키마,block에 대한 메타 데이터가 저장되어 있다.

Parquet의 압축

파케이의 압축은 2단계의 과정을 거친다. 1.값을 인코딩한다. 이때 방법은 값의 차이를 저장하는 Delta Encoding, 반복 횟수를 저장하는 Run-Length Encoding, 자주 등장하는 값을 묶어서 저장하는 Dictionary Encoding 등이 있다. 2.인코딩 된 값을 snappy,gzip 등의 알고리즘으로 압축한다.

Parquet의 분산처리

파케이는 분산처리에 적합한 데이터 파일 형식이다. 우선 컬럼 지향 저장 방식의 영향이 크다. 컬럼 기반으로 저장하기 때문에 각 컬럼을 독립적으로 처리할 수 있어 분산 환경에서 병렬 처리에 유리하다. 또 데이터를 일정 크기의 RowGroup으로 저장하기 때문에 각 RowGroup을 독립적으로 처리할 수 있다. 이러한 특징으로 인해 Spark,Hadoop 과 같은 분산 처리 프레임워크에서 각 노드가 나누어 처리하기 좋은 구조다.

Predict Push Down

Predict Push Down은 파케이의 읽기 속도를 빠르게 해주는 중요한 기능이다. 위에서 RowGourp들은 Column의 집계 값을 가지고 있다고 했다. 이 집계 값을 가지고 데이터를 필터링 하는 기능이라고 생각하면 된다. 예를 들어 5 이상의 데이터를 보는 쿼리를 날리게 되면 Column의 Max 값이 5 미만인 데이터는 자동으로 제외된다. 여기에 Sorting을 더한다면 더욱 효과적으로 데이터를 필터링 할 수 있게 된다.

Parquet 설정

파케이의 block과 page 사이즈를 조절할 수 있다. 블록 사이즈가 커지면 RowGroup가 더욱 많은 데이터를 저장할 수 있다. 하지만 메모리에 저장하는 사이즈가 커지기 때문에 size를 너무 크게 하는 것은 바람직하지 않다. 더하여 hdfs의 블록 기본 사이즈인 128Mb보다 사이즈가 커진다면 hdfs에서 읽는 것이 불가능하다.
페이지의 사이즈는 row 검색과 연관된다. row 검색시 페이지의 디코딩이 발생하는데, 페이지 사이즈가 큰데 검색이 빈번하다면 디코딩 시간의 오버헤드를 피할 수 없을 것이다. 따라서 row 검색시 페이지 사이즈를 작게 하는 것이 유리하다. 페이지 사이즈가 너무 작다면 페이지의 수가 많아지게 될 것이다. 페이지가 늘어난다면 그에 따라 메타데이터의 증가로 이어지기 때문에 트레이드오프를 잘 고려하여 사이즈를 정해야 할 것이다.