हमने ऑनलाइन साइटों से विज्ञापन अभियानों पर डेटा कैसे एकत्र किया (उत्पाद तक का कांटेदार रास्ता)

ऐसा लगता है कि ऑनलाइन विज्ञापन का क्षेत्र यथासंभव तकनीकी रूप से उन्नत और स्वचालित होना चाहिए। बेशक, क्योंकि Yandex, Mail.Ru, Google और Facebook जैसे अपने क्षेत्र के दिग्गज और विशेषज्ञ वहां काम करते हैं। लेकिन, जैसा कि यह निकला, पूर्णता की कोई सीमा नहीं है और स्वचालित करने के लिए हमेशा कुछ न कुछ होता है।

स्रोत

संचार समूह डेंटसु एजिस नेटवर्क रूस डिजिटल विज्ञापन बाज़ार में सबसे बड़ा खिलाड़ी है और सक्रिय रूप से प्रौद्योगिकी में निवेश कर रहा है, अपनी व्यावसायिक प्रक्रियाओं को अनुकूलित और स्वचालित करने का प्रयास कर रहा है। ऑनलाइन विज्ञापन बाज़ार की अनसुलझी समस्याओं में से एक विभिन्न इंटरनेट प्लेटफ़ॉर्म से विज्ञापन अभियानों पर आँकड़े एकत्र करने का कार्य बन गया है। इस समस्या के समाधान के परिणामस्वरूप अंततः एक उत्पाद का निर्माण हुआ D1.डिजिटल (दीवान के रूप में पढ़ें), जिसके विकास के बारे में हम बात करना चाहते हैं।

क्यों?

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

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

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

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

2. ऑनलाइन विज्ञापन बाजार साल-दर-साल बढ़ रहा है और 2018 में विज्ञापन बजट के मामले में इसने पारंपरिक रूप से सबसे बड़े टीवी विज्ञापन बाजार को पीछे छोड़ दिया। तो एक पैमाना है.

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

4. हमें ऐसा लगा कि इंटरनेट पर विज्ञापन सूची के मालिकों के पास आंकड़े एकत्र करने और उन्हें विज्ञापन खातों में प्रदर्शित करने के लिए पहले से ही बुनियादी ढांचा है, और वे इस डेटा के लिए एक एपीआई प्रदान करने में सक्षम होंगे। इसका मतलब यह है कि इसे लागू करना तकनीकी रूप से संभव है। आइए तुरंत कहें कि यह इतना आसान नहीं निकला।

सामान्य तौर पर, परियोजना के कार्यान्वयन के लिए सभी पूर्वापेक्षाएँ हमारे लिए स्पष्ट थीं, और हम परियोजना को जीवन में लाने के लिए दौड़ पड़े...

भव्य योजना

आरंभ करने के लिए, हमने एक आदर्श प्रणाली का एक दृष्टिकोण बनाया:

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

पहला पैनकेक गड़बड़ है

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

एमवीपी के लिए, कार्यान्वयन के संदर्भ में परियोजना को यथासंभव सरल बनाया गया था। हमने एकीकरण के लिए प्लेटफार्मों की एक सीमित सूची का चयन किया है। ये मुख्य प्लेटफ़ॉर्म थे, जैसे Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB, और मुख्य विज्ञापन सिस्टम Adriver और Weborama।

एपीआई के माध्यम से साइटों पर आंकड़ों तक पहुंचने के लिए, हमने एक एकल खाते का उपयोग किया। एक ग्राहक समूह प्रबंधक जो किसी विज्ञापन अभियान पर आँकड़ों के स्वचालित संग्रह का उपयोग करना चाहता था, उसे पहले साइटों पर आवश्यक विज्ञापन अभियानों तक पहुँच को प्लेटफ़ॉर्म खाते में सौंपना पड़ता था।

अगला सिस्टम उपयोगकर्ता है DANBo एक्सेल सिस्टम में एक निश्चित प्रारूप की एक फ़ाइल अपलोड करनी थी, जिसमें प्लेसमेंट (विज्ञापन अभियान, प्लेटफ़ॉर्म, प्रारूप, प्लेसमेंट अवधि, नियोजित संकेतक, बजट इत्यादि) और संबंधित विज्ञापन अभियानों के पहचानकर्ताओं के बारे में सारी जानकारी शामिल थी। विज्ञापन प्रणालियों में साइटें और काउंटर।

यह स्पष्ट रूप से, भयानक लग रहा था:

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

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

डाउनलोड किया गया डेटा एक छोटे कस्टम डैशबोर्ड के रूप में इंटरफ़ेस पर प्रदर्शित किया गया था:

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

