Polars 2.0 ออกแล้ว รายงานเร็วขึ้นได้ แต่ลำดับแถวอาจเปลี่ยน

Polars 2.0 รุ่นจริงออกแล้ว พร้อมเปลี่ยนวิธีประมวลผลเริ่มต้นจนลำดับแถวในรายงานอาจเปลี่ยน ตามประกาศ Polars วันที่ 6 ตุลาคม 2026 แปลว่า คนทำรายงานด้วย Python ต้องตรวจมากกว่าว่าโปรแกรมรันจบหรือเปล่าครับ

Polars คือเครื่องมือจัดการข้อมูลแบบตารางในภาษา Python ซึ่งใช้เขียนคำสั่งให้คอมพิวเตอร์ทำงานตามขั้นตอน ข่าวนี้เกี่ยวกับคนที่รวมยอดขาย ทำบัญชี หรือเตรียมข้อมูลขึ้นหน้าสรุปงาน โดยจุดเสี่ยงคือคำสั่งเดิมอาจได้แถวเรียงต่างไปหลังอัปเกรด ตามคู่มือย้ายรุ่น

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

สรุป 30 วินาที: เกิดอะไรขึ้น

Polars เปิดรุ่นจริงพร้อมระบบช่วยใช้ดิสก์เมื่อหน่วยความจำเริ่มตึง รองรับ SQL เป็นส่วนสำคัญของผลิตภัณฑ์ และเพิ่ม Map สำหรับข้อมูลคู่ชื่อกับค่า โดย SQL คือภาษาคำสั่งเลือกและสรุปข้อมูล ส่วนรายละเอียดทั้งหมดอยู่ในประกาศรุ่นจริง

การเปลี่ยนที่ต้องตรวจทันทีคือ LazyFrame หรือแผนงานที่เก็บคำสั่งไว้ก่อนคำนวณ เมื่อเรียก collect() เพื่อรับผลลัพธ์ ตอนนี้จะใช้ streaming engine ซึ่งเป็นระบบประมวลผลข้อมูลเป็นส่วน ๆ ตามคู่มือ Polars ระบบนี้ไม่รับประกันลำดับแถวของงานบางประเภทครับ

งานที่เกี่ยวข้องได้แก่ group_by ซึ่งรวมข้อมูลตามกลุ่ม join ซึ่งจับคู่ตารางด้วยข้อมูลที่ตรงกัน และ unpivot ซึ่งเปลี่ยนคอลัมน์ให้กลายเป็นแถว ตามคู่มืออัปเกรด ถ้ารายงานต้องมีลำดับแน่นอน คู่มือแนะนำให้เรียงอย่างชัดเจน หรือขอรักษาลำดับในคำสั่งที่รองรับ

ทำไมเรื่องนี้เกี่ยวกับคุณ

ลองนึกถึงรายงานรายเดือนที่ฝ่ายบัญชีเปิดแล้วเทียบกับไฟล์เดิม หากโค้ดรวมยอดตามลูกค้าไว้ แต่ไม่ได้สั่งเรียงลูกค้า ลำดับที่เคยเห็นอาจเปลี่ยนหลังอัปเกรด นี่เป็นผลกระทบที่เป็นไปได้จากคำเตือนเรื่องการพึ่งลำดับแถวโดยบังเอิญในคู่มือ Polars

ยอดรวมตรงแล้ว แปลว่าไฟล์พร้อมส่งเสมอหรือครับ? สำหรับขั้นตอนตรวจงาน ผมแนะนำให้แยกความถูกต้องของค่าออกจากรูปแบบที่ผู้รับต้องใช้ หากคนปลายทางอ่านตามลำดับสาขา หรือต้องเทียบรายการเดิม ควรเขียนลำดับนั้นเป็นเงื่อนไขของรายงานให้ชัด

คนที่รับเฉพาะ Excel ไม่จำเป็นต้องรู้ชื่อเครื่องประมวลผล แต่ควรแจ้งคนทำไฟล์ว่าต้องการเรียงตามอะไร ส่วนคนใช้สมุดงานที่รวมโค้ดกับผลลัพธ์ หรือ notebook ควรตรวจจุดเรียก collect() เพราะเป็นจุดที่ค่าเริ่มต้นเปลี่ยน ตามคู่มือทางการ

