作者：魯昊@美團點評
一、美團點評實時計算演進
美團點評實時計算演進曆程
在 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 都可能被離線計算打滿導緻實時任務延遲。而從資源使用率角度出發，則需要考慮實時和離線的混合部署，或者以流的方式來處理一些實時性要求并不是非常高的任務。這就要求更細粒度的資源隔離和更快的資源釋放。
推動實時數倉建設方式更新
實時數倉的建設一般分為幾個步驟：
- 首先，業務提出需求，後續會進行設計模組化、業務邏輯開發和底層技術實作。美團點評的實時數倉建設思路是将技術實作統一表達，讓業務關注邏輯開發，而邏輯開發也可以基于配置化手段實作自動建構。
- 再上一層是可以根據業務需求實作智能模組化，将設計模組化過程實作自動化。
目前，美團點評的實時數倉平台建設工作還集中在統一表達的層次，距離理想狀态仍然有比較長的一段路要走。