بولارز 2.0 يدعي أنه أسرع بـ 5 مرات... فما الذي تغير؟

BBetter Stack
컴퓨터/소프트웨어AI/미래기술

스크립트

00:00:00المنافس الأكبر لمكتبة Pandas على وشك إطلاق الإصدار 2.0.
00:00:04تحديث Polars أوشك على الوصول، ولعل التغيير الأكبر ليس ما تتوقعه.
00:00:09افتراضيًا، ينتقل كل استعلام كتبته سابقًا إلى محرك مختلف.
00:00:14دون أن تغير سطرًا واحدًا.
00:00:15كما تتوقف Polars عن ضمان عودة الصفوف بنفس الترتيب الذي أدخلتها به.
00:00:19قد يبدو هذا تراجعًا، رغم أنه ليس كذلك، بل هو ثمن إتاحة التغيير الأول.
00:00:24مع كسب Polars للمزيد من الزخم بالإصدار 2.0، أصبحت تنافس Pandas بقوة.
00:00:30دعونا نلقي نظرة على أضخم تحديث حتى الآن.
00:00:37حسناً، منذ البداية، كانت Pandas الخيار الأساسي لمعظم أعمال البيانات.
00:00:43إنها بسيطة ويستخدمها الجميع، ولا تقتصر على تحليل البيانات فحسب، بل تُعد أساسية في تعلم الآلة أيضًا.
00:00:49ثم ظهرت Polars منذ فترة.
00:00:51وكانت دائمًا أسرع من Pandas.
00:00:53وسنتحدث عن ذلك.
00:00:54والآن مع هذا التحديث الرئيسي 2.0، قد تقترب أكثر من الاعتماد الواسع.
00:01:00بما أنكم عرفتم الخلفية السريعة، فقد احتوت Polars بهدوء على محركين لفترة من الوقت.
00:01:05المحرك الذي كان معظم الناس يستخدمونه هو المحرك المعتمد على الذاكرة (in-memory).
00:01:08يمكنك تخيله كمستودع.
00:01:10فهو يحمل كامل مجموعة البيانات على أرضية المستودع، ثم ينفذ كل خطوة من الاستعلام عبر الأرضية بأكملها.
00:01:17وهذا سريع للغاية.
00:01:19طالما يتسع كل شيء في ذاكرة الوصول العشوائي (RAM).
00:01:21أما محرك التدفق (streaming engine) فيعمل بشكل مختلف.
00:01:23فبدلاً من أرضية واحدة عملاقة، أصبح أشبه بَخط تجميع.
00:01:27تقوم Polars بتقطيع البيانات إلى أجزاء صغيرة يطلق عليها المطورون اسم Marcels.
00:01:32وهذه الأجزاء مصممة لتناسب حجم الذاكرة المخبئية (CPU cache).
00:01:36ثم يتم تمريرها عبر خطة الاستعلام.
00:01:39الآن، يمكن لأجزاء مختلفة من الاستعلام المتابعة بدلاً من الانتظار لحين تحميل كامل مجموعة البيانات.
00:01:43وهنا تكمن السرعة.
00:01:44وفي النهاية، هذا هو الطريق نحو التعامل مع بيانات أكبر من حجم الذاكرة.
00:01:49ولكن هناك شرط.
00:01:50إذا كان لديك ثمانية عمال على خط التجميع، فلن ينهوا العمل بالضرورة بنفس الترتيب الذي بدأوا به.
00:01:56وكذلك الأمر بالنسبة لـ Polars.
00:01:58لذا في الإصدار 2.0، عمليات الدمج (joins)، التجميع (group buys)، وإلغاء المحور (unpivots)، تذكر الوثائق بالنص الخ...
00:02:04لم تعد تضمن ترتيب الصفوف.
00:02:06ما لم تطلب ذلك صراحة.
00:02:08إذا كنت تستمتع ببرمجة الأدوات لتسريع سير عملك، احرص على الاشتراك.
00:02:11لدينا مقاطع فيديو تنزل باستمرار.
00:02:13حسنًا، إليك كيف يبدو هذا عمليًا.
00:02:15سأقوم بتثبيت uv pip install pre-polars.
00:02:18وتذكر خيار pre-- هذا.
00:02:20سنعود إليه بعد قليل.
00:02:22حسناً.
00:02:22لدي إطار بيانات كسول (lazy frame) مع المفاتيح 210.
00:02:27أقوم بعمل دمج يساري (left join) مع إطار آخر، ثم ينفّذ بـ collect.
00:02:32وانظر إلى النتيجة.
00:02:34نفس الكود كما في Polars 1.
00:02:35لكن الترتيب لم يعد مضمونًا.
00:02:37نفس الكود، لكنه يتصرف بشكل مختلف.
00:02:39الآن أضيف maintain_order = “left” إلى عملية الدمج.
00:02:43أستطيع تشغيله مجددًا.
00:02:44سأشغله هنا مرة أخرى.
00:02:45وقد عاد الترتيب الأصلي.
00:02:47إذن، هذا ليس خلطًا عشوائيًا للبيانات من جانب Polars.
00:02:51بل تقول Polars: إذا كان الترتيب يهمك، فعليك إخبارها.
00:02:54يجب عليك إخبارها صراحة.
00:02:56وهناك تفصيل لطيف آخر هنا.
00:02:58شغّل دالة explain على استعلام ما.
00:03:01إنها لا تخفي هذا السلوك.
00:03:03عليك فقط أن تعرف أين تبحث عنه.
00:03:05هذا هو التغيير السلوكي الكبير.
00:03:06لكن الإصدار 2.0 غريب لأنه ليس إصدارًا لميزات جديدة حقًا.
00:03:10بل هو مجرد تنظيف وترتيب.
00:03:12وهناك قدر لا بأس به يتم تنظيفه هنا.
00:03:15في الأصل مثل Pandas، كان لدى Polars دالة read_csv، والتي أصبحت الآن مجرد scan_csv يتبعها collect.
00:03:22وقد أزيلت profile من lazy frame.
00:03:25وأصبحت melt تسمى unpivot.
00:03:28وأصبحت join_nulls تسمى nulls_equal.
00:03:30وتمت إزالة التحويل المباشر للعد الصحيح إلى فئوي (categorical).
00:03:35يمكنك استخدام cat2 الآن للمساعدة في ذلك.
00:03:38كما أزيل تحويل النص مباشرة إلى تاريخ.
00:03:41أي تحويل string إلى date.
00:03:43وعند جمع عدد صحيح بمؤشر وآخر بدون مؤشر بحجم 64-بت، تعطيك Polars الآن int128 بدلاً من تحويله لنوع float وفقدان الدقة بصمت.
00:03:53وهناك المزيد قادم.
00:03:55يمكنك استخدام concat.
00:03:57والتي ترفض الآن الارتفاعات غير المتطابقة بدلاً من تخمين ما تعنيه.
00:04:02وهذا خيار ذكي جدًا من طرف Polars.
00:04:05كل عنصر مُزال يعطي خطأ AttributeRemovedError.
00:04:09والذي يخبرك بالبديل الذي حل محله.
00:04:12استدعِ melt، وسينص الخطأ حرفيًا على استخدام unpivot مع index و on.
00:04:17تصبح كل هذه الأخطاء تقريبًا دليلاً لكيفية الاستخدام الفعلي.
00:04:20شغّل الكود، وإذا حدث عطل، أصلح ذلك العطل بناءً على رسالة الخطأ، وواصل العمل.
00:04:26وهذا يفسر سبب تحول Polars إلى أداة يومية لكثيرين في المقام الأول.
00:04:31تؤجل Pandas الكثير من المشاكل لزمن التشغيل (runtime).
00:04:35بينما تحاول Polars اكتشافها مبكرًا عبر كل هذا.
00:04:37يمكنك استدعاء collect_schema لمعرفة ما إذا كانت الأنواع خاطئة قبل أن تقرأ Polars صفًا واحدًا.
00:04:44إنها تتوقع ما يوشك على الحدوث.
00:04:47وتصبح أكثر كفاءة باستمرار.
00:04:48إذن، أين تقع Polars بالضبط؟
00:04:50حسناً، DuckDB تركز على SQL أولاً.
00:04:53بينما Polars هي واجهة تعابير (expression API) مصممة لباثون.
00:04:56وهناك أيضًا Dask و Spark.
00:04:58وتلك أنظمة موزعة.
00:04:59بينما تركز Polars على جهاز واحد.
00:05:01مكتبة البرمجيات مفتوحة المصدر نفسها مفتوحة المصدر.
00:05:04لكن سحابة Polars ليست كذلك.
00:05:05وهذا الأمر الأساسي يغير الأمور بمجرد نصل إلى الأداء.
00:05:09الآن، يقول هذا الإعلان إن محرك التدفق الجديد أسرع بخمس مرات بسهولة.
00:05:13لقد جربت Polars على مر السنين، ونعم، هي أسرع من Pandas، لكني لم أحصل قط على سرعات خيالية كخمسة أضعاف.
00:05:21جربها على مجموعات بيانات أكبر.
00:05:23ستلاحظ بالتأكيد فارقًا في السرعة.
00:05:25سيتفاوت الأمر مع كل تشغيل ومع كل مجموعة بيانات، لكنك ستشعر بالفارق وتراه عمليًا في زمن التشغيل.
00:05:30وهذا لعلّه أهم تمييز في هذا الإصدار بأكمله.
00:05:34الجزء الذي يسمح للمحرك بتفريغ البيانات على القرص، أي التنفيذ الحقيقي خارج الذاكرة (out-of-core)، لم يصل بعد.
00:05:40لذا، يعني التدفق اليوم أنه مقسم لكتل ومُمرر عبر خط معالجة.
00:05:43ولا يعني بعد أن مجموعة بياناتك يمكن أن تتجاوز الذاكرة بشكل سحري.
00:05:46رقم 5 أضعاف هو مجرد توقعات Polars الخاصة.
00:05:50ولا يوجد جدول قياس أداء (benchmark) في المنشور إطلاقًا.
00:05:53وبصراحة، يبدو أن معظم الناس راضون عن ذلك.
00:05:55يبدو الكثير من المستخدمين سعداء بإصدار مفيد رغم أنه غير مبهر.
00:05:59فلا يوجد ضخ لعدد هائل من الميزات.
00:06:01ولست مضطرًا لتعلم أي شيء جديد.
00:06:02تلك الأخطاء أثناء البرمجة ستخبرك بما يجب أن تستبدله.
00:06:07مجرد معالجة للأعطال، وتنظيف، واستخدام نظام ترقيم الإصدارات (semver) كما ينبغي.
00:06:12لكن هناك شكوان يتكرران باستمرار.
00:06:14الأولى هي ترتيب الصفوف.
00:06:15إذا كانت maintain_order افتراضيًا false، فقد يتسبب ذلك في ثغرات مزعجة بالكود.
00:06:19لأن البرنامج لن يتعطل.
00:06:21وقد تكون أرقامك صحيحة تمامًا.
00:06:23لكنها مرتبطة بالصفوف بترتيب مختلف.
00:06:26وهذا يترصد اكتشافه بصعوبة أكبر بكثير مقارنة باستثناء (exception).
00:06:29والشكوى الثانية كانت استخدام كلمة “تدفق” (streaming) هنا.
00:06:32حيث جادل الناس بأنها مربكة لمُحرك ليس يعمل خارج الذاكرة بشكل حقيقي بعد.
00:06:38ثم هناك أخطاء برمجية فعلية في النسخة المرشحة للإطلاق (RC).
00:06:41منذ وصول النسخة المرشحة، كانت هناك مشكلة عالية الأولوية حيث
00:06:44تلقي group_by_dynamic خطأ “التاريخ والوقت خارج النطاق” في محرك التدفق.
00:06:49استدعِ دالة limit.
00:06:51حسناً، دالة limit لا تخرج مبكراً بعد الدمج (join).
00:06:54وتحويل string إلى datetime قد يعيد قيم فارغة (null) في حين كان يرفع خطأً سابقاً.
00:06:58ولهذا السبب طلبت منك تذكر أمر التثبيت pre.
00:07:02ما قبل 2.0.
00:07:04هذه لا تزال نسخة مرشحة للإطلاق.
00:07:06وفي الوقت الحالي، تتصرف بهذه الصفة.
00:07:08وهذا أمر طبيعي.
00:07:09أليس كذلك؟
00:07:09فهي ليست النسخة النهائية بعد.
00:07:11شيء آخر.
00:07:12حزمة Rust لا تزال في الإصدار 0.55.
00:07:15لذا، إذا كنت تستخدم Polars من لغة Rust، فليس هناك Polars 2.0 لك بعد.
00:07:19لكنني أفترض أن معظمنا هنا سيستخدم باثون فقط.
00:07:24الآن، هل يجب عليك الترقية؟
00:07:25بالنسبة لمشروع جديد، نعم، سأفعل ذلك.
00:07:27أليس كذلك؟
00:07:27نحن نتأقلم مع التقنيات الجديدة والتحديثات الجديدة.
00:07:30إذا كان خط المعالجة لديك يستخدم بالفعل sink_parquet أو sink_csv، فأنت عمليًا تستخدم
00:07:34التدفق طوال هذا الوقت على أي حال.
00:07:36لكن هناك حالات استخدام قليلة قد ننتظر فيها.
00:07:39أليس كذلك؟
00:07:39إذا كان الكود لديك يعتمد على ترتيب الصفوف هذا، فلا تقم بالترقية وتتمنى الأفضل.
00:07:43ابحث عن عمليات group_by التي لا تتبعها عملية فرز.
00:07:47وإذا كنت تستخدم group_by_dynamic، فسأنتظر حتى يستقر كل هذا.
00:07:51وأعني، من الرائع رؤية الاتجاه الذي تتجه إليه الأُمور على الأرجح.
00:07:54سيكون هذا هو الإصدار 2.0 غالباً، لكنه ليس الإصدار الرسمي بعد.
00:07:57يمكنك الاعتياد عليه، ولكنه لم يكتمل تمامًا بعد.
00:08:00الشيء الذي أستمر في التفكير فيه هو مدى غرابة هذا الإصدار.
00:08:03إذ لا يقدم Polars 2.0 أي ميزات جديدة إطلاقًا.
00:08:07ومع ذلك، فهو يغير طريقة عمل الكود الحالي لديك.
00:08:10المحرك الجديد أسرع على جهازي، ولكنه ليس أسرع بخمس مرات.
00:08:14لذا فإن الإصدار 2.0 ليس مثيرًا لأنه يضيف الكثير من الأشياء الجديدة.
00:08:18بل هو مثير لأن Polars تستخدم ترقية إصدار رئيسية لمجرد إعادة ترتيب وتنظيف الأساس
00:08:24تحت كل ما نستخدمه بالفعل.
00:08:26أنا جوش من BetterStack.
00:08:28إذا كنت تستمتع بنصائح وحيل البرمجة مثل هذه، احرص على الاشتراك.
00:08:30ونراكم في فيديو آخر.

