오픈 소스의 역사: Go에서 분석 서비스를 만들고 이를 공개적으로 제공한 방법

현재 전 세계 거의 모든 회사는 웹 리소스에서 사용자 작업에 대한 통계를 수집합니다. 동기는 분명합니다. 기업은 제품/웹사이트가 어떻게 사용되는지 알고 싶어하며 사용자를 더 잘 이해하고 싶어합니다. 물론 시장에는 대시보드와 그래프 형식으로 데이터를 제공하는 분석 시스템부터 이 문제를 해결하기 위한 수많은 도구가 나와 있습니다(예: Google Analytics)를 고객 데이터 플랫폼에 추가하여 모든 창고의 다양한 소스에서 데이터를 수집하고 집계할 수 있습니다(예: 구획).

하지만 아직 해결되지 않은 문제를 발견했습니다. 그리하여 탄생했다 이벤트네이티브 — 오픈 소스 분석 서비스. 우리가 자체 서비스를 개발하기로 결정한 이유, 그것이 우리에게 제공한 것, 그리고 최종 결과가 무엇인지(코드 조각 포함) 읽어보세요.

왜 우리만의 서비스를 개발해야 할까요?

2019년대였고, 우리는 최선을 다해 살아 남았습니다. XNUMX년 API First 고객 데이터 플랫폼을 개발했습니다. kSense, 보다 편리한 데이터 분석, 종속성 식별 등을 위해 다양한 소스(Facebook 광고, Stripe, Salesforce, Google Play, Google Analytics 등)의 데이터를 집계할 수 있게 되었습니다. 많은 사용자가 데이터 분석, 특히 Google Analytics(이하 GA) 플랫폼을 사용하는 것으로 나타났습니다. 일부 사용자와 대화를 나눈 결과 GA를 사용하여 받는 제품에 대한 분석 데이터가 필요하다는 사실을 알게 되었지만 Google 샘플 데이터 그리고 많은 사람들에게 GA 사용자 인터페이스는 편의의 표준이 아닙니다. 우리는 사용자들과 충분한 대화를 나눴고 많은 사람들이 Segment 플랫폼을 사용하고 있다는 것을 깨달았습니다. 3.2억 달러에 매각).

그들은 웹 리소스에 세그먼트 자바스크립트 픽셀을 설치했고 사용자의 행동에 대한 데이터가 지정된 데이터베이스(예: Postgres)에 로드되었습니다. 그러나 Segment에는 가격이라는 단점도 있습니다. 예를 들어, 웹 리소스에 90,000 MTU(월별 추적 사용자)가 있는 경우 계산원에게 매월 ~1,000달러를 지불해야 합니다. 세 번째 문제도 있었습니다. 일부 브라우저 확장 프로그램(예: AdBlock)은 다음과 같은 이유로 분석 정보 수집을 차단했습니다. 브라우저의 http 요청은 GA 및 세그먼트 도메인으로 전송되었습니다. 우리는 고객의 희망에 따라 전체 데이터 세트(샘플링 없이)를 수집하고 무료이며 자체 인프라에서 작동할 수 있는 분석 서비스를 만들었습니다.

서비스 작동 방식

서비스는 세 부분으로 구성됩니다. JavaScript 픽셀(나중에 TypeScript로 다시 작성), 서버 부분은 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);
        });
    });
}

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 필드에 타임스탬프가 있는 문자열이 포함된 경우(field_3_sub_field_1_sub_sub_field_1 위의 예에서), 데이터베이스에 타임스탬프 유형의 필드를 생성하려면 구성에 매핑 규칙을 작성해야 합니다. 즉, 필드의 데이터 유형이 먼저 json 값에 의해 결정된 다음 유형 캐스팅 규칙(구성된 경우)이 적용됩니다. 우리는 STRING, FLOAT4, INT64 및 TIMESTAMP의 64가지 주요 데이터 유형을 확인했습니다. 매핑 및 유형 캐스팅 규칙은 다음과 같습니다.

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

또한 사용자가 다른 기준에 따라 데이터베이스의 데이터를 파티셔닝하거나 나눌 수 있어야 한다고 생각하고 테이블 이름을 상수 또는 변수로 설정할 수 있는 기능을 구현했습니다. 표현 구성에서. 아래 예에서 이벤트는 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명의 사용자가 기권했습니다.

출처 : habr.com