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

घटना संग्रह और विश्लेषण प्रणाली को उदारतापूर्वक क्लिकस्ट्रीम कहा जा सकता है। मैं आपको Avito में क्लिकस्ट्रीम के तकनीकी पक्ष के बारे में बताऊंगा: घटनाओं की व्यवस्था, उनके भेजने और वितरण, विश्लेषिकी, रिपोर्ट। यदि आप Google Analytics और Yandex.Metrica चाहते हैं, तो आप स्वयं को क्यों चाहते हैं, जिसे क्लिकस्ट्रीम डेवलपर्स जीवन बिगाड़ते हैं और क्यों गो-कोडर्स php को नहीं भूल सकते हैं।

मेरे बारे में

दिमित्री खसानोव, वेब विकास में दस साल, एविटो में तीन साल। मैं एक प्लेटफॉर्म टीम में काम करता हूं, सामान्य बुनियादी ढांचे के उपकरण विकसित करता हूं। मुझे हैकेथॉन बहुत पसंद है ।

कार्य

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

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

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

इसके अतिरिक्त, अक्सर घटनाओं के प्रवाह को विभाजित करने की आवश्यकता होती है। जब कुछ निश्चित घटनाएं होती हैं, तो प्रोजेक्ट्स को कार्रवाई करने की आवश्यकता होती है। उदाहरण के लिए, इस तरह, पैटर्न मान्यता और ऑटो-मॉडरेशन के लिए मॉडल को पुनः प्राप्त करने के लिए प्रतिक्रिया प्राप्त की जाती है, और वास्तविक समय के आंकड़े संकलित किए जाते हैं।

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

घटनाओं के प्रवाह के आधार पर रिपोर्ट।
उदाहरण 1

उदाहरण 2

तैयार उपकरण

हम Yandex Metric और Google Analytics के बारे में जानते हैं, हम इसका उपयोग कुछ कार्यों के लिए करते हैं। उनकी मदद से, सामने के छोर से विश्लेषणात्मक डेटा एकत्र करना अच्छा और तेज़ है। लेकिन बैकएंड से बाहरी विश्लेषणात्मक प्रणालियों में डेटा निर्यात करने के लिए, आपको मुश्किल एकीकरण करना होगा।

बाहरी उपकरणों के साथ आपको घटनाओं के प्रवाह को विभाजित करने की समस्या को स्वतंत्र रूप से हल करना होगा।

विश्लेषणात्मक जानकारी बहुत मूल्यवान है। हम इसे वर्षों से एकत्र कर रहे हैं, यह हमें महान विस्तार से जानने की अनुमति देता है कि हमारे उपयोगकर्ता कैसे व्यवहार करते हैं। मैं इस तरह के ज्ञान को बाहरी दुनिया के साथ साझा नहीं करना चाहता।

विधान रूस के क्षेत्र पर डेटा संग्रहीत करने के लिए बाध्य करता है।

ये कारण विश्लेषणात्मक डेटा को इकट्ठा करने और संसाधित करने के लिए मुख्य उपकरण के रूप में हमारे अपने समाधान को विकसित करने के लिए काफी पर्याप्त थे।

निर्णय

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

घटना

केंद्रीय इकाई। अपने आप में, इसका मतलब तथ्य है। समय की नामित इकाई में कुछ ठोस हुआ।

एक घटना को दूसरे से अलग करना आवश्यक है। यह घटना की विशिष्ट पहचानकर्ता है।

घटनाओं के घटने के समय में भी रुचि रखते हैं। हम इसे हर घटना में माइक्रोसेकंड की सटीकता के साथ प्रसारित करते हैं। आगे की घटनाओं से आने वाली घटनाओं में, हम अतिरिक्त रूप से क्रियाओं के अनुक्रम को पुनर्स्थापित करने के लिए क्लाइंट डिवाइस पर समय को ठीक करते हैं।

मैदान

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

फ़ील्ड विशेषताएँ: प्रकार (स्ट्रिंग, संख्या, सरणी), अनिवार्य।

पर्यावरण

सिस्टम के विभिन्न हिस्सों में एक ही घटना हो सकती है: उदाहरण के लिए, साइट पर या मोबाइल एप्लिकेशन में प्राधिकरण संभव है। इस मामले में, हम उसी घटना को भेजते हैं, लेकिन हमेशा इवेंट स्रोत के अनन्य पहचानकर्ता को अंदर जोड़ते हैं।

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

"पर्यावरण" की अवधारणा है। यह सभी स्रोत घटनाओं के लिए सामान्य फ़ील्ड सेट करने की क्षमता के साथ स्रोत द्वारा घटनाओं का एक तार्किक समूहन है।

पर्यावरण के उदाहरण: "सेवा ए का बैकेंड", "सेवा ए के सामने", "सेवा के ए-आवेदन"।

घटना निर्देशिका

