目錄

前言

一、應用場景

二、OLAP選型

三、實時數倉構建

四、實時數倉體系的建設與實踐

4.1?數倉分層的合理規劃

4.2?分桶分區策略的合理設置

4.3?多源數據遷移方案

4.4?全量與增量數據的同步

4.5?離線數據加工任務遷移

五、金融級數倉穩定性最佳實踐

5.1 多租戶資源隔離

5.1.1?單查詢資源限制，保證查詢間資源可控

5.1.2?基于Resource Tag的多租戶數據與查詢隔離

5.1.3 更靈活的資源隔離方案

5.2 精細用戶權限管理

5.3 集群穩定性保障

5.3.1 SQL熔斷

5.3.2 導入并發控制

5.3.3? 網絡流量控制

5.3.4? 監控報警

5.4?基于 CCR 的集群災備能力

六、總結與規劃

---

? 原文大佬的這篇實時數倉構建有借鑒意義，這里摘抄下來用作學習和知識沉淀。

前言

? ? 銀聯商務是國內大型的非銀行支付機構，沉淀了龐大、真實、優質的數據資產數據。隨著業務的不斷擴展，早期基于 Hadoop 的大數據平臺已無法高效支撐拓展性、時效性與便捷性的業務需求，因此2020 年起，銀聯商務開啟了數據平臺的升級之旅，基于Doris 構建了新一代實時數據倉庫架構，使數據導入性能提升 2-5 倍、ETL 場景性能提升 3-12 倍、查詢分析響應速度提升 10-15 倍，滿足大規模數據導入和實時極速查詢的業務需求，解決了業務和數據快速增長問題。

一、應用場景

? ? 在長期為各行各業的海量商戶提供服務的過程中，銀聯商務沉淀了大量的交易數據、用戶數據、終端數據以及經營數據等。

? ? 通過對這些數據的挖掘和利用，為銀聯商務總、分、子公司以及商戶提供多元化的數據服務，典型數據服務場景包括：? ??

• 經營分析場景：建設指標體系和駕駛艙，幫助業務方及管理者實時了解整體業務經營狀態
• 業務經營場景：建設標簽體系，更好理解用戶畫像及需求，從而提供精準的產品和業務服務
• 數據分析和挖掘場景：構建自助分析和報表服務，更好地了解業務情況并做出科學決策
• 對外數據服務場景：構建對賬單、報表和數據報告服務，以幫助商戶更好地了解市場需求。

? ? 為滿足上述場景需求，銀聯商務早在 2015年就引入了Hadoop體系構建了大數據平臺，并基于Hive構建了離線數倉。該架構整合了來自 MySQL、Oracle、MongoDB 等多業務系統的數據，按照T+1的時效性歸集到Hive離線數倉中，經由 Hive數倉各層的加工處理后分別同步至不同組件中提供數據查詢服務，包括基于Kylin與HBase構建Cube進行指標查詢分析，并使用Hbase進行增量數據的質量監測，同時還將處理完畢的數據同步到Oracle 中提供業務數據查詢。

? ?該架構各組件各司其職、整體架構清晰。在移動支付快速席卷的浪潮下，支付場景更加多元化，總部及分子公司對于數據應用的建設需求不斷涌現，而傳統的大數據平臺已經無法高效支撐業務和數據的不斷增長，痛點逐步展現出來：

• 數據時效性：整體數據處理鏈路較長，最新業務數據從生產到應用的時間間隔太長，無法充分發揮實時數據的價值
• 查詢效率低：Kylin早期承擔了大多指標查詢分析的需求，隨著業務量增長、Kylin數據預處理的成本越來越高，無法支持靈活快速的的分析訴求，而hive在應對復雜查詢時效性能不足，只能依賴于堆加機器，這無疑大大增加了硬件資源成本；
• 運維成本和擴展性：整體架構涉及多個組件，運維工作量較大，在應對業務需求增長的過程中可擴展性不足，無法敏捷響應數據的快速增長和數據應用快速上線的要求

二、OLAP選型

? ? 面向各行各業的數千萬商戶、行業特點和實際需求各不相同，在對企業內部眾多平臺系統以及對客戶提供的產品進行全面梳理后，銀聯商務確定了數字化轉型要實現的核心目標——“全量打通、準確實時、隨需自助、智能交互”。

