簡(jiǎn)介：?本文主要介紹一種通用的實(shí)時(shí)數(shù)倉(cāng)構(gòu)建的方法與實(shí)踐。實(shí)時(shí)數(shù)倉(cāng)以端到端低延遲、SQL 標(biāo)準(zhǔn)化、快速響應(yīng)變化、數(shù)據(jù)統(tǒng)一為目標(biāo)。

作者：朱良

本文主要介紹一種通用的實(shí)時(shí)數(shù)倉(cāng)構(gòu)建的方法與實(shí)踐。實(shí)時(shí)數(shù)倉(cāng)以端到端低延遲、SQL 標(biāo)準(zhǔn)化、快速響應(yīng)變化、數(shù)據(jù)統(tǒng)一為目標(biāo)。

在實(shí)踐中，我們總結(jié)的最佳實(shí)踐是：一個(gè)通用的實(shí)時(shí)生產(chǎn)平臺(tái) + 一個(gè)通用交互式實(shí)時(shí)分析引擎相互配合同時(shí)滿足實(shí)時(shí)和準(zhǔn)實(shí)時(shí)業(yè)務(wù)場(chǎng)景。兩者合理分工，互相補(bǔ)充，形成易于開發(fā)、易于維護(hù)、效率最高的流水線，兼顧開發(fā)效率與生產(chǎn)成本，以較好的投入產(chǎn)出比滿足業(yè)務(wù)多樣需求。

01 實(shí)時(shí)場(chǎng)景

實(shí)時(shí)數(shù)據(jù)在美團(tuán)外賣的場(chǎng)景是非常多的，主要有以下幾點(diǎn)：

• 運(yùn)營(yíng)層面：比如實(shí)時(shí)業(yè)務(wù)變化，實(shí)時(shí)營(yíng)銷效果，當(dāng)日營(yíng)業(yè)情況以及當(dāng)日實(shí)時(shí)業(yè)務(wù)趨勢(shì)分析等。
• 生產(chǎn)層面：比如實(shí)時(shí)系統(tǒng)是否可靠，系統(tǒng)是否穩(wěn)定，實(shí)時(shí)監(jiān)控系統(tǒng)的健康狀況等。
• C 端用戶：比如搜索推薦排序，需要實(shí)時(shí)了解用戶的想法，行為、特點(diǎn)，給用戶推薦更加關(guān)注的內(nèi)容。
• 風(fēng)控側(cè)：在外賣以及金融科技用的是非常多的，實(shí)時(shí)風(fēng)險(xiǎn)識(shí)別，反欺詐，異常交易等，都是大量應(yīng)用實(shí)時(shí)數(shù)據(jù)的場(chǎng)景

02 實(shí)時(shí)技術(shù)及架構(gòu)

1. 實(shí)時(shí)計(jì)算技術(shù)選型

目前開源的實(shí)時(shí)技術(shù)比較多，比較通用的是 Storm、Spark Streaming 以及 Flink，具體要根據(jù)不同公司的業(yè)務(wù)情況進(jìn)行選型。

美團(tuán)外賣是依托美團(tuán)整體的基礎(chǔ)數(shù)據(jù)體系建設(shè)，從技術(shù)成熟度來(lái)講，前幾年用的是 Storm，Storm 當(dāng)時(shí)在性能穩(wěn)定性、可靠性以及擴(kuò)展性上是無(wú)可替代的，隨著 Flink 越來(lái)越成熟，從技術(shù)性能上以及框架設(shè)計(jì)優(yōu)勢(shì)上已經(jīng)超越Storm，從趨勢(shì)來(lái)講就像 Spark 替代 MR 一樣，Storm 也會(huì)慢慢被 Flink 替代，當(dāng)然從 Storm 遷移到 Flink 會(huì)有一個(gè)過(guò)程，我們目前有一些老的任務(wù)仍然在 Storm 上，也在不斷推進(jìn)任務(wù)遷移。

具體 Storm 和 Flink 的對(duì)比可以參考上圖表格。

2. 實(shí)時(shí)架構(gòu)

① Lambda 架構(gòu)

Lambda 架構(gòu)是比較經(jīng)典的架構(gòu)，以前實(shí)時(shí)的場(chǎng)景不是很多，以離線為主，當(dāng)附加了實(shí)時(shí)場(chǎng)景后，由于離線和實(shí)時(shí)的時(shí)效性不同，導(dǎo)致技術(shù)生態(tài)是不一樣的。Lambda 架構(gòu)相當(dāng)于附加了一條實(shí)時(shí)生產(chǎn)鏈路，在應(yīng)用層面進(jìn)行一個(gè)整合，雙路生產(chǎn)，各自獨(dú)立。這在業(yè)務(wù)應(yīng)用中也是順理成章采用的一種方式。

