Gure kode irekiaren historia: Go-n analitika-zerbitzu bat nola egin eta publikoki eskuragarri jarri genuen

Gaur egun, munduko ia enpresa guztiek erabiltzaileen ekintzei buruzko estatistikak biltzen dituzte web baliabide batean. Motibazioa argia da: enpresek euren produktua/webgunea nola erabiltzen den jakin nahi dute eta erabiltzaileak hobeto ulertu. Jakina, arazo hau konpontzeko tresna ugari daude merkatuan: aginte-panel eta grafiko moduan datuak ematen dituzten analisi-sistemetatik (adibidez. Google Analytics) Bezeroaren Datuen Plataformara, zeinak iturri ezberdinetako datuak biltegiratzeko eta biltegiratzeko aukera ematen dizu edozein biltegiratzetan (adibidez, Segment).

Baina oraindik konpondu ez den arazo bat aurkitu dugu. Beraz, jaioa GertaeraJatorrizkoa — Kode irekiko analisi-zerbitzua. Gure zerbitzua garatzera zergatik joan ginen, zer eman zigun eta zer gertatu zen azkenean (kode zatiekin), ebaki azpian irakurri.

Zergatik garatu behar dugu gure zerbitzua?

Laurogeita hamarreko hamarkada zen, ahal genuen bezala bizirik atera ginen. 2019an, First Customer Data Platform APIa garatu genuen kSense, zeinak iturri ezberdinetako datuak (Facebook iragarkiak, Stripe, Salesforce, Google play, Google Analytics, etab.) batu ahal izateko, datuen azterketa erosoagoa izan dadin, mendekotasunak identifikatu eta abar. Erabiltzaile askok gure datu analitiko plataforma erabiltzen dutela ohartu gara, zehazki Google Analytics (aurrerantzean GA deitzen dena). Erabiltzaile batzuekin hitz egin dugu eta jakin dugu produktuen analisi-datuak behar dituztela, GA erabiliz jasotzen dituztenak, baina Google laginak datuak eta askorentzat GA Erabiltzaile Interfazea ez da erosotasun estandar bat. Nahikoa elkarrizketa izan genuen gure erabiltzaileekin eta konturatu ginen askok Segment plataforma ere erabiltzen zutela (bide batez, duela egun batzuk besterik ez zena). 3.2 milioi dolarretan saldu zen).

Segment javascript pixel bat instalatu zuten beren web baliabidean eta erabiltzailearen portaeraren datuak datu-base zehatz batean kargatu ziren (adibidez, Postgres). Baina Segmentuak ere badu bere alde txarra: prezioa. Esate baterako, web-baliabide batek 90,000 MTU baditu (hilabeteko erabiltzaileen jarraipena), orduan ~ $ 1,000 ordaindu behar dizkiozu hilero kutxazainari. Hirugarren arazo bat ere egon zen: arakatzaileen luzapen batzuek (adibidez, AdBlock) analisien bilduma blokeatu zuten. Arakatzailearen http eskaerak GA eta Segment domeinuetara bidali ziren. Gure bezeroen nahian oinarrituta, datu-multzo osoa (laginketarik gabe) biltzen duen analitika-zerbitzu bat sortu dugu, doan eta gure azpiegituran lan egin dezakeena.

Zerbitzuak nola funtzionatzen duen

Zerbitzuak hiru zati ditu: javascript pixel bat (gero mekanografian berridatzi genuena), GO hizkuntzan inplementatutako zerbitzari zati bat, eta Redshift eta BigQuery barneko datu-base gisa erabiltzea aurreikusi zen (gero Postgres-erako laguntza gehitu zuten. , ClickHouse eta Snowflake).

GA eta Segment ekitaldien egitura aldatu gabe uztea erabaki zuten. Beharrezkoa zen pixela instalatuta dagoen web-baliabidetik gertaera guztiak gure backendera bikoiztea. Bihurtzen denez, hau egitea erraza da. Javascript pixelak jatorrizko GA liburutegiaren metodoa gainidatzi zuen gure sisteman gertaera bikoiztu zuen berri batekin.

//'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 pixelarekin dena sinpleagoa da, middleware metodoak ditu eta horietako bat erabili dugu.

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

Gertaerak kopiatzeaz gain, json arbitrarioa bidaltzeko gaitasuna gehitu dugu:

//Отправка событий с произвольным 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'
});

Jarraian, hitz egin dezagun zerbitzariari buruz. Backend-ek http eskaerak onartu beharko lituzke, informazio gehigarriz bete, adibidez, geodatuak (eskerrik asko maxmind horretarako) eta idatzi datu-basean. Zerbitzua ahalik eta erosoena egin nahi izan dugu, konfigurazio minimoarekin erabili ahal izateko. Sarrerako json gertaeraren egituran oinarritutako datu-eskema zehazteko funtzionaltasuna inplementatu dugu. Datu motak balioen bidez definitzen dira. Habiaraturiko objektuak deskonposatu eta egitura lau batera murrizten dira:

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

