Polars

 (pola.rs)
4 คะแนน โดย GN⁺ 2024-01-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็น ไลบรารี DataFrame แบบโอเพนซอร์ส ที่มุ่งสำหรับสภาพแวดล้อมที่ต้องการประมวลผลข้อมูลอย่างรวดเร็วบนเครื่องเดียว โดยมียอดดาวน์โหลดมากกว่า 575 ล้านครั้งและ GitHub Star มากกว่า 38,000
  • หัวใจของประสิทธิภาพอยู่ที่ เอนจินคิวรีแบบมัลติเธรด ที่พัฒนาด้วย Rust รวมถึงการประมวลผลแบบคอลัมน์, vectorization, SIMD และการรันแบบขนาน
  • ยังคงให้บริการเป็นไลบรารีโอเพนซอร์สภายใต้ไลเซนส์ MIT และมี Polars Cloud ที่ใช้ API เดียวกันเพื่อขยายไปถึงเวิร์กโหลดโปรดักชัน
  • ชูประสิทธิภาพที่เร็วกว่า pandas มากกว่า 30 เท่า โดยเบนช์มาร์ก TPC-H แบบดัดแปลงรันบน c3-highmem-22 ด้วย scale factor 10 และรวม I/O
  • รองรับ CSV, JSON, Parquet, Delta Lake, AVRO, Excel, Arrow, ฐานข้อมูลหลัก ๆ, S3 และ Azure Storage จึงเชื่อมเข้ากับสแตกข้อมูลเดิมได้ง่าย

รูปแบบการให้บริการของ Polars

  • Polars เป็นไลบรารีโอเพนซอร์สสำหรับจัดการข้อมูล และวางตำแหน่งเป็นหนึ่งในโซลูชันประมวลผลข้อมูลที่เร็วที่สุดบนเครื่องเดียว
  • มี API ที่มีโครงสร้างและมีชนิดข้อมูล โดยมุ่งให้ทั้ง expressive และใช้งานง่าย
  • ตัวชี้วัดสาธารณะในปัจจุบันมีดังนี้
    • ดาวน์โหลด 575M+ ครั้ง
    • GitHub Star 38k+
  • เอกสารเริ่มต้นดูได้ที่ Get started

  • Polars โอเพนซอร์ส

    • Polars เป็นไลบรารีโอเพนซอร์สที่ใช้งานได้ฟรีภายใต้ไลเซนส์ MIT
    • ให้บริการเป็นไลบรารี DataFrame ประสิทธิภาพสูง และวิธีติดตั้งก็เรียบง่าย
    • ตัวอย่างการติดตั้งมีดังนี้
      • Python: pip install polars
      • Rust: polars = { version = "x", features = ["lazy", ...]}
      • Node.js: const pl = require('nodejs-polars');

  • Polars Cloud

    • Polars Cloud เป็นโซลูชันแบบ managed สำหรับขยายคิวรี Polars จากสภาพแวดล้อมโน้ตบุ๊กไปเป็นเวิร์กโหลดโปรดักชันบนคลาวด์หรือ on-premises
    • สามารถขยายได้ด้วย API เดียวกันโดยไม่ต้องเปลี่ยนโค้ด
    • รองรับการดีพลอยแบบ Cloud หรือ On-Prem
    • คิดค่าบริการเฉพาะการรันคิวรีเท่านั้น
    • ทดลองใช้งานได้ที่ Polars Cloud

