ปาร์เก้กับ ORC เทียบกับ ORC ด้วย Snappy

88

ฉันกำลังทำการทดสอบรูปแบบการจัดเก็บข้อมูลที่มีอยู่ใน Hive และใช้ Parquet และ ORC เป็นตัวเลือกหลัก ฉันรวม ORC หนึ่งครั้งด้วยการบีบอัดเริ่มต้นและอีกครั้งกับ Snappy

ฉันได้อ่านเอกสารหลายฉบับที่ระบุว่าปาร์เก้มีความซับซ้อนด้านเวลา / พื้นที่ดีกว่าเมื่อเทียบกับ ORC แต่การทดสอบของฉันตรงข้ามกับเอกสารที่ฉันทำ

ติดตามรายละเอียดข้อมูลของฉัน

Table A- Text File Format- 2.5GB

Table B - ORC - 652MB

Table C - ORC with Snappy - 802MB

Table D - Parquet - 1.9 GB

ปาร์เก้แย่ที่สุดเท่าที่การบีบอัดสำหรับโต๊ะของฉันเกี่ยวข้อง

การทดสอบของฉันกับตารางด้านบนให้ผลลัพธ์ดังต่อไปนี้

การดำเนินการนับแถว

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

ผลรวมของการดำเนินการคอลัมน์

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

ค่าเฉลี่ยของการดำเนินการคอลัมน์

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

การเลือก 4 คอลัมน์จากช่วงที่กำหนดโดยใช้ where clause

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

หมายความว่า ORC เร็วกว่า Parquet หรือไม่? หรือมีบางอย่างที่ฉันสามารถทำได้เพื่อให้ทำงานได้ดีขึ้นกับเวลาตอบสนองของแบบสอบถามและอัตราส่วนการบีบอัด?

ขอบคุณ!

hadoop  hive  parquet  snappy  orc 
— ราหุล
แหล่งที่มา
1
คุณช่วยแบ่งปันอัลกอริทึมทั่วไปที่ใช้ในการทดลองนั้นได้ไหม จำเป็นต้องใช้ข้อมูลเดียวกันแม้ว่า แต่การแบ่งปันทุกสิ่งทุกอย่างเพื่อให้ได้ผลลัพธ์เดียวกันกับชุดข้อมูลที่แตกต่างกันอาจเป็นประโยชน์อย่างมากในการให้คำตอบที่ดีกว่าหรือเพื่อพิสูจน์ว่าคุณมีจุดที่ดีมากและสามารถเปลี่ยนแปลงโลกไปตลอดกาล
— Mestre San
คุณมีผลลัพธ์ spark vs tez โดยใช้ orc vs parquet หรือไม่? จากสิ่งที่ฉันเห็นดูเหมือนว่า tez จะเร็วกว่า (เร็วกว่า 3 เท่า) เมื่อใช้รูปแบบ orc
— David H
+1 สำหรับภาพรวมการเปรียบเทียบที่ดีของคุณ อย่างไรก็ตามมีโอกาสที่คุณสามารถให้เวอร์ชันที่อัปเดตได้หรือไม่เนื่องจากประเด็นทางเทคนิคบางอย่างเบื้องหลังมีการเปลี่ยนแปลง (เช่นพูดคุยในคำตอบของ @jonathanChap)
— Markus

คำตอบ:

52

ฉันจะบอกว่าทั้งสองรูปแบบนี้มีข้อดีในตัวเอง

ปาร์เก้อาจจะดีกว่าถ้าคุณมีข้อมูลที่ซ้อนกันมากเพราะมันเก็บองค์ประกอบต่างๆไว้เป็นต้นไม้เหมือนกับที่Google Dremelทำ ( ดูที่นี่ )
Apache ORC อาจดีกว่าถ้าโครงสร้างไฟล์ของคุณแบน

และเท่าที่ฉันรู้ว่าไม้ปาร์เก้ยังไม่รองรับ Indexes ORC มาพร้อมกับดัชนีน้ำหนักเบาและตั้งแต่ Hive 0.14 จึงมี Bloom Filter เพิ่มเติมซึ่งอาจเป็นประโยชน์ในการตอบสนองการสืบค้นที่ดีขึ้นโดยเฉพาะอย่างยิ่งเมื่อต้องรวมการดำเนินการ

การบีบอัดเริ่มต้นของ Parquet คือ SNAPPY ตาราง A - B - C และ D ถือชุดข้อมูลเดียวกันหรือไม่ ถ้าใช่ดูเหมือนว่าจะมีอะไรบางอย่างที่น่าสนใจเมื่อบีบอัดเป็น 1.9 GB เท่านั้น

