摘要：數(shù)據(jù)倉庫的建設(shè)是“數(shù)據(jù)智能”必不可少的一環(huán)，也是大規(guī)模數(shù)據(jù)應(yīng)用中必然面臨的挑戰(zhàn)，而 Flink 實(shí)時(shí)數(shù)倉在數(shù)據(jù)鏈路中扮演著極為重要的角色。本文中，美團(tuán)點(diǎn)評高級技術(shù)專家魯昊為大家分享了美團(tuán)點(diǎn)評基于 Apache Flink 的實(shí)時(shí)數(shù)倉平臺實(shí)踐。

主要內(nèi)容為以下三個方面：

實(shí)時(shí)計(jì)算演進(jìn)與業(yè)務(wù)實(shí)踐

基于 Flink 的實(shí)時(shí)數(shù)倉平臺

未來發(fā)展與思考

重要：點(diǎn)擊文末「閱讀原文」可查看 Flink Forward Asia 大會視頻。?

一、美團(tuán)點(diǎn)評實(shí)時(shí)計(jì)算演進(jìn)

美團(tuán)點(diǎn)評實(shí)時(shí)計(jì)算演進(jìn)歷程

在 2016 年，美團(tuán)點(diǎn)評就已經(jīng)基于 Storm 實(shí)時(shí)計(jì)算引擎實(shí)現(xiàn)了初步的平臺化。2017 年初，我們引入了 Spark Streaming 用于特定場景的支持，主要是在數(shù)據(jù)同步場景方面的嘗試。在 2017 年底，美團(tuán)點(diǎn)評實(shí)時(shí)計(jì)算平臺引入了 Flink。相比于 Storm 和 Spark Streaming，Flink 在很多方面都具有優(yōu)勢。這個階段我們進(jìn)行了深度的平臺化，主要關(guān)注點(diǎn)是安全、穩(wěn)定和易用。從 19 年開始，我們致力于建設(shè)包括實(shí)時(shí)數(shù)倉、機(jī)器學(xué)習(xí)等特定場景的解決方案來為業(yè)務(wù)提供更好的支持。

實(shí)時(shí)計(jì)算平臺

目前，美團(tuán)點(diǎn)評的實(shí)時(shí)計(jì)算平臺日活躍作業(yè)數(shù)量為萬級，高峰時(shí)作業(yè)處理的消息量達(dá)到每秒 1.5 億條，而機(jī)器規(guī)模也已經(jīng)達(dá)到了幾千臺，并且有幾千位用戶正在使用實(shí)時(shí)計(jì)算服務(wù)。

實(shí)時(shí)計(jì)算平臺架構(gòu)

如下圖所示的是美團(tuán)點(diǎn)評實(shí)時(shí)計(jì)算平臺的架構(gòu)。

• 最底層是收集層，這一層負(fù)責(zé)收集用戶的實(shí)時(shí)數(shù)據(jù)，包括 Binlog、后端服務(wù)日志以及 IoT 數(shù)據(jù)，經(jīng)過日志收集團(tuán)隊(duì)和 DB 收集團(tuán)隊(duì)的處理，數(shù)據(jù)將會被收集到 Kafka 中。這些數(shù)據(jù)不只是參與實(shí)時(shí)計(jì)算，也會參與離線計(jì)算。

• 收集層之上是存儲層，這一層除了使用 Kafka 做消息通道之外，還會基于 HDFS 做狀態(tài)數(shù)據(jù)存儲以及基于 HBase 做維度數(shù)據(jù)的存儲。

• 存儲層之上是引擎層，包括 Storm 和 Flink。實(shí)時(shí)計(jì)算平臺會在引擎層為用戶提供一些框架的封裝以及公共包和組件的支持。

• 在引擎層之上就是平臺層了，平臺層從數(shù)據(jù)、任務(wù)和資源三個視角去管理。

• 架構(gòu)的最上層是應(yīng)用層，包括了實(shí)時(shí)數(shù)倉、機(jī)器學(xué)習(xí)、數(shù)據(jù)同步以及事件驅(qū)動應(yīng)用等。

本次分享主要介紹實(shí)時(shí)數(shù)倉方面的建設(shè)情況。

從功能角度來看，美團(tuán)點(diǎn)評的實(shí)時(shí)計(jì)算平臺主要包括作業(yè)和資源管理兩個方面的功能。其中，作業(yè)部分包括作業(yè)配置、作業(yè)發(fā)布以及作業(yè)狀態(tài)三個方面的功能。

