ປະຫວັດຂອງແຫຼ່ງເປີດຂອງພວກເຮົາ: ວິທີທີ່ພວກເຮົາເຮັດການບໍລິການການວິເຄາະໃນ Go ແລະເຮັດໃຫ້ມັນເປີດເຜີຍຕໍ່ສາທາລະນະ

ໃນປັດຈຸບັນ, ເກືອບທຸກບໍລິສັດໃນໂລກເກັບກໍາສະຖິຕິກ່ຽວກັບການດໍາເນີນການຂອງຜູ້ໃຊ້ໃນຊັບພະຍາກອນເວັບໄຊຕ໌. ແຮງຈູງໃຈແມ່ນຈະແຈ້ງ - ບໍລິສັດຕ້ອງການຮູ້ວ່າຜະລິດຕະພັນ / ເວັບໄຊທ໌ຂອງພວກເຂົາຖືກນໍາໃຊ້ແນວໃດແລະເຂົ້າໃຈຜູ້ໃຊ້ຂອງພວກເຂົາດີຂຶ້ນ. ແນ່ນອນ, ມີເຄື່ອງມືຈໍານວນຫລາຍຢູ່ໃນຕະຫຼາດເພື່ອແກ້ໄຂບັນຫານີ້ - ຈາກລະບົບການວິເຄາະທີ່ສະຫນອງຂໍ້ມູນໃນຮູບແບບຂອງ dashboards ແລະກາຟ (ຕົວຢ່າງ. ກູໂກວິເຄາະ) ໄປຫາແພລະຕະຟອມຂໍ້ມູນລູກຄ້າ, ເຊິ່ງອະນຸຍາດໃຫ້ທ່ານເກັບກໍາແລະລວບລວມຂໍ້ມູນຈາກແຫຼ່ງຕ່າງໆໃນສາງຕ່າງໆ (ຕົວຢ່າງ: ສ່ວນ).

ແຕ່ພວກເຮົາພົບບັນຫາທີ່ຍັງບໍ່ທັນໄດ້ແກ້ໄຂເທື່ອ. ດັ່ງນັ້ນຈຶ່ງເກີດ ເຫດການພື້ນເມືອງ — ການ​ບໍ​ລິ​ການ​ການ​ວິ​ເຄາະ​ແຫຼ່ງ​ເປີດ​. ອ່ານກ່ຽວກັບວ່າເປັນຫຍັງພວກເຮົາຕັດສິນໃຈທີ່ຈະພັດທະນາການບໍລິການຂອງພວກເຮົາເອງ, ສິ່ງທີ່ມັນໃຫ້ພວກເຮົາ, ແລະຜົນໄດ້ຮັບສຸດທ້າຍແມ່ນຫຍັງ (ກັບຕ່ອນຂອງລະຫັດ).

ເປັນຫຍັງພວກເຮົາຄວນພັດທະນາການບໍລິການຂອງຕົນເອງ?

ມັນແມ່ນ nineties, ພວກເຮົາຢູ່ລອດທີ່ດີທີ່ສຸດທີ່ພວກເຮົາສາມາດເຮັດໄດ້. 2019, ພວກເຮົາໄດ້ພັດທະນາແພລດຟອມຂໍ້ມູນລູກຄ້າທຳອິດຂອງ API kSense, ເຊິ່ງເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະລວບລວມຂໍ້ມູນຈາກແຫຼ່ງຕ່າງໆ (ໂຄສະນາເຟສບຸກ, Stripe, Salesforce, Google play, Google Analytics, ແລະອື່ນໆ) ສໍາລັບການວິເຄາະຂໍ້ມູນທີ່ສະດວກກວ່າ, ການກໍານົດການຂຶ້ນກັບ, ແລະອື່ນໆ. ພວກເຮົາໄດ້ສັງເກດເຫັນວ່າຜູ້ໃຊ້ຫຼາຍຄົນໃຊ້ແພລະຕະຟອມຂອງພວກເຮົາສໍາລັບການວິເຄາະຂໍ້ມູນໂດຍສະເພາະ Google Analytics (ຕໍ່ໄປນີ້ GA). ພວກເຮົາໄດ້ສົນທະນາກັບຜູ້ໃຊ້ບາງຄົນແລະພົບວ່າພວກເຂົາຕ້ອງການຂໍ້ມູນການວິເຄາະສໍາລັບຜະລິດຕະພັນຂອງພວກເຂົາທີ່ພວກເຂົາໄດ້ຮັບໂດຍໃຊ້ GA, ແຕ່. Google ຕົວຢ່າງຂໍ້ມູນ ແລະສໍາລັບຫຼາຍໆຄົນ, ການໂຕ້ຕອບຜູ້ໃຊ້ GA ບໍ່ແມ່ນມາດຕະຖານຂອງຄວາມສະດວກ. ພວກເຮົາມີການສົນທະນາພຽງພໍກັບຜູ້ໃຊ້ຂອງພວກເຮົາແລະຮັບຮູ້ວ່າຫຼາຍຄົນຍັງໃຊ້ເວທີ Segment (ເຊິ່ງ, ໂດຍວິທີທາງການ, ແມ່ນພຽງແຕ່ໃນມື້ອື່ນ. ຂາຍໃນລາຄາ 3.2 ຕື້ໂດລາ).