핵심 요약

يحول الإصدار Polars 2.0 محرك المعالجة الافتراضي إلى محرك التدفق لزيادة السرعة والتعامل مع البيانات الضخمة، وذلك على حساب التخلي عن ضمان ترتيب الصفوف الافتراضي وتغيير أسماء بعض الدوال الأساسية.

하이라이트

  • ينتقل Polars 2.0 افتراضيًا إلى محرك تدفق جديد يقسم البيانات إلى أجزاء صغيرة تسمى Marcels لتتناسب مع حجم الذاكرة المخبئية للنعالج.

  • تتوقف Polars 2.0 عن ضمان ترتيب الصفوف افتراضيًا في عمليات الدمج والتجميع وإلغاء المحور ما لم يتم تحديد المعلمة maintain_order صراحة.

  • استبدل الإصدار الجديد الدوال القديمة ببدائل صريحة مثل استخدام unpivot بدلاً من melt وnulls_equal بدلاً من join_nulls.

  • تطلق العناصر المزالة خطأ من نوع AttributeRemovedError يشرح البديل الدقيق للوظيفة الملغاة وكيفية إصلاح الكود.

  • لا يقدم Polars 2.0 ميزات جديدة رئيسية بل يركز على إعادة ترتيب وتنظيف الأساس البرمجي وإدارة الأخطاء مبكرًا.