• 在作業(yè)配置方面，則包括作業(yè)設(shè)置、運(yùn)行時(shí)設(shè)置以及拓?fù)浣Y(jié)構(gòu)設(shè)置；

• 在作業(yè)發(fā)布方面，則包括版本管理、編譯/發(fā)布/回滾等；

• 作業(yè)狀態(tài)則包括運(yùn)行時(shí)狀態(tài)、自定義指標(biāo)和報(bào)警以及命令/運(yùn)行時(shí)日志等。

在資源管理方面，則為用戶提供了多租戶資源隔離以及資源交付和部署的能力。

業(yè)務(wù)數(shù)倉實(shí)踐

• 流量

前面提到，現(xiàn)在的美團(tuán)點(diǎn)評實(shí)時(shí)計(jì)算平臺更多地會關(guān)注在安全、易用和穩(wěn)定方面，而應(yīng)用上很大的一個場景就是業(yè)務(wù)數(shù)倉。接下來會為大家分享幾個業(yè)務(wù)數(shù)倉的例子。

第一個例子是流量，流量數(shù)倉是流量類業(yè)務(wù)的基礎(chǔ)服務(wù)，從業(yè)務(wù)通道而言，會有不同通道的埋點(diǎn)和不同頁面的埋點(diǎn)數(shù)據(jù)，通過日志收集通道會進(jìn)行基礎(chǔ)明細(xì)層的拆分，按照業(yè)務(wù)維度劃分不同的業(yè)務(wù)通道，如美團(tuán)通道、外賣通道等。

基于業(yè)務(wù)通道還會進(jìn)行一次更加細(xì)粒度的拆分，比如曝光日志、猜你喜歡、推薦等。以上這些包括兩種使用方式，一種是以流的方式提供下游其他業(yè)務(wù)方使用，另外一方面就是做一些流量方面的實(shí)時(shí)分析。

下圖中右邊是流量數(shù)倉的架構(gòu)圖，自下向上分為四層，分別是 SDK 層，包括了前端、小程序以及 APP 的埋點(diǎn)；其上是收集層，埋點(diǎn)日志落地到 Nginx，通過日志收集通道收到 Kafka 中。在計(jì)算層，流量團(tuán)隊(duì)基于 Storm 能力實(shí)現(xiàn)了上層的 SQL 封裝，并實(shí)現(xiàn)了 SQL 動態(tài)更新的特性，在 SQL 變更時(shí)不必重啟作業(yè)。

• 廣告實(shí)時(shí)效果

這里再舉一個基于流量數(shù)倉的例子-廣告實(shí)時(shí)效果驗(yàn)證。下圖中左側(cè)是廣告實(shí)時(shí)效果的對比圖。廣告的打點(diǎn)一般分為請求（PV）打點(diǎn)、SPV（Server PV）打點(diǎn)、CPV（Client PV）曝光打點(diǎn)和 CPV 點(diǎn)擊打點(diǎn)，在所有打點(diǎn)中都會包含一個流量的 requestID 和命中的實(shí)驗(yàn)路徑。根據(jù) requestID 和命中的實(shí)驗(yàn)路徑可以將所有的日志進(jìn)行 join，得到一個 request 中需要的所有數(shù)據(jù)，然后將數(shù)據(jù)存入 Durid 中進(jìn)行分析，支持實(shí)際 CTR、預(yù)估 CTR 等效果驗(yàn)證。

• 即時(shí)配送

這里列舉的另外一個業(yè)務(wù)數(shù)倉實(shí)踐的例子是即時(shí)配送。實(shí)時(shí)數(shù)據(jù)在即時(shí)配送的運(yùn)營策略上發(fā)揮了重要作用。以送達(dá)時(shí)間預(yù)估為例，交付時(shí)間衡量的是騎手送餐的交付難度，整個履約時(shí)間分為了多個時(shí)間段，配送數(shù)倉會基于 Storm 做特征數(shù)據(jù)的清洗、提取，供算法團(tuán)隊(duì)進(jìn)行訓(xùn)練并得到時(shí)間預(yù)估的結(jié)果。這個過程涉及到商家、騎手以及用戶的多方參與，數(shù)據(jù)的特征會非常多，數(shù)據(jù)量也會非常大。

?

• 總結(jié)

