關(guān)鍵時刻，第一時間送達！
分享嘉賓：楊雄 網(wǎng)易嚴選 資深研發(fā)工程師
內(nèi)容來源：《基于Flink的嚴選實時數(shù)倉實踐》
出品社區(qū)：DataFun
今天分享的內(nèi)容主要分為四個部分，首先會介紹下嚴選實時數(shù)倉的背景、產(chǎn)生的一些問題。然后是針對這些背景和問題對實時數(shù)倉的整體設(shè)計和具體的實施方案，接著會介紹下在實時數(shù)倉的數(shù)據(jù)質(zhì)量方面的工作，最后講一下實時數(shù)倉在嚴選中的應用場景。
1、背景
嚴選實時數(shù)倉項目是從17年下半年開始做的，背景總結(jié)為三個方面：
第一個是長鏈路且快速變化的業(yè)務(wù)，嚴選作為一個ODM電商，整個業(yè)務(wù)鏈度從商品采購、生產(chǎn)、倉庫、到銷售這個階段可以在主站APP上購買或者分廠購買，然后通過商戶配送到達消費者。鏈度是非常長的，這也決定數(shù)據(jù)的數(shù)據(jù)域非常廣；嚴選作為一個成長的電商，會有很多新的業(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è)計目標，第一個是靈活可擴展，第二個是開發(fā)效率高，第三個是數(shù)據(jù)質(zhì)量要求高。
2、整體設(shè)計和實現(xiàn)
基于這樣的設(shè)計目標，介紹一下整體的設(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ì)當中。不同的存儲介質(zhì)是依據(jù)不同的應用場景來選擇?？蚣苤羞€有FLink和Kafka的交互，在數(shù)據(jù)上進行一個分層設(shè)計，計算引擎從Kafka中撈取數(shù)據(jù)做一些加工然后放回Kafka。在存儲層加工好的數(shù)據(jù)會通過服務(wù)層的兩個服務(wù)：統(tǒng)一查詢、指標管理，統(tǒng)一查詢是通過業(yè)務(wù)方調(diào)取數(shù)據(jù)接口的一個服務(wù)，指標管理是對數(shù)據(jù)指標的定義和管理工作。通過服務(wù)層應用到不同的數(shù)據(jù)應用，數(shù)據(jù)應用可能是我們的正式產(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層，明細數(shù)據(jù)層是按主題域來劃分，通過維度建模方式來組織各個業(yè)務(wù)過程的明細數(shù)據(jù)。中間會有一個DIM層，維度數(shù)據(jù)層主要做一些查詢和關(guān)聯(lián)的操作。最上層是DM層，通過DWD層數(shù)據(jù)做一些指標加工，主要面向一些分析和應用匯總的指標或者是做多維分析的明細數(shù)據(jù)。
舉例說明一下數(shù)據(jù)設(shè)計流向過程，假如要對嚴選主類目上當天銷售和流量的統(tǒng)計，統(tǒng)計每個類目的銷售量和流量從ODS層來源兩部分，一部分來自訪問，這是來源于埋點數(shù)據(jù)，這種數(shù)據(jù)通常比較規(guī)范，通過一些簡單加工，在DWD層形成一張商品訪問明細表；交易數(shù)據(jù)來自交易明細表，在ODS層來源于訂單表和訂單購物車表。將兩個表匯聚在DWD層形成一個交易域的交易明細表，因為統(tǒng)計需要統(tǒng)計到類目維度，所以從DWD層向DM加工需要從商品維度表做一個關(guān)聯(lián)，這樣就可以在DM層做一些匯總統(tǒng)計，就可以形成DM所需要的指標數(shù)據(jù)。這里的數(shù)據(jù)分為兩類，一種是實時的，一種是準實時；如果維度比較復雜，如準實時彈幕做一些配置來做到同步，如果有一些關(guān)聯(lián)關(guān)系比較簡單的就做成實時維表。這樣的好處是能實時統(tǒng)計，能比較直觀觀察。
實時數(shù)倉設(shè)計分為5個主題域，分別是商品、流量、交易、營銷、倉配。在這五個主題域下沉淀了25個模型，整個實時數(shù)倉在線任務(wù)數(shù)達到135。基于這樣的設(shè)計方案能整體實現(xiàn)設(shè)計目標。
首先通過主體域的模型復用能夠提高開發(fā)效率，最常用的就是交易域的實時數(shù)據(jù)。交易域的交易明細模型能夠產(chǎn)生多個集市層模型，交易明細的字段清洗比較規(guī)范，一般兩天就能開發(fā)一個模型，如果模型簡單一天就能搞定。第二個就是比較靈活，在DWD層封裝一些業(yè)務(wù)邏輯，快速應對一些業(yè)務(wù)調(diào)整。舉例說明下，嚴選上線一個眾籌業(yè)務(wù)，先前對交易定義都是以支付來算，但是眾籌交易和支付相隔時間較長，對于離線只需要活動結(jié)束再進行統(tǒng)計，但是實時只關(guān)注于當天數(shù)據(jù)，這個時候統(tǒng)計就沒有意義。因此需要將眾籌數(shù)據(jù)剔除，實現(xiàn)時只需要在交易明細里面進行過濾，這樣集市層所有指標數(shù)據(jù)都統(tǒng)一更改掉。第三個就是統(tǒng)一，數(shù)據(jù)都是按照業(yè)務(wù)域劃分，管理和維護都比較方便，對于開發(fā)資源分配也比較便利。
然后介紹下技術(shù)實現(xiàn)方面的考量，主要分為計算和存儲。對于計算方面，有很多實時計算引擎，有Flink、Storm、Spark Streaming，F(xiàn)link相對于Storm的優(yōu)勢就是支持SQL，相對于Spark Streaming又有一個相對好的性能表現(xiàn)。同時Flink在支持好的應用和性能方面還有比較好的語義支持和比較好的容錯機制，因此構(gòu)建實時數(shù)倉Flink是一個比較好的實時計算引擎選擇。
對于存儲層會依據(jù)不同的數(shù)據(jù)層的特點選擇不同的存儲介質(zhì)，ODS層和DWD層都是存儲的一些實時數(shù)據(jù)，選擇的是Kafka進行存儲，在DWD層會關(guān)聯(lián)一些歷史明細數(shù)據(jù)，會將其放到Redis里面。在DIM層主要做一些高并發(fā)維度的查詢關(guān)聯(lián)，一般將其存放在HBase里面，對于DIM層比價復雜，需要綜合考慮對于數(shù)據(jù)落地的要求以及具體的查詢引擎來選擇不同的存儲方式。對于常見的指標匯總模型直接放在MySQL里面，維度比較多的、寫入更新比較大的模型會放在HBase里面，還有明細數(shù)據(jù)需要做一些多維分析或者關(guān)聯(lián)會將其存儲在Greenplum里面，還有一種是維度比較多、需要做排序、查詢要求比較高的，如活動期間用戶的銷售列表等大列表直接存儲在Redis里面。
性能優(yōu)化方面，在計算中采用很多維度關(guān)聯(lián)，如果每一次維度關(guān)聯(lián)都從HBase中調(diào)用性能受限，因此將維度數(shù)據(jù)在本地task進行一次緩存。聚合去重用一些精度去重算法，如Hyperloglog，既能保證在一個可接受的數(shù)據(jù)統(tǒng)計誤差，又能比較好的優(yōu)化存儲。存儲方面主要針對MySQL和Greenplum兩種場景，在大數(shù)據(jù)場景下MySQL寫入壓力比較高，在寫入之前做一個窗口預聚合，實現(xiàn)延遲和負載均衡，較少MySQL的寫入壓力。對于明細數(shù)據(jù)寫入Greenplum，明細數(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ù)一致性，同一個指標實時與離線都會產(chǎn)出。這兩者一致性分為四個方面：
第一，建模方法與分層基本統(tǒng)一，建?；诰S度建模，分層也是業(yè)內(nèi)通用方法；
第二，業(yè)務(wù)上主題域和模型設(shè)計同步；
第三，數(shù)據(jù)接入與源數(shù)據(jù)統(tǒng)一；
最后，數(shù)據(jù)產(chǎn)出方面，指標定義和接口都是統(tǒng)一輸出。
DWD層做到主題域與模型同步，按照業(yè)務(wù)過程來設(shè)計模型，這種方法對于實時和離線都是統(tǒng)一的。以交易域為例，在實時和離線都有訂單、訂單明細、組合裝的交易明細，還有加購數(shù)據(jù)模型，由于開發(fā)成本原因?qū)崟r模型大都是離線模型的子集。在DM層會統(tǒng)一定義指標和模型定義的方法，規(guī)范對于實時和離線都是適用的，定義模型會指定相應的指標和維度，指標通常是派生指標，通過原子指標+時間維度+修飾詞完成派生指標的定義，再經(jīng)過定義維度形成模型。
有了模型定義規(guī)范具體落地，如果要定義當日主站PC端銷售，首先定義原子指標流水，時間維度今天，端是PC，然后定義派生指標，有了派生指標接著定義模型，定義為每天商品銷售實時情況，做一個實時與離線的標記，選擇其存儲，維度選擇一個是時間維度、一個是商品維度，然后加入先前的派生指標，最后生成模型。不同模型知識實時和離線標記，調(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)和處理，及時通報和定期進行修復，來提高整個數(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）指標異常時借助血緣定位問題。
4、應用場景
實時數(shù)倉應用場景分為三類：數(shù)據(jù)產(chǎn)品、線上運營活動、業(yè)務(wù)后臺。在線模型數(shù)有84個，歷史總模型數(shù)為110+，大部分數(shù)據(jù)延遲都在10s以內(nèi)，對于數(shù)據(jù)大屏這種對延遲要求比較高數(shù)據(jù)延遲在毫秒級。
數(shù)據(jù)大屏是最常用的實時數(shù)據(jù)應用場景，有針對客服業(yè)務(wù)大屏，如大麥-商品數(shù)據(jù)運營平臺、神相-流量分析平臺、刑天-推廣渠道管理系統(tǒng)。第二個是線上運營活動，如熱銷商品榜單、活動用戶消費排行、資源位排序轉(zhuǎn)化策略，業(yè)務(wù)后臺倉配產(chǎn)能監(jiān)控、物流時效監(jiān)控、庫存預警、商品變更通知。
5、展望
未來展望從三個方面：
第一，性能方面。模型用MySQL效率不高，后期遷移到ES上；維度表落地到Redis上進一步提高吞吐量。
第二，開發(fā)效率。開發(fā)是SQL和API兩種并存，開發(fā)效率不高，后期往SQL遷移，由于SQL本身局限，進行UDF擴展。
第三，數(shù)據(jù)質(zhì)量。目前主要是側(cè)面輔助決策，希望對舒適數(shù)據(jù)準確性校驗實現(xiàn)比較通用的規(guī)范，開發(fā)一些工具完成這些工作。
PPT獲取方式