雙路生產(chǎn)會(huì)存在一些問題，比如加工邏輯 double，開發(fā)運(yùn)維也會(huì) double，資源同樣會(huì)變成兩個(gè)資源鏈路。因?yàn)榇嬖谝陨蠁栴}，所以又演進(jìn)了一個(gè) Kappa 架構(gòu)。

② Kappa 架構(gòu)

Kappa 架構(gòu)從架構(gòu)設(shè)計(jì)來(lái)講比較簡(jiǎn)單，生產(chǎn)統(tǒng)一，一套邏輯同時(shí)生產(chǎn)離線和實(shí)時(shí)。但是在實(shí)際應(yīng)用場(chǎng)景有比較大的局限性，在業(yè)內(nèi)直接用 Kappa 架構(gòu)生產(chǎn)落地的案例不多見，且場(chǎng)景比較單一。這些問題在我們這邊同樣會(huì)遇到，我們也會(huì)有自己的一些思考，在后面會(huì)講到。

03 業(yè)務(wù)痛點(diǎn)

在外賣業(yè)務(wù)上，我們也遇到了一些問題。

業(yè)務(wù)早期，為了滿足業(yè)務(wù)需要，一般是拿到需求后 case by case 的先把需求完成，業(yè)務(wù)對(duì)于實(shí)時(shí)性要求是很高的，從時(shí)效性來(lái)說(shuō)，沒有進(jìn)行中間層沉淀的機(jī)會(huì)，在這種場(chǎng)景下，一般是拿到業(yè)務(wù)邏輯直接嵌入，這是能想到的簡(jiǎn)單有效的方法，在業(yè)務(wù)發(fā)展初期這種開發(fā)模式比較常見。

如上圖所示，拿到數(shù)據(jù)源后，會(huì)經(jīng)過(guò)數(shù)據(jù)清洗，擴(kuò)維，通過(guò) Storm 或 Flink 進(jìn)行業(yè)務(wù)邏輯處理，最后直接進(jìn)行業(yè)務(wù)輸出。把這個(gè)環(huán)節(jié)拆開來(lái)看，數(shù)據(jù)源端會(huì)重復(fù)引用相同的數(shù)據(jù)源，后面進(jìn)行清洗、過(guò)濾、擴(kuò)維等操作，都要重復(fù)做一遍，唯一不同的是業(yè)務(wù)的代碼邏輯是不一樣的，如果業(yè)務(wù)較少，這種模式還可以接受，但當(dāng)后續(xù)業(yè)務(wù)量上去后，會(huì)出現(xiàn)誰(shuí)開發(fā)誰(shuí)運(yùn)維的情況，維護(hù)工作量會(huì)越來(lái)越大，作業(yè)無(wú)法形成統(tǒng)一管理。而且所有人都在申請(qǐng)資源，導(dǎo)致資源成本急速膨脹，資源不能集約有效利用，因此要思考如何從整體來(lái)進(jìn)行實(shí)時(shí)數(shù)據(jù)的建設(shè)。

04 數(shù)據(jù)特點(diǎn)與應(yīng)用場(chǎng)景

那么如何來(lái)構(gòu)建實(shí)時(shí)數(shù)倉(cāng)呢？

首先要進(jìn)行拆解，有哪些數(shù)據(jù)，有哪些場(chǎng)景，這些場(chǎng)景有哪些共同特點(diǎn)，對(duì)于外賣場(chǎng)景來(lái)說(shuō)一共有兩大類，日志類和業(yè)務(wù)類。

