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