हाम्रो खुला स्रोतको इतिहास: हामीले Go मा कसरी एनालिटिक्स सेवा बनायौं र यसलाई सार्वजनिक रूपमा उपलब्ध गरायौं

हाल, संसारमा लगभग हरेक कम्पनीले वेब स्रोतमा प्रयोगकर्ता कार्यहरूको बारेमा तथ्याङ्क सङ्कलन गर्दछ। प्रेरणा स्पष्ट छ - कम्पनीहरू जान्न चाहन्छन् कि तिनीहरूको उत्पादन/वेबसाइट कसरी प्रयोग भइरहेको छ र उनीहरूका प्रयोगकर्ताहरूलाई अझ राम्रोसँग बुझ्न चाहन्छन्। निस्सन्देह, यो समस्या समाधान गर्न बजारमा धेरै उपकरणहरू छन् - ड्यासबोर्ड र ग्राफको रूपमा डेटा प्रदान गर्ने विश्लेषण प्रणालीहरूबाट (उदाहरणका लागि, Google विश्लेषण) ग्राहक डेटा प्लेटफर्ममा, जसले तपाईंलाई कुनै पनि भण्डारणमा विभिन्न स्रोतहरूबाट डेटा सङ्कलन र जम्मा गर्न अनुमति दिन्छ (उदाहरणका लागि, खण्ड).

तर हामीले एउटा समस्या भेट्टायौं जुन अहिलेसम्म समाधान हुन सकेको छैन। त्यसैले जन्मियो घटना नेटिभ - खुला स्रोत विश्लेषण सेवा। हामी किन हाम्रो आफ्नै सेवा विकास गर्न गयौं, यसले हामीलाई के दियो र अन्तमा के भयो (कोडका टुक्राहरू सहित), काटिएको तल पढ्नुहोस्।

हामीले किन आफ्नै सेवा विकास गर्नुपर्छ?

यो नब्बेको दशक थियो, हामी सकेसम्म बाँच्यौं। 2019, हामीले पहिलो ग्राहक डेटा प्लेटफर्म API को विकास गर्यौं kSense, जसले विभिन्न स्रोतहरू (फेसबुक विज्ञापनहरू, स्ट्राइप, सेल्सफोर्स, गुगल प्ले, गुगल एनालिटिक्स, इत्यादि) बाट थप सुविधाजनक डेटा विश्लेषण, निर्भरताहरू पहिचान गर्ने इत्यादिका लागि डेटा जम्मा गर्न अनुमति दियो। हामीले देखेका छौं कि धेरै प्रयोगकर्ताहरूले हाम्रो डेटा एनालिटिक्स प्लेटफर्म प्रयोग गर्छन्, विशेष गरी गुगल एनालिटिक्स (यसपछि GA भनिन्छ)। हामीले केही प्रयोगकर्ताहरूसँग कुरा गर्यौं र पत्ता लगायौं कि उनीहरूलाई उनीहरूको उत्पादन विश्लेषण डेटा चाहिन्छ, जुन उनीहरूले GA प्रयोग गरेर प्राप्त गर्छन्, तर Google नमूना डेटा र धेरैका लागि GA प्रयोगकर्ता इन्टरफेस सुविधाको मानक होइन। हामीले हाम्रा प्रयोगकर्ताहरूसँग पर्याप्त कुराकानी गरेका थियौं र महसुस गर्‍यौं कि धेरैले सेगमेन्ट प्लेटफर्म पनि प्रयोग गरेका थिए (जुन, वैसे, केही दिन अघि मात्र थियो। $ 3.2 बिलियन को लागी बेचेको छ).

