🐓 🧙 〽️ हम hh.ru पर प्रयोगों के आंकड़ों पर विचार करते हैं 🧚🏽 👸🏼 👨🏾‍💻

सभी को नमस्कार!

आज मैं आपको बताऊंगा कि कैसे हम hh.ru पर प्रयोगों पर मैनुअल आँकड़ों पर विचार करते हैं। हम देखेंगे कि डेटा कहाँ से आता है, हम इसे कैसे संसाधित करते हैं, और हम किस प्रकार के नुकसान पहुंचाते हैं। इस लेख में मैं एक सामान्य वास्तुकला और दृष्टिकोण साझा करूँगा, इसमें न्यूनतम स्क्रिप्ट और कोड होंगे। मुख्य दर्शक नौसिखिए विश्लेषक हैं जो hh.ru में डेटा विश्लेषण बुनियादी ढांचे की संरचना में रुचि रखते हैं। यदि यह विषय दिलचस्प होगा - टिप्पणियों में लिखें, हम निम्नलिखित लेखों में कोड में तल्लीन कर सकते हैं।

आप पढ़ सकते हैं कि ए / बी प्रयोगों के लिए स्वचालित मैट्रिक्स हमारे अन्य लेख में कैसे माना जाता है।

हम किस डेटा का विश्लेषण करते हैं और वे कहां से आते हैं

हम एक्सेस-लॉग और किसी भी कस्टम लॉग का विश्लेषण करते हैं जो हम खुद लिखते हैं।

95.108.213.12 - - [13 / अगस्त / 2018: 04: 00: 02 +0300] 200 "GET / नियोक्ता / 2574971 HTTP / 1.1" 12012 "-" "मोज़िला / 5.0 (संगत; यैंडेक्सॉट / 3.0; + http: /) /yandex.com/bots) "" - "" gardabani.headhunter.ge "" 0.063 "-" "1534122002.858" - "" 192.168.2.38:1500 "" - [0.064] "{15341220027959c8c01c51a6b01b682f} 200" - "- - [३५27२]] [०.००० ०]
178.23.230.16 - - [13 / अगस्त / 2018: 04: 00: 02 +0300] 200 "GET / रिक्ति / 24266672 HTTP / 1.1" 24229 " hh.ru/vacancy/2471876?query=bmw " "मोज़िला / 5.0 () Macintosh; Intel Mac OS X 10_10_5) AppleWebKit / 603.3.8 (KHTML, जैसे गेको) संस्करण / 10.1.2 Safari / 603.3.8 "-" "hh.ru" "0.210" "last_visit = 15341115966 :: 1534121915966; hhrole = बेनामी; क्षेत्र = 1; tmr_detect = 0% 7C1534121918520; Total_searches = 3; unique_banner_user = 1534121429.273825242076558 "" 1534122002.859 "" - "" "192.168.2.239:1500" "[0.208]" {1512122002649b7eef2e901d8c9c0469} "" 200 https: "

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

हडूप में डेटा कहां से आता है?

Hadoop न केवल सर्विस लॉग्स को स्टोर करता है, बल्कि ठेस डेटाबेस को भी अपलोड करता है। हडूप में हर दिन हम कुछ ऐसे टेबल अपलोड करते हैं जो एनालिटिक्स के लिए जरूरी होते हैं।

सेवा लॉग तीन तरीकों से हडूप में मिलता है।

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

आइए प्रत्येक दृष्टिकोण पर अधिक विस्तार से विचार करें।

माथे का रास्ता

क्रोन एक नियमित बैश स्क्रिप्ट चलाता है।

#!/bin/bash LOGGING_DATE_PATH_PART=$(date -d yesterday +\%Y/\%m/\%d) HADOOP_DATE_PATH_PART=$(date -d yesterday +year=\%Y/month=\%m/day=\%d) ls /logging/java/${LOGGING_DATE_PATH_PART}/hh-banner-sync/banner-versions*.log | while read source_filename; do dest_filename=$(basename "$source_filename") /usr/bin/rsync --no-relative --no-implied-dirs --bwlimit=12288 ${source_filename} rsync://hadoop2.hhnet.ru/hdfs-raw/banner-versions/${HADOOP_DATE_PATH_PART}/${dest_filename}; done

