जीवन चक्र एम.एल.

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

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

मॉडल जीवन चक्र

आमतौर पर हमारे विषय क्षेत्र में जीवन चक्र के तीन भाग होते हैं। पहले में , एक कार्य व्यवसाय से आता है । दूसरे में, एक डेटा इंजीनियर और / या डेटा वैज्ञानिक डेटा तैयार करते हैं , एक मॉडल बनाते हैं। तीसरे भाग में, अराजकता शुरू होती है। अंतिम दो में, अलग-अलग दिलचस्प परिस्थितियाँ होती हैं।

सभी ट्रेडों के जैक

पहली बार की स्थिति यह है कि एक डेटा वैज्ञानिक या डेटा इंजीनियर की उत्पादों तक पहुंच है, इसलिए वे उससे कहते हैं: "आपने यह सब किया, आपने इसे दांव पर लगा दिया।"

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

सब कुछ ठीक लगता है, लेकिन हमेशा नहीं। मैं आपको बाद में बताऊंगा क्यों।

बेरहम शोषण

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

• नोटबुक;
• विभिन्न संस्करणों का अचार;
• लिपियों के ढेर: यह स्पष्ट नहीं है कि उन्हें कहाँ और कब चलाना है, कहाँ से उत्पन्न होने वाले डेटा को बचाना है।

इस पहेली में, शोषण संस्करण असंगति का सामना करता है। उदाहरण के लिए, एक डेटा वैज्ञानिक ने लाइब्रेरी के एक विशिष्ट संस्करण को निर्दिष्ट नहीं किया, और ऑपरेशन ने नवीनतम ले लिया। कुछ समय बाद, डेटा वैज्ञानिक रिसॉर्ट्स:

- आप गलत संस्करण के लिए सीखते हैं, अब सभी मैट्रिक्स चले गए हैं! पिछले संस्करण पर वापस जाने की आवश्यकता है।

यह पूरी तरह से ठेस को तोड़ता है, और शोषण ग्रस्त है।

नौकरशाही

ग्रीन लोगो वाली कंपनियों में, जब डेटा वैज्ञानिक ऑपरेशन में आता है और मॉडल लाता है, तो आमतौर पर उसे जवाब में एक 800-शीट दस्तावेज़ मिलता है: "इस निर्देश का पालन करें, अन्यथा आपका उत्पाद कभी भी दिन का प्रकाश नहीं देखेगा"।

उदास डेटा वैज्ञानिक छोड़ देता है, सब कुछ आधा फेंक देता है, और फिर बुझाता है - उसे ऐसा करने में कोई दिलचस्पी नहीं है।

तैनाती

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

यह अच्छा है अगर विशेषज्ञ डेटाबेस में अपने काम के परिणाम लिखता है। थोड़ी देर बाद, वह उन्हें प्राप्त करेगा और देखेगा कि अंदर क्या होता है। लेकिन हमेशा ऐसा नहीं होता है। जब एक व्यवसाय और एक डेटा वैज्ञानिक बस मानते हैं कि सब कुछ ठीक और अद्भुत काम कर रहा है, तो यह असफल मामलों में तब्दील हो जाता है।

एमएफआई

किसी तरह हमने एक बड़े माइक्रोफाइनेंस संगठन के लिए एक स्कोरिंग इंजन विकसित किया। उन्होंने उन्हें ठेस तक नहीं जाने दिया, लेकिन बस हम से मॉडल का एक झरना लिया, इसे स्थापित और लॉन्च किया। मॉडलों के परीक्षा परिणामों ने उन्हें संतुष्ट किया। लेकिन 6 महीने बाद वे वापस आ गए:

- यह सब बुरा है। व्यापार नहीं चलता है, हम बदतर और बदतर हो रहे हैं। ऐसा लगता है कि मॉडल उत्कृष्ट हैं, लेकिन परिणाम गिर रहे हैं, धोखाधड़ी और डिफ़ॉल्ट रूप से अधिक से अधिक, और कम पैसे। हमने आपको क्या भुगतान किया? चलो ठीक है।