• 日志類：數(shù)據(jù)量特別大，半結(jié)構(gòu)化，嵌套比較深。日志類的數(shù)據(jù)有個(gè)很大的特點(diǎn)，日志流一旦形成是不會(huì)變的，通過(guò)埋點(diǎn)的方式收集平臺(tái)所有的日志，統(tǒng)一進(jìn)行采集分發(fā)，就像一顆樹，樹根非常大，推到前端應(yīng)用的時(shí)候，相當(dāng)于從樹根到樹枝分叉的過(guò)程（從 1 到 n 的分解過(guò)程），如果所有的業(yè)務(wù)都從根上找數(shù)據(jù)，看起來(lái)路徑最短，但包袱太重，數(shù)據(jù)檢索效率低。日志類數(shù)據(jù)一般用于生產(chǎn)監(jiān)控和用戶行為分析，時(shí)效性要求比較高，時(shí)間窗口一般是 5min 或 10min 或截止到當(dāng)前的一個(gè)狀態(tài)，主要的應(yīng)用是實(shí)時(shí)大屏和實(shí)時(shí)特征，例如用戶每一次點(diǎn)擊行為都能夠立刻感知到等需求。
• 業(yè)務(wù)類：主要是業(yè)務(wù)交易數(shù)據(jù)，業(yè)務(wù)系統(tǒng)一般是自成體系的，以 Binlog 日志的形式往下分發(fā)，業(yè)務(wù)系統(tǒng)都是事務(wù)型的，主要采用范式建模方式，特點(diǎn)是結(jié)構(gòu)化的，主體非常清晰，但數(shù)據(jù)表較多，需要多表關(guān)聯(lián)才能表達(dá)完整業(yè)務(wù)，因此是一個(gè) n 到 1 的集成加工過(guò)程。

業(yè)務(wù)類實(shí)時(shí)處理面臨的幾個(gè)難點(diǎn)：

• 業(yè)務(wù)的多狀態(tài)性：業(yè)務(wù)過(guò)程從開始到結(jié)束是不斷變化的，比如從下單->支付->配送，業(yè)務(wù)庫(kù)是在原始基礎(chǔ)上進(jìn)行變更的，binlog 會(huì)產(chǎn)生很多變化的日志。而業(yè)務(wù)分析更加關(guān)注最終狀態(tài)，由此產(chǎn)生數(shù)據(jù)回撤計(jì)算的問題，例如 10 點(diǎn)下單，13 點(diǎn)取消，但希望在 10 點(diǎn)減掉取消單。
• 業(yè)務(wù)集成：業(yè)務(wù)分析數(shù)據(jù)一般無(wú)法通過(guò)單一主體表達(dá)，往往是很多表進(jìn)行關(guān)聯(lián)，才能得到想要的信息，在實(shí)時(shí)流中進(jìn)行數(shù)據(jù)的合流對(duì)齊，往往需要較大的緩存處理且復(fù)雜。
• 分析是批量的，處理過(guò)程是流式的：對(duì)單一數(shù)據(jù)，無(wú)法形成分析，因此分析對(duì)象一定是批量的，而數(shù)據(jù)加工是逐條的。

日志類和業(yè)務(wù)類的場(chǎng)景一般是同時(shí)存在的，交織在一起，無(wú)論是 Lambda 架構(gòu)還是 Kappa 架構(gòu)，單一的應(yīng)用都會(huì)有一些問題。因此針對(duì)場(chǎng)景來(lái)選擇架構(gòu)與實(shí)踐才更有意義。

05 實(shí)時(shí)數(shù)倉(cāng)架構(gòu)設(shè)計(jì)

1. 實(shí)時(shí)架構(gòu)：流批結(jié)合的探索

基于以上問題，我們有自己的思考。通過(guò)流批結(jié)合的方式來(lái)應(yīng)對(duì)不同的業(yè)務(wù)場(chǎng)景。

如上圖所示，數(shù)據(jù)從日志統(tǒng)一采集到消息隊(duì)列，再到數(shù)據(jù)流的 ETL 過(guò)程，作為基礎(chǔ)數(shù)據(jù)流的建設(shè)是統(tǒng)一的。之后對(duì)于日志類實(shí)時(shí)特征，實(shí)時(shí)大屏類應(yīng)用走實(shí)時(shí)流計(jì)算。對(duì)于 Binlog 類業(yè)務(wù)分析走實(shí)時(shí) OLAP 批處理。

流式處理分析業(yè)務(wù)的痛點(diǎn)？對(duì)于范式業(yè)務(wù)，Storm 和 Flink 都需要很大的外存，來(lái)實(shí)現(xiàn)數(shù)據(jù)流之間的業(yè)務(wù)對(duì)齊，需要大量的計(jì)算資源。且由于外存的限制，必須進(jìn)行窗口的限定策略，最終可能放棄一些數(shù)據(jù)。計(jì)算之后，一般是存到 Redis 里做查詢支撐，且 KV 存儲(chǔ)在應(yīng)對(duì)分析類查詢場(chǎng)景中也有較多局限。

