Snappy를 사용한 Parquet vs ORC vs ORC

Snappy를 사용한 Parquet vs ORC vs ORC

---

Hive에서 사용할 수있는 스토리지 형식에 대한 몇 가지 테스트를 실행하고 주요 옵션으로 Parquet 및 ORC를 사용하고 있습니다. ORC를 기본 압축으로 한 번, Snappy로 한 번 포함했습니다.

나는 Parquet이 ORC에 비해 시간 / 공간 복잡성이 더 좋다는 문서를 많이 읽었지만 내 테스트는 내가 통과 한 문서와 반대입니다.

내 데이터의 몇 가지 세부 사항을 따릅니다.

Table A- Text File Format- 2.5GB

Table B - ORC - 652MB

Table C - ORC with Snappy - 802MB

Table D - Parquet - 1.9 GB

내 테이블의 압축에 관한 한 Parquet는 최악이었습니다.

위의 표를 사용한 테스트 결과는 다음과 같습니다.

행 개수 작업

Text Format Cumulative CPU - 123.33 sec

Parquet Format Cumulative CPU - 204.92 sec

ORC Format Cumulative CPU - 119.99 sec 

ORC with SNAPPY Cumulative CPU - 107.05 sec

열 연산의 합계

Text Format Cumulative CPU - 127.85 sec   

Parquet Format Cumulative CPU - 255.2 sec   

ORC Format Cumulative CPU - 120.48 sec   

ORC with SNAPPY Cumulative CPU - 98.27 sec

열 작업의 평균

Text Format Cumulative CPU - 128.79 sec

Parquet Format Cumulative CPU - 211.73 sec    

ORC Format Cumulative CPU - 165.5 sec   

ORC with SNAPPY Cumulative CPU - 135.45 sec 

where 절을 사용하여 주어진 범위에서 4 개의 열 선택

Text Format Cumulative CPU -  72.48 sec 

Parquet Format Cumulative CPU - 136.4 sec       

ORC Format Cumulative CPU - 96.63 sec 

ORC with SNAPPY Cumulative CPU - 82.05 sec 

ORC가 Parquet보다 빠르다는 의미입니까? 아니면 쿼리 응답 시간과 압축률로 더 잘 작동하도록 할 수있는 일이 있습니까?

감사!

---

이 두 형식 모두 고유 한 장점이 있습니다.

Parquet은 고도로 중첩 된 데이터가있는 경우 더 좋을 수 있습니다. Google Dremel 과 같은 트리로 요소를 저장하기 때문입니다 ( 여기 참조 ).
파일 구조가 평면화 된 경우 Apache ORC가 더 좋을 수 있습니다.

그리고 내가 아는 한 마루는 아직 인덱스를 지원하지 않습니다. ORC는 경량 인덱스와 함께 제공되며 Hive 0.14 이후에는 특히 합계 연산과 관련하여 더 나은 쿼리 응답 시간에 도움이 될 수있는 추가 블룸 필터가 있습니다.

Parquet 기본 압축은 SNAPPY입니다. 테이블 A-B-C 및 D가 동일한 데이터 세트를 보유하고 있습니까? 그렇다면 1.9GB로만 압축 될 때 뭔가 그늘진 것 같습니다.

---

다음과 같은 이유로 표시됩니다.

• Hive에는 벡터화 된 ORC 판독기가 있지만 벡터화 된 쪽모이 세공 판독기는 없습니다.

• Spark has a vectorized parquet reader and no vectorized ORC reader.

• Spark performs best with parquet, hive performs best with ORC.

I've seen similar differences when running ORC and Parquet with Spark.

Vectorization means that rows are decoded in batches, dramatically improving memory locality and cache utilization.

(correct as of Hive 2.0 and Spark 2.1)

---

We did some benchmark comparing the different file formats (Avro, JSON, ORC, and Parquet) in different use cases.

https://www.slideshare.net/oom65/file-format-benchmarks-avro-json-orc-parquet

The data is all publicly available and benchmark code is all open source at:

https://github.com/apache/orc/tree/branch-1.4/java/bench

---

Both Parquet and ORC have their own advantages and disadvantages. But I simply try to follow a simple rule of thumb - "How nested is your Data and how many columns are there". If you follow the Google Dremel you can find how parquet is designed. They user a hierarchal tree-like structure to store data. More the nesting deeper the tree.

But ORC is designed for a flattened file store. So if your Data is flattened with fewer columns, you can go with ORC, otherwise, parquet would be fine for you. Compression on flattened Data works amazingly in ORC.

We did some benchmarking with a larger flattened file, converted it to spark Dataframe and stored it in both parquet and ORC format in S3 and did querying with **Redshift-Spectrum **.

Size of the file in parquet: ~7.5 GB and took 7 minutes to write
Size of the file in ORC: ~7.1. GB and took 6 minutes to write
Query seems faster in ORC files.

Soon we will do some benchmarking for nested Data and update the results here.

---

Both of them have their advantages. We use Parquet at work together with Hive and Impala, but just wanted to point a few advantages of ORC over Parquet: during long-executing queries, when Hive queries ORC tables GC is called about 10 times less frequently. Might be nothing for many projects, but might be crucial for others.

ORC also takes much less time, when you need to select just a few columns from the table. Some other queries, especially with joins, also take less time because of vectorized query execution, which is not available for Parquet

Also, ORC compression is sometimes a bit random, while Parquet compression is much more consistent. It looks like when ORC table has many number columns - it doesn't compress as well. It affects both zlib and snappy compression

참고URL : https://stackoverflow.com/questions/32373460/parquet-vs-orc-vs-orc-with-snappy