اسان جي اوپن سورس جي تاريخ: ڪيئن اسان Go ۾ تجزياتي سروس ٺاهي ۽ ان کي عوامي طور تي دستياب ڪيو

في الحال، دنيا ۾ لڳ ڀڳ هر ڪمپني هڪ ويب وسيلن تي صارف جي عملن بابت انگ اکر گڏ ڪري ٿي. حوصلا واضح آهي - ڪمپنيون ڄاڻڻ چاهين ٿيون ته انهن جي پيداوار / ويب سائيٽ ڪيئن استعمال ٿئي ٿي ۽ انهن جي استعمال ڪندڙن کي بهتر سمجهي. يقينا، هن مسئلي کي حل ڪرڻ لاء مارڪيٽ تي اوزار جو هڪ وڏو تعداد آهي - تجزياتي سسٽم کان جيڪي ڊيٽا مهيا ڪن ٿا ڊيش بورڊ ۽ گراف جي صورت ۾ (مثال طور گوگل تجزياتي) ڏانهن ڪسٽمر ڊيٽا پليٽ فارم، جيڪو توهان کي ڪنهن به گودام ۾ مختلف ذريعن کان ڊيٽا گڏ ڪرڻ ۽ گڏ ڪرڻ جي اجازت ڏئي ٿو (مثال طور ٽڪڙو).

پر اسان کي هڪ مسئلو مليو آهي جيڪو اڃا تائين حل نه ڪيو ويو آهي. اهڙيء طرح پيدا ٿيو واقعي واقعي - اوپن سورس اينالائيٽڪس سروس. ان بابت پڙهو ته اسان پنهنجي خدمت کي ترقي ڪرڻ جو فيصلو ڪيو، اهو اسان کي ڇا ڏنو، ۽ آخر نتيجو ڇا هو (ڪوڊ جي ٽڪرن سان).

اسان کي پنهنجي خدمت کي ڇو ترقي ڪرڻ گهرجي؟

اهو نون جو ڏهاڪو هو، اسان جيتري بهتر ٿي سگهي ٿي بچي وياسين. 2019، اسان ترقي ڪئي API پهريون ڪسٽمر ڊيٽا پليٽ فارم kSense، جنهن کي اجازت ڏني وئي مختلف ذريعن کان ڊيٽا گڏ ڪرڻ (Facebook ads, Stripe, Salesforce, Google play, Google Analytics, etc.) لاءِ وڌيڪ آسان ڊيٽا جي تجزيي لاءِ، انحصار کي سڃاڻڻ وغيره. اسان ڏٺو آهي ته ڪيترائي صارف اسان جي ڊيٽا اينالائيٽڪس پليٽ فارم کي استعمال ڪندا آهن، خاص طور تي گوگل تجزياتي (هتي GA طور حوالو ڏنو ويو آهي). اسان ڪجهه استعمال ڪندڙن سان ڳالهايو ۽ معلوم ڪيو ته انهن کي پنهنجي پيداوار جي تجزياتي ڊيٽا جي ضرورت آهي، جيڪا اهي GA استعمال ڪندي وصول ڪندا آهن، پر گوگل نموني ڊيٽا ۽ گھڻن لاءِ، GA يوزر انٽرفيس سھولت جو معيار نه آھي. اسان اسان جي استعمال ڪندڙن سان ڪافي گفتگو ڪئي ۽ محسوس ڪيو ته ڪيترائي سيگمينٽ پليٽ فارم پڻ استعمال ڪري رهيا هئا (جيڪو، رستي ۾، صرف ٻئي ڏينهن هو 3.2 بلين ڊالر ۾ وڪرو ٿيو).

