在當今數據驅動的時代，構建一個快速、安全和高可靠的實時數據倉庫對于企業來說至關重要。Apache Doris作為一個強大的開源數據倉庫解決方案，提供了實現這一目標的理想選擇。通過利用Doris的強大功能和特性，可以構建一個高度可擴展且具備優異性能的實時數據倉庫，以滿足數據處理和分析的需求。本文介紹如何基于Doris打造這樣一個數據倉庫，以實現數據驅動。

1 使用Apache Doris構建實時數據倉庫

1.1 數據模型選擇

Apache Doris使用三種數據模型來組織數據，這些模型之間的主要區別在于是否以及如何聚合數據。

• Duplicate Key模型：用于詳細數據查詢。支持任意維度的即席查詢。
• Unique Key模型：用于存在數據唯一性約束的用例。支持精確去重、多流Upsert和部分列更新。
• Aggregate Key模型：用于數據報表。通過預聚合數據，加速數據報表生成。

金融用戶在不同的數據倉庫層中采用不同的數據模型：

• ODS（原始數據層）- Duplicate Key模型：作為支付服務提供商，用戶每天收到一百萬筆結算數據。由于結算周期可能跨越一整年，相關數據需要保存一年。因此，合適的方式是將其放入Duplicate Key模型，該模型不執行任何數據聚合。唯一的例外是一些容易變動的數據，比如來自零售商的訂單狀態。這些數據應該放入Unique Key模型，以便同一零售商ID或訂單ID的新記錄始終替換舊記錄。
• DWD（數據倉庫層）和DWS（數據服務層）- Unique Key模型：DWD和DWS層的數據進一步抽象，但仍然放在Unique Key模型中，以便結算數據可以自動更新。
• ADS（分析數據層）- Aggregate Key模型：該層中的數據高度抽象。通過預聚合數據，減輕下游分析的計算負載。

1.2 分區和桶化策略

分區和桶化的思想是將數據“切割”成較小的部分，以增加數據處理速度。關鍵是設置適當數量的數據分區和桶。根據使用情況，根據每個表自定義桶化字段和桶的數量。例如，經常需要從零售商扁平表查詢不同零售商的維度數據，因此可以將零售商ID列指定為桶化字段，并列出各種數據大小的推薦桶數量。

圖片

2 多源數據遷移

在采用Apache Doris時，需要將所有分支機構的本地數據遷移到Doris中，但會發現分支機構使用了不同的數據庫，并且具有非常不同的數據文件格式，所以遷移可能會很混亂。

圖片

幸運的是，Apache Doris支持豐富的數據集成方法，既支持實時數據流式處理，又支持離線數據導入。

• 實時數據流處理：Apache Doris實時獲取MySQL Binlog。其中一部分通過Flink CDC直接寫入Doris，而高容量的數據則通過Kafka同步，然后通過Flink-Doris-Connector寫入Doris。
• 離線數據導入：包括更多種類的數據源和數據格式。歷史數據和增量數據從S3和HDFS導入Doris使用經紀人加載方法，來自Hive或JDBC的數據通過Insert Into方法同步到Doris，文件通過Flink-Doris-Connector和Flink FTP Connector加載到Doris。（FTP是用戶在系統之間傳輸文件的方式，所以他們開發了Flink-FTP-Connector以支持復雜的數據格式和多個換行符的數據。）

3 全量數據攝取和增量數據攝取

為了確保業務連續性和數據準確性，可用以下攝取全量數據和增量數據的方法：

• 全量數據攝取：在Doris中創建目標模式的臨時表，將全量數據導入臨時表，然后使用ALTER TABLE t1 REPLACE WITH TABLE t2語句原子替換常規表為臨時表。這種方法可以避免對前面的查詢產生影響。

alter table ${DB_NAME}.${TBL_NAME} drop partition IF EXISTS p${P_DOWN_DATE};
ALTER TABLE ${DB_NAME}.${TBL_NAME} ADD PARTITION IF NOT EXISTS p${P_DOWN_DATE} VALUES[('${P_DOWN_DATE}'), ('${P_UP_DATE}'));

LOAD LABEL ${TBL_NAME}_${load_timestamp} ...

• 增量數據導入：創建新的數據分區以容納增量數據。

4 離線數據處理

已經將部分離線數據處理工作遷移到Apache Doris，并把執行速度提高了5倍。

圖片

• 之前：舊的基于Hive的離線數據倉庫使用TEZ執行引擎每天處理3000萬條新數據記錄。使用2TB計算資源，整個流程需要2.5小時。
• 現在：Apache Doris在僅30分鐘內完成相同的任務，僅消耗1TB。腳本執行僅需要10秒，而不是8分鐘。

5 面向金融機構的企業功能

多租戶資源隔離

這是必需的，因為經常會發生多個團隊或業務系統請求同一數據的情況。這些任務可能導致資源搶占，從而降低性能和系統的穩定性。

5.1 不同工作負載的資源限制

這里把分析工作負載分為四類，并為每個類別設置了資源限制。特別是擁有四種不同類型的Doris賬戶，并為每種類型的賬戶設置了CPU和內存資源的限制。

圖片

通過這種方式，當一個租戶需要過多的資源時，它只會影響自己的效率，而不會影響其他租戶。

5.2 基于資源標簽的隔離

為了滿足母子公司層級的數據安全性，這里為子公司設置隔離的資源組。每個子公司的數據存儲在其自己的資源組中，并具有三個副本，而母公司的數據則存儲在四個副本中：三個在母公司資源組中，另一個在子公司資源組中。因此，當子公司的員工請求母公司的數據時，查詢只會在子公司資源組中執行。具體而言，采取以下步驟：

圖片

5.3 工作負載組

基于資源標簽的隔離方案確保了物理級別的隔離，但作為Apache Doris開發人員，希望進一步優化資源利用率并追求更細粒度的資源隔離。為此，在Apache Doris 2.0中推出了工作負載組功能。

工作負載組機制將查詢與工作負載組相關聯，限制了查詢可以使用的后端節點的CPU和內存資源的共享。當集群資源短缺時，最大的查詢將停止執行。相反，當集群資源充足且工作負載組需要的資源超過限制時，它將按比例分配空閑資源。

5.4 細粒度用戶權限管理

出于規章制度和合規性原因，有的提供商實施嚴格的權限控制，以確保每個人只能訪問他們應該訪問的內容。參考做法如下：

• 用戶權限設置：不同子公司或具有不同業務需求的系統用戶被分配不同的數據訪問權限。
• 對數據庫、表和行的權限控制：Apache Doris的ROW POLICY機制使這些操作變得容易。
• 對列的權限控制：通過創建視圖來實現。

圖片

6 集群穩定性保證

• 斷路器機制：偶爾，系統用戶可能輸入有誤的SQL，導致資源消耗過多。為此，設置了斷路器機制。它將及時停止這些消耗資源的查詢，防止對系統的干擾。
• 數據攝取并發控制：例如經常需要將歷史數據整合到數據平臺中。這涉及大量的數據修改任務，可能會對集群造成壓力。為解決這個問題，可在唯一鍵模型中啟用寫入合并模式，啟用垂直壓縮和段壓縮，并調整數據壓縮參數以控制數據攝取并發性。
• 網絡流量控制：若有在不同城市的兩個集群，可采用針對不同場景的服務質量（QoS）策略，以實現精確的網絡隔離，確保網絡質量和穩定性。
• 監控和警報：將Doris與內部監控和警報平臺集成，任何檢測到的問題都將通過消息軟件和電子郵件及時通知。