Parket vs ORC vs ORC dengan Snappy

88

Saya menjalankan beberapa tes pada format penyimpanan yang tersedia dengan Hive dan menggunakan Parquet dan ORC sebagai opsi utama. Saya memasukkan ORC sekali dengan kompresi default dan sekali dengan Snappy.

Saya telah membaca banyak dokumen yang menyatakan Parquet menjadi lebih baik dalam kompleksitas ruang / waktu dibandingkan dengan ORC tetapi pengujian saya berlawanan dengan dokumen yang saya lalui.

Mengikuti beberapa detail data saya.

Table A- Text File Format- 2.5GB

Table B - ORC - 652MB

Table C - ORC with Snappy - 802MB

Table D - Parquet - 1.9 GB

Parket adalah yang terburuk sejauh kompresi untuk meja saya diperhatikan.

Pengujian saya dengan tabel di atas menghasilkan hasil sebagai berikut.

Operasi penghitungan baris

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

Jumlah operasi kolom

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

Rata-rata operasi kolom

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

Memilih 4 kolom dari rentang tertentu menggunakan klausa 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

Apakah itu berarti ORC lebih cepat dari Parquet? Atau ada sesuatu yang dapat saya lakukan untuk membuatnya bekerja lebih baik dengan waktu respons kueri dan rasio kompresi?

Terima kasih!

hadoop  hive  parquet  snappy  orc 
— Rahul
sumber
1
Bisakah Anda membagikan algoritme umum yang digunakan untuk melakukan eksperimen itu? Namun, Anda perlu menggunakan data yang sama. Tetapi berbagi hal lain untuk mencapai hasil yang sama dengan kumpulan data yang berbeda mungkin sangat berguna untuk memberi Anda jawaban yang lebih baik atau untuk membuktikan bahwa Anda memiliki poin yang sangat baik dan untuk mengubah dunia selamanya.
— Mestre San
apakah Anda memiliki hasil percikan vs tez menggunakan orc vs parket? dari apa yang saya lihat sepertinya tez lebih cepat (3 kali lebih cepat) saat menggunakan format orc.
— David H
+1 untuk ikhtisar pembandingan yang bagus. Bagaimanapun, adakah kemungkinan Anda dapat memberikan versi terbaru karena beberapa aspek teknis di balik layar telah berubah (misalnya seperti yang dibahas dalam jawaban @jonathanChap)?
— Markus

Jawaban:

52

Menurut saya, kedua format ini memiliki kelebihannya masing-masing.

Parket mungkin lebih baik jika Anda memiliki data yang sangat bertingkat, karena ia menyimpan elemennya sebagai pohon seperti yang dilakukan Google Dremel ( Lihat di sini ).
Apache ORC mungkin lebih baik jika struktur file Anda diratakan.

Dan sejauh yang saya tahu parket belum mendukung Indeks. ORC hadir dengan Indeks berbobot ringan dan sejak Sarang 0,14, Bloom Filter tambahan yang mungkin membantu waktu respons kueri yang lebih baik terutama ketika menyangkut operasi penjumlahan.

Kompresi default Parquet adalah SNAPPY. Apakah Tabel A - B - C dan D memiliki Set Data yang sama? Jika ya, sepertinya ada sesuatu yang mencurigakan tentangnya, ketika itu hanya dikompres menjadi 1,9 GB

— PhanThomas
sumber
2
Tabel A - Format File Teks - Tanpa Kompresi ......... Tabel B - Format file ORC dengan kompresi ZLIB ......... Tabel C - ORC dengan Snappy ....... Tabel D - Parquet with Snappy ..... Saya mengerjakan tabel lain dengan ~ 150 kolom dan ukuran ~ 160 GB untuk memeriksa bagaimana performa format file di sana. Parquet membutuhkan 35 GB untuk menyimpan data 160GB sementara ORC dengan tajam membutuhkan 39GB ...... Kompresi terlihat jauh lebih baik untuk Parquet dibandingkan dengan tes yang diposting dalam pertanyaan tetapi kinerjanya kembali pada baris yang sama .. ORC bersinar di sini dengan rata kinerja yang lebih baik daripada kombinasi ORC + SNAPPY.
— Rahul
1
Struktur data untuk kasus penggunaan saya lebih datar tanpa bersarang. Saya setuju dengan komentar pengindeksan Anda tentang Parquet vs ORC dan sebenarnya itu membuat perbedaan. Apakah Anda memiliki hasil untuk dibagikan dari perbandingan kinerja keduanya? Itu mungkin membantu menenangkan hati nurani saya bahwa saya menerapkan format dengan benar. :)
— Rahul
Saya tidak pernah menguji kumpulan data saya di Parquet karena Indeks merupakan persyaratan yang diperlukan dan kami juga memiliki struktur data datar tanpa informasi bersarang. Apa yang saya temukan adalah, bahwa tergantung di mana Anda menyimpan file Anda, Anda memerlukan garis dan ukuran file yang berbeda untuk mendapatkan hasil terbaik. Ketika Anda menyimpan file Anda secara permanen di HDFS, lebih baik memiliki file dan garis yang lebih besar. "set mapred.max.split.size = 4096000000" adalah parameter yang saya gunakan untuk memengaruhi ukuran file dan kiri ukuran garis ke nilai defaultnya. Dengan pengaturan ini, ini memberi saya sekitar 94% kueri dan peningkatan kompresi.
— PhanThomas
Jika Anda ingin menyimpan file Anda di Amazon S3 sebagai penyimpanan dingin, file yang jauh lebih kecil dan ukuran garis memberi saya hasil yang jauh lebih baik. Saya menggunakan file berukuran 40-60MB yang berisi satu Stripe.
— PhanThomas
44