उसी समय, मॉडल तक पहुंच दोबारा नहीं दी जाती है। छह महीने पहले, लॉग को एक महीने के लिए अनलोड किया गया था। हमने एक और महीने के लिए अनलोडिंग का अध्ययन किया और इस निष्कर्ष पर पहुंचे कि किसी समय MFI के IT विभाग ने इनपुट डेटा को बदल दिया था, और json में दस्तावेजों के बजाय, उन्होंने xml में दस्तावेज़ भेजने शुरू कर दिए। मॉडल को json की उम्मीद थी, लेकिन xml प्राप्त हुआ, दुखी था और उसने सोचा कि इनपुट में कोई डेटा नहीं है।

यदि कोई डेटा नहीं है, तो जो हो रहा है उसका आकलन अलग है। निगरानी के बिना, यह पता नहीं लगाया जा सकता है।

नया संस्करण, कैस्केड और परीक्षण

अक्सर हम इस तथ्य से सामना करते हैं कि मॉडल अच्छी तरह से काम करता है, लेकिन किसी कारण से एक नया संस्करण विकसित किया गया है। मॉडल को फिर से किसी तरह लाने की जरूरत है, और फिर से नरक के सभी हलकों से गुजरना है। यह अच्छा है अगर पुस्तकालय संस्करण पिछले मॉडल के समान हैं, और यदि नहीं, तो तैनाती नए सिरे से शुरू होती है ...

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

ऐसे हालात होते हैं जब मॉडलों का एक झरना उपयोग किया जाता है। जब निम्नलिखित मॉडल के परिणाम पिछले वाले पर निर्भर करते हैं, तो किसी तरह आपको उनके बीच बातचीत स्थापित करने की आवश्यकता होती है और कहीं फिर से यह सब बचाया जाना चाहिए।

ऐसी समस्याओं को कैसे हल करें?

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

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

एक कठोर उद्यम में, लोग सभी प्रकार के अजगर, बृहस्पति आदि से परेशान नहीं होना चाहते हैं, वे कहते हैं:

- आइए आईबीएम एसपीएसएस खरीदें, इंस्टॉल करें और सब कुछ बढ़िया होगा। संस्करण के साथ समस्याएँ, डेटा स्रोतों के साथ, वहाँ किसी तरह से तैनाती के साथ हल।

इस दृष्टिकोण को अस्तित्व का अधिकार है, लेकिन हर कोई इसे बर्दाश्त नहीं कर सकता। किसी भी मामले में, यह इतनी उच्च गुणवत्ता वाली दाँतेदार सुई है। वे इस पर बैठते हैं, लेकिन यह काम नहीं करता है। और यह आमतौर पर बहुत खर्च होता है।

ओपन सोर्स पिछले दृष्टिकोण के विपरीत है। डेवलपर्स ने इंटरनेट को सर्फ किया, बहुत सारे ओपन सोर्स समाधान पाए जो अपने कार्यों को अलग-अलग डिग्री तक हल करते हैं। यह एक शानदार तरीका है, लेकिन खुद के लिए हमें ऐसे समाधान नहीं मिले जो हमारी आवश्यकताओं को 100% पूरा करें।

इसलिए, हमने क्लासिक विकल्प को चुना है - हमारा निर्णय । अपनी बैसाखी, साइकिल, सभी अपने, मूल निवासी।

हम अपने फैसले से क्या चाहते हैं?

सब कुछ खुद मत लिखो । हम घटकों को लेना चाहते हैं, विशेष रूप से बुनियादी ढांचे वाले, जो खुद को अच्छी तरह से साबित कर चुके हैं और उन संस्थानों में संचालन से परिचित हैं जिनके साथ हम काम करते हैं। हम सिर्फ एक ऐसा वातावरण लिखते हैं जो डेटा वैज्ञानिक के काम को आसानी से देवो के काम से अलग कर देगा।

दो मोड में प्रक्रिया डेटा: बैच मोड में दोनों - बैच, और वास्तविक समय । हमारे कार्यों में दोनों ऑपरेटिंग मोड शामिल हैं।

