美團外賣實時數(shù)倉建設實踐

本文主要介紹一種通用的實時數(shù)倉構建的方法與實踐。實時數(shù)倉以端到端低延遲、SQL標準化、快速響應變化、數(shù)據(jù)統(tǒng)一為目標。美團外賣數(shù)據(jù)智能組總結的最佳實踐是：一個通用的實時生產(chǎn)平臺跟一個通用交互式實時分析引擎相互配合，同時滿足實時和準實時業(yè)務場景。兩者合理分工，互相補充，形成易開發(fā)、易維護且效率高的流水線，兼顧開發(fā)效率與生產(chǎn)成本，以較好的投入產(chǎn)出比滿足業(yè)務的多樣性需求。

• 01 實時場景

• 02 實時技術及架構

• 1. 實時計算技術選型

• 2. 實時架構

• 03 業(yè)務痛點

• 04 數(shù)據(jù)特點與應用場景

• 05 實時數(shù)倉架構設計

• 1. 實時架構：流批結合的探索

• 2. 實時數(shù)倉架構設計

• 06 實時平臺化建設

• 1. 實時基礎層功能

• 2. 實時特征生產(chǎn)功能

• 3. SLA建設

• 4. 實時OLAP方案

• 07 實時應用案例

01 實時場景

實時數(shù)據(jù)在美團外賣的場景是非常多的，主要有以下幾個方面：

• 運營層面：比如實時業(yè)務變化，實時營銷效果，當日營業(yè)情況以及當日分時業(yè)務趨勢分析等。
• 生產(chǎn)層面：比如實時系統(tǒng)是否可靠，系統(tǒng)是否穩(wěn)定，實時監(jiān)控系統(tǒng)的健康狀況等。
• C端用戶：比如搜索推薦排序，需要實時行為、特點等特征變量的生產(chǎn)，給用戶推薦更加合理的內容。
• 風控側：實時風險識別、反欺詐、異常交易等，都是大量應用實時數(shù)據(jù)的場景。

02 實時技術及架構

1. 實時計算技術選型

目前，市面上已經(jīng)開源的實時技術還是很多的，比較通用的有Storm、Spark Streaming以及Flink，技術同學在做選型時要根據(jù)公司的具體業(yè)務來進行部署。

美團外賣依托于美團整體的基礎數(shù)據(jù)體系建設，從技術成熟度來講，公司前幾年主要用的是Storm。當時的Storm，在性能穩(wěn)定性、可靠性以及擴展性上也是無可替代的。但隨著Flink越來越成熟，從技術性能上以及框架設計優(yōu)勢上已經(jīng)超越了Storm，從趨勢來講就像Spark替代MR一樣，Storm也會慢慢被Flink替代。當然，從Storm遷移到Flink會有一個過程，我們目前有一些老的任務仍然運行在Storm上，也在不斷推進任務遷移。

具體Storm和Flink的對比可以參考上圖表格。

2. 實時架構

① Lambda架構

Lambda是比較經(jīng)典的一款架構，以前實時的場景不是很多，以離線為主，當附加了實時場景后，由于離線和實時的時效性不同，導致技術生態(tài)是不一樣的。而Lambda架構相當于附加了一條實時生產(chǎn)鏈路，在應用層面進行一個整合，雙路生產(chǎn)，各自獨立。在業(yè)務應用中，順理成章成為了一種被采用的方式。

雙路生產(chǎn)會存在一些問題，比如加工邏輯Double，開發(fā)運維也會Double，資源同樣會變成兩個資源鏈路。因為存在以上問題，所以又演進了一個Kappa架構。

② Kappa架構

Kappa從架構設計來講，比較簡單，生產(chǎn)統(tǒng)一，一套邏輯同時生產(chǎn)離線和實時。但是在實際應用場景有比較大的局限性，在業(yè)內直接用Kappa架構生產(chǎn)落地的案例不多見，且場景比較單一。這些問題在美團外賣這邊同樣會遇到，我們也會有自己的一些思考，將會在后面的章節(jié)進行闡述。

03 業(yè)務痛點

首先，在外賣業(yè)務上，我們遇到了一些問題和挑戰(zhàn)。在業(yè)務早期，為了滿足業(yè)務需要，一般是Case By Case地先把需求完成。業(yè)務對于實時性要求是比較高的，從時效性的維度來說，沒有進行中間層沉淀的機會。在這種場景下，一般是拿到業(yè)務邏輯直接嵌入，這是能想到的簡單有效的方法，在業(yè)務發(fā)展初期這種開發(fā)模式也比較常見。