सभी मौजूदा घटनाओं को एक निर्देशिका में वर्णित किया गया है जिसे डेवलपर्स और विश्लेषक संपादित कर सकते हैं। घटनाओं को तार्किक रूप से पर्यावरण द्वारा समूहीकृत किया जाता है, प्रत्येक घटना का एक मालिक होता है, निर्देशिका में परिवर्तन का एक लॉग रखा जाता है।

फिलहाल, निर्देशिका कई सौ क्षेत्रों, कई दसियों वातावरण और एक हजार से अधिक घटनाओं का वर्णन करती है।

Langpak

हमने यातना से इनकार कर दिया, और हम अब डेवलपर्स को इवेंट डिस्पैच कोड को मैन्युअल रूप से लिखने के लिए मजबूर नहीं करते हैं। इसके बजाय, निर्देशिका के आधार पर, हम कंपनी द्वारा समर्थित सर्वर भाषाओं में से प्रत्येक के लिए फ़ाइलों का एक सेट उत्पन्न करते हैं: php, go or pyonon। इस तरह के उत्पन्न कोड को "लैंगपैक" कहा जाता है।

लैंगपैक की फाइलें यथासंभव सरल हैं, उन्हें परियोजनाओं के व्यावसायिक तर्क के बारे में पता नहीं है। यह प्रत्येक ईवेंट के लिए गेटर्स और फ़ील्ड सेटर्स का सेट है और ईवेंट भेजने के लिए एक कोड है।

प्रत्येक वातावरण के लिए एक लैंगपैक बनाया जाता है। यह एक पैकेज रिपॉजिटरी (php के लिए satis, pythi for python) में विघटित होता है। निर्देशिका में परिवर्तन किए जाने पर यह स्वचालित रूप से अपडेट हो जाता है।

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

वर्ज़निंग

संदर्भ संपादित किया जा सकता है। लड़ाई में कोड को तोड़ा नहीं जा सकता। हम निर्देशिका के आधार पर मुकाबला कोड उत्पन्न करते हैं। Opasnenko।

घटना के प्रत्येक परिवर्तन के बाद, निर्देशिका में एक नया संस्करण बनाया जाता है। घटनाओं के सभी निर्मित संस्करण हमेशा के लिए निर्देशिका में रहते हैं। तो हम विशिष्ट घटनाओं की अपरिहार्यता की समस्या को हल करते हैं। परियोजनाएं हमेशा इंगित करती हैं कि हम किस संस्करण के साथ काम कर रहे हैं।

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

हम वीर्य का उपयोग करते हैं। प्रत्येक लैंगपैक के संस्करण में तीन नंबर होते हैं। पहला हमेशा शून्य है, दूसरा लैंगपैक कोड का संस्करण है, तीसरा वृद्धि है। घटनाओं के प्रत्येक परिवर्तन के बाद तीसरा अंक सबसे अधिक बार बदलता है।

दो-स्तरीय संस्करणिंग आपको लड़ाई में कोड को तोड़ने के बिना निर्देशिका को संपादित करने की अनुमति देता है। यह दो सिद्धांतों पर आधारित है: आप कुछ भी नहीं हटा सकते हैं; आप बनाई गई संस्थाओं को संपादित नहीं कर सकते हैं, बस संशोधित प्रतियाँ बना सकते हैं।

ट्रांसपोर्ट

एलएसडी पर बुश के दोस्तों के विपरीत, हमने कभी भी खूबसूरती से फाइल लिखना नहीं सीखा। और हम मानते हैं कि एनएसक्यू न केवल एक कतार सर्वर है , बल्कि घटनाओं के लिए एक परिवहन भी है।

उन्होंने एनएसक्यू को गो कोड की एक छोटी परत के पीछे छिपा दिया, कुबेरनेट्स क्लस्टर में प्रत्येक नोड के लिए डेमॉन सेट का उपयोग करके कलेक्टरों को रखा, और उपभोक्ताओं को लिखा जो विभिन्न स्रोतों में घटनाओं को जोड़ सकते हैं।

फिलहाल, परिवहन प्रति दिन लगभग दो बिलियन इवेंट वितरित करता है। ऐसे भार के तहत, तीस कलेक्टर कुछ मार्जिन के साथ काम करते हैं। प्रत्येक एक छोटे से अधिक प्रोसेसर कोर और स्मृति के एक गीगाबाइट से थोड़ा अधिक खपत करता है।

इवेंट रूटिंग

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

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

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

परियोजनाओं की तरफ से रूटिंग के बारे में कोई जानकारी नहीं है। वे लंगपैक का उपयोग करके घटनाओं को भेजते हैं जिसमें आम कलेक्टरों के पते सिल दिए जाते हैं।

कोष

मुख्य घटना भंडार HP वर्टिका, कुछ दर्जन टेराबाइट्स है। हमारे विश्लेषकों के लिए उपयुक्त सुविधाओं के साथ एक स्तंभ आधार। इंटरफ़ेस - रिपोर्टिंग के लिए झांकी।

