सर्व्हर विश्लेषण प्रणाली

विश्लेषणात्मक प्रणालींबद्दलच्या लेखांच्या मालिकेचा हा दुसरा भाग आहे (भाग १ ची लिंक).

आज, यात शंका नाही की डेटाची अचूक प्रक्रिया आणि परिणामांचे स्पष्टीकरण जवळजवळ कोणत्याही प्रकारच्या व्यवसायास मदत करू शकते. या संदर्भात, विश्लेषणात्मक प्रणाली पॅरामीटर्ससह अधिकाधिक लोड होत आहेत, अनुप्रयोगांमध्ये ट्रिगर आणि वापरकर्ता इव्हेंट्सची संख्या वाढत आहे.
यामुळे, कंपन्या त्यांच्या विश्लेषकांना अधिकाधिक "कच्ची" माहिती विश्‍लेषण करून योग्य निर्णयांमध्ये बदलत आहेत. कंपनीसाठी विश्लेषण प्रणालीचे महत्त्व कमी लेखले जाऊ नये आणि ही प्रणाली स्वतःच विश्वासार्ह आणि टिकाऊ असावी.

क्लायंट विश्लेषक

क्लायंट अॅनालिटिक्स ही एक सेवा आहे जी कंपनी अधिकृत SDK द्वारे तिच्या वेबसाइट किंवा अनुप्रयोगासाठी कनेक्ट करते, तिच्या स्वतःच्या कोडबेसमध्ये समाकलित करते आणि इव्हेंट ट्रिगर निवडते. या दृष्टिकोनात एक स्पष्ट कमतरता आहे: कोणत्याही निवडलेल्या सेवेच्या मर्यादांमुळे, सर्व गोळा केलेल्या डेटावर तुमच्या इच्छेनुसार प्रक्रिया केली जाऊ शकत नाही. उदाहरणार्थ, एका सिस्टीमवर MapReduce कार्ये चालवणे सोपे होणार नाही, दुसऱ्यावर तुम्ही तुमचे मॉडेल चालवू शकणार नाही. आणखी एक तोटा म्हणजे सेवांसाठी नियमित (प्रभावी) बिल असेल.
बाजारात अनेक क्लायंट अॅनालिटिक्स सोल्यूशन्स आहेत, परंतु लवकरच किंवा नंतर, विश्लेषकांना या वस्तुस्थितीचा सामना करावा लागतो की कोणत्याही कार्यासाठी एकही सार्वत्रिक सेवा योग्य नाही (जरी या सर्व सेवांच्या किंमती सतत वाढत आहेत). अशा परिस्थितीत, कंपन्या अनेकदा सर्व आवश्यक सानुकूल सेटिंग्ज आणि वैशिष्ट्यांसह त्यांची स्वतःची विश्लेषण प्रणाली तयार करण्याचा निर्णय घेतात.

सर्व्हर विश्लेषक

सर्व्हर-साइड अॅनालिटिक्स ही एक सेवा आहे जी कंपनीच्या स्वतःच्या सर्व्हरवर आणि (सामान्यतः) इन-हाउसवर अंतर्गत तैनात केली जाऊ शकते. या मॉडेलमध्ये, सर्व वापरकर्ता इव्हेंट्स अंतर्गत सर्व्हरवर संग्रहित केले जातात, ज्यामुळे विकसकांना स्टोरेजसाठी भिन्न डेटाबेस वापरून पाहण्याची आणि सर्वात सोयीस्कर आर्किटेक्चर निवडण्याची परवानगी मिळते. आणि तरीही तुम्हाला काही कामांसाठी थर्ड-पार्टी क्लायंट-साइड अॅनालिटिक्स वापरायचे असले तरीही ते शक्य होईल.
सर्व्हर-साइड विश्लेषणे दोन प्रकारे तैनात केली जाऊ शकतात. प्रथम: काही ओपन सोर्स उपयुक्तता निवडा, त्या तुमच्या मशीनवर तैनात करा आणि व्यवसाय तर्क विकसित करा.

Плюсы
मिनिन्स

तुम्ही काहीही सानुकूलित करू शकता
बर्याचदा हे खूप कठीण असते आणि स्वतंत्र विकासकांची आवश्यकता असते

दुसरे: SaaS सेवा (Amazon, Google, Azure) स्वतः उपयोजित करण्याऐवजी घ्या. तिसऱ्या भागात आपण SaaS बद्दल अधिक तपशीलवार बोलू.

Плюсы
मिनिन्स

हे मध्यम खंडांवर स्वस्त असू शकते, परंतु मोठ्या वाढीसह ते अद्याप खूप महाग होईल
सर्व पॅरामीटर्स नियंत्रित करण्यास सक्षम नाही

प्रशासन पूर्णपणे सेवा पुरवठादाराच्या खांद्यावर वळवले जाते
सेवेमध्ये काय आहे हे नेहमी माहीत नसते (आवश्यक नसू शकते)

सर्व्हर विश्लेषण कसे गोळा करावे

