Snappy ile Parke - ORC - ORC

Hive ile kullanılabilen depolama formatları üzerinde birkaç test yapıyorum ve ana seçenekler olarak Parquet ve ORC'yi kullanıyorum. ORC'yi bir kez varsayılan sıkıştırmayla ve bir kez de Snappy ile dahil ettim.

ORC'ye kıyasla Parquet'in zaman / mekan karmaşıklığında daha iyi olduğunu belirten birçok belge okudum, ancak testlerim geçtiğim belgelerin tam tersi.

Verilerimin bazı ayrıntılarını takip eder.

Table A- Text File Format- 2.5GB

Table B - ORC - 652MB

Table C - ORC with Snappy - 802MB

Table D - Parquet - 1.9 GB

Masam için kompresyon söz konusu olduğunda parke en kötüydü.

Yukarıdaki tablolarla yaptığım testler aşağıdaki sonuçları verdi.

Satır sayma işlemi

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

Bir sütun işleminin toplamı

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

Bir sütun işleminin ortalaması

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 

Where cümlesini kullanarak belirli bir aralıktan 4 sütun seçme

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 

Bu ORC'nin Parquet'ten daha hızlı olduğu anlamına mı geliyor? Veya sorgu yanıt süresi ve sıkıştırma oranıyla daha iyi çalışmasını sağlamak için yapabileceğim bir şey var mı?

Teşekkürler!

Bu formatların her ikisinin de kendi avantajları olduğunu söyleyebilirim.

Yüksek oranda iç içe geçmiş verileriniz varsa parke daha iyi olabilir, çünkü öğelerini Google Dremel'in yaptığı gibi bir ağaç olarak depolar ( Buraya bakın ).
Dosya yapınız düzleştirilmişse Apache ORC daha iyi olabilir.

Ve bildiğim kadarıyla parke henüz İndeksleri desteklemiyor. ORC, hafif bir İndeks ile birlikte gelir ve Hive 0.14'ten bu yana, özellikle işlemlerin toplanması söz konusu olduğunda daha iyi sorgu yanıt süresi için yardımcı olabilecek ek bir Bloom Filtresi ile birlikte gelir.

Parke varsayılan sıkıştırması SNAPPY'dir. Tablo A - B - C ve D aynı Veri Kümesine mi sahip? Evet ise, yalnızca 1,9 GB'a sıkıştırıldığında, gölgeli bir şey var gibi görünüyor

Bunu görüyorsunuz çünkü:

• Hive, vektörleştirilmiş bir ORC okuyucusuna sahiptir, ancak vektörleştirilmiş parke okuyucusu yoktur.

• Spark'ın vektörlü parke okuyucusu vardır ve vektörleştirilmiş ORC okuyucusu yoktur.

• Spark, parke ile en iyi performansı gösterirken, Hive, ORC ile en iyi performansı gösterir.

ORC ve Parquet'i Spark ile çalıştırırken benzer farklılıklar gördüm.

Vektörizasyon, satırların toplu olarak kodunun çözülmesi anlamına gelir, bu da bellek yerelliğini ve önbellek kullanımını önemli ölçüde geliştirir.

(Hive 2.0 ve Spark 2.1'den itibaren doğru)

Hem Parke hem de ORC'nin kendi avantajları ve dezavantajları vardır. Ancak basit bir genel kuralı izlemeye çalışıyorum - "Verileriniz ne kadar iç içe geçmiş ve orada kaç sütun var" . Google Dremel'i takip ederseniz, parkenin nasıl tasarlandığını öğrenebilirsiniz. Verileri depolamak için hiyerarşik ağaç benzeri bir yapı kullanırlar. Ağacın daha derin yuvalanması.

Ancak ORC , düzleştirilmiş bir dosya deposu için tasarlanmıştır. Dolayısıyla, Verileriniz daha az sütunla düzleştirilmişse, ORC ile gidebilirsiniz, aksi takdirde parke sizin için uygun olur. Düzleştirilmiş Veriler üzerindeki sıkıştırma, ORC'de harika bir şekilde çalışıyor.

Biz, bazı daha büyük bir düzleştirilmiş dosyası ile kıyaslama yaptığımız Dataframe kıvılcım onu dönüştürülür ve hem parke ve ORC formatında saklanan S3 ** ve ** Redshift-Spectrum ile sorgulama etmedi.

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.

Yakında iç içe geçmiş Veriler için bazı kıyaslamalar yapacak ve sonuçları burada güncelleyeceğiz.

Farklı dosya formatlarını (Avro, JSON, ORC ve Parquet) farklı kullanım durumlarında karşılaştırarak bazı kıyaslamalar yaptık.

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

Veriler herkese açıktır ve karşılaştırma kodunun tamamı şu adreste açık kaynaktır:

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

Her ikisinin de avantajları var. İşyerinde Parquet'i Hive ve Impala ile birlikte kullanıyoruz, ancak ORC'nin Parquet'e göre birkaç avantajına işaret etmek istedik: Hive, ORC tablolarını sorgularken, GC yaklaşık 10 kat daha az çağrılır . Pek çok proje için hiçbir şey olmayabilir, ancak diğerleri için çok önemli olabilir.

ORC, tablodan yalnızca birkaç sütun seçmeniz gerektiğinde çok daha az zaman alır. Parquet için mevcut olmayan, vektörize edilmiş sorgu yürütme nedeniyle özellikle birleştirmelerle ilgili diğer bazı sorgular da daha az zaman alır.

Ayrıca ORC sıkıştırması bazen biraz rastgele olurken, Parquet sıkıştırması çok daha tutarlıdır. ORC tablosunda çok sayıda sayı sütunu olduğu zaman görünüyor - aynı zamanda sıkıştırılmıyor. Hem zlib hem de hızlı sıkıştırmayı etkiler