اگر اسکریپت‌های پایتونیتان برای تحلیل داده ساعت‌ها طول می‌کشد، فایل‌های CSV چند گیگابایتی حافظه را می‌بلعند و Pandas روی داده‌های بزرگ کم می‌آورد، Polars دقیقاً همان ابزاری است که دنبالش بوده‌اید. این کتابخانه متن‌باز با هسته‌ای نوشته‌شده به زبان Rust، پردازش دیتافریم را آن‌قدر سرعت می‌بخشد که در بنچمارک‌های مستقل، بسیاری عملیات چندین برابر سریع‌تر از Pandas انجام می‌شوند؛ آن هم با کدی کوتاه‌تر و خواناتر. در این راهنمای ابزار، قابلیت‌ها، محدودیت‌ها، نحوه نصب و سناری‌های واقعی Polars را کنار هم می‌گذاریم تا دقیقاً بدانید کِی باید سراغش بروید و کِی نه.

Polars؛ سریع‌ترین کتابخانه پردازش داده در پایتون

Polars یک کتابخانه متن‌باز با مجوز MIT و مبتنی بر Apache Arrow برای ساخت و پردازش دیتافریم در پایتون است که هسته اصلی‌اش با Rust نوشته شده است. رمز سرعت آن سه چیز است: چندهسته‌ای بودن واقعی، چیدمان ستونی حافظه و یک بهینه‌ساز کوئری که در حالت Lazy Execution کل زنجیره پردازش را قبل از اجرا بازنویسی و فشرده می‌کند. اگر داده‌هایتان از گنجایش Pandas بیرون زده، ادامه همین راهنما مسیر ورود و مهاجرت را نشان‌تان می‌دهد.

فهرست مطالب

Polars؛ سریع‌ترین کتابخانه پردازش داده در پایتون
Polars چیست و چه چیزی آن را سریع می‌کند؟
نصب Polars و ساخت اولین دیتافریم
Lazy Execution؛ قلب تپنده سرعت در Polars
کار با داده بزرگ؛ CSV، Parquet و Streaming
مقایسه Polars با Pandas و DuckDB
سناری‌های واقعی استفاده از Polars
اشتباهات رایج هنگام استفاده از Polars
سوالات متداول
جمع‌بندی

Polars چیست و چه چیزی آن را سریع می‌کند؟

Polars در سال ۲۰۲۰ به‌عنوان پاسخی به محدودیت‌های Pandas متولد شد؛ محدودیت‌هایی مثل مصرف حافظه بالا، اجرای تک‌رشته‌ای و ساختن نسخه‌های میانی بی‌مورد از داده. در Polars شما همان دیتافریم، ستون، فیلتر، گروه‌بندی و Join را دارید، اما زیر کاپوت چیزهای دیگری می‌گذرد. سرعت این کتابخانه روی چهار رکن می‌ایستد:

هسته Rust: کار سنگین در زبان Rust انجام می‌شود؛ بدون سربار تفسیر پایتون و با مدیریت حافظه‌ی پیش‌بینی‌پذیر.
پایه Arrow: داده‌ها در حافظه با فرمت ستونی Apache Arrow نگهداری می‌شوند؛ همان فرمتی که برای تبادل بدون کپی بین کتابخانه‌های تحلیل داده طراحی شده است.
اجرای چندهسته‌ای (Work-Stealing): عملیات روی همه هسته‌های CPU پخش می‌شوند، نه فقط یک هسته؛ همین تنها عامل بیشترِ شکاف سرعت با Pandas است.
بهینه‌ساز کوئری: فیلترها پایین‌تر از منبع داده فشار داده می‌شوند (Predicate Pushdown)، ستون‌های بلااستفاده حذف می‌شوند (Projection Pushdown) و مراحل قابل‌ادغام ترکیب می‌شوند.

