Doris的發(fā)展大家有目共睹。例如冷熱分離等新特性的持續(xù)增加。使得Doris在易用和成本上都有大幅提升。
基于Doris的一些存儲實(shí)時數(shù)倉在越來越多的場景中開始有一些實(shí)踐。大家也看到了這種方案頻繁出現(xiàn)在社區(qū)分享中。但是我們得客觀看待這種方案，基于存儲的實(shí)時數(shù)倉有優(yōu)勢也有他的劣勢，生產(chǎn)環(huán)境中我們要謹(jǐn)慎評估個人的業(yè)務(wù)場景。這篇文章我結(jié)合個人的實(shí)踐和思考簡單說說這個問題。。
為什么有這樣的方案？
基于Doris等OLAP實(shí)現(xiàn)實(shí)時計(jì)算的業(yè)務(wù)很多情況下是基于以下考慮。
在更多的情況下，基于Flink的實(shí)時數(shù)據(jù)開發(fā)難度要顯著高于離線任務(wù)(二者根本不在一個數(shù)量級)，基于Doris的存儲實(shí)時數(shù)據(jù)開發(fā)可以顯著降低開發(fā)門檻，但是存在濫用的可能。
其次，F(xiàn)link在大窗口、大狀態(tài)、靈活計(jì)算的場景下并不擅長(注意這里是不擅長，不是不能)，例如在多流Join、維表變更頻繁、口徑多變的場景下，開發(fā)成本極高，但是Doris可以顯著降低這一點(diǎn)。
最后，基于Flink的計(jì)算數(shù)據(jù)可觀測性差，例如狀態(tài)數(shù)據(jù)是不可見的，排查問題，Debug都存在顯著門檻，修復(fù)歷史數(shù)據(jù)也非常困難。
所以大家可以看到，上述基于Flink為主的實(shí)時數(shù)據(jù)開發(fā)存在不小的門檻。所以我們有一個定性的結(jié)論，在億級(或者數(shù)千萬)數(shù)據(jù)規(guī)模以下，可以使用類似Doris這種的分析引擎，仿照離線數(shù)據(jù)一樣進(jìn)行分層和定時調(diào)度，處理大窗口數(shù)據(jù)(一般時間跨度超過30天)，在保證性能的前提下，降低實(shí)時數(shù)據(jù)的開發(fā)成本，并且提高了數(shù)據(jù)的可觀測性，開發(fā)運(yùn)維效率也有一定提升。
和基于Flink的一些方案對比
門檻低，開發(fā)簡單
所有人都可以開發(fā)這樣的任務(wù)；
運(yùn)維簡單
因?yàn)椴幌馞link一樣考慮狀態(tài)兼容，不需要大量的資源長期占用。只在運(yùn)行SQL時需要調(diào)度資源；
開發(fā)效率提升
不需要對Flink有很深入的理解(當(dāng)然這不是好事),幾乎不存在參數(shù)條有，測試簡單，無需啟動調(diào)度容器(例如TaskManager和Task的調(diào)度)；
數(shù)據(jù)調(diào)試方便，中間結(jié)果落地可見
沒有Flink的狀態(tài)數(shù)據(jù)，所有數(shù)據(jù)都在表中可查。
上面幾點(diǎn)是一些優(yōu)勢，但是基于Doris的這種方案也存在明顯的短板，需要大家特別注意！
延遲明顯
如果你采用了Doris，那么我們大概率是配合定時調(diào)度進(jìn)行的，一般調(diào)度周期在30秒級以上，意味著數(shù)據(jù)實(shí)時性大幅降低，一些實(shí)時觀測的指標(biāo)例如實(shí)時GMV、在線人數(shù)等場景不適用；
數(shù)據(jù)規(guī)模限制
如果你采用了Doris，那么意味著，你的TPS不能過高，這不是Doris擅長的領(lǐng)域，需要大家特別注意。另外單次掃描的數(shù)據(jù)不能過大，正如我們前面所說，億級(或者數(shù)千萬)數(shù)據(jù)規(guī)模以下才有比較好的性能保證。
最后，如果你真的選擇以Doris為主的實(shí)時數(shù)據(jù)開發(fā)，那么意味著Doris會成為你的成本、運(yùn)維中心。要有非常嚴(yán)格的配套工具，例如報警、任務(wù)運(yùn)行監(jiān)控、任務(wù)規(guī)范性、調(diào)度和血緣能力。要特別注意資源和SQL性能問題，一旦他們成為瓶頸，會影響所有基于Doris的任務(wù)運(yùn)行。
