نسخهٔ پیش‌انتشار Polars 2.0 پیش‌فرض اجرای LazyFrameها را به «موتور استریمینگ» تغییر داده که در بسیاری از سناریوها سرعت را تا پنج برابر افزایش و مصرف حافظه را کاهش می‌دهد. با این حال، اجرای بچ‌محور می‌تواند ترتیب سطرهای خروجی را تغییر دهد و برای کدهایی که به ترتیب مشخص وابسته‌اند مشکل‌ساز شود.

موتور استریمینگ چیست و چرا سریع‌تر است

موتور استریمینگ کوئری‌های Lazy را به‌صورت بچ‌به‌بچ اجرا می‌کند به‌جای بارگذاری کامل داده‌ها در حافظه. نتیجه قابلیت اجرا روی مجموعه‌داده‌های بزرگ‌تر، کاهش مصرف حافظه و تسریع پردازش است. تیم توسعهٔ Polars در مستندات میزان بهبود را در بسیاری از موارد «تا ۵ برابر» گزارش کرده است. مستندات رسمی و کد پروژه در گیت‌هاب Polars موجود است.

نمایی مرتبط با Polars و پردازش جدول‌های داده

هشدار مهم: ترتیب سطرها ممکن است تغییر کند

موتور استریمینگ در برخی عملیات ترتیب سطرها را تضمین نمی‌کند. عملیات‌هایی مانند join، group_by و unpivot بیش از سایرین در معرض تغییر ترتیب قرار دارند. تیم توسعه این ریسک را در راهنمای مهاجرت 2.0-rc برجسته کرده است و تأکید داشته که تغییر ترتیب ممکن است بدون هشداری نتایج پایپ‌لاین‌های موجود را تغییر دهد.

کاهش ریسک تغییر ترتیب

برای محافظت از خروجی‌هایی که به ترتیب مشخص نیاز دارند، از رویکردهای زیر استفاده کنید:

  • مرتب‌سازی صریح: بعد از مرحله‌ای که به ترتیب نیاز دارید، به‌صورت صریح از sort استفاده کنید تا ترتیب قطعی شود (مثلاً df.sort("col")).
  • استفاده از maintain_order=True: در جاهایی که این پارامتر ارائه شده، آن را فعال کنید تا Polars تلاش کند ترتیب را حفظ کند. توجه داشته باشید که فعال‌سازی این گزینه ممکن است کارایی و صرفه‌جویی در حافظه را کاهش دهد.
  • نگهداری موتور درون‌حافظه‌ای: اگر نیاز دارید رفتار قبلی کاملاً حفظ شود، می‌توانید پیش‌فرض اجرای LazyFrame را به حالت درون‌حافظه‌ای برگردانید یا engine affinity را تنظیم کنید تا از موتور قدیمی استفاده شود.

چک‌لیست مهاجرت

  • اجرای کامل تست‌های واحد و انتگرال برای شناسایی بخش‌های وابسته به ترتیب خروجی.
  • نشانه‌گذاری مراحل حساس به ترتیب در کد و افزودن دستور صریح sort یا فعال‌سازی maintain_order=True.
  • ارزیابی تاثیر عملکرد و حافظه پس از اعمال تغییرات؛ در صورت نیاز، آزمایش حالت درون‌حافظه‌ای برای بخش‌های حیاتی.
  • مستندسازی هر تغییر در رفتار خروجی برای تیم مصرف‌کنندهٔ داده (تأیید قراردادهای خروجی).

سایر تغییرات و بهبودها در 2.0

نسخهٔ 2.0 تنها تغییر موتور را شامل نمی‌شود؛ اصلاحاتی در API و سخت‌گیری بیشتر در تبدیل نوع‌ها نیز اعمال شده که استفادهٔ واضح‌تر از توابع تبدیل رشته به تاریخ/زمان مانند .str.to_date() و .str.to_datetime() را تشویق می‌کند. برنامه‌های آینده شامل بهبودهای IO (از جمله خوانندهٔ سریع‌تر برای S3)، برنامه‌ریز مبتنی بر هزینه، بازآرایی عملیات join و توسعهٔ پوشش SQL است.

نکتهٔ عملی برای توسعه‌دهندگان

اگر قصد آزمایش نسخهٔ نامزد 2.0 را دارید، ابتدا مجموعهٔ تست‌ها و پایپ‌لاین‌های خود را اجرا کرده و بخش‌هایی که به ترتیب وابسته‌اند را مشخص کنید. مزایای کارایی و صرفه‌جویی در حافظه ارزش بررسی دارند، اما تضمین سازگاری خروجی باید در فرایند مهاجرت گنجانده شود.

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