[BigData] Parquet vs ORC vs Avro 빅데이터 파일 포멧 비교 정리

728x90

빅데이터에 사용이 많이 되는 파일 형식에 대해서 비교하고 정리해보겠습니다.

특징	Parquet	Avro	ORC
저장 방식	컬럼 기반	행 기반	컬럼 기반
압축률	높음	중간	매우 높음
주 용도	배치, 분석 처리	스트리밍, 실시간 처리	배치, 데이터 웨어하우스 처리
성능	읽기 성능 우수(columnar)	빠른 쓰기, schema evolution 지원	읽기 성능 우수
배치 처리	적합	부적합(행 기반 저장으로 인한 성능 저하)	매우 적합
스트리밍 처리	덜 최적화	최적화(schema evolution)	덜 최적화
사용되는 기술	Spark, Hive, Impala, Presto	Kafka, Spark, Flink, Hadoop	Hive, Spark, Presto, Impala

1. Parquet

Parquet 구조

+----------------------+
|      File Footer     |
|  (metadata, schema,  |
|  column statistics,  |
|  column metadata etc)|
+----------------------+
|      Row Groups      |  --> 여러 개
|  +------------------+|
|  |  Column Chunks   |  --> 컬럼별 데이터
|  |  +--------------+| 
|  |  |   Pages      ||  --> 실제 데이터(압축 & 인코딩 적용)
|  |  +--------------+|
|  +------------------+|
+----------------------+

Row Group
- Parquet은 테이블 데이터를 Row Group이라는 단위로 나누어 저장함.
- 하나의 Row Group에는 일정 범위(예: 128MB 등)에 해당하는 행들이 들어가며, 분산 처리 시 Row Group 단위로 병렬 처리가 가능함.
Column Chunk
- Row Group 내에서 각 컬럼별로 Column Chunk가 존재함.
- 예: Row Group 1에는 “age” Column Chunk, “gender” Column Chunk, “income” Column Chunk가 각각 저장됨.
Page
- Column Chunk는 여러 개의 Page로 구성되며, 실제 데이터와 인코딩/압축 정보 등이 저장됨.
- Page 단위로 압축을 적용하고, Page 헤더에 통계(statistics) 정보를 담아서 필터링(Pruning)에 활용할 수 있음.
Footer(메타데이터)
- Parquet 파일의 끝 부분(Footer)에 파일 전체에 대한 메타데이터(스키마, Row Group/Column Chunk 위치, 통계 정보 등)가 저장됨.
- 쿼리 엔진은 이 메타데이터를 빠르게 읽어, 필요한 컬럼이나 Row Group만 선택적으로 읽게 됨(Predicate Pushdown 최적화).

Parquet 특징과 장점

컬럼 지향 저장 방식(Columnar Format)
- Parquet은 같은 컬럼(열)의 데이터를 인접하게 저장하여, 열 단위로 효율적으로 읽고 쓸 수 있도록 함
- 컬럼 지향 구조로 인해 필요한 열만 Select해서 읽는 쿼리 최적화(Projection Pruning)가 가능
효율적인 압축(Compression) 및 인코딩(Encoding)
- 컬럼 단위로 같은 유형의 데이터가 연속되어 있기 때문에, 높은 압축률을 기대할 수 있음
- 예를 들면, Dictionary Encoding, Run-length Encoding 등 컬럼별로 맞춤형 압축 알고리즘(ZSTD, Snappy, GZIP 등)을 선택할 수 있고, Nested Column 구조를 가진 경우에도 하위 필드별로 독립적으로 압축할 수 있음
대규모 분산 처리 환경에 최적화
- Hadoop Distributed File System(HDFS) 뿐 아니라, Amazon S3, Google Cloud Storage 등 객체 스토리지에서도 효율적으로 동작함
- Spark, Hive, Presto(Trino), Dremio, Impala 등 다양한 쿼리 엔진에서 Parquet을 기본 스토리지 포맷으로 지원함
스키마 정보 내장(Self-describing)
- Parquet 파일 자체에 스키마(메타데이터)가 포함되어 있어, 별도로 스키마 정의를 제공하지 않아도 됨
- Nested 구조(Struct, List, Map 등)를 표현할 수 있어, 복잡한 데이터 모델에 대해서도 효율적인 쿼리를 제공 함