انهن پنهنجي ويب وسيلن تي سيگمينٽ جاوا اسڪرپٽ پکسل نصب ڪيو ۽ انهن جي استعمال ڪندڙن جي رويي بابت ڊيٽا مخصوص ڊيٽابيس ۾ لوڊ ڪئي وئي (مثال طور پوسٽ گريس). پر ڀاڱو پڻ ان جي گهٽتائي آهي - قيمت. مثال طور، جيڪڏهن هڪ ويب ريسورس ۾ 90,000 MTU (ماهوار ٽريڪ ٿيل استعمال ڪندڙ) آهن، ته پوءِ توهان کي ادا ڪرڻو پوندو ~ 1,000 $ هر مهيني ڪيشيئر کي. هڪ ٽيون مسئلو پڻ هو - ڪجهه برائوزر ايڪسٽينشنز (جهڙوڪ AdBlock) اينالائيٽڪس جي مجموعي کي بلاڪ ڪيو ڇاڪاڻ ته ... HTTP درخواستون برائوزر کان موڪليا ويا GA ۽ Segment ڊومينز ڏانهن. اسان جي گراهڪن جي خواهش جي بنياد تي، اسان هڪ تجزياتي خدمت ٺاهي آهي جيڪا ڊيٽا جو مڪمل سيٽ گڏ ڪري ٿي (بغير نموني جي)، مفت آهي ۽ اسان جي پنهنجي زيربناء تي ڪم ڪري سگهي ٿي.

خدمت ڪيئن ڪم ڪري ٿي

خدمت ٽن حصن تي مشتمل آهي: هڪ جاوا اسڪرپٽ پکسل (جنهن کي اسان بعد ۾ ٽائيپ اسڪرپٽ ۾ ٻيهر لکيو آهي)، سرور جو حصو GO ٻولي ۾ لاڳو ڪيو ويو آهي، ۽ اهو رٿابندي ڪئي وئي هئي ته Redshift ۽ BigQuery کي اندروني ڊيٽابيس طور استعمال ڪيو وڃي (بعد ۾ انهن لاءِ سپورٽ شامل ڪئي وئي. Postgres، ClickHouse ۽ Snowflake).

اهو فيصلو ڪيو ويو ته 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);
        });
    });
}

Segment pixel سان هر شي آسان آهي؛ ان ۾ وچولي طريقا آهن، جن مان هڪ اسان استعمال ڪيو آهي.

//'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"
}

بهرحال، arrays في الحال صرف اسٽرنگ ۾ تبديل ڪيا ويا آهن ڇاڪاڻ ته نه سڀئي لاڳاپيل ڊيٽابيس بار بار فيلڊ جي حمايت ڪن ٿا. اهو پڻ ممڪن آهي ته فيلڊ جا نالا تبديل ڪرڻ يا انهن کي حذف ڪرڻ اختياري ميپنگ ضابطن کي استعمال ڪندي. اهي توهان کي ڊيٽا اسڪيما کي تبديل ڪرڻ جي اجازت ڏين ٿا جيڪڏهن ضروري هجي يا هڪ ڊيٽا جي قسم کي ٻئي ۾ تبديل ڪريو. مثال طور، جيڪڏهن 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

اسان اهو پڻ سوچيو ته صارف کي تقسيم ڪرڻ يا ڊيٽابيس ۾ ڊيٽا کي ٻين معيارن جي مطابق ورهائڻ جي قابل هوندو ۽ ٽيبل جو نالو مقرر ڪرڻ جي صلاحيت کي لاڳو ڪرڻ جي قابل هوندو. اظهار جي تشڪيل ۾. هيٺ ڏنل مثال ۾، ايونٽ هڪ ٽيبل تي محفوظ ڪيو ويندو نالي سان حساب ڪيو ويندو پراڊڪٽ_ٽائپ ۽ _timestamp فيلڊز جي قدرن جي بنياد تي (مثال طور سامان_2020_10):

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

بهرحال، ايندڙ واقعن جي جوڙجڪ رن ٽائيم تي تبديل ٿي سگھي ٿي. اسان موجوده جدول جي ساخت ۽ ايندڙ واقعن جي جوڙجڪ جي وچ ۾ فرق کي جانچڻ لاءِ هڪ الگورتھم لاڳو ڪيو آهي. جيڪڏهن ڪو فرق ملي ٿو، جدول کي نئين فيلڊ سان اپڊيٽ ڪيو ويندو. ائين ڪرڻ لاء، پيچ SQL سوال استعمال ڪريو:

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