نکته مهم این است که Polars صرفاً یک Pandas سریع‌تر نیست؛ فلسفه‌اش «بیانگر‌محوری» است. یعنی به‌جای دست‌وپازدن با سطر و ستون، توصیف می‌کنید چه خروجی می‌خواهید و موتور تصمیم می‌گیرد چطور آن را بسازد.

نصب Polars و ساخت اولین دیتافریم

نصب Polars مثل هر کتابخانه پایتون دیگری است و چون همه‌چیز در فایل‌های از پیش کامپایل‌شده (Wheel) بسته‌بندی شده، نصب روی ویندوز، مک و لینوکس فقط چند ثانیه طول می‌کشد:

pip install polars

برای پروژه‌های جدی، ساختار ایزوله با venv یا ابزارهایی مثل uv پیشنهاد می‌شود تا نسخه کتابخانه قفل بماند. حالا اولین سناریوی واقعی: فروش یک فروشگاه را در فایل CSV دارید و می‌خواهید جمع فروش بالاتر از ۱۰۰ تومان را شهر‌به‌شهر ببینید:

import polars as pl

df = pl.read_csv("sales.csv")

report = (
    df.filter(pl.col("amount") > 100)
      .group_by("city")
      .agg(pl.col("amount").sum().alias("total"))
      .sort("total", descending=True)
)

print(report.head(5))

در این چند خط، pl.col("amount") یک بیانگر (Expression) است؛ یعنی به جای انتخاب ستون و سپس فیلتر کردن آن، کل منطق به موتور سپرده می‌شود تا بهینه اجرا کند. تابع .agg() هم مثل Pandas گروه‌بندی را با توابع تجمیعی تکمیل می‌کند، اما زنجیره‌سازی بیانگرها در Polars خواناتر و خطا‌گیرانه‌تر است. اگر از نسخه‌های قدیمی کتابخانه مهاجرت می‌کنید، دقت کنید نام groupby در نسخه‌های جدید به group_by تغییر کرده است.

Lazy Execution؛ قلب تپنده سرعت در Polars

مهم‌ترین قابلیتی که Polars را از رقبایش جدا می‌کند، اجرای تنبل یا Lazy است. در این حالت، هیچ خطی از کد فوراً اجرا نمی‌شود؛ در عوض یک نقشه راه (Query Plan) می‌سازید، بهینه‌ساز کل نقشه را بازنویسی می‌کند و فقط وقتی .collect() صدا بزنید، همه‌چیز یک‌جا و چندهسته‌ای اجرا می‌شود:

query = (
    pl.scan_parquet("sales.parquet")
      .filter(pl.col("amount") > 100)
      .group_by("city")
      .agg(pl.col("amount").sum().alias("total"))
      .sort("total", descending=True)
)

print(query.explain())    # نمایش نقشه اجرای بهینه‌شده
result = query.collect()  # اینجا و فقط اینجا اجرا می‌شود

دستور .explain() را جدی بگیرید؛ با خواندن خروجی‌اش دقیقاً می‌فهمید بهینه‌ساز چه کارهایی با کد شما کرده است. تفاوت کلیدی با حالت عادی (Eager) این است که در حالت Lazy، Polars می‌تواند فیلتر را داخل همان مرحله خواندن فایل Parquet بفرستد و فقط سطرهای لازم را از دیسک بخواند؛ کاری که در اجرای فوری مرحله‌به‌مرحله تقریباً غیرممکن است.

کار با داده بزرگ؛ CSV، Parquet و Streaming

Polars از CSV، JSON، Parquet و دیتابیس‌های SQL خواندن می‌کند و در هر کدام غافلگیری‌های خودش را دارد. برای CSV سرعت خواندن خوب است، اما اگر داده تکراری و حجیم است، تبدیل به Parquet تقریباً همیشه جواب می‌دهد: هم فشرده‌تر است، هم چون ستونی است فقط ستون‌های موردنیاز خوانده می‌شوند. در حالت Lazy هم می‌توانید بخشی از پردازش را به شکل Streaming اجرا کنید تا فایل بزرگ‌تر از حافظه RAM را قطعه‌قطعه پردازش کنید، بدون آنکه کل داده یک‌جا در حافظه جا بگیرد.

