1. 程式人生 > >除錯與優化:一次資料中心看板 T+1 改 T+0 優化過程

除錯與優化:一次資料中心看板 T+1 改 T+0 優化過程

背景

團隊目前在做一個使用者資料看板(下面簡稱看板),基本覆蓋使用者的所有行為資料,並生成分析資料,使用者行為資料來源於多個數據源(餐飲、生活日用、充值消費、交通出行、通訊物流、交通出行、醫療保健、住房物業、運動健康...),基於對大量資料的任意請求、排序和統計,沒有辦法對原生表(原生多表查詢相對複雜)直接進行資料採用,所以我們在當日的凌晨獲取前一天資料,並將資料做成Json物件儲存在Mongo資料庫中。

所以看板最初採用得是T+1的策略,這樣就減少了實時資料計算的過程,另一方面能夠保證資料的準確性。但是目前很多人反饋,希望能夠實時的獲取到看板最新的資料,而且每月月底輝有消費資料核對,消費資料按照看板統計得出並核對,如果等到第二天(也就是次月1號)再輸出資料報表,這種體驗就太差了。

優化方案

針對看板的原型需求和資料呈現形式,形成了類似 (資料(Mongo)服務 - 介面服務 - 前端展示頁面)的架構模式,以T+1的策略提供資料,

來保障使用者可以高效的瀏覽到自己的行為資料結構,並給出具體得資料分析和建議。

原有流程:通過設計開發控制檯排程服務,並部署到中心伺服器上,排程配置每天凌晨一點做服務啟動,會根據使用者新增和修改的日誌做資料增量。

優化目標:改成每次使用者行為資料的修改、刪除和儲存都採用訊息佇列形式實時的通知到服務去消費,服務消費之後立刻把Mongo的行為資料做好。

T+0 服務概要設計

核心功能實現設計 

1、使用者行為資料儲存後實時傳送MQ訊息通知,解耦行為資料儲存和看板資料生產的強關聯。

2、開發獨立服務消費MQ,同步聚合看板資料、輸出使用者行為資料報表,並推送通知訊息給使用者進行檢視。

資料服務生成流程

 

時序圖/流程圖說明

1、原有是獨立服務每天凌晨進行資料計算,改成每次使用者行為完成修改之後傳送MQ

2、服務端程式監聽MQ,消費到資料,則呼叫排程服務進行處理

3、排程服務根據配置好的排程規則,進行控制檯服務啟動,並將對應的資料增量拉取到記憶體中,進行資料的篩選、排序、整合,合併成目標mongo文件,並儲存到mongo叢集中

4、排程服務資料處理完成之後,同步聚合看板資料、輸出使用者行為資料報表,並推送通知訊息給使用者進行檢視。

資料聚合過程說明 

所有的使用者行為模組都遵循這個規則,最後實現資料T+0 實時聚合的目標

&n