የክፍት ምንጫችን ታሪክ፡ በGo ውስጥ የትንታኔ አገልግሎትን እንዴት እንደሰራን እና በይፋ እንዲገኝ እንዳደረግነው

በአሁኑ ጊዜ በዓለም ላይ ያለ እያንዳንዱ ኩባንያ ማለት ይቻላል በድር ምንጭ ላይ ስለተጠቃሚ እርምጃዎች ስታቲስቲክስን ይሰበስባል። ተነሳሽነቱ ግልጽ ነው - ኩባንያዎች ምርቶቻቸው/ድረ-ገጻቸው እንዴት ጥቅም ላይ እንደሚውል ማወቅ እና ተጠቃሚዎቻቸውን በተሻለ መልኩ መረዳት ይፈልጋሉ። በእርግጥ ይህንን ችግር ለመፍታት በገበያ ላይ ብዙ ቁጥር ያላቸው መሳሪያዎች አሉ - በዳሽቦርድ እና በግራፍ መልክ መረጃን ከሚሰጡ የትንታኔ ስርዓቶች (ለምሳሌ ፣ google ትንታኔዎች) በማንኛውም መጋዘን ውስጥ ከተለያዩ ምንጮች መረጃን ለመሰብሰብ እና ለማዋሃድ ወደ ሚፈቅደው የደንበኛ ዳታ መድረክ (ለምሳሌ ክፋይ).

ግን እስካሁን ያልተፈታ ችግር አግኝተናል። ስለዚህም ተወለደ ክስተትNative - ክፍት ምንጭ ትንታኔ አገልግሎት. የራሳችንን አገልግሎት ለማዳበር ለምን እንደወሰንን, ምን እንደሰጠን እና የመጨረሻው ውጤት ምን እንደሆነ (ከኮድ ቁርጥራጮች ጋር) ያንብቡ.

የራሳችንን አገልግሎት ማዳበር ያለብን ለምንድን ነው?

ዘጠናዎቹ ነበር፣ የምንችለውን ያህል ተረፍን። 2019፣ የኤፒአይ የመጀመሪያ የደንበኛ ውሂብ መድረክን ገንብተናል kSense, ይህም ከተለያዩ ምንጮች (የፌስቡክ ማስታወቂያዎች, ስትሪፕ, Salesforce, Google play, Google Analytics, ወዘተ) መረጃን ለበለጠ ምቹ የመረጃ ትንተና, ጥገኝነቶችን መለየት, ወዘተ. ብዙ ተጠቃሚዎች የእኛን መድረክ ለመረጃ ትንተና በተለይም ጎግል አናሌቲክስ (ከዚህ በኋላ GA) እንደሚጠቀሙ አስተውለናል። አንዳንድ ተጠቃሚዎችን አነጋግረን GA በመጠቀም ለሚቀበሉት ምርታቸው የትንታኔ ዳታ እንደሚያስፈልጋቸው አወቅን። Google ናሙናዎች ውሂብ እና ለብዙዎች የ GA የተጠቃሚ በይነገጽ የምቾት ደረጃ አይደለም። ከተጠቃሚዎቻችን ጋር በቂ ውይይት አድርገን ነበር እና ብዙዎች የሴክሽን መድረክንም እየተጠቀሙ መሆናቸውን ተረዳን (በነገራችን ላይ፣ ልክ ሌላ ቀን ነበር) በ3.2 ቢሊዮን ዶላር ተሸጧል).

