हमारे ओपन सोर्स का इतिहास: कैसे हमने गो में एक एनालिटिक्स सेवा बनाई और इसे सार्वजनिक रूप से उपलब्ध कराया

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

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

हमें अपनी स्वयं की सेवा क्यों विकसित करनी चाहिए?

यह नब्बे का दशक था, हम जैसे-तैसे बच सके। 2019, हमने एपीआई फर्स्ट कस्टमर डेटा प्लेटफ़ॉर्म विकसित किया केसेंस, जिसने अधिक सुविधाजनक डेटा विश्लेषण, निर्भरता की पहचान आदि के लिए विभिन्न स्रोतों (फेसबुक विज्ञापन, स्ट्राइप, सेल्सफोर्स, गूगल प्ले, गूगल एनालिटिक्स, आदि) से डेटा एकत्र करना संभव बना दिया। हमने देखा है कि कई उपयोगकर्ता डेटा विश्लेषण के लिए हमारे प्लेटफ़ॉर्म का उपयोग करते हैं, विशेष रूप से Google Analytics (इसके बाद GA)। हमने कुछ उपयोगकर्ताओं से बात की और पाया कि उन्हें अपने उत्पाद के लिए विश्लेषण डेटा की आवश्यकता है जो उन्हें GA का उपयोग करके प्राप्त होता है, लेकिन Google नमूना डेटा और कई लोगों के लिए, GA उपयोगकर्ता इंटरफ़ेस सुविधा का मानक नहीं है। हमने अपने उपयोगकर्ताओं के साथ पर्याप्त बातचीत की और महसूस किया कि कई लोग सेगमेंट प्लेटफ़ॉर्म का भी उपयोग कर रहे थे (जो, वैसे, अभी कुछ दिन पहले ही हुआ था) продана за 3.2 млрд$).

उन्होंने अपने वेब संसाधन पर एक सेगमेंट जावास्क्रिप्ट पिक्सेल स्थापित किया और उनके उपयोगकर्ताओं के व्यवहार के बारे में डेटा निर्दिष्ट डेटाबेस में लोड किया गया (उदाहरण के लिए पोस्टग्रेज)। लेकिन सेगमेंट का नकारात्मक पक्ष भी है - कीमत। उदाहरण के लिए, यदि किसी वेब संसाधन में 90,000 एमटीयू (मासिक ट्रैक किए गए उपयोगकर्ता) हैं, तो आपको कैशियर को प्रति माह ~1,000 डॉलर का भुगतान करना होगा। एक तीसरी समस्या भी थी - कुछ ब्राउज़र एक्सटेंशन (जैसे एडब्लॉक) ने एनालिटिक्स के संग्रह को अवरुद्ध कर दिया क्योंकि... ब्राउज़र से http अनुरोध GA और सेगमेंट डोमेन पर भेजे गए थे। अपने ग्राहकों की इच्छा के आधार पर, हमने एक एनालिटिक्स सेवा बनाई है जो डेटा का पूरा सेट एकत्र करती है (नमूना के बिना), मुफ़्त है और हमारे अपने बुनियादी ढांचे पर काम कर सकती है।

सेवा कैसे काम करती है

सेवा में तीन भाग होते हैं: एक जावास्क्रिप्ट पिक्सेल (जिसे हमने बाद में टाइपस्क्रिप्ट में फिर से लिखा), सर्वर भाग को GO भाषा में लागू किया गया है, और इन-हाउस डेटाबेस के रूप में Redshift और BigQuery का उपयोग करने की योजना बनाई गई थी (बाद में उन्होंने इसके लिए समर्थन जोड़ा) पोस्टग्रेज, क्लिकहाउस और स्नोफ्लेक)।

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

//'ga' - стандартное название переменной Google Analytics
if (window.ga) {
    ga(tracker => {
        var originalSendHitTask = tracker.get('sendHitTask');
        tracker.set('sendHitTask', (model) => {
            var payLoad = model.get('hitPayload');
            //отправка оригинального события в GA
            originalSendHitTask(model);
            let jsonPayload = this.parseQuery(payLoad);
            //отправка события в наш сервис
            this.send3p('ga', jsonPayload);
        });
    });
}