Anda melihat ini karena:

  • Sarang memiliki pembaca ORC vektor tetapi tidak ada pembaca parket vektor.

  • Spark memiliki pembaca parket vektor dan tidak ada pembaca ORC vektor.

  • Spark berkinerja terbaik dengan parket, sarang berkinerja terbaik dengan ORC.

Saya telah melihat perbedaan serupa saat menjalankan ORC dan Parquet dengan Spark.

Vektorisasi berarti bahwa baris didekodekan dalam batch, secara dramatis meningkatkan lokalitas memori dan pemanfaatan cache.

(benar pada Hive 2.0 dan Spark 2.1)

— jonathanChap
sumber
18
Mulai 2.3.0, spark memang memiliki pembaca ORC vektor: issues.apache.org/jira/browse/SPARK-16060
— Steen
6
Hive 2.3.0 memiliki pembaca Parket vektor - issues.apache.org/jira/browse/HIVE-14815
— ruhong
Sejak Spark 2.3, Spark mendukung pembaca ORC ber-
— Anurag Sharma
10

Baik Parket maupun ORC memiliki kelebihan dan kekurangan masing-masing. Tapi saya hanya mencoba untuk mengikuti aturan praktis sederhana - "Bagaimana data Anda bersarang dan berapa banyak kolom yang ada" . Jika Anda mengikuti Google Dremel Anda dapat menemukan bagaimana parket dirancang. Mereka menggunakan struktur seperti pohon hierarki untuk menyimpan data. Lebih banyak sarang di dalam pohon.

Tetapi ORC dirancang untuk penyimpanan file yang diratakan. Jadi jika Data Anda diratakan dengan lebih sedikit kolom, Anda dapat menggunakan ORC, jika tidak, parket akan baik-baik saja untuk Anda. Kompresi pada Data yang diratakan bekerja dengan luar biasa di ORC.

Kami melakukan beberapa benchmarking dengan file pipih yang lebih besar, mengubahnya menjadi spark Dataframe dan menyimpannya dalam format parket dan ORC di S3 dan melakukan kueri dengan ** 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.

Segera kami akan melakukan beberapa benchmarking untuk Data bersarang dan memperbarui hasilnya di sini.

— james.bondu
sumber
6

Kami melakukan beberapa benchmark yang membandingkan format file yang berbeda (Avro, JSON, ORC, dan Parquet) dalam kasus penggunaan yang berbeda.

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

Semua data tersedia untuk umum dan kode tolok ukur semuanya open source di:

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

— Owen O'Malley
sumber
5
Ini sangat berguna, tetapi harus ada penafian bahwa @Owen berfungsi untuk Horton Works, yang awalnya mengembangkan format file ORC
— Daniel Kats
1
Terima kasih! Tapi tautan kedua putus. Bisakah Anda memperbaiki atau menghapusnya dari jawaban Anda?
— Danilo Gomes
3

Keduanya memiliki kelebihan. Kami menggunakan Parquet saat bekerja bersama dengan Hive dan Impala, tetapi hanya ingin menunjukkan beberapa keuntungan ORC dibandingkan Parquet: selama kueri yang dijalankan lama, saat kueri Hive tabel ORC GC dipanggil sekitar 10 kali lebih jarang . Mungkin bukan apa-apa untuk banyak proyek, tetapi mungkin penting untuk proyek lainnya.

ORC juga membutuhkan lebih sedikit waktu, ketika Anda hanya perlu memilih beberapa kolom dari tabel. Beberapa kueri lain, terutama dengan gabungan, juga membutuhkan waktu lebih sedikit karena eksekusi kueri vektor, yang tidak tersedia untuk Parquet

Selain itu, kompresi ORC terkadang sedikit acak, sedangkan kompresi Parket jauh lebih konsisten. Sepertinya tabel ORC memiliki banyak kolom angka - tabel ini juga tidak dapat dikompres. Ini mempengaruhi kompresi zlib dan tajam

— Hasan Ammori
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.