तैनाती में आसानी, और एक बंद परिधि में । संवेदनशील निजी डेटा के साथ काम करते समय, कोई इंटरनेट कनेक्शन नहीं होता है। इस समय, सब कुछ जल्दी और सही ढंग से उत्पादन के लिए मिलना चाहिए। इसलिए, हमने Gitlab की ओर, इसके अंदर CI / CD पाइपलाइन और Docker की ओर देखना शुरू किया।

एक मॉडल अपने आप में एक अंत नहीं है। हम एक मॉडल के निर्माण की समस्या का समाधान नहीं करते हैं, हम एक व्यावसायिक समस्या का समाधान करते हैं।

पाइपलाइन के अंदर, सभी पाइपलाइन घटकों के संस्करण के लिए समर्थन के साथ नियम और मॉडल का एक समूह होना चाहिए।

पाइपलाइन से क्या मतलब है? रूस में, धन शोधन और आतंकवाद के वित्तपोषण पर संघीय कानून 115 लागू है। केवल सेंट्रल बैंक की सिफारिशों की सामग्री की तालिका में 16 स्क्रीन हैं। ये सरल नियम हैं जो एक बैंक पूरा कर सकता है अगर उसके पास ऐसा कोई डेटा है, या नहीं तो उसके पास कोई डेटा नहीं है।

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

मॉडल के कैस्केड बनाएं । अक्सर एक स्थिति उत्पन्न होती है जब अगला मॉडल अपने काम के लिए पिछले मॉडल में प्राप्त मूल्यों का उपयोग करता है।

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

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

आपने क्या करने का फैसला किया?

पहले हम निगरानी चाहते हैं। और अपनी तरह के दो।

निगरानी

तकनीकी निगरानी। यदि किसी भी पाइपलाइन घटक को तैनात किया जाता है, तो ऑपरेशन में उन्हें यह देखना चाहिए कि घटक का क्या होता है: यह मेमोरी, सीपीयू, डिस्क की खपत करता है।

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

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

परीक्षण

स्थिरता के लिए पाइपलाइन का परीक्षण करें। पाइपलाइन की बारीकियों को देखते हुए, यह एक तरह का कंप्यूटिंग ग्राफ है। हम यह समझना चाहते हैं कि हम एक ग्राफ को लागू कर रहे हैं, हम इसे दरकिनार कर सकते हैं और इसका एक रास्ता निकाल सकते हैं।

ग्राफ में घटक हैं - मॉड्यूल। सभी मॉड्यूल को यूनिट और एकीकरण परीक्षण पास करना होगा। डेटा वैज्ञानिक के लिए प्रक्रिया पारदर्शी और आसान होनी चाहिए।

डेवलपर अपने आप या किसी और की मदद से मॉडल और परीक्षणों का वर्णन करता है। Gitlab में सब कुछ डालता है, निरंतर एकीकरण द्वारा कॉन्फ़िगर की गई पाइपलाइन उठती है, परीक्षण करती है, परिणाम देखती है। यदि सब कुछ अच्छा है - यह आगे बढ़ता है, नहीं - यह नए सिरे से शुरू होता है।

डेटा वैज्ञानिक मॉडल पर केंद्रित है और यह नहीं जानता कि हुड के नीचे क्या है। इसके लिए उसे कई चीजें दी जाती हैं।

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

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

हमने हमारे लिए दो महत्वपूर्ण कहानियों की नींव रखी।

ग्राहक यात्रा। यह पूरे ग्राहक इतिहास को संरक्षित करने के लिए तंत्र का उपयोग करने का एक अवसर है - इस प्रणाली पर लागू होने वाली व्यावसायिक प्रक्रियाओं के हिस्से के रूप में ग्राहक के साथ क्या हुआ।