2. Avro

Avro는 데이터 직렬화(Serialization) 시스템이자 파일 포맷으로, 주로 스키마(메타데이터) 기반으로 데이터를 효율적으로 인코딩하고 전송 및 저장하기 위해 설계 됨
Hadoop, Kafka 등 빅데이터 에코시스템에서 널리 사용되며,스키마 진화(진화적 스키마 변경)와 RPC(원격 프로시저 호출) 기능을 염두에 둔 포맷이라는 점이 가장 큰 특징

Avro의 핵심 특징

1) 스키마 기반(점진적 스키마 진화 지원)

Avro는 데이터를 직렬화할 때, 별도의 스키마(Avro Schema)를 사용
스키마에 따라 직렬화·역직렬화를 수행하므로, 필드 유형·구조가 변경되어도 기존 데이터를 재구성하거나 읽을 수 있는 유연성을 제공
“읽는 쪽(Reader)”과 “쓰는 쪽(Writer)”에서 서로 다른 버전의 스키마를 사용해도, 스키마 호환성 정책(Evolution Policy)에 부합한다면 데이터를 정상적으로 해석할 수 있음

2) 이진(바이너리) 직렬화(Binary Serialization)

Avro는 JSON 스키마 정의를 제외하면, 실제 데이터는 이진(Binary) 포맷으로 직렬화
이는 CSV, JSON 등의 텍스트 포맷 대비 스토리지와 네트워크 대역폭 사용을 줄이는 효과가 있음

3) Row 지향(Row-based) 저장

Avro는 Row-based 포맷으로, 레코드(행 단위)별로 데이터를 직렬화
컬럼 지향(Columnar)인 Parquet 등과 달리, 한 레코드의 전체 필드가 인접하여 저장되므로 스트리밍이나 메시지 전송에도 적합

4) RPC 및 스트리밍 친화적

Avro는 원격 프로시저 호출(RPC) 프로토콜을 내장하고 있으며, 가벼운 이진 포맷이라는 점 때문에 Kafka 등 메시지 큐나 분산 로그에 자주 사용
특히 스키마 레지스트리(Schema Registry)와 결합해 Avro 스키마 관리를 일원화할 수 있음(예: Confluent Schema Registry).

5) 동적 스키마(Dynamic Schema) & 드라이버 의존성 낮음

Avro 레코드를 읽을 때, 별도 코드 생성이 필요 없으며(옵션에 따라 코드 생성도 가능), JSON 스키마를 해석해 Generic Record 형태로 데이터를 다룰 수 있음
스키마를 모델링하는 언어가 JSON이므로, 이해하기 쉽고 다양한 언어(Ruby, Python, Java, Go 등)에서 범용적으로 사용 가능

Avro 스키마

1) JSON 기반

Avro 스키마는 JSON 문서 형태를 띄며, 다음과 같이 type, fields, name, namespace 등을 지정

{
  "type" : "record",
  "namespace" : "com.example",
  "name" : "User",
  "fields" : [
    { "name" : "name",  "type" : "string" },
    { "name" : "age",   "type" : "int"    },
    { "name" : "email", "type" : ["null", "string"], "default": null }
  ]
}

여기서 email 필드는 Union 타입(["null", "string"])을 사용해 Null 허용여부(Optionality)를 표현

2) 스키마 호환성(Evolution)

Avro는 Schema Evolution을 지원
즉, 기존 스키마에서 필드가 추가되거나, 기본값(Default)이 설정되는 경우 등 다양한 변경 사항을 허용
일반적으로는 Backward/Forward/Full 호환성 정책을 사용할 수 있으며, 운영 환경에서 스키마가 변경되어도 재배포·재처리가 간단

3) 유니온(Union) 타입 & Null 처리