बड़े बैचों में हमारे भंडारण में घटनाओं को रिकॉर्ड करना अधिक कुशल है। भंडारण के सामने मेंगो के रूप में एक बफर है। हर घंटे के लिए ऑटो-निर्मित ऑटो-कलेक्शन संग्रह। कुछ गलत होने पर वर्टिका में प्रूफरीडिंग को फिर से शुरू करने में सक्षम होने के लिए कई दिनों तक संग्रहित किया जाता है।

पालतू लिपियों पर बफर मोंगो से पढ़ें। लिपियों को एक संदर्भ द्वारा निर्देशित किया जाता है, हम कोशिश करते हैं कि यहां व्यापारिक तर्क न रखें। इस स्तर पर, घटना संवर्धन संभव है।

विकास

अंधेरे में हाथ नाचता रहा

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

अक्सर घटना प्रेषण कोड के अंदर, व्यापार तर्क के बिट्स रहते थे। इस ज्ञान के साथ कोड को अन्य परियोजनाओं में पोर्ट नहीं किया जा सकता है। जब रीफैक्टरिंग, व्यावसायिक तर्क को परियोजना में वापस करने की आवश्यकता होती है, तो घटना कोड में केवल निर्दिष्ट डेटा प्रारूप का अनुपालन होता है।

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

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

अविकारी अतुल्यकालिक

सभी मौजूदा घटनाओं की एक निर्देशिका बनाने का निर्णय लिया गया। हमने बैकएंड के कोड को पार्स किया, वहां से कुछ जानकारी निकाली। हमने डिवेलपर्स को इवेंट कोड में हर बदलाव के साथ डायरेक्टरी में इसे नोट करने के लिए बाध्य किया।

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

डेवलपर्स जानते हैं कि कैसे भूलना है। इससे निर्देशिका और कोड का एक वंशानुक्रम हुआ, लेकिन निर्देशिका ने सामान्य चित्र दिखाया।

बफर संग्रह की संख्या में काफी वृद्धि हुई है, उन्हें बनाए रखने के लिए मैनुअल काम में काफी वृद्धि हुई है। बफर भंडारण के बारे में गुप्त ज्ञान का एक गुच्छा के साथ एक अपूरणीय व्यक्ति दिखाई दिया।

नया परिवहन

उन्होंने सभी ईवेंट डिलीवरी बिंदुओं से अवगत एक साझा परिवहन, ईएसपी बनाया। उन्होंने इसे स्वागत का एक बिंदु बना दिया। इससे सभी ईवेंट प्रवाह को नियंत्रित करना संभव हो गया। प्रोजेक्ट्स ने सीधे बफर स्टोरेज को एक्सेस करना बंद कर दिया।

प्रबुद्ध क्लिकस्ट्रीमिज्म

निर्देशिका के आधार पर, लैंगपैक्स उत्पन्न किए गए थे। वे अमान्य घटनाओं के निर्माण की अनुमति नहीं देते हैं।

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

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

निर्देशिका से मिलान करने के लिए एक सिस्टम मिला। बोनस: पारदर्शिता, प्रबंधन क्षमता, सृजन की गति और घटनाओं का परिवर्तन।

अंतभाषण

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

एक निर्देशिका बनाना एक बहुत अच्छा विचार था। वह सत्य का एकमात्र स्रोत बन गया, आप हमेशा उसे कोड की विसंगतियों के मामले में अपील कर सकते हैं। बहुत सारी स्वचालन निर्देशिका से जुड़ी है: चेक, ईवेंट रूटिंग, कोड जनरेशन।

इंफ्रास्ट्रक्चर को बिजनेस लॉजिक के बारे में जानने की जरूरत नहीं है। व्यावसायिक तर्क के उद्भव के संकेत: परियोजना के भंडार से रास्ते में घटनाएं बदल जाती हैं; बदलती परियोजनाओं के बिना परिवहन बदलना असंभव हो जाता है। बुनियादी ढाँचे पर, घटनाओं की संरचना, खेतों के प्रकार, उनकी अनिवार्यता के बारे में ज्ञान होना चाहिए। उत्पाद पक्ष पर, इन क्षेत्रों का तार्किक अर्थ।

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

बोल्ड विचारों के एक जोड़े हैं। उपयोगकर्ता संक्रमण का एक विस्तृत ग्राफ प्राप्त करना, सेवा को रोल किए बिना मक्खी पर घटनाओं को कॉन्फ़िगर करना। लेकिन इसके बारे में और अधिक निम्न लेखों में।

PS मैंने इस विषय पर बैकएंड यूनाइटेड # 1 मीटिंग में बात की। विनाईग्रेटे। देख सकते हैं
बैठक से प्रस्तुति या वीडियो ।