美團點評基於 Flink 的實時數倉平臺實踐

摘要：數據倉庫的建設是“數據智能”必不可少的一環，也是大規模數據應用中必然面臨的挑戰，而 Flink 實時數倉在數據鏈路中扮演着極爲重要的角色。本文中，美團點評高級技術專家魯昊爲大家分享了美團點評基於 Apache Flink 的實時數倉平臺實踐。

主要內容爲以下三個方面：

1. 實時計算演進與業務實踐

2. 基於 Flink 的實時數倉平臺

3. 未來發展與思考

一、美團點評實時計算演進

美團點評實時計算演進歷程

在 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 的實時數倉平臺

上面爲大家介紹了實時數倉的業務場景，接下來爲大家介紹實時數倉的演進過程和美團點評的實時數倉平臺建設思路。

傳統數倉模型

爲了更有效地組織和管理數據，數倉建設往往會進行數據分層，一般自下而上分爲四層：ODS（操作數據層）、DWD（數據明細層）、DWS（彙總層）和應用層。即時查詢主要通過 Presto、Hive 和 Spark 實現。

實時數倉模型

實時數倉的分層方式一般也遵守傳統數據倉庫模型，也分爲了 ODS 操作數據集、DWD 明細層和 DWS 彙總層以及應用層。但實時數倉模型的處理的方式卻和傳統數倉有所差別，如明細層和彙總層的數據一般會放在 Kafka 上，維度數據一般考慮到性能問題則會放在 HBase 或者 Tair 等 KV 存儲上，即席查詢則可以使用 Flink 完成。

準實時數倉模型

在以上兩種數倉模型之外，我們發現業務方在實踐過程中還有一種準實時數倉模型，其特點是不完全基於流去做，而是將明細層數據導入到 OLAP 存儲中，基於 OLAP 的計算能力去做彙總並進行進一步的加工。

實時數倉和傳統數倉的對比

實時數倉和傳統數倉的對比主要可以從四個方面考慮：

• 第一個是分層方式，離線數倉爲了考慮到效率問題，一般會採取空間換時間的方式，層級劃分會比較多；則實時數倉考慮到實時性問題，一般分層會比較少，另外也減少了中間流程出錯的可能性。

• 第二個是事實數據存儲方面，離線數倉會基於 HDFS，實時數倉則會基於消息隊列（如 Kafka）。

• 第三個是維度數據存儲，實時數倉會將數據放在 KV 存儲上面。

• 第四個是數據加工過程，離線數倉一般以 Hive、Spark 等批處理爲主，而實時數倉則是基於實時計算引擎如 Storm、Flink 等，以流處理爲主。

實時數倉建設方案對比

下圖中對於實時數倉的兩種建設方式，即準實時數倉和實時數倉兩種方式進行了對比。它們的實現方式分別是基於 OLAP 引擎和流計算引擎，實時度則分別是分鐘和秒級。

• 在調度開銷方面，準實時數倉是批處理過程，因此仍然需要調度系統支持，雖然調度開銷比離線數倉少一些，但是依然存在，而實時數倉卻沒有調度開銷。

• 在業務靈活性方面，因爲準實時數倉基於 OLAP 引擎實現，靈活性優於基於流計算的方式。

• 在對數據晚到的容忍度方面，因爲準實時數倉可以基於一個週期內的數據進行全量計算，因此對於數據晚到的容忍度也是比較高的，而實時數倉使用的是增量計算，對於數據晚到的容忍度更低一些。

• 在擴展性方面，因爲準實時數倉的計算和存儲是一體的，因此相比於實時數倉，擴展性更弱一些。

• 在適用場景方面，準實時數倉主要用於有實時性要求但不太高、數據量不大以及多表關聯複雜和業務變更頻繁的場景，如交易類型的實時分析，實時數倉則更適用於實時性要求高、數據量大的場景，如實時特徵、流量分發以及流量類型實時分析。

總結一下，基於 OLAP 引擎的建設方式是數據量不太大，業務流量不太高情況下爲了提高時效性和開發效率的一個折中方案，從未來的發展趨勢來看，基於流計算的實時數倉更具有發展前景。

一站式解決方案

從業務實踐過程中，我們看到了業務建設實時數倉的共同需求，包括髮現不同業務的元數據是割裂的，業務開發也傾向於使用 SQL 方式同時開發離線數倉和實時數倉，需要更多的運維工具支持。因此我們規劃了一站式解決方案，希望能夠將整個流程貫通。

這裏的一站式解決方案主要爲用戶提供了數據開發工作平臺、元數據管理。同時我們考慮到業務從生產到應用過程中的問題，我們 OLAP 生產平臺，從建模方式、生產任務管理和資源方面解決 OLAP 生產問題。左側是我們已經具備數據安全體系、資源體系和數據治理，這些是離線數倉和實時數倉可以共用的。

爲何選擇 Flink？

實時數倉平臺建設之所以選擇 Flink 是基於以下四個方面的考慮，這也是實時數倉方面關注的比較核心的問題。

• 第一個是狀態管理，實時數倉裏面會進行很多的聚合計算，這些都需要對於狀態進行訪問和管理，Flink 在這方面比較成熟。

• 第二個是表義能力，Flink 提供極爲豐富的多層次 API，包括 Stream API、Table API 以及 Flink SQL。

• 第三個是生態完善，實時數倉的用途廣泛，用戶對於多種存儲有訪問需求，Flink 對於這方面的支持也比較完善。

• 最後一點就是 Flink 提供了流批統一的可能性。

實時數倉平臺

• 建設思路

