ไลบรารี DataFrame สำหรับ Python อย่าง Ibis เลิกใช้แบ็กเอนด์ Pandas และ Dask

 (ibis-project.org)
8 คะแนน โดย GN⁺ 2024-08-30 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • จะเลิกใช้แบ็กเอนด์ pandas และ dask และมีแผนลบออกในเวอร์ชัน 10.0
  • ไม่มีความต่างด้านฟังก์ชันระหว่างแบ็กเอนด์ pandas กับแบ็กเอนด์ DuckDB ที่เป็นค่าเริ่มต้น และ DuckDB มีประสิทธิภาพสูงกว่ามาก
  • ยังสามารถใช้ pandas DataFrame เป็นรูปแบบสำหรับรับส่งข้อมูลใน Ibis ได้ แต่จะไม่รองรับการรันคิวรีด้วย pandas
  • ตรรกะส่วนใหญ่ใช้ได้กับแบ็กเอนด์ dask เช่นกัน และ dask ก็ยังเป็นโปรเจ็กต์ที่ยอดเยี่ยมซึ่งควรใช้งานต่อไปนอก Ibis

ทำไมต้อง pandas? และประวัติของ Ibis

  • ในช่วงแรกของ Ibis มีเพียงแบ็กเอนด์ Impala เท่านั้น
  • มีการเพิ่มแบ็กเอนด์ Postgres เข้ามา แต่การติดตั้งซับซ้อน ทำให้ผู้ใช้ลองใช้ Ibis ได้ไม่สะดวก
  • จำเป็นต้องมีวิธีทดลองใช้ API ของ Ibis ได้โดยไม่ต้องมีโครงสร้างพื้นฐานเพิ่มเติมนอกเหนือจากโน้ตบุ๊ก
  • ในเวลานั้น การเชื่อมต่อแบ็กเอนด์ pandas ซึ่งเป็นเอนจิน DataFrame แบบ in-memory เพียงตัวเดียว คือคำตอบที่ชัดเจน

ความยากของแบ็กเอนด์ Pandas

  • แม้ pandas จะเป็นตัวเลือกที่ดีที่สุดในเวลานั้น แต่ก็ไม่สอดคล้องกับโมเดลการวิเคราะห์ข้อมูลของ Ibis มากนัก
  • แบ็กเอนด์ pandas แตกต่างจากแบ็กเอนด์อื่นโดยพื้นฐาน และมีโค้ดเฉพาะกรณีมากที่สุด
  • pandas โดยธรรมชาติเป็นเอนจินที่ทำงานแบบประมวลผลทันที ขณะที่ Ibis ใช้โมเดลการทำงานแบบหน่วงเวลา
  • การทำให้อินเทอร์เฟซของ pandas ทำงานในรูปแบบหน่วงเวลาเป็นเรื่องยาก
  • แบ็กเอนด์ pandas ช้ากว่าแบ็กเอนด์อื่น และต้องใช้โค้ดหลายพันบรรทัดเพื่อรองรับสิ่งนี้
  • NaN ของ pandas และ NULL ของ Ibis เป็นแนวคิดที่ต่างกันโดยพื้นฐาน แต่กลับต้องถูกปฏิบัติราวกับเป็นสิ่งเดียวกัน
    • ใน pandas มีการใช้ NaN เป็นตัวแทนของค่าที่หายไป แต่สิ่งนี้ทำให้เกิดปัญหาความเข้ากันได้กับแบ็กเอนด์อื่น
    • NULL หมายถึงค่าที่หายไป ส่วน NaN หมายถึงไม่ใช่ตัวเลข ซึ่งเป็นคนละแนวคิดกันโดยสิ้นเชิง
  • ไทป์ใหม่ของ pandas ที่อิงกับ Arrow เป็นการปรับปรุงครั้งใหญ่ แต่ก็ยังมีปัญหาอยู่

สร้างความสับสนให้ผู้ใช้ใหม่

  • ผู้คนมักชอบสิ่งที่คุ้นเคย
  • เมื่อเริ่มใช้ Ibis ครั้งแรก ผู้ใช้ต้องเลือกทั้ง Ibis และแบ็กเอนด์พร้อมกัน
  • ผู้ใช้ใหม่มักรายงานว่า "Ibis ช้า"
  • สาเหตุส่วนใหญ่มาจากการใช้แบ็กเอนด์ pandas
  • หากใช้ DuckDB หรือ Polars ก็น่าจะเริ่มต้นได้ง่ายกว่ามาก

ความเท่าเทียมด้านความสามารถ

  • เหตุผลที่หนักแน่นที่สุดในการถอดแบ็กเอนด์ pandas ออกคือความซ้ำซ้อน
  • แบ็กเอนด์ DuckDB สามารถคิวรี pandas DataFrame ได้อย่างราบรื่น รองรับ UDF ได้หลายรูปแบบ และอ่านเขียนฟอร์แมตได้หลากหลาย เช่น parquet, CSV, JSON
  • DuckDB ติดตั้งง่าย รันได้ในเครื่อง локอล เร็วมาก และทำงานร่วมกับระบบนิเวศ Python ได้ดี

