九色国产,午夜在线视频,新黄色网址,九九色综合,天天做夜夜做久久做狠狠,天天躁夜夜躁狠狠躁2021a,久久不卡一区二区三区

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

• 在 2016 年，美團點評就已經(jīng)基于 Storm 實時計算引擎實現(xiàn)了初步的平臺化。

• 2017 年初，我們引入了 Spark Streaming 用于特定場景的支持，主要是在數(shù)據(jù)同步場景方面的嘗試。

• 在 2017 年底，美團點評實時計算平臺引入了 Flink。相比于 Storm 和 Spark Streaming，F(xiàn)link 在很多方面都具有優(yōu)勢。這個階段我們進行了深度的平臺化，主要關(guān)注點是安全、穩(wěn)定和易用。

• 從 19 年開始，我們致力于建設(shè)包括實時數(shù)倉、機器學(xué)習(xí)等特定場景的解決方案來為業(yè)務(wù)提供更好的支持。

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

如下圖所示的是美團點評實時計算平臺的架構(gòu)：

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

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

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

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

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

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

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

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

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

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

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

實時計算

1）流量

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

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

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

下圖中右邊是流量數(shù)倉的架構(gòu)圖：

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

2）廣告實時效果

這里再舉一個基于流量數(shù)倉的例子-廣告實時效果驗證。下圖中左側(cè)是廣告實時效果的對比圖：

廣告的打點一般分為請求（PV）打點、SPV（Server PV）打點、CPV（Client PV）曝光打點和 CPV 點擊打點，在所有打點中都會包含一個流量的 requestID 和命中的實驗路徑。

根據(jù) requestID 和命中的實驗路徑可以將所有的日志進行 join，得到一個 request 中需要的所有數(shù)據(jù)，然后將數(shù)據(jù)存入 Durid 中進行分析，支持實際 CTR、預(yù)估 CTR 等效果驗證。

3）即時配送

這里列舉的另外一個業(yè)務(wù)數(shù)倉實踐的例子是即時配送：

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

4）總結(jié)

業(yè)務(wù)實時數(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)注時序和趨勢，業(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)整頻率較低。

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

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

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

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

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

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

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

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

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

下圖中對于實時數(shù)倉的兩種建設(shè)方式，即準(zhǔn)實時數(shù)倉和實時數(shù)倉兩種方式進行了對比：

它們的實現(xiàn)方式分別是基于 OLAP 引擎和流計算引擎，實時度則分別是分鐘和秒級。

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

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

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

• 在擴展性方面，因為準(zhǔn)實時數(shù)倉的計算和存儲是一體的，因此相比于實時數(shù)倉，擴展性更弱一些。

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

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

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

這里的一站式解決方案主要為用戶提供了數(shù)據(jù)開發(fā)工作平臺、元數(shù)據(jù)管理。同時我們考慮到業(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ù)倉方面關(guān)注的比較核心的問題。

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

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

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

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

1）建設(shè)思路

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

2）實時數(shù)倉平臺架構(gòu)

如下圖所示的是美團點評的實時數(shù)倉平臺架構(gòu)：

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

3）消息表達-數(shù)據(jù)接入

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

如下圖左側(cè)是接入過程的一個例子：

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

4）計算表達-擴展 DDL

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

5）計算表達-UDF 平臺

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

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

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

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

UDF 的應(yīng)用其實非常廣泛，UDF 平臺并不是只支持實時數(shù)倉，也會同時支持離線數(shù)倉、機器學(xué)習(xí)以及查詢服務(wù)等應(yīng)用場景。下圖中右側(cè)展示的是 UDF 的使用案例，左圖是 UDF 的開發(fā)流程：

用戶只需要關(guān)心注冊流程，接下來的編譯打包、測試以及上傳等都由平臺完成；右圖是 UDF 的使用流程中，用戶只需要聲明 UDF，平臺會進行解析校驗、路徑獲取以及在作業(yè)提交的時候進行集成。

6）實時數(shù)倉平臺-Web IDE

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

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

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

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

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

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

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

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