如上圖所示，拿到數(shù)據(jù)源后，我們會經(jīng)過數(shù)據(jù)清洗、擴維，通過Storm或Flink進行業(yè)務邏輯處理，最后直接進行業(yè)務輸出。把這個環(huán)節(jié)拆開來看，數(shù)據(jù)源端會重復引用相同的數(shù)據(jù)源，后面進行清洗、過濾、擴維等操作，都要重復做一遍。唯一不同的是業(yè)務的代碼邏輯是不一樣的，如果業(yè)務較少，這種模式還可以接受，但當后續(xù)業(yè)務量上去后，會出現(xiàn)誰開發(fā)誰運維的情況，維護工作量會越來越大，作業(yè)無法形成統(tǒng)一管理。而且所有人都在申請資源，導致資源成本急速膨脹，資源不能集約有效利用，因此要思考如何從整體來進行實時數(shù)據(jù)的建設。

04 數(shù)據(jù)特點與應用場景

那么如何來構建實時數(shù)倉呢？首先要進行拆解，有哪些數(shù)據(jù)，有哪些場景，這些場景有哪些共同特點，對于外賣場景來說一共有兩大類，日志類和業(yè)務類。

• 日志類：數(shù)據(jù)量特別大，半結構化，嵌套比較深。日志類的數(shù)據(jù)有個很大的特點，日志流一旦形成是不會變的，通過埋點的方式收集平臺所有的日志，統(tǒng)一進行采集分發(fā)，就像一顆樹，樹根非常大，推到前端應用的時候，相當于從樹根到樹枝分叉的過程（從1到n的分解過程）。如果所有的業(yè)務都從根上找數(shù)據(jù)，看起來路徑最短，但包袱太重，數(shù)據(jù)檢索效率低。日志類數(shù)據(jù)一般用于生產(chǎn)監(jiān)控和用戶行為分析，時效性要求比較高，時間窗口一般是5min或10min，或截止到當前的一個狀態(tài)，主要的應用是實時大屏和實時特征，例如用戶每一次點擊行為都能夠立刻感知到等需求。
• 業(yè)務類：主要是業(yè)務交易數(shù)據(jù)，業(yè)務系統(tǒng)一般是自成體系的，以Binlog日志的形式往下分發(fā)，業(yè)務系統(tǒng)都是事務型的，主要采用范式建模方式。特點是結構化，主體非常清晰，但數(shù)據(jù)表較多，需要多表關聯(lián)才能表達完整業(yè)務，因此是一個n到1的集成加工過程。

而業(yè)務類實時處理，主要面臨的以下幾個難點：

• 業(yè)務的多狀態(tài)性：業(yè)務過程從開始到結束是不斷變化的，比如從下單->支付->配送，業(yè)務庫是在原始基礎上進行變更的，Binlog會產(chǎn)生很多變化的日志。而業(yè)務分析更加關注最終狀態(tài)，由此產(chǎn)生數(shù)據(jù)回撤計算的問題，例如10點下單，13點取消，但希望在10點減掉取消單。
• 業(yè)務集成：業(yè)務分析數(shù)據(jù)一般無法通過單一主體表達，往往是很多表進行關聯(lián)，才能得到想要的信息，在實時流中進行數(shù)據(jù)的合流對齊，往往需要較大的緩存處理且復雜。
• 分析是批量的，處理過程是流式的：對單一數(shù)據(jù)，無法形成分析，因此分析對象一定是批量的，而數(shù)據(jù)加工是逐條的。

日志類和業(yè)務類的場景一般是同時存在的，交織在一起，無論是Lambda架構還是Kappa架構，單一的應用都會有一些問題。因此針對場景來選擇架構與實踐才更有意義。

05 實時數(shù)倉架構設計

1. 實時架構：流批結合的探索

基于以上問題，我們有自己的思考。通過流批結合的方式來應對不同的業(yè)務場景。

如上圖所示，數(shù)據(jù)從日志統(tǒng)一采集到消息隊列，再到數(shù)據(jù)流的ETL過程，作為基礎數(shù)據(jù)流的建設是統(tǒng)一的。之后對于日志類實時特征，實時大屏類應用走實時流計算。對于Binlog類業(yè)務分析走實時OLAP批處理。

流式處理分析業(yè)務的痛點是什么？對于范式業(yè)務，Storm和Flink都需要很大的外存，來實現(xiàn)數(shù)據(jù)流之間的業(yè)務對齊，需要大量的計算資源。且由于外存的限制，必須進行窗口的限定策略，最終可能放棄一些數(shù)據(jù)。計算之后，一般是存到Redis里做查詢支撐，且KV存儲在應對分析類查詢場景中也有較多局限。

