Историја нашег отвореног кода: како смо направили аналитичку услугу у Го-у и учинили је јавно доступном

Тренутно скоро свака компанија на свету прикупља статистику о радњама корисника на веб ресурсу. Мотивација је јасна – компаније желе да знају како се њихов производ/веб страница користи и да боље разумеју своје кориснике. Наравно, на тржишту постоји велики број алата за решавање овог проблема – од аналитичких система који дају податке у облику контролне табле и графикона (нпр. Google Analytics) на Платформу података о клијентима, која вам омогућава да прикупљате и агрегирате податке из различитих извора у било ком складишту (нпр. Сегмент).

Али пронашли смо проблем који још увек није решен. Тако је рођен ЕвентНативе — аналитичка услуга отвореног кода. Прочитајте зашто смо одлучили да развијемо сопствену услугу, шта нам је то дало и шта је био крајњи резултат (са деловима кода).

Зашто да развијамо сопствену услугу?

Биле су деведесете, преживљавали смо како смо могли. 2019. развили смо АПИ Фирст Цустомер Дата Платформ кСенсе, што је омогућило агрегирање података из различитих извора (Фацебоок адс, Стрипе, Салесфорце, Гоогле плаи, Гоогле Аналитицс, итд.) ради практичније анализе података, идентификовања зависности итд. Приметили смо да многи корисници користе нашу платформу за анализу података посебно Гоогле аналитику (у даљем тексту ГА). Разговарали смо са неким корисницима и сазнали да су им потребни аналитички подаци за њихов производ које добијају помоћу ГА, али Гоогле узоркује податке и за многе, ГА кориснички интерфејс није стандард погодности. Имали смо довољно разговора са нашим корисницима и схватили да многи користе и платформу Сегмент (која је, иначе, тек пре неки дан продат за 3.2 милијарде долара).

Они су инсталирали сегментни јавасцрипт пиксел на свој веб ресурс и подаци о понашању њихових корисника су учитани у наведену базу података (на пример Постгрес). Али Сегмент има и своју лошу страну - цену. На пример, ако веб ресурс има 90,000 МТУ (месечно праћених корисника), онда морате да платите ~1,000 $ месечно благајнику. Постојао је и трећи проблем - неке екстензије претраживача (као што је АдБлоцк) блокирале су прикупљање аналитике јер... хттп захтеви из прегледача су послати на домене ГА и сегмента. На основу жеља наших клијената креирали смо услугу аналитике која прикупља комплетан сет података (без узорковања), бесплатна је и може да ради на сопственој инфраструктури.

Како услуга функционише

Сервис се састоји из три дела: јавасцрипт пиксела (који смо касније преписали у куцани текст), серверски део је имплементиран на ГО језику, а планирано је да се као интерна база података користе Редсхифт и БигКуери (касније су додали подршку за Постгрес, ЦлицкХоусе и Сновфлаке).

Одлучено је да се структура ГА и Сегмент догађаја остави непромењена. Све што је било потребно је да дуплирамо све догађаје са веб ресурса где је пиксел инсталиран на наш бацкенд. Како се испоставило, ово није тешко учинити. Јавасцрипт пиксел је заменио оригинални метод библиотеке ГА новим, који је дуплирао догађај у нашем систему.

//'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 объектом
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'
});

Даље, хајде да причамо о делу сервера. Позадина треба да прихвати хттп захтеве, испуни их додатним информацијама, на пример, географским подацима (хвала макминд за ово) и евидентирати у бази података. Желели смо да услугу учинимо што је могуће погоднијом тако да се може користити уз минималну конфигурацију. Имплементирали смо функционалност одређивања шеме података на основу структуре долазног јсон догађаја. Типови података су дефинисани вредностима. Угнежђени објекти се разлажу и своде на равну структуру:

//входящий 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"
}

Међутим, низови се тренутно једноставно претварају у низове јер Не подржавају све релационе базе података поновљена поља. Такође је могуће променити имена поља или их избрисати коришћењем опционих правила мапирања. Они вам омогућавају да промените шему података ако је потребно или претворите један тип података у други. На пример, ако јсон поље садржи стринг са временском ознаком (фиелд_3_суб_фиелд_1_суб_суб_фиелд_1 из горњег примера), онда да бисте креирали поље у бази података са типом временске ознаке, потребно је да напишете правило мапирања у конфигурацији. Другим речима, тип података поља је одређен прво јсон вредношћу, а затим се примењује правило за превођење типа (ако је конфигурисано). Идентификовали смо 4 главна типа података: СТРИНГ, ФЛОАТ64, ИНТ64 и ТИМЕСТАМП. Правила мапирања и преливања типова изгледају овако:

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

Алгоритам за одређивање типа података:

• претворити јсон структуру у равну структуру
• одређивање типа података поља по вредностима
• применом правила за пресликавање и преливање типа

Затим из долазне јсон структуре:

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

Међутим, структура долазних догађаја се може променити током извршавања. Имплементирали смо алгоритам за проверу разлике између структуре постојеће табеле и структуре долазног догађаја. Ако се пронађе разлика, табела ће бити ажурирана новим пољима. Да бисте то урадили, користите СКЛ упит закрпе:

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

архитектура

Зашто морате да пишете догађаје у систем датотека, а не само да их пишете директно у базу података? Базе података не раде увек добро када се баве великим бројем уметања (Постгрес препоруке). Да би то урадио, Логгер уписује долазне догађаје у датотеку и у засебној горутини (нит) читач датотека чита датотеку, затим се подаци конвертују и одређују. Након што се менаџер табеле увери да је шема табеле ажурирана, подаци ће бити уписани у базу података у једној групи. Накнадно смо додали могућност писања података директно у базу података, али овај режим користимо за догађаје који нису бројни – на пример, конверзије.

Отворени код и планови за будућност

У неком тренутку, услуга је почела да изгледа као пуноправни производ и одлучили смо да је пустимо на Опен Соурце. Тренутно су имплементиране интеграције са Постгрес, ЦлицкХоусе, БигКуери, Редсхифт, С3, Сновфлаке. Све интеграције подржавају и групни и стриминг режим учитавања података. Додата подршка за захтеве преко АПИ-ја.

Тренутна шема интеграције изгледа овако:

Иако се услуга може користити независно (на пример коришћењем Доцкер-а), ми такође имамо хостована верзија, у којој можете подесити интеграцију са складиштем података, додати ЦНАМЕ свом домену и прегледати статистику о броју догађаја. Наши непосредни планови су да додамо могућност агрегирања не само статистике са веб ресурса, већ и података из екстерних извора података и да их сачувамо у било коју меморију по вашем избору!

→ ГитХуб
→ Записи
→ Слацк

Биће нам драго ако ЕвентНативе помогне у решавању ваших проблема!

Само регистровани корисници могу учествовати у анкети. Пријавите се, Добродошао си.

Који систем прикупљања статистике се користи у вашој компанији?

• 100%Гоогле аналитика12

• 100%Сегмент1

• 100%Други (напишите у коментарима)4

• 100%Имплементирао вашу услугу8

Гласало је 25 корисника. Уздржано је било 6 корисника.

Извор: ввв.хабр.цом