जैसा कि हम याद करते हैं, लॉग रिपॉजिटरी में सभी लॉग सामान्य फ़ाइलों के रूप में होते हैं, फ़ोल्डर संरचना लगभग निम्न होती है: /log/java/2018/08/10/unningservice_nameasure/*.log

Hadoop लगभग समान फ़ोल्डर संरचना में अपनी फ़ाइलों को संग्रहीत करता है HDfs-raw / बैनर-संस्करण / वर्ष = 2018 / महीना = 08 / दिन - 10
वर्ष, महीना, दिन हम विभाजन के रूप में उपयोग करते हैं।

इस प्रकार, हमें केवल सही पथ (पंक्ति 3-4) बनाने की आवश्यकता है, और फिर सभी आवश्यक लॉग (पंक्ति 6) का चयन करें और उन्हें rsync का उपयोग हडूप (पंक्ति 8) में भरने के लिए करें।

इस दृष्टिकोण के लाभ:

तेजी से विकास
सब कुछ पारदर्शी और स्पष्ट है।

विपक्ष:

कोई प्रीप्रोसेसिंग नहीं

फैशनेबल तरीका

चूंकि हम एक स्व-लिखित स्क्रिप्ट के साथ रिपॉजिटरी में लॉग अपलोड करते हैं, इसलिए उन्हें न केवल सर्वर पर अपलोड करने की क्षमता को पेंच करने के लिए तार्किक था, बल्कि काफ्का के लिए भी।

आकर्षण आते हैं

ऑनलाइन लॉग्स (हडूप में लॉग दिखाई देते हैं जैसे आप काफ्का में भरते हैं)
आप पूर्व-प्रसंस्करण कर सकते हैं
यह अच्छी तरह से लोड रखता है और आप बड़े लॉग अपलोड कर सकते हैं

विपक्ष

हार्ड सेटअप
मुझे कोड लिखना है
कास्टिंग प्रक्रिया के अधिक भाग
अधिक जटिल निगरानी और घटनाओं का विश्लेषण

पुराने ढंग का

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

आकर्षण आते हैं

आप पूर्व-प्रसंस्करण कर सकते हैं

विपक्ष

हार्ड सेटअप
मुझे कोड लिखना है

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

Hadoop

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

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

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

कई ने शायद मानचित्र-कम के बारे में सुना है, लेकिन एनालिटिक्स के लिए लेखन कोड बहुत सुविधाजनक और तेज़ नहीं है, जबकि एसक्यूएल में लिखना बहुत सरल है। इसलिए, ऐसी सेवाएँ दिखाई दीं जो SQL को उपयोगकर्ता के लिए पारदर्शी रूप से मैप-कम कर सकती हैं, और विश्लेषक को संदेह नहीं हो सकता है कि उनके अनुरोध को वास्तव में कैसे माना जाता है।

Hh.ru में हम इसके लिए hive और presto का उपयोग करते हैं। हाइव पहले था, लेकिन हम धीरे-धीरे प्रेस्टो में जा रहे हैं, क्योंकि यह हमारे अनुरोधों के लिए बहुत तेज है। GUI के रूप में, हम hue और zeppelin का उपयोग करते हैं।

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

चलिए एनालिटिक्स पर वापस आते हैं।

कैसे समझना है कि हम क्या विचार करना चाहते हैं?

उत्पाद प्रबंधक प्रयोग के परिणामों की गणना के कार्य के साथ आया था

हम एक ईमेल न्यूज़लेटर भेजते हैं जिसमें हम आवेदक के लिए उपयुक्त रिक्तियों को भेजते हैं (क्या सभी को इस तरह के मेलिंग पसंद हैं?)। हमने पत्र के डिजाइन को थोड़ा बदलने का फैसला किया और यह समझना चाहते हैं कि क्या यह बेहतर हो गया है। इसके लिए हम विचार करेंगे:

पत्र से रिक्तियों के लिए संक्रमण की संख्या;
संक्रमण के बाद प्रतिक्रिया

मैं आपको याद दिला दूं कि हमारे पास सभी लॉग और डेटाबेस एक्सेस हैं। हमें लिंक क्लिक के संदर्भ में अपनी मीट्रिक तैयार करनी होगी।

एक पत्र से एक रिक्ति के लिए संक्रमण की संख्या

संक्रमण hh.ru/vacancy/26646861 पर एक GET अनुरोध है। यह समझने के लिए कि संक्रमण कहाँ से आया है, हम फ़ॉर्म के utm टैग जोड़ते हैं; Utm_source = email_campaign_123। एक्सेस लॉग में GET अनुरोधों के लिए मापदंडों के बारे में जानकारी होगी, और हम केवल हमारी मेलिंग सूची से संक्रमण को फ़िल्टर कर सकते हैं।

संक्रमण के बाद प्रतिक्रियाओं की संख्या

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

हमारे पास प्रतिक्रियाओं की संख्या तैयार करने के दो विकल्प हैं:

प्रतिक्रिया hh.ru/applicant/vacancy_response/popup?vacancy_id=26646861 पर एक POST है, जिसमें एक संदर्भ hh.ru/vacancy/26646862_utource_emource=email_campaign_123 है ।
इस दृष्टिकोण की बारीकियों यह है कि यदि उपयोगकर्ता एक रिक्ति पर स्विच करता है, और फिर साइट पर थोड़ा घूमता है और फिर एक रिक्ति पर प्रतिक्रिया करता है, तो हम इसे नहीं गिनेंगे।
हम उस उपयोगकर्ता की आईडी को याद कर सकते हैं, जो hh.ru/vacancy/26646861 पर स्विच किया गया है , और डेटाबेस के आधार पर दिन के दौरान रिक्ति के लिए समीक्षाओं की संख्या की गणना करता है।

दृष्टिकोण की पसंद व्यावसायिक आवश्यकताओं द्वारा निर्धारित की जाती है, आमतौर पर पहला विकल्प पर्याप्त होता है, लेकिन यह सब इस बात पर निर्भर करता है कि उत्पाद प्रबंधक क्या इंतजार कर रहा है।

नुकसान जो हो सकता है

सभी डेटा हडूप में नहीं है, आपको ठेस डेटाबेस से डेटा जोड़ने की आवश्यकता है। उदाहरण के लिए, लॉग में आमतौर पर केवल आईडी, और यदि आपको नाम की आवश्यकता है - तो यह डेटाबेस में है। कभी-कभी आपको एक उपयोगकर्ता को फिर से शुरू करने के लिए फिर से शुरू करने की आवश्यकता होती है। और यह भी डेटाबेस में संग्रहीत होता है। ऐसा करने के लिए, हम हडूप में डेटाबेस का हिस्सा अनलोड करते हैं ताकि जुड़ना आसान हो।
डेटा घटता हो सकता है। यह आमतौर पर हडूप के लिए एक आपदा है और जिस तरह से हम इसमें डेटा लोड करते हैं। डेटा के आधार पर, एक खाली मान शून्य हो सकता है, कोई नहीं, कोई नहीं, एक खाली स्ट्रिंग, आदि। आपको प्रत्येक मामले में सावधान रहने की आवश्यकता है, क्योंकि डेटा वास्तव में अलग है, विभिन्न तरीकों से और विभिन्न प्रयोजनों के लिए लोड किया गया है।
पूरी अवधि के लिए लंबी गिनती। उदाहरण के लिए, हमें महीने के लिए अपने परिवर्तन और प्रतिक्रियाओं की गणना करने की आवश्यकता है। यह लॉग के लगभग 3 टेराबाइट्स है। यहां तक कि हूपअप को इसमें काफी समय लगेगा। आमतौर पर 100% वर्किंग रिक्वेस्ट लिखना पहली बार काफी मुश्किल होता है, इसलिए हम इसे ट्रायल और एरर के द्वारा लिखते हैं। हर बार 20 मिनट इंतजार करने का समय बहुत लंबा होता है। हल करने के तरीके:
- 1 दिन में लॉग पर अनुरोध को डीबग करना। चूंकि हमने हडूप में डेटा का विभाजन किया था, इसलिए लॉग के 1 दिन के लिए कुछ गणना करना बहुत जल्दी है।
- अस्थायी तालिका में आवश्यक लॉग अपलोड करें। एक नियम के रूप में, हम समझते हैं कि हम किस url में रुचि रखते हैं, और हम इन url से लॉग के लिए एक अस्थायी तालिका बना सकते हैं।
व्यक्तिगत रूप से, पहला विकल्प मेरे लिए अधिक सुविधाजनक है, लेकिन, कभी-कभी, मुझे एक अस्थायी तालिका बनाने की आवश्यकता होती है, यह स्थिति पर निर्भर करता है।
अंतिम मैट्रिक्स में विकृतियां
- लॉग को फ़िल्टर करना बेहतर है। आपको ध्यान देने की आवश्यकता है, उदाहरण के लिए, प्रतिक्रिया कोड के लिए, पुनर्निर्देशित, आदि बेहतर कम डेटा, लेकिन अधिक सटीक, जिनमें से आप सुनिश्चित हैं।
- मीट्रिक में संभव के रूप में कुछ मध्यवर्ती कदम। उदाहरण के लिए, रिक्ति पर स्विच करना एक चरण है (GET के लिए अनुरोध / रिक्ति / 123)। प्रतिक्रिया दो है (रिक्ति + POST के लिए संक्रमण)। कम श्रृंखला, कम त्रुटियों और अधिक सटीक रूप से मीट्रिक। कभी-कभी ऐसा होता है कि संक्रमण के बीच का डेटा खो जाता है और कुछ की गणना करना आम तौर पर असंभव है। इस समस्या को हल करने के लिए, हमें यह सोचने की ज़रूरत है कि हम प्रयोग करने से पहले क्या विचार करेंगे और कैसे करेंगे। आवश्यक घटनाओं का आपका अलग लॉग बहुत मदद करता है। हम आवश्यक घटनाओं को शूट कर सकते हैं, और इस प्रकार घटनाओं की श्रृंखला अधिक सटीक होगी, और गिनती आसान है।
- बॉट संक्रमण का एक गुच्छा उत्पन्न कर सकते हैं। आपको यह समझने की आवश्यकता है कि बॉट कहां जा सकते हैं (उदाहरण के लिए, उन पृष्ठों पर जहां प्राधिकरण की आवश्यकता होती है, उन्हें नहीं होना चाहिए), और इस डेटा को फ़िल्टर करें।
- बड़े धक्कों - उदाहरण के लिए, एक समूह में एक आवेदक हो सकता है, जो सभी प्रतिक्रियाओं का 50% उत्पन्न करता है। आँकड़ों का तिरछा होगा, इस तरह के डेटा को भी फ़िल्टर करने की आवश्यकता है।
एक्सेस लॉग के संदर्भ में क्या विचार करना मुश्किल है, यह तैयार करना मुश्किल है। यह कोड आधार, अनुभव और क्रोम देव उपकरणों के ज्ञान में मदद करता है। हम उत्पाद से मीट्रिक का विवरण पढ़ते हैं, इसे साइट पर अपने हाथों से दोहराते हैं और देखते हैं कि क्या संक्रमण उत्पन्न होते हैं।

अंत में, आइए इस बारे में बात करते हैं कि गणना के परिणाम को कैसे देखना चाहिए।

गणना परिणाम

हमारे उदाहरण में, 2 समूह और 2 मीट्रिक हैं जो एक फ़नल बनाते हैं।

परिणामों की रिपोर्टिंग के लिए सिफारिशें:

जब तक आवश्यक न हो, भागों को अधिभार न डालें। सरल और छोटा बेहतर है (उदाहरण के लिए, यहां हम प्रत्येक रिक्ति को अलग-अलग दिखा सकते हैं या दिन के हिसाब से क्लिक कर सकते हैं)। एक बात पर ध्यान दें।
डेमो परिणामों के दौरान विवरण की आवश्यकता हो सकती है, इसलिए इस बारे में सोचें कि आप कौन से प्रश्न पूछ सकते हैं और विवरण तैयार कर सकते हैं। (हमारे उदाहरण में, विवरण ईमेल भेजने के बाद संक्रमण की गति के अनुसार हो सकता है - 1 दिन, 3 दिन, एक सप्ताह, पेशेवर क्षेत्र द्वारा रिक्तियों को समूहीकृत करना)
सांख्यिकीय महत्व के बारे में याद रखें। उदाहरण के लिए, 100 क्लिक और 15 क्लिक के साथ 1% परिवर्तन नगण्य है और यादृच्छिक हो सकता है। कैलकुलेटर का उपयोग करें
जितना संभव हो उतना स्वचालित करें, क्योंकि आपको कई बार गिनना होगा। आमतौर पर एक प्रयोग के बीच में पहले से ही समझना चाहता है कि चीजें कैसे चल रही हैं। प्रयोग के बाद, सवाल उठ सकते हैं और आपको कुछ स्पष्ट करना होगा। इस प्रकार, 3-4 बार गिनती करना आवश्यक होगा, और यदि प्रत्येक गणना 10 प्रश्नों का एक क्रम है और फिर एक्सेल को कॉपी करते हुए, यह बहुत समय तक चोट पहुंचाएगा और खर्च करेगा। अजगर जानें, यह एक टन का समय बचाएगा।
वारंट होने पर परिणामों के चित्रमय प्रतिनिधित्व का उपयोग करें। अंतर्निहित हाइव और ज़ेपेलिन उपकरण आपको बॉक्स से बाहर सरल रेखांकन बनाने की अनुमति देते हैं।

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

हम hh.ru पर प्रयोगों के आंकड़ों पर विचार करते हैं