• मुख्य समस्या सिस्टम में लोड करने के लिए डेटा तैयार करने की जटिलता थी। साथ ही, प्लेसमेंट डेटा को लोड करने से पहले एक निश्चित प्रारूप में परिवर्तित करना पड़ता था। डाउनलोड फ़ाइल में विभिन्न साइटों से इकाई पहचानकर्ताओं को शामिल करना आवश्यक था। हमें इस तथ्य का सामना करना पड़ रहा है कि तकनीकी रूप से अप्रशिक्षित उपयोगकर्ताओं के लिए यह समझाना बहुत मुश्किल है कि साइट पर इन पहचानकर्ताओं को कहां ढूंढें और फ़ाइल में उन्हें कहां दर्ज करने की आवश्यकता है। साइटों पर अभियान चलाने वाले विभागों में कर्मचारियों की संख्या और टर्नओवर को ध्यान में रखते हुए, इसके परिणामस्वरूप हमारी ओर से भारी मात्रा में समर्थन मिला, जिससे हम बिल्कुल खुश नहीं थे।
• एक और समस्या यह थी कि सभी विज्ञापन प्लेटफार्मों में विज्ञापन अभियानों तक पहुंच अन्य खातों को सौंपने की व्यवस्था नहीं थी। लेकिन भले ही एक प्रतिनिधिमंडल तंत्र उपलब्ध था, सभी विज्ञापनदाता अपने अभियानों को तीसरे पक्ष के खातों तक पहुंच प्रदान करने के इच्छुक नहीं थे।
• एक महत्वपूर्ण कारक वह आक्रोश था जो उपयोगकर्ताओं के बीच इस तथ्य से उत्पन्न हुआ कि सभी नियोजित संकेतक और प्लेसमेंट विवरण जो वे पहले से ही हमारी 1सी लेखा प्रणाली में दर्ज करते हैं, उन्हें फिर से दर्ज करना होगा DANBo.

इससे हमें यह विचार आया कि प्लेसमेंट के बारे में जानकारी का प्राथमिक स्रोत हमारा 1C सिस्टम होना चाहिए, जिसमें सभी डेटा सटीक और समय पर दर्ज किया जाता है (यहां मुद्दा यह है कि चालान 1C डेटा के आधार पर तैयार किए जाते हैं, इसलिए 1C में डेटा की सही प्रविष्टि होती है) प्रत्येक KPI के लिए प्राथमिकता है)। इस तरह सिस्टम की एक नई अवधारणा सामने आई...

संकल्पना

पहली चीज़ जो हमने करने का निर्णय लिया वह इंटरनेट पर विज्ञापन अभियानों पर आँकड़े एकत्र करने की प्रणाली को एक अलग उत्पाद में अलग करना था - D1.डिजिटल.

नई अवधारणा में, हमने लोड करने का निर्णय लिया D1.डिजिटल 1सी से विज्ञापन अभियानों और उनके भीतर प्लेसमेंट की जानकारी, और फिर साइटों और विज्ञापन सेवा प्रणालियों से आंकड़ों को इन प्लेसमेंट तक खींचें। यह उपयोगकर्ताओं के लिए जीवन को काफी सरल बनाने (और, हमेशा की तरह, डेवलपर्स के लिए अधिक काम जोड़ने) और समर्थन की मात्रा को कम करने वाला था।

हमारे सामने आई पहली समस्या संगठनात्मक प्रकृति की थी और इस तथ्य से संबंधित थी कि हमें कोई कुंजी या संकेत नहीं मिल सका जिसके द्वारा हम 1C के अभियानों और प्लेसमेंट के साथ विभिन्न प्रणालियों की संस्थाओं की तुलना कर सकें। तथ्य यह है कि हमारी कंपनी में प्रक्रिया इस तरह से डिज़ाइन की गई है कि विज्ञापन अभियान अलग-अलग सिस्टम में अलग-अलग लोगों (मीडिया प्लानर, खरीदारी आदि) द्वारा दर्ज किए जाते हैं।

इस समस्या को हल करने के लिए, हमें एक अद्वितीय हैश कुंजी, DANBoID का आविष्कार करना पड़ा, जो विभिन्न प्रणालियों में इकाइयों को एक साथ जोड़ेगी, और जिसे डाउनलोड किए गए डेटा सेट में काफी आसानी से और विशिष्ट रूप से पहचाना जा सकता है। यह पहचानकर्ता प्रत्येक व्यक्तिगत प्लेसमेंट के लिए आंतरिक 1C सिस्टम में उत्पन्न होता है और सभी साइटों और सभी विज्ञापन प्रणालियों में अभियानों, प्लेसमेंट और काउंटरों पर स्थानांतरित किया जाता है। सभी प्लेसमेंट में DANBoID लगाने की प्रथा को लागू करने में कुछ समय लगा, लेकिन हम इसे करने में कामयाब रहे :)

