साइटवर घुसखोरांचा सामना करण्यासाठी स्वयंचलित प्रणालीची निर्मिती (फसवणूक)

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

आमच्या प्रणालीची तत्त्वे

जेव्हा तुम्ही "स्वयंचलित" आणि "फसवणूक" सारख्या संज्ञा ऐकता तेव्हा तुम्ही बहुधा मशीन लर्निंग, Apache Spark, Hadoop, Python, Airflow आणि Apache Foundation इकोसिस्टम आणि डेटा सायन्स फील्डमधील इतर तंत्रज्ञानाबद्दल विचार करण्यास सुरुवात करता. मला वाटते की ही साधने वापरण्याचा एक पैलू आहे ज्याचा सहसा उल्लेख केला जात नाही: तुम्ही त्यांचा वापर सुरू करण्यापूर्वी त्यांना तुमच्या एंटरप्राइझ सिस्टमवर काही पूर्वतयारी असणे आवश्यक आहे. थोडक्यात, तुम्हाला एंटरप्राइझ डेटा प्लॅटफॉर्म आवश्यक आहे ज्यामध्ये डेटा लेक आणि स्टोरेज समाविष्ट आहे. परंतु आपल्याकडे असे व्यासपीठ नसल्यास आणि तरीही ही प्रथा विकसित करण्याची आवश्यकता असल्यास काय? खालील तत्त्वे, ज्यांचे मी खाली वर्णन केले आहे, त्यांनी आम्हाला अशा बिंदूपर्यंत पोहोचण्यास मदत केली आहे जिथे आम्ही कार्यशील शोधण्याऐवजी आमच्या कल्पना सुधारण्यावर लक्ष केंद्रित करू शकतो. तथापि, हे प्रकल्पाचे "पठार" नाही. तांत्रिक आणि उत्पादनाच्या दृष्टिकोनातून योजनेमध्ये आणखी अनेक गोष्टी आहेत.

तत्त्व 1: व्यवसाय मूल्य प्रथम

आम्ही आमच्या सर्व प्रयत्नांमध्ये "व्यवसाय मूल्य" अग्रस्थानी ठेवतो. सर्वसाधारणपणे, कोणतीही स्वयंचलित विश्लेषण प्रणाली उच्च पातळीवरील ऑटोमेशन आणि तांत्रिक जटिलता असलेल्या जटिल प्रणालींच्या गटाशी संबंधित असते. आपण सुरवातीपासून तयार केल्यास संपूर्ण समाधान तयार करण्यास बराच वेळ लागेल. आम्ही व्यावसायिक मूल्य प्रथम आणि तांत्रिक परिपक्वता दुसरे ठेवण्याचा निर्णय घेतला. वास्तविक जीवनात, याचा अर्थ असा आहे की आपण प्रगत तंत्रज्ञान हा एक सिद्धांत म्हणून स्वीकारत नाही. आम्ही या क्षणी आमच्यासाठी सर्वोत्तम कार्य करणारे तंत्रज्ञान निवडतो. कालांतराने, असे दिसते की आपल्याला काही मॉड्यूल पुन्हा लागू करावे लागतील. ही तडजोड आम्ही मान्य केली आहे.

तत्त्व 2: वाढीव बुद्धिमत्ता

मी पैज लावतो की जे लोक मशीन लर्निंग सोल्यूशन्स विकसित करण्यात सखोलपणे गुंतलेले नाहीत त्यांना असे वाटेल की मानवी बदलणे हे ध्येय आहे. खरं तर, मशीन लर्निंग सोल्यूशन्स परिपूर्ण नसतात आणि केवळ काही विशिष्ट क्षेत्रांमध्ये बदलणे शक्य आहे. आम्ही सुरुवातीपासून ही कल्पना अनेक कारणांमुळे सोडली: फसव्या क्रियाकलापांवरील असंतुलित डेटा आणि मशीन लर्निंग मॉडेल्ससाठी वैशिष्ट्यांची संपूर्ण यादी प्रदान करण्यात अक्षमता. याउलट, आम्ही वाढीव बुद्धिमत्ता पर्यायाची निवड केली. ही कृत्रिम बुद्धिमत्तेची पर्यायी संकल्पना आहे जी AI च्या सहाय्यक भूमिकेवर लक्ष केंद्रित करते, या वस्तुस्थितीवर जोर देते की संज्ञानात्मक तंत्रज्ञान मानवी बुद्धिमत्ता वाढविण्यासाठी डिझाइन केलेले आहे, ते बदलण्यासाठी नाही. [१]

