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!
Odpowiedzi:
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
źródło
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)
źródło
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 **.
Wkrótce przeprowadzimy testy porównawcze zagnieżdżonych danych i zaktualizujemy wyniki tutaj.
źródło
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
źródło
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
źródło