基於Doris構建億級數據實時數據分析系統

轉載至我的博客 https://www.infrastack.cn ，公眾號：架構成長指南背景隨著公司業務快速發展，對業務數據進行增長分析的需求越來越迫切，與此同時我們的業務數據量也在快速激增、每天的數據新增量大概在30w 左右，一年就會產生1 個億的數據，顯然基於傳統MySQL資料庫已經無法支 ...

轉載至我的博客 https://www.infrastack.cn ，公眾號：架構成長指南

背景

隨著公司業務快速發展，對業務數據進行增長分析的需求越來越迫切，與此同時我們的業務數據量也在快速激增、每天的數據新增量大概在30w 左右，一年就會產生1 個億的數據，顯然基於傳統MySQL資料庫已經無法支撐滿足以上需求

基於上述需求和痛點，決定提供一個靈活的多維實時查詢和分析平臺，幫助業務線做精細化運營。

業務分析

現有業務數據有以下特點，查詢多、更新少，基本不會更新1 個月以前的數據，但是查詢範圍較大，有時需要查詢幾年前的數據，而且數據會以年、月等不同維度統計來進行增長分析

因此以上場景使用 OLTP 引擎不是特別適合，OLAP則更為適合

這裡可能有些人員不懂什麼是 OLAP，下麵是一個OLAP與OLTP對比圖

技術選型

實時數倉

以上場景確定後，我們就開始了框架選型，最終確定了 Doris，理由如下

性能滿足要求
相容MySQL 協議
運維成本較低
架構足夠簡單
社區活躍，支持力度高

下麵是一個選型對比，沒有好壞，只是Doris適合我們

實時數據捕獲

實時數據，採用Fink CDC進行捕獲，Fink CDC Connectors 是Apache Flink的一組源連接器，使用變更數據捕獲 (CDC) 從不同資料庫中獲取變更，而獲取變更是通過Debezium監聽Binlog 日誌，獲取到更新數據以後，可以對數據進行轉換，然後在根據doris 提供的Flink 插件Doris flink connecto導入到 Doris 裡面

具體示例，可以參考：https://mp.weixin.qq.com/s/ssXocqCyoSVuRFBi2hzCKQ

為什麼需要實時數據捕獲？

Doris 只是一個數據倉庫，他提供的功能是實時數據統計、查詢和存儲，他不支持主動實時抓取數據，需要藉助第三方工具來進行實現，比如我們在 MySQL修改了一條數據，怎麼讓 Doris 進行更新？目前想到的答案是主動發送更新數據至Kafka，然後Doris訂閱 KafKa 的 Topic 然後進行實時同步，雖然以上能實現我們想要的功能，但是有點複雜，業務每次操作都要發送 Kafka，同時要想對數據進行加工，工作量相對較，正因為有以上問題，所以我們採用Flink CDC

數據調度平臺

數據調度平臺，採用海豚調度器（DolphinScheduler），它也是國人開源的一款分散式可擴展的大數據調度平臺，使用Java 語言開發，目前已經成為Apache 項目，它提供了強大的DAG可視化界面，所有流程定義都是可視化，通過拖拽任務完成定製DAG，同時支持 30+類型的任務，比如執行 SQL、shell 、DataX 等類型，官網地址：https://dolphinscheduler.apache.org

為什麼需要數據調度平臺？

數據轉換：通過Flink 抽取的數據，如果還想對這些數據進行加工處理，比如實時同步的業務數據，需要再次轉換為分鐘級、小時級、天、月等維度的報表

非實時數據同步：通過調度DataX，以分鐘、小時、天為單位進行源數據同步

定時歸檔：比如每晚同步業務資料庫一個月前數據，同步完成之後，在執行刪除任務，刪除業務庫一個月前的數據

數倉數據分層

數據倉庫的分層是一種常見的設計模式，它將數據倉庫劃分為不同的層級，每個層級有不同的功能和用途。

數倉層內部的劃分不是為了分層而分層，它是數據倉庫經過了建模和 ETL 之後真正開始對外提供服務的地方，因此數倉層內的劃分更應該符合使用者的思維習慣。 DW 內的分層沒有最正確的，只有最適合你的。

ODS層

Operation Data Store 數據準備區，也稱為貼源層。數據倉庫源頭系統的數據表通常會原封不動的存儲一份，這稱為ODS層，是後續數據倉庫加工數據的來源。

DWD層

data warehouse details 細節數據層，是業務層與數據倉庫的隔離層。主要對ODS數據層做一些數據清洗和規範化的操作，數據清洗：去除空值、臟數據、超過極限範圍的

DWS層

data warehouse service 數據服務層，基於DWD上的基礎數據，整合彙總成分析某一個主題域的服務數據層，一般是寬表。用於提供後續的業務查詢，OLAP分析，數據分發等。

用戶行為，輕度聚合
主要對ODS/DWD層數據做一些輕度的彙總。

註意：數倉層內部的劃分不是為了分層而分層，它是數據倉庫經過了建模和 ETL 之後真正開始對外提供服務的地方，因此數倉層內的劃分更應該符合使用者的思維習慣。 DW 內的分層沒有最正確的，只有最適合你的。

命名規範

系統架構

經過前面的技術選型，以及分層定義，我們最終架構如下

數據查詢

假設語句已經同步到doris，那麼怎麼進行展現，這裡有很多種方式，比如通過BI工具，例如：power bi、dataEase、Davinci等，同時Doris 支持mysql 協議，我們為了讓之前的業務改動，對後端介面實現進行了替換，通過 mybatis 動態解析 sql，並調用 doris進行查詢，架構如下