"मुझे आलस के अलावा, स्पार्क के साथ काम करने के लिए पायथन का उपयोग करने का कोई कारण नहीं दिखता है"

दूसरे दिन, हमने दिमित्री बुगायाचेंको ( dmitrybugaychenko ) के साथ बात की, स्कैला कार्यक्रम पर डेटा विश्लेषण के हमारे शिक्षकों में से एक, और उसके साथ डेटा साइंस और डेटा इंजीनियरिंग के कार्यों में स्काला का उपयोग करने के वास्तविक मुद्दों पर चर्चा की। दिमित्री Odnoklassniki में एक विश्लेषणात्मक इंजीनियर है।

- दीमा, आप Odnoklassniki में काम करते हैं। मुझे बताओ, तुम वहाँ क्या कर रहे हो?

Odnoklassniki में, मैंने 2011 में एक मसौदा संगीत सिफारिश पर काम करना शुरू किया। यह एक बहुत ही दिलचस्प और मुश्किल काम था - उस समय अधिकांश संगीत सिफारिश सेवाएं अच्छी तरह से सूचीबद्ध प्रकाशन सामग्री के आसपास थीं, जबकि हमारे पास वास्तविक यूजीसी (उपयोगकर्ता द्वारा उत्पन्न सामग्री) थी, जिसे पहले कंघी करना और अलमारियों में क्रमबद्ध करना था। सामान्य तौर पर, परिणामी प्रणाली काफी अच्छी साबित हुई और उन्होंने अनुभव को साइट के अन्य वर्गों में विस्तारित करने का निर्णय लिया: समूह की सिफारिशें, मित्रता, फीडिंग की रैंकिंग आदि। इसी समय, टीम बढ़ी, बुनियादी ढांचे का विकास हुआ, नए एल्गोरिदम और प्रौद्योगिकियां पेश की गईं। अब मेरे पास जिम्मेदारियों की एक विस्तृत श्रृंखला है: वैज्ञानिकों के डेटा का समन्वय, डीएस अवसंरचना का विकास, अनुसंधान परियोजनाएं आदि।

- आपने स्पार्क का उपयोग कब तक शुरू कर दिया है? क्या जरूरत है?

स्पार्क के साथ दोस्त बनाने के पहले प्रयास 2013 में वापस आ गए थे, लेकिन असफल रहे थे। हमें एक शक्तिशाली इंटरेक्टिव टूल की तत्काल आवश्यकता थी, जिसने हमें परिकल्पनाओं का त्वरित परीक्षण करने की अनुमति दी, लेकिन उस समय की स्पार्क हमें आवश्यक स्थिरता और मापनीयता प्रदान नहीं कर सका। दूसरा प्रयास हमने एक साल बाद, 2014 में किया, और इस बार सब कुछ बहुत बेहतर निकला। उसी वर्ष में, हमने काफ्का और सामजा पर आधारित स्ट्रीमिंग एनालिटिक्स टूल पेश करना शुरू किया, स्पार्क स्ट्रीमिंग की कोशिश की, लेकिन फिर यह शुरू नहीं हो सका। अपेक्षाकृत जल्दी कार्यान्वयन के कारण, 2017 तक हम थोड़ी देर के लिए पकड़ने की स्थिति में थे - पहली स्पार्क पर बड़ी मात्रा में कोड ने हमें दूसरे पर स्विच करने से रोक दिया, लेकिन 2018 की गर्मियों में हमने इस समस्या को हल किया और अब 2.3.3 पर काम कर रहे हैं। इस संस्करण में, स्ट्रीमिंग ने पहले से ही अधिक स्थिर काम किया है और हमने पहले से ही इस पर कुछ नए उत्पादों का काम किया है।

- जैसा कि मैं इसे समझता हूं, आप स्काला एपीआई का उपयोग करते हैं, न कि अजगर की तरह। ऐसा क्यों?

