데이터 적재 시스템 구축

신규 데이터 분석을 위해, 선발된 데이터들을 BigQuery와 Mixpanel에 등록해야 한다.

 

■ As-is

• BigQuery에 주기적으로 데이터를 insert, update해야한다.
• EC2 to BigQuery는 전송 가능하지만, EC2 to Mixpanel은 보안상 전송할 수 없다

■ Challenge

• 주기적으로 데이터를 전송하도록 Jenkins Scheduler사용.
• BigQuery to Mixpanel로 데이터를 전송하도록 결정.
  • GCP의 vm instance에 cron으로 GCP Scheduler 사용.
  • bq 명령어를 사용하여 Buckit에 전송 데이터 적재.
  • Cloud Function의 Trigger를 사용하여 Buckit Update시 Mixpanel로 데이터 전송.

■ To-be

• 신규 데이터 분석 구축.
• 해당 기능을 사용하여 다른 데이터도 적재 파이프라인도 쉽게 구축할 수 있다.

---

Mixpanel에 관련

 

■ As-is

• Java용 Mixpanel 라이브러리가 없다.
  
  • 사용자의 Identity ID를 발급, 확인 할 수 없다.
  • Identity ID 대신 Distinct ID로 등록할 수 있지만, 이 경우 사전 작업이 필요하다.
• Java에서 데이터를 바로 업로드할 수 없다.

■ Challenge

• 프론트앤드 팀에서 Distinct ID를 백엔드팀에서 전달받아 등록하기로 결정.
  • Distinct ID는 자체 설정 가능하여 사용자 ID를 Hash화 하여 저장.
  • Key-value 값으로 저장하기에 RDB대신 Redis를 사용하여 저장.
  • 클라이언트에서 요청시 있으면 결과를 리턴하고, 없으면 생성 후 리턴.
• 업로드 이슈는 GCP에서 보내는 방법으로 수정.

---

BigQuery 관련

 

■ As-is

• 대용량의 데이터를 insert, update 하는데 시간이 오래 걸린다.
• Jenkins Scheduler의 ReadTimeout을 무한정 기다릴수 없다.
• BigQuery의 Update Query처리 속도가 느려 실패하는 데이터가 발생한다.
  • Insert는 500개씩 Bulk처리가 가능하지만, Update는 1개의 row씩 수정할 수 밖에없다.
• BigQuery에서 Buckit으로 데이터 전송 시 하나의 테이블 데이터만 전송 할 수 있어, 데이터 조합을 할 수 없다.
• BigQuery의 데이터를 Mixpanel API가 원하는 형태로 변경해야 한다.

■ Challenge

• RabbitMQ를 사용하여 Jenkins Scheduler와 비동기 처리.
• 이중화된 서버에서 RabbitMQ의 Consumer를 1개에서 5개로 늘려 총 10개의 Consumer로 분산처리.
• Conumser의 Prefetch Count 설정을 1로 변경하여 처리가 오래걸리는 Update Query를 여러개 들고있지 않도록 수정.
• Update도 Bulk로 처리하기 위해, 데이터 분석팀과 협의 후 Type을 나누고 최대한 Bulk처리.
• GCP vm instance에서 bq 명령어를 통해 임시 BigQuery 테이블을 만들고, 여러 BigQuery 테이블을 조합하여 데이터를 신규 BigQuery 테이블에 저장후, Buckit으로 데이터를 전송

■ To-be

• Update Query로 인해 7시간이상 또는 전송 실패하던 로직을 1시간 이내로 성공하도록 변경.

---

■ Will

• 회사에서 Amazon Web Service를 사용하니까.. 위와 같은 분석툴도 Amazon Web Service것을 사용하면 더 좋을 것 같다.