ჩვენი ღია წყაროს ისტორია: როგორ შევქმენით ანალიტიკური სერვისი Go-ში და გავხადეთ ის საჯაროდ

ამჟამად, მსოფლიოს თითქმის ყველა კომპანია აგროვებს სტატისტიკას მომხმარებლის ქმედებების შესახებ ვებ რესურსზე. მოტივაცია ნათელია – კომპანიებს სურთ იცოდნენ, როგორ გამოიყენება მათი პროდუქტი/საიტი და უკეთ გაიგონ მათი მომხმარებლები. რა თქმა უნდა, ამ პრობლემის გადასაჭრელად ბაზარზე არსებობს უამრავი ინსტრუმენტი - ანალიტიკური სისტემებიდან, რომლებიც უზრუნველყოფენ მონაცემებს დაფის და გრაფიკების სახით (მაგალითად, Google ანალიტიკა) მომხმარებელთა მონაცემთა პლატფორმაზე, რომელიც საშუალებას გაძლევთ შეაგროვოთ და დააგროვოთ მონაცემები სხვადასხვა წყაროდან ნებისმიერ საწყობში (მაგ. სეგმენტის).

მაგრამ ჩვენ აღმოვაჩინეთ პრობლემა, რომელიც ჯერ არ არის მოგვარებული. ასე დაიბადა EventNative — ღია კოდის ანალიტიკის სერვისი. წაიკითხეთ იმის შესახებ, თუ რატომ გადავწყვიტეთ შეგვემუშავებინა ჩვენი სერვისი, რა მოგვცა და რა იყო საბოლოო შედეგი (კოდის ნაწილებით).

რატომ უნდა განვავითაროთ ჩვენი საკუთარი სერვისი?

ოთხმოცდაათიანი წლები იყო, როგორც შეგვეძლო, გადავრჩით. 2019 წელს ჩვენ შევიმუშავეთ API პირველი კლიენტების მონაცემთა პლატფორმა kSense, რამაც შესაძლებელი გახადა მონაცემების აგრეგაცია სხვადასხვა წყაროდან (Facebook ads, Stripe, Salesforce, Google play, Google Analytics და ა.შ.) მონაცემთა უფრო მოსახერხებელი ანალიზისთვის, დამოკიდებულებების იდენტიფიცირებისთვის და ა.შ. ჩვენ შევამჩნიეთ, რომ ბევრი მომხმარებელი იყენებს ჩვენს პლატფორმას მონაცემთა ანალიზისთვის, კონკრეტულად Google Analytics (შემდგომში GA). ჩვენ ვესაუბრეთ ზოგიერთ მომხმარებელს და გავარკვიეთ, რომ მათ სჭირდებათ ანალიტიკური მონაცემები მათი პროდუქტისთვის, რომელსაც ისინი იღებენ GA-ს გამოყენებით, მაგრამ Google აგროვებს მონაცემებს და ბევრისთვის GA მომხმარებლის ინტერფეისი არ არის მოხერხებულობის სტანდარტი. ჩვენ გვქონდა საკმარისი საუბარი ჩვენს მომხმარებლებთან და მივხვდით, რომ ბევრი ასევე იყენებდა Segment პლატფორმას (რომელიც, სხვათა შორის, მხოლოდ მეორე დღეს იყო გაიყიდა 3.2 მილიარდ დოლარად).

მათ თავიანთ ვებ რესურსზე დააინსტალირეს Segment javascript pixel და მონაცემები მათი მომხმარებლების ქცევის შესახებ ჩაიტვირთა მითითებულ მონაცემთა ბაზაში (მაგალითად, Postgres). მაგრამ სეგმენტს ასევე აქვს თავისი უარყოფითი მხარე - ფასი. მაგალითად, თუ ვებ რესურსს აქვს 90,000 MTU (თვიური თვალთვალის მომხმარებელი), მაშინ თქვენ უნდა გადაიხადოთ ~ 1,000 $ თვეში მოლარეს. იყო მესამე პრობლემაც - ბრაუზერის ზოგიერთმა გაფართოებამ (როგორიცაა AdBlock) დაბლოკა ანალიტიკის კოლექცია, რადგან... http მოთხოვნები ბრაუზერიდან გაეგზავნა GA და Segment დომენებს. ჩვენი კლიენტების სურვილებიდან გამომდინარე, ჩვენ შევქმენით ანალიტიკური სერვისი, რომელიც აგროვებს მონაცემთა სრულ კომპლექტს (ნიმუშების აღების გარეშე), უფასოა და შეუძლია იმუშაოს საკუთარ ინფრასტრუქტურაზე.

როგორ მუშაობს სერვისი

