Thư viện DataFrame Python Ibis loại bỏ các backend Pandas và Dask

 (ibis-project.org)
8 điểm bởi GN⁺ 2024-08-30 | 2 bình luận | Chia sẻ qua WhatsApp
  • Sẽ ngừng hỗ trợ các backend pandas và dask, đồng thời loại bỏ chúng trong phiên bản 10.0
  • Không còn khác biệt về tính năng giữa backend pandas và backend DuckDB mặc định, trong khi DuckDB có hiệu năng vượt trội hơn nhiều
  • pandas DataFrame vẫn có thể được dùng trong Ibis như một định dạng để trao đổi dữ liệu, nhưng không còn hỗ trợ thực thi truy vấn bằng pandas
  • Phần lớn logic này cũng áp dụng cho backend dask; dask là một dự án tuyệt vời và vẫn nên tiếp tục được sử dụng bên ngoài Ibis

Vì sao là pandas? Và lịch sử của Ibis

  • Trong giai đoạn đầu của Ibis, chỉ có backend Impala
  • Sau đó backend Postgres được bổ sung, nhưng việc cài đặt phức tạp khiến người dùng khó có thể dễ dàng thử Ibis
  • Cần có một cách để thử API Ibis mà không cần thêm hạ tầng nào ngoài notebook
  • Khi đó, kết nối với backend pandas, engine DataFrame in-memory duy nhất vào thời điểm đó, là câu trả lời hiển nhiên

Những khó khăn của backend Pandas

  • pandas là lựa chọn tốt nhất vào thời điểm đó, nhưng không thực sự phù hợp với mô hình phân tích dữ liệu của Ibis
  • Backend pandas về bản chất khác với các backend khác nên chứa nhiều mã xử lý đặc biệt nhất
  • pandas về bản chất là engine thực thi tức thời, trong khi Ibis sử dụng mô hình thực thi trì hoãn
  • Việc khiến giao diện pandas hoạt động theo cách trì hoãn là rất khó
  • Backend pandas chậm hơn các backend khác và đòi hỏi hàng nghìn dòng mã để duy trì
  • NaN của pandas và NULL của Ibis là hai khái niệm khác nhau về bản chất, nhưng lại buộc phải được xử lý như thể chúng là một
    • Trong pandas, NaN được dùng làm ký hiệu cho giá trị thiếu, nhưng điều này gây ra vấn đề tương thích với các backend khác
    • NULL biểu thị giá trị thiếu, còn NaN biểu thị một giá trị không phải số; đây là hai khái niệm fundamentally khác nhau
  • Các kiểu dữ liệu mới dựa trên Arrow của pandas là một cải tiến lớn, nhưng vẫn còn vấn đề

Gây nhầm lẫn cho người dùng mới

  • Mọi người thường thích những gì quen thuộc
  • Khi lần đầu dùng Ibis, người dùng phải chọn cả Ibis lẫn backend
  • Người dùng mới thường báo rằng "Ibis chậm"
  • Phần lớn là vì họ đã dùng backend pandas
  • Nếu họ dùng DuckDB hoặc Polars, có lẽ việc bắt đầu đã dễ dàng hơn nhiều

Tương đương về tính năng

  • Lý do thuyết phục nhất để loại bỏ backend pandas là tính trùng lặp
  • Backend DuckDB có thể truy vấn liền mạch pandas DataFrame, hỗ trợ nhiều dạng UDF, và có thể đọc ghi nhiều định dạng như parquet, CSV, JSON
  • DuckDB dễ cài đặt, chạy cục bộ, rất nhanh và tương tác tốt với hệ sinh thái Python

