Polars

 (pola.rs)
4 điểm bởi GN⁺ 2024-01-09 | 1 bình luận | Chia sẻ qua WhatsApp
  • Là thư viện DataFrame mã nguồn mở hướng đến các môi trường cần xử lý dữ liệu nhanh trên một máy đơn, ghi nhận hơn 575 triệu lượt tải xuống và hơn 38.000 sao GitHub
  • Cốt lõi hiệu năng nằm ở query engine đa luồng dựa trên Rust, xử lý hướng cột, vector hóa, SIMD và thực thi song song
  • Tiếp tục được cung cấp dưới dạng thư viện mã nguồn mở theo giấy phép MIT, đồng thời có Polars Cloud để mở rộng đến workload production với cùng API
  • Tuyên bố cải thiện hiệu năng hơn 30 lần so với pandas; benchmark TPC-H phái sinh được thực hiện trên c3-highmem-22 với scale factor 10 và bao gồm I/O
  • Hỗ trợ CSV, JSON, Parquet, Delta Lake, AVRO, Excel, Arrow, các cơ sở dữ liệu chính, S3 và Azure storage, nên dễ gắn vào data stack hiện có

Cách Polars được cung cấp

  • Polars là thư viện mã nguồn mở để thao tác dữ liệu, và đã trở thành một trong những giải pháp xử lý dữ liệu nhanh nhất trên một máy đơn
  • Cung cấp API có cấu trúc và có kiểu, đồng thời hướng đến cả tính biểu đạt lẫn sự dễ dùng
  • Các chỉ số công khai hiện tại như sau
    • Hơn 575M lượt tải xuống
    • Hơn 38k sao GitHub
  • Tài liệu bắt đầu có tại Get started

  • Polars mã nguồn mở

    • Polars là thư viện mã nguồn mở có thể sử dụng miễn phí theo giấy phép MIT
    • Được cung cấp như một thư viện DataFrame hiệu năng cao, với cách cài đặt đơn giản
    • Ví dụ cài đặt như sau
      • Python: pip install polars
      • Rust: polars = { version = "x", features = ["lazy", ...]}
      • Node.js: const pl = require('nodejs-polars');

  • Polars Cloud

    • Polars Cloud là giải pháp managed để mở rộng các truy vấn Polars trong môi trường notebook thành workload production trên cloud hoặc on-premises
    • Có thể mở rộng bằng cùng API mà không cần thay đổi code
    • Hỗ trợ triển khai theo hình thức Cloud hoặc On-Prem
    • Chỉ tính phí cho việc thực thi truy vấn
    • Có thể dùng thử tại Polars Cloud

