關(guān)鍵時刻,，第一時間送達(dá),！

分享嘉賓：楊雄 網(wǎng)易嚴(yán)選 資深研發(fā)工程師

內(nèi)容來源：《基于Flink的嚴(yán)選實時數(shù)倉實踐》

出品社區(qū)：DataFun

今天分享的內(nèi)容主要分為四個部分，首先會介紹下嚴(yán)選實時數(shù)倉的背景,、產(chǎn)生的一些問題,。然后是針對這些背景和問題對實時數(shù)倉的整體設(shè)計和具體的實施方案，接著會介紹下在實時數(shù)倉的數(shù)據(jù)質(zhì)量方面的工作,，最后講一下實時數(shù)倉在嚴(yán)選中的應(yīng)用場景,。

1、背景

嚴(yán)選實時數(shù)倉項目是從17年下半年開始做的,，背景總結(jié)為三個方面：

第一個是長鏈路且快速變化的業(yè)務(wù),，嚴(yán)選作為一個ODM電商，整個業(yè)務(wù)鏈度從商品采購,、生產(chǎn),、倉庫、到銷售這個階段可以在主站APP上購買或者分廠購買,，然后通過商戶配送到達(dá)消費者,。鏈度是非常長的，這也決定數(shù)據(jù)的數(shù)據(jù)域非常廣,；嚴(yán)選作為一個成長的電商,，會有很多新的業(yè)務(wù)出現(xiàn)。

第二個是越來越多的實時數(shù)據(jù)需求,，目前需要更多的實時數(shù)據(jù)來做業(yè)務(wù)決策,，需要依據(jù)銷售情況做一個資源位的調(diào)整；同時有些活動也需要實時數(shù)據(jù)來增強與用戶的互動,。如果數(shù)據(jù)有實時和離線兩種方案,，優(yōu)先考慮實時的，如果實時實現(xiàn)不了再考慮離線的方式,。

第三個就是越來越高的數(shù)據(jù)質(zhì)量要求,，因為數(shù)據(jù)會直接影響業(yè)務(wù)決策,，影響線上運營活動效果，因此對數(shù)據(jù)質(zhì)量的要求越來越高,。

針對這樣的項目背景提出了三個設(shè)計目標(biāo),，第一個是靈活可擴(kuò)展，第二個是開發(fā)效率高,，第三個是數(shù)據(jù)質(zhì)量要求高,。

2、整體設(shè)計和實現(xiàn)

基于這樣的設(shè)計目標(biāo),，介紹一下整體的設(shè)計和實現(xiàn)方案：

實時數(shù)倉整體框架依據(jù)數(shù)據(jù)的流向分為不同的層次,，接入層會依據(jù)各種數(shù)據(jù)接入工具收集各個業(yè)務(wù)系統(tǒng)的數(shù)據(jù)，如買點的業(yè)務(wù)數(shù)據(jù)或者業(yè)務(wù)后臺的并購放到消息隊列里面,。消息隊列的數(shù)據(jù)既是離線數(shù)倉的原始數(shù)據(jù),，也是實時計算的原始數(shù)據(jù)，這樣可以保證實時和離線的原始數(shù)據(jù)是統(tǒng)一的,。有了源數(shù)據(jù),，在計算層經(jīng)過FLink+實時計算引擎做一些加工處理，然后落地到存儲層中不同存儲介質(zhì)當(dāng)中,。不同的存儲介質(zhì)是依據(jù)不同的應(yīng)用場景來選擇,。框架中還有FLink和Kafka的交互,，在數(shù)據(jù)上進(jìn)行一個分層設(shè)計,，計算引擎從Kafka中撈取數(shù)據(jù)做一些加工然后放回Kafka。在存儲層加工好的數(shù)據(jù)會通過服務(wù)層的兩個服務(wù)：統(tǒng)一查詢,、指標(biāo)管理,，統(tǒng)一查詢是通過業(yè)務(wù)方調(diào)取數(shù)據(jù)接口的一個服務(wù)，指標(biāo)管理是對數(shù)據(jù)指標(biāo)的定義和管理工作,。通過服務(wù)層應(yīng)用到不同的數(shù)據(jù)應(yīng)用,，數(shù)據(jù)應(yīng)用可能是我們的正式產(chǎn)品或者直接的業(yè)務(wù)系統(tǒng)。后面會從數(shù)據(jù)的分層設(shè)計和具體的實現(xiàn)兩個方面介紹,。