業(yè)務(wù)實(shí)時(shí)數(shù)倉大致分為三類場景：流量類、業(yè)務(wù)類和特征類，這三種場景各有不同。

• 在數(shù)據(jù)模型上，流量類是扁平化的寬表，業(yè)務(wù)數(shù)倉更多是基于范式的建模，特征數(shù)據(jù)是 KV 存儲。

• 從數(shù)據(jù)來源區(qū)分，流量數(shù)倉的數(shù)據(jù)來源一般是日志數(shù)據(jù)；業(yè)務(wù)數(shù)倉的數(shù)據(jù)來源是業(yè)務(wù) binlog 數(shù)據(jù)；特征數(shù)倉的數(shù)據(jù)來源則多種多樣。

• 從數(shù)據(jù)量而言，流量和特征數(shù)倉都是海量數(shù)據(jù)，每天百億級以上，而業(yè)務(wù)數(shù)倉的數(shù)據(jù)量一般每天百萬到千萬級。

• 從數(shù)據(jù)更新頻率而言，流量數(shù)據(jù)極少更新，則業(yè)務(wù)和特征數(shù)據(jù)更新較多。流量數(shù)據(jù)一般關(guān)注時(shí)序和趨勢，業(yè)務(wù)數(shù)據(jù)和特征數(shù)據(jù)關(guān)注狀態(tài)變更。

• 在數(shù)據(jù)準(zhǔn)確性上，流量數(shù)據(jù)要求較低，而業(yè)務(wù)數(shù)據(jù)和特征數(shù)據(jù)要求較高。

• 在模型調(diào)整頻率上，業(yè)務(wù)數(shù)據(jù)調(diào)整頻率較高，流量數(shù)據(jù)和特征數(shù)據(jù)調(diào)整頻率較低。

二、基于 Flink 的實(shí)時(shí)數(shù)倉平臺

上面為大家介紹了實(shí)時(shí)數(shù)倉的業(yè)務(wù)場景，接下來為大家介紹實(shí)時(shí)數(shù)倉的演進(jìn)過程和美團(tuán)點(diǎn)評的實(shí)時(shí)數(shù)倉平臺建設(shè)思路。

傳統(tǒng)數(shù)倉模型

為了更有效地組織和管理數(shù)據(jù)，數(shù)倉建設(shè)往往會進(jìn)行數(shù)據(jù)分層，一般自下而上分為四層：ODS（操作數(shù)據(jù)層）、DWD（數(shù)據(jù)明細(xì)層）、DWS（匯總層）和應(yīng)用層。即時(shí)查詢主要通過 Presto、Hive 和 Spark 實(shí)現(xiàn)。

實(shí)時(shí)數(shù)倉模型

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

準(zhǔn)實(shí)時(shí)數(shù)倉模型

在以上兩種數(shù)倉模型之外，我們發(fā)現(xiàn)業(yè)務(wù)方在實(shí)踐過程中還有一種準(zhǔn)實(shí)時(shí)數(shù)倉模型，其特點(diǎn)是不完全基于流去做，而是將明細(xì)層數(shù)據(jù)導(dǎo)入到 OLAP 存儲中，基于 OLAP 的計(jì)算能力去做匯總并進(jìn)行進(jìn)一步的加工。

?

實(shí)時(shí)數(shù)倉和傳統(tǒng)數(shù)倉的對比

實(shí)時(shí)數(shù)倉和傳統(tǒng)數(shù)倉的對比主要可以從四個方面考慮：

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

• 第二個是事實(shí)數(shù)據(jù)存儲方面，離線數(shù)倉會基于 HDFS，實(shí)時(shí)數(shù)倉則會基于消息隊(duì)列（如 Kafka）。

• 第三個是維度數(shù)據(jù)存儲，實(shí)時(shí)數(shù)倉會將數(shù)據(jù)放在 KV 存儲上面。

• 第四個是數(shù)據(jù)加工過程，離線數(shù)倉一般以 Hive、Spark 等批處理為主，而實(shí)時(shí)數(shù)倉則是基于實(shí)時(shí)計(jì)算引擎如 Storm、Flink 等，以流處理為主。

實(shí)時(shí)數(shù)倉建設(shè)方案對比

下圖中對于實(shí)時(shí)數(shù)倉的兩種建設(shè)方式，即準(zhǔn)實(shí)時(shí)數(shù)倉和實(shí)時(shí)數(shù)倉兩種方式進(jìn)行了對比。它們的實(shí)現(xiàn)方式分別是基于 OLAP 引擎和流計(jì)算引擎，實(shí)時(shí)度則分別是分鐘和秒級。