हमारे पास बाहरी डेटा स्रोत हो सकते हैं, उदाहरण के लिए, डीएमपी प्लेटफॉर्म। उनसे हमें नेटवर्क और मोबाइल उपकरणों में मानव व्यवहार के बारे में जानकारी मिलती है। इससे उनके मॉडल के LTV और स्कोरिंग मॉडल पर असर पड़ सकता है। यदि उधारकर्ता को भुगतान करने में देर होती है, तो हम यह अनुमान लगा सकते हैं कि यह दुर्भावनापूर्ण इरादा नहीं है - बस समस्याएं हैं। इस मामले में, हम उधारकर्ता के संपर्क में आने के नरम तरीके लागू करते हैं। जब समस्याओं का समाधान हो जाएगा, तो ग्राहक ऋण को बंद कर देगा। जब वह अगली बार आएगा, तो हम उसकी पूरी कहानी जानेंगे। डेटा वैज्ञानिक मॉडल से दृश्य इतिहास प्राप्त करेंगे और प्रकाश मोड में स्कोरिंग करेंगे।

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

ग्राहक यात्रा मॉडल के माध्यम से जाने वाली डेटा स्ट्रीम के त्वरित और आसान पहुंच की अवधारणा है। मॉडल से विसंगतियों का पता लगाना आसान हो जाता है जो इसके द्रव्यमान की घटना के समय धोखाधड़ी की विशेषता है।

सब कुछ कैसे व्यवस्थित है?

बिना किसी हिचकिचाहट के, हमने काफ्का को एक संदेश बस पैच के रूप में लिया। यह एक अच्छा समाधान है जो हमारे कई ग्राहकों द्वारा उपयोग किया जाता है, ऑपरेशन इसके साथ काम करने में सक्षम है।

कुछ सिस्टम कंपोनेंट पहले से ही कंपनी में इस्तेमाल किए जा सकते हैं। हम सिस्टम को फिर से नहीं बना रहे हैं, लेकिन वे जो पहले से ही हैं, उसका पुन: उपयोग कर रहे हैं।

इस मामले में डेटा स्टोरेज वह स्टोरेज है जो क्लाइंट के पास आमतौर पर पहले से होता है। यह Hadoop, रिलेशनल और नॉन-रिलेशनल डेटाबेस हो सकता है। हम मूल रूप से एचडीएफएस, हाइव, इम्पाला, ग्रीनप्लम और पोस्टग्रेक्यूएल के साथ बॉक्स से बाहर काम कर सकते हैं। हम इन भंडारण को दुकान की खिड़कियों के स्रोत के रूप में मानते हैं।

गोदाम में डेटा आता है, हमारे ईटीएल या ग्राहक के ईटीएल से गुजरता है, अगर उसके पास एक है। हम दुकान की खिड़कियों का निर्माण कर रहे हैं जो आगे मॉडल के अंदर उपयोग की जाती हैं। डेटा स्टोरेज का उपयोग रीड-ओनली मोड में किया जाता है।

हमारे घटनाक्रम

ब्लैकबोर्ड। यह नाम 30-40 के गणितज्ञों के अजीबोगरीब अभ्यास से लिया गया है। यह पाइपलाइनों का प्रबंधक है जो व्यवस्थापक प्रणाली में रहते हैं। ब्लैकबोर्ड में किसी प्रकार का मेटा स्टोरेज है। यह पाइपलाइनों को स्वयं और विन्यासों को संग्रहीत करता है जो सभी घटकों को शुरू करने के लिए आवश्यक हैं।

सभी सिस्टम का काम ब्लैकबोर्ड से शुरू होता है। कुछ चमत्कार से, पाइप लाइन मेटा स्टोरेज में समाप्त हो गई, ब्लैकबोर्ड थोड़ी देर बाद यह समझता है, पाइपलाइन के वर्तमान संस्करण को बाहर निकालता है, इसे इनिशियलाइज़ करता है और काफ्का के अंदर एक सिग्नल भेजता है।

भागदौड़ का माहौल है । इसे डॉकर्स पर बनाया गया है और इसे ग्राहकों के निजी क्लाउड सहित सर्वर पर दोहराया जा सकता है।

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