Avro 스키마의 큰 특징 중 하나가 Union 타입을 통해 여러 가지 타입 중 하나가 될 수 있음을 표현
예를 들어 ["null", "string", "int"]처럼 지정하면, 해당 필드는 Null, String, Int 중 하나로 존재할 수 있음
다만, Union 타입이 너무 복잡해지면 호환성 문제가 발생할 수 있음

4) 복합 타입(Nested) 지원

record, array, map, enum, fixed 등 다양한 복합 타입(Complex Type)을 지원
Nested 구조도 Avro 스키마로 표현 가능하나, Parquet 대비 중첩 쿼리(analytic) 측면에서는 Row 기반인 만큼 직접적인 최적화가 적을 수 있음

Avro 파일 구조

Avro는 단순히 직렬화 포맷만을 의미하지 않고, 컨테이너 파일(Object Container File) 형식도 규정함.

이를 통해 스키마 + 데이터가 하나의 파일 내에 함께 저장될 수 있음.

1) 헤더(Header)

싱크 마커(Sync Marker), 스키마, 파일 형식 버전, 코덱(codec) 등 메타정보가 포함
스키마가 파일 내부에 내장되므로, 별도의 스키마 정보가 없어도 Avro 파일만 있으면 전체 구조를 이해할 수 있음(셀프 디스크라이빙, Self-describing).

2) 블록(Block) 구조

Avro 파일은 여러 개의 데이터 블록(Chunk)으로 구성되며, 각 블록에는 실제 레코드가 직렬화된 형태로 저장
블록 사이사이에 Sync Marker가 존재해, 임의 접근(Seek) 가능성을 높이고 손상 복구에 도움

3) 압축(Codec) 옵션

Snappy, Deflate, Zstandard, Brotli 등 다양한 압축 코덱을 선택할 수 있음
각 블록 단위로 압축할 수 있으며, Row-based 포맷 특성상 Parquet 등 컬럼 지향 포맷보다는 압축 효율이 떨어질 수도 있지만, 레코드 단위로 빠르게 압축/해제가 가능

4) 메타데이터 확장(파일 수준)

파일 상단(header)에 사용자 정의 메타데이터를 추가로 기록할 수 있어, 특정 ETL 파이프라인에서 필요로 하는 정보를 Avro 파일 자체에 저장하기도 함

Avro 장점

1) 동적 스키마 변화(진화)에 강함

Backward/Forward compatibility가 뛰어나, 데이터 생산자와 소비자가 완전히 동일한 스키마 버전을 사용하지 않아도 상호 이해가 가능

2) Row 지향 포맷으로 스트리밍 친화적

Kafka, Pulsar 같은 메시지 플랫폼에서 Avro 직렬화를 많이 사용
레코드 단위로 쉽게 구조화된 데이터를 전송하기 좋음

3) 가볍고 빠른 이진 직렬화

JSON 대비 훨씬 작고 빠르며, 프로토콜 버퍼(Protobuf)나 Thrift에 비해 스키마를 JSON 형태로 직관적으로 정의·변경 가능한 장점 존재

4) RPC 기능 내장

Avro 자체가 RPC 프로토콜을 지원하여, Avro IDL(Interface Definition Language) 기반으로 원격 메서드를 정의하고 호출할 수 있음

Avro 단점

1) 컬럼 지향 분석에 비해 느릴 수 있음

Avro는 Row-based 포맷이므로, 대규모 데이터 분석(OLAP)에서는 컬럼 지향인 Parquet, ORC 등에 비해 컬럼 단위 필터링 최적화(Projection Pruning, Predicate Pushdown)가 부족

2) 스키마 레지스트리(Registry) 필요

스키마가 자주 바뀌거나 많은 주체가 공유하는 경우, 중앙에서 스키마를 관리하고 호환성을 보장하기 위해 Schema Registry 인프라가 필요함(Confluent Schema Registry 등)

3. 파일 사이즈 증가 가능

스키마, Sync Marker, 블록 헤더 등을 포함하기 때문에 순수 CSV·JSON 대비 파일 오버헤드가 존재할 수 있음(물론 바이너리 직렬화로 이득을 보는 경우가 많음)

Avro 활용 사례

1) Kafka 스트리밍 데이터