तब हमें पता चला कि सभी साइटों में स्वचालित रूप से आंकड़े एकत्र करने के लिए एपीआई नहीं है, और यहां तक ​​कि जिनके पास एपीआई है, वह सभी आवश्यक डेटा वापस नहीं करता है।

इस स्तर पर, हमने एकीकरण के लिए प्लेटफार्मों की सूची को महत्वपूर्ण रूप से कम करने और मुख्य प्लेटफार्मों पर ध्यान केंद्रित करने का निर्णय लिया जो अधिकांश विज्ञापन अभियानों में शामिल हैं। इस सूची में विज्ञापन बाज़ार (Google, Yandex, Mail.ru), सोशल नेटवर्क (VK, Facebook, Twitter), प्रमुख AdServing और एनालिटिक्स सिस्टम (DCM, Adriver, Weborama, Google Analytics) और अन्य प्लेटफ़ॉर्म के सभी सबसे बड़े खिलाड़ी शामिल हैं।

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

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

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

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

लेख में बाद में हम समाधान की वास्तुकला और कार्यान्वयन के तकनीकी विवरण का अधिक विस्तार से वर्णन करने का प्रयास करेंगे।

समाधान वास्तुकला 1.0

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

आर्किटेक्चर को डिज़ाइन करते समय, हमने सभी बाहरी सिस्टम - 1C, विज्ञापन प्लेटफ़ॉर्म और विज्ञापन सिस्टम - के कनेक्टर्स को अलग-अलग सेवाओं में अलग कर दिया।
मुख्य विचार यह है कि साइटों के सभी कनेक्टरों में एक ही एपीआई होती है और वे एडाप्टर होते हैं जो साइट एपीआई को हमारे लिए सुविधाजनक इंटरफ़ेस में लाते हैं।

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

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

विकास की सरलता और गति के लिए, हमने यह भी निर्णय लिया कि सभी सेवाएँ वेब एपीआई होंगी। इससे प्रूफ-ऑफ-कॉन्सेप्ट को तुरंत इकट्ठा करना और यह सत्यापित करना संभव हो गया कि संपूर्ण डिज़ाइन काम करता है।

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

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

साइटों पर मौजूद अनुरोध सीमाओं का अनुपालन करने के लिए, हम सेटिंग्स के अनुरोधों को एक टोकन के भीतर जोड़ते हैं, लेकिन हम समानांतर में विभिन्न टोकन संसाधित कर सकते हैं।

हमने वेब एप्लिकेशन और कनेक्टर्स दोनों के लिए लोड किए गए डेटा के भंडारण के रूप में MongoDB को चुना, जिससे हमें विकास के प्रारंभिक चरणों में डेटा संरचना के बारे में बहुत अधिक चिंता करने की अनुमति नहीं मिली, जब एप्लिकेशन का ऑब्जेक्ट मॉडल हर दूसरे दिन बदलता है।

हमें जल्द ही पता चला कि सभी डेटा MongoDB में अच्छी तरह से फिट नहीं होते हैं और, उदाहरण के लिए, दैनिक आंकड़ों को एक रिलेशनल डेटाबेस में संग्रहीत करना अधिक सुविधाजनक है। इसलिए, उन कनेक्टर्स के लिए जिनकी डेटा संरचना रिलेशनल डेटाबेस के लिए अधिक उपयुक्त है, हमने स्टोरेज के रूप में PostgreSQL या MS SQL सर्वर का उपयोग करना शुरू कर दिया है।

चुनी गई वास्तुकला और प्रौद्योगिकियों ने हमें अपेक्षाकृत तेज़ी से D1.Digital उत्पाद बनाने और लॉन्च करने की अनुमति दी। उत्पाद विकास के दो वर्षों में, हमने साइटों के लिए 23 कनेक्टर विकसित किए, तृतीय-पक्ष एपीआई के साथ काम करने का अमूल्य अनुभव प्राप्त किया, विभिन्न साइटों के नुकसान से बचना सीखा, जिनमें से प्रत्येक की अपनी-अपनी साइटें थीं, कम से कम 3 एपीआई के विकास में योगदान दिया। साइटों ने लगभग 15 अभियानों और 000 से अधिक प्लेसमेंट पर स्वचालित रूप से जानकारी डाउनलोड की, उत्पाद के संचालन पर उपयोगकर्ताओं से बहुत सारी प्रतिक्रिया एकत्र की और इस प्रतिक्रिया के आधार पर उत्पाद की मुख्य प्रक्रिया को कई बार बदलने में कामयाब रही।

