आमच्या मुक्त स्रोताचा इतिहास: आम्ही Go मध्ये विश्लेषण सेवा कशी बनवली आणि ती सार्वजनिकरीत्या उपलब्ध करून दिली

सध्या, जगातील जवळजवळ प्रत्येक कंपनी वेब संसाधनावरील वापरकर्त्याच्या क्रियांची आकडेवारी गोळा करते. प्रेरणा स्पष्ट आहे - कंपन्यांना त्यांचे उत्पादन/वेबसाइट कशी वापरली जाते हे जाणून घ्यायचे आहे आणि त्यांच्या वापरकर्त्यांना अधिक चांगल्या प्रकारे समजून घ्यायचे आहे. अर्थात, या समस्येचे निराकरण करण्यासाठी बाजारात मोठ्या प्रमाणात साधने आहेत - विश्लेषण प्रणालींमधून जे डॅशबोर्ड आणि आलेखांच्या स्वरूपात डेटा प्रदान करतात (उदाहरणार्थ Google Analytics मध्ये) कडे ग्राहक डेटा प्लॅटफॉर्म, जे तुम्हाला कोणत्याही वेअरहाऊसमधील विविध स्त्रोतांकडून डेटा संकलित आणि एकत्रित करण्याची परवानगी देते (उदाहरणार्थ विभाग).

परंतु आम्हाला एक समस्या आढळली जी अद्याप सोडविली गेली नाही. अशा प्रकारे जन्म झाला इव्हेंटनेटिव्ह - मुक्त स्रोत विश्लेषण सेवा. आम्ही आमची स्वतःची सेवा विकसित करण्याचा निर्णय का घेतला, यामुळे आम्हाला काय मिळाले आणि अंतिम परिणाम काय झाला याबद्दल वाचा (कोडच्या तुकड्यांसह).

आपण स्वतःची सेवा का विकसित करावी?

नव्वदचे दशक होते, आम्ही शक्य तितके टिकून राहिलो. 2019, आम्ही API प्रथम ग्राहक डेटा प्लॅटफॉर्म विकसित केला kSense, ज्यामुळे अधिक सोयीस्कर डेटा विश्लेषण, अवलंबित्व ओळखणे इत्यादीसाठी विविध स्त्रोतांकडून डेटा एकत्रित करणे शक्य झाले (फेसबुक जाहिराती, स्ट्राइप, सेल्सफोर्स, Google प्ले, Google Analytics, इ.). आमच्या लक्षात आले आहे की बरेच वापरकर्ते आमच्या प्लॅटफॉर्मचा वापर डेटा विश्लेषणासाठी करतात विशेषत: Google Analytics (यापुढे GA). आम्ही काही वापरकर्त्यांशी बोललो आणि आम्हाला आढळले की त्यांना त्यांच्या उत्पादनासाठी विश्लेषण डेटा आवश्यक आहे जो ते GA वापरून प्राप्त करतात, परंतु Google नमुने डेटा आणि अनेकांसाठी, GA वापरकर्ता इंटरफेस हे सोयीचे मानक नाही. आम्ही आमच्या वापरकर्त्यांशी पुरेशी संभाषणे केली आणि लक्षात आले की बरेच लोक सेगमेंट प्लॅटफॉर्म देखील वापरत आहेत (जे, तसे, दुसऱ्या दिवशी होते $3.2 अब्ज विकले गेले).

त्यांनी त्यांच्या वेब संसाधनावर सेगमेंट जावास्क्रिप्ट पिक्सेल स्थापित केला आणि त्यांच्या वापरकर्त्यांच्या वर्तनाबद्दलचा डेटा निर्दिष्ट डेटाबेसमध्ये लोड केला गेला (उदाहरणार्थ पोस्टग्रेस). परंतु सेगमेंटला देखील त्याची कमतरता आहे - किंमत. उदाहरणार्थ, वेब संसाधनामध्ये 90,000 MTU (मासिक ट्रॅक केलेले वापरकर्ते) असल्यास, तुम्हाला दरमहा ~1,000 $ कॅशियरला भरावे लागतील. तिसरी समस्या देखील होती - काही ब्राउझर विस्तारांनी (जसे की AdBlock) विश्लेषणाचे संकलन अवरोधित केले कारण... ब्राउझरकडून http विनंत्या GA आणि सेगमेंट डोमेनवर पाठवल्या गेल्या. आमच्या क्लायंटच्या इच्छेनुसार, आम्ही एक विश्लेषण सेवा तयार केली आहे जी डेटाचा संपूर्ण संच (नमुने न घेता) संकलित करते, विनामूल्य आहे आणि आमच्या स्वतःच्या पायाभूत सुविधांवर कार्य करू शकते.

