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

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

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

ग्राहक विश्लेषकहरू

ग्राहक विश्लेषण एक सेवा हो जुन कम्पनीले आधिकारिक SDK मार्फत आफ्नो वेबसाइट वा अनुप्रयोगमा जडान गर्दछ, आफ्नै कोडबेसमा एकीकृत गर्दछ र घटना ट्रिगरहरू चयन गर्दछ। यस दृष्टिकोणको एक स्पष्ट नकारात्मक पक्ष छ: तपाईंले रोज्नुभएको कुनै पनि सेवाको सीमितताको कारणले गर्दा सङ्कलन गरिएका सबै डाटाहरू तपाईंले चाहानुहुने रूपमा प्रशोधन नहुन सक्छ। उदाहरणका लागि, एउटा प्रणालीमा MapReduce कार्यहरू चलाउन सजिलो हुनेछैन, अर्कोमा तपाईंले आफ्नो मोडेल चलाउन सक्नुहुने छैन। अर्को हानि सेवाहरूको लागि नियमित (प्रभावशाली) बिल हुनेछ।
बजारमा धेरै ग्राहक एनालिटिक्स समाधानहरू छन्, तर चाँडो वा पछि विश्लेषकहरूले यस तथ्यको सामना गरिरहेका छन् कि प्रत्येक कार्यको लागि उपयुक्त कुनै पनि विश्वव्यापी सेवा छैन (जब कि यी सबै सेवाहरूको मूल्यहरू सधैं बढ्दैछन्)। यस्तो अवस्थामा, कम्पनीहरूले प्रायः सबै आवश्यक अनुकूलन सेटिङहरू र क्षमताहरूसँग आफ्नै विश्लेषण प्रणाली सिर्जना गर्ने निर्णय गर्छन्।

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

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

Плюсы
Минусы

तपाईले चाहानु भएको केहि अनुकूलन गर्न सक्नुहुन्छ
यो अक्सर धेरै गाह्रो छ र अलग विकासकर्ता आवश्यक छ

दोस्रो: सास सेवाहरू लिनुहोस् (अमेजन, गुगल, Azure) यसलाई आफैं प्रयोग गर्नुको सट्टा। हामी तेस्रो भागमा थप विवरणमा SaaS को बारेमा कुरा गर्नेछौं।

Плюсы
Минусы

यो मध्यम मात्रामा सस्तो हुन सक्छ, तर ठूलो वृद्धि संग यो अझै पनि धेरै महँगो हुनेछ
सबै प्यारामिटरहरू नियन्त्रण गर्न सम्भव छैन

प्रशासन पूर्ण रूपमा सेवा प्रदायकको काँधमा हस्तान्तरण गरिएको छ
यो सधैं सेवा भित्र के छ थाहा छैन (यो आवश्यक नहुन सक्छ)

सर्भर एनालिटिक्स कसरी सङ्कलन गर्ने

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

1. डाटा प्राप्त गर्दै

ग्राहक विश्लेषणको मामलामा जस्तै, सबैभन्दा पहिले, कम्पनी विश्लेषकहरूले भविष्यमा अध्ययन गर्न चाहने घटनाहरूको प्रकारहरू चयन गर्छन् र तिनीहरूलाई सूचीमा सङ्कलन गर्छन्। सामान्यतया, यी घटनाहरू एक विशेष क्रममा हुन्छन्, जसलाई "घटना ढाँचा" भनिन्छ।
अर्को, कल्पना गर्नुहोस् कि मोबाइल अनुप्रयोग (वेबसाइट) मा नियमित प्रयोगकर्ताहरू (उपकरणहरू) र धेरै सर्भरहरू छन्। यन्त्रहरूबाट सर्भरहरूमा घटनाहरू सुरक्षित रूपमा स्थानान्तरण गर्न, एक मध्यवर्ती तह आवश्यक छ। वास्तुकलामा निर्भर गर्दै, त्यहाँ धेरै फरक घटना लामहरू हुन सक्छ।
अपाचे काफ्का हो पब/सब लाम, जुन घटनाहरू सङ्कलन गर्नका लागि लामको रूपमा प्रयोग गरिन्छ।