— พันธุ์โธมัส
แหล่งที่มา
2
ตาราง A - รูปแบบไฟล์ข้อความ - ไม่มีการบีบอัด ......... ตาราง B - รูปแบบไฟล์ ORC พร้อมการบีบอัด ZLIB ......... ตาราง C - ORC พร้อม Snappy ....... ตาราง D - Parquet กับ Snappy ..... ฉันทำงานบนโต๊ะอื่นที่มี ~ 150 คอลัมน์และขนาด ~ 160 GB เพื่อตรวจสอบว่ารูปแบบไฟล์ทำงานอย่างไรที่นั่น Parquet ใช้เวลา 35 GB ในการจัดเก็บข้อมูล 160GB ในขณะที่ ORC ที่มีเร็วใช้ 39GB ...... การบีบอัดดูดีกว่าสำหรับ Parquet เมื่อเทียบกับการทดสอบที่โพสต์ในคำถาม แต่ประสิทธิภาพก็เป็นอีกครั้งในแนวเดียวกัน .. ORC ส่องแสงที่นี่ด้วยซ้ำ ประสิทธิภาพที่ดีกว่าการรวม ORC + SNAPPY
— Rahul
1
โครงสร้างข้อมูลสำหรับกรณีการใช้งานของฉันราบเรียบโดยไม่มีการซ้อนกัน ฉันยอมรับความคิดเห็นในการจัดทำดัชนีของคุณเกี่ยวกับ Parquet vs ORC และนั่นสร้างความแตกต่างได้จริง คุณมีผลลัพธ์ที่จะแบ่งปันจากการเปรียบเทียบประสิทธิภาพของทั้งสองหรือไม่? นั่นอาจช่วยสงบสติอารมณ์ของฉันได้ว่าฉันกำลังใช้รูปแบบอย่างถูกต้อง :)
— ราหุล
ฉันไม่เคยทดสอบชุดข้อมูลของฉันบนไม้ปาร์เก้เนื่องจากดัชนีเป็นข้อกำหนดที่จำเป็นและเรายังมีโครงสร้างข้อมูลแบบเรียบโดยไม่มีข้อมูลซ้อนกัน สิ่งที่ฉันคิดได้คือขึ้นอยู่กับตำแหน่งที่คุณจัดเก็บไฟล์ของคุณคุณต้องมีแถบและขนาดไฟล์ที่แตกต่างกันเพื่อให้ได้ผลลัพธ์ที่ดีที่สุด เมื่อคุณจัดเก็บไฟล์ของคุณอย่างถาวรบน HDFS ควรมีไฟล์ขนาดใหญ่และลายเส้น "set mapred.max.split.size = 4096000000" เป็นพารามิเตอร์ที่ฉันใช้เพื่อกำหนดขนาดไฟล์และปล่อยให้ขนาดแถบเป็นค่าเริ่มต้น ด้วยการตั้งค่านี้ทำให้ฉันมีคิวรีและการบีบอัดเพิ่มขึ้นประมาณ 94%
— PhanThomas
หากคุณต้องการจัดเก็บไฟล์ของคุณบน Amazon S3 เป็นที่เก็บความเย็นวิธีที่ไฟล์ขนาดเล็กลงและขนาดลายให้ผลลัพธ์ที่ดีกว่ามาก ฉันใช้ไฟล์ขนาด 40-60MB ที่มี Stripe เดียว
— PhanThomas
44

คุณเห็นสิ่งนี้เนื่องจาก:

  • Hive มีเครื่องอ่าน ORC แบบเวกเตอร์ แต่ไม่มีเครื่องอ่านไม้ปาร์เก้แบบเวกเตอร์

  • Spark มีเครื่องอ่านไม้ปาร์เก้แบบเวกเตอร์และไม่มีเครื่องอ่าน ORC แบบเวกเตอร์

  • Spark ทำงานได้ดีที่สุดกับไม้ปาร์เก้รังผึ้งทำงานได้ดีที่สุดกับ ORC

ฉันเห็นความแตกต่างที่คล้ายกันเมื่อใช้ ORC และ Parquet กับ Spark

Vectorization หมายความว่าแถวต่างๆจะถูกถอดรหัสเป็นแบตช์ปรับปรุงพื้นที่หน่วยความจำและการใช้แคชอย่างมาก

(ถูกต้องตาม Hive 2.0 และ Spark 2.1)

