[HADOOP] 마루 대 ORC 대 ORC 대 Snappy

마루 대 ORC 대 ORC 대 Snappy

Hive에서 사용할 수있는 저장소 형식에 대한 몇 가지 테스트를 실행 중이고 주요 옵션으로 Parquet 및 ORC를 사용하고 있습니다. ORC를 기본 압축과 함께 한 번, Snappy와 함께 한 번 포함 시켰습니다.

필자는 ORC와 비교하여 시간 / 공간의 복잡성을 개선하기 위해 마루판을 언급 한 많은 문서를 읽었지만 필자의 테스트는 내가 수행 한 문서와 반대입니다.

내 데이터의 세부 정보를 따르십시오.

Table A- Text File Format- 2.5GB

Table B - ORC - 652MB

Table C - ORC with Snappy - 802MB

Table D - Parquet - 1.9 GB

내 테이블에 대한 압축과 관련하여 마루판이 최악이었습니다.

위 표의 테스트 결과는 다음과 같습니다.

행 수 연산

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가 빠르다가 파르 케를 의미합니까? 아니면 쿼리 응답 시간 및 압축 비율을 사용하여 더 잘 작동하도록 할 수있는 방법이 있습니까?

감사!

해결법

1. ==============================

   1.나는이 포맷들 모두가 그들 자신의 장점들을 가지고 있다고 말할 것이다.

   나는이 포맷들 모두가 그들 자신의 장점들을 가지고 있다고 말할 것이다.

   Google Dremel처럼 나무로 요소를 저장하기 때문에 매우 중첩 된 데이터가있는 경우 마루가 더 좋을 수 있습니다 (여기 참조). 파일 구조가 평평 해지면 Apache ORC가 더 나을 수도 있습니다.

   그리고 내가 아는 한 마루는 아직 색인을 지원하지 않습니다. ORC는 가벼운 지수를 가지고 있으며, Hive 0.14부터 Bloom 필터가 추가되었습니다. 특히 합계 연산과 관련하여 쿼리 응답 시간이 더 좋습니다.

   여기 엔 나무 마루의 기본 압축은 SNAPPY입니다. 테이블 A - B - C와 D는 동일한 데이터 세트를 보유하고 있습니까? 그렇다면 1.9GB로 압축 될 때 그곳에 뭔가 어수선한 것이있는 것처럼 보입니다.

2. ==============================

   2.당신은 이것을보고 있습니다 :

   당신은 이것을보고 있습니다 :

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

   벡터화는 행을 일괄 처리하여 메모리 위치 및 캐시 활용률을 크게 향상시킵니다.

   (Hive 2.0 및 Spark 2.1에서 정답)

3. ==============================

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

   다양한 사용 사례에서 서로 다른 파일 형식 (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

4. ==============================

   4.둘 다 장점이 있습니다. 우리는 Hive와 Impala와 함께 직장에서 Parquet을 사용하지만, Parquet보다 ORC의 몇 가지 장점을 지적하고자했습니다. 오래 실행되는 쿼리에서 Hive 쿼리 ORC 테이블 GC가 약 10 배 덜 자주 호출 될 때. 많은 프로젝트에서 아무것도 아니지만 다른 사람들에게 중요 할 수 있습니다.

   둘 다 장점이 있습니다. 우리는 Hive와 Impala와 함께 직장에서 Parquet을 사용하지만, Parquet보다 ORC의 몇 가지 장점을 지적하고자했습니다. 오래 실행되는 쿼리에서 Hive 쿼리 ORC 테이블 GC가 약 10 배 덜 자주 호출 될 때. 많은 프로젝트에서 아무것도 아니지만 다른 사람들에게 중요 할 수 있습니다.

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

   또한, Parquet 압축은 훨씬 더 일관성있는 반면, ORC 압축은 때로는 조금 임의적입니다. ORC 테이블에 숫자 열이 많은 경우처럼 보입니다. 압축도되지 않습니다. zlib 및 snappy 압축 모두에 영향을줍니다.

5. ==============================

   5.마루와 ORC에는 각각 장단점이 있습니다. 하지만 간단히 말해서 "데이터가 얼마나 중첩되어 있고 얼마나 많은 열이 있는지"에 대한 간단한 규칙을 따르기 만하면됩니다. Google Dremel을 따라 가면 마루가 어떻게 디자인되었는지 확인할 수 있습니다. 그들은 데이터를 저장하기 위해 계층 트리와 같은 구조를 사용합니다. 나무를 더 깊게 중첩시킵니다.

   마루와 ORC에는 각각 장단점이 있습니다. 하지만 간단히 말해서 "데이터가 얼마나 중첩되어 있고 얼마나 많은 열이 있는지"에 대한 간단한 규칙을 따르기 만하면됩니다. Google Dremel을 따라 가면 마루가 어떻게 디자인되었는지 확인할 수 있습니다. 그들은 데이터를 저장하기 위해 계층 트리와 같은 구조를 사용합니다. 나무를 더 깊게 중첩시킵니다.

   그러나 ORC는 평평한 파일 저장소를 위해 설계되었습니다. 따라서 데이터가 더 적은 수의 열로 병합되면 ORC로 갈 수 있습니다. 그렇지 않으면 마루가 좋을 것입니다. 병합 된 데이터의 압축은 ORC에서 놀랍도록 작동합니다.

   우리는 더 큰 평탄화 된 파일로 벤치마킹을 수행하고, Dataframe을 발화시키기 위해 그것을 변환하여 S3의 마루와 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.
   

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

from https://stackoverflow.com/questions/32373460/parquet-vs-orc-vs-orc-with-snappy by cc-by-sa and MIT license