सेवा कशी कार्य करते

सेवेमध्ये तीन भाग असतात: एक जावास्क्रिप्ट पिक्सेल (जे आम्ही नंतर टाइपस्क्रिप्टमध्ये पुन्हा लिहिले), सर्व्हरचा भाग GO भाषेत लागू केला जातो आणि Redshift आणि BigQuery चा इन-हाउस डेटाबेस म्हणून वापर करण्याची योजना होती (नंतर त्यांनी यासाठी समर्थन जोडले. पोस्टग्रेस, क्लिकहाऊस आणि स्नोफ्लेक).

GA आणि सेगमेंट इव्हेंटची रचना अपरिवर्तित ठेवण्याचा निर्णय घेण्यात आला. आमच्या बॅकएंडवर पिक्सेल स्थापित केलेल्या वेब संसाधनावरील सर्व इव्हेंटची डुप्लिकेट करणे आवश्यक होते. तो बाहेर वळते म्हणून, हे करणे कठीण नाही आहे. JavaScript पिक्सेलने मूळ 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 विनंत्या स्वीकारल्या पाहिजेत, त्यांना अतिरिक्त माहिती भरा, उदाहरणार्थ, भौगोलिक डेटा (धन्यवाद maxmind यासाठी) आणि डेटाबेसमध्ये रेकॉर्ड करा. आम्हाला सेवा शक्य तितकी सोयीस्कर बनवायची होती जेणेकरून ती कमीतकमी कॉन्फिगरेशनसह वापरली जाऊ शकते. आम्ही येणार्‍या 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_sub_field_1_sub_sub_field_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 संरचनेतून:

{
    "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

आम्ही असेही विचार केला की वापरकर्त्याने विभाजन कॉन्फिगर करणे किंवा डेटाबेसमधील डेटा इतर निकषांनुसार विभाजित करण्यास सक्षम असावे आणि टेबलचे नाव स्थिर किंवा स्थिरतेसह सेट करण्याची क्षमता लागू केली. अभिव्यक्ती कॉन्फिगरेशन मध्ये. खालील उदाहरणामध्ये, उत्पादन_प्रकार आणि _टाइमस्टॅम्प फील्डच्या मूल्यांवर आधारित गणना केलेल्या नावासह इव्हेंट टेबलवर सेव्ह केला जाईल (उदाहरणार्थ पुरवठा_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, Snowflake सह एकत्रीकरण लागू केले आहे. सर्व एकत्रीकरण डेटा लोडिंगच्या बॅच आणि स्ट्रीमिंग मोड्सना समर्थन देतात. API द्वारे विनंत्यांसाठी समर्थन जोडले.

सध्याची एकत्रीकरण योजना असे दिसते:

जरी सेवा स्वतंत्रपणे वापरली जाऊ शकते (उदाहरणार्थ डॉकर वापरणे), आमच्याकडे देखील आहे होस्ट केलेली आवृत्ती, ज्यामध्ये तुम्ही डेटा वेअरहाऊससह एकत्रीकरण सेट करू शकता, तुमच्या डोमेनमध्ये एक CNAME जोडा आणि इव्हेंटच्या संख्येवर आकडेवारी पाहू शकता. आमची तात्काळ योजना केवळ वेब संसाधनातील आकडेवारीच नाही तर बाह्य डेटा स्रोतांमधील डेटा देखील एकत्रित करण्याची क्षमता जोडण्याची आणि तुमच्या आवडीच्या कोणत्याही स्टोरेजमध्ये जतन करण्याची आहे!

→ GitHub
→ दस्तऐवजीकरण
→ मंदीचा काळ

EventNative तुमच्या समस्यांचे निराकरण करण्यात मदत करत असल्यास आम्हाला आनंद होईल!

केवळ नोंदणीकृत वापरकर्तेच सर्वेक्षणात भाग घेऊ शकतात. साइन इन करा, आपले स्वागत आहे.

तुमच्या कंपनीमध्ये कोणती आकडेवारी संकलन प्रणाली वापरली जाते?

• 48,0%गूगल Xनालिटिक्सएक्सयूएनएमएक्स

• 4,0%विभाग १

• 16,0%दुसरा (टिप्पण्यांमध्ये लिहा) 4

• 32,0%तुमची सेवा लागू केली

25 वापरकर्त्यांनी मतदान केले. 6 वापरकर्ते दूर राहिले.

स्त्रोत: www.habr.com