जर आम्हाला क्लायंट अॅनालिटिक्स वापरण्यापासून दूर जायचे असेल आणि स्वतःचे बनवायचे असेल, तर सर्वप्रथम आम्हाला नवीन प्रणालीच्या आर्किटेक्चरवर विचार करणे आवश्यक आहे. खाली मी तुम्हाला चरण-दर-चरण सांगेन की तुम्हाला काय विचारात घेणे आवश्यक आहे, प्रत्येक चरणाची आवश्यकता का आहे आणि तुम्ही कोणती साधने वापरू शकता.

1. डेटा संपादन

ज्याप्रमाणे क्लायंट अॅनालिटिक्सच्या बाबतीत, सर्व प्रथम, कंपनी विश्लेषक त्यांना पुढील अभ्यास करू इच्छित असलेल्या इव्हेंटचे प्रकार निवडतात आणि त्यांना सूचीमध्ये संकलित करतात. सहसा, या घटना एका विशिष्ट क्रमाने घडतात, ज्याला "इव्हेंट स्कीम" म्हणतात.
पुढे, कल्पना करूया की मोबाइल ऍप्लिकेशन (वेबसाइट) चे नियमित वापरकर्ते (डिव्हाइस) आणि बरेच सर्व्हर आहेत. डिव्हाइसेसवरून सर्व्हरवर इव्हेंट सुरक्षितपणे हस्तांतरित करण्यासाठी, मध्यवर्ती स्तर आवश्यक आहे. आर्किटेक्चरवर अवलंबून, अनेक भिन्न कार्यक्रम रांगा येऊ शकतात.
अपाचे काफ्का - हे आहे पब/सब रांग, जे इव्हेंट गोळा करण्यासाठी रांग म्हणून वापरले जाते.

मते Quora वर पोस्ट करा 2014 मध्ये, अपाचे काफ्काच्या निर्मात्याने सॉफ्टवेअरचे नाव फ्रांझ काफ्काच्या नावावर ठेवण्याचा निर्णय घेतला कारण “ही एक लेखन-अनुकूलित प्रणाली आहे” आणि त्याला काफ्काच्या लेखनाची आवड होती. - विकिपीडिया

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

(चित्र येथून)

त्याच वेळी, काफ्का आपल्याला भागांमध्ये वाचण्याची आणि मिनी-बॅचेसमध्ये इव्हेंटच्या प्रवाहावर प्रक्रिया करण्याची परवानगी देतो. काफ्का हे एक अतिशय सोयीचे साधन आहे जे वाढत्या गरजा (उदाहरणार्थ, इव्हेंटच्या भौगोलिक स्थानानुसार) चांगले मोजते.
सहसा एक शार्ड पुरेसा असतो, परंतु स्केलिंग करताना (नेहमीप्रमाणे) संवादासह गोष्टी अधिक क्लिष्ट होतात. कदाचित कोणीही उत्पादनात फक्त एक भौतिक शार्ड वापरू इच्छित नाही, कारण वास्तुकला दोष-सहिष्णु असणे आवश्यक आहे. काफ्का व्यतिरिक्त, आणखी एक सुप्रसिद्ध उपाय आहे - RabbitMQ. आम्ही इव्हेंट विश्लेषणासाठी रांग म्हणून उत्पादनात त्याचा वापर केला नाही (तुम्हाला असा अनुभव असल्यास, टिप्पण्यांमध्ये त्याबद्दल आम्हाला सांगा!). तथापि, AWS Kinesis चा वापर करण्यात आला.

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

2. इव्हेंट प्रवाह हाताळणे

आम्ही सर्व कार्यक्रम तयार केल्यानंतर आणि त्यांना योग्य रांगेत ठेवल्यानंतर, आम्ही प्रक्रियेच्या टप्प्यावर जाऊ. येथे मी दोन सर्वात सामान्य प्रक्रिया पर्यायांबद्दल बोलेन.
Apache प्रणालीवर स्पार्क स्ट्रीमिंग सक्षम करणे हा पहिला पर्याय आहे. सर्व Apache उत्पादने HDFS वर राहतात, एक सुरक्षित प्रतिकृती फाइल प्रणाली. स्पार्क स्ट्रीमिंग हे वापरण्यास सोपे साधन आहे जे स्ट्रीमिंग डेटावर प्रक्रिया करते आणि चांगले स्केल करते. तथापि, ते राखणे कठीण होऊ शकते.
दुसरा पर्याय म्हणजे तुमचा स्वतःचा इव्हेंट हँडलर तयार करणे. हे करण्यासाठी, उदाहरणार्थ, तुम्हाला पायथन ऍप्लिकेशन लिहावे लागेल, ते डॉकरमध्ये तयार करावे लागेल आणि काफ्काच्या रांगेचे सदस्यत्व घ्यावे लागेल. जेव्हा डॉकरमधील हँडलर्सकडे ट्रिगर येतात, तेव्हा प्रक्रिया सुरू होईल. या पद्धतीसह, आपल्याला सतत अनुप्रयोग चालू ठेवणे आवश्यक आहे.
चला असे गृहीत धरू की आम्ही वर वर्णन केलेल्या पर्यायांपैकी एक निवडला आहे आणि स्वतःच प्रक्रियेकडे जाऊ. प्रोसेसरने डेटाची वैधता तपासणे, कचरा फिल्टर करणे आणि "तुटलेले" कार्यक्रम सुरू केले पाहिजेत. प्रमाणीकरणासाठी आम्ही सहसा वापरतो सेरबेरस. त्यानंतर, डेटा मॅपिंग केले जाऊ शकते: सामान्य सारणीमध्ये जोडण्यासाठी भिन्न स्त्रोतांकडून डेटा सामान्यीकृत आणि प्रमाणित केला जातो.