የክፍል ጃቫስክሪፕት ፒክሰል በድር ሀብታቸው ላይ ጫኑ እና የተጠቃሚዎቻቸው ባህሪ መረጃ ወደተገለጸው የውሂብ ጎታ (ለምሳሌ Postgres) ተጭኗል። ነገር ግን ክፍል እንዲሁ አሉታዊ ጎን አለው - ዋጋው። ለምሳሌ፣ የድረ-ገጽ ምንጭ 90,000 MTU (በወር ክትትል የሚደረግባቸው ተጠቃሚዎች) ካለው፣ በወር ~1,000$ ለካሳሪው መክፈል አለቦት። ሦስተኛው ችግርም ነበር - አንዳንድ የአሳሽ ቅጥያዎች (እንደ አድብሎክ ያሉ) የትንታኔዎችን ስብስብ አግደዋል ምክንያቱም... ከአሳሹ የ http ጥያቄዎች ወደ GA እና ክፍል ጎራዎች ተልከዋል። በደንበኞቻችን ፍላጎት መሰረት የተሟላ የውሂብ ስብስብ (ናሙና ሳይደረግ) የሚሰበስብ, ነፃ እና በራሳችን መሠረተ ልማት ላይ የሚሰራ የትንታኔ አገልግሎት ፈጠርን.

አገልግሎቱ እንዴት እንደሚሰራ

አገልግሎቱ ሶስት ክፍሎችን ያቀፈ ነው፡- ጃቫስክሪፕት ፒክሰል (በኋላ በታይፕ የፃፍነው)፣ የአገልጋዩ ክፍል በGO ቋንቋ የተተገበረ ሲሆን Redshift እና BigQueryን እንደ የውስጥ ዳታቤዝ ለመጠቀም ታቅዶ ነበር (በኋላ ድጋፍ ጨምረዋል። Postgres፣ ClickHouse እና Snowflake)።

የ GA እና ክፍል ክስተቶች መዋቅር ሳይለወጥ ለመተው ተወስኗል። የሚያስፈልገው ነገር ቢኖር ፒክስል ከተጫነበት የድረ-ገጽ ምንጭ ሁሉንም ክስተቶች ወደ ኋለኛ ክፍል ማባዛት ነበር። እንደ ተለወጠ, ይህን ለማድረግ አስቸጋሪ አይደለም. የጃቫስክሪፕት ፒክሴል የመጀመሪያውን የ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);
        });
    });
}

በሴጅመንት ፒክሴል ሁሉም ነገር ቀላል ነው፡ የመሃል ዌር ዘዴዎች አሉት፣ ከእነዚህም ውስጥ አንዱ ተጠቀምን።

//'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 መዋቅርን ወደ ጠፍጣፋ መዋቅር ይለውጡ
• የመስኮችን የውሂብ አይነት በእሴቶች መወሰን
• የካርታ ስራ እና የመተየብ ደንቦችን መተግበር

ከዚያ ከሚመጣው 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

እንዲሁም ተጠቃሚው በመረጃ ቋቱ ውስጥ መረጃን በሌሎች መስፈርቶች ማዋቀር ወይም መከፋፈል መቻል አለበት ብለን አሰብን እና የጠረጴዛውን ስም በቋሚ ወይም በቋሚነት የማዘጋጀት ችሎታን ተግባራዊ እናደርጋለን ። አገላለጽ በማዋቀር ውስጥ. ከዚህ በታች ባለው ምሳሌ ዝግጅቱ በምርት ዓይነት እና በ _timestamp መስኮች (ለምሳሌ) እሴቶች ላይ በመመስረት የተሰላው ስም ባለው ሠንጠረዥ ውስጥ ይቀመጣል አቅርቦቶች_2020_10):

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

ነገር ግን፣ የገቢ ክስተቶች አወቃቀሩ በሂደት ጊዜ ሊለወጥ ይችላል። አሁን ባለው ሰንጠረዥ አወቃቀር እና በመጪው ክስተት መዋቅር መካከል ያለውን ልዩነት ለመፈተሽ ስልተ ቀመርን ተግባራዊ አድርገናል። ልዩነት ከተገኘ, ሠንጠረዡ በአዲስ መስኮች ይዘምናል. ይህንን ለማድረግ የ patch SQL ጥያቄን ይጠቀሙ፡-

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

ሥነ ሕንፃ