तिनीहरूले तिनीहरूको वेब संसाधनमा खण्ड जाभास्क्रिप्ट पिक्सेल स्थापना गरे र तिनीहरूको प्रयोगकर्ता व्यवहार डेटा निर्दिष्ट डाटाबेस (जस्तै Postgres) मा लोड गरियो। तर खण्डको पनि यसको माइनस छ - मूल्य। उदाहरणका लागि, यदि वेब स्रोतमा 90,000 MTU (मासिक ट्र्याक गरिएका प्रयोगकर्ताहरू) छ भने, तपाईंले क्यासियरलाई प्रति महिना ~ $ 1,000 तिर्नु पर्छ। त्यहाँ तेस्रो समस्या पनि थियो - केहि ब्राउजर विस्तारहरू (जस्तै AdBlock) ले विश्लेषणहरूको सङ्कलन अवरुद्ध गर्यो। ब्राउजरबाट http अनुरोधहरू GA र खण्ड डोमेनहरूमा पठाइयो। हाम्रा ग्राहकहरूको इच्छाको आधारमा, हामीले एक एनालिटिक्स सेवा सिर्जना गरेका छौं जसले डेटाको पूर्ण सेट (नमूना बिना) सङ्कलन गर्दछ, नि:शुल्क र हाम्रो आफ्नै पूर्वाधारमा काम गर्न सक्छ।

सेवा कसरी काम गर्दछ

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

घटनाहरू GA र खण्डको संरचना अपरिवर्तित छोड्ने निर्णय गरियो। हाम्रो ब्याकइन्डमा पिक्सेल स्थापना भएको वेब स्रोतबाट सबै घटनाहरू डुप्लिकेट गर्न आवश्यक थियो। यो बाहिर जान्छ, यो गर्न सजिलो छ। जाभास्क्रिप्ट पिक्सेलले हाम्रो प्रणालीमा घटनाको नक्कल गर्ने नयाँसँग मूल 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_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 struct लाई flat struct मा रूपान्तरण गर्नुहोस्
• मानहरूद्वारा फिल्डहरूको डेटा प्रकार निर्धारण गर्दै
• म्यापिङ र टाइप कास्टिङ नियमहरू लागू गर्दै

त्यसपछि आगमन 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 सिफारिसहरू)। यो गर्नको लागि, लगरले फाइलमा आगमन घटनाहरू लेख्छ र पहिले नै छुट्टै गोराउटिन (थ्रेड) मा फाइल रिडरले फाइल पढ्छ, त्यसपछि डेटा योजनाको रूपान्तरण र परिभाषा हुन्छ। तालिका प्रबन्धकले तालिका स्किमा अप-टु-डेट छ भनी सुनिश्चित गरेपछि, डाटा एक ब्याचमा डाटाबेसमा लेखिनेछ। पछि, हामीले डाटाबेसमा सीधै डाटा लेख्ने क्षमता थप्यौं, तर हामी यो मोड धेरै नभएका घटनाहरूको लागि प्रयोग गर्छौं - उदाहरणका लागि, रूपान्तरणहरू।

खुला स्रोत र भावी योजनाहरू

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

हालको एकीकरण योजना यस्तो देखिन्छ:

यद्यपि सेवा स्वतन्त्र रूपमा प्रयोग गर्न सकिन्छ (उदाहरणका लागि, डकर प्रयोग गरेर), हामीसँग पनि छ होस्ट गरिएको संस्करण, जहाँ तपाइँ डेटा गोदाम संग एकीकरण सेट अप गर्न सक्नुहुन्छ, तपाइँको डोमेनमा CNAME थप्नुहोस्, र घटनाहरूको संख्यामा तथ्याङ्कहरू हेर्नुहोस्। हाम्रो तत्काल योजनाहरू वेब स्रोतबाट तथ्याङ्कहरू मात्र नभई बाह्य डेटा स्रोतहरूबाट पनि डेटा जम्मा गर्ने र तपाईंको मनपर्ने कुनै पनि भण्डारणमा बचत गर्ने क्षमता थप्ने हो!

→ GitHub
→ दस्तावेज
→ सुस्त

यदि EventNative ले तपाईका समस्याहरू समाधान गर्न मद्दत गर्दछ भने हामी खुसी हुनेछौं!

दर्ता भएका प्रयोगकर्ताहरूले मात्र सर्वेक्षणमा भाग लिन सक्छन्। साइन इन गर्नुहोस्कृपया

तपाईको कम्पनीमा कुन तथ्याङ्क सङ्कलन प्रणाली प्रयोग गरिन्छ

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

• 4,0%खण्ड १

• 16,0%अन्य (कमेन्टमा लेख्नुहोस्) ४

• 32,0%तपाईंको सेवा8 लागू गरियो

25 प्रयोगकर्ताहरूले मतदान गरे। 6 प्रयोगकर्ताहरू रोकिए।

स्रोत: www.habr.com