Hala ere, gaur egun matrizeak kate bihurtzen dira. datu-base erlazional guztiek ez dituzte eremu errepikatuak onartzen. Eremu izenak aldatzea edo kentzea ere posible da aukerako mapa-arauak erabiliz. Datu-eskema aldatzeko aukera ematen dute, behar izanez gero, edo datu-mota bat beste batera igortzeko. Adibidez, json eremuak denbora-zigilua duen kate bat badu (eremua_3_azpi_eremua_1_azpi_eremua_1 goiko adibidetik), orduan datu-basean denbora-zigilu motako eremu bat sortzeko, konfigurazioan mapa-arau bat idatzi behar duzu. Beste era batera esanda, eremuaren datu-mota json balioaren arabera zehazten da lehenik, eta, ondoren, motaren casting-araua (konfiguratuta badago) aplikatzen da. 4 datu mota nagusi identifikatu ditugu: STRING, FLOAT64, INT64 eta TIMESTAMP. Mapeatzeko eta igortzeko arauak honelakoak dira:

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

Datu mota zehazteko algoritmoa:

• bihurtu json struct egitura laua
• eremuen datu mota balioen bidez zehaztea
• mapaketa- eta mota-galdaketa-arauak aplikatuz

Ondoren, sarrerako json egituratik:

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

datu-eskema lortuko da:

"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

Erabiltzaileak datu-basean beste irizpide batzuen arabera partizioak edo zatiketak konfiguratzeko gai izan behar zuela ere pentsatu genuen eta taularen izena konstante edo konstante gisa ezartzeko gaitasuna ezarri genuen. adierazpena konfigurazioan. Beheko adibidean, gertaera taula batean gordeko da product_type eta _timestamp eremuen balioetan oinarrituta kalkulatutako izen batekin (adibidez hornigaiak_2020_10):

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

Hala ere, sarrerako gertaeren egitura alda daiteke exekuzioan. Lehendik dagoen taula baten egituraren eta sarrerako gertaera baten egituraren arteko aldea egiaztatzeko algoritmo bat ezarri dugu. Alderik aurkitzen bada, taula eremu berriekin eguneratuko da. Horretarako, erabili adabaki SQL kontsulta:

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

arkitektura

Zergatik idatzi behar dituzu gertaerak fitxategi-sisteman, eta ez zuzenean datu-basean idatzi? Datu-baseek ez dute beti errendimendu altua erakusten txertaketa kopuru handiarekin (postgres gomendioak). Horretarako, Logger-ek sarrerako gertaerak idazten ditu fitxategi batean eta dagoeneko aparteko goroutine batean (haria) Fitxategi-irakurleak fitxategia irakurtzen du, ondoren datu-eskemaren eraldaketa eta definizioa egiten da. Taula-kudeatzaileak taula-eskema eguneratuta dagoela ziurtatu ondoren, datuak lote batean idatziko dira datu-basean. Ondoren, datu-basean datuak zuzenean idazteko gaitasuna gehitu dugu, baina modu hau asko ez diren gertaeretarako erabiltzen dugu, adibidez, bihurketak.

Kode irekia eta etorkizuneko planak

Noizbait, zerbitzua erabateko produktu bat bezala bihurtu zen eta Open Sourcen jartzea erabaki genuen. Momentuz, Postgres, ClickHouse, BigQuery, Redshift, S3, Snowflake-ekin integrazioak ezarri dira. Integrazio guztiek batch eta streaming datuak kargatzeko moduak onartzen dituzte. API bidezko eskaeretarako laguntza gehitu da.

Egungo integrazio-eskemak honela dauka:

Zerbitzua modu independentean erabil daitekeen arren (adibidez, Docker erabiliz), badugu ere ostatatutako bertsioa, non datu biltegiarekin integrazioa konfigura dezakezu, CNAME bat gehitu zure domeinuari eta gertaera kopuruari buruzko estatistikak ikus ditzakezu. Gure berehalako planak web-baliabide bateko estatistikak ez ezik, kanpoko datu-iturrietako datuak ere batzeko gaitasuna gehitzea eta nahi duzun edozein biltegian gordetzea da!

→ GitHub
→ Dokumentazioa
→ Galdutako

Pozik egongo gara EventNativek zure arazoak konpontzen lagunduko badizu!

Erregistratutako erabiltzaileek soilik parte hartu dezakete inkestan. Hasi saioa, mesedez.

Zein estatistikak biltzeko sistema erabiltzen den zure enpresan

• 48,0%Google Analytics12

• 4,0%Segmentua 1

• 16,0%Beste batzuk (idatzi iruzkinetan) 4

• 32,0%Zure zerbitzua ezarri duzu8

25 erabiltzailek eman dute botoa. 6 erabiltzaile abstenitu ziren.

Iturria: www.habr.com