समाधान वास्तुकला 2.0

विकास शुरू हुए दो साल बीत चुके हैं D1.डिजिटल. सिस्टम पर लोड में लगातार वृद्धि और अधिक से अधिक नए डेटा स्रोतों के उद्भव से धीरे-धीरे मौजूदा समाधान वास्तुकला में समस्याएं सामने आईं।

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

इस समस्या को हल करने के लिए, हमने साइटों से डेटा डाउनलोड करने के लिए सभी प्रकार की रिपोर्टों का उपयोग करना शुरू कर दिया, हम साइटों के साथ मिलकर उनके एपीआई को विकसित करने का प्रयास कर रहे हैं ताकि इसके संचालन की गति हमारी आवश्यकताओं को पूरा कर सके, और डेटा डाउनलोड को यथासंभव समानांतर बना सके।

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

उत्पाद के आगे के विकास के लिए पहचानी गई समस्याओं और महत्वाकांक्षी योजनाओं ने हमें एप्लिकेशन आर्किटेक्चर पर पुनर्विचार करने की आवश्यकता के लिए प्रेरित किया।

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

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

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

कनेक्टर्स के बाद, हमने बाकी एप्लिकेशन के आर्किटेक्चर को बदलने का फैसला किया।
मुख्य समस्या यह थी कि डेटा बड़े बैचों में कनेक्टर्स से प्रॉक्सी तक आता है, और फिर DANBoID पर हिट होता है और प्रसंस्करण के लिए केंद्रीय वेब एप्लिकेशन को भेजा जाता है। बड़ी संख्या में मेट्रिक्स पुनर्गणना के कारण, एप्लिकेशन पर बड़ा भार पड़ता है।

व्यक्तिगत डेटा संग्रह कार्यों की स्थिति की निगरानी करना और केंद्रीय वेब एप्लिकेशन के कनेक्टर्स के भीतर होने वाली त्रुटियों की रिपोर्ट करना भी काफी कठिन साबित हुआ ताकि उपयोगकर्ता देख सकें कि क्या हो रहा था और डेटा क्यों एकत्र नहीं किया जा रहा था।

इन समस्याओं को हल करने के लिए, हमने आर्किटेक्चर 2.0 विकसित किया।

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

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

साथ ही, हम समाधान को स्केल करने में आसान और प्रबंधित करने में अधिक सुविधाजनक बनाने के लिए सभी सेवाओं और एप्लिकेशन को डॉकर और कुबेरनेट्स में स्थानांतरित कर रहे हैं।

अब हम कहां हैं

प्रूफ़-ऑफ़-कॉन्सेप्ट आर्किटेक्चर 2.0 उत्पाद D1.डिजिटल कनेक्टर्स के सीमित सेट के साथ परीक्षण वातावरण में तैयार और काम कर रहा है। बस इतना करना बाकी है कि अन्य 20 कनेक्टर्स को एक नए प्लेटफ़ॉर्म पर फिर से लिखें, परीक्षण करें कि डेटा सही ढंग से लोड किया गया है और सभी मेट्रिक्स की गणना सही ढंग से की गई है, और पूरे डिज़ाइन को उत्पादन में रोल आउट करें।

वास्तव में, यह प्रक्रिया धीरे-धीरे होगी और हमें सबकुछ चालू रखने के लिए पुराने एपीआई के साथ बैकवर्ड संगतता छोड़नी होगी।

हमारी तात्कालिक योजनाओं में नए कनेक्टर्स का विकास, नए सिस्टम के साथ एकीकरण और कनेक्टेड साइटों और एडसर्विंग सिस्टम से डाउनलोड किए गए डेटा के सेट में अतिरिक्त मेट्रिक्स जोड़ना शामिल है।

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

एक अन्य विचार आँकड़ों को संग्रहीत करने के लिए डेटाबेस की पसंद के साथ प्रयोग करना है, जो वर्तमान में MongoDB में संग्रहीत है। हमने पहले ही कई नए कनेक्टर्स को SQL डेटाबेस में स्थानांतरित कर दिया है, लेकिन वहां अंतर लगभग ध्यान देने योग्य नहीं है, और दिन के अनुसार एकत्रित आंकड़ों के लिए, जिसे एक मनमानी अवधि के लिए अनुरोध किया जा सकता है, लाभ काफी गंभीर हो सकता है।

सामान्य तौर पर, योजनाएँ भव्य हैं, आइए आगे बढ़ें :)

लेख के लेखक आर एंड डी डेंटसु एजिस नेटवर्क रूस: जॉर्जी ओस्टापेंको (शमीगा), मिखाइल कोत्सिक (हिटएक्सएक्स)

स्रोत: www.habr.com