Polars 2.0: เหตุใดการ join จึงไม่รักษาลำดับแถวอีกต่อไป

วิดีโอนี้ครอบคลุมอะไรบ้าง

• การเรียก collect() บน lazy query ตอนนี้ใช้ streaming engine เป็นค่าเริ่มต้น ซึ่งไม่รับประกันลำดับแถวสำหรับการ join, group_by และ unpivot
• คู่มือการย้ายข้อมูลระบุว่าลำดับไม่ใช่ลำดับก่อน 2.0 อีกต่อไปและไม่รับประกัน หากคุณพึ่งพาลำดับนั้น ควรจัดเรียงอย่างชัดเจน
• ในการรันของเรา การ inner join เริ่มต้นส่งคืน input order เป็น False; maintain_order="left_right" ในการ join ส่งคืน True เครื่องเดียว, รันเดียว, รูปแบบการ join เดียว
• Out-of-core spilling เปิดใช้งานโดยค่าเริ่มต้น: เริ่มที่ประมาณ 80% ของ RAM โดยมีงบประมาณดิสก์เริ่มต้น 64 GB Out-of-core join และ group_by อยู่ในแผนงาน
• collect_schema() ตรวจจับคอลัมน์ที่หายไปก่อนที่จะมีการอ่านข้อมูลใดๆ แต่การ cast ที่ล้มเหลวบนค่าเดียวจะล้มเหลวที่ collect() เท่านั้น
• การเปรียบเทียบ TPC-H และ TPC-DS เป็นการรันของ vendor เองบนข้อมูลที่ได้มา และเชิงอรรถระบุว่าผลลัพธ์ไม่สามารถเปรียบเทียบกับเกณฑ์มาตรฐานอย่างเป็นทางการได้

บทถอดเสียงที่แปลแล้ว

แปลจากการบรรยายภาษาอังกฤษต้นฉบับ เสียงและคำบรรยายที่มีให้จะควบคุมโดย YouTube

ทำไมลำดับเริ่มต้นถึงเปลี่ยนไป?

0:00 คุณคิดว่าการ join จะส่งคืนแถวของคุณตามลำดับที่คุณเขียน Polars 2.0 หยุดสัญญาว่าจะทำอย่างนั้นเป็นค่าเริ่มต้นโดยเจตนา ในวิดีโอนี้: ทำไมค่าเริ่มต้นถึงเปลี่ยนไป? มันได้อะไรมาบ้าง? และสคริปต์ไหนของคุณจะพังก่อน? นี่คือ The Daily Diff, ภายใต้ฝาครอบ Polars เป็นไลบรารี DataFrame แบบโอเพนซอร์ส: engine ตารางที่คุณเรียกใช้จาก Python,

0:20 โดยมีแกนหลักเขียนด้วย Rust มันฟรีภายใต้ใบอนุญาต MIT และคุณติดตั้งได้ด้วย pip install polars รายละเอียดหนึ่งก่อน สวิตช์ที่ทำให้ลำดับเก่ากลับมาคืออาร์กิวเมนต์ของการ join เอง ฉันจะกลับมาพูดถึงมันในตอนท้าย ตั้งแต่ 2.0 เป็นต้นไป collect จะรัน streaming engine โดยค่าเริ่มต้น Streaming จะแบ่ง query ออกเป็นส่วนๆ ที่รันแบบขนาน, และส่วนต่างๆ จะเสร็จสิ้นเมื่อเสร็จ

0:42 สำหรับ join, group by และ unpivot เวอร์ชันนี้ไม่รับประกันลำดับ ใครจะได้รับผลกระทบก่อน? ใครก็ตามที่เปรียบเทียบเอาต์พุตกับไฟล์ที่บันทึกไว้ แถวต่อแถว การทดสอบนั้นอาจผ่านบนแล็ปท็อปของคุณและล้มเหลวบนเครื่องอื่น ถัดไป คู่มือการย้ายข้อมูล