• 在調(diào)度開銷方面，準(zhǔn)實(shí)時(shí)數(shù)倉是批處理過程，因此仍然需要調(diào)度系統(tǒng)支持，雖然調(diào)度開銷比離線數(shù)倉少一些，但是依然存在，而實(shí)時(shí)數(shù)倉卻沒有調(diào)度開銷。

• 在業(yè)務(wù)靈活性方面，因?yàn)闇?zhǔn)實(shí)時(shí)數(shù)倉基于 OLAP 引擎實(shí)現(xiàn)，靈活性優(yōu)于基于流計(jì)算的方式。

• 在對數(shù)據(jù)晚到的容忍度方面，因?yàn)闇?zhǔn)實(shí)時(shí)數(shù)倉可以基于一個周期內(nèi)的數(shù)據(jù)進(jìn)行全量計(jì)算，因此對于數(shù)據(jù)晚到的容忍度也是比較高的，而實(shí)時(shí)數(shù)倉使用的是增量計(jì)算，對于數(shù)據(jù)晚到的容忍度更低一些。

• 在擴(kuò)展性方面，因?yàn)闇?zhǔn)實(shí)時(shí)數(shù)倉的計(jì)算和存儲是一體的，因此相比于實(shí)時(shí)數(shù)倉，擴(kuò)展性更弱一些。

• 在適用場景方面，準(zhǔn)實(shí)時(shí)數(shù)倉主要用于有實(shí)時(shí)性要求但不太高、數(shù)據(jù)量不大以及多表關(guān)聯(lián)復(fù)雜和業(yè)務(wù)變更頻繁的場景，如交易類型的實(shí)時(shí)分析，實(shí)時(shí)數(shù)倉則更適用于實(shí)時(shí)性要求高、數(shù)據(jù)量大的場景，如實(shí)時(shí)特征、流量分發(fā)以及流量類型實(shí)時(shí)分析。

總結(jié)一下，基于 OLAP 引擎的建設(shè)方式是數(shù)據(jù)量不太大，業(yè)務(wù)流量不太高情況下為了提高時(shí)效性和開發(fā)效率的一個折中方案，從未來的發(fā)展趨勢來看，基于流計(jì)算的實(shí)時(shí)數(shù)倉更具有發(fā)展前景。

一站式解決方案

從業(yè)務(wù)實(shí)踐過程中，我們看到了業(yè)務(wù)建設(shè)實(shí)時(shí)數(shù)倉的共同需求，包括發(fā)現(xiàn)不同業(yè)務(wù)的元數(shù)據(jù)是割裂的，業(yè)務(wù)開發(fā)也傾向于使用 SQL 方式同時(shí)開發(fā)離線數(shù)倉和實(shí)時(shí)數(shù)倉，需要更多的運(yùn)維工具支持。因此我們規(guī)劃了一站式解決方案，希望能夠?qū)⒄麄€流程貫通。

這里的一站式解決方案主要為用戶提供了數(shù)據(jù)開發(fā)工作平臺、元數(shù)據(jù)管理。同時(shí)我們考慮到業(yè)務(wù)從生產(chǎn)到應(yīng)用過程中的問題，我們 OLAP 生產(chǎn)平臺，從建模方式、生產(chǎn)任務(wù)管理和資源方面解決 OLAP 生產(chǎn)問題。左側(cè)是我們已經(jīng)具備數(shù)據(jù)安全體系、資源體系和數(shù)據(jù)治理，這些是離線數(shù)倉和實(shí)時(shí)數(shù)倉可以共用的。

為何選擇 Flink？

實(shí)時(shí)數(shù)倉平臺建設(shè)之所以選擇 Flink 是基于以下四個方面的考慮，這也是實(shí)時(shí)數(shù)倉方面關(guān)注的比較核心的問題。

• 第一個是狀態(tài)管理，實(shí)時(shí)數(shù)倉里面會進(jìn)行很多的聚合計(jì)算，這些都需要對于狀態(tài)進(jìn)行訪問和管理，Flink 在這方面比較成熟。

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

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

• 最后一點(diǎn)就是?Flink 提供了流批統(tǒng)一的可能性。

實(shí)時(shí)數(shù)倉平臺

• 建設(shè)思路

