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

Во моментов, речиси секоја компанија во светот собира статистика за активностите на корисниците на веб-ресурс. Мотивацијата е јасна - компаниите сакаат да знаат како се користи нивниот производ/веб-страница и подобро да ги разберат своите корисници. Се разбира, на пазарот има голем број алатки за решавање на овој проблем - од аналитички системи кои обезбедуваат податоци во форма на контролни табли и графикони (на пример Google Analytics) на платформата за податоци за клиентите, која ви овозможува да собирате и собирате податоци од различни извори во кое било складирање (на пример, Сегмент).

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

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

Беа деведесетти, опстанавме најдобро што можевме. Во 2019 година, го развивме првиот API за платформа за податоци за клиентите kSense, што овозможи собирање податоци од различни извори (реклами на Facebook, Stripe, Salesforce, Google play, Google Analytics итн.) за попогодна анализа на податоци, идентификување на зависности итн. Забележавме дека многу корисници ја користат нашата платформа за анализа на податоци, конкретно Google Analytics (во натамошниот текст GA). Разговаравме со некои корисници и дознавме дека им се потребни нивните податоци за анализа на производи, кои ги добиваат со помош на GA, но Google зема примероци од податоци и за многумина GA корисничкиот интерфејс не е стандард за практичност. Имавме доволно разговори со нашите корисници и сфативме дека многумина ја користеа и платформата Segment (што, патем, беше пред само неколку дена продаден за 3.2 милијарди долари).

Тие инсталираа Segment javascript пиксел на нивниот веб-ресурс и нивните податоци за однесувањето на корисниците беа вчитани во одредена база на податоци (на пр. Postgres). Но, Сегмент има и свој минус - цената. На пример, ако веб-ресурс има 90,000 MTU (месечни следени корисници), тогаш треба да плаќате ~ 1,000 долари месечно на благајната. Имаше и трет проблем - некои екстензии на прелистувачи (како AdBlock) ја блокираа колекцијата на аналитика. Барањата http од прелистувачот беа испратени до домените GA и Segment. Врз основа на желбата на нашите клиенти, создадовме аналитичка услуга која собира целосен сет на податоци (без земање примероци), бесплатно и може да работи на нашата сопствена инфраструктура.

Како функционира услугата

Услугата се состои од три дела: javascript пиксел (кој подоцна го преработивме во типка), дел од серверот имплементиран на јазикот GO и беше планирано да се користат Redshift и BigQuery како внатрешна база на податоци (подоцна додадоа поддршка за Postgres , ClickHouse и Snowflake).

Структурата на настаните ГА и Сегмент одлучија да останат непроменети. Сè што беше потребно беше да се дуплираат сите настани од веб-ресурсот каде што е инсталиран пикселот во нашиот заден дел. Како што се испоставува, ова е лесно да се направи. Пикселот 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, сè е поедноставно, има методи на среден софтвер, а ние користевме еден од нив.

//'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_под_поле_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 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

Ние, исто така, сметавме дека корисникот треба да може да постави партиционирање или разделување податоци во базата на податоци според други критериуми и имплементиравме можност да го поставите името на табелата како константа или изразување во конфигурација. Во примерот подолу, настанот ќе биде зачуван во табела со име пресметано врз основа на вредностите на полињата product_type и _timestamp (на пример залихи_2020_10 година):

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

Сепак, структурата на дојдовните настани може да се промени во времето на извршување. Имплементиравме алгоритам за проверка на разликата помеѓу структурата на постоечка табела и структурата на дојдовен настан. Ако се најде разлика, табелата ќе се ажурира со нови полиња. За да го направите ова, користете го барањето за закрпи SQL:

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

архитектура

Зошто треба да пишувате настани во датотечниот систем, а не само да ги пишувате директно во базата на податоци? Базите на податоци не секогаш покажуваат високи перформанси со голем број вметнувања (препораки на постгрес). За да го направите ова, Logger ги запишува дојдовните настани во датотека и веќе во посебна горутина (нишка) Читачот на датотеки ја чита датотеката, потоа се врши трансформација и дефинирање на шемата за податоци. Откако менаџерот на табелата ќе се увери дека шемата на табелата е ажурирана, податоците ќе бидат запишани во базата на податоци во една серија. Последователно, ја додадовме можноста за пишување податоци директно во базата на податоци, но овој режим го користиме за настани што не се многу - на пример, конверзии.

Отворен код и идни планови

Во одреден момент, услугата стана како полноправен производ и решивме да ја ставиме во софтвер со отворен код. Во моментов се имплементирани интеграции со 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