كلاهما يقدم مجموعة واسعة من الأدوات والمزايا التي قد تجعلنا نشك في أي منهما سنختار في مرحلة ما. لا يتعلق الأمر بتغيير جميع عمليات الشركة بحيث تبدأ في استخدام Polars أو "الموت" للباندا (وهذا لن يحدث في المستقبل القريب). يتعلق الأمر بمعرفة الأدوات الأخرى التي يمكن أن تساعدنا في تقليل التكاليف والوقت المستغرق في العمليات، والحصول على نفس النتائج أو نتائج أفضل.

عندما نستخدم الخدمات السحابية، فإننا نعطي الأولوية لعوامل معينة، بما في ذلك تكلفتها. الخدمات التي أستخدمها في هذه العملية هي AWS Lambda مع وقت تشغيل Python 3.10 وS3 لتخزين الملف الخام والملف المحول من الباركيه.

القصد هو الحصول على ملف CSV كبيانات أولية ومعالجته باستخدام الباندا والقطبية بهدف التحقق من أي من هاتين المكتبتين توفر لنا تحسينًا أفضل للموارد مثل الذاكرة ووزن الملف الناتج.

الباندا
هي مكتبة بايثون متخصصة في معالجة البيانات وتحليلها، وهي مكتوبة بلغة C وإصدارها الأولي كان في عام 2008.

*القطبية *
هي مكتبة Python and Rust متخصصة في معالجة البيانات وتحليلها وتتيح العمليات المتوازية ومكتوبة في الغالب بلغة Rust وتم إصدارها في عام 2022.

بنية العملية:

المشروع بسيط إلى حد ما كما هو موضح في البنية: يقوم المستخدم بإيداع ملف CSV في العمل/pandas أو العمل/porlas ويبدأ تلقائيًا مشغل s3 لمعالجة الملف لتحويله إلى باركيه وإيداعه في المعالجة.

في هذا المشروع الصغير، استخدم اثنين من لامدا بالتكوين التالي:
الذاكرة: 2 جيجابايت
الذاكرة المؤقتة: 2 جيجابايت
مدة الحياة: 600 ثانية

متطلبات
لامدا مع الباندا: الباندا، نومبي وبيارو
لامدا مع القطبية: القطبية

مجموعة البيانات المستخدمة للمقارنة متاحة على kaggle تحت اسم "مراجعات أفلام Rotten Tomatoes - 1.44 مليون صف" أو يمكن تنزيلها من هنا.

المستودع الكامل متاح على GitHub ويمكن استنساخه هنا.

الحجم أو الوزن
يتطلب lambda الذي يستخدمه Pandas مكونين إضافيين لإنشاء ملف باركيه، وهو في هذه الحالة PyArrow وإصدار محدد من numpy لإصدار Pandas الذي كنت أستخدمه. ونتيجة لذلك، حصلنا على لامدا بوزن أو حجم 74.4 ميجابايت، وهو شيء قريب جدًا من الحد الذي تسمح لنا به AWS لوزن لامدا.

لا يتطلب lambda المزود بـ Polars مكونًا إضافيًا آخر مثل PyArrow مما يجعل الحياة أسهل ويقلل حجم lambda إلى أقل من النصف. ونتيجة لذلك، يبلغ وزن أو حجم لامدا الخاص بنا 30.6 ميجابايت مقارنة بالأول، مما يمنحنا مساحة لتثبيت التبعيات الأخرى التي قد نحتاجها لعملية التحويل لدينا.

أداء

تم تحسين Lamda مع Pandas لاستخدام الضغط بعد الإصدار الأول، ومع ذلك، تم تحليل سلوكها أيضًا.
الباندا
استغرقت معالجة مجموعة البيانات 18 ثانية واستخدمت 1894 ميجا بايت من الذاكرة لمعالجة ملف CSV وإنشاء ملف Parquet مقارنة بالإصدارات الأخرى، وكانت هي النسخة التي استخدمت أكبر قدر من الوقت والموارد.

ضغط الباندا
أتاحت لنا إضافة سطر من التعليمات البرمجية تحسينًا طفيفًا مقارنة بالإصدار السابق (Pandas)، فقد استغرقت معالجة مجموعة البيانات 17 ثانية واستخدمت 1837 ميجابايت، وهو ما لا يمثل تحسنًا كبيرًا في المعالجة والوقت الحسابي، ولكن في الحجم. من الملف الناتج.

القطبية
استغرق الأمر 12 ثانية لمعالجة نفس مجموعة البيانات واستخدمت 1462 ميجابايت فقط، مقارنة بالاثنين السابقين، وهو ما يمثل توفيرًا للوقت بنسبة 44.44% واستهلاكًا أقل للذاكرة.

حجم ملف الإخراج

الباندا
تم إنشاء ملف lambda الذي لم يتم إنشاء عملية ضغط فيه، ملف باركيه بحجم 177.4 ميجابايت.

ضغط الباندا
عند تكوين الضغط في لامدا، لا أقوم بإنشاء ملف باركيه بحجم 121.1 ميجابايت. ساعدنا سطر أو خيار صغير واحد على تقليل حجم الملف بنسبة 31.74%. وبالنظر إلى أنه ليس تغييرا كبيرا في التعليمات البرمجية، فهو خيار جيد للغاية.

القطبية
قام Polars بإنشاء ملف بحجم 105.8 ميجا بايت، والذي تم شراؤه مع الإصدار الأول من Pandas، يمثل توفيرًا بنسبة 40.36% و12.63% مقارنة بإصدار Pandas مع الضغط.

خاتمة
ليس من الضروري تغيير جميع العمليات الداخلية التي تستخدم Pandas بحيث تستخدم Polars الآن، ومع ذلك، من المهم مراعاة أنه إذا كنا نتحدث عن آلاف أو ملايين عمليات تنفيذ Lamda، فإن استخدام Polars سيساعدنا ليس فقط في النشر الوقت ولكنه سيساعدنا أيضًا في الحصول على تكلفة أقل نظرًا للرسوم المستندة إلى الوقت التي تفرضها AWS مقابل الخدمات بدون خادم مثل Lambda.
وبالمثل، عندما نترجم نسبة 40.36% إلى ملايين الملفات، فإننا نتحدث عن وحدات الجيجابايت أو التيرابايت، وهو أمر من شأنه أن يكون له تأثير كبير داخل Datalake أو Dataware house أو حتى في مخزن الملفات البارد.

لن يقتصر التخفيض مع Polars على هذين العاملين فقط، لأنه سيؤثر بشكل كبير على إخراج البيانات و/أو الكائنات من AWS لأنها خدمة لها تكلفة.