हे लक्षात घेऊन, सुरुवातीपासून संपूर्ण मशीन लर्निंग सोल्यूशन विकसित करण्यासाठी मोठ्या प्रमाणावर प्रयत्न करावे लागतील ज्यामुळे आमच्या व्यवसायासाठी मूल्य निर्माण होण्यास विलंब होईल. आम्ही आमच्या डोमेन तज्ञांच्या मार्गदर्शनाखाली मशीन लर्निंगच्या पुनरावृत्ती वाढत्या पैलूसह एक प्रणाली तयार करण्याचा निर्णय घेतला. अशी प्रणाली विकसित करण्याचा अवघड भाग असा आहे की आमच्या विश्लेषकांना ही फसवी क्रिया आहे की नाही या संदर्भात केवळ केस स्टडी प्रदान करणे आवश्यक आहे. सर्वसाधारणपणे, ग्राहकांच्या वर्तनातील कोणतीही विसंगती ही एक संशयास्पद घटना आहे ज्याची तज्ञांनी तपासणी करणे आणि कसा तरी प्रतिसाद देणे आवश्यक आहे. यापैकी फक्त काही नोंदवलेल्या प्रकरणांनाच फसवणूक म्हणून वर्गीकृत केले जाऊ शकते.

तत्त्व 3: रिच इनसाइट्स प्लॅटफॉर्म

आमच्या सिस्टमचा सर्वात कठीण भाग म्हणजे सिस्टमच्या वर्कफ्लोचे एंड-टू-एंड सत्यापन. विश्लेषक आणि विकासकांनी विश्लेषणासाठी वापरल्या गेलेल्या सर्व मेट्रिक्ससह ऐतिहासिक डेटासेट सहजपणे प्राप्त केले पाहिजेत. याव्यतिरिक्त, डेटा प्लॅटफॉर्मने विद्यमान निर्देशकांच्या संचाला नवीनसह पूरक करण्याचा एक सोपा मार्ग प्रदान केला पाहिजे. आम्ही तयार करत असलेल्या प्रक्रिया आणि या केवळ सॉफ्टवेअर प्रक्रिया नसून, मागील कालावधीची पुनर्गणना करणे, नवीन मेट्रिक्स जोडणे आणि डेटा अंदाज बदलणे सोपे झाले पाहिजे. आमची उत्पादन प्रणाली व्युत्पन्न करत असलेला सर्व डेटा जमा करून आम्ही हे साध्य करू शकतो. अशा परिस्थितीत, डेटा हळूहळू अडथळा बनतो. आम्‍ही वापरत नसल्‍या डेटाच्‍या वाढत्या प्रमाणात संचयित करणे आणि ते संरक्षित करणे आवश्‍यक आहे. अशा परिस्थितीत, डेटा कालांतराने अधिकाधिक अप्रासंगिक होत जाईल, परंतु तरीही ते व्यवस्थापित करण्यासाठी आमचे प्रयत्न आवश्यक आहेत. आमच्यासाठी, डेटा होर्डिंगला अर्थ नाही आणि आम्ही एक वेगळा दृष्टीकोन वापरण्याचा निर्णय घेतला. आम्‍ही वर्गीकृत करू इच्‍छित असलेल्‍या लक्ष्‍य घटकांभोवती रीअल-टाइम डेटा वेअरहाऊस आयोजित करण्‍याचे ठरवले आणि केवळ डेटा संग्रहित करायचा जो आम्‍हाला सर्वात अलीकडील आणि अद्ययावत कालावधी तपासण्‍याची अनुमती देतो. या प्रयत्नातील आव्हान हे आहे की आमची प्रणाली एकाधिक डेटा स्टोअर्स आणि सॉफ्टवेअर मॉड्यूल्ससह विषम आहे ज्यांना सातत्यपूर्ण पद्धतीने कार्य करण्यासाठी काळजीपूर्वक नियोजन आवश्यक आहे.

आमच्या सिस्टमच्या डिझाइन संकल्पना

आमच्या सिस्टममध्ये आमच्याकडे चार मुख्य घटक आहेत: एक अंतर्ग्रहण प्रणाली, एक संगणकीय प्रणाली, एक BI विश्लेषण आणि एक ट्रॅकिंग प्रणाली. ते विशिष्ट पृथक उद्देश पूर्ण करतात आणि आम्ही त्यांना विशिष्ट विकास पद्धतींचे अनुसरण करून वेगळे ठेवतो.

करारावर आधारित डिझाइन