อย่าเหมารวมว่าคำสั่งตารางทั้งหมดเปลี่ยนไปครับ DataFrame คือตารางข้อมูลที่พร้อมใช้งาน และการทำงานแบบคำนวณทันทีบน DataFrame ยังใช้ระบบ in-memory หรือประมวลผลในหน่วยความจำตามเดิม โดยมีข้อยกเว้นของเส้นทางอ่าน CSV และคำสั่ง SQL ที่คู่มือแจกแจงไว้ในรายละเอียดการย้ายรุ่น

ทำงานยังไง

DataFrame กับ LazyFrame ต่างกันตรงที่อย่างแรกเป็นตารางพร้อมทำงาน ส่วนอย่างหลังเก็บแผนว่าจะเลือก จับคู่ และสรุปข้อมูลอย่างไร เมื่อเรียก collect() จึงได้ผลลัพธ์จริง โดย engine="auto" ของงานแบบ Lazy เปลี่ยนจาก in-memory ไปเป็น streaming ตามคู่มือ Polars

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

ในข้อมูลจริง maintain_order=True ใช้ขอรักษาลำดับ เช่นตัวอย่าง group_by ที่ Real Python ยกมา แต่สำหรับ join ที่ต้องการลำดับตามตารางฝั่งซ้าย คู่มือระบุ maintain_order="left" โดยตรงในตัวอย่างการจับคู่ตาราง จึงไม่ควรเติมค่าเดียวกันทุกคำสั่งโดยไม่ดูเอกสาร

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

ส่วน out-of-core หรือการทำงานที่ไม่ต้องเก็บข้อมูลทั้งหมดในหน่วยความจำ มีวิธี spill-to-disk คือพักข้อมูลบางส่วนลงดิสก์ ผู้พัฒนาระบุว่าเริ่มพักข้อมูลเมื่อใช้ RAM ราว 80% ในประกาศรุ่นจริง แปลว่าเริ่มใช้พื้นที่เก็บข้อมูลช่วยเมื่อหน่วยความจำใกล้เต็ม โดยผู้พัฒนาย้ำว่าเกณฑ์นี้อาจต้องปรับแต่ง

จุดหักมุม: เร็วขึ้นได้ แต่ยังต้องกำหนดลำดับเอง

แต่การรันจบเร็วกว่าเดิม ไม่ได้เป็นคำรับรองว่ารายงานจะเรียงเหมือนเดิม Real Python ชี้ว่า Polars รุ่นก่อนก็ไม่ได้สัญญาลำดับผล group_by หากไม่ขอรักษาลำดับ การเปลี่ยนเครื่องประมวลผลทำให้ข้อควรระวังเดิมมองข้ามได้ยากขึ้น

แต่ระบบพักข้อมูลลงดิสก์ยังไม่ได้ครอบคลุมทุกงาน Polars ระบุว่ารองรับการเรียง งานคำนวณตามหน้าต่างข้อมูล และคำสั่งหลายชนิด ส่วน join กับ group_by ยังอยู่ในแผนพัฒนาต่อ อย่าเพิ่งอ่านคำว่าเปิดเป็นค่าเริ่มต้นแล้วสรุปว่างานใหญ่ทุกแบบจะจบได้ครับ

เรื่องเงิน / ผลกระทบ

สำหรับทีมทำรายงาน ประโยชน์ที่ควรทดลองคือเวลารอและการใช้ RAM หรือหน่วยความจำที่คอมพิวเตอร์ใช้ระหว่างทำงาน Polars กล่าวว่าการใช้ streaming ช่วยเรื่องหน่วยความจำและประสิทธิภาพในคำสั่งส่วนใหญ่ แต่ยังไม่มีผลทดสอบรายงานของคุณให้ใช้คำนวณว่าประหยัดเวลากี่ชั่วโมงหรือเงินกี่บาท

ผู้พัฒนากำหนดงบพื้นที่ดิสก์เริ่มต้นไว้ 64GB ตามประกาศ Polars แปลว่ามีเพดานสำหรับพื้นที่พักข้อมูล ไม่ได้หมายความว่าทุกงานจะใช้พื้นที่ทั้งหมดนั้น ผมแนะนำให้ทีม IT ตรวจพื้นที่ว่างในเครื่องทดลอง พร้อมวัดทั้งเวลา RAM และพื้นที่ดิสก์ก่อนตัดสินใจเรื่องเครื่องใหม่

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

