淺談Doris和Flink在廣告實時數倉中的實踐

Doris簡介

▍1.1 簡介

Apache Doris是一個現代化的MPP分析型數據庫產品。僅需亞秒級響應時間便可得到查詢結果，有效地支持實時數據分析。Apache Doris的分佈式架構很是簡潔，易於運維，而且能夠支持10PB以上的超大數據集。mysql

Apache Doris能夠知足多種數據分析需求，例如固定歷史報表，實時數據分析，交互式數據分析和探索式數據分析等。令您的數據分析工做更加簡單高效！web

▍ 1.2 架構

咱們的業務背景，就是想秒級實時數據呈現。算法

開始進入正題。。。。

▍2.1 咱們的歷史架構

數據量介紹：
sql

計算問題：app

存儲問題：

寬表須要多流join，還得關聯維度表
es不支持join，須要提早加工好寬表
es大量聚合查詢性能降低
es-sql，計算函數支持不優雅，好比：除法等等
es沒有聚合模型，全量寫入會帶來寫入壓力和冗餘數據，須要依託flink窗口預計算來減輕寫入壓力。缺點：flink窗口小，寫入量大帶來數據冗餘和寫入性能差；flink窗口大，寫入數據量會減小，數據時效性差，沒法知足模型訓練秒級別的需求

計算替代思考🤔？

多流join，可否在近實時的olap引擎中去作？
用olap引擎作能帶給咱們什麼價值？
web接口服務提供的維度數據如何辦？olap也無法實時查詢接口服務呀，還有kv內存得維度數據，這些都須要flink去擴充。mysql的數據也能夠用flink擴充，也能夠本身經過腳本寫入到olap中。

結論：doris能夠替代flink作join計算，而且doris的udf函數齊全，自帶colocate join模型(按照相同key分桶，join的時候能夠避免網絡shuffle)和聚合模型（下降數據量，提高查詢效率），還有好多優點，我就很少說了，doris真的是個神器😝。

看上面👆這個圖，你就知道doris的優點了，千萬級數據join，秒級產出，很是贊👍。

存儲替代思考🤔？

總結：直接換成doris，es自己就不適合作olap多維聚合分析，尤爲是在join的場景，沒法知足業務需求。

計算上olap能夠替代部分flink的join任務：

兩個kafka流作join，無需關聯kv和接口維度數據，好比點擊流+喚起流+mysql維度信息（多個mysql表），能夠直接在doris中作join，無需單獨開發flink去作，複用doris的udf函數。（目前我在doris中都是進行4表join很是方便，千萬級數據join性能在2-3s返回）
mysql能夠寫個定時任務寫入到doris中
hive的維度數據也能夠導入到doris中進行維度關聯。

最後架構：

總結：doris內部作join能夠節省開發時間，而且自已維護，不用考慮數據延遲落後的問題。doris內部自帶物化視圖，既能夠存明細，也能夠實現聚合模型，既方便報表查詢，也方便線上經過明細數據問題排查，同時還方便維護，模型訓練也支持秒級查詢。

爲何我要all in 這個doris

淺談不到位的，還請各位大佬多多指點，祝全部作大數據的小夥伴，均可以升職加薪，超過作算法同窗的工資哈哈哈哈哈哈哈

業務數倉架構應該具有哪些能力？

業務常常變更打法，你的實時數據倉不能構建的過重，須要短期迭代上線（你們沒有遇到業務提一個需求，一個月時間作完了，業務用了幾回就不用了，還有就是公司改變廣告營銷打法，以前的實時指標可能沒人去看了，打入冷宮了）。
你的架構要足夠的輕量化，易維護，同時還得兼顧：明細查詢（線上問題排查），聚合查詢（報表指標呈現）
業務看重的是你支持業務的能力，而不是你花裏胡哨的架構。你要確保業務當天提需求，當天能夠完成，你的架構好壞是靠你支持業務的效果來體現，因此適合本身業務的架構，就是好架構。
你的架構平時穩只能算及格，你要確保架構在大促和高峯流量來時系統穩定，能不能抗住百億或者千億的流量。
不一樣sla的業務場景設計不一樣的架構，並非全部的業務場景都是要求毫秒或者秒級，其實你仔細跟他們聊分鐘級他們也能夠接受，不一樣的sla對你的計算資源成本要求不同，適量把控計算資源成本，優秀的工程師都是想辦法給公司省錢，同時還能夠圓滿完成任務。

END

最後拋出來一個問題，500億的實時數據，如何加工報表指標？是全量計算嗎？全量計算會遇到什麼問題？數據傾斜怎麼辦？即便數據不傾斜了，遇到流量高峯怎麼辦？數據背壓就必定要追加計算資源嗎？你有什麼好的辦法？

公衆號回覆：「資料全集」，海量PPT等你來拿。

本文分享自微信公衆號 - 小晨說數據（flink-spark）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。