타임라인

التحول إلى محمحرك التدفق وتغيير سلوك الترتيب

  • ينقل Polars 2.0 جميع الاستعلامات تلقائيًا إلى محرك تدفق جديد كليًا.
  • يفقد المحرك الجديد ضمان ترتيب الصفوف الافتراضي في العمليات المعقدة.
  • يعتمد المحرك على تقطيع البيانات إلى كتل Marcels تناسب الذاكرة المخبئية للمعالج.

كان المحرك القديم يعتمد على الذاكرة الكاملة ويحمل البيانات على مساحة واحدة، مما يتطلب سعة RAM كبيرة. يقطع محرك التدفق الجديد البيانات إلى أجزاء صغيرة تتناسب مع حجم الذاكرة المخبئية لمعالج الحاسوب وتُمرر عبر خطة الاستعلام. تسبب معالجة هذه الأجزاء بالتوازي عبر عمال متعددين في فقدان الترتيب الأصلي للصفوف في عمليات مثل الدمج والتجميع.

إدارة الترتيب عمليًا ورسائل الأخطاء التوضيحية

  • استعادة الترتيب الأصلي تتطلب إضافة خيار maintain_order صراحة في الاستعلام.
  • توفر دالة explain رؤية كاملة لخطة تنفيذ الاستعلام وسلوك الترتيب.
  • تغيير سلوك الترتيب ليس خلطًا عشوائيًا بل نتيجة للمعالجة المتوازية.