? ? 具體而言，“全量打通”即各平臺間充分互通、數據融合共享，便于更全面掌握數據主題的全方位信息、充分發揮數據的協同效應；“準確實時”即充分發揮數據的實時價值，并根據技術手段保證數據又“快”又“準”，為后續分析打好堅實基礎；“隨需自取”即提供自助式的服務，靈活組合、按需取用；“智能交互”即充分利用技術手段，從被動式的接受服務，變成主動式的能力輸出，提供分析、預測、輔助決策等智能服務，響應用戶需求、實現雙向交互。

? ? ?而具體到數據服務層面，在為內外部客戶提供數據服務的過程中，銀聯商務注意到用戶對數據分析的性能、分析模式的靈活性、數據服務的穩定性以及數據應用的時效性有著更高的期望，因此我們決定對現有架構升級，旨在滿足新的業務訴求、解決早期架構存在的問題，于是在 2020 年正式啟動了銀聯商務數據架構的升級之旅，升級目標主要包含幾方面：

• 統一、簡潔：單一系統即可完成數據加工和服務的統一，以簡化數據處理流程，提高工作效率；
• 穩定、高效：支持高效的數據加工和高性能的數據查詢，同時系統和平臺的穩定性得以充分的保證；
• 準確、實時：支持數據實時更新以及接入，保證數據準確、不丟不重；
• 安全、可靠：確保數據訪問和數據存儲的安全性，支持集群災備，數據高可靠；

?基于以上目標，進行了深入的調研，在對比了多種大數據組件后，選擇引入Doris 來構建新一代實時數據倉庫架構。

三、實時數倉構建

? ?在架構的迭代過程中，一方面需要務必保證業務無縫運轉、避免系統切換造成業務體驗受影響，另一方面需要兼顧與舊有架構的兼容、根據實際情況逐步迭代、漸進式調整，同時也希望充分發揮全新架構的能力優勢，因此建設路徑逐步明晰：

• 引入實時數據處理和分析鏈路，提升數據時效性
• 推動數據應用從離線遷至實時，并持續提升查詢分析效率，為業務提效；
• 打通離線與實時數據鏈路的屏障，統一數據口徑和數據服務出口，提供一致性的數據服務體驗

? ?因此在新的架構中，在原有離線數據倉庫體系中增加了一條實時鏈路，通過kafka將mysql等各類業務數據庫中的實時數據歸集并傳輸到Doris中，并利用Flink和?Doris SQL 對數據進行加工處理。在Doris內部構建了從ODS到ADS的數倉分層體系，同時基于Doris提供的Multi-Catalog（多源數據目錄）能力打通對Hive數據的查詢，避免了繁重的數據遷移成本。各上層數據應用統一對接 Doris 即可，無需在離線數據和實時數據間進行切換，由Doris 統一對外提供查詢服務。

? ?這一升級，極大提升了數據處理的效率和查詢的便捷性，當前我們正逐步推進離線數倉向以 Doris為核心的實時數倉遷移，為更高效和更大規模的數據管理和分析做好準備。

? ? 接下來將介紹基于Doris的實時數倉架構的規劃與設計，將從數據模型、分桶策略、數據同步與加工方式出現，分享實時架構搭建的實踐經驗。

四、實時數倉體系的建設與實踐

? ? 在建設數據倉庫體系時，銀聯商務遵循邊治理、邊建設、邊賦能的原則，數據治理為關鍵一環，而統一規劃又是其核心內容。因此數據倉庫的統一規劃能夠確保數據倉庫結構設計的合理性，不僅有利于后續對架構的管理維護，也有利于對數據可靠性和一致性的保障。因此我們在數據倉庫統一規劃方面采取了以下措施：

4.1?數倉分層的合理規劃

? 合理的數倉分層對數據的管理以及查詢性能的充分發揮起著關鍵作用，基于Doris豐富的數據模型，對數倉的分層進行了提前規劃。Doris 數據模型有：

• Duplicate Key明細模型：適用于明細數據查詢場景，可支持任何唯獨的即席查詢
• Unique Key更新模型：適用于對數據唯一約束的場景，需要支持數據的精準去重，或者有數據更新需求，可支持大寬表的多流upsert和部分列的更新；
• Aggregate Key聚合模型：適用于報表查詢場景，通過數據的預聚合來加速報表分析

? ? 結合實際應用場景和數據模型，介紹銀聯商務數倉分層策略：

