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

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

做者：魯昊@美團點評

點擊查看本場直播>>>

更多2019 Flink Forward 大會視頻>>>

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

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

在 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 數據；特徵數倉的數據來源則多種多樣。
• 從數據量而言，流量和特徵數倉都是海量數據，天天百億級以上，而業務數倉的數據量通常天天百萬到千萬級。
• 從數據更新頻率而言，流量數據極少更新，則業務和特徵數據更新較多。流量數據通常關注時序和趨勢，業務數據和特徵數據關注狀態變動。
• 在數據準確性上，流量數據要求較低，而業務數據和特徵數據要求較高。
• 在模型調整頻率上，業務數據調整頻率較高，流量數據和特徵數據調整頻率較低。

2、基於 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 作一些版本的管理，而且支持用戶回退到已部署成功的版本上去。

3、將來發展與思考

資源自動調優

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

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

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

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

實時數倉的建設通常分爲幾個步驟：

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

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