實時數倉平臺的建設思路從外到內分爲了四個層次，我們認爲平臺應該做的事情是爲用戶提供抽象的表達能力，分別是消息表達、數據表達、計算表達以及流和批統一。

• 實時數倉平臺架構

如下圖所示的是美團點評的實時數倉平臺架構，從下往上看，資源層和存儲層複用了實時計算平臺的能力，在引擎層則會基於 Flink Streaming 實現一些擴展能力，包括對 UDF 的集成和 Connector 的集成。再往上是基於 Flink SQL 獨立出來的 SQL 層，主要負責解析、校驗和優化。在這之上是平臺層，包括開發工作臺、元數據、UDF 平臺以及 OLAP 平臺。最上層則是平臺所支持的實時數倉的應用，包括實時報表、實時 OLAP、實時 Dashboard 和實時特徵等。

• 消息表達-數據接入

在消息表達層面，因爲 Binlog、埋點日誌、後端日誌以及 IoT 數據等的數據格式是不一致的，因此美團點評的實時數倉平臺提供數據接入的流程，能夠幫助大家把數據同步到 ODS 層。這裏主要實現了兩件事情，分別是統一消息協議和屏蔽處理細節。

如下圖左側是接入過程的一個例子，對於 Binlog 類型數據，實時數倉平臺還爲大家提供了分庫分表的支持，能夠將屬於同一個業務的不同的分庫分表數據根據業務規則收集到同一個 ODS 表中去。

• 計算表達-擴展 DDL

美團點評實時數倉平臺基於 Flink 擴展了 DDL，這部分工作的主要目的是建設元數據體系，打通內部的主流實時存儲，包括 KV 數據、OLAP 數據等。由於開發工作臺和元數據體系是打通的，因此很多數據的細節並不需要大家在 DDL 中明確地聲明出來，只需要在聲明中寫上數據的名字，和運行時的一些設置，比如 MQ 從最新消費還是最舊消費或者從某個時間戳消費即可，其他的數據訪問方式是一致的。

• 計算表達-UDF 平臺

對於 UDF 平臺而言，需要從三個層面考慮：

• 首先是數據安全性。之前的數倉建設過程中，用戶可以上傳 Jar 包去直接引用 UDF，這樣做是有危險性存在的，並且我們無法知道數據的流向。從數據安全的角度來考慮，平臺會進行代碼審計和血緣關係分析，對於歷史風險組件或者存在問題的組件可以進行組件收斂。

• 第二個層面，在數據安全基礎上我們還會關注 UDF 的運行質量，平臺將會爲用戶提供模板、用例以及測試的管理，爲用戶屏蔽編譯打包、Jar 包管理的過程，並且會在 UDF 模板中進行指標日誌的埋點和異常處理。

• 第三個層面是 UDF 的複用能力，因爲一個業務方開發的 UDF，其他業務方很可能也會使用，但是升級過程中可能會帶來不兼容的問題，因此，平臺爲業務提供了項目管理、函數管理和版本管理的能力。

UDF 的應用其實非常廣泛，UDF 平臺並不是只支持實時數倉，也會同時支持離線數倉、機器學習以及查詢服務等應用場景。下圖中右側展示的是 UDF 的使用案例，左圖是 UDF 的開發流程，用戶只需要關心註冊流程，接下來的編譯打包、測試以及上傳等都由平臺完成；右圖是 UDF 的使用流程中，用戶只需要聲明 UDF，平臺會進行解析校驗、路徑獲取以及在作業提交的時候進行集成。

• 實時數倉平臺-Web IDE

最後介紹一下實時數倉平臺的開發工作臺，以 Web IDE 的形式集成了模型、作業以及 UDF 的管理，用戶可以在 Web IDE 上以 SQL 方式開發。平臺會對 SQL 做一些版本的管理，並且支持用戶回退到已部署成功的版本上去。

三、未來發展與思考

資源自動調優

從整個實時計算角度來考慮，目前美團點評的實時計算平臺的節點數已經達到了幾千臺，未來很可能會達到上萬臺，因此資源優化這件事情很快就會被提上日程。由於業務本身的流量存在高峯和低谷，對於一個實時任務來說，可能在高峯時需要很多資源，但是在低谷時並不需要那麼多資源。

另外一方面，波峯本身也是會發生變化的，有可能隨着業務的上漲使得原來分配的資源數量不夠用。因此，資源自動調優有兩個含義，一個是指能夠適配作業的高峯流量上漲，自動適配 Max 值；另外一個含義是指使得作業能夠在高峯過去之後自動適應流量減少，能夠快速縮容。我們可以通過每個任務甚至是算子的歷史運行情況，擬合得到算子、流量與資源的關係函數，在流量變化時同步調整資源量。

以上是資源優化的思路，除此之外還需要考慮當資源完成優化之後應該如何利用。爲了保證可用性，實時和離線任務一般會分開部署，否則帶寬、IO 都可能被離線計算打滿導致實時任務延遲。而從資源使用率角度出發，則需要考慮實時和離線的混合部署，或者以流的方式來處理一些實時性要求並不是非常高的任務。這就要求更細粒度的資源隔離和更快的資源釋放。

推動實時數倉建設方式升級

實時數倉的建設一般分爲幾個步驟：

• 首先，業務提出需求，後續會進行設計建模、業務邏輯開發和底層技術實現。美團點評的實時數倉建設思路是將技術實現統一表達，讓業務關注邏輯開發，而邏輯開發也可以基於配置化手段實現自動構建。

• 再上一層是可以根據業務需求實現智能建模，將設計建模過程實現自動化。

目前，美團點評的實時數倉平臺建設工作還集中在統一表達的層次，距離理想狀態仍然有比較長的一段路要走。