• ODS層主要采用明細模型，例如在交易清算場景中，銀聯商務每天有幾千萬的清算數據需處理，清算日期跨度長達一年，這就要求所有數據能被完整存儲。為了滿足這一需求，在ODS層選擇Duplicate Key明細模型，完全按照導入文件中的明細數據進行存儲，沒有任何聚合操作。而部分商戶訂單數據涉及到訂單狀態的更新，因此采取Unique Key更新模型，在數據導入過程中如果商戶id以及訂單id相同時自定更新成最新狀態。
• DWD與DWS層所采取的數據模型基本相同，其本質差異在于對業務數據的抽象程度，主要采用的是Unique Key更新模型，而部分有明細數據存儲的場景還保留了Duplicate Key明細模型。以結算劃付場景為例，將結算日期作為分區字段，表模型為 Unique Key 模型，通過這種方式能夠實現跨度長達一年結算數據狀態的自動更新。
• ADS層作為高度業務數據的抽象，采用了Aggregate Key聚合模型，通過對所有結算數據進預聚合，可大幅度提高數據查詢和分析的效率，減少實時計算的壓力。

4.2?分桶分區策略的合理設置

? ?分區分桶是優化數據存儲和提升查詢效率的重要手段，合理設置分桶數和分桶字段可以有效提升查詢速度和數據加工腳本的執行效率。在數倉應用中，我們參考實際數據規模和官網的設置建議，會對每一張表均規劃了分桶字段和分桶數。例如，在分店寬表中經常需要查詢分店維度數據，因此我們將分店作為分桶字段，并根據表的大小設置分桶數。以下是我們在不同數據分片Tablet下Bucket設置的數據，可供參考：

4.3?多源數據遷移方案

? ??在銀聯商務各分支機構數據遷移至 Doris 的過程中，發現分支機構本地系統采用的數據庫種類繁多，文件存儲格式也比較復雜，這給數據遷移工作帶來不小的挑戰。為確保數據遷移的順序進行，我們針對不用數據和文件格式制定了相應的遷移方案。

? ?Doris支持多種豐富的數據遷移方式，無論是離線數據同步還是實時數據同步，都能找到高效快捷的數據遷移方式：

• 在實時場景中，使用Flink CDC方式實時獲取MySQL Binlog， 其中一部分數據直接通過Flink CDC直接寫入Doris，另一部分高流量數據則先同步至Kafka中進行削峰填谷，再經由?Flink-Doris-Connector連接器寫入到?Doris中
• 在離線場景中，數據來源更加多樣，并且文件格式更加復雜，因此采用了多種方式進行數據遷移。對于S3和 HDFS上的歷史數據及增量數據，使用Broker Load進行批量導入；對于Hive及 JDBC 外表存儲的數據，使用?Insert into 方式進行同步；對于文件格式的數據，使用Flink Ftp Connector 和 Flink Doris Connector同步（因 Ftp 方式在銀聯商務內部是跨系統的數據文件交互方式，文件的格式復雜，因此開發了 Flink Ftp Connector，可支持復雜的數據格式、支持多換行符等復雜應用場景）。

? ? ?豐富的數據遷移方式使得我們可以輕松地將數據從各類數據庫遷移至 Doris 中來，同時，多文件格式的同步解決了分支機構數據不統一、不規范的問題，大大降低了各分支機構數據遷移的難度及成本，為銀聯商務的數據整合和統一管理提供了有力支持。

4.4?全量與增量數據的同步

? ?在大量離線數據同步的過程中，業務連續性和數據的準確性保證十分重要，因此我們采取了兩種方式來應對全量數據同步和增量數據同步。

? ? ?在全量同步場景中，我們首先創建相同表結構的臨時表，將全量數據導入臨時表后、再利用?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.5?離線數據加工任務遷移

? ? 當前我們已經把離線數倉的數據加工任務直接遷移到Doris進行，采取Doris SQL 進行數據加工處理，通過調度平臺進行任務調度。

? ?以清分流水交易寬表場景為例，過去每天需加工三千萬條數據，在Hive離線數倉采用的TEZ計算引擎進行數據加工，在分配2T的計算資源下，整條鏈路加工耗時長達2.5小時。當將數據加工任務遷移至Doris后，僅使用過去一半的計算資源，即可將整條鏈路加工耗時縮短為0.5小時，整條鏈路執行效率提升 5 倍以上，且單個腳本執行時效也從 8 分鐘提升到 10 秒。

五、金融級數倉穩定性最佳實踐

? ? 當前Doris 在銀聯商務已廣泛應用于多個業務場景，服務內部各類經營分析報表、用戶標簽、自助取數平臺等應用，并對外部商戶提供了對賬單、報表、數據報告等多種數據服務，因此集群的穩定性和可用性對于平臺用戶體驗和業務連續性而言至關重要，任何集群故障或不穩定因素都可能導致業務決策受阻、用戶信任度受影響。