สรุปโดย GN⁺

  • การเลือก DuckDB เป็นแบ็กเอนด์เริ่มต้นดูเป็นการตัดสินใจที่ชาญฉลาดมาก เพราะติดตั้งง่าย รันในเครื่องได้ เร็วมาก และทำงานร่วมกับระบบนิเวศ Python ได้ดี ซึ่งนี่ก็เป็นเหตุผลเดียวกับที่ Ibis เคยเพิ่ม pandas เป็นแบ็กเอนด์ในตอนแรก
  • การที่ pandas ยังสามารถใช้เป็นฟอร์แมตสำหรับรับส่งข้อมูลได้ ถือเป็นข่าวดีสำหรับผู้ใช้ pandas เดิม เพราะไม่จำเป็นต้องทิ้งโค้ดเดิมทั้งหมด
  • อย่างไรก็ตาม การไม่ใช้ pandas สำหรับรันคิวรีอีกต่อไปดูเป็นทิศทางที่ถูกต้อง โมเดลการทำงานแบบ eager ของ pandas ไม่สอดคล้องกับโมเดลแบบ lazy ของ Ibis ทำให้แบ็กเอนด์ pandas มักช้ากว่าการใช้ pandas โดยตรงเสียอีก
  • เมื่อ Ibis รองรับแบ็กเอนด์มากขึ้นเรื่อย ๆ การดูแลรักษาโค้ดที่ปรับให้เข้ากับแบ็กเอนด์เฉพาะก็จะยิ่งยากขึ้น การถอดแบ็กเอนด์ pandas ออกจะช่วยให้โค้ดเบสสะอาดขึ้นและดูแลรักษาง่ายขึ้น
  • หากการใช้แบ็กเอนด์ DuckDB สามารถทดแทนความสามารถทั้งหมดของ pandas ได้ ก็แทบไม่เห็นเหตุผลที่จะต้องคงแบ็กเอนด์ pandas ไว้ แถมยังอาจสร้างความสับสนให้ผู้ใช้ใหม่ได้อีกด้วย

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

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

 
yangeok 2024-09-03

ความจริงก็คือหลายคนยังคงใช้ pandas ที่คุ้นเคยที่สุดอยู่เยอะเหมือนเดิมครับ,,
 
GN⁺ 2024-08-30
ความคิดเห็นจาก Hacker News

  • NaN เป็นผลลัพธ์ของ 0/0 ซึ่งหมายความว่ามีค่าอยู่ แต่ไม่สามารถทราบค่าได้อย่างแม่นยำ

    • NULL หมายความว่าไม่สามารถทราบค่าที่ตำแหน่งหนึ่ง ๆ ได้
    • แม้การอิมพลีเมนต์ NaN กับ NULL จะแตกต่างกัน แต่ก็ไม่ได้ไม่เกี่ยวข้องกันเลย
    • None ของ Python แตกต่างจากทั้ง NaN และ NULL

  • มีเอนจินประมวลผลที่ดีกว่า pandas อยู่มาก

    • ยังคงใช้ pandas ต่อไปเพราะโค้ดเบสเดิมและการเชื่อมต่อกับ third-party
    • สำหรับงานข้อมูลขนาดเล็ก pandas ก็เหมาะสมเพียงพอ

  • ในช่วงไม่กี่เดือนที่ผ่านมา ได้แทนที่ pandas ด้วย ibis ในโปรเจ็กต์ใหม่

    • ไวยากรณ์ของ ibis ยืดหยุ่นกว่า pandas
    • การเชนการทำงานทำให้โค้ดสไนเป็ตพกพาไปใช้ต่อได้ง่ายขึ้น
    • แบ็กเอนด์ DuckDB เร็วมาก
    • ชุมชนมีความกระตือรือร้นและเป็นมิตรมาก
    • กำลังแนะนำ ibis ให้เพื่อนร่วมงานอยู่

  • ฟีเจอร์ multi-index ของ pandas ทรงพลังที่สุด

    • ใช้กับคอลัมน์ได้ด้วย
    • ไม่แน่ใจว่าเครื่องมือใหม่ ๆ จะจัดการฟีเจอร์นี้อย่างไร

  • สงสัยว่าเคยพิจารณา Polars หรือไม่

    • ในกลุ่มใช้งาน Polars เป็นมาตรฐาน เพราะไม่ชอบ pandas

  • pandas สามารถขยายไปยังคอลัมน์ชนิดใหม่ได้

    • ไม่แน่ใจว่า Polars รองรับสิ่งนี้หรือไม่

  • คุณค่าของ Ibis ไม่ได้อยู่ที่การใช้ DuckDB ได้

    • ต่อให้มีเครื่องมือใหม่ออกมา ไวยากรณ์ก็ยังใช้ต่อได้

  • ไม่ค่อยเคยได้ยินเกี่ยวกับ Ibis มากนัก

    • ถ้าจะเลิกใช้ pandas ก็ยิ่งมีโอกาสน้อยที่จะลอง Ibis
    • แม้เฟรมเวิร์กใหม่ ๆ จะกำลังออกห่างจาก pandas/numpy แต่จะรอจนกว่าปัญหาเรื่องความเข้ากันได้และ edge case จะถูกแก้ก่อน
    • รอเพิ่มอีกไม่กี่มิลลิวินาทีก็ไม่เป็นไร

  • API ของไลบรารี pandas ไม่ได้ใช้งานได้อย่างเป็นธรรมชาติเสมอไป

    • มีปัญหาเรื่อง NaN/None อยู่บ้าง แต่เป็นความไม่สะดวกเล็กน้อย

  • เหตุผลที่ใช้ pandas คืออีโคซิสเต็มที่เชื่อมต่อกันครบ

    • เวลาจะอ่านข้อมูลจากไฟล์ json, ไฟล์ csv, Python dict ฯลฯ แล้วนำไปทำ visualization ด้วย plotly, pandas สะดวกมาก
    • ถ้า Ibis ใช้ร่วมกับ pandas dataframe ได้ ก็ไม่ได้ใส่ใจเรื่องแบ็กเอนด์มากนัก