實時OLAP怎么實現(xiàn)？有沒有一種自帶存儲的實時計算引擎，當實時數(shù)據(jù)來了之后，可以靈活的在一定范圍內自由計算，并且有一定的數(shù)據(jù)承載能力，同時支持分析查詢響應呢？隨著技術的發(fā)展，目前MPP引擎發(fā)展非常迅速，性能也在飛快提升，所以在這種場景下就有了一種新的可能。這里我們使用的是Doris引擎。

這種想法在業(yè)內也已經(jīng)有實踐，且成為一個重要探索方向。阿里基于ADB的實時OLAP方案等。

2. 實時數(shù)倉架構設計

從整個實時數(shù)倉架構來看，首先考慮的是如何管理所有的實時數(shù)據(jù)，資源如何有效整合，數(shù)據(jù)如何進行建設。

從方法論來講，實時和離線是非常相似的。離線數(shù)倉早期的時候也是Case By Case，當數(shù)據(jù)規(guī)模漲到一定量的時候才會考慮如何治理。分層是一種非常有效的數(shù)據(jù)治理方式，所以在實時數(shù)倉如何進行管理的問題上，首先考慮的也是分層的處理邏輯，具體內容如下：

• 數(shù)據(jù)源：在數(shù)據(jù)源的層面，離線和實時在數(shù)據(jù)源是一致的，主要分為日志類和業(yè)務類，日志類又包括用戶日志、DB日志以及服務器日志等。
• 實時明細層：在明細層，為了解決重復建設的問題，要進行統(tǒng)一構建，利用離線數(shù)倉的模式，建設統(tǒng)一的基礎明細數(shù)據(jù)層，按照主題進行管理，明細層的目的是給下游提供直接可用的數(shù)據(jù)，因此要對基礎層進行統(tǒng)一的加工，比如清洗、過濾、擴維等。

• 匯總層：匯總層通過Flink或Storm的簡潔算子直接可以算出結果，并且形成匯總指標池，所有的指標都統(tǒng)一在匯總層加工，所有人按照統(tǒng)一的規(guī)范管理建設，形成可復用的匯總結果。

總結起來，從整個實時數(shù)倉的建設角度來講，首先數(shù)據(jù)建設的層次化要先建出來，先搭框架，然后定規(guī)范，每一層加工到什么程度，每一層用什么樣的方式，當規(guī)范定義出來后，便于在生產(chǎn)上進行標準化的加工。由于要保證時效性，設計的時候，層次不能太多，對于實時性要求比較高的場景，基本可以走上圖左側的數(shù)據(jù)流，對于批量處理的需求，可以從實時明細層導入到實時OLAP引擎里，基于OLAP引擎自身的計算和查詢能力進行快速的回撤計算，如上圖右側的數(shù)據(jù)流。

06 實時平臺化建設

架構確定之后，我們后面考慮的是如何進行平臺化的建設，實時平臺化建設是完全附加于實時數(shù)倉管理之上進行的。

首先進行功能的抽象，把功能抽象成組件，這樣就可以達到標準化的生產(chǎn)，系統(tǒng)化的保障就可以更深入的建設，對于基礎加工層的清洗、過濾、合流、擴維、轉換、加密、篩選等功能都可以抽象出來，基礎層通過這種組件化的方式構建直接可用的數(shù)據(jù)結果流。這會產(chǎn)生一個問題，用戶的需求多樣，為了滿足了這個用戶，如何兼容其他的用戶，因此可能會出現(xiàn)冗余加工的情況。從存儲的維度來講，實時數(shù)據(jù)不存歷史，不會消耗過多的存儲，這種冗余是可以接受的，通過冗余的方式可以提高生產(chǎn)效率，是一種以空間換時間思想的應用。

通過基礎層的加工，數(shù)據(jù)全部沉淀到IDL層，同時寫到OLAP引擎的基礎層，再往上是實時匯總層計算，基于Storm、Flink或Doris，生產(chǎn)多維度的匯總指標，形成統(tǒng)一的匯總層，進行統(tǒng)一的存儲分發(fā)。

當這些功能都有了以后，元數(shù)據(jù)管理，指標管理，數(shù)據(jù)安全性、SLA、數(shù)據(jù)質量等系統(tǒng)能力也會逐漸構建起來。

1. 實時基礎層功能

實時基礎層的建設要解決一些問題。首先是一條流重復讀的問題，一條Binlog打過來，是以DB包的形式存在的，用戶可能只用其中一張表，如果大家都要用，可能存在所有人都要接這個流的問題。解決方案是可以按照不同的業(yè)務解構出來，還原到基礎數(shù)據(jù)流層，根據(jù)業(yè)務的需要做成范式結構，按照數(shù)倉的建模方式進行集成化的主題建設。

