系統(tǒng)架構(gòu)
這是目前我們公司的系統(tǒng)架構(gòu)：
首先是兩個(gè)數(shù)據(jù)，用戶行為數(shù)據(jù)和業(yè)務(wù)數(shù)據(jù)。商品會(huì)員交易庫存這一方面是業(yè)務(wù)數(shù)據(jù)，這些業(yè)務(wù)數(shù)據(jù)多數(shù)存儲(chǔ)在my sql數(shù)據(jù)庫里。埋點(diǎn)系統(tǒng)里的渠道數(shù)據(jù)分為兩端，PC和H5的采集很簡單，用腳本組件進(jìn)行采集，這是通用的。但App就需要打制組件。
拿到數(shù)據(jù)以后會(huì)往flume里面去，到flume里直接取到之后，上面會(huì)搭一層隊(duì)列，因?yàn)槿绻麊渭円揽縡lume的話，系統(tǒng)會(huì)卡死，因?yàn)閒lume經(jīng)常出現(xiàn)卡頓現(xiàn)象，也就是說你去控制他的一些監(jiān)控腳本的話也是沒意義的，因?yàn)橛袝r(shí)候他的內(nèi)存卡住了，資源占用，他依然在那動(dòng)。所以搭建這個(gè)隊(duì)列有個(gè)好處，第一，走的是消費(fèi)者模式；第二，里面有位置信息，一旦出現(xiàn)數(shù)據(jù)錯(cuò)亂可以回補(bǔ)。
這些數(shù)據(jù)，我們首先要滿足實(shí)時(shí)性問題，我們采用的是ES。利用ES做實(shí)時(shí)查詢能解決很多問題，這也是我們原來做大數(shù)據(jù)的時(shí)候經(jīng)常說給到對方企業(yè)采購時(shí)，你會(huì)發(fā)現(xiàn)前期沒問題，但越做到后面我們一直說做數(shù)據(jù)倉要分主題，包括說做Cube之類的，這些都沒有意義，當(dāng)數(shù)據(jù)量達(dá)到一定層級以后，依然很慢。
然后是我們的BI系統(tǒng)。所有BI系統(tǒng)都是在展現(xiàn)層和應(yīng)用層，展現(xiàn)層可以選擇FineReport、echart、excel，這個(gè)根據(jù)企業(yè)的情況去定義。但如果企業(yè)沒有專業(yè)的人員， FineReport是你最好的選擇，如果用別的話，后期維護(hù)成本很高。在BI系統(tǒng)里面不光是做展示你還需要做接口的，這個(gè)信息設(shè)施需要做接口推送給第三方，包括PC、H5、微信的應(yīng)用，都是從這個(gè)系統(tǒng)里出去的，能實(shí)現(xiàn)聚合一個(gè)企業(yè)的所有數(shù)據(jù)，在一個(gè)系統(tǒng)里面進(jìn)行展示。
應(yīng)用案例
電商里面存在很多黃牛黨的事兒。但我們做活動(dòng)的目的是讓用戶享受到實(shí)惠，所以在提交訂單的時(shí)候會(huì)有一個(gè)過程，并不是立即審核通過的，但這個(gè)過程必須很短，要考慮到訂單轉(zhuǎn)化的問題。如下圖，左邊是后臺系統(tǒng)的展示，這是疑似刷單名單的截圖展示。流程是這樣的，用戶提交完訂單以后，會(huì)有一個(gè)模型檢測，這個(gè)模型檢測是純機(jī)器，從模型檢測再到專家知識。如果在模型檢測中符合會(huì)到名單里去，否則會(huì)進(jìn)入到專家支持，專家支持完了以后如果認(rèn)為是正常訂單，才能到支付階段，否則的話都會(huì)到疑似名單，到時(shí)候再人工判斷。
作者：帆軟