摘要：運行過程中，客戶數(shù)據(jù)量集中在早晚高峰。多年運營結(jié)果是并發(fā)和數(shù)據(jù)庫處理能力是統(tǒng)計分析的最大瓶頸。

架構(gòu)使用的語言知識

這幾年數(shù)據(jù)分析迅速發(fā)展，我們也做了一個微數(shù)據(jù)分析工具。該產(chǎn)品已成功運行三年，滿足日活百萬的企業(yè)。產(chǎn)品結(jié)構(gòu)很簡單，用世上最簡單的語言php，最普遍的數(shù)據(jù)庫mysql，服務器可以選擇apache也可以選擇nginx，一切看你自己的喜好。

一、微服務架構(gòu)圖

整個流程圖：
1、SDK上傳數(shù)據(jù)到服務器，如果安裝redis做緩存，數(shù)據(jù)會最先進到redis，然后定時抽取數(shù)據(jù)到DB服務器。有了redis可以大大提高并行數(shù)據(jù)處理能力。
2、數(shù)據(jù)庫收集原始數(shù)據(jù)，存儲過程將數(shù)據(jù)按照不同維度統(tǒng)計各個指標數(shù)據(jù)，同時將數(shù)據(jù)匯總表。
3、前臺報表展示，實時報表、小時報表和天報表數(shù)據(jù)展示。最好做到讀寫分離。

二、功能架構(gòu)

功能架構(gòu)主要包括功能、角色和權限三部分。功能是企業(yè)服務，用戶使用的每一個功能，就是企業(yè)的每一個服務。角色是用戶操作的歸類，功能與角色的對應關系及權限。了解系統(tǒng)架構(gòu)的現(xiàn)狀，從功能架構(gòu)開始。

三、應用架構(gòu)

應用架構(gòu)的內(nèi)容包括現(xiàn)有架構(gòu)圖、web應用現(xiàn)狀和接口架構(gòu)。其中，接口是應用層面的關鍵，它是程序之間交互的部分。
主要包括clientdata、usinglog、event和errorlog等接口。
SDK通過接口定時發(fā)送數(shù)據(jù)到后臺。
應用架構(gòu)羅列出前后端調(diào)用關系。

四、數(shù)據(jù)設計

兩個數(shù)據(jù)庫，大約一百張表。數(shù)據(jù)庫的設計依賴業(yè)務數(shù)據(jù)，對業(yè)務數(shù)據(jù)歸類，導致數(shù)據(jù)設計畫出E_R圖，數(shù)據(jù)設計完成，最終數(shù)據(jù)庫設計就出來了。數(shù)據(jù)庫只要早起設計的號，是可以做到易伸縮、易拆分的。統(tǒng)計類主要分為統(tǒng)計的維度，還有就是用戶、設備、錯誤信息等。
1、數(shù)據(jù)處理能力
日活百萬，啟動次數(shù)大概兩百萬，事件數(shù)和頁面訪問量起碼在三百到五百萬之間，平均每小時數(shù)據(jù)量五十萬。運行過程中，**客戶數(shù)據(jù)量集中在早晚高峰。根據(jù)客戶的特殊情況，會把一些任務安排在閑暇時間段，比如日任務、周任務、月任務等安排在零晨。
好的硬件配置是數(shù)據(jù)處理的好幫手，更大的內(nèi)存更快的硬盤絕對可以讓數(shù)據(jù)流快速執(zhí)行。
2、數(shù)據(jù)清洗和讀寫分離
大量原始數(shù)據(jù)入庫，這些數(shù)據(jù)處理之后就是垃圾數(shù)據(jù)了。當所有報表數(shù)據(jù)都統(tǒng)計之后并寫入各個維度表之后，需要定時把這些數(shù)據(jù)清除掉。
前臺報表展示數(shù)據(jù)跟存儲分析數(shù)據(jù)庫最好分開。

五、物理架構(gòu)

微服務的物理架構(gòu)需要的機器很少，一臺機器也能跑起來。分析統(tǒng)計主要是數(shù)據(jù)處理能力要求很高，數(shù)據(jù)庫服務器需要兩臺，web端需要一臺足矣。多年運營結(jié)果是并發(fā)和數(shù)據(jù)庫處理能力是統(tǒng)計分析的最大瓶頸。

六、繼續(xù)優(yōu)化的方向

1、數(shù)據(jù)讀寫分離，數(shù)據(jù)清洗。
2、并發(fā)量。

七、客戶

客戶最關心的數(shù)據(jù)：
每一個客戶最關心的就是用戶表，用戶新增狀況、用戶活躍情況、用戶留存情況。
不同的客戶對用戶要求不同，需要判斷用戶是否是刷機來的，用戶跟設備號及用戶ID（用戶號碼）之間的映射關系。
事件數(shù)據(jù)也是很重要的，關系轉(zhuǎn)化率。
頁面訪問跟事件是同等重要。
錯誤數(shù)據(jù)可以檢測應用存在的Bug。
不同的客戶，不同的使用場景對指標會有不同需求。
本文原創(chuàng)首發(fā)于Cobub Razor官網(wǎng)博客，作者qhzhang, 轉(zhuǎn)載請注明出處！