上面是對數(shù)據(jù)的整體設(shè)計,，主要參考了離線數(shù)倉的設(shè)計方案，也參考了業(yè)界同行的一些做法,。將數(shù)據(jù)分為四個層次：

首先是ODS層,，即操作數(shù)據(jù)層，通過數(shù)據(jù)采集工具收集各個業(yè)務(wù)源數(shù)據(jù),；DWD層,，明細(xì)數(shù)據(jù)層是按主題域來劃分，通過維度建模方式來組織各個業(yè)務(wù)過程的明細(xì)數(shù)據(jù),。中間會有一個DIM層,，維度數(shù)據(jù)層主要做一些查詢和關(guān)聯(lián)的操作,。最上層是DM層，通過DWD層數(shù)據(jù)做一些指標(biāo)加工,，主要面向一些分析和應(yīng)用匯總的指標(biāo)或者是做多維分析的明細(xì)數(shù)據(jù)。

舉例說明一下數(shù)據(jù)設(shè)計流向過程,，假如要對嚴(yán)選主類目上當(dāng)天銷售和流量的統(tǒng)計,，統(tǒng)計每個類目的銷售量和流量從ODS層來源兩部分，一部分來自訪問,，這是來源于埋點數(shù)據(jù),，這種數(shù)據(jù)通常比較規(guī)范，通過一些簡單加工,，在DWD層形成一張商品訪問明細(xì)表,；交易數(shù)據(jù)來自交易明細(xì)表，在ODS層來源于訂單表和訂單購物車表,。將兩個表匯聚在DWD層形成一個交易域的交易明細(xì)表,，因為統(tǒng)計需要統(tǒng)計到類目維度，所以從DWD層向DM加工需要從商品維度表做一個關(guān)聯(lián),，這樣就可以在DM層做一些匯總統(tǒng)計,，就可以形成DM所需要的指標(biāo)數(shù)據(jù)。這里的數(shù)據(jù)分為兩類,，一種是實時的,，一種是準(zhǔn)實時；如果維度比較復(fù)雜,，如準(zhǔn)實時彈幕做一些配置來做到同步,，如果有一些關(guān)聯(lián)關(guān)系比較簡單的就做成實時維表。這樣的好處是能實時統(tǒng)計,，能比較直觀觀察,。

實時數(shù)倉設(shè)計分為5個主題域，分別是商品,、流量,、交易、營銷,、倉配,。在這五個主題域下沉淀了25個模型，整個實時數(shù)倉在線任務(wù)數(shù)達(dá)到135,?；谶@樣的設(shè)計方案能整體實現(xiàn)設(shè)計目標(biāo)。

首先通過主體域的模型復(fù)用能夠提高開發(fā)效率,，最常用的就是交易域的實時數(shù)據(jù),。交易域的交易明細(xì)模型能夠產(chǎn)生多個集市層模型,，交易明細(xì)的字段清洗比較規(guī)范，一般兩天就能開發(fā)一個模型,，如果模型簡單一天就能搞定,。第二個就是比較靈活，在DWD層封裝一些業(yè)務(wù)邏輯,，快速應(yīng)對一些業(yè)務(wù)調(diào)整,。舉例說明下，嚴(yán)選上線一個眾籌業(yè)務(wù),，先前對交易定義都是以支付來算,，但是眾籌交易和支付相隔時間較長，對于離線只需要活動結(jié)束再進(jìn)行統(tǒng)計,，但是實時只關(guān)注于當(dāng)天數(shù)據(jù),，這個時候統(tǒng)計就沒有意義。因此需要將眾籌數(shù)據(jù)剔除,，實現(xiàn)時只需要在交易明細(xì)里面進(jìn)行過濾,，這樣集市層所有指標(biāo)數(shù)據(jù)都統(tǒng)一更改掉。第三個就是統(tǒng)一,，數(shù)據(jù)都是按照業(yè)務(wù)域劃分,，管理和維護(hù)都比較方便，對于開發(fā)資源分配也比較便利,。