یک قاعده سرانگشتی سالم این است: تا داده با فشرده‌سازی معقول در RAM جا می‌شود، از حافظه استفاده کنید چون سریع‌ترین حالت است؛ وقتی از RAM رد شدید، سراغ Streaming یا موتورهای خارج‌حافظه‌ای مثل DuckDB بروید.

مقایسه Polars با Pandas و DuckDB

انتخاب ابزار بدون مقایسه معنا ندارد. سه رقیب نزدیک را با معیار روشن کنار هم می‌گذاریم:

معیار	Polars	Pandas	DuckDB
زبان هسته	Rust	Cython / پایتون	C++
رابط کاربری	دیتافریم + بیانگر پایتونی	دیتافریم پایتونی	SQL درون‌فرآیندی
اجرا	چندهسته‌ای، Lazy و Eager	عمدتاً تک‌رشته‌ای و Eager	بهینه‌ساز SQL، وکتوریزه
داده بزرگ‌تر از RAM	Streaming در حالت Lazy	محدود، نیازمند ابزار کمکی	خارج حافظه، بسیار قوی
زیست‌بوم	رشد سریع، یکپارچگی با Arrow	بزرگ‌ترین جامعه و منبع آموزشی	اکوسیستم SQL و BI
مناسب برای	ETL و تحلیل سنگین پایتونی	تحلیل تعاملی و یادگیری	کوئری SQL روی فایل‌ها

تصمیم ساده می‌شود این: اگر کدتان پایتونِ محض است و سرعت می‌خواهید، Polars؛ اگر با SQL راحت‌ترید و می‌خواهید مستقیم روی فایل‌های Parquet کوئری بزنید، DuckDB؛ و اگر به کتابخانه‌ای وابسته‌اید که فقط Pandas می‌فهمد، همان Pandas. خوشبختانه Polars با .to_pandas() و pl.from_pandas() مسیر رفت‌وبرگشت تمیزی دارد، اما یادتان باشد این تبدیل‌ها نسخه‌برداری از داده هستند و اگر وسط یک زنجیره Lazy بارها تکرار شوند، مزیت سرعت را می‌بلعند.

سناری‌های واقعی استفاده از Polars

کجا Polars واقعاً خودش را نشان می‌دهد؟ اولین و پرتکرارترین سناریو، پایپ‌لاین‌های ETL است؛ خواندن فایل‌های خام، پاکسازی، تبدیل و نوشتن خروجی. همینجا ترکیبش با ابزارهای زمان‌بندی جواب می‌دهد؛ مثلاً در آموزش Prefect در پایتون که جریان کار خودکار را راه انداخته‌اید، هر تسک پردازش داده می‌تواند یک کوئری Lazy در Polars باشد.

سناریوی دوم، تحلیل لاگ و رویداد است: میلیون‌ها سطر ورودی که باید پنجره‌های زمانی، شمارش تکرار و گروه‌بندی شوند. سناریوی سوم که کمتر به چشم می‌آید، تحلیل خروجی مدل‌های هوش مصنوعی است؛ فرض کنید خروجی‌های متنی تبدیل گفتار به نوشتار را با آموزش Whisper تولید کرده‌اید و حالا می‌خواهید ساعت‌ها فایل صوتی را از نظر طول جملات، کلمات پرتکرار و زمان‌بندی بخش‌بندی کنید؛ Polars با همین حجم داده روی یک لپ‌تاپ معمولی راحت است.

اشتباهات رایج هنگام استفاده از Polars

