簡介： 數據倉庫的建設是“數據智能”必不可少的一環，也是大規模數據應用中必然面臨的挑戰，而 Flink 實時數倉在數據鏈路中扮演著極為重要的角色。本文中，美團點評高級技術專家魯昊為大家分享了美團點評基於 Apache Flink 的實時數倉平臺實踐。
作者：魯昊@美團點評
一、美團點評實時計算演進
美團點評實時計算演進歷程
在 2016 年，美團點評就已經基於 Storm 實時計算引擎實現了初步的平臺化。2017 年初，我們引入了 Spark Streaming 用於特定場景的支持，主要是在數據同步場景方面的嘗試。在 2017 年底，美團點評實時計算平臺引入了 Flink。相比於 Storm 和 Spark Streaming，Flink 在很多方面都具有優勢。這個階段我們進行了深度的平臺化，主要關注點是安全、穩定和易用。從 19 年開始，我們致力於建設包括實時數倉、機器學習等特定場景的解決方案來為業務提供更好的支持。
實時計算平臺
目前，美團點評的實時計算平臺日活躍作業數量為萬級，高峰時作業處理的消息量達到每秒 1.5 億條，而機器規模也已經達到了幾千臺，並且有幾千位用戶正在使用實時計算服務。
實時計算平臺架構
如下圖所示的是美團點評實時計算平臺的架構。
- 最底層是收集層，這一層負責收集用戶的實時數據，包括 Binlog、後端服務日誌以及 IoT 數據，經過日誌收集團隊和 DB 收集團隊的處理，數據將會被收集到 Kafka 中。這些數據不只是參與實時計算，也會參與離線計算。
- 收集層之上是存儲層，這一層除了使用 Kafka 做消息通道之外，還會基於 HDFS 做狀態數據存儲以及基於 HBase 做維度數據的存儲。
- 存儲層之上是引擎層，包括 Storm 和 Flink。實時計算平臺會在引擎層為用戶提供一些框架的封裝以及公共包和組件的支持。
- 在引擎層之上就是平臺層了，平臺層從數據、任務和資源三個視角去管理。
- 架構的最上層是應用層 ，包括了實時數倉、機器學習、數據同步以及事件驅動應用等。
本次分享主要介紹實時數倉方面的建設情況。
從功能角度來看，美團點評的實時計算平臺主要包括作業和資源管理兩個方面的功能。其中，作業部分包括作業配置、作業發佈以及作業狀態三個方面的功能。
- 在作業配置方面，則包括作業設置、運行時設置以及拓撲結構設置；
- 在作業發佈方面，則包括版本管理、編譯/發佈/回滾等；
- 作業狀態則包括運行時狀態、自定義指標和報警以及命令/運行時日誌等。
在資源管理方面，則為用戶提供了多租戶資源隔離以及資源交付和部署的能力。
業務數倉實踐
流量
前面提到，現在的美團點評實時計算平臺更多地會關注在安全、易用和穩定方面，而應用上很大的一個場景就是業務數倉。接下來會為大家分享幾個業務數倉的例子。
第一個例子是流量，流量數倉是流量類業務的基礎服務，從業務通道而言，會有不同通道的埋點和不同頁面的埋點數據，通過日誌收集通道會進行基礎明細層的拆分，按照業務維度劃分不同的業務通道，如美團通道、外賣通道等。
基於業務通道還會進行一次更加細粒度的拆分，比如曝光日誌、猜你喜歡、推薦等。以上這些包括兩種使用方式，一種是以流的方式提供下游其他業務方使用，另外一方面就是做一些流量方面的實時分析。
下圖中右邊是流量數倉的架構圖，自下向上分為四層，分別是 SDK 層，包括了前端、小程序以及 APP 的埋點；其上是收集層，埋點日誌落地到 Nginx，通過日誌收集通道收到 Kafka 中。在計算層，流量團隊基於 Storm 能力實現了上層的 SQL 封裝，並實現了 SQL 動態更新的特性，在 SQL 變更時不必重啟作業。
廣告實時效果
這裡再舉一個基於流量數倉的例子-廣告實時效果驗證。下圖中左側是廣告實時效果的對比圖。廣告的打點一般分為請求（PV）打點、SPV（Server PV）打點、CPV（Client PV）曝光打點和 CPV 點擊打點，在所有打點中都會包含一個流量的 requestID 和命中的實驗路徑。根據 requestID 和命中的實驗路徑可以將所有的日誌進行 join，得到一個 request 中需要的所有數據，然後將數據存入 Durid 中進行分析，支持實際 CTR、預估 CTR 等效果驗證。
即時配送
這裡列舉的另外一個業務數倉實踐的例子是即時配送。實時數據在即時配送的運營策略上發揮了重要作用。以送達時間預估為例，交付時間衡量的是騎手送餐的交付難度，整個履約時間分為了多個時間段，配送數倉會基於 Storm 做特徵數據的清洗、提取，供算法團隊進行訓練並得到時間預估的結果。這個過程涉及到商家、騎手以及用戶的多方參與，數據的特徵會非常多，數據量也會非常大。
總結
業務實時數倉大致分為三類場景：流量類、業務類和特徵類，這三種場景各有不同。
- 在數據模型上，流量類是扁平化的寬表，業務數倉更多是基於範式的建模，特徵數據是 KV 存儲。
- 從數據來源區分，流量數倉的數據來源一般是日誌數據；業務數倉的數據來源是業務 binlog 數據；特徵數倉的數據來源則多種多樣。
- 從數據量而言，流量和特徵數倉都是海量數據，每天百億級以上，而業務數倉的數據量一般每天百萬到千萬級。
- 從數據更新頻率而言，流量數據極少更新，則業務和特徵數據更新較多。流量數據一般關注時序和趨勢，業務數據和特徵數據關注狀態變更。
- 在數據準確性上，流量數據要求較低，而業務數據和特徵數據要求較高。
- 在模型調整頻率上，業務數據調整頻率較高，流量數據和特徵數據調整頻率較低。
二、基於 Flink 的實時數倉平臺
上面為大家介紹了實時數倉的業務場景，接下來為大家介紹實時數倉的演進過程和美團點評的實時數倉平臺建設思路。
點擊“瞭解更多”解讀基於 Flink 的實時數倉平臺實踐內容
關鍵詞：存儲、SQL、消息中間件、機器學習/深度學習、分佈式計算、OLAP