ด้านความถูกต้อง Polars เข้มงวดกับ dtype หรือชนิดของข้อมูลมากขึ้น เช่นจำนวนเต็ม ข้อความ และวันที่ ผู้พัฒนาต้องการให้เจอข้อมูลไม่เข้ากันเร็วขึ้น แทนการแปลงให้อัตโนมัติจนซ่อนปัญหา ตามประกาศช่วงก่อนรุ่นจริง สำหรับงานบัญชี ผมแนะนำให้ตรวจการแปลงชนิดข้อมูลเป็นพิเศษเมื่อย้ายรุ่น

ตัวอย่างที่คู่มือระบุคือ is_in() ซึ่งตรวจว่าค่าอยู่ในชุดที่กำหนดหรือไม่ จะไม่ยอมแปลงชนิดข้อมูลแบบสูญเสียความแม่นยำโดยเงียบ ๆ อีกต่อไป ส่วนการวางตารางต่อกันแนวนอนด้วย how="horizontal" ต้องมีจำนวนแถวเท่ากัน มิฉะนั้นจะเกิดข้อผิดพลาด ตามคู่มืออัปเกรด การหยุดให้ตรวจอาจเพิ่มงานช่วงย้ายรุ่น แต่ช่วยให้เห็นเงื่อนไขที่เคยถูกปล่อยผ่าน

Map คือชนิดข้อมูลที่เก็บชื่อคู่กับค่า เช่นชื่อวิชาคู่กับคะแนน และมีคำสั่งค้นค่าด้วยชื่อ ตามประกาศ Polars อย่างไรก็ตาม คู่มือเตือนว่าคอลัมน์ Map ที่อ่านจากรูปแบบข้อมูลที่รองรับจะเปลี่ยนจากรายการคู่ชื่อกับค่ามาเป็น Map จริง โค้ดที่จัดการรูปแบบเก่าอาจใช้ต่อไม่ได้ ตามรายละเอียด Map

ยังมีการเปลี่ยนที่อาจกระทบจำนวนรายการ explode() คือคำสั่งแยกรายการย่อยให้เป็นแถว โดยรายการว่างจะไม่สร้างแถวค่าว่างเหมือนเดิมตามคู่มือ Polars ดังนั้นเวลาทดสอบ ผมแนะนำให้เทียบจำนวนแถวและรายการที่หายไปด้วย ไม่ดูเฉพาะยอดรวมท้ายตาราง

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

เสียงสนับสนุนมาจาก Polars ผู้พัฒนาเอง ซึ่งรายงานว่าเครื่องมือของตนทำได้เร็วกว่าคู่แข่งในเกือบทุกชุดทดสอบที่นำเสนอ โดยเทียบกับ DuckDB และ DataFusion ซึ่งเป็นเครื่องมือประมวลผลข้อมูลอีกสองตัวในประกาศรุ่นจริง นี่คือ benchmark หรือการวัดความเร็วด้วยงานทดสอบของ Polars ไม่ใช่ผลยืนยันจากการทดลองของบทความนี้

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

เสียงเตือนมาจาก Real Python โดย Bartosz Zaczyński ซึ่งเน้นว่าโค้ดที่พึ่งลำดับเดิมอาจมีปัญหา และแนะนำทดสอบในพื้นที่แยกก่อนเปลี่ยนระบบจริงในข่าวเดือนตุลาคม นี่เป็นข้อทักท้วงเรื่องความพร้อมของงานเดิม ไม่ใช่คำกล่าวว่า Polars ไม่มีประโยชน์ และชุดแหล่งข้อมูลนี้ไม่มีคำตอบโต้ผล benchmark จากทีม DuckDB หรือ DataFusion

ส่วนสถานะรุ่นต่างกันตามเวลาของข่าว Real Python วันที่ 5 ตุลาคมยังพูดถึง release candidate หรือรุ่นทดสอบก่อนออกจริง แต่ประกาศ Polars วันถัดมาระบุว่าออกแล้ว จึงควรใช้ประกาศที่ใหม่กว่าเมื่ออธิบายสถานะปัจจุบัน ไม่ตีความว่าแหล่งข่าวขัดกันเรื่องการเปิดตัว