मैं ईमानदारी से आलस के अलावा, स्पार्क के साथ काम करने के लिए पायथन का उपयोग करने का कोई कारण नहीं देखता हूं। स्काला एपीआई अधिक लचीला और बहुत अधिक कुशल है, लेकिन अधिक जटिल नहीं है। यदि आप स्पार्क एसक्यूएल की मानक विशेषताओं का उपयोग करते हैं, तो स्केल कोड लगभग समान पायथन कोड के समान है, और गति समान होगी। लेकिन अगर आप सबसे सरल उपयोगकर्ता-परिभाषित फ़ंक्शन बनाने की कोशिश करते हैं, तो अंतर स्पष्ट हो जाता है - स्केल कोड का काम उतना ही कुशल रहता है, और पायथन कोड मल्टी-कोर क्लस्टर को कद्दू में बदल देता है और पूरी तरह से अनुत्पादक गतिविधि के लिए किलोवाट / घंटे जलना शुरू कर देता है। जिस पैमाने पर हमें काम करना है, हम बस इस तरह की बर्बादी बर्दाश्त नहीं कर सकते।

- सी पायथन समझ में आता है। और जब जावा से तुलना की जाती है, तो क्या स्काला डेटा विश्लेषण के लिए कुछ बेहतर है? जावा में, बड़े डेटा स्टैक में बहुत सी चीजें लिखी जाती हैं।

हम मशीन सीखने में जावा का व्यापक रूप से उपयोग करते हैं। हम सबसे अधिक लोड किए गए स्काला अनुप्रयोगों में खींचने की कोशिश नहीं करते हैं। लेकिन जब इंटरेक्टिव एनालिसिस और रैपिड प्रोटोटाइपिंग की बात आती है, तो स्काला का लैकोनिज़्म एक प्लस बन जाता है। सच है, आपको हमेशा ध्यान रखना चाहिए कि स्काला में प्रोग्रामिंग करते समय, अपने पैरों को कानों तक शूट करना बहुत आसान होता है - कई डिजाइन व्यवहार नहीं कर सकते हैं जैसा कि आप सामान्य ज्ञान की स्थिति से उम्मीद करते हैं, और कुछ सरल ऑपरेशन अनावश्यक नकल और विशाल सामग्री के प्रयासों का कारण बनते हैं। स्मृति में डेटासेट।

- इन सभी फायदों के साथ, स्काला इतना लोकप्रिय क्यों नहीं है? क्या यह स्पष्ट रूप से पायथन और जावा को बेहतर बनाता है?

स्काला एक बहुत शक्तिशाली उपकरण है जिसका उपयोग करने वाले से पर्याप्त उच्च योग्यता की आवश्यकता होती है। इसके अलावा, टीम के विकास के दौरान, विकास संस्कृति के सामान्य स्तर पर अतिरिक्त आवश्यकताओं को भी लगाया जाता है: स्काला पर कोड लिखना बहुत आसान है, लेकिन हमेशा कुछ समय बाद लेखक द्वारा सफलतापूर्वक पढ़ा नहीं जाता है, और एक साधारण एपीआई के हुड के तहत यह किसी प्रकार का खेल बना सकता है। इसलिए, समाधान की एकीकृत शैली, कार्यात्मक और तनाव परीक्षण को बनाए रखने के लिए विशेष ध्यान दिया जाना चाहिए।

खैर, जब JVM भाषाओं की तुलना करते हैं, तो कोई भी कोटलिन का उल्लेख नहीं कर सकता है - यह लोकप्रियता प्राप्त कर रहा है, कई लोगों द्वारा इसे अधिक "वैचारिक रूप से सत्यापित" माना जाता है, और स्पार्कल स्पार्कलिन परियोजना के हिस्से के रूप में स्पार्क का समर्थन भी करता है, हालांकि यह अभी भी सीमित है। हम खुद अभी तक स्पार्क के लिए इसका उपयोग नहीं करते हैं, लेकिन हम विकास का बारीकी से पालन कर रहे हैं।

- स्पार्क पर वापस। जैसा कि मैंने इसे समझा है, आप अभी भी इस स्काला एपीआई कार्यक्षमता की तरह नहीं हैं और आपने स्पार्क के लिए किसी तरह का कांटा लिखा है?

हमारे PravdaML प्रोजेक्ट फोर्क को कॉल करना गलत होगा: यह लाइब्रेरी प्रतिस्थापित नहीं करती है, लेकिन नए फीचर्स के साथ SparkML कार्यक्षमता को पूरक बनाती है। हम उन फैसलों पर आए जो वहां लागू किए गए थे, टेप रैंकिंग मॉडल को पुन: पेश करने की कोशिश कर रहे थे। तथ्य यह है कि प्रभावी वितरित मशीन लर्निंग एल्गोरिदम विकसित करते समय, आपको कई "तकनीकी" कारकों पर विचार करने की आवश्यकता है: कैसे ठीक से नोड्स में डेटा को विघटित करना है, कैश, डाउन-सैंपल, आदि के किस बिंदु पर। मानक स्पार्कएमएल में इन पहलुओं को प्रबंधित करने का कोई तरीका नहीं है, और उन्हें एमएल पाइप लाइन से परे ले जाना होगा, जो कि प्रबंधनीयता और प्रजनन क्षमता को नकारात्मक रूप से प्रभावित करता है।

