빅데이터를 다루다 보면 Parquet(파케이) 이라는 파일 형식을 자주 접하게 됩니다. 이 글에서는 Parquet 파일이 무엇이고 왜 빅데이터 환경에서 널리 쓰이는지, 다른 파일 형식과 비교하여 어떤 장점이 있는지 등을 자연스럽게 풀어서 설명해 보겠습니다. Parquet의 역사부터 기술적인 구조, 실제 활용 사례와 베스트 프랙티스까지 하나씩 알아볼 테니, 빅데이터 초보자라도 편하게 읽어보세요.
Parquet(아파치 파케이)는 아파치 하둡 생태계에서 탄생한 오픈 소스 컬럼 지향(column-oriented) 데이터 저장 형식입니다 . 쉽게 말해, 데이터를 저장할 때 행(row) 단위가 아니라 열(column) 단위로 저장하는 특별한 파일 포맷이죠. 2013년 트위터(Twitter)와 클라우데라(Cloudera)가 처음 공동 개발했고, 이후 아파치 소프트웨어 재단(ASF)으로 기부되어 활발히 발전해 왔습니다 . 이름 “파케이(Parquet)”는 프랑스어로 “나무 바닥무늬”를 뜻하는데, 데이터베이스의 “바닥 층(layer)”을 재미있는 모양으로 깐다는 의미에서 지어졌다고 합니다 (일종의 개발자 유머입니다!). 역사적으로 Parquet는 구글의 Dremel이라는 거대 데이터 분석 시스템 논문에서 영감을 받았습니다. 또 하둡 창시자 더그 커팅이 만든 이전의 컬럼 저장 포맷인 Trevni의 단점을 개선하고자 고안되었죠 . 첫 공식 버전(Parquet 1.0)은 2013년 7월에 나왔고, 2015년 4월에는 아파치의 톱 레벨 프로젝트로 승격되면서 하둡 생태계의 표준 컬럼형 포맷 중 하나로 자리 잡았습니다 . 요약하면, Parquet는 “대용량 데이터 분석을 위해 태어난 컬럼 기반 저장 파일”이라고 정의할 수 있습니다 .
Parquet의 가장 큰 특징은 데이터를 열 단위로 저장하는 구조입니다. 일반적인 CSV나 JSON 같은 행 지향(row-oriented) 포맷에서는 한 레코드(행)에 속한 모든 필드 값을 연달아 기록합니다. 반면 Parquet 같은 컬럼 지향 포맷에서는 동일한 컬럼의 값들을 한 곳에 모아 연속적으로 저장합니다 . 컬럼 지향 저장의 개념: 위 그림의 위쪽은 행(row) 기반 저장을, 아래쪽은 열(column) 기반 저장을 나타냅니다. 행 기반에서는 한 주문의 모든 정보(주문 ID, 상품, 날짜, 금액 등)를 한 줄에 기록하지만, 열 기반에서는 주문 ID만 쭉 모아 저장하고, 상품명만 모아 별도로 저장하는 식입니다. 이렇게 하면 특정 열만 필요할 때 해당 부분만 읽으면 되므로 효율적입니다. 이 열 기반 설계 덕분에 Parquet는 대용량 데이터의 부분적인 읽기 성능을 극대화할 수 있습니다. 예를 들어 100개의 열로 이루어진 거대한 테이블에서 5개 열만 분석할 때, Parquet 파일은 그 5개 열에 해당하는 데이터만 디스크에서 읽어오면 되기 때문에 불필요한 I/O를 크게 줄여줍니다 . 실제로 Databricks의 벤치마크에 따르면 Parquet는 전통적인 행 기반 포맷보다 10배에서 최대 100배까지 읽기 속도가 빠른 경우도 있었다고 합니다 . 이것이 가능한 이유는, Parquet가 각 열을 연속된 메모리 블록에 저장하기 때문에 디스크 엑세스가 줄고 CPU 캐시 효율이 높아지기 때문이에요 .
또 다른 기술적 장점은 파일 내에 스키마(schema)와 메타데이터를 함께 저장한다는 것입니다 . 즉, Parquet 파일 자체에 데이터 구조 정의가 포함되어 있어 일종의 “Self-describing (자체 설명)” 형식을 이룹니다. 이를 통해 스키마 진화(schema evolution)도 지원하는데, 오래 운영되는 데이터에서는 컬럼이 추가되거나 유형이 변경되는 일이 생기잖아요. Parquet는 새로운 컬럼을 추가하더라도 기존 파일들을 읽는 데 문제가 없도록 이전 스키마와 호환시키는 기능이 있습니다 . 예를 들어, 오늘부터 새 컬럼 하나가 추가되더라도 Parquet 리더기들은 예전 데이터와 새 데이터를 함께 처리할 수 있습니다. (물론 완전 자유로운 건 아니지만 “백워드/포워드 호환” 정도는 가능합니다 .)
압축과 인코딩도 Parquet의 핵심 기술 요소입니다. Parquet는 열별로 최적화된 압축을 적용하는데, 대표적으로 많이 쓰이는 압축 코덱은 Snappy, Gzip, Brotli, LZ4, ZSTD 등이 있습니다 . 각 컬럼의 데이터 특성에 따라 압축을 다르게 선택할 수 있어요. 예를 들어 문자열이 많은 컬럼은 사전 인코딩(딕셔너리 인코딩)을 통해 동일한 값들은 작은 사전 키로 치환하고 , 정수 숫자가 많은 컬럼은 비트 패킹이나 런-렝스 부호화(RLE) 같은 기법으로 반복 패턴을 압축합니다 . 이렇게 맞춤형 인코딩을 하면 압축 효율이 높아지죠. 실제로 Parquet를 사용하면 동일한 데이터를 CSV로 저장할 때보다 파일 크기가 보통 2~5배 정도 작아집니다 . 저장 공간이 줄어들 뿐만 아니라 읽어야 할 바이트도 줄어드니 그만큼 쿼리 속도도 빨라지고 비용도 절감되는 효과가 있습니다. 마지막으로, Parquet 파일 내부를 조금 더 들여다보면 Row Group이라는 단위로 데이터가 묶여 있고, 그 안에 각 컬럼별 Chunk들이 있으며, 그 컬럼 청크는 다시 페이지 단위로 구성됩니다 . 이 구조 덕분에 병렬 처리에 유리합니다. 예를 들어 하둡이나 스파크가 Parquet 파일을 처리할 때 여러 노드가 서로 다른 Row Group을 동시에 읽어서 병렬로 처리할 수 있죠. 그래서 대용량 배치(batch) 처리에 매우 효율적인 포맷으로 설계되어 있습니다 . 정리하면, Parquet의 기술적 구조는 “열 지향 + 파일 내 스키마/메타데이터 + 열별 압축/인코딩 + 병렬처리 친화적 구조”로 요약할 수 있습니다.
이제 왜 이렇게까지 해서 Parquet를 쓰는지, 빅데이터 분석 워크플로우 관점에서 그 이유를 알아볼게요. 핵심은 “효율성” 한 마디로 정리됩니다. 빅데이터 환경에서는 데이터의 양이 방대하기 때문에, 저장 공간과 I/O, 처리 시간 모든 면에서 효율이 생명입니다. Parquet는 앞서 설명한 대로 컬럼 단위 저장과 강력한 압축 덕분에 이러한 요구에 딱 들어맞습니다. 첫째, 쿼리 성능 향상 때문입니다. 빅데이터 분석 작업은 보통 큰 데이터셋에서 일부 컬럼만 추려서 집계하거나 필터링하는 경우가 많습니다. Parquet라면 필요한 열만 읽으면 되니, 전체 데이터를 몽땅 읽어야 하는 CSV나 JSON에 비해 현격하게 빠른 쿼리가 가능해요. 실제로 OLAP(온라인 분석 처리) 같은 워크로드에서 Parquet는 CSV/JSON 대비 10배 이상 빠른 질의 응답 시간을 보여주곤 합니다 . 빅데이터 세계에서 10배 속도 차이는 엄청난 것이죠. Spark 등의 분산엔진은 Parquet 파일에서 프루닝(pruning), 즉 필요한 부분만 골라 읽는 최적화를 자동으로 해주기 때문에, 대규모 데이터 집합을 실시간에 가깝게 인터랙티브하게 다룰 수 있게 해줍니다. 둘째, 스토리지 비용 절감 및 데이터 전송량 감소입니다. 데이터가 크면 클수록 저장 용량과 네트워크 전송 비용이 무시할 수 없는데, Parquet는 뛰어난 압축으로 데이터를 훨씬 작게 만들어줍니다. 예를 들어 1TB짜리 원본 CSV 데이터를 Parquet로 변환하면 수백 GB대로 줄어들 수 있어요 . 클라우드 환경에서 저장비용과 쿼리 비용(예: AWS Athena나 Google BigQuery 같은 서비스는 스캔한 데이터 양으로 비용을 청구)이 직접 절감되는 효과가 있습니다 . 다시 말해 “덜 읽고, 덜 저장하고, 덜 전송하니 돈과 시간이 준다”는 점에서 기업들이 선호합니다. 셋째, 확장성과 호환성입니다. Parquet는 하둡 에코시스템에서 태어난 이후로 사실상 업계 표준 컬럼 포맷 중 하나가 되었습니다 . 덕분에 대부분의 빅데이터 도구가 Parquet를 지원하며, 한 번 Parquet로 저장해두면 여러 시스템에서 두루 활용할 수 있어요. 예를 들어, Hadoop HDFS에 저장된 Parquet 파일을 Spark, Hive, Presto, AWS Athena, Google BigQuery 등이 다 같이 읽을 수 있습니다 . 심지어 Pandas나 R 같은 언어의 데이터 분석 라이브러리에서도 Parquet 파일을 손쉽게 불러올 수 있죠 . 이러한 광범위한 호환성은 데이터 레이크나 레이크하우스 아키텍처에서 Parquet가 기본 포맷으로 자리잡는 이유입니다 . 클라우드 객체 스토리지(S3, GCS 등)에 Parquet로 데이터를 쌓아두면, 나중에 어떤 엔진으로 분석하든 다 접속해서 읽을 수 있으니까요. 넷째, 스키마 관리와 복잡한 데이터 구조 지원입니다. Parquet는 아까 말했듯이 파일에 스키마를 내장하고 있어 데이터 구조를 엄격히 정의합니다. 이는 데이터 품질 유지와 일관성 측면에서 큰 장점이에요. JSON처럼 자유도가 높은 포맷은 데이터 구조가 제각각 될 위험이 있는데, Parquet는 스키마에 어긋나는 데이터는 쓸 수 없으니 파이프라인에 오류가 줄어듭니다. 또한 Parquet는 내부적으로 중첩된 구조(nested structure)도 다룰 수 있도록 설계되어 있어서, 계층적인 복잡한 데이터를 펼쳐서 저장하고 질의할 수 있습니다 . 예컨대 JSON으로 표현된 배열이나 구조체가 있는 복잡한 데이터를 Parquet로 저장하면, 하위 필드들도 컬럼처럼 취급하여 효율적으로 쿼리할 수 있어요. 이런 유연성 때문에 IoT 로그, 웹 이벤트 로그처럼 반정형 데이터까지 Parquet로 변환해 두는 경우가 많습니다. 이처럼 Parquet는 빅데이터 워크플로우의 핵심 요구 사항인 “빠른 읽기, 적은 저장, 쉬운 통합”을 충족하기 때문에 널리 쓰이고 있습니다. 한마디로, “데이터가 클수록 Parquet의 진가가 발휘된다”고 볼 수 있겠네요.
그렇다면 Parquet의 효율을 좀 더 실감하기 위해, 흔히 쓰이는 다른 파일 포맷들과 비교를 해보겠습니다. 여기서는 CSV, JSON, Avro, ORC 네 가지와 간략히 견줘볼게요. • CSV: 콤마로 구분된 값들로 이루어진 텍스트 기반 행 지향 포맷입니다. 사람이 직접 메모장으로 열어볼 수도 있을 만큼 단순하죠. 그러나 대용량에는 가장 비효율적입니다. 모든 데이터가 문자열로 저장되기 때문에 같은 값도 글자로 다 써야 하고, 숫자 TRUE/FALSE도 "true" 혹은 "false" 문자열로 저장되니 공간 낭비가 큽니다 . 스키마(데이터 타입 정보)가 파일 안에 없어서 데이터를 쓸 때도 읽을 때도 별도 처리나 형 변환이 필요해요 . 또한 필요한 컬럼만 골라 읽는 최적화가 불가능하므로, 거대한 CSV를 분석하려면 매번 전 컬럼을 다 파싱해야 하죠. 요약하면 “휴대성은 좋지만 대용량 처리 성능은 최악”인 포맷입니다. 작은 데이터나 일회성 작업, 혹은 사람이 직접 내용을 들여다봐야 할 때나 유용하고, 빅데이터 분석에는 부적합합니다 . • JSON: 중괄호 {}와 배열 []로 구조화된 텍스트 기반 포맷으로, 데이터 자체에 키-값 구조가 있어 반정형(semi-structured) 데이터를 표현하기 좋습니다. 다만 CSV와 마찬가지로 모든 게 문자로 저장되기 때문에 파일 크기가 크고 파싱 비용이 큽니다. JSON은 스키마가 암묵적이라 유연하지만, 그 때문에 대용량 분석 시엔 오히려 발목을 잡습니다. 빅데이터 환경에서 JSON을 그대로 쌓아두면, 나중에 중복되는 키 이름들까지 모두 저장해야 해서 심각한 공간 낭비가 생기고, 쿼리할 때도 느립니다 . 한 가지 장점은 계층적 데이터를 표현하기 수월하다는 건데, 사실 Parquet 같은 포맷도 복잡한 구조를 지원하므로 JSON의 이점이 크게 부각되지 않아요. JSON은 로그나 설정파일처럼 사람이 바로 읽어야 하는 용도에 적합하고, 거대한 데이터를 저장해 놓고 분석하는 포맷으로는 잘 쓰지 않습니다 . • Avro: 아브로는 Apache Avro라는 이진 바이너리 포맷입니다. Parquet와 달리 행 지향(row-based) 저장이고, 하나의 연속된 레코드 스트림으로 데이터를 씁니다. 하지만 CSV/JSON과 큰 차이는 스키마를 명시한다는 점이에요. Avro 파일에는 JSON 형태로 정의된 스키마가 함께 저장되어 있어서, 데이터를 읽을 때 그 스키마에 따라 타입을 해석합니다. 덕분에 CSV보다 공간 효율이 좋고 이진 데이터라서 파싱도 빠릅니다 . 주 용도는 스트리밍과 메시지 전송입니다; 예를 들어 카프카(Kafka) 메시지나 로그 데이터를 실시간 전송할 때 Avro 포맷을 쓰면 부피도 줄고 수신 측에서 스키마 검증도 가능하죠. 그러나 대규모 배치 분석용으로는 Avro보다 Parquet/ORC를 선호합니다. 이유는 Avro는 행 단위 처리에 최적화되어 있어, 몇 가지 컬럼만 조회해도 모든 데이터를 읽어야 하고 압축 효율도 컬럼 포맷보다 떨어집니다 . 다행히 Avro 저장 데이터는 나중에 Parquet로 변환하기도 쉬운 편이어서, 실시간 처리에는 Avro, 최종 저장은 Parquet 이런 식으로 파이프라인을 구성하기도 합니다 . • ORC: ORC(Optimized Row Columnar)는 Parquet와 마찬가지로 컬럼 지향 저장을 하는 빅데이터 전용 포맷입니다. 원래 Hortonworks에서 Hive의 저장 포맷으로 개발한 것이며, Parquet의 가장 직접적인 라이벌이라 할 수 있어요. 기술 구조와 장단점이 Parquet와 매우 유사합니다 . 컬럼별 압축, 스키마 내장, 대용량 최적화 등의 특징을 공유하고, 읽기 성능도 비슷하게 우수합니다 . ORC는 특히 Hive나 Presto 같은 하둡 생태계에서 많이 쓰였고, Parquet는 Spark나 다양한 클라우드 플랫폼에서 더 인기가 높았습니다(물론 두 포맷 다 상대 생태계에서 지원됩니다). 구체적인 차이를 꼽자면, ORC는 내부적으로 스트라이프(stripe)라는 단위와 인덱스를 포함하고 있어서 파일 내에서 특정 행 범위를 건너뛰는 등의 최적화가 있습니다. 한편 Parquet도 row group마다 통계 메타데이터를 둬서 비슷한 최적화를 합니다. 압축률 면에서는 ORC가 약간 더 높다는 의견도 있고요 . 전반적으로 “Parquet나 ORC나 큰 차이 없다”가 업계의 평가입니다. 둘 다 컬럼 포맷의 대표주자로, 전통적인 Hadoop 환경(온프레미스)에서는 ORC도 많이 쓰이지만, 클라우드 데이터 레이크나 다양한 툴 호환성 측면에서는 Parquet가 좀 더 범용적으로 쓰이는 추세입니다 . 무엇보다 Parquet는 Spark의 기본 파일 포맷이고, AWS나 구글 같은 곳에서도 Parquet 예제를 흔히 제공하기 때문에 자연스럽게 표준처럼 자리잡았습니다. 정리하면, 대용량 분석을 할 때는 Parquet나 ORC 같은 컬럼 지향 이진 포맷이 최고 성능을 내고, 실시간 처리나 잦은 기록/업데이트가 필요할 때는 Avro 같은 행 지향 이진 포맷이 어울리며, 소규모나 사람이 볼 때는 CSV/JSON 같은 텍스트 포맷이 편리합니다 . 실제 하둡 환경에서 권장되는 포맷 우선순위도 “ORC/Parquet > Avro > 순차파일(SequenceFile) > 텍스트(CSV 등)” 순으로 꼽히곤 합니다 . 그만큼 Parquet는 성능과 효율 면에서 상위권에 속하는 포맷이라 볼 수 있겠네요.
Parquet의 성공 요인 중 하나는 빅데이터 에코시스템에서의 폭넓은 호환성입니다. 앞서도 언급했듯, 사실상 대부분의 데이터 처리 도구들이 Parquet를 지원하거나 기본 포맷으로 활용하고 있는데요 . 몇 가지 대표적인 예를 들어볼게요. • 아파치 스파크(Apache Spark): Spark는 Parquet를 1급 시민으로 취급합니다. DataFrame을 Parquet로 쉽게 저장하고 불러올 수 있고, 기본 설정도 Parquet를 선호하죠. Spark SQL에서 Parquet테이블을 만들면 컬럼 통계 메타데이터를 활용한 프루닝이나 필터 푸시다운 등의 최적화를 자동으로 수행합니다. 사실 Spark에서 “데이터소스를 지정하지 않고 파일 저장”하면 기본이 Parquet일 정도로 밀접합니다. • 하둡/Hive: Hadoop HDFS 파일 시스템 위에 데이터 웨어하우스를 구축하는 Hive에서도 Parquet를 테이블 저장 형식으로 많이 사용합니다. 원래 Hive는 ORC를 기본 사용하지만 Parquet 테이블도 완벽히 지원하고, 스토리지 포맷을 Parquet로 지정하면 됩니다. MapReduce나 Tez 작업을 할 때 Parquet InputFormat/OutputFormat을 써서 처리할 수도 있습니다. Pig나 Crunch 같은 오래된 하둡계 툴들도 Parquet 라이브러리를 통해 입출력할 수 있어요 . • Presto/Trino 및 AWS Athena: Presto SQL 엔진(현재는 Trino로 불리죠) 역시 Parquet 파일을 그대로 SQL로 조회할 수 있습니다. AWS Athena는 내부적으로 Presto 엔진을 사용해서 S3 상의 데이터를 쿼리해주는데, 여기서 가장 성능이 잘 나오는 포맷이 Parquet입니다. AWS에서는 모범사례로 “CSV 대신 Parquet로 저장하라, 그럼 Athena 쿼리 비용을 획기적으로 줄일 수 있다”고까지 말합니다. 이유는 역시 스캔 데이터 양 감소 때문이죠 . • 클라우드 데이터 웨어하우스: Google BigQuery는 자사 내부적으로 Colossus라는 파일 시스템과 Capacitor 포맷을 쓰지만, 외부 데이터를 불러올 때 Parquet를 지원하고 있습니다. Snowflake도 마찬가지로 외부 스테이지에서 Parquet 파일을 읽어올 수 있죠. Microsoft의 Azure Synapse나 AWS Redshift Spectrum 등도 데이터 레이크의 Parquet파일을 바로 쿼리하는 기능을 제공합니다. 즉, 클라우드 서비스들도 Parquet를 데이터 교환의 표준 포맷처럼 취급하고 있음을 알 수 있습니다 . • 기타 도구들: “한 번 Parquet로 저장하면 어디서든 읽는다”는 말처럼, Python의 Pandas, R의 dplyr, Apache Drill, Apache Flink, Apache Impala 등 수많은 엔진이 Parquet와의 연결고리를 갖고 있어요 . 예를 들어 Pandas에선 read_parquet() 한 줄이면 Parquet 파일을 DataFrame으로 불러올 수 있고, Spark 외에도 DuckDB나 Dask 같은 엔진도 Parquet를 기본 데이터 포맷으로 다룹니다. 최근 떠오르는 레이크하우스(Table Format) 기술들 – 예컨대 Apache Iceberg, Delta Lake, Apache Hudi – 역시 저장 계층으로 Parquet 파일을 사용하고, 그 위에 테이블 관리 기능만 얹은 것입니다 . 그 정도로 Parquet는 “데이터 레이크의 표준 언어”처럼 폭넓게 쓰이고 있어요. 요약하자면, 하둡 생태계의 대부분의 프레임워크와 AWS/GCP 등의 클라우드 분석 서비스, 그리고 여러 프로그래밍 언어 라이브러리까지 Parquet를 지원합니다. 이런 호환성 덕분에 기업들이 안심하고 Parquet로 데이터를 저장해 두는 것이죠. 실제로 “넷플릭스, 우버, 링크드인, 에어비앤비 같은 주요 IT기업들도 대규모 데이터 처리 포맷으로 Parquet“하고 있을 정도입니다 .
이제 현업에서 Parquet를 사용할 때 체감하는 장점과 단점을 정리해 보겠습니다. 아무리 좋아도 단점이 전혀 없는 기술은 없으니까요. 장점: • 뛰어난 읽기 성능: 대량의 데이터를 일부만 읽거나 집계할 때 속도가 월등히 빠릅니다. 컬럼 지향의 이점을 제대로 살려서, 동일한 조건에서 CSV/JSON보다 10배 이상 빨리 결과를 볼 수 있곤 합니다 . 특히 Spark, Presto 같은 엔진과 결합하면 분산 환경에서 수 테라바이트를 가진 데이터도 수십 초~수 분 내에 처리해내는 힘이 있습니다. • 높은 압축률로 저장공간 절약: Parquet는 데이터를 효율적으로 압축하여 저장하므로, 원본 대비 파일 사이즈가 크게 줄어듭니다. 앞서 말한 대로 2~5배 이상 용량 절감은 흔하고, 잘 압축되는 컬럼은 그 이상도 가능합니다 . 이는 곧 스토리지 비용 절약과 네트워크 전송 비용 절감으로 이어집니다. 예를 들어, 똑같은 데이터를 S3에 저장할 때 CSV로 100TB가 필요한 것을 Parquet로 30TB로 줄였다면, 저장비용도 3분의 1, Athena로 분석할 때 비용도 3분의 1이 되겠죠. • 스키마 포함 및 진화 지원: Parquet 파일 안에는 데이터의 스키마(구조)가 포함되어 있어, 데이터를 주고받을 때 구조가 보장됩니다. 분석가는 Parquet만 받아도 어떤 컬럼들이 있고 어떤 타입인지 바로 알 수 있어요. 또한 새로운 컬럼 추가 등의 스키마 변경을 어느 정도 허용해서, 데이터 스키마에 변화가 생겨도 기존 파이프라인을 깨뜨리지 않고 유연하게 대응할 수 있습니다 . 이는 장기간 운영되는 데이터 레이크에서 매우 중요한 장점입니다. • 복잡한 데이터 구조 표현: Parquet는 단순 테이블 형태뿐 아니라, 내부적으로 구조화된 계층 데이터를 다룰 수 있습니다. 리스트나 맵 같은 중첩 구조도 Parquet의 레코드 분해 알고리즘으로 컬럼처럼 저장되기 때문에, JSON처럼 복잡한 데이터를 효율적으로 저장/질의할 수 있죠. 다시 말해 반정형 데이터를 정형처럼 다룰 수 있게 해줍니다. • 폭넓은 도구 지원: 앞서 설명한 대로 거의 모든 빅데이터 툴이 Parquet를 지원하므로, 하나의 포맷으로 일원화했을 때 얻는 생산성 향상이 큽니다. 여러 부서나 시스템 간에 데이터 교환 포맷으로 Parquet를 선택하면 타입 불일치나 parsing 오류를 크게 줄일 수 있고, 별도 변환 작업도 줄어듭니다. 업계 표준이 주는 편리함이 있죠. • 대규모 병렬 처리에 최적: 분산 파일시스템(HDFS 등)과 궁합이 좋아서, 큰 파일을 여러 분할로 읽으며 클러스터 리소스를 최대한 활용할 수 있습니다. 또 Parquet 파일의 Footer 영역에 컬럼의 최소/최대값 등의 통계가 저장되어 있어, 쿼리 시에 필요 없는 데이터 블록은 아예 안 읽고 건너뛰는 프루닝 최적화도 가능합니다. 이러한 최적화 기법들로 실제 분석 쿼리 성능을 극대화합니다 . 단점: • 인간이 읽기 어려움: Parquet는 이진 바이너리 포맷이라서, 메모장이나 스프레드시트로 열어볼 수가 없습니다. JSON/CSV처럼 눈으로 데이터를 직접 확인하거나 간단히 편집하기 힘들지요 . 개발/분석 중에 간혹 원시 데이터를 들여다보며 디버깅하고 싶을 때 답답함이 있습니다. 전용 툴(예: parquet-tools CLI나 PyArrow 같은 라이브러리)을 이용해야만 내용을 확인할 수 있어요. 초보자 입장에서는 처음 Parquet 파일을 접하고 “이걸 어떻게 보지?” 당황할 수 있습니다. • 쓰기 오버헤드(느린 쓰기): 컬럼 단위로 데이터를 모아서 압축/인코딩하다 보니, 데이터를 기록하는 데 시간이 더 걸리는 편입니다 . 새로운 데이터를 실시간으로 계속 받아서 즉각즉각 기록해야 하는 워크로드(예: 실시간 로그 수집)에서는 Parquet의 느린 쓰기가 병목이 될 수 있어요. 예컨대 1건씩 자주 기록해야 하는 트랜잭션 시스템에 Parquet는 어울리지 않습니다. Parquet는 대신 한꺼번에 모아서 배치로 쓰는 것을 가정한 설계이기 때문에, 소규모 잦은 쓰기에는 부적합한 것이죠 . (Kafka나 Spark Streaming으로 실시간 데이터를 받을 땐, 일단 메모리/버퍼에 모아뒀다가 일정량씩 Parquet로 내보내는 식으로 완충하는 것이 일반적입니다.) • 부분 업데이트/삭제의 비효율: Parquet 파일은 한 번 쓰여진 데이터를 임의로 수정하거나 일부만 지우는 작업이 어렵습니다. 왜냐하면 컬럼식으로 블록 단위로 저장되기에, 중간에 있는 한 행을 고치려면 그 행이 속한 덩어리(예: Row Group) 전체를 다시 써야 할 수 있거든요. 그래서 Parquet는 불변의 로그 저장에는 좋지만, 트랜잭션 처리나 빈번한 업데이트가 필요하면 맞지 않습니다 . (이 단점을 보완하려고 앞서 언급한 Iceberg나 Delta Lake 같은 테이블 레이어가 등장한 것이기도 합니다. 그런 레이어는 Parquet 파일 단위로 버전관리하여 업데이트를 흉내냅니다.) • 소규모 데이터에 대한 오버킬: 데이터가 몇 KB~몇 MB 수준으로 아주 작을 때는, Parquet로 저장해봐야 얻는 이점이 없습니다. 오히려 압축/인코딩 헤더 정보 때문에 용량이 더 커지거나 처리만 복잡해질 수 있어요. 예를 들어 엑셀 한 두 개 분량의 데이터라면 그냥 CSV로 관리하는 편이 나을 수 있습니다. Parquet의 장점은 데이터 규모가 클 때 나타나니, 작은 데이터엔 과투자일 수 있다는 거죠. • 전처리 필요 및 학습 곡선: 기존에 텍스트로 저장된 데이터를 Parquet로 활용하려면 한 번 변환해줘야 합니다. Pandas, Spark 등으로 금방 할 수 있지만, 초보자 입장에선 처음에 이 변환 작업이 번거롭게 느껴질 수 있습니다. 또한 Parquet 스키마 설계나 파티셔닝 전략 등 성능 최적화를 위해 신경쓸 점들이 있어서, 완전히 아무 생각없이 쓸 순 없습니다. 하지만 이 부분은 단점이라기보다 숙련도에 따른 과제일 수 있겠네요. 정리하면, Parquet는 “읽기 최적화, 쓰기 부족화” 포맷입니다. 배치 분석에 강하고, 실시간 처리에 약하다고 볼 수 있죠 . 그리고 눈으로 바로 보기 어려운 건 사실이지만, 이 부분은 대부분의 이진 포맷의 공통 단점이기도 합니다 (Avro나 ORC도 마찬가지). 그래서 현업에서는 Parquet로 저장하되, 데이터 확인용으로는 일부 샘플을 CSV로 추출해 둔다든가 하는 식으로 보완하기도 합니다.
마지막으로, 실제 실무에서 Parquet가 어떻게 활용되는지 사례를 살펴보고, 효과적으로 Parquet를 쓰기 위한 팁들을 소개해 드리겠습니다. 활용 사례: 오늘날 많은 기업들이 데이터 레이크를 구축할 때 기본 포맷으로 Parquet를 채택합니다. 예를 들어 넷플릭스, 우버, 링크드인, 에어비앤비 등은 자사 대규모 데이터 처리를 위해 공식적으로 Parquet 포맷을 활용하고 있다고 알려져 있습니다 . 우버의 경우 모든 차량 로그와 데이터 피드를 Parquet로 모아 Data Lake에 저장하고, 이를 Presto와 Spark로 분석하는 구조를 갖췄습니다. AWS에서는 CloudTrail 로그나 서비스 메트릭을 Parquet로 저장해 Athena로 쿼리하는 가이드를 제공하기도 합니다. 또한 Airbnb나 여러 소매기업들은 S3에 누적되는 판매/이용 데이터를 Parquet로 쌓아두고 필요할 때마다 Trino(Presto)로 조인하고 분석하는 패턴을 사용합니다 . 요즘 뜨는 머신러닝 피처 스토어(feature store)에서도 훈련에 필요한 거대한 테이블을 Parquet로 관리하여, 특정 컬럼만 빠르게 뽑아 쓰도록 한 사례가 있습니다 . 이렇듯 “대용량 테이블형 데이터 저장 = Parquet”라는 공식이 업계에 널리 퍼져 있어, 사실상 베스트 프랙티스로 통합니다. 베스트 프랙티스: Parquet를 실무에 도입할 때 유용한 팁을 몇 가지 꼽아보겠습니다: • 적절한 파티셔닝: Parquet는 파일 자체 성능도 좋지만, 데이터 레이크에서는 디렉토리 파티셔닝과 함께 쓸 때 시너지가 납니다. 예를 들어 날짜별로 디렉토리를 나눠 (.../date=2025-12-27/파일.parquet 식으로) 저장해두면, 쿼리시 해당 날짜 디렉토리만 읽게 할 수 있습니다. 이는 불필요한 파일 스캔을 피하는 추가 최적화가 되죠. 일반적으로 시간, 지역, 카테고리 같은 분석에 자주 쓰이는 필드로 상위 디렉토리를 구분해 두는 것을 권장합니다. • 파일 크기 관리: Parquet는 내부적으로 수 MB~수백 MB 단위의 Row Group으로 나누어지므로, 너무 작은 Parquet 파일을 많이 만드는 것은 피해야 합니다. 작은 파일이 수천 수만 개 쌓이면 메타데이터 관리 오버헤드로 인해 오히려 성능이 나빠집니다 . 가능하면 한 파일당 수백 MB 정도 크기로 만드는 것이 좋고, 실시간 스트리밍으로 아주 작은 파일들이 생긴 경우 주기적으로 병합(compaction)해 주는 게 좋습니다. (예컨대 하루치 데이터를 모아 하나로 합치는 등.) • 압축 코덱 선택: Parquet는 Snappy를 기본으로 많이 쓰는데, 이는 압축률과 속도의 균형이 좋아서입니다. Gzip은 압축률은 더 높지만 압축/해제 속도가 느려, 읽기 성능이 중요할 땐 잘 안 씁니다. Brotli나 ZSTD 같은 최신 알고리즘은 특정 상황에서 매우 좋은 성능을 내지만 CPU 자원 소모를 고려해야 합니다. 데이터 종류에 따라 다르지만, 일반적인 분석 워크로드에서는 Snappy 압축이 권장됩니다 . (참고로, 압축을 아예 안 하면 CPU는 아낄 수 있어도 I/O가 늘어나서 대부분의 빅데이터 시나리오에는 비효율적입니다.) • 스키마 설계 및 진화: 처음 Parquet에 넣을 때 스키마를 잘 정의하는 게 중요합니다. 컬럼의 데이터 타입을 적절히 (예: 문자열 길거나 중복 많으면 Dictionary encoding 유리) 선택하고, 불필요한 필드는 빼는 등 깨끗한 스키마가 좋습니다. 만약 스키마 변경이 불가피하다면, Parquet는 새 컬럼 추가 정도는 쉽게 되지만 컬럼 이름 변경이나 타입 변경은 호환성이 깨질 수 있으니 가급적 추가만 하고 기존 건 유지하는 방식을 택해야 안전합니다 . 스키마 진화를 체계적으로 관리하려면 Apache Iceberg나 Delta Lake 같은 테이블 레이어를 도입하는 것도 방법입니다 . • 도구 활용: Parquet 파일은 직접 열어보기 어려우므로, 유틸리티를 적극 활용하세요. 예를 들어 Apache Arrow의 pyarrow Python 라이브러리는 Parquet를 읽어서 판다스 DataFrame으로 바꾸거나, 스키마/통계 정보를 출력하는 기능이 있습니다. 또한 parquet-tools라는 CLI를 쓰면 Parquet 파일의 메타데이터를 확인하거나 CSV로 덤프할 수 있어요. 개발 단계에서는 소량의 데이터를 Parquet로 만들어보고 Schema Evolution이나 Null 처리 등이 내가 의도한 대로 되는지 미리 검증해보는 것도 좋습니다. 끝으로, Parquet는 현대 빅데이터 환경에서 빼놓을 수 없는 핵심 기술로 평가받습니다. “데이터가 크고 분석적이라면 일단 Parquet”이라는 말이 있을 정도인데요 . 물론 모든 경우에 만능은 아니라서, 앞서 언급한 실시간 로그 스트리밍이나 잦은 업데이트가 필요한 경우에는 적합한 다른 방식을 택해야 합니다 . 하지만 클라우드 환경, 배치 기반 대규모 분석, 데이터 레이크/레이크하우스 구성에서는 Parquet가 사실상 디폴트 선택지가 되어가고 있습니다. 잘 압축된 컬럼 지향 데이터는 읽기 빠르고 비용 효율적이라, 데이터 활용을 더욱 극대화할 수 있기 때문이죠. 요약하자면: Parquet는 빅데이터 시대의 효율적인 데이터 저장 및 분석을 가능케 한 숨은 일꾼입니다. 그 정의와 구조를 이해하고 적재적소에 활용한다면, 방대한 데이터도 마치 다룰 수 있는 크기인 양 가볍게 요리할 수 있을 것입니다. 이제 여러분도 Parquet를 활용해 한층 똑똑한 빅데이터 분석을 시도해 보세요!