基於Doris實時資料開發的一些注意事項

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的任務執行。