Parquet Version 2 แสดงผลการปรับปรุงประสิทธิภาพแต่เผชิญอุปสรรคในการนำมาใช้เนื่องจากการแยกส่วนของระบบนิเวศ

ทีมชุมชน BigGo
Parquet Version 2 แสดงผลการปรับปรุงประสิทธิภาพแต่เผชิญอุปสรรคในการนำมาใช้เนื่องจากการแยกส่วนของระบบนิเวศ

รูปแบบไฟล์ Apache Parquet พบว่าตัวเองติดอยู่ระหว่างสองโลก ในขณะที่ Version 2 ได้รับการสรุปเป็นเวอร์ชันสุดท้ายมาหลายปีแล้วและมีการปรับปรุงประสิทธิภาพที่ชัดเจน ชุมชนวิศวกรรมข้อมูลยังคงติดอยู่กับ Version 1 เป็นส่วนใหญ่เนื่องจากข้อกังวลเรื่องความเข้ากันได้และการแยกส่วนของระบบนิเวศ

ประโยชน์ด้านประสิทธิภาพเป็นจริงแต่เป็นเพียงเล็กน้อย

การทดสอบข้ามชุดข้อมูลหลักสองชุดเผยให้เห็นว่า Parquet Version 2 ให้การปรับปรุงที่สม่ำเสมอเหนือรุ่นก่อนหน้า ขนาดไฟล์ลดลง 2-37% ขึ้นอยู่กับวิธีการบีบอัด โดยไฟล์ที่ไม่ได้บีบอัดจะเห็นผลได้มากที่สุด ประสิทธิภาพการเขียนดีขึ้น 4-27% ในขณะที่การดำเนินการอ่านเร็วขึ้น 1-19% การปรับปรุงจะเด่นชัดที่สุดกับชุดข้อมูลที่มีค่าตัวเลขจำนวนมาก ซึ่งการเข้ารหัสใหม่สามารถทำงานได้อย่างมีประสิทธิภาพมากขึ้น

ผลได้เหล่านี้มาจากการเข้ารหัสข้อมูลที่ดีขึ้นก่อนที่จะมีการบีบอัด Version 2 รวมถึงวิธีการเข้ารหัสใหม่เช่น RLE_DICTIONARY และ DELTA_BYTE_ARRAY ที่บีบอัดข้อมูลได้อย่างมีประสิทธิภาพมากขึ้น สิ่งนี้ทำให้อัลกอริทึมการบีบอัดแบบดั้งเดิมมีงานน้อยลง ซึ่งอธิบายได้ว่าทำไมไฟล์ที่ไม่ได้บีบอัดจึงเห็นการปรับปรุงสัมพัทธ์ที่ใหญ่ที่สุด

การปรับปรุงประสิทธิภาพของ Parquet Version 2

การลดขนาดไฟล์ (ชุดข้อมูล Italian Government Dataset):

  • UNCOMPRESSED: เล็กลง 37%
  • SNAPPY: เล็กลง 10%
  • GZIP: เล็กลง 5%
  • ZSTD: เล็กลง 2%
  • LZ4_RAW: เล็กลง 8%
  • LZO: เล็กลง 9%

การปรับปรุงประสิทธิภาพการเขียน (ชุดข้อมูล New York Taxi Dataset):

  • UNCOMPRESSED: เร็วขึ้น 13%
  • SNAPPY: เร็วขึ้น 10%
  • GZIP: เร็วขึ้น 27%
  • ZSTD: เร็วขึ้น 11%
  • LZ4_RAW: เร็วขึ้น 11%
  • LZO: เร็วขึ้น 9%

การปรับปรุงประสิทธิภาพการอ่าน (ชุดข้อมูล New York Taxi Dataset):

  • UNCOMPRESSED: เร็วขึ้น 12%
  • SNAPPY: เร็วขึ้น 15%
  • GZIP: เร็วขึ้น 16%
  • ZSTD: เร็วขึ้น 18%
  • LZ4_RAW: เร็วขึ้น 19%
  • LZO: เร็วขึ้น 18%

ความซับซ้อนในการดำเนินการจุดประกายความกังวลของนักพัฒนา

การดำเนินการอ้างอิง Java ได้รับการวิพากษ์วิจารณ์จากนักพัฒนาที่ทำงานกับรูปแบบนี้ การดำเนินการ bit-packing เพียงอย่างเดียวสร้างโค้ด Java 74,000 บรรทัดเพื่อจัดการกับทุกการรวมกันของความกว้างบิต endianness และความยาวค่า แนวทางนี้ให้ความสำคัญกับประสิทธิภาพมากกว่าความสามารถในการบำรุงรักษาและสร้างความท้าทายสำหรับนักพัฒนาที่พยายามดำเนินการสนับสนุน Parquet ในภาษาอื่นหรือบนฮาร์ดแวร์ที่แตกต่างกันเช่น GPU