تعمير

توهان کي فائل سسٽم ۾ واقعا لکڻ جي ضرورت ڇو آهي، ۽ نه صرف انهن کي سڌو سنئون ڊيٽابيس ڏانهن لکو؟ ڊيٽابيس هميشه سٺي ڪارڪردگي نه ڪندا آهن جڏهن وڏي تعداد ۾ داخل ٿيڻ سان معاملو ڪيو وڃي (Postgres سفارشون). ائين ڪرڻ لاءِ، Logger ايندڙ واقعن کي فائل ۾ لکي ٿو ۽ الڳ goroutine (thread) ۾ فائل ريڊر فائل پڙهي ٿو، پوءِ ڊيٽا کي تبديل ڪيو وڃي ٿو ۽ طئي ڪيو وڃي ٿو. ٽيبل مئنيجر کان پوءِ پڪ ڪري ٿو ته ٽيبل اسڪيما تازه ترين آهي، ڊيٽا کي هڪ بيچ ۾ ڊيٽابيس ڏانهن لکيو ويندو. ان کان پوء، اسان ڊيٽا کي سڌو سنئون ڊيٽابيس ۾ لکڻ جي صلاحيت شامل ڪئي، پر اسان هن موڊ کي انهن واقعن لاء استعمال ڪندا آهيون جيڪي گهڻا نه آهن - مثال طور، تبديليون.

کليل ذريعو ۽ مستقبل لاء منصوبا

ڪجهه نقطي تي، خدمت هڪ مڪمل پيداوار وانگر ڏسڻ شروع ڪيو ۽ اسان ان کي ڇڏڻ جو فيصلو ڪيو اوپن سورس. في الحال، Postgres، ClickHouse، BigQuery، Redshift، S3، Snowflake سان انضمام تي عمل ڪيو ويو آھي. سڀئي انضمام ڊيٽا لوڊ ڪرڻ جي بيچ ۽ اسٽريمنگ طريقن جي مدد ڪن ٿا. API ذريعي درخواستن لاءِ سپورٽ شامل ڪئي وئي.

موجوده انضمام جو منصوبو هن طرح نظر اچي ٿو:

جيتوڻيڪ خدمت آزاديءَ سان استعمال ڪري سگھجي ٿي (مثال طور Docker استعمال ڪندي)، اسان وٽ پڻ آھي ميزباني ڪيل نسخو، جنهن ۾ توهان ڊيٽا گودام سان انضمام قائم ڪري سگهو ٿا، پنهنجي ڊومين ۾ هڪ CNAME شامل ڪريو ۽ واقعن جي تعداد تي انگ اکر ڏسو. اسان جا فوري منصوبا شامل ڪرڻ جي صلاحيت شامل ڪرڻ لاءِ آهن نه صرف ويب وسيلن مان انگ اکر گڏ ڪرڻ، پر ٻاهرين ڊيٽا ذريعن مان ڊيٽا ۽ انهن کي پنهنجي پسند جي ڪنهن به ذخيري ۾ محفوظ ڪرڻ!

→ GitHub
→ دستاويزي
→ سست

اسان کي خوشي ٿيندي جيڪڏهن EventNative توهان جي مسئلن کي حل ڪرڻ ۾ مدد ڪري ٿي!

صرف رجسٽرڊ استعمال ڪندڙ سروي ۾ حصو وٺي سگهن ٿا. سائن ان ڪريو، توهان جي مهرباني.

توهان جي ڪمپني ۾ ڪهڙي انگ اکر گڏ ڪرڻ جو نظام استعمال ڪيو ويندو آهي؟

• 48,0٪Google Analytics12

• 4,0٪حصو 1

• 16,0٪ٻيو (تبصرن ۾ لکو) 4

• 32,0٪توهان جي خدمت تي عمل ڪيو 8

25 صارفين ووٽ ڏنو. 6 استعمال ڪندڙن کي روڪيو ويو.

جو ذريعو: www.habr.com