Pandas nên tuyệt chủng: Khi thư viện DataFrame huyền thoại không còn xứng đáng

Có một nghịch lý đang tồn tại trong cộng đồng phân tích dữ liệu Python: Pandas — thư viện được hàng triệu lập trình viên sử dụng mỗi ngày — lại đang âm thầm đẩy người dùng vào những giải pháp cồng kềnh và tốn kém không cần thiết. Bài viết này sẽ mổ xẻ lý do tại sao Pandas cần được thay thế, và đâu là những lựa chọn thay thế xứng đáng.

Con đường tiến hóa quen thuộc của dân phân tích dữ liệu

Hầu hết chúng ta đều bắt đầu với Excel. Khi dữ liệu vượt qua ngưỡng vài GB, ta chuyển sang Pandas. Thư viện này phục vụ tốt cho đến khi kích thước dữ liệu lên tới hàng chục GB — lúc đó người dùng bắt đầu gặp các vấn đề về bộ nhớ, tốc độ tính toán chậm chạp, và cảm thấy bực bội với API rườm rà của Pandas.

Câu trả lời truyền thống cho vấn đề này là chuyển sang các công cụ "thực thụ" như Spark, DataBricks, Snowflake hay Dask — những hệ thống phân tán được thiết kế cho Big Data với chi phí không hề nhỏ.

Nhưng đây là điều quan trọng: có một khoảng trống ngày càng lớn giữa "vách đá Pandas" và quy mô mà các hệ thống phân tán thực sự cần thiết. Khoảng trống này nằm đâu đó quanh ngưỡng 100GB, và có thể được lấp đầy hiệu quả bằng các công cụ đơn máy hiệu năng cao hiện đại như Polars và DuckDB.

Bạn có thực sự có Big Data?

Năm 2024, Amazon công bố một bài báo mang tên "Why TPC is not enough: An analysis of the Amazon Redshift fleet". Mục tiêu là so sánh dữ liệu telemetry từ chính hệ thống Redshift của họ với các mẫu truy vấn trong benchmark tiêu chuẩn ngành.

So sánh thời gian chạy truy vấn của Amazon Redshift

Với một vài giả định hợp lý — mỗi hàng trong bảng Redshift trung bình 1KB, mỗi cluster gồm 10 máy với khả năng xử lý 8GB/s từ S3 — ta rút ra được những kết luận đáng chú ý:

• 94,68% bảng trong hệ thống Redshift chứa ít hơn 100GB dữ liệu
• 86,9% truy vấn xử lý trên 80GB dữ liệu hoặc ít hơn

Kích thước bảng trong hệ thống Amazon Redshift

Nói cách khác: phần lớn chúng ta không có Big Data, và có lẽ sẽ không bao giờ có. Chúng ta có các bài toán Medium Data, và cần những giải pháp Medium Data phù hợp.

Nếu bạn đang tự hỏi liệu mình có cần đến Spark hay không, câu trả lời rất có thể là không.

Cuộc đua hiệu năng: Pandas vs Polars vs DuckDB

Để minh họa rõ ràng sự khác biệt, hãy xem xét bài toán 1 Billion Row Challenge — thử thách viết chương trình tính min, mean, max của một file CSV chứa 1 tỷ dòng dữ liệu trạm thời tiết. Bản Java nhanh nhất đạt 1,5 giây.

Kết quả benchmark trên cấu hình 32 nhân, 128GB RAM:

Thư viện	Thời gian trung vị	CPU tối đa	Bộ nhớ tối đa
Pandas	4 phút 28 giây	113%	38,12 GB
Polars	5,04 giây	3202,6%	18,02 GB
DuckDB	5,19 giây	3174,6%	1,93 GB

Kết quả nói lên tất cả: Polars và DuckDB nhanh hơn Pandas hàng chục lần, sử dụng ít hơn 2 lần và 19 lần bộ nhớ tương ứng. Chúng chỉ còn cách bản Java tinh chỉnh thủ công một khoảng rất nhỏ.

Ngay cả trên laptop cấu hình khiêm tốn hơn (Framework 13, Intel i5-1135G7, 16GB RAM), sự chênh lệch vẫn rõ rệt: Pandas mất 12 phút 15 giây, trong khi Polars chỉ cần 39 giây và DuckDB là 47 giây.

Những lợi ích "miễn phí" bạn nhận được

Việc chuyển sang Polars hoặc DuckDB mang lại nhiều lợi ích vượt xa tốc độ thuần túy:

• Đa luồng không đau đớn: Cả hai tự động tận dụng toàn bộ nhân CPU mà bạn không cần quản lý thread hay process thủ công
• Sử dụng bộ nhớ hiệu quả và streaming: Xử lý dữ liệu theo từng khối giúp giảm đáng kể lượng RAM cần thiết
• Lazy evaluation: Định nghĩa toàn bộ phép tính trước, cho phép tối ưu hóa execution plan — giống như các database "thực thụ"
• Spill-to-disk tiềm năng: Khi vượt quá RAM, các công cụ này có cơ chế ghi tạm kết quả trung gian xuống đĩa thông minh hơn so với swap mặc định của OS

Chuyển đổi dễ dàng nhờ Apache Arrow

Điểm mấu chốt giúp việc thử nghiệm các công cụ này không cần viết lại toàn bộ codebase là Apache Arrow — định dạng biểu diễn dữ liệu cột trong bộ nhớ đang trở thành tiêu chuẩn thực tế, được tạo ra bởi chính Wes McKinney, cha đẻ của Pandas.

Polars và DuckDB đều hỗ trợ Arrow native. Điều này có nghĩa là bạn có thể di chuyển DataFrame giữa Polars, Pandas và DuckDB mà không cần sao chép bộ nhớ — khiến việc chuyển đổi gần như "miễn phí".

Ví dụ minh họa với dữ liệu taxi NYC

Polars hay DuckDB — cái nào tốt hơn?

Câu trả lời hoàn toàn phụ thuộc vào workload, kinh nghiệm và sở thích của bạn:

• Data engineer thường yêu thích DuckDB vì giao diện SQL quen thuộc và khả năng chuyển đổi kỹ năng cao
• Software engineer thường yêu thích Polars vì API DataFrame gần gũi với Pandas

Điều duy nhất bạn không nên làm là mù quáng chọn một hệ thống truy vấn phân tán cùng tất cả sự phức tạp đi kèm chỉ vì Pandas có hiệu năng kém.

Hiệu năng chưa bao giờ dễ tiếp cận đến thế. Hãy thử nghiệm và lựa chọn!

Kết luận cho cộng đồng Việt Nam

Với các đội ngũ phát triển phần mềm và phân tích dữ liệu tại Việt Nam — nơi hạ tầng cloud thường là yếu tố chi phí đáng cân nhắc — việc chuyển từ Pandas sang Polars hoặc DuckDB có thể mang lại hiệu quả rõ rệt về cả thời gian xử lý lẫn chi phí vận hành. Bạn không cần những cụm Spark đắt đỏ cho các bài toán dữ liệu hàng chục GB.

Hãy bắt đầu bằng cách thử Polars hoặc DuckDB trên một pipeline nhỏ, tận dụng khả năng tương thích Arrow để chuyển đổi dần dần. Rất có thể bạn sẽ ngạc nhiên với những gì mình nhận được mà không phải trả thêm bất kỳ chi phí nào.