ለምንድነው ክስተቶችን ወደ የፋይል ስርዓቱ መጻፍ, እና በቀጥታ ወደ የውሂብ ጎታ ብቻ መጻፍ ብቻ ሳይሆን? የመረጃ ቋቶች ብዙ ቁጥር ካላቸው ማስገቢያዎች ጋር ሲገናኙ ሁልጊዜ ጥሩ አፈጻጸም የላቸውም (Postgres ምክሮች). ይህንን ለማድረግ ሎገር የሚመጡ ክስተቶችን ወደ ፋይል ይጽፋል እና በተለየ ጎሮቲን (ክር) ፋይል አንባቢ ፋይሉን ያነባል, ከዚያም ውሂቡ ይለወጣል እና ይወሰናል. የሰንጠረዡ አቀናባሪ የሠንጠረዡ ንድፍ ወቅታዊ መሆኑን ካረጋገጠ በኋላ ውሂቡ በአንድ ባች ወደ ዳታቤዝ ይጻፋል። በመቀጠል, ውሂብን በቀጥታ ወደ የውሂብ ጎታ የመፃፍ ችሎታን ጨምረናል, ነገር ግን ይህንን ሁነታ ብዙ ላልሆኑ ክስተቶች እንጠቀማለን - ለምሳሌ, ልወጣዎች.

ክፍት ምንጭ እና የወደፊት እቅዶች

በአንድ ወቅት አገልግሎቱ የተሟላ ምርት መምሰል ጀመረ እና ወደ ክፍት ምንጭ ለመልቀቅ ወሰንን. በአሁኑ ጊዜ ከ Postgres፣ ClickHouse፣ BigQuery፣ Redshift፣ S3፣ Snowflake ጋር ውህደቶች ተተግብረዋል። ሁሉም ውህደቶች የውሂብ ጭነት ሁለቱንም ባች እና የዥረት ሁነታዎች ይደግፋሉ። በኤፒአይ በኩል ለጥያቄዎች ድጋፍ ታክሏል።

አሁን ያለው የውህደት እቅድ ይህን ይመስላል።

ምንም እንኳን አገልግሎቱ በተናጥል (ለምሳሌ ዶከርን በመጠቀም) መጠቀም ቢቻልም እኛ ደግሞ አለን። የተስተናገደ ስሪትከውሂብ ማከማቻ ጋር ውህደትን ማዋቀር የምትችልበት፣ በጎራህ ላይ CNAME ጨምር እና የክስተቶች ብዛት ላይ ስታቲስቲክስን ተመልከት። የእኛ የቅርብ ጊዜ ዕቅዶች ከድር ምንጭ የሚገኘውን ስታቲስቲክስን ብቻ ሳይሆን ከውጫዊ የመረጃ ምንጮች የተገኙ መረጃዎችን በማዋሃድ ወደ መረጡት ማንኛውም ማከማቻ የማስቀመጥ ችሎታን ማከል ነው!

→ የፊልሙ
→ ሰነድ
→ ትወርሱ

EventNative የእርስዎን ችግሮች ለመፍታት የሚረዳ ከሆነ ደስተኞች ነን!

በዳሰሳ ጥናቱ ውስጥ የተመዘገቡ ተጠቃሚዎች ብቻ መሳተፍ ይችላሉ። ስግን እንእባክህን።

በድርጅትዎ ውስጥ ምን ዓይነት የስታቲስቲክስ አሰባሰብ ስርዓት ጥቅም ላይ ይውላል?

• 48,0%ጉግል አናሌቲክስ12

• 4,0%ክፍል 1

• 16,0%ሌላ (በአስተያየቶቹ ውስጥ ይፃፉ) 4

• 32,0%አገልግሎትህን 8

25 ተጠቃሚዎች ድምጽ ሰጥተዋል። 6 ተጠቃሚዎች ድምፀ ተአቅቦ አድርገዋል።

ምንጭ: hab.com