其次要進行組件的封裝，比如基礎層的清洗、過濾、擴維等功能，通過一個很簡單的表達入口，讓用戶將邏輯寫出來。數(shù)據(jù)轉換環(huán)節(jié)是比較靈活的，比如從一個值轉換成另外一個值，對于這種自定義邏輯表達，我們也開放了自定義組件，可以通過Java或Python開發(fā)自定義腳本，進行數(shù)據(jù)加工。

2. 實時特征生產(chǎn)功能

特征生產(chǎn)可以通過SQL語法進行邏輯表達，底層進行邏輯的適配，透傳到計算引擎，屏蔽用戶對計算引擎的依賴。就像對于離線場景，目前大公司很少通過代碼的方式開發(fā)，除非一些特別的Case，所以基本上可以通過SQL化的方式表達。

在功能層面，把指標管理的思想融合進去，原子指標、派生指標，標準計算口徑，維度選擇，窗口設置等操作都可以通過配置化的方式，這樣可以統(tǒng)一解析生產(chǎn)邏輯，進行統(tǒng)一封裝。

還有一個問題，同一個源，寫了很多SQL，每一次提交都會起一個數(shù)據(jù)流，比較浪費資源，我們的解決方案是，通過同一條流實現(xiàn)動態(tài)指標的生產(chǎn)，在不停服務的情況下可以動態(tài)添加指標。

所以在實時平臺建設過程中，更多考慮的是如何更有效的利用資源，在哪些環(huán)節(jié)更能節(jié)約化的使用資源，這是在工程方面更多考慮的事情。

3. SLA建設

SLA主要解決兩個問題，一個是端到端的SLA，一個是作業(yè)生產(chǎn)效率的SLA，我們采用埋點+上報的方式，由于實時流比較大，埋點要盡量簡單，不能埋太多的東西，能表達業(yè)務即可，每個作業(yè)的輸出統(tǒng)一上報到SLA監(jiān)控平臺，通過統(tǒng)一接口的形式，在每一個作業(yè)點上報所需要的信息，最后能夠統(tǒng)計到端到端的SLA。

在實時生產(chǎn)中，由于鏈路非常長，無法控制所有鏈路，但是可以控制自己作業(yè)的效率，所以作業(yè)SLA也是必不可少的。

4. 實時OLAP方案

問題

• Binlog業(yè)務還原復雜：業(yè)務變化很多，需要某個時間點的變化，因此需要進行排序，并且數(shù)據(jù)要存起來，這對于內存和CPU的資源消耗都是非常大的。
• Binlog業(yè)務關聯(lián)復雜：流式計算里，流和流之間的關聯(lián)，對于業(yè)務邏輯的表達是非常困難的。

解決方案

通過帶計算能力的OLAP引擎來解決，不需要把一個流進行邏輯化映射，只需要解決數(shù)據(jù)實時穩(wěn)定的入庫問題。

我們這邊采用的是Doris作為高性能的OLAP引擎，由于業(yè)務數(shù)據(jù)產(chǎn)生的結果和結果之間還需要進行衍生計算，Doris可以利用Unique模型或聚合模型快速還原業(yè)務，還原業(yè)務的同時還可以進行匯總層的聚合，也是為了復用而設計。應用層可以是物理的，也可以是邏輯化視圖。

這種模式重在解決業(yè)務回撤計算，比如業(yè)務狀態(tài)改變，需要在歷史的某個點將值變更，這種場景用流計算的成本非常大，OLAP模式可以很好的解決這個問題。

07 實時應用案例

最后通過一個案例說明，比如商家要根據(jù)用戶歷史下單數(shù)給用戶優(yōu)惠，商家需要看到歷史下了多少單，歷史T+1的數(shù)據(jù)要有，今天實時的數(shù)據(jù)也要有，這種場景是典型的Lambda架構。我們可以在Doris里設計一個分區(qū)表，一個是歷史分區(qū)，一個是今日分區(qū)，歷史分區(qū)可以通過離線的方式生產(chǎn)，今日指標可以通過實時的方式計算，寫到今日分區(qū)里，查詢的時候進行一個簡單的匯總。

這種場景看起來比較簡單，難點在于商家的量上來之后，很多簡單的問題都會變得復雜。后續(xù)，我們也會通過更多的業(yè)務輸入，沉淀出更多的業(yè)務場景，抽象出來形成統(tǒng)一的生產(chǎn)方案和功能，以最小化的實時計算資源支撐多樣化的業(yè)務需求，這也是未來我們需要達到的目的。