ພວກເຂົາເຈົ້າໄດ້ຕິດຕັ້ງ Segment javascript pixel ໃນຊັບພະຍາກອນເວັບຂອງພວກເຂົາແລະຂໍ້ມູນກ່ຽວກັບພຶດຕິກໍາຂອງຜູ້ໃຊ້ຂອງພວກເຂົາຖືກໂຫລດເຂົ້າໄປໃນຖານຂໍ້ມູນທີ່ລະບຸ (ຕົວຢ່າງ Postgres). ແຕ່ Segment ຍັງມີຂໍ້ເສຍຂອງມັນ - ລາຄາ. ຕົວຢ່າງ, ຖ້າຊັບພະຍາກອນເວັບມີ 90,000 MTU (ຜູ້ຕິດຕາມປະຈໍາເດືອນ), ຫຼັງຈາກນັ້ນທ່ານຈໍາເປັນຕ້ອງຈ່າຍ ~ 1,000 ໂດລາຕໍ່ເດືອນໃຫ້ຜູ້ເກັບເງິນ. ຍັງມີບັນຫາທີສາມ - ບາງສ່ວນຂະຫຍາຍຂອງຕົວທ່ອງເວັບ (ເຊັ່ນ: AdBlock) ຂັດຂວາງການລວບລວມການວິເຄາະເພາະວ່າ ... ການຮ້ອງຂໍ http ຈາກຕົວທ່ອງເວັບໄດ້ຖືກສົ່ງໄປຫາໂດເມນ GA ແລະ Segment. ອີງຕາມຄວາມປາດຖະຫນາຂອງລູກຄ້າຂອງພວກເຮົາ, ພວກເຮົາໄດ້ສ້າງການບໍລິການການວິເຄາະທີ່ເກັບກໍາຂໍ້ມູນທີ່ກໍານົດໄວ້ຢ່າງສົມບູນ (ໂດຍບໍ່ມີການເກັບຕົວຢ່າງ), ແມ່ນບໍ່ເສຍຄ່າແລະສາມາດເຮັດວຽກກ່ຽວກັບໂຄງສ້າງພື້ນຖານຂອງພວກເຮົາເອງ.

ການບໍລິການເຮັດວຽກແນວໃດ

ການບໍລິການປະກອບມີສາມສ່ວນ: javascript pixel (ເຊິ່ງຕໍ່ມາພວກເຮົາຂຽນໃຫມ່ໃນ typescript), ສ່ວນເຊີຟເວີຖືກປະຕິບັດໃນພາສາ GO, ແລະໄດ້ມີການວາງແຜນທີ່ຈະໃຊ້ Redshift ແລະ BigQuery ເປັນຖານຂໍ້ມູນພາຍໃນ (ຕໍ່ມາພວກເຂົາໄດ້ເພີ່ມການສະຫນັບສະຫນູນສໍາລັບ Postgres, ClickHouse ແລະ Snowflake).

ມັນໄດ້ຖືກຕັດສິນໃຈທີ່ຈະອອກຈາກໂຄງສ້າງຂອງເຫດການ GA ແລະ Segment ບໍ່ປ່ຽນແປງ. ທັງຫມົດທີ່ຈໍາເປັນແມ່ນເພື່ອຊ້ໍາກັນເຫດການທັງຫມົດຈາກຊັບພະຍາກອນເວັບໄຊຕ໌ທີ່ pixels ລວງໄດ້ຖືກຕິດຕັ້ງໃສ່ backend ຂອງພວກເຮົາ. ຍ້ອນວ່າມັນຫັນອອກ, ນີ້ບໍ່ແມ່ນການຍາກທີ່ຈະເຮັດ. Javascript pixel ທັບຊ້ອນວິທີການຫ້ອງສະຫມຸດ 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 arbitrary:

//Отправка событий с произвольным 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, ຕື່ມຂໍ້ມູນໃສ່ພວກເຂົາດ້ວຍຂໍ້ມູນເພີ່ມເຕີມ, ຕົວຢ່າງ, ຂໍ້ມູນທາງພູມສາດ (ຂໍຂອບໃຈ ໃຈສູງສຸດ ສໍາລັບການນີ້) ແລະບັນທຶກມັນຢູ່ໃນຖານຂໍ້ມູນ. ພວກ​ເຮົາ​ຕ້ອງ​ການ​ທີ່​ຈະ​ເຮັດ​ໃຫ້​ການ​ບໍ​ລິ​ການ​ເປັນ​ສະ​ດວກ​ເທົ່າ​ທີ່​ເປັນ​ໄປ​ໄດ້​ເພື່ອ​ໃຫ້​ມັນ​ສາ​ມາດ​ນໍາ​ໃຊ້​ທີ່​ມີ​ການ​ຕັ້ງ​ຄ່າ​ຫນ້ອຍ​. ພວກເຮົາໄດ້ປະຕິບັດຫນ້າທີ່ກໍານົດໂຄງການຂໍ້ມູນໂດຍອີງໃສ່ໂຄງສ້າງຂອງເຫດການ 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 ປະຈຸບັນພຽງແຕ່ປ່ຽນເປັນ strings ເນື່ອງຈາກວ່າ ບໍ່ແມ່ນຖານຂໍ້ມູນທີ່ກ່ຽວຂ້ອງທັງໝົດຮອງຮັບຊ່ອງຂໍ້ມູນຊ້ຳໆ. ມັນຍັງເປັນໄປໄດ້ທີ່ຈະປ່ຽນຊື່ພາກສະຫນາມຫຼືລຶບພວກມັນໂດຍໃຊ້ກົດລະບຽບການສ້າງແຜນທີ່ທາງເລືອກ. ພວກເຂົາເຈົ້າອະນຸຍາດໃຫ້ທ່ານສາມາດປ່ຽນແຜນຜັງຂໍ້ມູນຖ້າຈໍາເປັນຫຼືປ່ຽນປະເພດຂໍ້ມູນຫນຶ່ງໄປຫາອີກ. ຕົວຢ່າງ, ຖ້າຊ່ອງ 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

ພວກເຮົາຍັງຄິດວ່າຜູ້ໃຊ້ຄວນຈະສາມາດ configure ການແບ່ງສ່ວນຫຼືແບ່ງຂໍ້ມູນໃນຖານຂໍ້ມູນຕາມເງື່ອນໄຂອື່ນໆແລະປະຕິບັດຄວາມສາມາດໃນການກໍານົດຊື່ຕາຕະລາງທີ່ມີຄ່າຄົງທີ່ຫຼື. ການສະແດງອອກ ໃນ​ການ​ຕັ້ງ​ຄ່າ​. ໃນຕົວຢ່າງຂ້າງລຸ່ມນີ້, ເຫດການຈະຖືກບັນທຶກໄວ້ໃນຕາຕະລາງທີ່ມີຊື່ທີ່ຄິດໄລ່ໂດຍອີງໃສ່ຄ່າຂອງຊ່ອງຂໍ້ມູນ product_type ແລະ _timestamp (ຕົວຢ່າງ: ອຸປະກອນ_2020_10):

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

ຢ່າງໃດກໍ່ຕາມ, ໂຄງສ້າງຂອງເຫດການທີ່ເຂົ້າມາສາມາດປ່ຽນແປງໃນເວລາແລ່ນ. ພວກເຮົາໄດ້ປະຕິບັດສູດການຄິດໄລ່ເພື່ອກວດເບິ່ງຄວາມແຕກຕ່າງລະຫວ່າງໂຄງສ້າງຂອງຕາຕະລາງທີ່ມີຢູ່ແລ້ວແລະໂຄງສ້າງຂອງເຫດການທີ່ເຂົ້າມາ. ຖ້າພົບຄວາມແຕກຕ່າງ, ຕາຕະລາງຈະຖືກປັບປຸງດ້ວຍຊ່ອງຂໍ້ມູນໃຫມ່. ເພື່ອເຮັດສິ່ງນີ້, ໃຊ້ patch SQL query:

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

ຖາປັດຕະຍະ