然后介紹下技術(shù)實現(xiàn)方面的考量,，主要分為計算和存儲。對于計算方面,，有很多實時計算引擎,，有Flink、Storm,、Spark Streaming,，F(xiàn)link相對于Storm的優(yōu)勢就是支持SQL，相對于Spark Streaming又有一個相對好的性能表現(xiàn),。同時Flink在支持好的應(yīng)用和性能方面還有比較好的語義支持和比較好的容錯機制,，因此構(gòu)建實時數(shù)倉Flink是一個比較好的實時計算引擎選擇。

對于存儲層會依據(jù)不同的數(shù)據(jù)層的特點選擇不同的存儲介質(zhì),，ODS層和DWD層都是存儲的一些實時數(shù)據(jù),，選擇的是Kafka進(jìn)行存儲，在DWD層會關(guān)聯(lián)一些歷史明細(xì)數(shù)據(jù),，會將其放到Redis里面,。在DIM層主要做一些高并發(fā)維度的查詢關(guān)聯(lián)，一般將其存放在HBase里面,，對于DIM層比價復(fù)雜,，需要綜合考慮對于數(shù)據(jù)落地的要求以及具體的查詢引擎來選擇不同的存儲方式,。對于常見的指標(biāo)匯總模型直接放在MySQL里面，維度比較多的,、寫入更新比較大的模型會放在HBase里面,，還有明細(xì)數(shù)據(jù)需要做一些多維分析或者關(guān)聯(lián)會將其存儲在Greenplum里面，還有一種是維度比較多,、需要做排序,、查詢要求比較高的，如活動期間用戶的銷售列表等大列表直接存儲在Redis里面,。

性能優(yōu)化方面,，在計算中采用很多維度關(guān)聯(lián),，如果每一次維度關(guān)聯(lián)都從HBase中調(diào)用性能受限,，因此將維度數(shù)據(jù)在本地task進(jìn)行一次緩存。聚合去重用一些精度去重算法,，如Hyperloglog,，既能保證在一個可接受的數(shù)據(jù)統(tǒng)計誤差，又能比較好的優(yōu)化存儲,。存儲方面主要針對MySQL和Greenplum兩種場景,，在大數(shù)據(jù)場景下MySQL寫入壓力比較高，在寫入之前做一個窗口預(yù)聚合,，實現(xiàn)延遲和負(fù)載均衡,，較少MySQL的寫入壓力。對于明細(xì)數(shù)據(jù)寫入Greenplum,，明細(xì)數(shù)據(jù)不適合高并發(fā)寫入,，因此會對要寫入的表依據(jù)主鍵做哈希，定位要錄入的segment,，直接到Slave節(jié)點,，批量寫入數(shù)據(jù)，這樣也能有效提高寫入的存儲量,。

3,、數(shù)據(jù)質(zhì)量

數(shù)據(jù)質(zhì)量分為兩個方面來介紹，數(shù)據(jù)一致性和數(shù)據(jù)監(jiān)控,。

數(shù)據(jù)一致性主要針對實時與離線的數(shù)據(jù)一致性,，同一個指標(biāo)實時與離線都會產(chǎn)出。這兩者一致性分為四個方面：

第一,，建模方法與分層基本統(tǒng)一,，建模基于維度建模,，分層也是業(yè)內(nèi)通用方法,；

第二,，業(yè)務(wù)上主題域和模型設(shè)計同步；

第三,，數(shù)據(jù)接入與源數(shù)據(jù)統(tǒng)一,；

最后，數(shù)據(jù)產(chǎn)出方面,，指標(biāo)定義和接口都是統(tǒng)一輸出,。

DWD層做到主題域與模型同步，按照業(yè)務(wù)過程來設(shè)計模型,，這種方法對于實時和離線都是統(tǒng)一的,。以交易域為例，在實時和離線都有訂單,、訂單明細(xì),、組合裝的交易明細(xì)，還有加購數(shù)據(jù)模型,，由于開發(fā)成本原因?qū)崟r模型大都是離線模型的子集,。在DM層會統(tǒng)一定義指標(biāo)和模型定義的方法，規(guī)范對于實時和離線都是適用的,，定義模型會指定相應(yīng)的指標(biāo)和維度,，指標(biāo)通常是派生指標(biāo)，通過原子指標(biāo)+時間維度+修飾詞完成派生指標(biāo)的定義,，再經(jīng)過定義維度形成模型,。