5.1 多租戶資源隔離

? ? ?在實際業務運行過程中，往往存在多個業務或者不同部門同時查詢同一份數據的情況發生，在有限的資源條件下往往可能因查詢任務件的資源搶占導致查詢性能下降甚至集群不穩定，同時針對組織架構的不同層級對于數據的可見性要求也不一致，因此我們結合自身業務類型以及Doris 多租戶資源隔離能力進行了深度應用。

5.1.1?單查詢資源限制，保證查詢間資源可控

? ??在對內部多個應用進行梳理后，我們根據業務分析負載對場景和租戶進行了細分，主要劃分為數據加工（ETL）、數據探索（Ad-hoc）、數據看板（Reporting）和數據服務（Data Serving）四個場景。為確保各個場景及租戶之間的獨立性，我們對每個場景的單查詢進行了資源限制。具體而言，對每個租戶設置了四類Doris賬號，并對賬號的CPU和內存使用資源進行了限制，初始值統一設置為5 CPU，后續則根據使用情況進行微調，以達到適配的資源分配。目前銀聯商務各場景分配情況如下：

?該策略的優點在于，即使單個租戶的資源使用量增加，也只會影響該租戶在特定場景下的使用 ，不會對其他租戶，其他場景產生任何影響，有效提升了平臺的穩定性。

5.1.2?基于Resource Tag的多租戶數據與查詢隔離

? 而面對總-分公司的數據使用場景，我們采用了基于Resource Tag的資源組物理隔離方式，以確保數據的安全性和獨立性。

? ? 目前在Doris 中存儲了豐富多樣的數據，基于數據安全的角度考慮，對數據可見范圍進行了精細劃分，總公司可以訪問到公司層的全部數據，而分公司只能訪問自身業務范疇內的數據。除此以外，還有部分數據是由總公司授權分公司進行查詢，或者分公司個性化數據需要與總公司數據進行關聯。在這一場景之下，我們采取了Resource Tag的資源隔離模式，將數據和集群可用資源單獨劃分開來。

? ? 具體而言，我們為分公司配置獨立的資源組，將分公司個性化數據以三副本的方式存儲到獨立資源組中，同時將總公司數據設置為四副本，將其中三副本存儲在總公司資源組中，剩余單副本存儲到分公司獨立資源組中。當分公司查詢總公司數據時，僅會查詢分公司資源組中的單副本數據，通過這樣的方式即保證了數據的安全性，也提高了系統的穩定性及可靠性。具體方案如下：

• 設置 BE 節點標簽：分配總公司資源組和分公司資源組，并在服務器上設置對應標簽。

• 設置數據分布：建表時設置?replication_allocation?，同時將總分公司比例設置為 3:1，該比例可結合總分公司的實際使用情況靈活調整。

• 設置用戶資源組：為用戶設置對應的默認資源組，總、分公司使用各自資源組，從而實現總分公司查詢隔離。

5.1.3 更靈活的資源隔離方案

? ??基于 Resource Tag 的資源隔離方案實現的是物理層級的資源隔離，盡管在獨立性方面更佳、但在資源的利用率方面還存在一定的優化空間，并且無法保證進程內更細粒度的資源隔離，因此 Doris 在 2.0 版本中推出了 Workload Group資源軟限制。( Workload Group可限制組內任務在單個BE節點上的計算資源和內存資源的使用)

WORKLOAD GROUP - Apache Doris

? 從實現原理來看， Workload Group 通過對工作負載分組管理，將用戶執行的 Query 與 Workload Group 相關聯，可限制單個Query在BE節點上的CPU 和內存資源的百分比，并可以配置開啟資源組的內存軟限制。當集群資源緊張時，可自動終止哪些內存占用較大的查詢任務以緩解集群壓力。當集群資源空閑時，Workload Group使用資源超過預設值時，其他 Workload Group 可以共享空閑集群資源，并自動突破闕值、確保查詢任務的穩定執行，通過這一方式實現內存和 CPU 資源的精細化管控。

? ? 我們也在持續探索新版本特性與業務的結合，后續對于數據加工、數據探索、數據看板和數據服務等場景的單查詢資源限制可以通過 Workload Group 來實現，并且還可以進一步利用任務優先級和任務排隊機制來保證關鍵業務的優先運轉。

5.2 精細用戶權限管理