Real Python เขียนว่า Polars อ้างความเร็วราว 5 เท่าจาก streaming engine แปลว่าเป็นคำกล่าวอ้างของผู้พัฒนาที่สื่อสรุปต่อ ไม่ใช่คำรับรองว่ารายงานคุณจะเร็วขึ้นตามตัวเลขนี้ ส่วนประกาศก่อนรุ่นจริง พูดกว้างๆ ว่าจะได้ประสิทธิภาพและหน่วยความจำดีขึ้นมากในงานส่วนใหญ่ ส่วนประกาศรุ่นจริงให้ดูผลทดสอบพร้อมเงื่อนไขแทนการรับรองงานทุกชนิด

เรื่องเอกสารก็มีจุดที่ควรระวังครับ ตอนต้นคู่มือย้ายรุ่น บอกว่า show_graph() ไม่ได้รับผลเหมือน collect() แต่หัวข้อถัดมาระบุว่าค่าเริ่มต้นแสดงแผนแบบ physical หรือขั้นตอนประมวลผลจริง และอาจแสดงแผน streaming ข้อความส่วนนี้จึงยังอ่านไม่สอดคล้องกันนัก หากใช้ภาพแผนงานตรวจระบบ ควรทดสอบแยกจากผลตาราง

สิ่งที่ยังไม่รู้คือรายงานของแต่ละทีมจะเร็วขึ้นแค่ไหน และเมื่อไรระบบพักข้อมูลลงดิสก์จะรองรับการจับคู่กับรวมกลุ่มครบ Polars ระบุเพียงแผนพัฒนาต่อ ยังไม่ให้วันแน่นอน ส่วนข้อมูลที่อ่านครั้งนี้ไม่มีหลักฐานหน้า PyPI สำหรับยืนยันวันที่อัปโหลด จึงไม่ใช้เป็นหลักฐานเพิ่มเติมครับ

แล้วเราควรทำอะไร

คนทำรายงาน บัญชี และงานปฏิบัติการ: ทำตามได้เลย

1. ตรึงเวอร์ชันที่ใช้อยู่ให้ชัดก่อนทดลอง หมายถึงระบุรุ่นของเครื่องมือในรายการที่โปรเจกต์ต้องใช้ พร้อมเก็บไฟล์รายงานเดิมไว้เทียบ วิธีนี้เป็นข้อเสนอเพื่อแยกผลจากการย้ายรุ่น โดยอิงคำแนะนำทดสอบแยกของ Real Python
2. รันชุดตรวจสอบกับสำเนาข้อมูลก่อน เทียบยอดรวม จำนวนแถว ชื่อคอลัมน์ และลำดับรายการ โดยคู่มือมีทั้งพฤติกรรมที่แจ้งข้อผิดพลาดและที่เปลี่ยนผลเงียบ ๆ ตามรายการ breaking changes หรือการเปลี่ยนที่ทำให้โค้ดเดิมทำงานต่างไป
3. เพิ่มการเรียงแบบชัดเจนก่อนส่งออก Excel หรือ CSV ซึ่งเป็นไฟล์ตารางข้อความ ระบุว่าจะเรียงตามวันที่ สาขา หรือลูกค้าให้ตรงความต้องการ คู่มือแนะนำ explicit sort หรือการสั่งเรียงโดยตรงเมื่อโค้ดพึ่งลำดับแถวในแนวทางย้ายรุ่น
4. ให้คนรับรายงานเปิดไฟล์ทดลองและตรวจงานที่ทำต่อจริง เช่นการเทียบกับเดือนก่อน ขั้นตอนนี้เป็นข้อเสนอให้ตรวจทั้งข้อมูลและวิธีใช้งาน ก่อนสลับรุ่นที่ใช้ผลิตรายงานประจำ

ทีม IT และนักพัฒนา: ตรวจจุดเปลี่ยนก่อนปล่อยใช้

