كمبرمج ، كتب حبات مركز البيانات

يعتقد عدد قليل من الناس أنه لا يمكن بناء مكدس علم البيانات الحديث في بيثون ، ولكن هناك سوابق :). تم تكديس مجموعة Odnoklassniki لسنوات عديدة ، في المقام الأول من قبل المبرمجين الذين تحولوا إلى علم البيانات ، ولكن لا يزالون على مقربة من المنتج ، لذلك فهو يعتمد على التقنيات المفتوحة لمكدس JVM: Hadoop ، Spark ، Kafka ، Cassandra ، إلخ. يساعدنا ذلك في تقليل وقت وتكلفة تشغيل النماذج ، ولكنه في بعض الأحيان يخلق صعوبات. على سبيل المثال ، عند إعداد الحلول الأساسية للمشاركين في SNA Hackathon 2019 ، اضطروا إلى ضغط قوة الإرادة والانغماس في عالم الكتابة الديناميكية. التفاصيل (وسهولة التصيد) تحت خفض :)

التثبيت

هناك نوع من الثعبان على أي آلة تطوير تقريبا. تم العثور عليه على الألغام ، بالفعل في نسختين - 2.7 و 3.4. بعد البحث في صناديق الذاكرة ، تذكرت أنني قمت بتثبيت الإصدار 3.4 قبل ثلاث سنوات ، بعد أن واجه المشاركون مشاكل ملحمية في SNA Hackathon 2016 ، في محاولة لتوسيع رسم بياني نصف غيغابايت في الذاكرة (نتيجة لفيديو تدريبي صغير ومسابقة منفصلة ) ، ولكن اليوم الاقتصاد عفا عليه الزمن بالفعل ويحتاج إلى التحديث.

في عالم Java ، يشير كل مشروع أثناء التجميع إلى كل ما يريد إدماجه في نفسه ، ويستمر في ذلك. من الناحية النظرية ، كل شيء بسيط وجميل ، ولكن في الممارسة العملية ، عندما تحتاج إلى مكتبة A ومكتبة B ، سيتضح بالتأكيد أنهما بحاجة إلى مكتبة C ، بنسختين مختلفتين غير متوافقين :). في محاولات فاشلة لكسر هذه الحلقة المفرغة ، تقوم بعض المكتبات بتعبئة جميع التبعيات في حد ذاتها والاختباء عن الباقي ، بينما تدور الباقي قدر الإمكان.

ما الأمر مع هذا في بيثون؟ لا يوجد مشروع على هذا النحو ، ولكن هناك "بيئة" ، وضمن كل بيئة ، يمكن تشكيل نظام بيئي مستقل من حزم من إصدارات معينة. في الوقت نفسه ، هناك أدوات للكسل ، بمساعدة من أنه لم يعد من الصعب إدارة بيئة بيثون المحلية ، من مجموعة غير متجانسة موزعة من كلودر أو هورتون. لكن التعارض المتبادل بين إصدارات الحزم لن يذهب إلى أي مكان ، لقد واجهت على الفور حقيقة أن إصدار Pandas 0.24 نقل أسلوب _maybe_box_datetimelike الخاص إلى API العامة ، وفجأة تبين أن الكثير من الناس قد استخدموه في شكله السابق وتراجعوا الآن :) (ونعم ، في عالم جافا هو نفسه ). ولكن في النهاية ، تم إصلاح كل شيء ، بصرف النظر عن التحذيرات الرهيبة حول depriycheyshin جديدة ، نجحت.

خط الأساس التعاوني

تنقسم المهام في SNA Hackathon 2019 إلى ثلاثة مجالات - توصيات حول السجلات والنصوص والصور. دعنا نبدأ مع سجلات (المفسد - megapattern Cmd + C / Cmd + V مع stackoverflow يعمل أيضا مع الثعبان). تم جمع البيانات من الإنتاج المباشر - كل مستخدم بشكل عشوائي ، دون وزن ، تم عرض بعض الخلاصات من بيئته ، وبعد ذلك تم تسجيل جميع العلامات في وقت العرض ورد الفعل النهائي في السجل. مهمة قطعة الكعكة: نأخذ علامات ، نحن نطلق العنان للربح!

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

ولكن كانت هناك جوانب إيجابية. كان Jupyter ، بشكل عام ، سعيدًا ، فهو مريح تقريبًا ، رغم أنه ليس جميلًا مثل Zeppelin . هناك حتى جوهر الصخور ! حسنًا ، لقد سررت سرعة الانحدار اللوجستي على جزء صغير من البيانات في الذاكرة - لا تصل إلى قوة الخيار الموزع ، لكنها تتعلم على الفور على أربع علامات ومئات الآلاف من الأمثلة.

ومع ذلك ، فإن الحماس الذي نشأ تأثر بشدة: إذا لم يكن تحويل البيانات الضروري (تجميع حسب المفتاح وتجميعه في قائمة) في القائمة القياسية وتطبيق أو تظهر الخريطة ، فإن السرعة تنخفض بأوامر من حيث الحجم. ونتيجة لذلك ، فإن 80٪ من وقت الأساس لا يقوم بقراءة البيانات ، والانضمام ، والتدريب النموذجي والفرز ، ولكن التجميع العادي للقائمة.

بالمناسبة ، بسبب هذه الميزة بالتحديد ، أشعر بالدهشة دائمًا لدى مستخدمي pySpark - بعد كل شيء ، تتوفر جميع الوظائف القياسية تقريبًا في شكل Spark SQL ، وهو نفسه في python و rock ، وبعد أول yudf-like python مع شيء شخصي ذو عشرة نواة يتحول الكتلة إلى اليقطين ...