عند إجابة استعلام دمج يساري في الإصدار الجديد بدون إعدادات إضافية، تتغير أرقام الترتيب مقارنة بالإصدار الأول. يستعيد الكود سلوكه السابق بمجرد تمرير خيارات الترتيب الصريحة للعملية. تتيح أدوات الفحص الداخلي للمطورين معرفة أين يتم إسقاط ضمانات الترتيب داخل خطة التنفيذ.

تنظيف واجهة البرمجة وتوحيد التسميات

  • تم تحويل دالة read_csv إلى مسح كسول يتبعه جمع بيانات عبر scan_csv ثم collect.
  • تغيرت مسميات دوال رئيسية مثل melt إلى unpivot وjoin_nulls إلى nulls_equal.
  • تعيد الدوال المزالة خطأ AttributeRemovedError يوضح البديل المباشر لاستخدامه.

يركز الإصدار على إعادة هيكلة واجهة التطبيق البرمجية وإزالة الاستخدامات القديمة التي تشبه مكتبة Pandas. يمنع النظام الجديد التحويل الضمني المباشر للنصوص إلى تواريخ أو الأعداد الصحيحة إلى فئوية لمنع فقدان الدقة بصمت. تظهر الأخطاء أثناء زمن التشغيل مصحوبة بإرشادات توضح الدالة البديلة المعوضة والمعلمات المطلوبة لتشغيلها.

