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에는 벡터화 된 쪽모이 세공 판독기가 있으며 벡터화 된 ORC 판독기가 없습니다.

• Spark는 쪽모이 세공 마루에서 가장 잘 수행되고 하이브는 ORC에서 가장 잘 수행됩니다.

Spark로 ORC와 Parquet를 실행할 때 비슷한 차이점을 보았습니다.

벡터화는 행이 일괄 적으로 디코딩되어 메모리 지역 성과 캐시 사용률이 크게 향상됨을 의미합니다.

(Hive 2.0 및 Spark 2.1 기준)

Parquet과 ORC는 모두 장점과 단점이 있습니다. 그러나 저는 단순히 "당신의 데이터가 얼마나 중첩되어 있고 얼마나 많은 열이 있는지" 라는 간단한 경험 법칙을 따르려고합니다 . Google Dremel 을 따라 가면 마루가 어떻게 디자인되었는지 알 수 있습니다. 그들은 데이터를 저장하기 위해 계층 적 트리와 같은 구조를 사용합니다. 더 깊은 나무를 더 많이 중첩합니다.

그러나 ORC 는 평면화 된 파일 저장소를 위해 설계되었습니다. 따라서 데이터가 더 적은 수의 열로 평면화되면 ORC를 사용할 수 있습니다. 그렇지 않으면 쪽모이 세공을 사용해도 좋습니다. 평면화 된 데이터에 대한 압축은 ORC에서 놀랍도록 작동합니다.

더 큰 병합 파일로 벤치마킹을 수행하고 Spark Dataframe으로 변환하여 S3에 parquet 및 ORC 형식으로 저장하고 ** 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.

곧 중첩 된 데이터에 대한 벤치마킹을 수행하고 여기에서 결과를 업데이트 할 것입니다.

다양한 사용 사례에서 다양한 파일 형식 (Avro, JSON, ORC 및 Parquet)을 비교하는 벤치 마크를 수행했습니다.

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

데이터는 모두 공개적으로 사용 가능하며 벤치 마크 코드는 다음 위치에서 모두 오픈 소스입니다.

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

둘 다 장점이 있습니다. 우리는 Hive 및 Impala와 함께 작업 할 때 Parquet를 사용하지만, Parquet에 비해 ORC의 몇 가지 장점을 지적하고 싶었습니다. 장기 실행 쿼리 중에 Hive가 ORC 테이블을 쿼리 할 때 GC가 약 10 배 덜 자주 호출됩니다 . 많은 프로젝트에는 아무것도 아니지만 다른 프로젝트에는 중요 할 수 있습니다.

ORC는 또한 테이블에서 몇 개의 열만 선택해야 할 때 훨씬 적은 시간이 걸립니다. 특히 조인을 사용하는 일부 다른 쿼리도 Parquet에서 사용할 수없는 벡터화 된 쿼리 실행으로 인해 시간이 덜 걸립니다.

또한 ORC 압축은 때때로 약간 무작위이지만 Parquet 압축은 훨씬 더 일관 적입니다. ORC 테이블에 숫자 열이 많을 때처럼 압축되지 않습니다. zlib 및 snappy 압축 모두에 영향을 미칩니다.