انتشار Polars 2.0

امروز ما Polars 2.0 را ارسال می کنیم. در پست اعلان قبلی، دلیل برآمدگی نسخه را بررسی کردیم. در این پست درباره ویژگی‌های 2.0 بحث خواهیم کرد. اگرچه ما قصد نداشتیم آن را به یک ویژگی بزرگ تبدیل کنیم، اما هنوز هم چیزهای زیادی برای مشتاق شدن وجود دارد.

بیایید نکات مهم این نسخه را مرور کنیم:

Polars 2.0 نقطه علامت گذاری خواهد بود که در آن با SQL به عنوان شهروند درجه یک رفتار خواهیم کرد. پوشش Polars SQL طی چند ماه گذشته به طرز چشمگیری افزایش یافته است. ما می دانیم که در چند سال گذشته در حال ساخت یک موتور جامد بوده ایم. در Polars 2.0، ما می خواهیم آن را برای بارهای کاری بیشتر، از جمله SQL فعال کنیم. برای ایجاد این عملکرد، پیشرفت‌های زیادی را برای بهینه‌ساز و موتور خود ارسال کردیم. نکات برجسته در اینجا به مرتب سازی مجدد می پیوندند، فیلترهای محمول-زیرطرح مشترک و پویا/ فیلترهای شکوفایی بسیار بهتر.

برای مشاهده عملکرد ما در معیارهای معمولی SQL، Polars SQL را بر روی داده‌های مشتق شده از TPC-H و TPC-DS 1 اجرا کردیم و آن را با آخرین نسخه DuckDB (1.5.6)، DuckDB 2.0 آلفا (2.0.0.dev2610011535) و آخرین نسخه (54xlargeasion) (54xlareasion) اجرا کردیم. (16 vCPU، 32 گیگابایت رم) و یک c7a.metal (192 vCPU، 384 گیگابایت رم). هر پرس و جو 5 بار در یک تنظیمات داغ، با یک فرآیند جداگانه در هر پرس و جو و 60 ثانیه تایم اوت اجرا شد. کش فایل بین هر موتور/معیار پاک شد (نه بین پرس و جوها).

برای هر پرس و جو، بهترین را از 5 اجرا در نظر می گیریم، و موتورها را بر اساس مجموع و میانگین هندسی آن زمان های پرس و جو مقایسه می کنیم.

داده ها با پارکت tpcgen-cli که از منبع در commit 99bedae کامپایل شده است، تولید می شود. ما اندازه‌های گروه ردیف پیش‌فرض tpcgen-cli را بررسی کردیم و تأیید کردیم که تقریبا مشابه آنچه Polars scan_csv از طریق sink_parquet و Duckdb COPY لوله‌گذاری می‌کند، هستند. پرس و جوهای SQL با tpch_queries() و tpcds_queries() DuckDB 1.5.6 ایجاد شدند. داده ها در EBS ذخیره شدند.

نمودارهای زیر زمان اجرای هر موتور را بر حسب ثانیه نشان می‌دهند (کمتر بهتر است)، تقسیم بر اساس ماشین.

Polars و هر دو نسخه DuckDB همه پرس و جوها را تکمیل کردند. زمان DataFusion در TPC-DS q72 (و یک بار در q67) تمام شد و حافظه آن در TPC-H q18 در c7a.4xlarge تمام شد. این پرسش‌ها برای همه موتورها از نتایج بالا حذف می‌شوند.

مشاهده می کنیم که Polars پیش فرض در همه معیارها به جز یک معیار سریعترین است. هنگامی که ما به 192 رشته مقیاس می کنیم، Polars یک سربار ثابت دارد، که به پرس و جوهای داده کوچک آسیب می رساند. در واقع می بینیم که Polars محدود به 32 هسته در همه معیارها رقابتی یا برنده است. ما علت را در نهایت تشخیص داده ایم و امیدواریم در نسخه بعدی این مشکل را برطرف کنیم. اطلاعات بیشتر در مورد معیارها را می توانید در پیوست پیدا کنید. ما شما را تشویق می‌کنیم که نتایج ما را تکرار کنید و یک مخزن برای این معیار در اینجا به اشتراک گذاشته‌اید: https://github.com/pola-rs/polars-2.0-benchmark.

این یکی از بزرگترین تغییرات تاثیر 2.0 است. فراخوانی جمع‌آوری در LazyFrame اکنون به موتور استریم پیش‌فرض تبدیل می‌شود که منجر به بهبود عملکرد و حافظه گسترده در اکثر درخواست‌ها می‌شود. دلیل اینکه این نیاز به یک نسخه عمده دارد این است که موتور استریم به طور پیش‌فرض ترتیب ردیف را برای عملیات خاص (join، group_by، unpivot و غیره) تضمین نمی‌کند. اگر در این عملیات به ترتیب ردیف قابل مشاهده نیاز دارید، می توانید با تنظیم maintenance_order=True در آن شرکت کنید.