गणितीय रूप से, एक अभिनेता एक ऐसा कार्य है जो एक या एक से अधिक वस्तुओं को इनपुट के रूप में लेता है, अंदर एक एल्गोरिथ्म का उपयोग करके वस्तुओं की स्थिति को बदलता है, आउटपुट पर एक नई वस्तु उत्पन्न करता है, या एक मौजूदा की स्थिति को बदलता है।

तकनीकी रूप से, एक अभिनेता एक पायथन कार्यक्रम है। अपने वातावरण के साथ डॉकटर कंटेनर में चलता है।

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

अभिनेता :: Init कई डॉकर कंटेनरों को जन्म देता है। इसके अलावा, अभिनेता डेटा भंडारण के साथ काम करने में सक्षम हैं।

सिस्टम में स्वयं एक इवेंट स्टोरेज घटक होता है। Event Storage के रूप में हम ClickHouse का उपयोग करते हैं । इसका कार्य सरल है: काफ्का के माध्यम से अभिनेता के बीच आदान-प्रदान की गई सभी जानकारी क्लिकहाउस में संग्रहीत की जाती है। यह आगे ऑडिट के लिए किया जाता है। यह पाइपलाइन ऑपरेशन लॉग है।

ग्राहक यात्रा के लिए अभिनेता भी विकसित किए जा सकते हैं। वे पाइपलाइन लॉग में परिवर्तन देखते हैं, और पहले से ही पाइपलाइन के अंदर, नियमों के साथ काम करने के लिए मॉडल या घटकों के लिए आवश्यक खिड़कियों का निर्माण कर सकते हैं। यह डेटा बदलने की एक सतत प्रक्रिया है।

निगरानी बल्कि मुख्यतः प्रोमेथियस पर निर्मित है। अभिनेता को एक बुनियादी एपीआई दिया जाता है, और एक बंद मोड में, लेकिन डेवलपर के लिए पर्याप्त पारदर्शी, वह काफ्का को मैट्रिक्स के साथ संदेश भेजता है। प्रोमेथियस काफ्का से मैट्रिक्स पढ़ता है और इसे अपने भंडार में बचाता है।

विज़ुअलाइज़ेशन के लिए हम ग्राफाना का उपयोग करते हैं ।

एकीकरण के दो बिंदु

पहला डेटा स्रोतों के साथ एकीकरण का बिंदु है जो डेटा गोदाम में ईटीएल के माध्यम से जाता है। एकीकरण का दूसरा बिंदु जब एक सेवा पहले से ही डेटा उपभोक्ता द्वारा उपयोग की जाती है, उदाहरण के लिए, एक स्कोरिंग सेवा।

हमने Apache ServiceMix लिया । अनुभव से, ये एकीकरण बिंदु एक ही प्रकार के प्रोटोकॉल के साथ एक ही प्रकार के होते हैं: SOAP, RESTful, कम अक्सर कतारें। अगली बार जब हम अगली SOAP सेवा तैयार करने के लिए अपने स्वयं के निर्माता या सेवा को विकसित नहीं करना चाहते हैं। इसलिए, हम ServiceMix लेते हैं, इसे SDL में वर्णित करते हैं, जिसमें इस सेवा के डेटा मॉडल और इसमें मौजूद विधियों का निर्माण किया जाता है। फिर हम सर्विसमिक्स के अंदर राउटर के माध्यम से धक्का देते हैं, और यह सेवा को स्वयं उत्पन्न करता है।

अपने आप से, हमने एक मुश्किल सिंक्रोनस-एसिंक्रोनस रूपांतरण जोड़ा। सिस्टम के अंदर रहने वाले सभी अनुरोध अतुल्यकालिक हैं और संदेश बस के माध्यम से जाते हैं।

अधिकांश स्कोरिंग सेवाएं सिंक्रोनस हैं। ServiceMix अनुरोध REST या SOAP के माध्यम से आते हैं। इस बिंदु पर, वह हमारे गेटवे से गुजरता है, जो HTTP सत्र के ज्ञान को बनाए रखता है। फिर वह काफ्का को एक संदेश भेजता है, यह कुछ पाइपलाइन से चलता है, और एक समाधान उत्पन्न होता है।

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

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