अनुसार Quora मा पोस्ट 2014 मा, अपाचे काफ्काका निर्माताले सफ्टवेयरको नाम फ्रान्ज काफ्काको नाममा राख्ने निर्णय गरे किनभने "यो लेख्नका लागि अनुकूलित प्रणाली हो" र किनभने उनले काफ्काका कामहरू मन पराए। - विकिपीडिया

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

(तस्बिर यहाँ देखि)

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

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

2. घटना स्ट्रिमहरू प्रशोधन गर्दै

हामीले सबै घटनाहरू तयार गरिसकेपछि र तिनीहरूलाई उपयुक्त लाइनहरूमा राखेपछि, हामी प्रशोधन चरणमा जान्छौं। यहाँ म तपाईंलाई दुई सबैभन्दा सामान्य प्रशोधन विकल्पहरूको बारेमा बताउनेछु।
पहिलो विकल्प भनेको अपाचे प्रणालीमा स्पार्क स्ट्रिमिङ सक्षम पार्नु हो। सबै Apache उत्पादनहरू HDFS मा लाइभ हुन्छन्, फाइल प्रतिकृतिहरू भएको सुरक्षित फाइल प्रणाली। स्पार्क स्ट्रिमिङ एक प्रयोग-गर्न-सजिलो उपकरण हो जसले स्ट्रिमिङ डेटा र स्केल राम्रोसँग ह्यान्डल गर्छ। तर, यसलाई कायम राख्न गाह्रो हुन सक्छ।
अर्को विकल्प तपाईंको आफ्नै घटना ह्यान्डलर निर्माण गर्न हो। यो गर्नको लागि, तपाईंलाई आवश्यक छ, उदाहरणका लागि, पाइथन अनुप्रयोग लेख्न, यसलाई डकरमा निर्माण गर्नुहोस् र काफ्का लाममा सदस्यता लिनुहोस्। जब ट्रिगरहरू डकर ह्यान्डलरहरूमा आइपुग्छन्, प्रशोधन सुरु हुनेछ। यस विधिको साथ, तपाईंले सधैं चलिरहेको अनुप्रयोगहरू राख्न आवश्यक छ।
मानौं कि हामीले माथि वर्णन गरिएका विकल्पहरू मध्ये एउटा छनोट गरेका छौं र प्रशोधनमा नै जान्छौं। प्रोसेसरहरूले डाटाको वैधता जाँच गरेर, फोहोर फिल्टर गर्ने र "ब्रेकन" घटनाहरू जाँच गरेर सुरु गर्नुपर्छ। प्रमाणीकरणको लागि हामी सामान्यतया प्रयोग गर्छौं Cerberus। यस पछि, तपाइँ डेटा म्यापिङ गर्न सक्नुहुन्छ: विभिन्न स्रोतहरूबाट डाटा सामान्य तालिकामा थप्नको लागि सामान्य र मानकीकृत गरिन्छ।

3. डाटाबेस

तेस्रो चरण भनेको सामान्यीकृत घटनाहरू कायम राख्नु हो। तयार विश्लेषणात्मक प्रणालीको साथ काम गर्दा, हामीले तिनीहरूलाई प्राय: पहुँच गर्नुपर्नेछ, त्यसैले सुविधाजनक डाटाबेस छनौट गर्न महत्त्वपूर्ण छ।
यदि डेटा निश्चित योजनामा ​​राम्रोसँग फिट हुन्छ भने, तपाइँ छनौट गर्न सक्नुहुन्छ क्लिकहाउस वा केहि अन्य स्तम्भ डेटाबेस। यस तरिकाले एकीकरण धेरै छिटो काम गर्नेछ। नकारात्मक पक्ष यो हो कि योजना कठोर रूपमा तय गरिएको छ र त्यसैले परिमार्जन बिना मनमानी वस्तुहरू थप्न सम्भव छैन (उदाहरणका लागि, जब एक गैर-मानक घटना हुन्छ)। तर तपाईं साँच्चै धेरै छिटो गणना गर्न सक्नुहुन्छ।
असंरचित डेटाको लागि, तपाईंले NoSQL लिन सक्नुहुन्छ, उदाहरणका लागि, अपाचे कासेन्ड्रा। यो HDFS मा चल्छ, राम्रोसँग प्रतिकृति बनाउँछ, तपाइँ धेरै उदाहरणहरू उठाउन सक्नुहुन्छ, र गल्ती-सहिष्णु छ।
तपाईं केहि सरल पनि उठाउन सक्नुहुन्छ, उदाहरणका लागि, MongoDB। यो एकदम ढिलो र सानो मात्रा को लागी छ। तर प्लस यो धेरै सरल छ र त्यसैले सुरु गर्न को लागी उपयुक्त छ।