حلقه روی سطرها: اگر وسط کد Polars حلقه for روی سطر‌ها زدید، عملاً به دوران قبل از برداری‌سازی برگشته‌اید؛ تقریباً هر کاری با بیانگرها و map روی ستون بهتر است.
collect زودهنگام: در حالت Lazy هر .collect() یعنی یک اجرای کامل؛ اگر وسط زنجیره چند بار اجرا کنید، بهینه‌ساز فرصت بازنویسی کل مسیر را از دست می‌دهد.
اصرار بر CSV: خواندن CSV بزرگ بدون تبدیل به Parquet، گلوگاه دیسک می‌سازد؛ یک بار تبدیل کنید و بارها با هزینه ناچیز بخوانید.
رفت‌وبرگشت بی‌رویه با Pandas: تبدیل وسط کار به دیتافریم Pandas و برگشتن به Polars، کپی حافظه است؛ فقط لبه‌های پروژه تبدیل کنید.
نادیده گرفتن نسخه‌ها: API در نسخه‌های اولیه تغییر نام‌هایی مثل groupby به group_by داشته؛ نسخه را قفل کنید و مستندات همان نسخه را بخوانید.

سوالات متداول

آیا Polars جایگزین کامل Pandas می‌شود؟

برای کارهای محاسباتی، ETL و داده بزرگ تقریباً بله؛ اما زیست‌بوم Pandas آن‌قدر بزرگ است که کتابخانه‌های زیادی همچنان خروجی Pandas می‌خواهند. مسیر واقع‌بینانه این است: پردازش سنگین با Polars، تحویل نهایی در صورت نیاز با Pandas.

برای چه حجم داده‌ای سراغ Polars برویم؟

از همان صد مگابایت اول Polars خودش را نشان می‌دهد و نقطه طلایی‌اش جایی است که Pandas کند یا پرمصرف شده اما پایگاه‌داده بزرگ به‌صرفه نیست. برای فایل‌های خیلی بزرگ‌تر از RAM هم حالت Streaming را فراموش نکنید.

چه زمانی DuckDB را به Polars ترجیح دهیم؟

وقتی تیم شما زبان SQL را ترجیح می‌دهد، باید مستقیم روی فایل‌های Parquet یا جداول دیتابیس کوئری بزنید، یا به موتور SQL سبک و درون‌فرآیندی برای ابزار BI نیاز دارید. این دو رقیب هم‌خانواده‌اند و می‌توانند کنار هم استفاده شوند.

آیا Polars رایگان است و از چه نسخه‌هایی از پایتون پشتیبانی می‌کند؟

بله، Polars کاملاً متن‌باز با مجوز MIT است و از نسخه‌های پشتیبانی‌شده‌ی پایتون (۳.۹ به بالا) روی پلتفرم‌های اصلی کار می‌کند؛ نصبش هم از طریق pip یا uv در چند ثانیه انجام می‌شود.

جمع‌بندی

Polars همان حد وسط میان Pandas سبک و دیتابیس‌های تحلیلی سنگین است: سرعت Rust، سادگی پایتون و انعطاف یک موتور کوئری واقعی. اگر بخواهیم مسیر ورود را در یک چک‌لیست خلاصه کنیم:

با pip install polars شروع کنید و یکی از اسکریپت‌های Pandasیتان را عیناً بازنویسی کنید.
برای هر داده تکرارشونده، فایل را به Parquet تبدیل کنید.
به‌محض بزرگ شدن پروژه، از scan_* و .collect() و حالت Lazy استفاده کنید.
خروجی .explain() را بخوانید تا ذهن بیانگر‌محورتان جا بیفتد.
حلقه روی سطر را حذف کنید و تبدیل‌های وسط زنجیره را به حداقل برسانید.

یک بعدازظهر وقت بگذارید؛ به‌احتمال زیاد اسکریپت ساعت‌پاسازی‌تان به یک دقیقه‌ای تبدیل می‌شود و جای Pandas در کد روزمره‌تان باریک‌تر خواهد شد.

Polars چیست؟ راهنمای پردازش سریع داده در پایتون