Mô hình hiệu năng và tích hợp dữ liệu

  • Nền tảng hiệu năng của Polars là query engine đa luồng dựa trên Rust và thiết kế xử lý song song
  • Vector hóa và xử lý hướng cột cho phép các thuật toán có tính nhất quán cache và hiệu năng cao trên các bộ xử lý hiện đại
  • Đã được so sánh với nhiều giải pháp trong benchmark TPC-H độc lập phái sinh, nhằm tái hiện các tác vụ làm sạch dữ liệu trong thực tế
    • Có thể cải thiện hiệu năng hơn 30 lần so với pandas
    • Benchmark được thực hiện trên c3-highmem-22 với scale factor 10 và bao gồm I/O
    • Các truy vấn được công bố dưới dạng open source
    • Có thể xem chi tiết tại Learn more

  • Tính dễ dùng và tối ưu hóa thực thi

    • Người dùng viết truy vấn theo cách mình muốn, còn query optimizer của Polars sẽ quyết định cách thực thi hiệu quả
    • Chia công việc cho các lõi CPU khả dụng và thực thi song song mà không cần cấu hình bổ sung hay overhead tuần tự hóa
    • Sử dụng mô hình bộ nhớ Apache Arrow để tích hợp với các công cụ dữ liệu hiện có
    • Chia sẻ dữ liệu zero-copy giúp giảm chi phí phối hợp giữa các công cụ
    • Được thiết kế gần với máy mà không có phụ thuộc bên ngoài, cho phép kiểm soát API, bộ nhớ và thực thi
    • Các dataset lớn hơn bộ nhớ có thể được xử lý bằng streaming API mà không cần đưa toàn bộ dữ liệu vào bộ nhớ

  • Định dạng dữ liệu được hỗ trợ

    • Polars hỗ trợ đọc và ghi các định dạng dữ liệu phổ biến để tích hợp với data stack hiện có
    • Phạm vi hỗ trợ như sau
      • 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

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-01-09
Ý kiến trên Hacker News

  • Trang này rõ ràng được viết cho những người đã biết mình đang xem gì. Ngay từ câu đầu đã không giải thích công cụ, mà bắt đầu bằng chuyện chất lượng như “Polars is written from the ground up with performance in mind”, rồi phần còn lại cũng theo cùng mạch đó
    Có ai có thể giải thích như cho trẻ 5 tuổi rằng đây là gì và nó là giải pháp tốt cho nhu cầu nào không?
    Chỉnh sửa: Cuối cùng tôi hiểu nó là một triển khai thay thế cho Pandas DataFrame. Theo phần giải thích tôi tìm được trên Google ở https://realpython.com/pandas-dataframe/, DataFrame là cấu trúc chứa dữ liệu hai chiều và nhãn; được dùng rộng rãi trong các lĩnh vực nặng về dữ liệu như khoa học dữ liệu, machine learning, tính toán khoa học; và tương tự bảng SQL hoặc bảng tính Excel/Calc

    • Đây chính là một nhược điểm gây khó chịu của nhiều sản phẩm công nghệ. Việc muốn nói với độc giả mục tiêu — ở đây là nhà khoa học dữ liệu thích Pandas nhưng thấy nó chậm và kém linh hoạt — là điều tự nhiên, nhưng với người mới thì lại tạo cảm giác bị gạt ra ngoài
      Tôi là độc giả mục tiêu của Polars và đã định dùng thử suốt mấy tháng nay nhưng cứ trì hoãn. Tôi vẫn còn trung thành với Pandas vì Wes McKinney, người tạo ra Pandas, đã viết một cuốn sách hữu ích giải thích các công cụ phân tích phổ biến: https://wesmckinney.com/book/
    • Nó là Pandas nhưng nhanh. Pandas là thư viện dataframe mã nguồn mở nguyên bản, chắc chắn và được dùng rộng rãi, nhưng có vẻ phạm vi rộng và chậm hơn tân binh này. Từ “dataframe” đã là tín hiệu đủ rõ cho những ai từng dùng rồi
    • Mỗi lần thấy những trang như thế này tôi lại thấy mình khiêm tốn hơn. “DataFrame cho kỷ nguyên mới” — tôi tự hỏi liệu mình có biết dataframe là gì không; thấy “query engine đa luồng” thì lại nghĩ có phải giống cơ sở dữ liệu không
      Có biểu đồ so sánh với những thứ tên là pandas, modin, vaex, nhưng tôi cũng chẳng biết chúng là gì, nên cuối cùng cảm giác rằng thứ này không dành cho mình. Tôi thích đọc và học về công nghệ hay dự án mới, nhưng ở đây tôi không có gì để bám vào
      Có lẽ đây cũng là điều người bình thường trải qua khi tôi nói về mấy chuyện phát triển web tầm thường của mình
    • Công bằng mà nói, tiêu đề trang là “Dataframes for the new Era”, và liên kết Get Started dưới tiêu đề trỏ tới tài liệu trên trang GitHub. GitHub giải thích thư viện này là gì cho những người có nền tảng phân tích dữ liệu: https://github.com/pola-rs/polars
    • Hiện tôi đang bị kéo vào mảng “dữ liệu”, và nơi này giống như một vũ trụ song song có bối cảnh và văn hóa riêng. Có rất nhiều cách nói kiểu như “kết nối tới instance Antelope hay Meringue với độ dễ dùng của Nincompoop và hiệu năng của ARSE2”
      Điều thú vị ở Polars là nó giống Pandas nhưng dùng Arrow, một backend Rust hiệu quả hơn, và có những thứ như query planner giúp việc kết hợp phép toán hiệu quả hơn. Thường thì Polars hiệu quả hơn Pandas rất nhiều, nên nhiều tác vụ trước đây cần hạ tầng phức tạp nay thường có thể chạy trên một máy đơn
      Đây là một thế cạnh tranh rất thân thiện do một nhà phát triển cốt lõi của Pandas tạo ra; nhìn chung có vẻ mọi người đều thích nó và theo thời gian khả năng cao nó sẽ thay thế Pandas

  • Các bài liên quan:
    Detailed Comparison Between Polars, DuckDB, Pandas, Modin, Ponder, Fugue, Daft - https://news.ycombinator.com/item?id=37087279 - tháng 8 năm 2023
    Polars: Company Formation Announcement - https://news.ycombinator.com/item?id=36984611 - tháng 8 năm 2023
    Replacing Pandas with Polars - https://news.ycombinator.com/item?id=34452526 - tháng 1 năm 2023
    Fast DataFrames for Ruby - https://news.ycombinator.com/item?id=34423221 - tháng 1 năm 2023
    Modern Polars: A comparison of the Polars and Pandas dataframe libraries - https://news.ycombinator.com/item?id=34275818 - tháng 1 năm 2023
    Rust polars 0.26 is released - https://news.ycombinator.com/item?id=34092566 - tháng 12 năm 2022
    Polars: Fast DataFrame library for Rust and Python - https://news.ycombinator.com/item?id=29584698 - tháng 12 năm 2021
    Polars: Rust DataFrames Based on Apache Arrow - https://news.ycombinator.com/item?id=23768227 - tháng 7 năm 2020

  • Tôi đã dùng Pandas vài năm nhưng lúc nào cũng có cảm giác như đang lăn một quả bóng lên dốc. Chỉ riêng những tác vụ đơn giản như join đã vậy, và cũng không được quên reset index
    Polars cho cảm giác tốt hơn Pandas ở hầu như mọi mặt. Nhanh hơn, dùng đa lõi, tốn ít bộ nhớ hơn, và API trực quan hơn. Vì vẫn là thư viện còn khá trẻ nên có nhược điểm, nhưng nếu là dự án mới thì ít nhất cũng đáng xem xét
    Việc có thể dễ dàng tận dụng hệ sinh thái Rust cũng rất tuyệt. Tôi đã tự viết plugin để song song hóa hàm, và làm cho một số mã địa không gian nhanh hơn 100 lần

    • Lấy join làm ví dụ thì hơi mỉa mai. Tôi luôn nghĩ vấn đề lớn nhất của Pandas là tài liệu. Chẳng hạn, bạn có biết có cách join dataframe mà không dùng index không? Tên của nó không phải “join” mà là merge
      Ban đầu Pandas chịu ảnh hưởng mạnh từ thuật ngữ và cách dùng của R, và trong R “merge” đã là cách gọi phổ biến cho “join”. Nếu vào khoảng năm 2015, khi bắt đầu học Pandas, mà trước đó chưa biết R thì có lẽ khó có thể học nhanh được
    • Tôi tò mò mọi người nhìn nhận PRQL (prql-lang.org) thế nào. Cá nhân tôi xem nó là thứ kết hợp cảm giác sử dụng và trải nghiệm lập trình viên của Polars hay Pandas với sức mạnh và tính phổ quát của SQL
      Truy vấn có thể chạy không chỉ trên Polars và Pandas mà còn trên bất kỳ engine thực thi tương thích SQL nào bạn muốn, như DuckDB, ClickHouse, BigQuery, Redshift, Postgres, Trino/Presto, SQLite, v.v.
      Cú pháp và ngữ nghĩa của join là một trong những phần khó nhất nên gần đây đang được thảo luận lại. Nó là cốt lõi của đại số quan hệ, và cũng tương ứng với chữ R trong PRQL. Hầu hết các biến đổi cơ bản của PRQL là thao tác danh sách đơn giản như map, filter, reduce, nhưng join cần cẩn thận nếu muốn bảo toàn phép hợp thành monad. Tôi đã để lại suy nghĩ ở đây: https://github.com/PRQL/prql/issues/3782#issuecomment-1811312787
      Issue đó đã đóng, nhưng sẽ rất hay nếu bạn mở issue mới hoặc tag @snth để chia sẻ ý kiến. Nói thêm, tôi là contributor của PRQL
    • Tôi tò mò không biết việc merge dataframe trong Pandas khó ở điểm nào

  • Khi đánh giá thử, ưu điểm lớn nhất là API nhất quán và dễ hiểu hơn Pandas rất nhiều. Có lẽ điều đó cũng là tự nhiên vì họ đã học được từ 20 phiên bản major của Pandas
    Tuy nhiên, do ít được dùng hơn rất nhiều nên Copilot viết code Polars không tốt. Vì vậy hiện tại tôi vẫn tiếp tục dùng Pandas và Copilot. Đây là lần đầu tôi cảm nhận được rằng các thư viện mới nói chung có rào cản như vậy

    • Đây là lần đầu tôi thấy có người công khai nói rằng họ ưu tiên một thư viện vì mức hỗ trợ của Copilot. Không phán xét, chỉ thấy thú vị
      Dù vậy Copilot học rất nhanh bên trong repository. Tôi dùng một stack cực kỳ tùy biến được cấu hình bằng TS-Plus, một fork TypeScript mà ngay cả tác giả cũng không dùng hay khuyến nghị, vậy mà Copilot vẫn sinh ra code TS-Plus khá tốt
      Sau khi thấy vài ví dụ, đừng đánh giá thấp việc Copilot có thể trở nên khá giỏi ở giai đoạn code lặp lại
    • Hỗ trợ Copilot là vấn đề con gà và quả trứng. Nó phải học từ code của người khác, nhưng nếu mọi người không viết code Polars khi không có Copilot, thì Copilot cũng sẽ không viết code Polars tốt hơn được
    • Tôi từng gặp chuyện tương tự khi dùng danfo.js, một thư viện dataframe khác của js. Copilot cứ ảo giác ra tính năng và tên method
      Cũng không phải vấn đề lớn vì có thể đọc tài liệu, nhưng việc Copilot không thể lập tức nhả ra thứ mình cần thì khá phiền
    • Dù thừa nhận API nhất quán và dễ hiểu hơn, bạn vẫn định ở lại với Pandas chỉ vì Copilot giúp dễ hơn sao? Tốt hơn là nên dùng công cụ mà bạn đã công nhận là tốt hơn, cho cả bản thân lẫn đổi mới mã nguồn mở
      Tôi đã dùng API Pandas lâu rồi và không thích nó. Tôi khá chủ động trong việc liên tục cải thiện cách học, công cụ, tư duy và kỹ năng
    • Thư viện Polars thay đổi nhanh. Tôi không dùng Copilot, nhưng nếu đưa thông tin mới vào system instruction, ví dụ như with_column đã đổi thành with_columns, và thêm nội dung tài liệu, thì tôi nhận được kết quả khá tốt với ChatGPT

  • Khi Deno ra mắt hỗ trợ Jupyter, nodejs-polars là một trong những thư viện cốt lõi về khoa học dữ liệu được hỗ trợ
    https://blog.jupyter.org/bringing-modern-javascript-to-the-jupyter-notebook-fc998095081e
    Cá nhân tôi không phải dân khoa học dữ liệu, nhưng xét việc hệ sinh thái JS/Jupyter vẫn còn ở giai đoạn đầu, việc dựng phân tích dựa trên pola.rs trong TypeScript nhanh đến đáng ngạc nhiên
    JS binding chắc chắn vẫn còn chỗ cần chỉnh, nhưng tôi hy vọng khả năng tiếp cận tốt hơn sẽ kéo theo cải tiến lặp lại

    • Tôi luôn muốn có thứ gì đó giống Pandas trong JS, giờ mới biết cái này

  • Tôi thật sự kỳ vọng vào Polars và hiệu năng tốc độ cũng rất ấn tượng, nhưng việc so sánh vaex, modin, dask trong cùng một benchmark làm tôi thấy khó chịu
    Tất cả các thư viện này đều nhắm tới xử lý dữ liệu ngoài lõi, tức là khi dữ liệu quá lớn nên phải tính toán trên nhiều máy. So sánh với một thư viện dataframe chạy trên một máy là kỳ lạ, và vì chắc chắn có nhiều overhead nên chúng tất yếu sẽ chậm hơn
    Không có nhiều trường hợp dùng Polars trong cùng bối cảnh với các thư viện đó, nên việc đưa chúng vào benchmark như thể cùng hạng là hơi buồn cười. Hơn nữa, DuckDB, thứ có thể dùng trong cùng bối cảnh với Polars và trong nhiều trường hợp còn nhanh hơn, lại không có trong benchmark
    Kỹ thuật phần mềm của Polars là một công trình xuất sắc, và không cần những benchmark dễ gây hiểu lầm như vậy

    • Tôi không biết các cái khác thế nào, nhưng Dask có thể dùng trên một máy, và đó cũng là cách dễ nhất để dùng Dask. Nó chia dataframe thành các partition rồi xử lý trên từng core để song song hóa phép toán
      Có thể cải thiện hiệu năng gấp 2 lần so với Pandas mà không cần cấu hình, và với một số phép toán tôi đã thấy tới 5 lần
    • Ibis, dataframe Python do người tạo ra Pandas làm, dùng DuckDB làm backend mặc định, và trừ một số ngoại lệ truy vấn, thường thắng Polars trong các benchmark kiểu này

  • Tôi không trực tiếp dùng Polars, mà dùng nó như một định dạng vật hoá trong workflow DuckDB
    duckdb.query(sql).pl() nhanh hơn rất nhiều so với duckdb.query(sql).df(). Với Polars thì zero-copy nên hoàn tất ngay, còn Pandas thì nếu DataFrame lớn sẽ mất khá lâu. Và chỉ khác cú pháp một chút, vẫn có thể thao tác như Pandas DataFrame
    Rất phù hợp để xử lý các tập dữ liệu lớn

  • Có lẽ sẽ có một hệ quả của định luật thứ 10 của Greenspun (https://en.wikipedia.org/wiki/Greenspun's_tenth_rule)): mọi thư viện phân tích dữ liệu đủ phức tạp rốt cuộc sẽ triển khai một nửa SQL theo cách chắp vá, không có đặc tả chính thức, nhiều lỗi và chậm
    Thỉnh thoảng tôi dùng Pandas và có lẽ cũng sẽ thử cái này, nhưng lúc nào tôi cũng nghĩ giá như ngay từ đầu cứ đưa dữ liệu đang làm việc vào Postgres thì tốt hơn
    Dù tôi không phải chuyên gia cơ sở dữ liệu và Python tiện hơn nhiều, các chức năng chọn, sắp xếp, lọc, join dữ liệu dạng bảng thì SQL vẫn tốt hơn hẳn

    • Khuyên nên xem DuckDB và extension duckdb-prql
      DuckDB cho phép xử lý trực tiếp bằng SQL dữ liệu ở định dạng Polars, Pandas và Arrow mà không cần sao chép hay nhân bản dữ liệu
      duckdb-prql cho phép dùng PRQL (prql-lang.org), và cá nhân tôi cho rằng nó kết hợp sức mạnh và tính phổ quát của SQL với cảm giác sử dụng và trải nghiệm lập trình viên của Polars hoặc Pandas. Nói thêm, tôi là contributor của PRQL
    • Có thể làm vậy, nhưng nếu là truy vấn “phân tích” thì hiệu năng có khả năng kém hơn nhiều, tính linh hoạt và khả năng biểu đạt cũng giảm
      Thay vào đó, đáng để xem DuckDB. Phần triển khai SQL của nó không phải kiểu chắp vá, cũng không đầy lỗi, chậm hay không hoàn chỉnh. Tôi không rõ mức độ hình thức của đặc tả, nhưng nó tương thích với Polars
    • Cá nhân tôi thấy cú pháp lazy dataframe là frontend tốt hơn nhiều cho query engine. Polars cũng hỗ trợ SQL, nhưng lỗi thường không đến từ frontend mà từ query engine
      Với kiểu truy vấn chạy trên các engine như vậy, Postgres sẽ chậm hơn OLAP query engine khoảng một bậc độ lớn
    • Người tạo ra Pandas đã làm Ibis với backend Postgres vì lý do này: https://ibis-project.org/backends/postgresql
      Đây là cách tiếp cận tốt hơn để dùng Python dataframe cùng với SQL

  • Vài tháng trước tôi đã thử chuyển một codebase Pandas lớn sang Polars. Tôi vốn không thích lắm việc làm phân tích hay data pipelining trong Python, vì các phép biến đổi phức tạp trong Pandas mất lâu hơn 2–5 lần so với Julia hoặc R (dùng dataframes.jl, dplyr)
    Đáng tiếc là Polars cũng không phải câu trả lời. Có quá nhiều lỗi trong các thao tác chuẩn, và khả năng tương tác với Pandas không ổn định. Đây là vấn đề vì nhiều thư viện yêu cầu Pandas DataFrame làm input. API cũng rất dài dòng đối với một thư viện dataframe hiện đại, dù vẫn tốt hơn Pandas
    Hy vọng theo thời gian các vấn đề này sẽ được giải quyết, nhưng hiện tại dùng DuckDB trên Pandas là tốt nhất. Nhanh như Polars nhưng ổn định hơn và khả năng tương tác cũng tốt hơn
    Mong rằng một ngày nào đó hệ sinh thái dataframe của Python cũng đạt đến mức như R, nơi có thể dễ dàng dùng song song một thư viện dataframe hướng phân tích với API trực quan (dplyr) và một thư viện dataframe hiệu năng cao (data.table)

    • Tôi cũng khó chịu vì sự dài dòng đó. Pandas cũng khá dài dòng so với những thứ như data.table, nhưng Polars đem lại cảm giác đang dùng một API hơn là “công cụ thao tác dữ liệu”
      Có lẽ tôi sẽ không dùng nó cho phân tích dữ liệu khám phá hay nghiên cứu, nhưng tôi đã bắt đầu dùng trong một số script production vì hiệu năng tốt hơn
      Kết hợp dplyr + data.table của R vẫn là trải nghiệm thao tác dữ liệu tôi thích nhất. Chỉ tiếc là R mà có thứ gì đó như Matplotlib thì tốt. ggplot thì quá high-level, còn đồ hoạ cơ bản thì quá low-level. Scikit-Learn cũng mô-đun hoá hơn Caret rất nhiều, nên tôi không nhớ Caret
    • Tôi tò mò bạn nhìn nhận PRQL (prql-lang.org) thế nào. Mục tiêu của nó là mang lại cảm giác dùng dplyr ở bất cứ nơi nào dùng SQL, và biên dịch xuống SQL
      Cá nhân tôi xem nó là sự kết hợp giữa trải nghiệm lập trình viên của dplyr, Polars, Pandas với sức mạnh và tính phổ quát của SQL. Truy vấn có thể chạy trên bất kỳ execution engine tương thích SQL nào bạn muốn, không chỉ Polars, Pandas mà cả DuckDB, ClickHouse, BigQuery, Redshift, Postgres, Trino/Presto, SQLite, v.v.
      Tôi muốn nghe ý kiến trên thảo luận GitHub (https://github.com/PRQL/prql/discussions) hoặc Discord (https://discord.com/invite/XWxbCrWr). Nói thêm, tôi là contributor của PRQL
    • Thật hay khi bạn đã có trải nghiệm với dataframe của cả R, Python và Julia. Tôi tò mò trong số đó bạn thích bên nào nhất. Hệ sinh thái có thể không so sánh trực tiếp được, nhưng nếu xét các tác vụ như những phép toán cốt lõi thì cái nào tốt nhất?
    • Ibis với backend DuckDB cũng đáng thử một lần. Cá nhân tôi cũng khá thích Polars. Nhìn chung các developer phản hồi issue khá nhanh

  • Nhóm khoa học dữ liệu của chúng tôi đã đánh giá Polars và kết quả khá lẫn lộn. Nếu có những đoạn mà hiệu năng là yếu tố quan trọng thì chúng tôi sẽ cân nhắc áp dụng, nhưng ngoài ra thì hơi nghiêng về phía tiêu cực vì chi phí thay thế Pandas trong hàng chục dự án

    • Tôi nghĩ nhận định đó là đúng. Hiện tại, tôi cho rằng đây là lúc thử nghiệm hơn là thay thế Pandas vốn đang chạy tốt
      API vẫn còn có những thay đổi phá vỡ tương thích có thể dự đoán được, và nếu trải rộng qua nhiều dự án thì có thể trở thành gánh nặng bảo trì. Dù vậy, API đã cho cảm giác nhất quán hơn, và nhìn chung có vẻ đang đi đúng hướng
    • Tốt nhất là đừng viết lại toàn bộ mã. Tuy nhiên, với mã mới thì đáng để áp dụng hoặc đánh giá
      Đặc biệt là chi phí tương tác với Pandas rất thấp, và nếu dùng backend Arrow thì việc chuyển sang Pandas theo kiểu zero-copy cũng khá dễ dàng
    • Trong tương lai còn có https://github.com/fugue-project/fugue
    • Tôi tò mò không biết nhóm của bạn dùng pandasql, hay chủ yếu dùng trực tiếp API của Pandas