لكن في النهاية ، تم التغلب على جميع العقبات وكانت تسع نقاط كافية لتسجيل 0.65!

النص الأساسي

حسنًا ، أصبحت مهمتنا الآن أكثر تعقيدًا - إذا كان من الممكن العثور على السجل في مئات التطبيقات لجميع المنصات ، فهناك مجموعة متنوعة من الأدوات للعمل مع النصوص تحت الثعبان. لحسن الحظ ، يتم إرسال النصوص بالفعل ليس فقط في شكل أولي ، ولكن أيضًا تتم معالجتها بواسطة نظام المعالجة المسبق المعتاد لدينا استنادًا إلى Spark و Lucene . لذلك ، يمكنك أن تأخذ على الفور قائمة الرموز ولا تقلق بشأن رمزية / lematization / stemming.

لبعض الوقت كنت أشك في ما يجب اتخاذها: BigARTM المحلية أو Gensim المستوردة. نتيجة لذلك ، استقرت في الثاني ونسخت البرنامج التعليمي doc2vec :). آمل ألا يفشل الزملاء من فريق BigARTM في اغتنام الفرصة وإظهار مزايا مكتبتهم في المسابقة.

لدينا مرة أخرى خطة بسيطة: نأخذ جميع النصوص من الاختبار ، ندرب نموذج Doc2Vec ، ثم نستنتجه في القطار ونتعرف على logreg في نتائجه (التراص هو كل شيء لدينا!). ولكن ، كالعادة ، بدأت المشاكل على الفور. على الرغم من كمية النصوص المتواضعة نسبيًا في عينة التدريب (واحد ونصف غيغابايت فقط) ، عند محاولة جرها إلى المنحدر ، أكل الثعبان 20 (20 كارل!) غيغا بايت من الذاكرة ، في مقايضة ولم يعد. اضطررت الى أكل فيل في أجزاء.

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

يعمل تسجيل الدخول فوق هذا بنفس السرعة ، وفي النهاية نحصل على 14 فقرة ونحصل على 0.54 :)

الصورة الأساسية

ماذا يمكن أن يكون أكثر شعبية من التعلم العميق؟ القطط فقط! لذلك ، بالنسبة لصورة الأساس ، وضعنا خطة بسيطة ببراعة: تشغيل كاشف كات على الصور من مجموعة الاختبار ، ثم رتب المحتوى وفقًا للنتيجة :)

ومرة أخرى هناك الكثير للاختيار من بينها. تصنيف أم اكتشاف؟ pyTorch أو Tensorflow؟ المعيار الرئيسي هو سهولة التنفيذ عن طريق طريقة نسخ لصق. والفائز هو ... YOLOv3 على MXNet :). تم اختصار نظرة التجريبي الخاصة بهم لأول وهلة ، ولكن بعد ذلك ، كما جرت العادة ، بدأت المشاكل.

ما العمل مع البيانات الكبيرة عادة ما تبدأ؟ مع تقديرات الأداء والوقت اللازم للآلة! كنت أرغب في جعل خط الأساس مستقلاً قدر الإمكان ، لذا فقد علموه العمل مباشرة مع ملف القطران وأدركوا بسرعة أنه في سرعة استخراج 200 صورة في الثانية الواحدة من القطران إلى tmpfs ، سيستغرق الأمر حوالي نصف ساعة ، ومعايير لمعالجة 352758 صورة. إضافة تحميل ومعالجة مسبقة من الصور - 100 في الثانية الواحدة ، حوالي ساعة لكل شيء ، والقواعد. أضف حساب الشبكة العصبية - 20 صورة في الثانية ، 5 ساعات ، حسنًا ... حسنًا ، أضف نتيجة الاستخراج - صورة واحدة في الثانية ، الأسبوع ، WTF؟

بعد بضع ساعات من الرقص مع الدف ، يأتي الفهم أن NDArray التي نلاحظها ليست غاضبة أبدًا ، ولكن البنية الداخلية لـ MXNet ، والتي تقوم بكل العمليات الحسابية. البنغو! ماذا تفعل؟ يعرف أي مراسل مبتدئ أن الأمر يتعلق بحجم الدُفعة! إذا كانت MXNet تحسب النتيجة بتكاسل ، فعندئذٍ إذا طلبناها أولاً لبضع عشرات من الصور ، ثم بدأنا في استخراجها ، فربما تتم معالجة الصور على دفعات؟ ونعم ، بعد إضافة الخليط بسرعة 10 صور في الثانية ، تمكنت من العثور على جميع القطط :).

ثم نطبق الهندسة المشهورة وفي 10 فقرات نحصل على 0.504 :).

الاستنتاجات

عندما سئل أحد الحكمة ، "من سيفوز ، سيد أيكيدو أو كاراتيه؟" ، أجاب "سيد سيفوز". لقد توصلنا إلى نفس الاستنتاجات تقريبًا في هذه التجربة: لا توجد ولا يمكن أن تكون لغة مثالية لجميع المناسبات. مع Python ، يمكنك تجميع حل بسرعة من الكتل الجاهزة ، ولكن محاولة الابتعاد عنها بكميات كبيرة كافية من البيانات ستجلب الكثير من الألم. في Java و Scala ، يمكنك أيضًا العثور على العديد من الأدوات الجاهزة وتنفيذ الأفكار الخاصة بك بسهولة ، ولكن ستكون اللغات نفسها أكثر طلبًا على جودة الشفرة.

ونتمنى لك التوفيق لجميع أعضاء SNA Hackathon 2019 !