3. डेटाबेस

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

4. एकत्रीकरण

सर्व इव्हेंट काळजीपूर्वक सेव्ह केल्यावर, आम्ही आलेल्या बॅचमधून सर्व महत्वाची माहिती गोळा करून डेटाबेस अपडेट करू इच्छितो. जागतिक स्तरावर, आम्हाला संबंधित डॅशबोर्ड आणि मेट्रिक्स हवे आहेत. उदाहरणार्थ, इव्हेंटमधून वापरकर्ता प्रोफाइल गोळा करणे आणि कसे तरी वर्तन मोजणे. इव्हेंट एकत्रित केले जातात, संकलित केले जातात आणि पुन्हा सेव्ह केले जातात (आधीपासूनच वापरकर्ता टेबलमध्ये). त्याच वेळी, अशा प्रकारे सिस्टम तयार करणे शक्य आहे की एक फिल्टर देखील समन्वयक एग्रीगेटरशी जोडलेला असेल: केवळ विशिष्ट प्रकारच्या इव्हेंटमधून वापरकर्ते गोळा करण्यासाठी.
त्यानंतर, टीममधील एखाद्याला फक्त उच्च-स्तरीय विश्लेषणाची आवश्यकता असल्यास, तुम्ही बाह्य विश्लेषण प्रणाली कनेक्ट करू शकता. तुम्ही Mixpanel पुन्हा घेऊ शकता. परंतु ते बरेच महाग असल्याने, तेथे सर्व वापरकर्ता इव्हेंट पाठवले जात नाहीत, परंतु फक्त आवश्यक तेच पाठवले जातात. हे करण्यासाठी, आम्हाला एक समन्वयक तयार करणे आवश्यक आहे जे काही अपरिष्कृत इव्हेंट्स किंवा आम्ही स्वतः एकत्र केलेल्या बाह्य प्रणाली, API किंवा जाहिरात प्लॅटफॉर्मवर हस्तांतरित करेल.

5. फ्रंटएंड

आपल्याला तयार केलेल्या सिस्टमशी फ्रंटएंड कनेक्ट करणे आवश्यक आहे. एक उत्तम उदाहरण म्हणजे सेवा. लालसर, एक डेटाबेस GUI आहे जो पॅनेल तयार करण्यात मदत करतो. परस्परसंवाद कसे कार्य करते:

1. वापरकर्ता SQL क्वेरी करतो.
2. प्रतिसादात, त्याला एक चिन्ह प्राप्त होते.
3. त्यासाठी 'नवीन व्हिज्युअलायझेशन' तयार करतो आणि एक सुंदर आलेख मिळवतो जो तुम्ही आधीच वाचवू शकता.

सेवेतील व्हिज्युअलायझेशन स्वयं-अपडेट होत आहेत, तुम्ही तुमचे निरीक्षण कॉन्फिगर आणि ट्रॅक करू शकता. Redash विनामूल्य आहे, सेल्फ-होस्ट केलेल्या बाबतीत, परंतु SaaS म्हणून त्याची किंमत दरमहा $50 असेल.

निष्कर्ष

वरील सर्व पायऱ्या पूर्ण केल्यानंतर, तुम्ही तुमचे सर्व्हर-साइड विश्लेषण तयार कराल. कृपया लक्षात घ्या की हे फक्त क्लायंट अॅनालिटिक्स कनेक्ट करण्याइतके सोपे नाही, कारण प्रत्येक गोष्ट स्वतःच कॉन्फिगर करणे आवश्यक आहे. म्हणूनच, तुमची स्वतःची सिस्टम तयार करण्यापूर्वी, तुम्ही त्यास वाटप करण्यास तयार असलेल्या संसाधनांसह गंभीर विश्लेषण प्रणालीच्या गरजेची तुलना करणे योग्य आहे.
जर तुम्ही सर्व गणित केले असेल आणि खर्च खूप जास्त असल्याचे आढळले असेल तर, मी पुढील भागात बॅक-एंड विश्लेषणाची स्वस्त आवृत्ती कशी बनवायची याबद्दल बोलेन.

वाचल्याबद्दल धन्यवाद! टिप्पण्यांमधील प्रश्नांमध्ये मला आनंद होईल.

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