हमने कुबेरनेट्स के अंदर फास कैसे किया और टिंकफ हैकथॉन में जीत हासिल की

पिछले साल से, हमारी कंपनी में हैकथॉन का आयोजन किया जाने लगा। इस तरह की पहली प्रतियोगिता बहुत सफल रही, हमने लेख में इसके बारे में लिखा। दूसरा हैकथॉन फरवरी 2019 में आयोजित किया गया था और कोई कम सफल नहीं था। आयोजक ने हाल ही में उत्तरार्द्ध के लक्ष्यों के बारे में लिखा ।

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

कार्य गैर-तुच्छ है और इसे कई तरीकों से हल किया जा सकता है, जैसा कि हमने प्रतिभागियों की परियोजनाओं की अंतिम प्रस्तुतियों के प्रदर्शन में देखा था। हैकाथॉन में 5 लोगों की 6 टीमें थीं, सभी प्रतिभागियों के पास अच्छी परियोजनाएं थीं, लेकिन हमारा मंच सबसे अधिक प्रतिस्पर्धी निकला। हमें एक बहुत ही दिलचस्प प्रोजेक्ट मिला, जिसके बारे में मैं इस लेख में बात करना चाहूंगा।

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

स्कोरिंग क्या है?

Tinkoff.ru, कई आधुनिक कंपनियों की तरह, ग्राहक स्कोरिंग है। स्कोरिंग एक ग्राहक मूल्यांकन प्रणाली है जो डेटा विश्लेषण के सांख्यिकीय तरीकों पर आधारित है।

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

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

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

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

इस कार्य के लिए, हम पहले से ही विशिष्ट IBM WebSphere ILOG JRules BRMS निर्णय लेने की प्रणाली का उपयोग करते हैं , जो विश्लेषकों, प्रौद्योगिकीविदों और डेवलपर्स द्वारा निर्धारित नियमों के आधार पर, यह तय करता है कि किसी ग्राहक को किसी विशेष बैंकिंग उत्पाद को मंजूरी देनी है या नहीं।

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

कार्य

हैकथॉन 23 फरवरी को आयोजित किया गया था। प्रतिभागियों को एक लड़ाकू मिशन की पेशकश की गई: एक निर्णय लेने की प्रणाली विकसित करने के लिए, जिसे कई स्थितियों को पूरा करना था।

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

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

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

हमारा निर्णय

एक छोटे से बुद्धिशीलता सत्र के बाद, हमने फैसला किया कि FaaS समाधान कार्य के लिए आदर्श होगा।

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

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

1. विश्लेषक रिपॉजिटरी के डेटा के आधार पर एक स्क्रिप्ट, नियम या एमएल मॉडल लिखते हैं। हैकाथॉन के हिस्से के रूप में, हमने मोंगोडब का उपयोग करने का फैसला किया, लेकिन भंडारण प्रणाली का विकल्प यहां महत्वपूर्ण नहीं है।
2. ऐतिहासिक डेटा पर विकसित नियमों का परीक्षण करने के बाद, विश्लेषक अपना कोड एडमिन पैनल में डालता है।
3. वर्जनिंग सुनिश्चित करने के लिए, सभी कोड Git रिपॉजिटरी में जाएंगे।
4. व्यवस्थापक पैनल के माध्यम से, क्लाउड में कोड को एक अलग कार्यात्मक सर्वर रहित मॉड्यूल के रूप में तैनात करना संभव होगा।

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

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

सभी पेशेवरों और विपक्षों का वजन करने के बाद, हमने विखंडन का विकल्प चुना। यह सर्वर रहित ढांचा कार्य की आवश्यकताओं को प्रबंधित करने और पूरा करने में काफी आसान है।

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

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

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

हमारे द्वारा प्रस्तावित समाधान में, नियमों को जारी करने की आवश्यकता नहीं है, एक बटन के क्लिक पर कोड आसानी से तैनात किया जाता है। इसके अलावा, कुबेरनेट्स में बुनियादी ढांचा प्रबंधन आपको लोड और स्केलिंग के बारे में सोचने की अनुमति नहीं देता है, ऐसी समस्याओं को बॉक्स से बाहर हल किया जाता है। और एकल डेटा वेयरहाउस का उपयोग ऐतिहासिक डेटा के साथ वास्तविक समय डेटा की तुलना करने की आवश्यकता को समाप्त करता है, जो विश्लेषक के काम को सरल करता है।

हमें क्या मिला?

चूंकि हम रेडी-मेड समाधान (हमारी कल्पनाओं में) के साथ हैकाथॉन पहुंचे, हमें केवल अपने सभी विचारों को कोड की लाइनों में बदलने की आवश्यकता है।

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

हमारी परियोजना की वास्तुकला इस प्रकार थी:


यह आरेख दो प्रवेश बिंदु, एक विश्लेषक (हमारे सिस्टम का मुख्य उपयोगकर्ता) और एक ग्राहक दिखाता है।

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

1. साइट पर एक फ़ॉर्म भरने वाला ग्राहक नियंत्रक को अपना अनुरोध भेजता है। एक प्रणाली के इनपुट पर एक आवेदन आता है, जिसके अनुसार एक निर्णय किया जाना चाहिए, और डेटाबेस में अपने मूल रूप में दर्ज किया जाता है।
2. अगला, आवश्यक होने पर संवर्धन के लिए एक कच्चा अनुरोध भेजा जाता है। आप बाहरी सेवाओं और रिपॉजिटरी से डेटा के साथ प्रारंभिक अनुरोध को पूरक कर सकते हैं। प्राप्त रिच क्वेरी डेटाबेस में भी संग्रहीत है।
3. विश्लेषणात्मक फ़ंक्शन लॉन्च किया गया है, जो इनपुट पर एक समृद्ध अनुरोध प्राप्त करता है और एक निर्णय देता है, जिसे रिपॉजिटरी में भी दर्ज किया जाता है।

हमारी प्रणाली में एक भंडारण के रूप में, हमने JSON दस्तावेज़ों के रूप में डेटा के प्रलेखित भंडारण के मद्देनजर MongoDB का उपयोग करने का निर्णय लिया, क्योंकि प्रारंभिक अनुरोध सहित संवर्धन सेवाओं ने REST नियंत्रकों के माध्यम से सभी डेटा एकत्र किया।

इसलिए, हमारे पास मंच को लागू करने के लिए एक दिन था। हमने काफी सफलतापूर्वक भूमिकाओं को वितरित किया, प्रत्येक टीम के सदस्य की हमारी परियोजना में जिम्मेदारी का अपना क्षेत्र था:

1. विश्लेषक के कार्य के लिए फ्रंटएंड एडमिन पैनल जिसके माध्यम से वह लिखित स्क्रिप्ट के संस्करण नियंत्रण प्रणाली से नियम डाउनलोड कर सकता है, इनपुट डेटा को समृद्ध करने के लिए विकल्पों का चयन कर सकता है और नियमों की स्क्रिप्ट को ऑनलाइन संपादित कर सकता है।
2. एक बैकएंड एडमिन पैनल जिसमें फ्रंट और VCS एकीकरण के लिए REST API शामिल है।
3. Google क्लाउड में अवसंरचना स्थापित करना और स्रोत डेटा संवर्धन सेवा विकसित करना।
4. नियमों के बाद की तैनाती के लिए सर्वर रहित ढांचे के साथ व्यवस्थापक अनुप्रयोग को एकीकृत करने के लिए मॉड्यूल।
5. अंतिम प्रदर्शन के लिए आने वाले अनुप्रयोगों (निर्णय किए गए) के लिए संपूर्ण प्रणाली के स्वास्थ्य के परीक्षण और विश्लेषण के एकत्रीकरण के लिए नियमों का लिप्यांकन।

चलिए शुरू करते हैं।

बैंकिंग यूआई किट का उपयोग करते हुए हमारा दृश्य कोणीय 7 में लिखा गया था। व्यवस्थापक पैनल का अंतिम संस्करण इस प्रकार था:


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

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


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

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

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

विखंडन के साथ काम करने के लिए, हमने विखंडन CLI का उपयोग किया, जिसे Kubernetes CLI के शीर्ष पर स्थापित किया जाना चाहिए। K8s क्लस्टर में कार्य करना काफी सरल है, आपको केवल आंतरिक मार्ग निर्दिष्ट करने की आवश्यकता है और फ़ंक्शन के लिए आने वाले ट्रैफ़िक की अनुमति देने की आवश्यकता है यदि क्लस्टर के बाहर एक्सेस की आवश्यकता है। एक फ़ंक्शन को लागू करने में आमतौर पर 10 सेकंड से अधिक नहीं लगता है।

परियोजना का अंतिम प्रदर्शन और संक्षेप

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

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


अस्वीकृति या अनुमोदन के अलावा, क्लाइंट को अन्य उत्पादों की एक सूची भी मिली, जिसके लिए हमने समानांतर में अनुरोध भेजे। इसलिए हमने अपने प्लेटफॉर्म में क्रॉस-सेल की संभावना का प्रदर्शन किया।

कुल में, 3 आविष्कार किए गए बैंक उत्पाद उपलब्ध थे:

• क्रेडिट।
• खिलौना
• बंधक।

प्रत्येक प्रदर्शन के दौरान, हमने प्रत्येक सेवा के लिए तैयार कार्यों और संवर्धन स्क्रिप्ट को तैनात किया।

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

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

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

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