實(shí)時(shí) OLAP 怎么實(shí)現(xiàn)？有沒有一種自帶存儲(chǔ)的實(shí)時(shí)計(jì)算引擎，當(dāng)實(shí)時(shí)數(shù)據(jù)來(lái)了之后，可以靈活的在一定范圍內(nèi)自由計(jì)算，并且有一定的數(shù)據(jù)承載能力，同時(shí)支持分析查詢響應(yīng)呢？隨著技術(shù)的發(fā)展，目前 MPP 引擎發(fā)展非常迅速，性能也在飛快提升，所以在這種場(chǎng)景下就有了一種新的可能。這里我們使用的是 Doris 引擎。

這種想法在業(yè)內(nèi)也已經(jīng)有實(shí)踐，且成為一個(gè)重要探索方向。阿里基于 ADB 的實(shí)時(shí) OLAP 方案等。

2. 實(shí)時(shí)數(shù)倉(cāng)架構(gòu)設(shè)計(jì)

從整個(gè)實(shí)時(shí)數(shù)倉(cāng)架構(gòu)來(lái)看，首先考慮的是如何管理所有的實(shí)時(shí)數(shù)據(jù)，資源如何有效整合，數(shù)據(jù)如何進(jìn)行建設(shè)。

從方法論來(lái)講，實(shí)時(shí)和離線是非常相似的，離線數(shù)倉(cāng)早期的時(shí)候也是 case by case，當(dāng)數(shù)據(jù)規(guī)模漲到一定量的時(shí)候才會(huì)考慮如何治理。分層是一種非常有效的數(shù)據(jù)治理方式，所以在實(shí)時(shí)數(shù)倉(cāng)如何進(jìn)行管理的問題上，首先考慮的也是分層的處理邏輯，具體如下：

• 數(shù)據(jù)源：在數(shù)據(jù)源的層面，離線和實(shí)時(shí)在數(shù)據(jù)源是一致的，主要分為日志類和業(yè)務(wù)類，日志類又包括用戶日志，DB 日志以及服務(wù)器日志等。
• 實(shí)時(shí)明細(xì)層：在明細(xì)層，為了解決重復(fù)建設(shè)的問題，要進(jìn)行統(tǒng)一構(gòu)建，利用離線數(shù)倉(cāng)的模式，建設(shè)統(tǒng)一的基礎(chǔ)明細(xì)數(shù)據(jù)層，按照主題進(jìn)行管理，明細(xì)層的目的是給下游提供直接可用的數(shù)據(jù)，因此要對(duì)基礎(chǔ)層進(jìn)行統(tǒng)一的加工，比如清洗、過(guò)濾、擴(kuò)維等。
• 匯總層：匯總層通過(guò) Flink 或 Storm 的簡(jiǎn)潔算子直接可以算出結(jié)果，并且形成匯總指標(biāo)池，所有的指標(biāo)都統(tǒng)一在匯總層加工，所有人按照統(tǒng)一的規(guī)范管理建設(shè)，形成可復(fù)用的匯總結(jié)果。

總結(jié)起來(lái)，從整個(gè)實(shí)時(shí)數(shù)倉(cāng)的建設(shè)角度來(lái)講，首先數(shù)據(jù)建設(shè)的層次化要先建出來(lái)，先搭框架，然后定規(guī)范，每一層加工到什么程度，每一層用什么樣的方式，當(dāng)規(guī)范定義出來(lái)后，便于在生產(chǎn)上進(jìn)行標(biāo)準(zhǔn)化的加工。由于要保證時(shí)效性，設(shè)計(jì)的時(shí)候，層次不能太多，對(duì)于實(shí)時(shí)性要求比較高的場(chǎng)景，基本可以走上圖左側(cè)的數(shù)據(jù)流，對(duì)于批量處理的需求，可以從實(shí)時(shí)明細(xì)層導(dǎo)入到實(shí)時(shí) OLAP 引擎里，基于 OLAP 引擎自身的計(jì)算和查詢能力進(jìn)行快速的回撤計(jì)算，如上圖右側(cè)的數(shù)據(jù)流。

06 實(shí)時(shí)平臺(tái)化建設(shè)

架構(gòu)確定之后，后面考慮的是如何進(jìn)行平臺(tái)化的建設(shè)，實(shí)時(shí)平臺(tái)化建設(shè)完全附加于實(shí)時(shí)數(shù)倉(cāng)管理之上進(jìn)行的。