सर्व प्रथम, आम्ही सहमत झालो की घटकांनी केवळ त्यांच्या दरम्यान पास केलेल्या विशिष्ट डेटा स्ट्रक्चर्स (करार) वर अवलंबून राहावे. हे त्यांच्यामध्ये समाकलित करणे सोपे करते आणि घटकांची विशिष्ट रचना (आणि ऑर्डर) लादत नाही. उदाहरणार्थ, काही प्रकरणांमध्ये हे आम्हाला अॅलर्ट ट्रॅकिंग सिस्टमसह प्राप्त करणारी प्रणाली थेट समाकलित करण्यास अनुमती देते. अशा परिस्थितीत, हे मान्य अधिसूचना करारानुसार केले जाईल. याचा अर्थ असा की दोन्ही घटक एका कराराचा वापर करून एकत्रित केले जातील जे इतर कोणतेही घटक वापरू शकतात. आम्ही इनपुट सिस्टमवरून ट्रॅकिंग सिस्टममध्ये अलर्ट जोडण्यासाठी अतिरिक्त करार जोडणार नाही. या दृष्टिकोनासाठी पूर्वनिर्धारित किमान संख्येचा करार वापरणे आवश्यक आहे आणि सिस्टम आणि संप्रेषण सुलभ करते. मुळात, आम्ही "कॉन्ट्रॅक्ट फर्स्ट डिझाईन" नावाचा दृष्टिकोन घेत आहोत आणि ते स्ट्रीमिंग कॉन्ट्रॅक्टवर लागू करत आहोत. [२]

सर्वत्र प्रवाहित होत आहे

सिस्टममध्ये राज्य जतन आणि व्यवस्थापित केल्याने त्याच्या अंमलबजावणीमध्ये अपरिहार्यपणे गुंतागुंत निर्माण होईल. सर्वसाधारणपणे, राज्य कोणत्याही घटकातून प्रवेशयोग्य असणे आवश्यक आहे, ते सुसंगत असले पाहिजे आणि सर्व घटकांमध्ये सर्वात अद्ययावत मूल्य प्रदान केले पाहिजे आणि ते योग्य मूल्यांसह विश्वसनीय असले पाहिजे. याव्यतिरिक्त, नवीनतम स्थिती मिळविण्यासाठी सतत स्टोरेजवर कॉल केल्याने आमच्या रिअल-टाइम पाइपलाइनमध्ये वापरल्या जाणार्‍या I/O चे प्रमाण आणि अल्गोरिदमची जटिलता वाढेल. यामुळे, आम्ही शक्य असल्यास, आमच्या सिस्टममधून स्टेट स्टोरेज पूर्णपणे काढून टाकण्याचा निर्णय घेतला. या दृष्टिकोनासाठी आवश्यक आहे की सर्व आवश्यक डेटा प्रसारित डेटा युनिट (संदेश) मध्ये समाविष्ट केला जावा. उदाहरणार्थ, जर आपल्याला काही निरीक्षणांची एकूण संख्या (काही वैशिष्ट्यांसह ऑपरेशन्स किंवा प्रकरणांची संख्या) मोजण्याची आवश्यकता असल्यास, आम्ही ते मेमरीमध्ये मोजतो आणि अशा मूल्यांचा प्रवाह तयार करतो. घटकांद्वारे प्रवाह विभाजित करण्यासाठी आणि नवीनतम मूल्यांवर कार्य करण्यासाठी आश्रित मॉड्यूल विभाजन आणि बॅचिंग वापरतील. या पध्दतीने अशा डेटासाठी सतत डिस्क स्टोरेज असण्याची गरज दूर केली. आमची प्रणाली काफ्का संदेश दलाल म्हणून वापरते आणि ती KSQL सह डेटाबेस म्हणून वापरली जाऊ शकते. [३] पण ते वापरल्याने आमचे समाधान काफ्काशी घट्ट बांधले जाईल आणि आम्ही ते न वापरण्याचा निर्णय घेतला. आम्ही निवडलेला दृष्टीकोन आम्हाला प्रणालीमध्ये मोठे अंतर्गत बदल न करता काफ्काला दुसर्‍या संदेश ब्रोकरसह बदलण्याची परवानगी देतो.