實(shí)時(shí)數(shù)倉平臺的建設(shè)思路從外到內(nèi)分為了四個層次，我們認(rèn)為平臺應(yīng)該做的事情是為用戶提供抽象的表達(dá)能力，分別是消息表達(dá)、數(shù)據(jù)表達(dá)、計(jì)算表達(dá)以及流和批統(tǒng)一。

• 實(shí)時(shí)數(shù)倉平臺架構(gòu)

如下圖所示的是美團(tuán)點(diǎn)評的實(shí)時(shí)數(shù)倉平臺架構(gòu)，從下往上看，資源層和存儲層復(fù)用了實(shí)時(shí)計(jì)算平臺的能力，在引擎層則會基于 Flink Streaming 實(shí)現(xiàn)一些擴(kuò)展能力，包括對 UDF 的集成和 Connector 的集成。再往上是基于 Flink SQL 獨(dú)立出來的 SQL 層，主要負(fù)責(zé)解析、校驗(yàn)和優(yōu)化。在這之上是平臺層，包括開發(fā)工作臺、元數(shù)據(jù)、UDF 平臺以及 OLAP 平臺。最上層則是平臺所支持的實(shí)時(shí)數(shù)倉的應(yīng)用，包括實(shí)時(shí)報(bào)表、實(shí)時(shí) OLAP、實(shí)時(shí) Dashboard 和實(shí)時(shí)特征等。

• 消息表達(dá)-數(shù)據(jù)接入

在消息表達(dá)層面，因?yàn)?Binlog、埋點(diǎn)日志、后端日志以及 IoT 數(shù)據(jù)等的數(shù)據(jù)格式是不一致的，因此美團(tuán)點(diǎn)評的實(shí)時(shí)數(shù)倉平臺提供數(shù)據(jù)接入的流程，能夠幫助大家把數(shù)據(jù)同步到 ODS 層。這里主要實(shí)現(xiàn)了兩件事情，分別是統(tǒng)一消息協(xié)議和屏蔽處理細(xì)節(jié)。

如下圖左側(cè)是接入過程的一個例子，對于 Binlog 類型數(shù)據(jù)，實(shí)時(shí)數(shù)倉平臺還為大家提供了分庫分表的支持，能夠?qū)儆谕粋€業(yè)務(wù)的不同的分庫分表數(shù)據(jù)根據(jù)業(yè)務(wù)規(guī)則收集到同一個 ODS 表中去。

• 計(jì)算表達(dá)-擴(kuò)展 DDL

美團(tuán)點(diǎn)評實(shí)時(shí)數(shù)倉平臺基于 Flink 擴(kuò)展了 DDL，這部分工作的主要目的是建設(shè)元數(shù)據(jù)體系，打通內(nèi)部的主流實(shí)時(shí)存儲，包括 KV 數(shù)據(jù)、OLAP 數(shù)據(jù)等。由于開發(fā)工作臺和元數(shù)據(jù)體系是打通的，因此很多數(shù)據(jù)的細(xì)節(jié)并不需要大家在 DDL 中明確地聲明出來，只需要在聲明中寫上數(shù)據(jù)的名字，和運(yùn)行時(shí)的一些設(shè)置，比如 MQ 從最新消費(fèi)還是最舊消費(fèi)或者從某個時(shí)間戳消費(fèi)即可，其他的數(shù)據(jù)訪問方式是一致的。

?

• 計(jì)算表達(dá)-UDF 平臺

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

• 首先是數(shù)據(jù)安全性。之前的數(shù)倉建設(shè)過程中，用戶可以上傳 Jar 包去直接引用 UDF，這樣做是有危險(xiǎn)性存在的，并且我們無法知道數(shù)據(jù)的流向。從數(shù)據(jù)安全的角度來考慮，平臺會進(jìn)行代碼審計(jì)和血緣關(guān)系分析，對于歷史風(fēng)險(xiǎn)組件或者存在問題的組件可以進(jìn)行組件收斂。

• 第二個層面，在數(shù)據(jù)安全基礎(chǔ)上我們還會關(guān)注?UDF 的運(yùn)行質(zhì)量，平臺將會為用戶提供模板、用例以及測試的管理，為用戶屏蔽編譯打包、Jar 包管理的過程，并且會在 UDF 模板中進(jìn)行指標(biāo)日志的埋點(diǎn)和異常處理。