სერვისი შედგება სამი ნაწილისგან: javascript პიქსელი (რომელიც ჩვენ მოგვიანებით გადავწერეთ საბეჭდი სკრიპტით), სერვერის ნაწილი დანერგილია GO ენაზე და დაგეგმილი იყო Redshift-ისა და BigQuery-ის გამოყენება შიდა მონაცემთა ბაზად (მოგვიანებით მათ დაამატეს მხარდაჭერა Postgres, ClickHouse და Snowflake).

გადაწყდა 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);
        });
    });
}

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'
});

შემდეგი, მოდით ვისაუბროთ სერვერის ნაწილზე. Backend-მა უნდა მიიღოს 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 ველი შეიცავს სტრიქონს დროის ნიშნულით (field_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 სტრუქტურის ბრტყელ სტრუქტურად გადაქცევა
• ველების მონაცემთა ტიპის განსაზღვრა მნიშვნელობებით
• რუკების და ტიპების ჩამოსხმის წესების გამოყენება

შემდეგ შემომავალი 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

არქიტექტურა

რატომ გჭირდებათ მოვლენების ჩაწერა ფაილურ სისტემაში და არა მხოლოდ მათ პირდაპირ მონაცემთა ბაზაში ჩაწერა? მონაცემთა ბაზები ყოველთვის არ მუშაობს კარგად, როდესაც საქმე გვაქვს ჩანართების დიდ რაოდენობასთან (პოსტგრესის რეკომენდაციები). ამისათვის Logger წერს შემომავალ მოვლენებს ფაილში და ცალკე გორუტინში (თემა) File reader კითხულობს ფაილს, შემდეგ ხდება მონაცემების კონვერტაცია და განსაზღვრა. მას შემდეგ, რაც ცხრილის მენეჯერი დარწმუნდება, რომ ცხრილის სქემა განახლებულია, მონაცემები ერთ პარტიაში ჩაიწერება მონაცემთა ბაზაში. შემდგომში დავამატეთ მონაცემთა ბაზაში უშუალოდ ჩაწერის შესაძლებლობა, მაგრამ ამ რეჟიმს ვიყენებთ არა მრავალრიცხოვანი მოვლენებისთვის - მაგალითად, კონვერტაციებისთვის.

ღია წყარო და სამომავლო გეგმები

რაღაც მომენტში, სერვისმა დაიწყო სრულფასოვანი პროდუქტის სახე და ჩვენ გადავწყვიტეთ მისი გამოშვება ღია წყაროზე. ამჟამად განხორციელებულია ინტეგრაცია Postgres-თან, ClickHouse-თან, BigQuery-თან, Redshift-თან, S3-თან, Snowflake-თან. ყველა ინტეგრაცია მხარს უჭერს მონაცემთა ჩატვირთვის ორივე და ნაკადის რეჟიმებს. დამატებულია მოთხოვნის მხარდაჭერა API-ის საშუალებით.

მიმდინარე ინტეგრაციის სქემა ასე გამოიყურება:

მიუხედავად იმისა, რომ სერვისის გამოყენება შესაძლებელია დამოუკიდებლად (მაგალითად, Docker-ის გამოყენებით), ჩვენ ასევე გვაქვს ჰოსტინგის ვერსია, რომელშიც შეგიძლიათ დააყენოთ ინტეგრაცია მონაცემთა საწყობთან, დაამატოთ CNAME თქვენს დომენში და ნახოთ სტატისტიკა მოვლენების რაოდენობის შესახებ. ჩვენი უახლოესი გეგმებია დავამატოთ არა მხოლოდ სტატისტიკის შეგროვების შესაძლებლობა ვებ რესურსიდან, არამედ მონაცემების გარე მონაცემთა წყაროებიდან და შეინახოთ ისინი თქვენს მიერ არჩეულ ნებისმიერ საცავში!

→ GitHub
→ დოკუმენტაცია
→ Slack

მოხარული ვიქნებით, თუ EventNative დაგეხმარებათ თქვენი პრობლემების მოგვარებაში!

გამოკითხვაში მონაწილეობა შეუძლიათ მხოლოდ დარეგისტრირებულ მომხმარებლებს. Შებრძანდითგთხოვთ

რა სტატისტიკის შეგროვების სისტემა გამოიყენება თქვენს კომპანიაში?

• 48,0%Google Analytics12

• 4,0%სეგმენტი 1

• 16,0%კიდევ ერთი (დაწერეთ კომენტარებში)4

• 32,0%განხორციელდა თქვენი სერვისი8

მისცა ხმა 25 მომხმარებელმა. 6-მა მომხმარებელმა თავი შეიკავა.

წყარო: www.habr.com