有了模型定義規(guī)范具體落地，如果要定義當(dāng)日主站PC端銷售,，首先定義原子指標(biāo)流水,，時間維度今天，端是PC,，然后定義派生指標(biāo),，有了派生指標(biāo)接著定義模型，定義為每天商品銷售實時情況,，做一個實時與離線的標(biāo)記,，選擇其存儲，維度選擇一個是時間維度,、一個是商品維度,，然后加入先前的派生指標(biāo)，最后生成模型,。不同模型知識實時和離線標(biāo)記,，調(diào)用都是基于同一套接口來調(diào)用。

數(shù)據(jù)監(jiān)控涉及兩個方面，一個是數(shù)據(jù)平臺監(jiān)控,。主要是對任務(wù)失敗情況監(jiān)控,、異常日志監(jiān)控、任務(wù)失敗是RPS異常監(jiān)控,。還有任務(wù)本身運行正常,，但是數(shù)據(jù)已經(jīng)處理不過來，由于Flink機制,，數(shù)據(jù)擠壓到消費管理,，通過對Kafka數(shù)據(jù)延遲監(jiān)控能夠及時發(fā)現(xiàn)問題。將問題通過監(jiān)控發(fā)現(xiàn),，利用值班流程規(guī)范將問題及時發(fā)現(xiàn)和處理,，及時通報和定期進(jìn)行修復(fù)，來提高整個數(shù)據(jù)質(zhì)量,。

為了配合數(shù)據(jù)監(jiān)控,，正在做實時數(shù)據(jù)血緣。主要是梳理實時數(shù)倉中數(shù)據(jù)依賴關(guān)系,，以及實時任務(wù)的依賴關(guān)系,，從底層ODS到DIM再到DM,，以及DM層被哪些模型用到,，將整個鏈度串聯(lián)起來。這樣的好處是：

（1）數(shù)據(jù)/任務(wù)主動調(diào)整可以周知關(guān)聯(lián)的下游,；

（2）任務(wù)異常及時判斷影響范圍,，通知產(chǎn)品和業(yè)務(wù)方；

（3）指標(biāo)異常時借助血緣定位問題,。

4,、應(yīng)用場景

實時數(shù)倉應(yīng)用場景分為三類：數(shù)據(jù)產(chǎn)品、線上運營活動,、業(yè)務(wù)后臺,。在線模型數(shù)有84個，歷史總模型數(shù)為110+,，大部分?jǐn)?shù)據(jù)延遲都在10s以內(nèi),，對于數(shù)據(jù)大屏這種對延遲要求比較高數(shù)據(jù)延遲在毫秒級。

數(shù)據(jù)大屏是最常用的實時數(shù)據(jù)應(yīng)用場景,，有針對客服業(yè)務(wù)大屏,，如大麥-商品數(shù)據(jù)運營平臺、神相-流量分析平臺,、刑天-推廣渠道管理系統(tǒng),。第二個是線上運營活動，如熱銷商品榜單、活動用戶消費排行,、資源位排序轉(zhuǎn)化策略,，業(yè)務(wù)后臺倉配產(chǎn)能監(jiān)控、物流時效監(jiān)控,、庫存預(yù)警,、商品變更通知。

5,、展望

未來展望從三個方面：

第一,，性能方面。模型用MySQL效率不高,，后期遷移到ES上,；維度表落地到Redis上進(jìn)一步提高吞吐量。

第二,，開發(fā)效率,。開發(fā)是SQL和API兩種并存，開發(fā)效率不高,，后期往SQL遷移,，由于SQL本身局限，進(jìn)行UDF擴(kuò)展,。

第三,，數(shù)據(jù)質(zhì)量。目前主要是側(cè)面輔助決策,，希望對舒適數(shù)據(jù)準(zhǔn)確性校驗實現(xiàn)比較通用的規(guī)范,，開發(fā)一些工具完成這些工作。

PPT獲取方式