今天分享的內容主要分為四個部分，首先會介紹下嚴選實時數倉的背景、產生的一些問題。然後是針對這些背景和問題對實時數倉的整體設計和具體的實施方案，接著會介紹下在實時數倉的數據質量方面的工作，最後講一下實時數倉在嚴選中的應用場景。
1、背景
嚴選實時數倉項目是從17年下半年開始做的，背景總結為三個方面：
第一個是長鏈路且快速變化的業務，嚴選作為一個ODM電商，整個業務鏈度從商品採購、生產、倉庫、到銷售這個階段可以在主站APP上購買或者分廠購買，然後通過商戶配送到達消費者。鏈度是非常長的，這也決定數據的數據域非常廣；嚴選作為一個成長的電商，會有很多新的業務出現。
第二個是越來越多的實時數據需求，目前需要更多的實時數據來做業務決策，需要依據銷售情況做一個資源位的調整；同時有些活動也需要實時數據來增強與用戶的互動。如果數據有實時和離線兩種方案，優先考慮實時的，如果實時實現不了再考慮離線的方式。
第三個就是越來越高的數據質量要求，因為數據會直接影響業務決策，影響線上運營活動效果，因此對數據質量的要求越來越高。
針對這樣的項目背景提出了三個設計目標，第一個是靈活可擴展，第二個是開發效率高，第三個是數據質量要求高。
2、整體設計和實現
基於這樣的設計目標，介紹一下整體的設計和實現方案：
實時數倉整體框架依據數據的流向分為不同的層次，接入層會依據各種數據接入工具收集各個業務系統的數據，如買點的業務數據或者業務後臺的併購放到消息隊列裡面。消息隊列的數據既是離線數倉的原始數據，也是實時計算的原始數據，這樣可以保證實時和離線的原始數據是統一的。有了源數據，在計算層經過FLink+實時計算引擎做一些加工處理，然後落地到存儲層中不同存儲介質當中。不同的存儲介質是依據不同的應用場景來選擇。框架中還有FLink和Kafka的交互，在數據上進行一個分層設計，計算引擎從Kafka中撈取數據做一些加工然後放回Kafka。在存儲層加工好的數據會通過服務層的兩個服務：統一查詢、指標管理，統一查詢是通過業務方調取數據接口的一個服務，指標管理是對數據指標的定義和管理工作。通過服務層應用到不同的數據應用，數據應用可能是我們的正式產品或者直接的業務系統。後面會從數據的分層設計和具體的實現兩個方面介紹。
上面是對數據的整體設計，主要參考了離線數倉的設計方案，也參考了業界同行的一些做法。將數據分為四個層次：
首先是ODS層，即操作數據層，通過數據採集工具收集各個業務源數據；DWD層，明細數據層是按主題域來劃分，通過維度建模方式來組織各個業務過程的明細數據。中間會有一個DIM層，維度數據層主要做一些查詢和關聯的操作。最上層是DM層，通過DWD層數據做一些指標加工，主要面向一些分析和應用匯總的指標或者是做多維分析的明細數據。
舉例說明一下數據設計流向過程，假如要對嚴選主類目上當天銷售和流量的統計，統計每個類目的銷售量和流量從ODS層來源兩部分，一部分來自訪問，這是來源於埋點數據，這種數據通常比較規範，通過一些簡單加工，在DWD層形成一張商品訪問明細表；交易數據來自交易明細表，在ODS層來源於訂單表和訂單購物車表。將兩個表匯聚在DWD層形成一個交易域的交易明細表，因為統計需要統計到類目維度，所以從DWD層向DM加工需要從商品維度表做一個關聯，這樣就可以在DM層做一些彙總統計，就可以形成DM所需要的指標數據。這裡的數據分為兩類，一種是實時的，一種是準實時；如果維度比較複雜，如準實時彈幕做一些配置來做到同步，如果有一些關聯關係比較簡單的就做成實時維表。這樣的好處是能實時統計，能比較直觀觀察。
實時數倉設計分為5個主題域，分別是商品、流量、交易、營銷、倉配。在這五個主題域下沉澱了25個模型，整個實時數倉在線任務數達到135。基於這樣的設計方案能整體實現設計目標。
首先通過主體域的模型複用能夠提高開發效率，最常用的就是交易域的實時數據。交易域的交易明細模型能夠產生多個集市層模型，交易明細的字段清洗比較規範，一般兩天就能開發一個模型，如果模型簡單一天就能搞定。第二個就是比較靈活，在DWD層封裝一些業務邏輯，快速應對一些業務調整。舉例說明下，嚴選上線一個眾籌業務，先前對交易定義都是以支付來算，但是眾籌交易和支付相隔時間較長，對於離線只需要活動結束再進行統計，但是實時只關注於當天數據，這個時候統計就沒有意義。因此需要將眾籌數據剔除，實現時只需要在交易明細裡面進行過濾，這樣集市層所有指標數據都統一更改掉。第三個就是統一，數據都是按照業務域劃分，管理和維護都比較方便，對於開發資源分配也比較便利。
然後介紹下技術實現方面的考量，主要分為計算和存儲。對於計算方面，有很多實時計算引擎，有Flink、Storm、Spark Streaming，Flink相對於Storm的優勢就是支持SQL，相對於Spark Streaming又有一個相對好的性能表現。同時Flink在支持好的應用和性能方面還有比較好的語義支持和比較好的容錯機制，因此構建實時數倉Flink是一個比較好的實時計算引擎選擇。
對於存儲層會依據不同的數據層的特點選擇不同的存儲介質，ODS層和DWD層都是存儲的一些實時數據，選擇的是Kafka進行存儲，在DWD層會關聯一些歷史明細數據，會將其放到Redis裡面。在DIM層主要做一些高併發維度的查詢關聯，一般將其存放在HBase裡面，對於DIM層比價複雜，需要綜合考慮對於數據落地的要求以及具體的查詢引擎來選擇不同的存儲方式。對於常見的指標彙總模型直接放在MySQL裡面，維度比較多的、寫入更新比較大的模型會放在HBase裡面，還有明細數據需要做一些多維分析或者關聯會將其存儲在Greenplum裡面，還有一種是維度比較多、需要做排序、查詢要求比較高的，如活動期間用戶的銷售列表等大列表直接存儲在Redis裡面。
性能優化方面，在計算中採用很多維度關聯，如果每一次維度關聯都從HBase中調用性能受限，因此將維度數據在本地task進行一次緩存。聚合去重用一些精度去重算法，如Hyperloglog，既能保證在一個可接受的數據統計誤差，又能比較好的優化存儲。存儲方面主要針對MySQL和Greenplum兩種場景，在大數據場景下MySQL寫入壓力比較高，在寫入之前做一個窗口預聚合，實現延遲和負載均衡，較少MySQL的寫入壓力。對於明細數據寫入Greenplum，明細數據不適合高併發寫入，因此會對要寫入的表依據主鍵做哈希，定位要錄入的segment，直接到Slave節點，批量寫入數據，這樣也能有效提高寫入的存儲量。
3、數據質量
數據質量分為兩個方面來介紹，數據一致性和數據監控。
數據一致性主要針對實時與離線的數據一致性，同一個指標實時與離線都會產出。這兩者一致性分為四個方面：
第一，建模方法與分層基本統一，建模基於維度建模，分層也是業內通用方法；
第二，業務上主題域和模型設計同步；
第三，數據接入與源數據統一；
最後，數據產出方面，指標定義和接口都是統一輸出。
DWD層做到主題域與模型同步，按照業務過程來設計模型，這種方法對於實時和離線都是統一的。以交易域為例，在實時和離線都有訂單、訂單明細、組合裝的交易明細，還有加購數據模型，由於開發成本原因實時模型大都是離線模型的子集。在DM層會統一定義指標和模型定義的方法，規範對於實時和離線都是適用的，定義模型會指定相應的指標和維度，指標通常是派生指標，通過原子指標+時間維度+修飾詞完成派生指標的定義，再經過定義維度形成模型。
有了模型定義規範具體落地，如果要定義當日主站PC端銷售，首先定義原子指標流水，時間維度今天，端是PC，然後定義派生指標，有了派生指標接著定義模型，定義為每天商品銷售實時情況，做一個實時與離線的標記，選擇其存儲，維度選擇一個是時間維度、一個是商品維度，然後加入先前的派生指標，最後生成模型。不同模型知識實時和離線標記，調用都是基於同一套接口來調用。
數據監控涉及兩個方面，一個是數據平臺監控。主要是對任務失敗情況監控、異常日誌監控、任務失敗是RPS異常監控。還有任務本身運行正常，但是數據已經處理不過來，由於Flink機制，數據擠壓到消費管理，通過對Kafka數據延遲監控能夠及時發現問題。將問題通過監控發現，利用值班流程規範將問題及時發現和處理，及時通報和定期進行修復，來提高整個數據質量。
為了配合數據監控，正在做實時數據血緣。主要是梳理實時數倉中數據依賴關係，以及實時任務的依賴關係，從底層ODS到DIM再到DM，以及DM層被哪些模型用到，將整個鏈度串聯起來。這樣的好處是：
（1）數據/任務主動調整可以周知關聯的下游；
（2）任務異常及時判斷影響範圍，通知產品和業務方；
（3）指標異常時藉助血緣定位問題。
4、應用場景
實時數倉應用場景分為三類：數據產品、線上運營活動、業務後臺。在線模型數有84個，歷史總模型數為110+，大部分數據延遲都在10s以內，對於數據大屏這種對延遲要求比較高數據延遲在毫秒級。
數據大屏是最常用的實時數據應用場景，有針對客服業務大屏，如大麥-商品數據運營平臺、神相-流量分析平臺、刑天-推廣渠道管理系統。第二個是線上運營活動，如熱銷商品榜單、活動用戶消費排行、資源位排序轉化策略，業務後臺倉配產能監控、物流時效監控、庫存預警、商品變更通知。
5、展望
未來展望從三個方面：
第一，性能方面。模型用MySQL效率不高，後期遷移到ES上；維度表落地到Redis上進一步提高吞吐量。
第二，開發效率。開發是SQL和API兩種並存，開發效率不高，後期往SQL遷移，由於SQL本身侷限，進行UDF擴展。
第三，數據質量。目前主要是側面輔助決策，希望對舒適數據準確性校驗實現比較通用的規範，開發一些工具完成這些工作。
閱讀更多 智能推薦系統 的文章