1. อ่านคู่มืออัปเกรดฉบับเต็ม แล้วค้นจุด collect() การรวมกลุ่ม การจับคู่ และการแปลงคอลัมน์เป็นแถว ในจุดรวมกลุ่มที่ต้องรักษาลำดับ ใช้ maintain_order=True ตามตัวอย่างของ Real Python ส่วนการจับคู่ที่ต้องตามฝั่งซ้าย ใช้ maintain_order="left" ตามคู่มือ
2. หากต้องการทดลองกลับไปใช้เครื่องประมวลผลเดิม คู่มือให้ใช้ pl.Config.set_engine_affinity("in-memory") สำหรับทั้งโปรแกรม หรือ collect(engine="in-memory") สำหรับงานนั้นโดยเฉพาะ อีกทางคือค่าตั้งสภาพแวดล้อม POLARS_ENGINE_AFFINITY=in-memory ตามเอกสารทางการ แต่ยังต้องตรวจการเปลี่ยนอื่นด้วย
3. แก้ melt() ที่ถูกถอดออกเป็น unpivot() และเปลี่ยนชื่อส่วนกำหนดคอลัมน์จาก id_vars เป็น index กับ value_vars เป็น on ตามตารางคำสั่งที่ถอดออก หากพบ join_nulls ให้ตรวจการเปลี่ยนเป็น nulls_equal จากคู่มือเดียวกัน
4. ตรวจการอ่านข้อความเป็นวันที่ เพราะการแปลงตรงด้วย cast ไม่รองรับแล้ว ให้ดู str.to_date() หรือ str.to_datetime() ตามชนิดที่ต้องการในคู่มือย้ายรุ่น และตรวจข้อผิดพลาดชนิดข้อมูลด้วย collect_schema() ซึ่งตรวจโครงสร้างได้ก่อนคำนวณข้อมูลจริง แต่จับข้อผิดพลาดที่ขึ้นกับค่าข้อมูลไม่ได้ทั้งหมดตามประกาศ Polars

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

ผมมองว่า…

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

ผมมองว่า ทีมเล็กควรเริ่มจากรายงานที่มีเจ้าของและมีไฟล์เก่าให้เทียบ แล้วบันทึกสิ่งที่ต้องแก้ไว้ก่อนขยายไปงานอื่น หากตัวเลขความเร็วดูสวย แต่ยังตอบไม่ได้ว่าแถวแรกของไฟล์ควรเป็นอะไร เรามีงานออกแบบรายงานให้เสร็จก่อนครับ เครื่องเร็วขึ้นไม่ช่วยให้คนอนุมัติเดาใจเราได้

ปิดท้าย: สิ่งที่ต้องจับตา

ความพร้อมของรายงานวัดจากการส่งผลที่คนใช้ตรวจได้อย่างสม่ำเสมอ พอ ๆ กับเวลาที่เครื่องใช้คำนวณ สิ่งที่ควรจับตาคือการขยาย spill-to-disk ไปยัง join และ group_by รวมถึงการปรับประสิทธิภาพเมื่อใช้เครื่องที่มีหน่วยประมวลผลจำนวนมาก ซึ่งPolars ระบุว่าจะพัฒนาต่อ แต่ยังไม่มีวันที่แน่นอน

รายงานรายเดือนของคุณมีขั้นตอนไหนที่ต้องได้ลำดับแถวเหมือนเดิมก่อนส่งให้คนอนุมัติ?

Recap

• เกิดอะไรขึ้น: Polars รุ่นจริงออกแล้ว และงาน Lazy ใช้ streaming เป็นค่าเริ่มต้น ตามประกาศรุ่นจริง
• ตัวเลขที่จำ: รุ่น 2.0 แปลว่ามีการเปลี่ยนค่าเริ่มต้นและพฤติกรรมที่ต้องตรวจในคู่มืออัปเกรด
• เสียงเตือน: Polars เน้นประสิทธิภาพ ส่วน Real Python เน้นความเสี่ยงของโค้ดที่พึ่งลำดับเดิม ไม่มีเสียงค้าน benchmark จากคู่แข่งในชุดแหล่งนี้
• ยังไม่รู้: เวลาที่รายงานของคุณประหยัดได้ และวันรองรับการพักข้อมูลลงดิสก์สำหรับการจับคู่กับรวมกลุ่ม ตามขอบเขตในประกาศ Polars
• ผลต่อคนทำงาน: ขอให้ผู้รับระบุลำดับที่ต้องใช้ แล้วตรวจสำเนาก่อนเปลี่ยนไฟล์รายงานประจำ
• สิ่งที่ต้องทำ: ตรึงรุ่น ทดสอบสำเนา เรียงก่อนส่งออก และอ่านคู่มือคำสั่งที่เปลี่ยน
• แหล่งอ้างอิง: 1 ประกาศรุ่นจริง · 2 คู่มืออัปเกรด · 3 ประกาศก่อนรุ่นจริง · 4 Real Python