??為了滿足業務需求和法規合規的要求，銀聯商務建立了嚴格的用戶權限管理制度。該制度明確了不同用戶群體的角色和權限，確保了用戶只能訪問其需要的功能和數據。以下為銀聯商務用戶權限管理的方案：

• 用戶權限設置：針對每個分支機構不同場景的不同用戶，為用戶設置不同的數據使用權限。

• 庫、表、行級權限管理：為滿足各分公司權限管理需求，一般會為每個分公司建立視圖，該方式操作繁瑣，且與 Hive 數倉的使用有較大差異，可能需要對表、語句進行修改。通過?ROW POLICY機制可以便捷實現庫、表、行級的權限控制，并可以將原來 Hive 數倉的任務較為無縫地遷移到 Doris 中。

• 列級權限管理：當前采用構建視圖的方式進行列級權限管理。

5.3 集群穩定性保障

5.3.1 SQL熔斷

? 平臺對內部用戶開放后，經常會面臨用戶查詢SQL不規范消耗過多資源的情況，針對這種情況，采用SQL熔斷機制對高危SQL及時熔斷，以保證集群的穩定運行

5.3.2 導入并發控制

? ?考慮經常需將歷史數據同步到平臺中，這就會涉及大量數據修改任務，可能對集群會造成比較大的壓力。因此使用了?Unique Key 模型的 Merge-on-Write 更新模式、啟動了Vertical Compaction 和 Segment Compaction 并通過調整 Compaction合并參數調整，以控制數據導入頻率，減輕集群的 壓力。

5.3.3? 網絡流量控制

??針對離線、實時不同場景設置了 QoS ，通過 QoS 策略進一步實現網絡隔離。考慮到銀聯商務內部有上海和武漢兩套集群，異地網絡交互過程中的流量至關重要，因此，我們通過 QoS 策略來實現了精確的網絡隔離操作，確保不同場景下的網絡服務質量與穩定性。

5.3.4? 監控報警

?為滿足公司內部夜班值班監控的要求，我們使用 Doris 與內部監控報警平臺進行對接。將Doris 相關的監控報警與聲光監控、CU 即時通訊軟件以及郵件進行了對接，實現了對問題的實時監控和處理。

5.4?基于 CCR 的集群災備能力

? 對于金融企業而言，服務穩定性和數據安全性是至關重要的一環，而災備方案是確保業務連續性和數據安全性的重要措施，通過集群災備，能夠在災難或故障發生時迅速恢復業務和數據，最大程度地減少損失和風險。

??對于銀聯商務的核心業務數據，我們期望能夠實現跨集群異地的災備，因此我們基于跨集群數據復制能力，構架主備集群的雙活方案。正常業務查詢訪問的是主集群，關鍵業務數據會同時寫入至備用集群且保持實時更新，這樣即使某個集群發生宕機事件，也可以迅速切換至備用集群，以快速恢復核心業務和數據。

六、總結與規劃

? ? 截至目前 Doris已經服務了經營分析報表、用戶標簽、自助取數等多個內部業務以及對外商戶數據服務場景。

? ? ?僅以對賬單查詢場景為例，在半年對賬單場景下數據查詢時效從 8 分鐘降低到 3 秒，提速超 100 倍，在全年對賬單查詢中耗時也縮短至 2 分鐘內，多數典型查詢場景性能提升了 10- 15 倍，整體查詢分析效率得到極大幅度提升。此外，數據導入性能平均提升了 2- 5 倍，數據處理加工速度效率提升了 3- 12 倍，數據應用的時效性得到大幅增強。

? ?未來，還將繼續深入使用? Doris ，并在以下三個方面進行探索和實踐：

• 統一查詢引擎：將Doris作為聯邦查詢的統一出口，通過Multi-Catalog（多源目錄） 接入底層各數據源。同時將Doris完全作為對外服務的統一出口，實現數據查詢服務的統一路由，為用戶提供更便捷、更高效的數據查詢服務。
• 存算分離架構：進一步探索存算分離架構，實現資源的彈性擴縮容，并將離線數倉任務全部遷移到Doris中，實現實時化改造以及計算負載的進一步隔離
• 自動化運維：對接公司內部的業務流程，實現相關工作的自動化運維處理，并完成業務問題的快速排查；基于 Doris 實現更靈活的數據血緣分析，幫助銀聯商務更好地理解數據之間的關系和影響

參考文章：

銀聯商務：Apache Doris 賦能“科技銀商”，助力金融機構挖掘增長新機遇