- मुझे याद है कि आपके पास नाम के लिए दो विकल्प थे ...

हां, मूल नाम ओके-एमएल-पाइपलाइन लोगों को उबाऊ लग रहा था, इसलिए हम अब नए नाम PravdaML के साथ "रीब्रांडिंग" की प्रक्रिया में हैं।

- कई लोग आपकी टीम के बाहर इसका इस्तेमाल करते हैं?

मैं ज्यादा नहीं सोचता, लेकिन हम इस पर काम कर रहे हैं। जम्मू

- चलो डेटा के साथ काम करने के क्षेत्र में भूमिकाओं और व्यवसायों के बारे में बात करते हैं। मुझे बताओ, क्या एक डेटा वैज्ञानिक को उत्पादन में कोड लिखना चाहिए या यह पहले से ही कुछ अन्य पेशे और भूमिका है?

इस सवाल का जवाब मेरी राय है, और एक कठोर वास्तविकता है। मैंने हमेशा सोचा था कि एमएल समाधानों के सफल कार्यान्वयन के लिए, एक व्यक्ति को यह समझना चाहिए कि यह कहां और क्यों लागू किया जा रहा है (जो उपयोगकर्ता है, उसकी जरूरतें क्या हैं, और व्यवसाय की क्या जरूरत है), उसे यह समझने की जरूरत है कि समाधान विकसित करने के लिए क्या गणितीय तरीके लागू किए जा सकते हैं और ये तरीके तकनीकी दृष्टिकोण से कैसे काम कर सकते हैं। इसलिए, ओडनोकलास्निक में हम अभी भी एकल जिम्मेदारी के मॉडल का पालन करने की कोशिश करते हैं, जब कोई व्यक्ति कुछ पहल के साथ आता है, इसे लागू करता है और इसे लागू करता है। बेशक, व्यक्तिगत निजी मुद्दों को हल करने के लिए, चाहे वह एक प्रभावी डीबीएमएस हो या एक इंटरैक्टिव लेआउट, आप हमेशा इन क्षेत्रों में व्यापक अनुभव वाले लोगों को आकर्षित कर सकते हैं, लेकिन इन सभी का एकीकरण एकल वैज्ञानिक में रहता है, क्योंकि वह व्यक्ति जो वास्तव में सबसे अच्छा समझता है और इसे कैसे काम करना चाहिए उत्पादन।

लेकिन श्रम बाजार पर एक कठोर वास्तविकता भी है, जो अब एमएल के क्षेत्र में बहुत अधिक गरम है, जो इस तथ्य की ओर जाता है कि कई युवा विशेषज्ञ खुद को एमएल के अलावा और कुछ भी अध्ययन करने के लिए आवश्यक नहीं मानते हैं। नतीजतन, एक पूर्ण-चक्र विशेषज्ञ को ढूंढना अधिक से अधिक कठिन हो जाता है। हालांकि हाल ही में एक अच्छा विकल्प सामने आया है: अभ्यास से पता चला है कि अच्छे प्रोग्रामर एमएल को बहुत जल्दी और काफी अच्छी तरह से सीखते हैं। जम्मू

- तारीख इंजीनियर को स्काला जानना जरूरी है? वैसे कैसे अच्छा है? क्या मुझे कार्यात्मक प्रोग्रामिंग के जंगल में जाने की आवश्यकता है?

स्केला को जानना निश्चित रूप से आवश्यक है, यदि केवल इसलिए कि कफका और स्पार्क जैसे दो मूलभूत उपकरण इस पर लिखे गए हैं, और आपको उनके स्रोत कोड को पढ़ने में सक्षम होना चाहिए। "कार्यात्मक प्रोग्रामिंग के जंगल" के लिए, मैं उन्हें बहुत अधिक दुरुपयोग न करने की दृढ़ता से सलाह दूंगा: अधिक डेवलपर्स कोड को पढ़ और समझ सकते हैं, बेहतर। यहां तक ​​कि अगर इसके लिए कभी-कभी आपको एक भोजान चक्र में "सुरुचिपूर्ण" कार्यात्मक डिजाइन करना पड़ता है।

