it-swarm.com.de

Parkett gegen ORC gegen ORC mit bissigem

Ich führe ein paar Tests mit den Speicherformaten aus, die mit Hive verfügbar sind, und benutze Parquet und ORC als Hauptoptionen. Ich habe ORC einmal mit der Standardkomprimierung und einmal mit Snappy aufgenommen.

Ich habe viele Dokumente gelesen, in denen Parquet im Vergleich zu ORC eine bessere Zeit-/Raum-Komplexität aufweist, aber meine Tests stehen im Gegensatz zu den Dokumenten, die ich durchlaufen habe.

Folgt einigen Details meiner Daten.

Table A- Text File Format- 2.5GB

Table B - ORC - 652MB

Table C - ORC with Snappy - 802MB

Table D - Parquet - 1.9 GB

Parkett war am schlechtesten, was die Kompression für meinen Tisch angeht.

Meine Tests mit den obigen Tabellen ergaben folgende Ergebnisse.

Zeilenzähloperation

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

Summe einer Spaltenoperation

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

Durchschnitt einer Spaltenoperation

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 

Auswählen von 4 Spalten aus einem bestimmten Bereich mithilfe von where-Klausel

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 

Bedeutet das, dass ORC schneller als Parkett ist? Oder gibt es etwas, das ich tun kann, um die Antwortzeit und die Komprimierungsrate von Abfragen zu verbessern?

Vielen Dank! 

68
Rahul

Ich würde sagen, dass beide Formate ihre eigenen Vorteile haben. 

Parkett ist möglicherweise besser, wenn Sie über stark verschachtelte Daten verfügen, da diese Elemente als Baumstruktur wie Google Dremel ( siehe hier ) gespeichert werden.
Apache-ORC ist möglicherweise besser, wenn Ihre Dateistruktur reduziert ist. 

Soweit ich weiß, unterstützt Parkett noch keine Indizes. ORC verfügt über einen Light Weight Index und seit Hive 0.14 einen zusätzlichen Bloom-Filter, der insbesondere bei Summenoperationen hilfreich sein kann.

Die Standardkomprimierung des Parketts ist SNAPPY. Enthalten Tabelle A - B - C und D denselben Datensatz? Wenn ja, sieht es so aus, als wäre etwas zwielichtig, wenn es nur auf 1,9 GB komprimiert wird

36
PhanThomas

Sie sehen das aus folgenden Gründen:

  • Hive hat einen vektorisierten ORC-Leser, aber keinen vektorisierten Parkettleser.

  • Spark verfügt über einen vektorisierten Parkettleser und keinen vektorisierten ORC-Leser.

  • Spark ist am besten mit Parkett, Hive mit ORC am besten.

Ich habe ähnliche Unterschiede beim Ausführen von ORC und Parkett mit Spark gesehen.

Vektorisierung bedeutet, dass Zeilen in Batches dekodiert werden, was die Speicherlokalität und die Cache-Nutzung erheblich verbessert.

(korrekt ab Hive 2.0 und Spark 2.1)

33
jonathanChap

Wir haben einige Benchmark-Vergleiche der verschiedenen Dateiformate (Avro, JSON, ORC und Parquet) in verschiedenen Anwendungsfällen durchgeführt.

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

Die Daten sind alle öffentlich verfügbar und der Benchmark-Code ist alles Open Source unter:

https://github.com/Apache/orc/tree/branch-1.4/Java/bench

5
Owen O'Malley

Beide haben ihre Vorteile. Wir setzen Parquet bei der Arbeit zusammen mit Hive und Impala ein, wollten aber nur einige Vorteile von ORC gegenüber Parquet aufzeigen: Bei lang ausgeführten Abfragen, wenn Hive ORC-Tabellen GC abfragt, werden sie etwa 10-mal seltener aufgerufen. Könnte für viele Projekte nichts sein, aber für andere von entscheidender Bedeutung sein. 

ORC benötigt auch viel weniger Zeit, wenn Sie nur wenige Spalten aus der Tabelle auswählen müssen. Einige andere Abfragen, insbesondere bei Joins, benötigen aufgrund der vektorisierten Abfrageausführung, die für Parkett nicht verfügbar ist, weniger Zeit

Außerdem ist die ORC-Komprimierung manchmal etwas zufällig, während die Parkettkomprimierung viel konsistenter ist. Es sieht so aus, als wenn die ORC-Tabelle viele Nummernspalten hat - sie wird auch nicht komprimiert. Dies wirkt sich sowohl auf die Zlib- als auch auf die zackige Komprimierung aus

2
Hasan Ammori

Sowohl Parkett als auch ORC haben ihre eigenen Vor- und Nachteile. Aber ich versuche einfach einer einfachen Faustregel zu folgen - "Wie verschachtelt sind Ihre Daten und wie viele Spalten gibt es" . Wenn Sie dem Google Dremel folgen, können Sie feststellen, wie Parkett ausgelegt ist. Sie verwenden eine hierarchische Baumstruktur zum Speichern von Daten. Je tiefer das Nest, desto tiefer der Baum. 

ORCist jedoch für einen abgeflachten Dateispeicher gedacht. Wenn Ihre Daten mit weniger Spalten abgeflacht werden, können Sie mit ORC arbeiten, ansonsten wäre Parkett für Sie in Ordnung. Die Komprimierung von abgeflachten Daten funktioniert erstaunlich gut in ORC.

Wir haben ein Benchmarking mit einer größeren, abgeflachten Datei durchgeführt, sie in Spark Dataframe konvertiert und sowohl im Parkett als auch im ORC-Format in S3 gespeichert und mit ** Redshift-Spectrum ** abgefragt. 

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.

In Kürze werden wir ein Benchmarking für verschachtelte Daten durchführen und die Ergebnisse hier aktualisieren. 

0
james.bondu