Parkiet vs ORC vs ORC z Snappy

Przeprowadzam kilka testów na formatach przechowywania dostępnych w Hive i używam Parquet i ORC jako głównych opcji. Raz włączyłem ORC z domyślną kompresją, a raz ze Snappy.

Przeczytałem wiele dokumentów, w których stwierdzono, że Parquet jest lepszy pod względem złożoności czasowo-przestrzennej w porównaniu z ORC, ale moje testy są odwrotne do dokumentów, które przeszedłem.

Śledzi niektóre szczegóły moich danych.

Table A- Text File Format- 2.5GB

Table B - ORC - 652MB

Table C - ORC with Snappy - 802MB

Table D - Parquet - 1.9 GB

Najgorzej wypadł parkiet, jeśli chodzi o kompresję na moim stole.

Moje testy z powyższymi tabelami dały następujące wyniki.

Operacja liczenia wierszy

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

Suma operacji na kolumnie

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

Średnia z operacji na kolumnie

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 

Wybieranie 4 kolumn z podanego zakresu za pomocą klauzuli where

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 

Czy to oznacza, że ​​ORC jest szybsze niż Parquet? A może jest coś, co mogę zrobić, aby działało lepiej z czasem odpowiedzi na zapytanie i współczynnikiem kompresji?

Dzięki!

Powiedziałbym, że oba te formaty mają swoje zalety.

Parkiet może być lepszy, jeśli masz mocno zagnieżdżone dane, ponieważ przechowuje swoje elementy jako drzewo, tak jak robi to Google Dremel ( patrz tutaj ).
Apache ORC może być lepszy, jeśli struktura plików jest spłaszczona.

O ile wiem, parkiet nie obsługuje jeszcze indeksów. ORC jest dostarczany z lekkim indeksem, a od Hive 0.14 dodatkowy filtr Bloom, który może być pomocny w lepszym czasie odpowiedzi na zapytanie, szczególnie jeśli chodzi o operacje sumaryczne.

Domyślną kompresją Parquet jest SNAPPY. Czy tabela A - B - C i D zawiera ten sam zestaw danych? Jeśli tak, wygląda na to, że jest w nim coś podejrzanego, gdy kompresuje się tylko do 1,9 GB

Widzisz to, ponieważ:

• Hive ma wektoryzowany czytnik ORC, ale nie ma czytnika parkietu wektoryzowanego.

• Spark ma wektoryzowany czytnik parkietu i nie ma wektoryzowanego czytnika ORC.

• Spark działa najlepiej z parkietem, ul z ORC.

Widziałem podobne różnice podczas uruchamiania ORC i Parquet ze Sparkiem.

Wektoryzacja oznacza, że ​​wiersze są dekodowane partiami, co radykalnie poprawia lokalność pamięci i wykorzystanie pamięci podręcznej.

(poprawne od Hive 2.0 i Spark 2.1)

Zarówno Parquet, jak i ORC mają swoje zalety i wady. Ale po prostu staram się przestrzegać prostej praktycznej zasady - „Jak zagnieżdżone są Twoje dane i ile jest tam kolumn” . Jeśli podążasz za Google Dremel , możesz dowiedzieć się, jak projektowany jest parkiet. Używają hierarchicznej struktury drzewiastej do przechowywania danych. Bardziej zagnieżdżanie się głębiej w drzewie.

Ale ORC jest przeznaczony do magazynu plików spłaszczonych. Więc jeśli twoje dane są spłaszczone z mniejszą liczbą kolumn, możesz wybrać ORC, w przeciwnym razie parkiet byłby dla ciebie w porządku. Kompresja spłaszczonych danych działa zadziwiająco w ORC.

Przeprowadziliśmy trochę testów porównawczych z większym spłaszczonym plikiem, przekonwertowaliśmy go na iskrę Dataframe i zapisaliśmy go zarówno w formacie parkietu, jak i ORC w S3, a następnie wykonaliśmy zapytania z ** 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.

Wkrótce przeprowadzimy testy porównawcze zagnieżdżonych danych i zaktualizujemy wyniki tutaj.

Przeprowadziliśmy test porównawczy, porównując różne formaty plików (Avro, JSON, ORC i Parquet) w różnych przypadkach użycia.

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

Wszystkie dane są publicznie dostępne, a kod porównawczy jest w całości open source pod adresem:

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

Oba mają swoje zalety. Używamy Parquet we współpracy z Hive i Impala, ale chcieliśmy tylko wskazać kilka zalet ORC w porównaniu z Parquet: podczas długo wykonywanych zapytań, gdy Hive wysyła zapytania do tabel ORC GC jest wywoływane około 10 razy rzadziej . Może to być nic dla wielu projektów, ale może mieć kluczowe znaczenie dla innych.

ORC zajmuje również znacznie mniej czasu, gdy trzeba wybrać tylko kilka kolumn z tabeli. Niektóre inne zapytania, szczególnie z łączeniami, również zajmują mniej czasu z powodu wykonywania zapytań zwektoryzowanych, które nie są dostępne dla Parquet

Ponadto kompresja ORC jest czasami nieco przypadkowa, podczas gdy kompresja Parquet jest znacznie bardziej spójna. Wygląda na to, że tabela ORC ma wiele kolumn liczbowych - również nie kompresuje się. Wpływa na kompresję zlib i snappy