คู่มือการย้ายข้อมูลสัญญาอะไร?

0:57 ระบุว่าลำดับแถวที่แสดงด้านบนไม่รับประกัน ดังนั้นหากคุณพึ่งพาลำดับนั้น ให้จัดเรียงอย่างชัดเจน Out-of-core ก็เปิดใช้งานโดยค่าเริ่มต้นเช่นกัน มันเริ่มเขียนข้อมูลลงดิสก์ที่ประมาณ 80 เปอร์เซ็นต์ของ RAM, โดยมีงบประมาณ 64 กิกะไบต์ Sort, window functions และหลาย expression สามารถเขียนข้อมูลลงดิสก์ได้แล้ว Joins และ group-bys กำลังจะมา

เกณฑ์มาตรฐานนี้เป็นการแข่งขันที่ยุติธรรมหรือไม่?

1:17 Polars กล่าวว่ามันเอาชนะ DataFusion และ DuckDB ใน TPC-H และ TPC-DS เกณฑ์มาตรฐาน ตัวเลขมาจากผลการรันของพวกเขาเอง บนข้อมูลที่ได้มา, และเชิงอรรถระบุว่าไม่สามารถเปรียบเทียบกับผลลัพธ์อย่างเป็นทางการได้ ตัวเลขของพวกเขาเองระบุว่า Polars เร็วขึ้นประมาณ 3.8 เท่าจาก 16 คอร์เป็น 192 คอร์ บน TPC-H พวกเขายังกล่าวอีกว่าเธรดพิเศษของเครื่องขนาดใหญ่ทำให้ query ขนาดเล็กช้าลง

เราเห็นอะไรเมื่อเราเรียกใช้?

1:41 เราได้รันการ join เดียวกันสองครั้งบน Polars 2.0.0 การรันเริ่มต้นจะสลับแถว ด้วย flag ลำดับอินพุตจะยังคงอยู่ ค้นหาการ join ที่ป้อนข้อมูลให้กับการทดสอบ การ join ใดๆ ที่ไม่มีการจัดเรียงตามหลังคือการตัดสินใจเกี่ยวกับลำดับแถวที่คุณไม่เคยทำ Polars 2.0 เข้มงวดกับประเภทข้อมูลมากขึ้น

เข้มงวดกว่าหมายถึงเร็วกว่าหรือไม่?

1:58 การตรวจสอบ schema จะตรวจจับคอลัมน์ที่หายไปก่อนที่จะมีการอ่านข้อมูลใดๆ มันไม่สามารถตรวจจับการ cast ที่ล้มเหลวบนแถวเดียวได้ เพราะข้อผิดพลาดนั้นต้องรอ ข้อมูล ตอนนี้วงจรที่ฉันเปิดไว้

ฉันจะเรียกคืนลำดับเก่าได้อย่างไร?

2:08 สวิตช์อยู่ในการ join ตั้งค่า maintain order ในการ join หรือเพิ่ม sort หลังจากนั้น คู่มือแนะนำให้ใช้ sort แฟล็กการ join รักษาลำดับในการรันของเรา โดยที่ลำดับด้านซ้ายถูกเก็บไว้เป็น ซ้าย, ขวา คำตัดสิน, ภายใต้ฝาครอบ: NEEDS REVIEW

คำตัดสินคืออะไร?

2:22 ฉันจะตรวจสอบทุกการ join ก่อนอัปเกรด มีคำถามเกี่ยวกับเรื่องนี้หรือไม่? ใส่ไว้ในความคิดเห็น และนั่นคือ diff สำหรับวันนี้ ฉันคือนิโก้จาก Axrisi Merge อย่างรับผิดชอบ

แหล่งที่มา

1. Release of Polars 2.0Polars (pola.rs)
2. Polars 2.0 upgrade guidePolars documentation
3. Polars homepagePolars (pola.rs)
4. polars-2.0-benchmark repositoryPolars on GitHub
5. Release of Polars 2.0 (Hacker News discussion)Hacker News