Kafka 토픽에 전달되는 레코드의 스키마를 Avro로 정의하고, Schema Registry로 관리하여 메시지 호환성을 유지
실시간 스트리밍 분석, 이벤트 처리 파이프라인에서 널리 사용

2)로그 수집 & ETL 파이프라인

Fluentd, Logstash 등을 통해 Avro 포맷으로 로그를 수집한 뒤, Hadoop/S3 등에 저장하거나 Kafka로 전송함
다운스트림에서 Spark나 Hadoop MapReduce 작업으로 Avro 파일을 읽어 배치 처리

3) RPC 서비스

Avro IDL을 이용해 마이크로서비스 간 통신 프로토콜을 정의하고, Avro RPC를 통해 직렬화·역직렬화를 자동으로 처리

4) 데이터 호환성 유지가 중요한 환경

버전이 다른 Producer와 Consumer가 동시에 존재하고, 원활한 Schema Evolution이 필요할 때 Avro가 많이 사용
예를 들면, DW/DM 단계로 데이터를 공급할 때

Avro vs 다른 포맷 (Parquet, ORC, Protobuf 등)

1) Avro vs. Parquet/ORC

Parquet/ORC는 컬럼 지향(Columnar) 포맷으로 대규모 분석 쿼리에 최적화
Avro는 Row 지향 포맷으로, 빠른 직렬화/역직렬화와 스키마 진화를 중시하는 스트리밍/메시지 시나리오에 적합

2) Avro vs. Protobuf/Thrift

Protobuf, Thrift도 이진 직렬화를 제공하지만, 스키마 정의 언어(DSL)와 RPC 프레임워크가 각각 다름
Avro는 스키마가 JSON 형식이라는 점, 컨테이너 파일 포맷(Object Container)까지 표준화했다는 점에서 차별화

3) Avro vs. JSON

JSON은 사람이 읽기 쉽지만, 바이너리 직렬화보다 부피가 크고 파싱 비용이 큼
Avro는 JSON 스키마를 통해 구조를 정의하되, 실제 데이터는 바이너리로 직렬화하므로 더 효율적

3. ORC(Optimized Row Columnar)

대규모 데이터 처리를 위해 설계된 열 기반 저장 포맷으로, 빅데이터 처리 환경(예: Apache Hive, Apache Spark)에서 널리 사용
효율적인 저장 공간 사용, 빠른 읽기 성능, 강력한 압축 기능을 제공하며, 특히 Hive의 데이터 처리 요구 사항을 충족하기 위해 개발

ORC 파일 구조

ORC 특징 및 장점

1) 열 기반 저장(Columnar Storage)

데이터를 열 단위로 저장하므로, 분석 쿼리가 특정 열에만 접근할 때 성능이 크게 향상
열 단위의 압축과 빠른 읽기를 지원

2) 효율적인 압축

ZLIB, Snappy, LZ4 등 다양한 압축 알고리즘을 지원하며, 데이터 중복 제거 및 배치 압축으로 높은 압축률을 제공
Stripe-level compression으로 데이터 블록 단위로 압축해 메모리와 디스크 공간을 절약

3) Schema Evolution 지원

스키마가 변경되어도 데이터의 호환성을 유지하며, 이전 스키마와 새로운 스키마 간의 매핑을 지원

4) 빠른 읽기 성능

Predicate Pushdown: 필요한 데이터만 읽도록 최적화하여 I/O를 줄이고 성능을 향상
Indexing: 데이터 파일 내부에 최소/최대 값 및 위치 정보(Index)를 저장해 빠른 조회가 가능

5) Metadata 지원

각 파일에 메타데이터가 포함되어 있어 데이터 구조를 빠르게 파악할 수 있음
Stripe-level statistics를 통해 데이터의 최소값, 최대값, 누락된 값 등을 저장

6) 분할 처리(Stripe-based Processing)

데이터를 Stripe 단위로 나누어 처리
Stripe에는 데이터, 인덱스, 메타데이터가 포함되며, 병렬 처리에 적합

참조:

https://louisdev.tistory.com/63

https://pinggoopark.tistory.com/1023