• 第三個層面是?UDF 的復(fù)用能力，因?yàn)橐粋€業(yè)務(wù)方開發(fā)的 UDF，其他業(yè)務(wù)方很可能也會使用，但是升級過程中可能會帶來不兼容的問題，因此，平臺為業(yè)務(wù)提供了項(xiàng)目管理、函數(shù)管理和版本管理的能力。

UDF 的應(yīng)用其實(shí)非常廣泛，UDF 平臺并不是只支持實(shí)時(shí)數(shù)倉，也會同時(shí)支持離線數(shù)倉、機(jī)器學(xué)習(xí)以及查詢服務(wù)等應(yīng)用場景。下圖中右側(cè)展示的是 UDF 的使用案例，左圖是 UDF 的開發(fā)流程，用戶只需要關(guān)心注冊流程，接下來的編譯打包、測試以及上傳等都由平臺完成；右圖是 UDF 的使用流程中，用戶只需要聲明 UDF，平臺會進(jìn)行解析校驗(yàn)、路徑獲取以及在作業(yè)提交的時(shí)候進(jìn)行集成。

• 實(shí)時(shí)數(shù)倉平臺-Web IDE

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

三、未來發(fā)展與思考

資源自動調(diào)優(yōu)

從整個實(shí)時(shí)計(jì)算角度來考慮，目前美團(tuán)點(diǎn)評的實(shí)時(shí)計(jì)算平臺的節(jié)點(diǎn)數(shù)已經(jīng)達(dá)到了幾千臺，未來很可能會達(dá)到上萬臺，因此資源優(yōu)化這件事情很快就會被提上日程。由于業(yè)務(wù)本身的流量存在高峰和低谷，對于一個實(shí)時(shí)任務(wù)來說，可能在高峰時(shí)需要很多資源，但是在低谷時(shí)并不需要那么多資源。

另外一方面，波峰本身也是會發(fā)生變化的，有可能隨著業(yè)務(wù)的上漲使得原來分配的資源數(shù)量不夠用。因此，資源自動調(diào)優(yōu)有兩個含義，一個是指能夠適配作業(yè)的高峰流量上漲，自動適配 Max 值；另外一個含義是指使得作業(yè)能夠在高峰過去之后自動適應(yīng)流量減少，能夠快速縮容。我們可以通過每個任務(wù)甚至是算子的歷史運(yùn)行情況，擬合得到算子、流量與資源的關(guān)系函數(shù)，在流量變化時(shí)同步調(diào)整資源量。

以上是資源優(yōu)化的思路，除此之外還需要考慮當(dāng)資源完成優(yōu)化之后應(yīng)該如何利用。為了保證可用性，實(shí)時(shí)和離線任務(wù)一般會分開部署，否則帶寬、IO 都可能被離線計(jì)算打滿導(dǎo)致實(shí)時(shí)任務(wù)延遲。而從資源使用率角度出發(fā)，則需要考慮實(shí)時(shí)和離線的混合部署，或者以流的方式來處理一些實(shí)時(shí)性要求并不是非常高的任務(wù)。這就要求更細(xì)粒度的資源隔離和更快的資源釋放。

推動實(shí)時(shí)數(shù)倉建設(shè)方式升級

實(shí)時(shí)數(shù)倉的建設(shè)一般分為幾個步驟：

• 首先，業(yè)務(wù)提出需求，后續(xù)會進(jìn)行設(shè)計(jì)建模、業(yè)務(wù)邏輯開發(fā)和底層技術(shù)實(shí)現(xiàn)。美團(tuán)點(diǎn)評的實(shí)時(shí)數(shù)倉建設(shè)思路是將技術(shù)實(shí)現(xiàn)統(tǒng)一表達(dá)，讓業(yè)務(wù)關(guān)注邏輯開發(fā)，而邏輯開發(fā)也可以基于配置化手段實(shí)現(xiàn)自動構(gòu)建。

• 再上一層是可以根據(jù)業(yè)務(wù)需求實(shí)現(xiàn)智能建模，將設(shè)計(jì)建模過程實(shí)現(xiàn)自動化。

目前，美團(tuán)點(diǎn)評的實(shí)時(shí)數(shù)倉平臺建設(shè)工作還集中在統(tǒng)一表達(dá)的層次，距離理想狀態(tài)仍然有比較長的一段路要走。

總結(jié)

以上是生活随笔為你收集整理的美团点评基于 Flink 的实时数仓平台实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。