- इस क्षेत्र में व्यवसायों का ब्रह्मांड पहले से ही विस्तारित होना बंद हो गया है, या हमें अभी भी इसमें कुछ नए व्यवसायों के उभरने का इंतजार करना चाहिए?

मुझे लगता है कि एमएल और डीएस में निकट भविष्य में स्वचालन से संबंधित एक महत्वपूर्ण मोड़ होगा: मुख्य पैटर्न जो लोग विशेषताओं के साथ काम करते समय अपनाते हैं, एक मॉडल और इसके मापदंडों का चयन करते हैं, और गुणवत्ता की जांच स्वचालित होगी। यह इस तथ्य को जन्म देगा कि "मापदंडों का चयन करने वाले" विशेषज्ञों की मांग में काफी कमी आएगी, लेकिन ऑटोएमएल-इंजीनियर जो स्वचालित समाधानों को लागू करने और विकसित करने में सक्षम हैं, मांग में होंगे।

"आप सक्रिय रूप से सिखा रहे हैं, जैसा कि मैं इसे समझता हूं।" आप इसे महत्वपूर्ण क्यों मानते हैं? इसके पीछे क्या प्रेरणा है?

हम सभी एक दिन रिटायर होंगे और हमारे जीवन की गुणवत्ता इस बात पर बहुत निर्भर करेगी कि हमारी जगह कौन लेगा। इसलिए, अगली पीढ़ी की शिक्षा में निवेश सबसे महत्वपूर्ण है।

- हमारे कार्यक्रम "स्काला पर डेटा विश्लेषण" पर आप कई कक्षाएं आयोजित करेंगे। मुझे उनके बारे में संक्षेप में बताएं। उनका महत्व क्या है?

इन कक्षाओं में, हम सिर्फ अध्ययन करेंगे कि इंजीनियरिंग और गणित एक साथ कैसे फिट होते हैं: ईटीएल-> एमएल-> प्रोडक्ट के लिए अनावश्यक बाधाओं को पेश किए बिना प्रक्रिया को सही ढंग से कैसे व्यवस्थित किया जाए। पाठ्यक्रम स्पार्क एमएल की क्षमताओं के आसपास बनाया जाएगा: बुनियादी अवधारणाओं, समर्थित रूपांतरण, कार्यान्वित एल्गोरिदम और उनकी सीमाएं। हम उस क्षेत्र को स्पर्श करेंगे जहां मौजूदा स्पार्कएमएल सुविधाएँ पर्याप्त नहीं हैं, और यह आवश्यक है कि प्रवीडाएमएल जैसे एक्सटेंशन का उपयोग करें। खैर, निश्चित रूप से अभ्यास होगा, न केवल "तैयार क्यूब्स से एक समाधान को इकट्ठा करने" के स्तर पर, बल्कि यह भी कि कैसे समझें कि एक नया "क्यूब" यहां आवश्यक है और इसे कैसे लागू किया जाए।

- क्या स्काला के साथ कोई पसंदीदा सजा है? चढ़ाई की दीवार, रॉक-क्लाइंबर, रॉक आर्ट - क्या आप अपने रोजमर्रा के जीवन में उपयोग करते हैं?

जब तक एपिथेट "इंडोसकल" नहीं है, जिसका उपयोग हम विशेष रूप से खुले स्रोत के उल्लेखनीय टुकड़ों को संबोधित करने के लिए करते हैं, जिसका लेखक स्पष्ट रूप से कार्यात्मक सार का उपयोग करके अपठनीय कोड के निर्माण की उल्लेखनीय क्षमता का प्रदर्शन करना चाहता था।

- मास्को या पीटर?

प्रत्येक शहर का अपना उत्साह होता है। मॉस्को एक अमीर और अच्छी तरह से तैयार शहर है जिसमें एक तेज लय है। पीटर शांत है और पूर्व यूरोपीय राजधानी के आकर्षण से भरा है। इसलिए, मुझे मॉस्को आना पसंद है, लेकिन मैं सेंट पीटर्सबर्ग में रहना पसंद करता हूं।