โมเดลประสิทธิภาพและการผสานรวมข้อมูล

  • ฐานประสิทธิภาพของ Polars คือ เอนจินคิวรีแบบมัลติเธรดที่พัฒนาด้วย Rust และการออกแบบเพื่อประมวลผลแบบขนาน
  • การทำ vectorization และการประมวลผลแบบคอลัมน์ช่วยให้ใช้อัลกอริทึมที่มี cache coherence และประสิทธิภาพสูงบนโปรเซสเซอร์สมัยใหม่ได้
  • ถูกนำไปเปรียบเทียบกับหลายโซลูชันใน เบนช์มาร์ก TPC-H อิสระแบบดัดแปลง โดยมีเป้าหมายเพื่อจำลองงานจัดระเบียบข้อมูลในภาคปฏิบัติ
    • เมื่อเทียบกับ pandas สามารถทำประสิทธิภาพได้สูงกว่ามากกว่า 30 เท่า
    • เบนช์มาร์กรันบน c3-highmem-22 ด้วย scale factor 10 และรวม I/O
    • คิวรีเผยแพร่เป็น open source
    • ดูรายละเอียดเพิ่มเติมได้ที่ Learn more

  • ความสะดวกในการใช้งานและการปรับแต่งการรัน

    • ผู้ใช้เขียนคิวรีตามที่ตั้งใจไว้ และ query optimizer ของ Polars จะกำหนดวิธีรันที่มีประสิทธิภาพ
    • แบ่งงานไปยัง CPU core ที่พร้อมใช้งานและรันแบบขนานโดยไม่ต้องตั้งค่าเพิ่มเติมหรือมี overhead จาก serialization
    • ใช้โมเดลหน่วยความจำของ Apache Arrow เพื่อผสานรวมกับเครื่องมือข้อมูลที่มีอยู่ได้
    • การแชร์ข้อมูลแบบ zero-copy ช่วยลดต้นทุนการทำงานร่วมกันระหว่างเครื่องมือ
    • ออกแบบให้ใกล้กับเครื่องโดยไม่ต้องพึ่งพาภายนอก เพื่อให้ควบคุม API, หน่วยความจำ และการรันได้
    • ชุดข้อมูลที่ใหญ่กว่าหน่วยความจำสามารถประมวลผลด้วย streaming API โดยไม่จำเป็นต้องโหลดข้อมูลทั้งหมดขึ้นหน่วยความจำ

  • รูปแบบข้อมูลที่รองรับ

    • Polars รองรับการอ่านและเขียนรูปแบบข้อมูลทั่วไป จึงผสานรวมกับสแตกข้อมูลเดิมได้
    • ขอบเขตที่รองรับมีดังนี้
      • Text: CSV, JSON
      • Binary: Parquet, Delta Lake, AVRO, Excel
      • IPC: Feather, Arrow
      • Databases: MySQL, Postgres, SQL Server, Sqlite, Redshift, Oracle
      • Cloud storage: S3, Azure Blob, Azure File

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-01-09
ความคิดเห็นจาก Hacker News

  • เห็นชัดมากว่าหน้านี้เขียนมาสำหรับคนที่รู้อยู่แล้วว่ากำลังดูอะไรอยู่ ตั้งแต่ประโยคแรกก็ไม่ได้อธิบายเครื่องมือ แต่เริ่มด้วยเรื่องคุณภาพอย่าง “Polars is written from the ground up with performance in mind” แล้วส่วนที่เหลือก็เป็นแนวเดียวกัน
    ใครช่วยอธิบายแบบ เหมือนอธิบายให้เด็ก 5 ขวบฟัง ได้ไหมว่านี่คืออะไร และเหมาะเป็นโซลูชันสำหรับความต้องการแบบไหน?
    แก้ไข: สุดท้ายเข้าใจว่าเป็น การใช้งานทดแทน Pandas DataFrame จากคำอธิบายที่เจอใน Google ที่ https://realpython.com/pandas-dataframe/ ระบุว่า DataFrame คือโครงสร้างที่เก็บข้อมูลสองมิติพร้อม label ใช้กันอย่างแพร่หลายในงานที่เน้นข้อมูล เช่น data science, machine learning และ scientific computing และคล้ายกับตาราง SQL หรือสเปรดชีต Excel/Calc

    • นี่แหละคือข้อเสียที่น่าหงุดหงิดของผลิตภัณฑ์เทคโนโลยีจำนวนมาก เป็นเรื่องธรรมชาติที่อยากพูดกับกลุ่มผู้อ่านเป้าหมาย ซึ่งในกรณีนี้คือ data scientist ที่ชอบ Pandas แต่รู้สึกว่ามันช้าและไม่ยืดหยุ่นพอ แต่สำหรับมือใหม่แล้วมันให้ความรู้สึกเหมือนถูกกันออกไป
      ผมเป็นกลุ่มผู้อ่านเป้าหมายของ Polars และตั้งใจจะลองใช้มาหลายเดือนแล้ว แต่ก็ผลัดไปเรื่อย ๆ ยังมีความภักดีต่อ Pandas อยู่ เพราะ Wes McKinney ผู้สร้าง Pandas เขียนหนังสือที่มีประโยชน์สำหรับอธิบายเครื่องมือวิเคราะห์ที่ใช้กันทั่วไปไว้ที่ https://wesmckinney.com/book/
    • มันคือ Pandas แต่เร็วกว่า Pandas เป็นไลบรารี dataframe แบบโอเพนซอร์สต้นตำรับ แข็งแรงและใช้กันแพร่หลาย แต่ดูเหมือนจะมีขอบเขตกว้างและช้ากว่าผู้เล่นหน้าใหม่นี้ คำว่า “dataframe” เป็นสัญญาณที่คนที่เคยใช้มาก่อนจะเข้าใจทันที
    • ทุกครั้งที่เห็นหน้าแบบนี้จะรู้สึกถ่อมตัวขึ้นมาเลย “DataFrame สำหรับยุคใหม่” งั้นเหรอ ทำให้สงสัยว่าตัวเองรู้จัก dataframe จริงไหม แล้วพอเห็น “multi-threaded query engine” ก็สงสัยว่ามันเป็นอะไรคล้าย database หรือเปล่า
      มีกราฟเปรียบเทียบกับสิ่งที่ชื่อ pandas, modin, vaex แต่ผมก็ไม่รู้จักพวกนั้นเลย สุดท้ายก็รู้สึกว่านี่ไม่ใช่ของสำหรับผม ผมชอบอ่านและเรียนรู้เทคโนโลยีหรือโปรเจกต์ใหม่ ๆ แต่ตรงนี้ไม่มีอะไรให้ผมเกาะเกี่ยวได้เลย
      เวลาผมพูดเรื่อง web development เล็ก ๆ น้อย ๆ กับคนทั่วไป เขาคงรู้สึกแบบนี้แหละ
    • ถ้าพูดอย่างเป็นธรรม ชื่อหน้าคือ “Dataframes for the new Era” และลิงก์ Get Started ใต้ชื่อก็ชี้ไปยังเอกสารบนหน้า GitHub ส่วน GitHub อธิบายว่าไลบรารีนี้คืออะไรให้คนที่มีพื้นฐานด้านการวิเคราะห์ข้อมูลเข้าใจ: https://github.com/pola-rs/polars
    • ตอนนี้ผมกำลังถูกดึงเข้าไปทำงานสาย “data” และที่นี่เหมือนจักรวาลคู่ขนานที่มีพื้นเพและวัฒนธรรมของตัวเอง มีสำนวนทำนอง “เชื่อมต่อกับอินสแตนซ์ Antelope หรือ Meringue ด้วยความใช้งานง่ายของ Nincompoop และประสิทธิภาพของ ARSE2” เต็มไปหมด
      สิ่งที่น่าสนใจใน Polars คือมันคล้าย Pandas แต่ใช้ Arrow ซึ่งเป็นแบ็กเอนด์ Rust ที่มีประสิทธิภาพกว่า และมีสิ่งอย่าง query planner ที่ทำให้การประกอบ operation ต่าง ๆ มีประสิทธิภาพขึ้น โดยทั่วไป Polars มีประสิทธิภาพกว่า Pandas มาก จนงานที่เมื่อก่อนต้องใช้โครงสร้างพื้นฐานซับซ้อนก็มักทำได้บนเครื่องเดียว
      เป็นการแข่งขันที่เป็นมิตรมากจากนักพัฒนาหลักของ Pandas และดูเหมือนทุกคนจะชอบกันหมด และเมื่อเวลาผ่านไปก็มีแนวโน้มสูงที่จะมาแทน Pandas

  • บทความที่เกี่ยวข้อง:
    Detailed Comparison Between Polars, DuckDB, Pandas, Modin, Ponder, Fugue, Daft - https://news.ycombinator.com/item?id=37087279 - สิงหาคม 2023
    Polars: Company Formation Announcement - https://news.ycombinator.com/item?id=36984611 - สิงหาคม 2023
    Replacing Pandas with Polars - https://news.ycombinator.com/item?id=34452526 - มกราคม 2023
    Fast DataFrames for Ruby - https://news.ycombinator.com/item?id=34423221 - มกราคม 2023
    Modern Polars: A comparison of the Polars and Pandas dataframe libraries - https://news.ycombinator.com/item?id=34275818 - มกราคม 2023
    Rust polars 0.26 is released - https://news.ycombinator.com/item?id=34092566 - ธันวาคม 2022
    Polars: Fast DataFrame library for Rust and Python - https://news.ycombinator.com/item?id=29584698 - ธันวาคม 2021
    Polars: Rust DataFrames Based on Apache Arrow - https://news.ycombinator.com/item?id=23768227 - กรกฎาคม 2020

  • ใช้ Pandas มาหลายปี แต่รู้สึกเหมือนต้องกลิ้งลูกบอลขึ้นเนินอยู่ตลอด แม้แต่งานง่าย ๆ อย่าง join ก็เป็นแบบนั้น และต้องไม่ลืมรีเซ็ต index ด้วย
    Polars ให้ความรู้สึกว่าดีกว่า Pandas แทบทุกด้าน เร็วกว่า ใช้ หลายคอร์ กินหน่วยความจำน้อยกว่า และ API เข้าใจเป็นธรรมชาติกว่า แม้ยังเป็นไลบรารีที่ค่อนข้างใหม่จึงมีข้อเสียอยู่บ้าง แต่ถ้าเป็นโปรเจกต์ใหม่ อย่างน้อยก็คุ้มค่าที่จะพิจารณา
    การใช้ประโยชน์จากระบบนิเวศ Rust ได้ง่ายก็ยอดเยี่ยมมาก ผมเขียนปลั๊กอินเองเพื่อทำให้ฟังก์ชันรันขนานกัน และทำให้โค้ดภูมิสารสนเทศบางส่วนเร็วขึ้น 100 เท่า

    • ที่ยก join มาเป็นตัวอย่างนี่ออกจะย้อนแย้งนิดหน่อย ผมคิดเสมอว่าปัญหาใหญ่ที่สุดของ Pandas คือเอกสารประกอบ เช่น รู้ไหมว่ามีวิธี join dataframe โดยไม่ใช้ index อยู่ด้วย? ชื่อมันไม่ใช่ “join” แต่เป็น merge
      ในช่วงแรก Pandas ได้รับอิทธิพลอย่างมากจากคำศัพท์และรูปแบบการใช้งานของ R และใน R คำว่า “merge” เป็นคำที่ใช้กันทั่วไปอยู่แล้วในความหมายของ “join” ถ้าตอนเริ่มเรียน Pandas ราวปี 2015 ไม่ได้รู้ R มาก่อน ก็คงยากที่จะเรียนรู้ได้เร็ว
    • อยากรู้ว่ามอง PRQL(prql-lang.org) อย่างไร ส่วนตัวผมมองว่ามันผสานพลังและความเป็นสากลของ SQL เข้ากับความรู้สึกในการใช้งานและประสบการณ์นักพัฒนาของ Polars หรือ Pandas
      คิวรีสามารถรันได้ไม่ใช่แค่บน Polars และ Pandas แต่รวมถึงเอนจินรัน SQL-compatible ที่ต้องการ เช่น DuckDB, ClickHouse, BigQuery, Redshift, Postgres, Trino/Presto, SQLite เป็นต้น
      ไวยากรณ์และความหมายของ join เป็นหนึ่งในส่วนที่ยากที่สุด จึงมีการกลับมาถกกันอีกครั้งเมื่อไม่นานนี้ มันเป็นแกนหลักของพีชคณิตเชิงสัมพันธ์ และก็สอดคล้องกับตัว R ใน PRQL ด้วย การแปลงพื้นฐานส่วนใหญ่ของ PRQL เป็นการจัดการลิสต์แบบง่าย ๆ เช่น map, filter, reduce แต่ join ต้องระวังเพื่อคงการประกอบแบบ monad ไว้ ผมทิ้งความคิดไว้ที่นี่: https://github.com/PRQL/prql/issues/3782#issuecomment-1811312787
      อิชชูนั้นปิดไปแล้ว แต่ถ้าเปิดอิชชูใหม่หรือแท็ก @snth เพื่อแสดงความคิดเห็นก็ยินดี อนึ่ง ผมเป็นผู้มีส่วนร่วมกับ PRQL
    • อยากรู้ว่าการ merge dataframe ใน Pandas ยากตรงไหน

  • ตอนลองประเมินดู ข้อดีที่ใหญ่ที่สุดคือ API สม่ำเสมอและเข้าใจง่ายกว่า Pandas มาก แน่นอนว่าส่วนหนึ่งก็เป็นเพราะได้เรียนรู้จาก Pandas ตลอด 20 เวอร์ชันหลักมาแล้ว
    แต่เพราะมีคนใช้น้อยกว่ามาก Copilot เลยเขียนโค้ด Polars ได้ไม่ค่อยดี ดังนั้นตอนนี้จึงยังใช้ Pandas กับ Copilot ต่อไป นี่เป็นครั้งแรกที่รู้สึกว่ามีอุปสรรคแบบนี้กับไลบรารีใหม่ ๆ โดยทั่วไป

    • นี่เป็นครั้งแรกที่เห็นคนพูดต่อสาธารณะว่าชอบไลบรารีหนึ่งเพราะ Copilot รองรับ ไม่ได้จะตัดสินนะ แค่รู้สึกน่าสนใจ
      แต่ Copilot เรียนรู้จากในรีโปได้เร็วมาก ผมใช้สแตกที่คัสตอมสุด ๆ ซึ่งสร้างด้วย TS-Plus ซึ่งเป็น fork ของ TypeScript ที่แม้แต่ผู้เขียนเองก็ไม่ได้ใช้หรือแนะนำ แต่ Copilot ก็ยังสร้างโค้ด TS-Plus ที่ค่อนข้างดีออกมาได้
      หลังจากเห็นตัวอย่างไม่กี่อย่างแล้ว ไม่ควรประเมินต่ำไปว่าในขั้นตอนโค้ดซ้ำ ๆ Copilot สามารถเก่งขึ้นได้พอสมควร
    • การรองรับ Copilot เป็น ปัญหาไก่กับไข่ มันต้องเรียนรู้จากโค้ดของคนอื่น แต่ถ้าผู้คนไม่เขียนโค้ด Polars โดยไม่มี Copilot, Copilot ก็จะไม่เขียนโค้ด Polars ได้ดีขึ้น
    • ตอนใช้ danfo.js ซึ่งเป็นไลบรารี dataframe อีกตัวของ JS ก็คล้ายกัน Copilot แค่ มโน ฟีเจอร์กับชื่อเมธอดขึ้นมาเอง
      ไม่ใช่ปัญหาใหญ่เพราะอ่านเอกสารได้ แต่ก็น่ารำคาญที่ Copilot ไม่สามารถพ่นสิ่งที่ต้องการออกมาได้ทันที
    • ทั้งที่ยอมรับว่า API สม่ำเสมอและเข้าใจง่ายกว่า แต่จะอยู่กับ Pandas ต่อเพียงเพราะ Copilot ทำให้ง่ายกว่าอย่างนั้นหรือ? ทั้งสำหรับตัวเองและเพื่อ นวัตกรรมโอเพนซอร์ส ควรใช้เครื่องมือที่ยอมรับว่าดีกว่า
      ผมใช้ API ของ Pandas มานานและไม่ชอบมัน ผมค่อนข้างกระตือรือร้นในการปรับปรุงการเรียนรู้ เครื่องมือ วิธีคิด และทักษะอย่างต่อเนื่อง
    • ไลบรารี Polars เปลี่ยนแปลงเร็ว ผมไม่ได้ใช้ Copilot แต่ถ้าใส่ข้อมูลล่าสุดใน system instruction เช่น with_column เปลี่ยนเป็น with_columns แล้วเพิ่มเนื้อหาเอกสารเข้าไป ก็ได้ผลลัพธ์จาก ChatGPT ค่อนข้างดี

  • ตอน Deno เปิดตัวการรองรับ Jupyter, nodejs-polars เป็นหนึ่งในไลบรารีหลักด้านวิทยาศาสตร์ข้อมูลที่รองรับ
    https://blog.jupyter.org/bringing-modern-javascript-to-the-jupyter-notebook-fc998095081e
    ส่วนตัวผมไม่ใช่คนสายวิทยาศาสตร์ข้อมูล แต่เมื่อคิดว่าระบบนิเวศ JS/Jupyter ยังอยู่ในช่วงเริ่มต้น การเรียกใช้การวิเคราะห์บนพื้นฐาน pola.rs จาก TypeScript ได้เร็วขนาดนั้นน่าทึ่งมาก
    JS binding ยังมีจุดที่ต้องปรับปรุงแน่นอน แต่หวังว่าการเข้าถึงที่ดีขึ้นจะนำไปสู่การปรับปรุงซ้ำ ๆ

    • ผมอยากได้อะไรแบบ Pandas ใน JS มาตลอด เพิ่งรู้จักนี่แหละ

  • Polars น่าตื่นเต้นมากจริง ๆ และประสิทธิภาพด้านความเร็วก็น่าประทับใจ แต่การเอา vaex, modin, dask มาเปรียบเทียบในเบนช์มาร์กเดียวกันทั้งหมดนั้นรู้สึกขัดใจ
    ไลบรารีเหล่านี้ทั้งหมดมุ่งไปที่ การประมวลผลข้อมูลนอกคอร์ กล่าวคือใช้สำหรับกรณีที่ข้อมูลใหญ่เกินไปจนต้องคำนวณกระจายข้ามหลายเครื่อง การเทียบกับไลบรารี dataframe แบบเครื่องเดียวเป็นเรื่องแปลก และด้วย overhead ที่หลีกเลี่ยงไม่ได้ก็ย่อมช้ากว่าอยู่แล้ว
    ไม่ค่อยมีเหตุผลที่จะใช้ Polars ในบริบทเดียวกับไลบรารีเหล่านั้น แต่การแสดงในเบนช์มาร์กเหมือนเป็นระดับเดียวกันก็ดูตลกอยู่บ้าง ยิ่งไปกว่านั้น DuckDB ซึ่งใช้ได้ในบริบทเดียวกับ Polars และในหลายกรณีเร็วกว่า กลับไม่อยู่ในเบนช์มาร์ก
    วิศวกรรมซอฟต์แวร์ของ Polars เป็นงานที่ยอดเยี่ยม และไม่จำเป็นต้องมีเบนช์มาร์กที่อาจทำให้เข้าใจผิดแบบนี้

    • อย่างอื่นไม่รู้ แต่ Dask ใช้บนเครื่องเดียวได้ด้วย และนั่นก็เป็นวิธีที่ง่ายที่สุดในการใช้ Dask ด้วย มันแบ่ง dataframe เป็นพาร์ทิชันแล้วประมวลผลบนแต่ละคอร์เพื่อทำให้การคำนวณขนานกัน
      โดยไม่ต้องตั้งค่าอะไร ก็ทำให้ประสิทธิภาพดีกว่า Pandas ได้ 2 เท่า และในบาง operation ผมเคยเห็นถึง 5 เท่า
    • Ibis ซึ่งเป็น dataframe ของ Python ที่ผู้สร้าง Pandas ทำ ใช้ DuckDB เป็น backend เริ่มต้น และยกเว้นบางคิวรี มักชนะ Polars ในเบนช์มาร์กแบบนี้

  • ไม่ได้ใช้ Polars โดยตรง แต่ใช้เป็น รูปแบบ materialized ในเวิร์กโฟลว์ของ DuckDB
    duckdb.query(sql).pl() เร็วกว่า duckdb.query(sql).df() มาก สำหรับ Polars เป็นแบบ zero-copy จึงเสร็จทันที แต่ Pandas จะใช้เวลาค่อนข้างนานถ้า DataFrame มีขนาดใหญ่ และสามารถจัดการได้เหมือน Pandas DataFrame เพียงแต่ไวยากรณ์ต่างกันเล็กน้อย
    เหมาะมากสำหรับจัดการชุดข้อมูลขนาดใหญ่

  • น่าจะมีบทแทรกของกฎข้อที่ 10 ของ Greenspun(https://en.wikipedia.org/wiki/Greenspun's_tenth_rule)) ประมาณว่า ไลบรารีวิเคราะห์ข้อมูลที่ซับซ้อนเพียงพอจะลงเอยด้วยการอิมพลีเมนต์ครึ่งหนึ่งของ SQL ขึ้นมาแบบเฉพาะหน้า เป็นสเปกไม่เป็นทางการ มีบั๊กเยอะ และช้า
    ผมใช้ Pandas เป็นครั้งคราว และก็คงจะลองตัวนี้ด้วย แต่ก็มักคิดเสมอว่าน่าจะเริ่มจากการเอาข้อมูลที่กำลังทำงานอยู่ใส่ลงใน Postgres ไปเลยดีกว่า
    ถึงผมจะไม่ใช่ผู้เชี่ยวชาญฐานข้อมูล และถนัด Python มากกว่าเยอะ แต่สำหรับการเลือก เรียงลำดับ กรอง และ join ข้อมูลแบบตาราง SQL ทำได้ดีกว่ามาก

    • แนะนำให้ดู DuckDB กับส่วนขยาย duckdb-prql
      DuckDB ช่วยให้จัดการข้อมูลในรูปแบบ Polars, Pandas และ Arrow ได้โดยตรงด้วย SQL โดยไม่ต้องคัดลอกหรือทำข้อมูลซ้ำ
      duckdb-prql ช่วยให้ใช้ PRQL(prql-lang.org) ได้ และโดยส่วนตัวผมมองว่ามันผสานพลังและความแพร่หลายของ SQL เข้ากับความรู้สึกในการใช้งานและประสบการณ์นักพัฒนาของ Polars หรือ Pandas ขอเสริมว่าผมเป็นผู้ร่วมพัฒนา PRQL
    • ทำแบบนั้นก็ได้ แต่ถ้าเป็นคิวรีแบบ “วิเคราะห์” ประสิทธิภาพน่าจะแย่ลงมาก และความยืดหยุ่นกับพลังในการสื่อความก็อาจลดลงด้วย
      แนะนำให้ลองดู DuckDB แทน การอิมพลีเมนต์ SQL ของมันไม่ได้เป็นแบบเฉพาะหน้า และก็ไม่ได้เต็มไปด้วยบั๊ก ช้า หรือไม่สมบูรณ์ ส่วนเรื่องความเป็นทางการของสเปกผมไม่แน่ใจ แต่ เข้ากันได้กับ Polars
    • โดยส่วนตัว ไวยากรณ์ lazy dataframe เป็นฟรอนต์เอนด์ของ query engine ที่ดีกว่ามาก Polars ก็รองรับ SQL แต่บั๊กมักไม่ได้มาจากฟรอนต์เอนด์ แต่มาจาก query engine
      สำหรับคิวรีประเภทที่ทำกับเอนจินเหล่านี้ Postgres น่าจะช้ากว่า OLAP query engine หลายเท่าในระดับหลักเดียว
    • ผู้สร้าง Pandas ทำ Ibis ที่มีแบ็กเอนด์ Postgres ด้วยเหตุผลนี้: https://ibis-project.org/backends/postgresql
      เป็นแนวทางที่ดีกว่าสำหรับการใช้ Python dataframe ร่วมกับ SQL

  • เมื่อไม่กี่เดือนก่อน ผมพยายามย้ายโค้ดเบส Pandas ขนาดใหญ่ไปเป็น Polars ผมไม่ค่อยชอบทำงานวิเคราะห์หรือ data pipelining ใน Python อยู่แล้ว เพราะการแปลงข้อมูลที่ซับซ้อนใช้เวลานานกว่า Julia หรือ R(dataframes.jl, dplyr) ประมาณ 2~5 เท่า ใน Pandas
    น่าเสียดายที่ Polars ก็ไม่ใช่คำตอบเช่นกัน มีบั๊กมากเกินไปใน operation มาตรฐาน และการทำงานร่วมกับ Pandas ก็ไม่เสถียร นี่เป็นปัญหาเพราะไลบรารีจำนวนมากต้องการ Pandas DataFrame เป็นอินพุต API ก็ยืดยาวมากสำหรับไลบรารี dataframe สมัยใหม่ แต่ก็ยังดีกว่า Pandas
    หวังว่าเมื่อเวลาผ่านไปจะดีขึ้น แต่ตอนนี้การใช้ DuckDB บน Pandas เป็นทางเลือกที่ดีที่สุด เร็วพอ ๆ กับ Polars แต่เสถียรกว่าและทำงานร่วมกับอย่างอื่นได้ดีกว่า
    หวังว่าสักวันระบบนิเวศ dataframe ของ Python จะไปถึงจุดที่สามารถใช้ไลบรารี dataframe สำหรับงานวิเคราะห์ที่มี API ใช้ง่าย (dplyr) ร่วมกับไลบรารี dataframe ประสิทธิภาพสูง (data.table) ได้อย่างสะดวกเหมือน R

    • ผมเองก็หงุดหงิดกับความยืดยาวเหมือนกัน Pandas ก็ยืดยาวพอสมควรถ้าเทียบกับของอย่าง data.table แต่ Polars ให้ความรู้สึกเหมือน กำลังใช้ API มากกว่าจะเป็น “เครื่องมือจัดการข้อมูล”
      ผมคงไม่ใช้กับ exploratory data analysis หรืองานวิจัย แต่เริ่มใช้ในสคริปต์ production บางตัวเพราะประสิทธิภาพที่ดีกว่า
      ประสบการณ์จัดการข้อมูลที่ผมชอบที่สุดยังเป็นชุด R อย่าง dplyr + data.table อยู่ดี เพียงแต่ถ้า R มีอะไรแบบ Matplotlib ก็คงดี ggplot เป็นระดับสูงเกินไป ส่วนกราฟิกพื้นฐานก็ระดับต่ำเกินไป Scikit-Learn ก็เป็นโมดูลาร์กว่า Caret มาก เลยไม่ได้คิดถึง Caret เท่าไร
    • อยากรู้ว่ามอง PRQL(prql-lang.org) อย่างไร เป้าหมายคือให้ความรู้สึกแบบ dplyr ในทุกที่ที่ใช้ SQL ได้ และคอมไพล์เป็น SQL
      โดยส่วนตัวผมมองว่ามันผสานประสบการณ์นักพัฒนาของ dplyr, Polars, Pandas เข้ากับพลังและความแพร่หลายของ SQL คิวรีสามารถรันบนเอนจินที่เข้ากันได้กับ SQL ตามต้องการได้ ไม่ใช่แค่ Polars, Pandas แต่รวมถึง DuckDB, ClickHouse, BigQuery, Redshift, Postgres, Trino/Presto, SQLite เป็นต้น
      อยากฟังความคิดเห็นใน GitHub discussions(https://github.com/PRQL/prql/discussions) หรือ Discord(https://discord.com/invite/XWxbCrWr) ขอเสริมว่าผมเป็นผู้ร่วมพัฒนา PRQL
    • ดีจังที่มีประสบการณ์ใช้ dataframe ของทั้ง R, Python และ Julia อยากรู้ว่าชอบฝั่งไหนที่สุด แม้ระบบนิเวศจะเทียบกันตรง ๆ ไม่ได้ แต่ถ้าวัดจากงานอย่าง operation หลัก ๆ ตัวไหนดีที่สุด?
    • Ibis ที่ใช้แบ็กเอนด์ DuckDB ก็น่าลองเช่นกัน โดยส่วนตัวผมก็ชอบ Polars อยู่พอสมควร นักพัฒนาโดยรวมตอบสนองต่อ issue ค่อนข้างเร็วมาก

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

    • ผมคิดว่าการตัดสินนั้นถูกแล้ว ตอนนี้น่าจะเป็นช่วง ทดลองใช้ มากกว่าจะเป็นเวลามาแทนที่ Pandas ที่ทำงานได้ดีอยู่แล้ว
      API ยังมีการเปลี่ยนแปลงที่ทำให้โค้ดพังได้ในระดับที่คาดเดาได้ และถ้ากระจายอยู่หลายโปรเจกต์ก็อาจกลายเป็นภาระในการบำรุงรักษาได้ ถึงอย่างนั้น API ก็เริ่มให้ความรู้สึกสอดคล้องกันมากขึ้นแล้ว และโดยรวมดูเหมือนกำลังไปในทิศทางที่ถูกต้อง
    • ไม่ควรเขียนโค้ดทั้งหมดใหม่หมด แต่สำหรับโค้ดใหม่ก็คุ้มค่าที่จะนำมาใช้หรือประเมินดู
      โดยเฉพาะต้นทุนในการทำงานร่วมกับ Pandas นั้นต่ำมาก และถ้าใช้แบ็กเอนด์ Arrow ก็สามารถแปลงไปเป็น Pandas แบบ zero-copy ได้ค่อนข้างง่าย
    • ต่อไปก็มี https://github.com/fugue-project/fugue
    • สงสัยว่าทีมใช้ pandasql อยู่หรือเปล่า หรือหลัก ๆ ใช้ Pandas API โดยตรง