轉(zhuǎn)載鏈接：http://www.reibang.com/p/a1749c1526d7
導(dǎ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ù)多樣需求擎值。
1 實(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)景
2 實(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ù)成熟度來講玻熙，前幾年用的是Storm嗦随，Storm當(dāng)時(shí)在性能穩(wěn)定性枚尼、可靠性以及擴(kuò)展性上是無可替代的。隨著Flink越來越成熟署恍，從技術(shù)性能上以及框架設(shè)計(jì)優(yōu)勢(shì)上已經(jīng)超越Storm袁串，從趨勢(shì)來講就像Spark替代MR一樣呼巷，Storm也會(huì)慢慢被Flink替代王悍，當(dāng)然從Storm遷移到Flink會(huì)有一個(gè)過程，我們目前有一些老的任務(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ì)來講比較簡(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ì)講到。
3 業(yè)務(wù)痛點(diǎn)
在外賣業(yè)務(wù)上蚊夫，我們也遇到了一些問題诉字。
業(yè)務(wù)早期，為了滿足業(yè)務(wù)需要知纷，一般是拿到需求后case by case的先把需求完成壤圃，業(yè)務(wù)對(duì)于實(shí)時(shí)性要求是很高的，從時(shí)效性來說琅轧，沒有進(jìn)行中間層沉淀的機(jī)會(huì)伍绳，在這種場(chǎng)景下，一般是拿到業(yè)務(wù)邏輯直接嵌入鹰晨，這是能想到的簡(jiǎn)單有效的方法墨叛，在業(yè)務(wù)發(fā)展初期這種開發(fā)模式比較常見。
如上圖所示模蜡，拿到數(shù)據(jù)源后漠趁，會(huì)經(jīng)過數(shù)據(jù)清洗，擴(kuò)維忍疾，通過Storm或Flink進(jìn)行業(yè)務(wù)邏輯處理闯传，最后直接進(jìn)行業(yè)務(wù)輸出。把這個(gè)環(huán)節(jié)拆開來看卤妒，數(shù)據(jù)源端會(huì)重復(fù)引用相同的數(shù)據(jù)源甥绿，后面進(jìn)行清洗、過濾则披、擴(kuò)維等操作共缕，都要重復(fù)做一遍，唯一不同的是業(yè)務(wù)的代碼邏輯是不一樣的士复。如果業(yè)務(wù)較少图谷，這種模式還可以接受翩活，但當(dāng)后續(xù)業(yè)務(wù)量上去后，會(huì)出現(xiàn)誰開發(fā)誰運(yùn)維的情況便贵，維護(hù)工作量會(huì)越來越大菠镇，作業(yè)無法形成統(tǒng)一管理。而且所有人都在申請(qǐng)資源承璃，導(dǎo)致資源成本急速膨脹利耍，資源不能集約有效利用，因此要思考如何從整體來進(jìn)行實(shí)時(shí)數(shù)據(jù)的建設(shè)盔粹。
4 數(shù)據(jù)特點(diǎn)與應(yīng)用場(chǎng)景
那么如何來構(gòu)建實(shí)時(shí)數(shù)倉(cāng)呢隘梨？
首先要進(jìn)行拆解，有哪些數(shù)據(jù)舷嗡，有哪些場(chǎng)景出嘹，這些場(chǎng)景有哪些共同特點(diǎn)，對(duì)于外賣場(chǎng)景來說一共有兩大類咬崔，日志類和業(yè)務(wù)類。
日志類：數(shù)據(jù)量特別大烦秩，半結(jié)構(gòu)化垮斯，嵌套比較深。日志類的數(shù)據(jù)有個(gè)很大的特點(diǎn)只祠，日志流一旦形成是不會(huì)變的兜蠕，通過埋點(diǎn)的方式收集平臺(tái)所有的日志，統(tǒng)一進(jìn)行采集分發(fā)抛寝，就像一顆樹熊杨，樹根非常大，推到前端應(yīng)用的時(shí)候盗舰，相當(dāng)于從樹根到樹枝分叉的過程（從1到n的分解過程）晶府，如果所有的業(yè)務(wù)都從根上找數(shù)據(jù)，看起來路徑最短钻趋，但包袱太重川陆，數(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的集成加工過程片部。
業(yè)務(wù)類實(shí)時(shí)處理面臨的幾個(gè)難點(diǎn)：
業(yè)務(wù)的多狀態(tài)性：業(yè)務(wù)過程從開始到結(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ù)一般無法通過單一主體表達(dá)，往往是很多表進(jìn)行關(guān)聯(lián)典挑，才能得到想要的信息酥宴，在實(shí)時(shí)流中進(jìn)行數(shù)據(jù)的合流對(duì)齊，往往需要較大的緩存處理且復(fù)雜您觉。
分析是批量的拙寡，處理過程是流式的：對(duì)單一數(shù)據(jù)，無法形成分析琳水，因此分析對(duì)象一定是批量的肆糕，而數(shù)據(jù)加工是逐條的。
日志類和業(yè)務(wù)類的場(chǎng)景一般是同時(shí)存在的在孝，交織在一起诚啃，無論是Lambda架構(gòu)還是Kappa架構(gòu)，單一的應(yīng)用都會(huì)有一些問題私沮。因此針對(duì)場(chǎng)景來選擇架構(gòu)與實(shí)踐才更有意義绍申。
5 實(shí)時(shí)數(shù)倉(cāng)架構(gòu)設(shè)計(jì)
1. 實(shí)時(shí)架構(gòu)：流批結(jié)合的探索
基于以上問題，我們有自己的思考顾彰。通過流批結(jié)合的方式來應(yīng)對(duì)不同的業(yè)務(wù)場(chǎng)景极阅。
如上圖所示，數(shù)據(jù)從日志統(tǒng)一采集到消息隊(duì)列，再到數(shù)據(jù)流的ETL過程，作為基礎(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都需要很大的外存髓迎，來實(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ù)來了之后，可以靈活的在一定范圍內(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)來看，首先考慮的是如何管理所有的實(shí)時(shí)數(shù)據(jù)糯累，資源如何有效整合算利，數(shù)據(jù)如何進(jìn)行建設(shè)。
從方法論來講泳姐，實(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)一的加工篮条，比如清洗弟头、過濾、擴(kuò)維等涉茧。
匯總層：匯總層通過Flink或Storm的簡(jiǎn)潔算子直接可以算出結(jié)果赴恨，并且形成匯總指標(biāo)池，所有的指標(biāo)都統(tǒng)一在匯總層加工伴栓，所有人按照統(tǒng)一的規(guī)范管理建設(shè)伦连，形成可復(fù)用的匯總結(jié)果。
總結(jié)起來钳垮，從整個(gè)實(shí)時(shí)數(shù)倉(cāng)的建設(shè)角度來講惑淳，首先數(shù)據(jù)建設(shè)的層次化要先建出來，先搭框架饺窿，然后定規(guī)范歧焦，每一層加工到什么程度，每一層用什么樣的方式肚医，當(dāng)規(guī)范定義出來后绢馍，便于在生產(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ù)流。
6 實(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ǔ)加工層的清洗疗垛、過濾症汹、合流、擴(kuò)維贷腕、轉(zhuǎn)換背镇、加密、篩選等功能都可以抽象出來泽裳，基礎(chǔ)層通過這種組件化的方式構(gòu)建直接可用的數(shù)據(jù)結(jié)果流瞒斩。這其中會(huì)有一個(gè)問題，用戶的需求多樣涮总，滿足了這個(gè)用戶胸囱，如何兼容其他的用戶，因此可能會(huì)出現(xiàn)冗余加工的情況瀑梗，從存儲(chǔ)來講烹笔，實(shí)時(shí)數(shù)據(jù)不存歷史，不會(huì)消耗過多的存儲(chǔ)抛丽，這種冗余是可以接受的谤职，通過冗余的方式可以提高生產(chǎn)效率，是一種空間換時(shí)間的思想應(yīng)用亿鲜。
通過基礎(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)建起來撬码。
1. 實(shí)時(shí)基礎(chǔ)層功能
實(shí)時(shí)基礎(chǔ)層的建設(shè)要解決一些問題。
首先是一條流重復(fù)讀的問題版保，一條Binlog打過來呜笑，是以DB包的形式存在的夫否，用戶可能只用其中一張表，如果大家都要用叫胁，可能存在所有人都要接這個(gè)流的問題凰慈。解決方案是可以按照不同的業(yè)務(wù)解構(gòu)出來，還原到基礎(chǔ)數(shù)據(jù)流層驼鹅，根據(jù)業(yè)務(wù)的需要做成范式結(jié)構(gòu)微谓，按照數(shù)倉(cāng)的建模方式進(jìn)行集成化的主題建設(shè)。
其次要進(jìn)行組件的封裝输钩，比如基礎(chǔ)層的清洗豺型、過濾、擴(kuò)維等功能买乃，通過一個(gè)很簡(jiǎn)單的表達(dá)入口姻氨，讓用戶將邏輯寫出來。trans環(huán)節(jié)是比較靈活的为牍，比如從一個(gè)值轉(zhuǎn)換成另外一個(gè)值哼绑，對(duì)于這種自定義邏輯表達(dá)，我們也開放了自定義組件碉咆，可以通過Java或Python開發(fā)自定義腳本抖韩，進(jìn)行數(shù)據(jù)加工。
2. 實(shí)時(shí)特征生產(chǎn)功能
特征生產(chǎn)可以通過SQL語法進(jìn)行邏輯表達(dá)疫铜，底層進(jìn)行邏輯的適配茂浮，透?jìng)鞯接?jì)算引擎，屏蔽用戶對(duì)計(jì)算引擎的依賴壳咕。就像對(duì)于離線場(chǎng)景席揽，目前大公司很少通過代碼的方式開發(fā)，除非一些特別的case谓厘，所以基本上可以通過SQL化的方式表達(dá)幌羞。
在功能層面，把指標(biāo)管理的思想融合進(jìn)去竟稳，原子指標(biāo)属桦、派生指標(biāo)，標(biāo)準(zhǔn)計(jì)算口徑他爸，維度選擇聂宾，窗口設(shè)置等操作都可以通過配置化的方式，這樣可以統(tǒng)一解析生產(chǎn)邏輯诊笤，進(jìn)行統(tǒng)一封裝系谐。
還有一個(gè)問題，同一個(gè)源讨跟，寫了很多SQL纪他，每一次提交都會(huì)起一個(gè)數(shù)據(jù)流鄙煤，比較浪費(fèi)資源，我們的解決方案是止喷，通過同一條流實(shí)現(xiàn)動(dòng)態(tài)指標(biāo)的生產(chǎn)馆类，在不停服務(wù)的情況下可以動(dòng)態(tài)添加指標(biāo)。
所以在實(shí)時(shí)平臺(tái)建設(shè)過程中弹谁，更多考慮的是如何更有效的利用資源乾巧，在哪些環(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)冻记，通過統(tǒng)一接口的形式睡毒，在每一個(gè)作業(yè)點(diǎn)上報(bào)所需要的信息，最后能夠統(tǒng)計(jì)到端到端的SLA冗栗。
在實(shí)時(shí)生產(chǎn)中演顾，由于鏈路非常長(zhǎng)，無法控制所有鏈路隅居，但是可以控制自己作業(yè)的效率钠至，所以作業(yè)SLA也是必不可少的。
4. 實(shí)時(shí)OLAP方案
問題：
Binlog業(yè)務(wù)還原復(fù)雜：業(yè)務(wù)變化很多胎源，需要某個(gè)時(shí)間點(diǎn)的變化棉钧，因此需要進(jìn)行排序，并且數(shù)據(jù)要存起來涕蚤，這對(duì)于內(nèi)存和CPU的資源消耗都是非常大的宪卿。
Binlog業(yè)務(wù)關(guān)聯(lián)復(fù)雜：流式計(jì)算里，流和流之間的關(guān)聯(lián)赞季，對(duì)于業(yè)務(wù)邏輯的表達(dá)是非常困難的愧捕。
解決方案：
通過帶計(jì)算能力的OLAP引擎來解決奢驯，不需要把一個(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è)問題宠纯。
7 實(shí)時(shí)應(yīng)用案例
最后通過一個(gè)案例說明，比如商家要根據(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ū)可以通過離線的方式生產(chǎn)，今日指標(biāo)可以通過實(shí)時(shí)的方式計(jì)算宵统，寫到今日分區(qū)里晕讲，查詢的時(shí)候進(jìn)行一個(gè)簡(jiǎn)單的匯總。
這種場(chǎng)景看起來比較簡(jiǎn)單马澈，難點(diǎn)在于商家的量上來之后瓢省，很多簡(jiǎn)單的問題都會(huì)變的復(fù)雜，因此后面我們也會(huì)通過更多的業(yè)務(wù)輸入痊班，沉淀出更多的業(yè)務(wù)場(chǎng)景勤婚，抽象出來形成統(tǒng)一的生產(chǎn)方案和功能，以最小化的實(shí)時(shí)計(jì)算資源支撐多樣化的業(yè)務(wù)需求涤伐，這也是未來需要達(dá)到的目的馒胆。
作者：DorisDB
鏈接：http://www.reibang.com/p/a1749c1526d7
來源：簡(jiǎn)書
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)凝果，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處祝迂。