خارج از هسته (نشت به دیسک) اکنون به طور پیش فرض فعال است. شروع به ریختن در 80% رم می کند (این ممکن است نیاز به تنظیم داشته باشد). عملیات‌هایی که در این لحظه از هسته پشتیبانی می‌کنند (مرتب‌سازی، توابع پنجره، بسیاری از عبارات) اکنون می‌توانند شروع به ریختن روی دیسک برای تکمیل یک پرس و جو کنند. بودجه دیسک پیش فرض 64 گیگابایت است. در زمان آتی، غیر هسته ای را برای پیوستن ها و گروه ها نیز فعال خواهیم کرد.

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

Polars اکنون از Arrow MapType مستقیما به عنوان dtype نقشه قطبی پشتیبانی می کند. می توانید نقشه را به عنوان یک فرهنگ لغت پایتون در نظر بگیرید که کلیدها را به مقادیر نگاشت می کند. قبل از نسخه 2.0، Arrow MapType در Polars به ​​صورت List خوانده می شد(ساختار({"key": ...، "value": ...})).

به عنوان یک dtype پشتیبانی شده، نوع نقشه اکنون دارای عبارات اختصاصی است، مانند جستجوی کلید، تکرار روی مقادیر و سایر روش‌های مشابه فرهنگ لغت.

قطبی قصد دارد سخت گیر باشد و سریع شکست بخورد. خطاها به طور ایده‌آل باید از قبل بالا بروند، نه 20 دقیقه در خط لوله. رفتار ضمنی در مورد عدم تطابق داده‌ها باید انتخابی باشد، نه پیش‌فرض، زیرا این عدم تطابق‌ها می‌توانند باگ‌ها را پنهان کنند. این سختگیری با افزایش توسعه مبتنی بر هوش مصنوعی ارزشمندتر شده است. Agent ها می توانند با فراخوانی collect_schema() ساختار یک پرس و جو را زودهنگام تأیید کنند، که انواع را برطرف می کند و عدم تطابق در سطح طرحواره را بدون تحقق هیچ داده ای می گیرد. این بازخورد سریع را تضمین می کند، به این معنی که عوامل و انسان ها می توانند سریعتر تکرار کنند.

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

ما بسیار هیجان زده هستیم که Polars 2.0 منتشر شده است. ماه‌های آینده در جاده‌ها پیشرفت خواهیم کرد. خارج از هسته بهتر، مقیاس‌بندی بهتر در تعداد پردازنده‌های بزرگ و در Polars Cloud هدف ما این است که سریع‌ترین موتور توزیع‌شده موجود باشیم. ما همچنین کار روی GeoPolars را شروع کردیم و امیدواریم به زودی اخبار بیشتری در این مورد ارائه کنیم. اگر مشکلی در نسخه جدید ما پیدا کردید، لطفا یک شماره را باز کنید: https://github.com/pola-rs/polars/issues . و در نهایت، برای کمک به شما در ارتقاء به 2.0، راهنمای مهاجرت را ارسال کرده ایم.

اعداد مطلق (بر حسب ثانیه) در زیر آمده است. عدد پررنگ سریعترین موتور در هر ردیف است. هرچه سایه تیره تر باشد، موتور کندتر با سریع ترین موتور مقایسه می شود. Polars با 32 رشته فقط روی c7a.metal اجرا شد.

قطبی ها همچنین با هسته های بیشتر در داده های بزرگتر به خوبی مقیاس می شوند. حرکت از 16 به 192 vCPU در SF100، Polars را 3.8 برابر در TPC-H و 2.2 برابر در TPC-DS (بر اساس مجموع)، در مقایسه با 3.2x و 1.9x برای DuckDB 1.5.6، 2.2x و 1.5x، و 1.0x برای Duck، و 1.0x، و 1.0x. برای DataFusion. در SF10، هسته‌های اضافی به Polars در تنظیمات پیش‌فرض کمک نمی‌کنند: در TPC-H به همان اندازه سریع و در TPC-DS 1.8 برابر کندتر است، در حالی که DuckDB 1.5.6 هنوز هم 1.8 برابر و 1.3 برابر سریع‌تر است. قطبی با 32 رشته فقط روی c7a.metal اجرا می شد، بنابراین بخشی از این مقایسه نیست.

این معیارها از معیارهای TPC-H و TPC-DS مشتق شده‌اند و به این ترتیب، نتایج به‌دست‌آمده با نتایج محک منتشر شده TPC-H و TPC-DS قابل مقایسه نیستند، زیرا نتایج به‌دست‌آمده با معیارهای TPC-H و TPC-DS مطابقت ندارد. ↩ ↩ 2