ເປັນຫຍັງທ່ານຈໍາເປັນຕ້ອງຂຽນເຫດການໃນລະບົບໄຟລ໌, ແລະບໍ່ພຽງແຕ່ຂຽນມັນໂດຍກົງໃສ່ຖານຂໍ້ມູນ? ຖານ​ຂໍ້​ມູນ​ບໍ່​ສະ​ເຫມີ​ໄປ​ປະ​ຕິ​ບັດ​ໄດ້​ດີ​ໃນ​ເວ​ລາ​ທີ່​ກ່ຽວ​ກັບ​ການ​ຈໍາ​ນວນ​ຫຼາຍ​ຂອງ​ການ​ແຊກ (ຄໍາແນະນໍາຂອງ Postgres). ເພື່ອເຮັດສິ່ງນີ້, Logger ຂຽນເຫດການທີ່ເຂົ້າມາໃນໄຟລ໌ແລະໃນ goroutine ແຍກຕ່າງຫາກ (ກະທູ້) File reader ອ່ານໄຟລ໌, ຫຼັງຈາກນັ້ນຂໍ້ມູນຈະຖືກແປງແລະກໍານົດ. ຫຼັງຈາກຜູ້ຈັດການຕາຕະລາງເຮັດໃຫ້ແນ່ໃຈວ່າຕາຕະລາງຕາຕະລາງແມ່ນທັນສະໄຫມ, ຂໍ້ມູນຈະຖືກຂຽນໃສ່ຖານຂໍ້ມູນໃນຫນຶ່ງຊຸດ. ຕໍ່ມາ, ພວກເຮົາໄດ້ເພີ່ມຄວາມສາມາດໃນການຂຽນຂໍ້ມູນໂດຍກົງກັບຖານຂໍ້ມູນ, ແຕ່ພວກເຮົາໃຊ້ໂຫມດນີ້ສໍາລັບເຫດການທີ່ບໍ່ມີຈໍານວນຫລາຍ - ຕົວຢ່າງ, ການແປງ.

Open Source ແລະແຜນການສໍາລັບອະນາຄົດ

ໃນບາງຈຸດ, ການບໍລິການເລີ່ມເບິ່ງຄືວ່າເປັນຜະລິດຕະພັນທີ່ເຕັມໄປດ້ວຍຄວາມສາມາດແລະພວກເຮົາໄດ້ຕັດສິນໃຈປ່ອຍມັນໃຫ້ກັບ Open Source. ໃນປັດຈຸບັນ, ການເຊື່ອມໂຍງກັບ Postgres, ClickHouse, BigQuery, Redshift, S3, Snowflake ໄດ້ຖືກປະຕິບັດ. ການເຊື່ອມໂຍງທັງຫມົດສະຫນັບສະຫນູນທັງຮູບແບບ batch ແລະ streaming ຂອງການໂຫຼດຂໍ້ມູນ. ເພີ່ມການສະຫນັບສະຫນູນການຮ້ອງຂໍຜ່ານ API.

ໂຄງ​ການ​ລວມ​ໃນ​ປັດ​ຈຸ​ບັນ​ເບິ່ງ​ຄື​ນີ້​:

ເຖິງແມ່ນວ່າການບໍລິການສາມາດຖືກນໍາໃຊ້ເປັນເອກະລາດ (ຕົວຢ່າງເຊັ່ນການນໍາໃຊ້ Docker), ພວກເຮົາຍັງມີ ສະບັບທີ່ເປັນເຈົ້າພາບ, ທີ່ທ່ານສາມາດຕັ້ງຄ່າການເຊື່ອມໂຍງກັບສາງຂໍ້ມູນ, ເພີ່ມ CNAME ກັບໂດເມນຂອງທ່ານແລະເບິ່ງສະຖິຕິກ່ຽວກັບຈໍານວນເຫດການ. ແຜນການທັນທີຂອງພວກເຮົາແມ່ນເພື່ອເພີ່ມຄວາມສາມາດໃນການລວບລວມສະຖິຕິບໍ່ພຽງແຕ່ຈາກຊັບພະຍາກອນເວັບ, ແຕ່ຍັງຂໍ້ມູນຈາກແຫຼ່ງຂໍ້ມູນພາຍນອກແລະບັນທຶກພວກມັນໄວ້ໃນບ່ອນເກັບຂໍ້ມູນທີ່ທ່ານເລືອກ!

→ GitHub
→ Документация
→ slack

ພວກເຮົາຈະດີໃຈຖ້າ EventNative ຊ່ວຍແກ້ໄຂບັນຫາຂອງເຈົ້າ!

ພຽງແຕ່ຜູ້ໃຊ້ລົງທະບຽນສາມາດເຂົ້າຮ່ວມໃນການສໍາຫຼວດ. ເຂົ້າ​ສູ່​ລະ​ບົບກະລຸນາ.

ລະບົບການເກັບກຳສະຖິຕິອັນໃດທີ່ໃຊ້ຢູ່ໃນບໍລິສັດຂອງເຈົ້າ?

• 48,0%Google Analytics12

• 4,0%ພາກທີ1

• 16,0%ອື່ນ (ຂຽນໃນຄໍາເຫັນ) 4

• 32,0%ປະຕິບັດການບໍລິການຂອງເຈົ້າ 8

25 ຜູ້ໃຊ້ລົງຄະແນນສຽງ. 6 ຜູ້ໃຊ້ງົດ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com