या संकल्पनेचा अर्थ असा नाही की आम्ही डिस्क स्टोरेज आणि डेटाबेस वापरत नाही. सिस्टम कार्यक्षमतेची चाचणी आणि विश्लेषण करण्यासाठी, आम्हाला डिस्कवर मोठ्या प्रमाणात डेटा संग्रहित करणे आवश्यक आहे, जे विविध निर्देशक आणि स्थिती दर्शवते. येथे महत्त्वाचा मुद्दा असा आहे की रिअल-टाइम अल्गोरिदम अशा डेटावर अवलंबून नाहीत. बर्‍याच प्रकरणांमध्ये, आम्ही जतन केलेला डेटा ऑफलाइन विश्लेषण, डीबगिंग आणि सिस्टमद्वारे तयार केलेल्या विशिष्ट प्रकरणांचा आणि परिणामांचा मागोवा घेण्यासाठी वापरतो.

आमच्या सिस्टममध्ये समस्या

काही समस्या आहेत ज्या आम्ही एका विशिष्ट स्तरावर सोडवल्या आहेत, परंतु त्यांना अधिक विचारपूर्वक उपाय आवश्यक आहेत. आत्तासाठी, मी त्यांचा येथे उल्लेख करू इच्छितो, कारण प्रत्येक आयटम स्वतःच्या लेखाची किंमत आहे.

• आम्हाला अजूनही प्रक्रिया आणि धोरणे परिभाषित करणे आवश्यक आहे जे आमच्या स्वयंचलित विश्लेषण, शोध आणि डेटाच्या अन्वेषणासाठी अर्थपूर्ण आणि संबंधित डेटा तयार करण्यात मदत करतात.
• नवीनतम डेटासह अद्यतनित करण्यासाठी सिस्टम स्वयंचलितपणे ट्यून करण्याच्या प्रक्रियेत एखाद्या व्यक्तीद्वारे विश्लेषणाच्या परिणामांचा परिचय. हे केवळ आमच्या मॉडेलचे अपडेट नाही, तर आमच्या प्रक्रियेचे अपडेट आणि आमच्या डेटाची अधिक चांगली समज देखील आहे.
• IF-ELSE आणि ML च्या निर्धारक दृष्टिकोनामध्ये संतुलन शोधणे. कोणीतरी म्हणाले: "एमएल हे हताशांसाठी एक साधन आहे." याचा अर्थ असा की जेव्हा तुम्हाला तुमचे अल्गोरिदम कसे ऑप्टिमाइझ करायचे आणि सुधारायचे हे समजत नसेल तेव्हा तुम्हाला ML वापरायचे आहे. दुसरीकडे, निर्धारवादी दृष्टीकोन पूर्वकल्पित नसलेल्या विसंगती शोधण्याची परवानगी देत ​​​​नाही.
• डेटामधील मेट्रिक्समधील आमची गृहितके किंवा सहसंबंध तपासण्यासाठी आम्हाला एक सोपा मार्ग हवा आहे.
• सिस्टीममध्ये खरे सकारात्मक परिणामांचे अनेक स्तर असणे आवश्यक आहे. फसवणूक प्रकरणे ही सर्व प्रकरणांपैकी फक्त एक अंश आहेत जी सिस्टमसाठी सकारात्मक मानली जाऊ शकतात. उदाहरणार्थ, विश्लेषक पुनरावलोकनासाठी सर्व संशयास्पद प्रकरणे प्राप्त करू इच्छितात आणि त्यापैकी फक्त एक छोटासा भाग फसवा आहे. प्रणालीने सर्व प्रकरणे विश्लेषकांना प्रभावीपणे प्रदान करणे आवश्यक आहे, मग ती वास्तविक फसवणूक असो किंवा केवळ संशयास्पद वर्तन असो.
• डेटा प्लॅटफॉर्म तयार केलेल्या आणि फ्लायवर गणना केलेल्या गणनेसह ऐतिहासिक डेटासेट पुनर्प्राप्त करण्यात सक्षम असावे.
• कमीत कमी तीन वेगवेगळ्या वातावरणात कोणत्याही सिस्टीम घटकांची साधी आणि स्वयंचलित उपयोजन: उत्पादन, प्रायोगिक (बीटा) आणि विकासकांसाठी.
• आणि शेवटचे पण किमान नाही. आम्हाला एक विस्तृत बेंचमार्किंग प्लॅटफॉर्म तयार करण्याची गरज आहे ज्यावर आम्ही आमच्या मॉडेल्सचे विश्लेषण करू शकतो. [४]

संदर्भ

1. संवर्धित बुद्धिमत्ता म्हणजे काय?
2. API-प्रथम डिझाइन पद्धतीची अंमलबजावणी करणे
3. काफ्का "इव्हेंट स्ट्रीमिंग डेटाबेस" मध्ये बदलत आहे
4. AUC-ROC वक्र समजून घेणे

स्त्रोत: www.habr.com