सेगमेंट पिक्सेल के साथ सब कुछ सरल है; इसमें मिडलवेयर विधियाँ हैं, जिनमें से एक का हमने उपयोग किया है।

//'analytics' - стандартное название переменной Segment
if (window.analytics) {
    if (window.analytics.addSourceMiddleware) {
        window.analytics.addSourceMiddleware(chain => {
            try {
		//дублирование события в наш сервис
                this.send3p('ajs', chain.payload);
            } catch (e) {
                LOG.warn('Failed to send an event', e)
            }
	    //отправка оригинального события в Segment
            chain.next(chain.payload);
        });
    } else {
        LOG.warn("Invalid interceptor state. Analytics js initialized, but not completely");
    }
} else {
    LOG.warn('Analytics.js listener is not set.');
}

घटनाओं की प्रतिलिपि बनाने के अलावा, हमने मनमाना json भेजने की क्षमता जोड़ी है:

//Отправка событий с произвольным json объектом
eventN.track('product_page_view', {
    product_id: '1e48fb70-ef12-4ea9-ab10-fd0b910c49ce',
    product_price: 399.99,
    price_currency: 'USD'
    product_release_start: '2020-09-25T12:38:27.763000Z'
});

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

//входящий json
{
  "field_1":  {
    "sub_field_1": "text1",
    "sub_field_2": 100
  },
  "field_2": "text2",
  "field_3": {
    "sub_field_1": {
      "sub_sub_field_1": "2020-09-25T12:38:27.763000Z"
    }
  }
}

//результат
{
  "field_1_sub_field_1":  "text1",
  "field_1_sub_field_2":  100,
  "field_2": "text2",
  "field_3_sub_field_1_sub_sub_field_1": "2020-09-25T12:38:27.763000Z"
}

हालाँकि, सरणियों को वर्तमान में केवल स्ट्रिंग्स में परिवर्तित किया जाता है क्योंकि सभी रिलेशनल डेटाबेस दोहराए गए फ़ील्ड का समर्थन नहीं करते हैं। वैकल्पिक मैपिंग नियमों का उपयोग करके फ़ील्ड नाम बदलना या उन्हें हटाना भी संभव है। यदि आवश्यक हो तो वे आपको डेटा स्कीमा बदलने या एक डेटा प्रकार को दूसरे में परिवर्तित करने की अनुमति देते हैं। उदाहरण के लिए, यदि किसी json फ़ील्ड में टाइमस्टैम्प के साथ एक स्ट्रिंग है (फ़ील्ड_3_उप_फ़ील्ड_1_उप_उप_फ़ील्ड_1 उपरोक्त उदाहरण से), फिर टाइमस्टैम्प प्रकार के साथ डेटाबेस में एक फ़ील्ड बनाने के लिए, आपको कॉन्फ़िगरेशन में एक मैपिंग नियम लिखना होगा। दूसरे शब्दों में, फ़ील्ड का डेटा प्रकार पहले json मान द्वारा निर्धारित किया जाता है, और फिर टाइप कास्टिंग नियम (यदि कॉन्फ़िगर किया गया है) लागू किया जाता है। हमने 4 मुख्य डेटा प्रकारों की पहचान की है: STRING, FLOAT64, INT64 और TIMESTAMP। मैपिंग और टाइप कास्टिंग नियम इस तरह दिखते हैं:

rules:
  - "/field_1/subfield_1 -> " #правило удаления поля
  - "/field_2/subfield_1 -> /field_10/subfield_1" #правило переноса поля
  - "/field_3/subfield_1/subsubfield_1 -> (timestamp) /field_20" #правило переноса поля и приведения типа

डेटा प्रकार निर्धारित करने के लिए एल्गोरिदम:

• json संरचना को समतल संरचना में बदलें
• मानों द्वारा फ़ील्ड के डेटा प्रकार का निर्धारण करना
• मैपिंग और टाइप कास्टिंग नियम लागू करना

फिर आने वाली json संरचना से:

{
    "product_id":  "1e48fb70-ef12-4ea9-ab10-fd0b910c49ce",
    "product_price": 399.99,
    "price_currency": "USD",
    "product_type": "supplies",
    "product_release_start": "2020-09-25T12:38:27.763000Z",
    "images": {
      "main": "picture1",
      "sub":  "picture2"
    }
}

डेटा स्कीमा प्राप्त किया जाएगा:

"product_id" character varying,
"product_price" numeric (38,18),
"price_currency" character varying,
"product_type" character varying,
"product_release_start" timestamp,
"images_main" character varying,
"images_sub" character varying

हमने यह भी सोचा कि उपयोगकर्ता को अन्य मानदंडों के अनुसार डेटाबेस में विभाजन को कॉन्फ़िगर करने या डेटा को विभाजित करने में सक्षम होना चाहिए और तालिका नाम को स्थिरांक के साथ सेट करने की क्षमता लागू करनी चाहिए अभिव्यक्ति कॉन्फ़िगरेशन में. नीचे दिए गए उदाहरण में, ईवेंट को product_type और _timestamp फ़ील्ड के मानों के आधार पर गणना किए गए नाम के साथ एक तालिका में सहेजा जाएगा (उदाहरण के लिए) आपूर्ति_2020_10):

tableName: '{{.product_type}}_{{._timestamp.Format "2006_01"}}'

हालाँकि, आने वाली घटनाओं की संरचना रनटाइम पर बदल सकती है। हमने मौजूदा तालिका की संरचना और आने वाली घटना की संरचना के बीच अंतर की जांच करने के लिए एक एल्गोरिदम लागू किया है। यदि कोई अंतर पाया जाता है, तो तालिका को नए फ़ील्ड के साथ अद्यतन किया जाएगा। ऐसा करने के लिए, पैच SQL क्वेरी का उपयोग करें:

#Пример для Postgres
ALTER TABLE "schema"."table" ADD COLUMN new_column character varying

आर्किटेक्चर

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

खुला स्रोत और भविष्य की योजनाएँ

कुछ बिंदु पर, सेवा एक पूर्ण उत्पाद की तरह दिखने लगी और हमने इसे ओपन सोर्स पर जारी करने का निर्णय लिया। वर्तमान में, Postgres, ClickHouse, BigQuery, Redshift, S3, स्नोफ्लेक के साथ एकीकरण लागू किया गया है। सभी एकीकरण डेटा लोडिंग के बैच और स्ट्रीमिंग मोड दोनों का समर्थन करते हैं। एपीआई के माध्यम से अनुरोधों के लिए समर्थन जोड़ा गया।

वर्तमान एकीकरण योजना इस प्रकार दिखती है:

हालाँकि सेवा का उपयोग स्वतंत्र रूप से किया जा सकता है (उदाहरण के लिए डॉकर का उपयोग करके), हमारे पास भी है होस्ट किया गया संस्करण, जिसमें आप डेटा वेयरहाउस के साथ एकीकरण स्थापित कर सकते हैं, अपने डोमेन में एक CNAME जोड़ सकते हैं और घटनाओं की संख्या पर आंकड़े देख सकते हैं। हमारी तत्काल योजना न केवल वेब संसाधन से आंकड़ों को एकत्रित करने की क्षमता जोड़ने की है, बल्कि बाहरी डेटा स्रोतों से डेटा भी जोड़ने और उन्हें आपकी पसंद के किसी भी भंडारण में सहेजने की है!

→ GitHub
→ अभिलेख
→ सुस्त

अगर इवेंटनेटिव आपकी समस्याओं को हल करने में मदद करता है तो हमें खुशी होगी!

केवल पंजीकृत उपयोगकर्ता ही सर्वेक्षण में भाग ले सकते हैं। साइन इन करेंकृपया।

आपकी कंपनी में कौन सी सांख्यिकी संग्रहण प्रणाली का उपयोग किया जाता है?

• 48,0% तक गूगल एनालिटिक्स12

• 4,0% तक खंड 1

• 16,0% तक एक और (टिप्पणियों में लिखें)4

• 32,0% तक अपनी सेवा कार्यान्वित की8

25 उपयोगकर्ताओं ने मतदान किया। 6 उपयोगकर्ता अनुपस्थित रहे।

स्रोत: www.habr.com