واقع الأداء وحدود محرك التدفق الحالي

  • ادعاء زيادة السرعة بمقدار 5 أضعاف يمثل تقديرات داخلية دون جداول قياس أداء معلنة.
  • لا يدعم محرك التدفق الحالي التفريغ كاملًا على القرص الصلب خارج الذاكرة.
  • تعتمد Polars على معالجة البيانات على جهاز واحد مقارنة بالأنظمة الموزعة مثل Spark.

تختلف Polars عن DuckDB في تركيزها على واجهة التعبير الخاصة بلغة بايثون بدلاً من SQL. رغم التحسينات في زمن التشغيل مع مجموعات البيانات الكبيرة، فإن ميزة التنفيذ الحقيقي خارج الذاكرة (out-of-core) لم تكتمل بعد في هذا الإصدار. يقتصر مفهوم التدفق حالياً على تقسيم البيانات إلى كتل وتمريرها عبر خط معالجة داخلي.

المشكلات الحالية في النسخة المرشحة وتوصيات الترقية

  • قد يتسبب إلغاء الترتيب الافتراضي في أخطاء صامتة تربط البيانات بصفوف خاطئة.
  • تحتوي النسخة المرشحة للإطلاق على مشكلات برمجية في دوال التجميع الزمني والدوال المحدودة.
  • يُنصح بالتريث في الترقية للمشاريع التي تعتمد على ترتيب الصفوف أو حزمة Rust.

تتضمن النسخة المرشحة للإطلاق أخطاء مثل إرجاع قيم فارغة عند تحويل النصوص إلى تواريخ وأخطاء في نطاقات التاريخ والوقت مع group_by_dynamic. لم تتلق حزمة Rust التحديث بعد وتستقر عند الإصدار 0.55. يُفضل الترقية للمشاريع الجديدة فقط، مع الانتظار للمشاريع القائمة التي تعتمد عملياتها الحسابية على تسلسل الصفوف.

커뮤니티 글

아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!

이 영상에 대해 글쓰기