Parkiet vs ORC vs ORC z Snappy

87

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!

Rahul
źródło
1
Czy mógłbyś podzielić się ogólnym algorytmem używanym do tego eksperymentu? Konieczne jest jednak użycie tych samych danych. Jednak dzielenie się wszystkim innym, aby osiągnąć te same wyniki z różnymi zbiorami danych, może być bardzo przydatne, aby dać ci lepszą odpowiedź lub udowodnić, że masz bardzo dobry punkt widzenia i na zawsze zmienić świat.
Mestre San
czy masz jakieś wyniki Spark vs Tez przy użyciu orc vs parquet? z tego, co widziałem, wygląda na to, że tez jest szybszy (3 razy szybszy) przy używaniu formatu orc.
David H
+1 za przyjemny przegląd testów porównawczych. W każdym razie, czy jest szansa, że ​​możesz dostarczyć zaktualizowaną wersję, ponieważ niektóre aspekty techniczne za kulisami uległy zmianie (na przykład jak omówione w odpowiedzi @jonathanChap)?
Markus

Odpowiedzi:

52

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

PhanThomas
źródło
2
Tabela A - Format pliku tekstowego - bez kompresji ......... Tabela B - Format pliku ORC z kompresją ZLIB ......... Tabela C - ORC z Snappy ....... D - Parquet with Snappy ..... Pracowałem na innym stole z ~ 150 kolumnami i ~ 160 GB rozmiaru, aby sprawdzić, jak działają tam formaty plików. Parquet zajął 35 GB na przechowywanie tych 160 GB danych, podczas gdy ORC ze snappy zajął 39 GB ...... Kompresja wyglądała znacznie lepiej w przypadku Parquet w porównaniu z opublikowanym testem, ale wydajność znów była podobna. lepsza wydajność niż kombinacja ORC + SNAPPY.
Rahul
1
Struktura danych dla moich przypadków użycia była bardziej płaska bez żadnego zagnieżdżania. Zgadzam się na Twój komentarz dotyczący indeksowania w sprawie Parquet vs ORC i to faktycznie ma znaczenie. Czy chcesz podzielić się wynikami z porównania wydajności obu? To może uspokoić moje sumienie, że poprawnie wdrażam formaty. :)
Rahul
Nigdy nie testowałem mojego zestawu danych w Parquet, ponieważ indeks był niezbędnym wymogiem, a także mamy płaską strukturę danych bez zagnieżdżonych informacji. Odkryłem, że w zależności od tego, gdzie przechowujesz pliki, potrzebujesz innego paska i rozmiaru pliku, aby uzyskać najlepsze wyniki. Kiedy przechowujesz swoje pliki na stałe w HDFS, lepiej jest mieć większe pliki i paski. „set mapred.max.split.size = 4096000000” był parametrem, którego użyłem, aby wpłynąć na rozmiar pliku i pozostawił domyślną wartość rozmiaru paska. Przy tym ustawieniu dało mi to około 94% wzrostu zapytań i kompresji.
PhanThomas,
Jeśli chcesz przechowywać swoje pliki na Amazon S3 jako chłodnię, znacznie mniejszy plik i rozmiar paska dały mi znacznie lepsze wyniki. Użyłem plików o rozmiarze 40-60 MB zawierających pojedynczy pasek.
PhanThomas,
44

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)

jonathanChap
źródło
18
Począwszy od 2.3.0, iskra nie posiada czytnika ORC: wektorowy issues.apache.org/jira/browse/SPARK-16060
Steen
6
Hive 2.3.0 ma wektoryzowany czytnik Parquet - issue.apache.org/jira/browse/HIVE-14815
ruhong
Od Spark 2.3 Spark obsługuje wektoryzowany czytnik ORC spark.apache.org/docs/latest/sql-data-sources-orc.html
Anurag Sharma
10

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.

james.bondu
źródło
6

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

Owen O'Malley
źródło
5
Jest to bardzo przydatne, ale powinno być zastrzeżenie, że @Owen działa dla Horton Works, które pierwotnie opracowało format pliku ORC
Daniel Kats
1
Dzięki! Ale drugie łącze jest zepsute. Czy możesz to poprawić lub usunąć z odpowiedzi?
Danilo Gomes,
3

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

Hasan Ammori
źródło