इसलिए, हम अपडेट की निगरानी करने और नियमित रूप से कुछ बदलने के लिए मजबूर हैं।

इन्फ्रास्ट्रक्चर गितलब है। हम लगभग हर चीज का उपयोग करते हैं जो इसमें है।

• कोड रिपॉजिटरी।
• निरंतरता / निरंतरता वितरण पाइपलाइन।
• डॉकटर कंटेनरों की एक रजिस्ट्री बनाए रखने के लिए रजिस्ट्री।

घटकों

हमने 5 घटक विकसित किए हैं:

• ब्लैकबोर्ड - पाइपलाइन जीवनचक्र प्रबंधन। कहां, क्या और किन मापदंडों से पाइपलाइन से चलना है।
• फ़ीचर एक्सट्रैक्टर बस काम करता है - हम फ़ीचर एक्सट्रैक्टर को सूचित करते हैं कि हमें इनपुट पर इस तरह के डेटा मॉडल मिलते हैं, डेटा से आवश्यक फ़ील्ड का चयन करते हैं, उन्हें कुछ निश्चित मानों में मैप करते हैं। उदाहरण के लिए, हमें क्लाइंट के जन्म की तारीख मिलती है, इसे उम्र में परिवर्तित करें, इसे हमारे मॉडल में एक सुविधा के रूप में उपयोग करें। फीचर एक्सट्रैक्टर डेटा संवर्धन के लिए जिम्मेदार है।
• नियम आधारित इंजन - नियमों के अनुसार डेटा की जाँच करना। यह एक सरल विवरण भाषा है जो किसी व्यक्ति को <कोड> के निर्माण से परिचित कराता है, यदि, सिस्टम के भीतर जांच के लिए नियमों का वर्णन करने के लिए <code /> ब्लॉक करता है।
• मशीन लर्निंग इंजन - आपको निष्पादक को चलाने, प्रशिक्षित मॉडल को इनिशियलाइज़ करने और इसे इनपुट डेटा में सबमिट करने की अनुमति देता है। आउटपुट पर, मॉडल डेटा लेता है।
• निर्णय इंजन - निर्णय इंजन, ग्राफ से बाहर निकलें। उदाहरण के लिए, मॉडल का एक झरना होने, उधारकर्ता के मूल्यांकन की विभिन्न शाखाओं, आपको कहीं न कहीं पैसे के मुद्दे पर निर्णय लेना होगा। समाधान के लिए नियमों का सेट सरल होना चाहिए। , LTV- — , , .

. — , . — , .

pipeline .

• Feature extractor : , , .
• . , -: , , 18.
• . , . , , pipeline.
• Decision engine . .
• .

yaml. . , , . yaml.

pipeline, , : feature extractor, rules, models, decision engine, . — Docker- . Registry, Docker-. -, , . , , Docker- .

पाइपलाइन

, Python — . Feature extractor, , decision engine Python.

Pipeline yaml. meta storage — .

Runtime environment 10 , Blackboard , pipeline 10 . , : , , IP- Kafka, , . .

GitLab. Ansible. , . , 50 000 Ansible .

?

GitLab pipeline. GitLab. CI , , , . GitLab Runner , Docker- , pipeline. — Registry.



Docker , . Docker- . CI pipeline pipeline - Meta Storage, Blackboard.

Blackboard Meta Storage — , , , -. Docker- , , .

- Blackboard Meta Storage : , Kafka, . , , Docker- , .

, Docker-, — pipeline !

DigitalOcean. AWS Scaleway, .

, . pipeline . , .

?

— . , pipeline, real-time .

• 2 Feature extractor . 1 , .. json .
• 8 — 8 ML engine. XGBoost.
• 18 RB engine (115 ). 1000 .
• 1 decision engine.

200 . 2 Feature extractor, 8 , 18 1 decision engine 1,2 .

Discovery . , - . , , . . Meta Storage.

pipeline . , BPM . yaml , , .

. Java, Scala, R. Python, , . API , pipeline .

?

— . — . , . , . — 2018 .

, . — , , .

, . , , notebook , .

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