復(fù)雜業(yè)務(wù)是從數(shù)據(jù)搜集者的角度來看的，也就是說，在線下要收集到整個業(yè)務(wù)流程的各個信息經(jīng)常需要將多個來源的日志、binlog、消息隊(duì)列等的數(shù)據(jù)join在一起，形成一個所謂的“寬表”。

　　之所以會出現(xiàn)這樣的場景一般有如下原因：

　　業(yè)務(wù)邏輯較為復(fù)雜，無法在一個大服務(wù)里維護(hù)，只能拆解為多個模塊，每個處理自己相關(guān)的部分。

　　由于請求量比較大，將所有狀態(tài)和歷史信息都放在一個數(shù)據(jù)庫表中會對數(shù)據(jù)庫的壓力比較大，所以一般會按字段關(guān)聯(lián)性和訪問服務(wù)的耦合進(jìn)行拆解，拆分為多個邏輯表。

　　還有一些業(yè)務(wù)歷史信息，因?yàn)闃I(yè)務(wù)本身不再需要訪問，都放在數(shù)據(jù)庫中不經(jīng)濟(jì)，往往會形成日志或日志消息，等待異步/離線分析。

　　實(shí)時監(jiān)控指標(biāo)與特征

　　從生產(chǎn)方式的角度上來說，實(shí)時監(jiān)控與實(shí)時特征其實(shí)是同一類，差別主要就在到底是人來觀察，還是給線上模型/程序來使用。

　　雖然工程實(shí)現(xiàn)的時候會盡量傾向于拆解和解耦，但大部分業(yè)務(wù)相關(guān)的監(jiān)控指標(biāo)和業(yè)務(wù)特征的粒度都比最終工程拆解的粒度要大，所以經(jīng)常需要融合多個來源的數(shù)據(jù)之后才能產(chǎn)生。這時我們不光要在線下做數(shù)據(jù)join，還經(jīng)常需要在線上實(shí)時的join各來源的數(shù)據(jù)，形成線上實(shí)時寬表數(shù)據(jù)。

　　在一些不太復(fù)雜的系統(tǒng)中，這種邏輯可能會直接在數(shù)據(jù)使用方實(shí)現(xiàn)，數(shù)據(jù)使用方直接請求各個原始數(shù)據(jù)源并實(shí)時計(jì)算響應(yīng)的結(jié)果，這不可避免地增加了線上存儲系統(tǒng)的讀壓力。

　　但直接和線上業(yè)務(wù)使用同一個存儲系統(tǒng)是不經(jīng)濟(jì)的，因?yàn)椋?/p>

　　線上業(yè)務(wù)主要關(guān)心的業(yè)務(wù)狀態(tài)的一致性，并且業(yè)務(wù)需要的讀寫性能能夠滿足業(yè)務(wù)流量的需求。

　　實(shí)時監(jiān)控大多數(shù)時候不關(guān)心單個case級的異常，而是關(guān)心一段時間內(nèi)的整體狀態(tài)分布。不需要太強(qiáng)的一致性，對時效性有一定要求（分鐘級）。

　　由于大部分實(shí)時特征也都不需要非常嚴(yán)格的準(zhǔn)確性，模型能夠自動承受一定范圍內(nèi)的抖動，所以實(shí)時特征的場景下，也不需要嚴(yán)格的一致性，時效性方面只要不影響模型最終效果就好。

　　所以很明顯，結(jié)論是實(shí)時監(jiān)控和特征沒必要和線上業(yè)務(wù)使用相同的存儲系統(tǒng)。

　　業(yè)務(wù)實(shí)時狀態(tài)視圖

　　考慮到監(jiān)控和特征都是經(jīng)常變動的，所以為他們服務(wù)的存儲方式在性能能接受的情況下，最好是直接保存所有最細(xì)粒度的訂單級數(shù)據(jù)，由每個指標(biāo)來定義聚合方式。

　　那么這個在邏輯上就是一個實(shí)時更新的數(shù)據(jù)寬表，考慮到需求方?jīng)]有強(qiáng)一致的需求，可以接受數(shù)據(jù)上有輕微的延遲和不一致。

　　在實(shí)現(xiàn)層面可以：

　　直接使用線上數(shù)據(jù)庫的從庫

　　實(shí)時計(jì)算join所有數(shù)據(jù)源

　　單獨(dú)為此準(zhǔn)備的寬表數(shù)據(jù)庫，當(dāng)接收到業(yè)務(wù)狀態(tài)變更時進(jìn)行更新等，根據(jù)具體場景選擇合適的方案。

　　標(biāo)簽：車底監(jiān)控