Tổng kết của GN⁺

  • Việc chọn DuckDB làm backend mặc định có vẻ là một quyết định rất sáng suốt. Nó dễ cài đặt, chạy cục bộ, rất nhanh và tương tác tốt với hệ sinh thái Python. Đây cũng chính là lý do ban đầu Ibis thêm pandas làm backend
  • Việc pandas vẫn có thể được dùng như một định dạng trao đổi dữ liệu là tin tốt cho người dùng pandas hiện tại. Không cần phải vứt bỏ hoàn toàn mã nguồn hiện có
  • Tuy nhiên, việc không còn dùng pandas để thực thi truy vấn có vẻ là hướng đi đúng. Mô hình thực thi eager của pandas không phù hợp với mô hình thực thi trì hoãn của Ibis. Vì thế backend pandas thường chậm hơn rất nhiều so với việc dùng trực tiếp pandas
  • Khi Ibis hỗ trợ ngày càng nhiều backend, việc bảo trì mã được tinh chỉnh cho từng backend riêng lẻ sẽ ngày càng khó hơn. Loại bỏ backend pandas sẽ giúp codebase gọn gàng hơn và dễ bảo trì hơn
  • Nếu việc dùng backend DuckDB có thể thay thế toàn bộ chức năng của pandas, thì có vẻ không còn lý do để duy trì backend pandas. Ngược lại, nó còn có thể gây nhầm lẫn cho người dùng mới

Bài viết liên quan

2 bình luận

 
yangeok 2024-09-03

Thực tế là nhiều người vẫn đang dùng pandas quen thuộc nhất,,
 
GN⁺ 2024-08-30
Ý kiến trên Hacker News

  • NaN là kết quả của 0/0, nghĩa là giá trị có tồn tại nhưng không thể biết chính xác

    • NULL nghĩa là không biết giá trị tại một vị trí cụ thể
    • Cách triển khai NaN và NULL khác nhau, nhưng không hoàn toàn không liên quan
    • None của Python khác với NaN và NULL

  • Có nhiều engine tính toán tốt hơn pandas

    • Mọi người vẫn tiếp tục dùng pandas vì codebase hiện có và tích hợp với bên thứ ba
    • Với các tác vụ dữ liệu nhỏ, pandas vẫn hoàn toàn phù hợp

  • Trong vài tháng gần đây, tôi đã thay pandas bằng ibis trong các dự án mới

    • Cú pháp của ibis linh hoạt hơn pandas
    • Việc chain các phép toán khiến các đoạn mã dễ переносить hơn
    • Backend DuckDB rất nhanh
    • Cộng đồng rất năng động và thân thiện
    • Tôi đang quảng bá ibis với các đồng nghiệp

  • Tính năng multi-index của pandas là điểm mạnh nhất

    • Có thể dùng cho cả cột
    • Tôi không chắc các công cụ mới sẽ xử lý tính năng này như thế nào

  • Tôi tò mò không biết mọi người đã cân nhắc Polars chưa

    • Nhóm của chúng tôi ghét pandas nên đang dùng Polars làm tiêu chuẩn

  • pandas có thể mở rộng sang các kiểu cột mới

    • Tôi không chắc Polars có hỗ trợ điều đó hay không

  • Giá trị của Ibis không nằm ở chỗ có thể dùng DuckDB

    • Dù có công cụ mới xuất hiện thì cú pháp vẫn tiếp tục hoạt động

  • Tôi chưa từng nghe nhiều về Ibis

    • Nếu rời khỏi pandas, khả năng tôi thử Ibis sẽ thấp hơn
    • Các framework mới đang rời xa pandas/numpy, nhưng tôi sẽ chờ đến khi vấn đề tương thích và các edge case được giải quyết
    • Tôi không ngại chờ thêm vài mili giây

  • API thư viện của pandas không phải lúc nào cũng trực quan

    • Có vấn đề với NaN/None, nhưng đó chỉ là bất tiện nhỏ

  • Lý do dùng pandas là vì hệ sinh thái tích hợp của nó

    • Khi đọc dữ liệu từ file json, file csv, Python dict... rồi trực quan hóa bằng plotly, pandas rất tiện
    • Nếu Ibis tương thích với DataFrame của pandas thì tôi không quá quan tâm đến backend