首先進(jìn)行功能的抽象，把功能抽象成組件，這樣就可以達(dá)到標(biāo)準(zhǔn)化的生產(chǎn)，系統(tǒng)化的保障就可以更深入的建設(shè)，對(duì)于基礎(chǔ)加工層的清洗、過(guò)濾、合流、擴(kuò)維、轉(zhuǎn)換、加密、篩選等功能都可以抽象出來(lái)，基礎(chǔ)層通過(guò)這種組件化的方式構(gòu)建直接可用的數(shù)據(jù)結(jié)果流。這其中會(huì)有一個(gè)問題，用戶的需求多樣，滿足了這個(gè)用戶，如何兼容其他的用戶，因此可能會(huì)出現(xiàn)冗余加工的情況，從存儲(chǔ)來(lái)講，實(shí)時(shí)數(shù)據(jù)不存歷史，不會(huì)消耗過(guò)多的存儲(chǔ)，這種冗余是可以接受的，通過(guò)冗余的方式可以提高生產(chǎn)效率，是一種空間換時(shí)間的思想應(yīng)用。

通過(guò)基礎(chǔ)層的加工，數(shù)據(jù)全部沉淀到 IDL 層，同時(shí)寫到 OLAP 引擎的基礎(chǔ)層，再往上是實(shí)時(shí)匯總層計(jì)算，基于 Storm、Flink 或 Doris，生產(chǎn)多維度的匯總指標(biāo)，形成統(tǒng)一的匯總層，進(jìn)行統(tǒng)一的存儲(chǔ)分發(fā)。

當(dāng)這些功能都有了以后，元數(shù)據(jù)管理，指標(biāo)管理，數(shù)據(jù)安全性、SLA、數(shù)據(jù)質(zhì)量等系統(tǒng)能力也會(huì)逐漸構(gòu)建起來(lái)。

1. 實(shí)時(shí)基礎(chǔ)層功能

實(shí)時(shí)基礎(chǔ)層的建設(shè)要解決一些問題。

首先是一條流重復(fù)讀的問題，一條 Binlog 打過(guò)來(lái)，是以 DB 包的形式存在的，用戶可能只用其中一張表，如果大家都要用，可能存在所有人都要接這個(gè)流的問題。解決方案是可以按照不同的業(yè)務(wù)解構(gòu)出來(lái)，還原到基礎(chǔ)數(shù)據(jù)流層，根據(jù)業(yè)務(wù)的需要做成范式結(jié)構(gòu)，按照數(shù)倉(cāng)的建模方式進(jìn)行集成化的主題建設(shè)。

其次要進(jìn)行組件的封裝，比如基礎(chǔ)層的清洗、過(guò)濾、擴(kuò)維等功能，通過(guò)一個(gè)很簡(jiǎn)單的表達(dá)入口，讓用戶將邏輯寫出來(lái)。trans 環(huán)節(jié)是比較靈活的，比如從一個(gè)值轉(zhuǎn)換成另外一個(gè)值，對(duì)于這種自定義邏輯表達(dá)，我們也開放了自定義組件，可以通過(guò) Java 或 Python 開發(fā)自定義腳本，進(jìn)行數(shù)據(jù)加工。

2. 實(shí)時(shí)特征生產(chǎn)功能

特征生產(chǎn)可以通過(guò) SQL 語(yǔ)法進(jìn)行邏輯表達(dá)，底層進(jìn)行邏輯的適配，透?jìng)鞯接?jì)算引擎，屏蔽用戶對(duì)計(jì)算引擎的依賴。就像對(duì)于離線場(chǎng)景，目前大公司很少通過(guò)代碼的方式開發(fā)，除非一些特別的 case，所以基本上可以通過(guò) SQL 化的方式表達(dá)。

在功能層面，把指標(biāo)管理的思想融合進(jìn)去，原子指標(biāo)、派生指標(biāo)，標(biāo)準(zhǔn)計(jì)算口徑，維度選擇，窗口設(shè)置等操作都可以通過(guò)配置化的方式，這樣可以統(tǒng)一解析生產(chǎn)邏輯，進(jìn)行統(tǒng)一封裝。

還有一個(gè)問題，同一個(gè)源，寫了很多 SQL，每一次提交都會(huì)起一個(gè)數(shù)據(jù)流，比較浪費(fèi)資源，我們的解決方案是，通過(guò)同一條流實(shí)現(xiàn)動(dòng)態(tài)指標(biāo)的生產(chǎn)，在不停服務(wù)的情況下可以動(dòng)態(tài)添加指標(biāo)。

所以在實(shí)時(shí)平臺(tái)建設(shè)過(guò)程中，更多考慮的是如何更有效的利用資源，在哪些環(huán)節(jié)更能節(jié)約化的使用資源，這是在工程方面更多考慮的事情。

