في اليوم الآخر ، قررنا التحدث مع Dmitry Bugaychenko ( dmitrybugaychenko ) ، أحد مدرسي برنامج تحليل البيانات في Scala ، ومناقشة القضايا الفعلية لاستخدام Scala في مهام علوم البيانات وهندسة البيانات. ديمتري هو مهندس تحليلي في Odnoklassniki.
- ديما ، أنت تعمل في Odnoklassniki. قل لي ، ماذا تفعل هناك؟
في Odnoklassniki ، بدأت العمل في عام 2011 على مشروع توصية موسيقية. لقد كانت مهمة شاقة وصعبة للغاية - كانت معظم خدمات التوصية الموسيقية في ذلك الوقت تعتمد على محتوى نشر مفهرس جيدًا ، بينما كان لدينا محتوى UGC حقيقي (محتوى تم إنشاؤه بواسطة المستخدم) ، والذي كان لا بد من تمشيطه وتصنيفه إلى أرفف أولاً. بشكل عام ، أثبت النظام الناتج أنه جيد جدًا وقرروا مد التجربة إلى أقسام أخرى من الموقع: توصيات المجموعة ، الصداقات ، ترتيب الخلاصة ، إلخ. في الوقت نفسه ، نما الفريق وتطوير البنية التحتية وخوارزميات وتقنيات جديدة. لدي الآن مجموعة واسعة من المسؤوليات: تنسيق بيانات العلماء ، وتطوير البنية التحتية DS ، ومشاريع البحث ، إلخ.
- منذ متى وانت بدأت باستخدام Spark؟ ما هي الحاجة؟
كانت المحاولات الأولى لتكوين صداقات مع Spark في عام 2013 ، لكنها لم تنجح. كانت لدينا حاجة ملحة لأداة تفاعلية قوية سمحت لنا باختبار الفرضيات بسرعة ، لكن سبارك في ذلك الوقت لم تستطع توفير الاستقرار وقابلية التطوير التي نحتاجها. المحاولة الثانية التي أجريناها بعد عام ، في عام 2014 ، وهذه المرة تحول كل شيء بشكل أفضل. في نفس العام ، بدأنا في تطبيق أدوات تحليل التدفق استنادًا إلى Kafka و Samza ، جربنا Spark Streaming ، لكن بعد ذلك لم يستطع البدء. نظرًا للتطبيق المبكر نسبيًا ، بحلول عام 2017 ، أصبحنا في وضع يمكننا من اللحاق بالركب لفترة من الوقت - منعتنا كمية كبيرة من التعليمات البرمجية في Spark الأولى من التحول إلى الثانية ، ولكن في صيف عام 2018 حلنا هذه المشكلة ونعمل الآن على 2.3.3. في هذا الإصدار ، عمل التدفق بالفعل أكثر استقرارًا وقمنا بالفعل ببعض مهام prod الجديدة عليه.
- كما أفهمها ، فأنت تستخدم واجهة برمجة تطبيقات Scala ، وليس Python ، مثلها مثل معظم. لماذا هذا
لا أرى بصدق أي سبب لاستخدام بيثون للعمل مع سبارك ، باستثناء الكسل. يعد Scala API أكثر مرونة وأكثر كفاءة ، ولكنه ليس أكثر تعقيدًا. إذا كنت تستخدم الميزات القياسية لـ Spark SQL ، فإن رمز Scala مماثل تقريبًا لرمز Python المقابل ، وستكون السرعة مماثلة. ولكن إذا حاولت جعل أبسط وظيفة معرفة من قبل المستخدم ، فإن الفرق يصبح واضحًا - يظل عمل كود Scala فعالًا ، ويحول رمز Python مجموعة متعددة النواة إلى قرع ويبدأ في حرق كيلوواط / ساعة من أجل نشاط غير مثمر تمامًا. على النطاق الذي يجب أن نعمل به ، لا يمكننا ببساطة تحمل هذا التبذير.
- جيم بيثون أمر مفهوم. ومقارنة بـ Java ، هل Scala شيء أفضل على الإطلاق لتحليل البيانات؟ في Java ، تتم كتابة الكثير من الأشياء في رصة البيانات الكبيرة.
نحن نستخدم جافا على نطاق واسع ، بما في ذلك التعلم الآلي. نحن نحاول عدم السحب إلى تطبيقات Scala الأكثر تحميلًا. ولكن عندما يتعلق الأمر بالتحليل التفاعلي والنماذج الأولية السريعة ، تصبح اللاهوتية لـ Scala ميزة إضافية. صحيح ، يجب عليك دائمًا أن تضع في اعتبارك أنه عند البرمجة في Scala ، من السهل جدًا أن تطلق ساقيك على الأذنين - قد لا تتصرف العديد من التصميمات كما تتوقع من وضع الفطرة السليمة ، وبعض العمليات البسيطة تسبب نسخًا غير ضروري ومحاولات لتجسيد ضخم مجموعات البيانات في الذاكرة.
- مع كل هذه المزايا ، لماذا لا تحظى Scala بشعبية كبيرة حتى الآن؟ هل يتفوق بوضوح على بيثون وجافا؟
Scala هي أداة قوية للغاية تتطلب مؤهلات عالية بما فيه الكفاية من الشخص الذي يستخدمها. بالإضافة إلى ذلك ، أثناء تطوير الفريق ، تُفرض أيضًا متطلبات إضافية على المستوى العام لثقافة التطوير: من السهل جدًا كتابة التعليمات البرمجية الموجودة في Scala ، ولكن لا يقرأ المؤلف دائمًا بنجاح بعد مرور بعض الوقت ، ويمكن أن يخلق نوعًا من الألعاب تحت غطاء واجهة برمجة التطبيقات البسيطة. لذلك ، يجب إيلاء اهتمام خاص للحفاظ على أسلوب موحد ، واختبار وظيفي وإجهاد للحل.
حسنًا ، عند مقارنة لغات JVM ، لا يسع المرء إلا أن يذكر Kotlin - إنها تكتسب شعبية ، ويعتبرها الكثيرون "أكثر تحققًا أيديولوجيًا" ، وحتى أنها تدعم Spark كجزء من مشروع sparklin ، على الرغم من أنها لا تزال محدودة للغاية. نحن أنفسنا لا نستخدمها في Spark حتى الآن ، لكننا نتابع التطوير عن كثب.
- العودة إلى شرارة. كما أفهمها ، ما زلت لا تحب حتى وظيفة Scala API هذه وكنت قد كتبت نوعًا من الشوكة لـ Spark؟
قد يكون من الخطأ استدعاء مفترق مشروع PravdaML الخاص بنا: لا تحل هذه المكتبة محل ، ولكنها تكمل وظيفة SparkML بميزات جديدة. لقد توصلنا إلى القرارات التي تم تنفيذها هناك ، في محاولة لتوسيع نطاق القضبان القابلة للتكرار ونماذج التصنيف الشريط. الحقيقة هي أنه عند تطوير خوارزميات فعالة للتعلم الآلي الموزع ، تحتاج إلى النظر في العديد من العوامل "التقنية": كيفية تحليل البيانات بشكل صحيح في العقد ، وفي أي نقطة يتم تخزينها في ذاكرة التخزين المؤقت ، وخفض حجم العينة ، إلخ. لا توجد طريقة لإدارة هذه الجوانب في SparkML القياسية ، ويجب نقلها إلى ما بعد خط أنابيب ML ، مما يؤثر سلبًا على الإدارة وقابلية التكاثر.
- أتذكر أنه كان لديك خياران لاسم ...
نعم ، بدا أن الاسم الأصلي ok-ml-pipelines ممل للرجال ، لذلك نحن الآن في عملية "إعادة تسمية العلامة التجارية" بالاسم الجديد PravdaML.
- كثير من الناس استخدامه خارج فريقك؟
لا أفكر كثيرًا ، لكننا نعمل عليه. ج
- دعونا نتحدث عن الأدوار والمهن في مجال العمل مع البيانات. أخبرني ، هل يجب على عالم البيانات كتابة التعليمات البرمجية في الإنتاج أم أن هذا بالفعل بعض المهن والدور؟
الجواب على هذا السؤال هو رأيي ، وهناك حقيقة قاسية. لقد اعتقدت دائمًا أنه من أجل التنفيذ الناجح لحلول ML ، يجب أن يفهم الشخص أين ولماذا يتم تنفيذه بالكامل (من هو المستخدم ، وما هي احتياجاته ، وما يحتاجه العمل) ، يحتاج إلى فهم الأساليب الرياضية التي يمكن تطبيقها لتطوير الحل ، و كيف يمكن لهذه الأساليب أن تعمل من وجهة نظر تقنية. لذلك ، في Odnoklassniki ما زلنا نحاول الالتزام بنموذج المسؤولية الفردية ، عندما يأتي شخص ما بمبادرة ، وينفذها وينفذها. بالطبع ، لحل المشكلات الفردية الخاصة ، سواء أكانت قاعدة بيانات فعالة أو مخططًا تفاعليًا ، يمكنك دائمًا جذب أشخاص يتمتعون بخبرة واسعة في هذه المجالات ، ولكن دمج كل هذا في آلية واحدة يبقى مع العالم ، حيث أن الشخص الذي يفهم أفضل ما يجب عمله بالضبط وكيف يجب أن يعمل عليه الإخراج.
ولكن هناك أيضًا واقعًا قاسيًا في سوق العمل ، وهو الآن محموم بدرجة كبيرة في مجال ML ، الأمر الذي يؤدي إلى حقيقة أن العديد من الشباب المتخصصين لا يعتبرون من الضروري دراسة أي شيء آخر غير ML نفسه. نتيجة لذلك ، يصبح إيجاد اختصاصي دورة كاملة أكثر صعوبة. على الرغم من ظهور بديل جيد مؤخرًا: فقد أظهرت الممارسة أن المبرمجين الجيدين يتعلمون ML بسرعة وبصورة جيدة. ج
- مهندس تاريخ بحاجة إلى معرفة سكالا؟ كيف جيدة بالمناسبة؟ هل أحتاج للذهاب إلى غابة البرمجة الوظيفية؟
من الضروري بالتأكيد معرفة Scala ، فقط لأن هناك أداتين أساسيتين مثل Kafka و Spark مكتوبتان على ذلك ، ويجب أن تكون قادرًا على قراءة الكود المصدري. أما بالنسبة لـ "غابة البرمجة الوظيفية" ، فإنني أنصحهم بشدة بعدم إساءة الاستخدام: فكلما زاد عدد المطورين الذين يمكنهم قراءة الشفرة وفهمها ، كان ذلك أفضل. حتى لو كان هذا في بعض الأحيان لديك لتصميم وظيفي "أنيقة" نشر في دورة عادية.
- إن عالم المهن في هذا المجال قد توقف بالفعل عن التوسع ، أم هل ما زلنا ننتظر ظهور بعض المهن الجديدة فيه؟
أعتقد أنه في المستقبل المنظور في ML و DS ، ستكون هناك نقطة تحول متعلقة بالأتمتة: الأنماط الرئيسية التي يتبعها الأشخاص عند العمل مع السمات ، واختيار النموذج ومعلماته ، وسيتم أتمتة فحص الجودة. سيؤدي هذا إلى حقيقة أن الطلب على المتخصصين الذين "يختارون المعلمات" سوف ينخفض بشكل كبير ، لكن الطلب على مهندسي AutoML القادرين على تنفيذ وتطوير الحلول الآلية سيكون في الطلب.
"أنت تدرس بنشاط ، كما أفهمها." لماذا تعتبر هذا مهم؟ ما هو الدافع وراء هذا؟
كل واحد منا سيتقاعد يومًا ما وستعتمد جودة حياتنا إلى حد كبير على من سيحل محلنا. لذلك ، فإن الاستثمار في تعليم الجيل القادم هو أحد أهم الاستثمارات.
- في برنامجنا "تحليل البيانات على Scala" ، ستجري عدة فصول. قل لي لفترة وجيزة عنهم. ما هي أهميتها؟
في هذه الفصول ، سوف ندرس فقط كيف تتوافق الهندسة والرياضيات معًا: كيفية تنظيم العملية بشكل صحيح ، دون تقديم حواجز غير ضرورية لـ ETL-> ML-> Prod. سيتم بناء الدورة حول إمكانيات Spark ML: المفاهيم الأساسية والتحويلات المدعومة والخوارزميات المنفذة وحدودها. سنتطرق إلى المنطقة التي لا تكفي فيها ميزات SparkML الحالية ، ويصبح من الضروري استخدام ملحقات مثل PravdaML. حسنًا ، ستكون هناك ممارسة بالتأكيد ، ليس فقط على مستوى "تجميع حل من مكعبات جاهزة" ، ولكن أيضًا حول كيفية فهم الحاجة إلى "مكعب جديد" هنا وكيفية تنفيذه.
- هل هناك أي لعبة الكلمات المفضلة مع سكالا؟ تسلق الجدار ، متسلق الصخور ، الفن الصخري - هل تستخدمه في روتينك اليومي؟
ما لم تكن كلمة "indoskal" ، التي نستخدمها لمعالجة الأجزاء البارزة بشكل خاص من المصادر المفتوحة ، والتي أراد مؤلفها بوضوح إثبات القدرة الرائعة على إنشاء كود غير قابل للقراءة باستخدام التجريدات الوظيفية.
- موسكو أم بيتر؟
كل مدينة لها الحماس الخاصة بها. موسكو هي مدينة غنية ومهيفة مع إيقاع سريع. بيتر أهدأ ومليء بسحر العاصمة الأوروبية السابقة. لذلك ، أود المجيء إلى موسكو للزيارة ، لكنني أفضل العيش في سان بطرسبرغ.