— jonathanChap
แหล่งที่มา
18
ในฐานะของ 2.3.0 จุดประกายไม่มี vectorized อ่าน ORC: issues.apache.org/jira/browse/SPARK-16060
— สตีน
6
Hive 2.3.0 ได้ทำ vectorized Parquet reader - issue.apache.org/jira/browse/HIVE-14815
— ruhong
ตั้งแต่ Spark 2.3 Spark รองรับเครื่องอ่าน ORC แบบเวกเตอร์spark.apache.org/docs/latest/sql-data-sources-orc.html
— Anurag Sharma
10

ทั้งไม้ปาร์เก้และ ORC มีข้อดีและข้อเสียในตัวเอง แต่ผมก็พยายามที่จะทำตามกฎง่ายๆของหัวแม่มือ - "วิธีที่ซ้อนกันเป็นข้อมูลของคุณและจำนวนคอลัมน์จะมี" หากคุณติดตามGoogle Dremelคุณจะพบว่าไม้ปาร์เก้ถูกออกแบบมาอย่างไร พวกเขาใช้โครงสร้างแบบต้นไม้ลำดับชั้นในการจัดเก็บข้อมูล ยิ่งทำรังลึกลงไปในต้นไม้

แต่ORCได้รับการออกแบบมาสำหรับที่เก็บไฟล์แบบแบน ดังนั้นหากข้อมูลของคุณแบนโดยมีคอลัมน์น้อยลงคุณสามารถใช้ ORC ได้มิฉะนั้นไม้ปาร์เก้จะดีสำหรับคุณ การบีบอัดข้อมูลแบบแบนทำงานได้อย่างน่าอัศจรรย์ใน ORC

เราทำการเปรียบเทียบกับไฟล์ที่แบนขนาดใหญ่ขึ้นแปลงเป็นจุดประกาย Dataframe และจัดเก็บไว้ในรูปแบบไม้ปาร์เก้และ ORC ในS3และทำการค้นหาด้วย ** 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.

เร็ว ๆ นี้เราจะทำการเปรียบเทียบสำหรับข้อมูลที่ซ้อนกันและอัปเดตผลลัพธ์ที่นี่

— james.bondu
แหล่งที่มา
6

เราได้ทำการเปรียบเทียบเปรียบเทียบรูปแบบไฟล์ต่างๆ (Avro, JSON, ORC และ Parquet) ในกรณีการใช้งานที่แตกต่างกัน

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

ข้อมูลทั้งหมดนี้เปิดเผยต่อสาธารณะและโค้ดมาตรฐานเป็นโอเพ่นซอร์สทั้งหมดที่:

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

— Owen O'Malley
แหล่งที่มา
5
สิ่งนี้มีประโยชน์มาก แต่ควรมีข้อจำกัดความรับผิดชอบว่า @Owen ใช้งานได้กับ Horton Works ซึ่งเดิมพัฒนารูปแบบไฟล์ ORC
— Daniel Kats
1
ขอบคุณ! แต่ลิงค์ที่สองเสีย คุณช่วยแก้ไขหรือลบออกจากคำตอบของคุณได้ไหม
— Danilo Gomes
3

ทั้งสองคนมีข้อดีของพวกเขา เราใช้ Parquet ในที่ทำงานร่วมกับ Hive และ Impala แต่เพียงต้องการชี้ให้เห็นข้อดีบางประการของ ORC เหนือ Parquet: ในระหว่างการสืบค้นที่ดำเนินการเป็นเวลานานเมื่อ Hive สอบถามตาราง ORC GC ถูกเรียกบ่อยน้อยกว่า 10 เท่าครั้งไม่บ่อย อาจไม่มีอะไรสำหรับหลาย ๆ โครงการ แต่อาจสำคัญสำหรับคนอื่น ๆ

ORC ยังใช้เวลาน้อยกว่ามากเมื่อคุณต้องการเลือกเพียงไม่กี่คอลัมน์จากตาราง คำค้นหาอื่น ๆ โดยเฉพาะอย่างยิ่งเมื่อใช้การรวมยังใช้เวลาน้อยลงเนื่องจากการดำเนินการสืบค้นแบบเวกเตอร์ซึ่งไม่สามารถใช้ได้กับ Parquet

นอกจากนี้การบีบอัด ORC บางครั้งก็สุ่มเล็กน้อยในขณะที่การบีบอัดไม้ปาร์เก้มีความสม่ำเสมอมากกว่า ดูเหมือนว่าเมื่อตาราง ORC มีคอลัมน์ตัวเลขจำนวนมาก - มันจะไม่บีบอัดด้วย มีผลต่อการบีบอัด zlib และ snappy

— ฮาซันอัมโมรี
แหล่งที่มา
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.