3. SLA 建設(shè)

SLA 主要解決兩個(gè)問題，一個(gè)是端到端的 SLA，一個(gè)是作業(yè)生產(chǎn)效率的 SLA，我們采用埋點(diǎn)+上報(bào)的方式，由于實(shí)時(shí)流比較大，埋點(diǎn)要盡量簡(jiǎn)單，不能埋太多的東西，能表達(dá)業(yè)務(wù)即可，每個(gè)作業(yè)的輸出統(tǒng)一上報(bào)到 SLA 監(jiān)控平臺(tái)，通過(guò)統(tǒng)一接口的形式，在每一個(gè)作業(yè)點(diǎn)上報(bào)所需要的信息，最后能夠統(tǒng)計(jì)到端到端的 SLA。

在實(shí)時(shí)生產(chǎn)中，由于鏈路非常長(zhǎng)，無(wú)法控制所有鏈路，但是可以控制自己作業(yè)的效率，所以作業(yè) SLA 也是必不可少的。

4. 實(shí)時(shí) OLAP 方案

問題：

• Binlog 業(yè)務(wù)還原復(fù)雜：業(yè)務(wù)變化很多，需要某個(gè)時(shí)間點(diǎn)的變化，因此需要進(jìn)行排序，并且數(shù)據(jù)要存起來(lái)，這對(duì)于內(nèi)存和 CPU 的資源消耗都是非常大的。
• Binlog 業(yè)務(wù)關(guān)聯(lián)復(fù)雜：流式計(jì)算里，流和流之間的關(guān)聯(lián)，對(duì)于業(yè)務(wù)邏輯的表達(dá)是非常困難的。

解決方案：

通過(guò)帶計(jì)算能力的 OLAP 引擎來(lái)解決，不需要把一個(gè)流進(jìn)行邏輯化映射，只需要解決數(shù)據(jù)實(shí)時(shí)穩(wěn)定的入庫(kù)問題。

我們這邊采用的是 Doris 作為高性能的 OLAP 引擎，由于業(yè)務(wù)數(shù)據(jù)產(chǎn)生的結(jié)果和結(jié)果之間還需要進(jìn)行衍生計(jì)算，Doris可以利用 unique 模型或聚合模型快速還原業(yè)務(wù)，還原業(yè)務(wù)的同時(shí)還可以進(jìn)行匯總層的聚合，也是為了復(fù)用而設(shè)計(jì)。應(yīng)用層可以是物理的，也可以是邏輯化視圖。

這種模式重在解決業(yè)務(wù)回撤計(jì)算，比如業(yè)務(wù)狀態(tài)改變，需要在歷史的某個(gè)點(diǎn)將值變更，這種場(chǎng)景用流計(jì)算的成本非常大，OLAP 模式可以很好的解決這個(gè)問題。

07 實(shí)時(shí)應(yīng)用案例

最后通過(guò)一個(gè)案例說(shuō)明，比如商家要根據(jù)用戶歷史下單數(shù)給用戶優(yōu)惠，商家需要看到歷史下了多少單，歷史 T+1 的數(shù)據(jù)要有，今天實(shí)時(shí)的數(shù)據(jù)也要有，這種場(chǎng)景是典型的 Lambda 架構(gòu)，可以在 Doris 里設(shè)計(jì)一個(gè)分區(qū)表，一個(gè)是歷史分區(qū)，一個(gè)是今日分區(qū)，歷史分區(qū)可以通過(guò)離線的方式生產(chǎn)，今日指標(biāo)可以通過(guò)實(shí)時(shí)的方式計(jì)算，寫到今日分區(qū)里，查詢的時(shí)候進(jìn)行一個(gè)簡(jiǎn)單的匯總。

這種場(chǎng)景看起來(lái)比較簡(jiǎn)單，難點(diǎn)在于商家的量上來(lái)之后，很多簡(jiǎn)單的問題都會(huì)變的復(fù)雜，因此后面我們也會(huì)通過(guò)更多的業(yè)務(wù)輸入，沉淀出更多的業(yè)務(wù)場(chǎng)景，抽象出來(lái)形成統(tǒng)一的生產(chǎn)方案和功能，以最小化的實(shí)時(shí)計(jì)算資源支撐多樣化的業(yè)務(wù)需求，這也是未來(lái)需要達(dá)到的目的。

?

?

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的从 Storm 迁移到 Flink，美团外卖实时数仓建设实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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