4. एकत्रीकरण

सबै घटनाहरू सावधानीपूर्वक सुरक्षित गरिसकेपछि, हामी आइपुगेको ब्याचबाट सबै महत्त्वपूर्ण जानकारी सङ्कलन र डाटाबेस अद्यावधिक गर्न चाहन्छौं। विश्वव्यापी रूपमा, हामी सान्दर्भिक ड्यासबोर्ड र मेट्रिक्स प्राप्त गर्न चाहन्छौं। उदाहरणका लागि, घटनाहरूबाट प्रयोगकर्ता प्रोफाइल सङ्कलन गर्नुहोस् र व्यवहार मापन गर्नुहोस्। घटनाहरू एकत्रित, सङ्कलन र पुन: बचत गरिएका छन् (प्रयोगकर्ता तालिकाहरूमा)। एकै समयमा, तपाइँ एक प्रणाली निर्माण गर्न सक्नुहुन्छ ताकि तपाइँ एग्रीगेटर-संयोजकमा फिल्टर जडान गर्न सक्नुहुन्छ: एक निश्चित प्रकारको घटनाबाट मात्र प्रयोगकर्ताहरू सङ्कलन गर्नुहोस्।
त्यस पछि, यदि टोलीमा कसैलाई मात्र उच्च-स्तर विश्लेषणहरू चाहिन्छ भने, बाह्य विश्लेषण प्रणालीहरू जडान गर्न सकिन्छ। तपाईं फेरि Mixpanel लिन सक्नुहुन्छ। तर यो धेरै महँगो भएकोले, सबै प्रयोगकर्ता घटनाहरू त्यहाँ पठाइँदैन, तर केवल के आवश्यक छ। यो गर्नको लागि, हामीले एक संयोजक सिर्जना गर्न आवश्यक छ जसले केही कच्चा घटनाहरू वा हामीले आफैंले पहिले जम्मा गरेका बाह्य प्रणालीहरू, API वा विज्ञापन प्लेटफर्महरूमा स्थानान्तरण गर्नेछ।

5. अगाडिको भाग

तपाईंले सिर्जना गरिएको प्रणालीमा फ्रन्टएन्ड जडान गर्न आवश्यक छ। एउटा राम्रो उदाहरण सेवा हो redash, एक डाटाबेस GUI हो जसले ड्यासबोर्डहरू निर्माण गर्न मद्दत गर्दछ। कसरी अन्तरक्रिया कार्य गर्दछ:

1. प्रयोगकर्ताले SQL क्वेरी बनाउँछ।
2. जवाफमा उसले एउटा चिन्ह पाउँछ।
3. यसले यसको लागि 'नयाँ भिजुअलाइजेशन' सिर्जना गर्छ र तपाईंले आफ्नो लागि बचत गर्न सक्ने सुन्दर ग्राफ पाउँछ।

सेवामा भिजुअलाइजेसनहरू स्वत: अद्यावधिक हुँदैछन्, तपाईं आफ्नो अनुगमनलाई अनुकूलित र ट्र्याक गर्न सक्नुहुन्छ। Redash नि:शुल्क छ यदि स्व-होस्ट गरिएको छ, तर SaaS को रूपमा यो प्रति महिना $ 50 खर्च हुनेछ।

निष्कर्षमा

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

पढ्नु भएकोमा धन्यवाद! म टिप्पणीहरूमा प्रश्नहरू सोध्न खुसी हुनेछु।

स्रोत: www.habr.com