ความซับซ้อนขยายไปไกลกว่าแค่โค้ด ช่องว่างในเอกสารทำให้ผู้ดำเนินการใหม่เข้าใจเค้าโครงไฟล์ได้อย่างถูกต้องยาก แม้แต่รายละเอียดพื้นฐานเช่นวิธีที่ส่วนหัวของหน้าถูกรวมไว้ในการคำนวณขนาดที่บีบอัดต้องการการขุดค้นผ่าน hex dump มากกว่าเอกสารข้อกำหนดที่ชัดเจน

การถกเถียงมาตรฐานสี่ปีขัดขวางความก้าวหน้า

สิ่งที่น่ากังวลที่สุดคือความไม่เห็นด้วยที่ดำเนินต่อไปเกี่ยวกับสิ่งที่ถือเป็นฟังก์ชันหลัก Version 2 pull request ที่พูดคุยเกี่ยวกับปัญหานี้เปิดมาสี่ปีโดยไม่มีการแก้ไข การถกเถียงมุ่งเน้นไปที่ว่าการปรับปรุงการเข้ารหัสและการเปลี่ยนแปลงโครงสร้างหน้าควรได้รับการปฏิบัติเป็นคุณลักษณะแยกต่างหากที่พัฒนาอย่างอิสระมากกว่าการอัปเกรดเวอร์ชันแบบเดียว

การเป็นอัมพาตของมาตรฐานนี้สร้างปัญหาไก่กับไข่ เครื่องมือสืบค้นเช่นในแพลตฟอร์มข้อมูลหลักจะไม่สนับสนุน Version 2 อย่างเต็มที่โดยไม่มีข้อกำหนดความเข้ากันได้ที่ชัดเจน ในขณะเดียวกัน นักพัฒนาเครื่องมือหลีกเลี่ยงการนำคุณลักษณะ Version 2 มาใช้เพราะพวกเขาไม่สามารถรับประกันความเข้ากันได้กับระบบปลายทางที่ยังคงคาดหวังไฟล์ Version 1

ความระมัดระวังขององค์กรเสริมสถานะเดิม

ความท้าทายด้านความเข้ากันได้เสริมสร้างเหตุผลที่องค์กรมักจะยึดติดกับโซลูชันเชิงพาณิชย์ที่ก่อตั้งขึ้นแล้วแม้จะมีข้อจำกัดทางเทคนิค ในอุตสาหกรรมที่การไม่มีข้อมูลสามารถจบอาชีพได้ ผลได้ด้านประสิทธิภาพเพียงเล็กน้อยจาก Version 2 ไม่สมเหตุสมผลกับความเสี่ยงของความล้มเหลวในการรวมระบบกับระบบบุคคลที่สามที่ยังคงคาดหวังไฟล์ Version 1

ปัญหาเช่นนี้เป็นเหตุผลที่รัฐบาลและองค์กรยังคงทำงานบน Oracle และ SQL Server... อีเมล CYA นั้นและคอที่จะบีบเป็นเหตุผลที่ Oracle ทำข้อตกลงใบอนุญาต 7 และ 8 หลักกับองค์กรที่ขายโซลูชันซอฟต์แวร์ที่ด้อยกว่าเมื่อเทียบกับตัวเลือกโอเพ่นซอร์ส

แนวทางอนุรักษ์นิยมนี้หมายความว่าแม้ในขณะที่ส่วนประกอบแต่ละส่วนของระบบนิเวศข้อมูลเพิ่มการสนับสนุน Version 2 การนำมาใช้ยังคงถูกจำกัดโดยจุดอ่อนที่สุดในห่วงโซ่เครื่องมือของแต่ละองค์กร

เส้นทางไปข้างหน้าต้องการการประสานงาน

สำหรับองค์กรที่มีการควบคุมอย่างเต็มที่เหนือไปป์ไลน์ข้อมูลของพวกเขา การนำ Version 2 มาใช้ทำให้เกิดความรู้สึกในวันนี้ การปรับปรุงประสิทธิภาพแม้จะไม่น่าทึ่งแต่ก็สม่ำเสมอและมาพร้อมกับข้อเสียเปรียบเมื่อความเข้ากันได้ไม่ใช่ความกังวล อย่างไรก็ตาม การนำมาใช้ของระบบนิเวศที่กว้างขึ้นจะต้องการการประสานงานระหว่างเครื่องมือสืบค้นหลัก รูปแบบ data lake เช่น Iceberg และ Delta Lake และไลบรารีที่ได้รับความนิยมเช่น Pandas

ประสบการณ์ของชุมชน Parquet สะท้อนความท้าทายที่เผชิญโดยมาตรฐานที่พัฒนาอื่นๆ เรื่องราวความสำเร็จเช่น Linux แสดงให้เห็นว่าความเป็นผู้นำทางเทคนิคที่แข็งแกร่งสามารถป้องกันการลังเลเป็นเวลานานที่ทำให้การนำ Parquet Version 2 มาใช้ช้าลง จนกว่าความชัดเจนที่คล้ายคลึงกันจะเกิดขึ้นรอบการพัฒนาของ Parquet รูปแบบจะยังคงให้บริการชุมชนวิศวกรรมข้อมูลได้ดี แม้จะไม่ได้อยู่ในศักยภาพเต็มที่

อ้างอิง: The two versions of Parquet