導讀：在長期服務廣大規模商戶的過程中，銀聯商務已沉淀了龐大、真實、優質的數據資產數據，這些數據不僅是銀聯商務開啟新增長曲線的基礎，更是進一步服務好商戶的關鍵支撐。為更好提供數據服務，銀聯商務實現了從 Hadoop 到 Apache Doris 的架構升級，使數據導入性能提升 2-5 倍、ETL 場景性能提升 3-12 倍、查詢分析響應速度提升 10-15 倍，滿足大規模數據導入和實時極速查詢的業務需求，解決了業務和數據快速增長問題，提升了數據應用構建的效率，充分助力業務提效與數字資產的服務化，推進數字化進程的落地，展示了 Apache Doris 在推動金融科技創新方面的巨大潛力。
銀聯商務是國內大型的非銀行支付機構，提供以銀行卡收單、網絡支付為基礎的綜合支付服務，以及多樣化和專業化的商戶增值和科技創新服務，始終致力于為商戶、合作伙伴及消費者構筑普惠、便捷、高效、安全的支付環境。截至 2023 年 12月，銀聯商務已累計服務大中型、知名企業在內的各類商戶超過 2500 萬家，累計鋪設終端超 4000 萬臺，實體服務網絡覆蓋中國大陸所有地級以上城市及港澳地區，收單交易筆數連續十年蟬聯尼爾森亞太地區收單機構榜首。
如今，數據已經成為了推動經濟增長的新動力，數字技術正在成為社會發展的重要引擎。隨著數字經濟的迅猛發展，金融企業紛紛加大在金融科技領域的投入，以提升自身的數字化運營能力，加速數字化轉型的進程。在這一背景之下，銀聯商務以 “全量打通、準確實時、隨需自助、智能交互” 為數字化轉型目標，加快推進數字基礎設施建設。
在長期服務廣大規模商戶的過程中，銀聯商務已沉淀了龐大、真實、優質的數據資產數據，這些數據不僅是銀聯商務開啟新增長曲線的基礎，更是進一步服務好商戶的關鍵支撐。為了實現數據資產可管理、可視化、可賦能的建設目標，銀聯商務早在 2015 年就基于 Hadoop 體系構建了大數據平臺，為公司及商戶提供了數據支持。但隨著業務的不斷擴展，銀聯商務總公司各部門和分子公司對于數據應用的建設需求不斷涌現，早期基于 Hadoop 的大數據平臺已無法高效支撐拓展性、時效性與便捷性的業務需求，因此數據平臺的迭代升級勢在必行。
2020 年起，銀聯商務開啟了數據平臺的升級之旅，基于 Apache Doris 構建了新一代實時數據倉庫架構，使數據導入性能提升 2-5 倍、ETL 場景性能提升 3-12 倍、查詢分析響應速度提升 10-15 倍，滿足大規模數據導入和實時極速查詢的業務需求，解決了業務和數據快速增長問題，提升了數據應用構建的效率，充分助力業務提效與數字資產的服務化，推進數字化進程的落地。
應用場景
在長期為各行各業的海量商戶提供服務的過程中，銀聯商務沉淀了大量的交易數據、用戶數據、終端數據以及經營數據等。通過對這些數據的挖掘和利用，為銀聯商務總、分、子公司以及商戶提供多元化的數據服務，可以發掘隱藏在其中的價值和消費趨勢，成為掌握經營掌控、進行經營決策的有效工具。典型數據服務場景包括：
- 經營分析場景：建設指標體系和駕駛艙，幫助業務方及管理者實時了解整體業務經營狀態。
- 業務運營場景：建設標簽體系，更好理解用戶畫像及需求，從而提供精準的產品和業務服務。
- 數據分析和挖掘場景：構建自助分析和報表服務，更好地了解自己的業務情況并做出科學決策。
- 對外數據服務場景：構建對賬單、報表和數據報告服務，以幫助商戶更好地了解市場需求。
為滿足上述場景需求，銀聯商務早在 2015 年就引入了 Hadoop 體系構建了大數據平臺，并基于 Hive 構建了離線數倉。該架構整合了來自 MySQL、Oracle、MongoDB 等多業務系統的數據，按照 T+ 1 的時效性歸集到 Hive 離線數倉中，經由 Hive 數倉各層的加工處理后分別同步至不同組件中提供數據查詢服務，包括基于 Kylin 與 HBase 構建 Cube 進行指標查詢分析，并使用 HBase 進行增量數據的質量監測，同時還將處理完畢的數據同步到 Oracle 中提供業務數據查詢。
該架構各組件各司其職、整體架構清晰，在早期承載了業務對于數據查詢服務的需求。在移動支付快速席卷的浪潮下，支付場景更加多元化，銀聯商務業務規模穩步增長、總部及分子公司對于數據應用的建設需求不斷涌現，而傳統的大數據平臺已經無法高效支撐業務和數據的不斷增長，痛點逐步展現出來：
- 數據時效性：整體數據處理鏈路較長，大規模數據導入和加工處理的效率低，最新業務數據從生產到應用的時間間隔太長，無法充分發揮實時數據的價值；
- 查詢效率低：Kylin 早期承擔了大多指標查詢分析的需求，隨著業務量增長、數據預處理的成本越來越高、無法支持靈活快速的分析訴求，而 Hive 在應對復雜查詢時性能不足、只能依賴于堆加機器，這無疑大大增加了硬件資源成本；
- 運維成本和可擴展性：整體架構涉及多個組件，運維工作量較大，在應對業務需求增長的過程中可擴展性不足，無法敏捷響應數據的快速增長和數據應用快速上線的要求。
目標及選型
面向各行各業的數千萬商戶、行業特點和實際需求各不相同，在對企業內部眾多平臺系統以及對客戶提供的產品進行全面梳理后，銀聯商務確定了數字化轉型要實現的核心目標——“全量打通、準確實時、隨需自助、智能交互”。
具體而言，“全量打通”即各平臺間充分互通、數據融合共享，便于更全面掌握數據主題的全方位信息、充分發揮數據的協同效應；“準確實時”即充分發揮數據的實時價值，并根據技術手段保證數據又“快”又“準”，為后續分析打好堅實基礎；“隨需自取”即提供自助式的服務，靈活組合、按需取用，甚至實現量身定制、因客而變；“智能交互”即充分利用技術手段，從被動式的接受服務，變成主動式的能力輸出，提供分析、預測、輔助決策等智能服務，響應用戶需求、實現雙向交互。
而具體到數據服務層面，在為內外部客戶提供數據服務的過程中，銀聯商務注意到用戶對數據分析的性能、分析模式的靈活性、數據服務的穩定性以及數據應用的時效性有著更高的期望，因此我們決定對現有架構升級，旨在滿足新的業務訴求、解決早期架構存在的問題，于是在 2020 年正式啟動了銀聯商務數據架構的升級之旅，升級目標主要包含幾方面：
- 統一、簡潔：單一系統即可完成數據加工和服務的統一，以簡化數據處理流程，提高工作效率；
- 穩定、高效：支持高效的數據加工和高性能的數據查詢，同時系統和平臺的穩定性得以充分的保證；
- 準確、實時：支持數據實時更新以及接入，保證數據準確、不丟不重；
- 安全、可靠：確保數據訪問和數據存儲的安全性，支持集群災備、數據高可靠；
基于以上目標，我們進行了深入的調研，在對比了多種大數據組件后，選擇引入 Apache Doris 來構建新一代實時數據倉庫架構。
基于 Apache Doris 的新一代實時數倉架構
在架構的迭代過程中，一方面我們需要務必保證業務無縫運轉、避免系統切換造成業務體驗受影響，另一方面需要兼顧與舊有架構的兼容、根據實際情況逐步迭代、漸進式調整，同時也希望充分發揮全新架構的能力優勢，因此建設路徑逐步明晰：
- 引入實時數據處理和分析鏈路，提升數據時效性；
- 推動數據應用從離線遷至實時，并持續提升查詢分析效率，為業務提效；
- 打通離線與實時數據鏈路的屏障，統一數據口徑和數據服務出口，提供一致性的數據服務體驗；
因此在新的架構中，在原有離線數據倉庫體系中增加了一條實時鏈路，通過 Kafka 將 MySQL 等各類業務數據庫中的實時數據歸集并傳輸到 Apache Doris 中，并利用 Flink 和 Doris SQL 對數據進行加工處理，在 Doris 內部構建了從 ODS 到 ADS 的數倉分層體系。同時基于 Doris 提供的 Multi-Catalog 能力打通對 Hive 數據的查詢，避免了繁重的數據遷移成本。各上層數據應用統一對接 Doris 即可，無需在離線數據和實時數據間進行切換，由 Doris 統一對外提供查詢服務。
這一升級，極大提升了數據處理的效率和查詢的便捷性，當前我們正逐步推進離線數倉向以 Apache Doris 為核心的實時數倉遷移，為更高效和更大規模的數據管理和分析做好準備。
接下來我們將介紹基于 Apache Doris 的實時數倉架構的規劃與設計，我們將從數據模型、分桶策略、數據同步與加工方式出發，分享實時架構搭建的實踐經驗。
實時數據倉庫體系的建設與實踐
在建設數據倉庫體系時，銀聯商務遵循邊治理、邊建設、邊賦能的原則，數據治理為關鍵一環，而統一規劃又是其核心內容。因此數據倉庫的統一規劃能夠確保數據倉庫結構設計的合理性，不僅有利于后續對架構的管理維護，也有利于對數據可靠性和一致性的保障。因此我們在數據倉庫統一規劃方面采取了以下措施：
數倉分層的合理規劃
合理的數倉分層對數據的管理以及查詢性能的充分發揮起著關鍵作用，基于 Apache Doris 豐富的數據模型，我們對數倉的分層進行了提前規劃。先來了解 Doris 數據模型都具備哪些特性：
- Duplicate Key 模型：適用于明細數據查詢場景，可支持任何維度的即席查詢；
- Unique Key 模型：適用于對數據有唯一性約束的場景、需要支持數據精確去重，或者有數據更新需求、可支持大寬表的多流 Upsert 和部分列更新；
- Aggregate Key 模型：適用于報表查詢場景，通過數據的預聚合來加速報表分析。
結合實際應用場景和數據模型，我們來介紹銀聯商務數倉分層策略：
- ODS 層主要采用 Duplicate Key 模型，例如在交易清算場景中，銀聯商務每天有幾千萬的清算數據需處理，清算日期跨度長達一年，這就要求所有數據能被完整地存儲。為了滿足這一需求，我們在 ODS 層選擇 Duplicate Key 模型，完全按照導入文件中的明細數據進行存儲，沒有任何聚合操作。而部分商戶訂單數據涉及到訂單狀態的更新，因此采取 Unique Key 模型，在數據導入過程中如果商戶 id 以及訂單 id 相同時自動更新成最新狀態。
- DWD 與 DWS 層所采取的數據模型基本相同，其本質差異在于對于業務數據的抽象程度，主要采用的是 Unique Key 模型，而部分有明細數據存儲的場景還保留了 Duplicate Key 模型。以結算劃付場景為例，將結算日期作為分區字段，設置表模型為 Unique Key 模型，通過這種方式能夠實現跨度長達一年結算數據狀態的自動更新。
- ADS 層作為高度業務數據的抽象，采用了 Aggregate Key 模型，通過對所有結算數據進行預聚合，可大幅提高數據查詢和分析的效率，減少實時計算的壓力。
分桶分區策略的合理設置
分區分桶是優化數據存儲和提升查詢效率的重要手段，合理設置分桶數和分桶字段可以有效提升查詢速度和數據加工腳本的執行效率。在數倉應用中，我們參考實際數據規模和官網的設置建議，會對每一張表均規劃了分桶字段和分桶數。例如，在分店寬表中經常需要查詢分店維度數據，因此我們將分店作為分桶字段，并根據表的大小設置分桶數。以下是我們在不同 Tablet 下 Bucket 設置的數量，可供參考：
多源數據遷移方案
在銀聯商務各分支機構數據遷移至 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 中來，同時，多文件格式的同步解決了分支機構數據不統一、不規范的問題，大大降低了各分支機構數據遷移的難度及成本，為銀聯商務的數據整合和統一管理提供了有力支持。
全量與增量數據的同步
在大量離線數據同步的過程中，業務的連續性和數據的準確性保證十分重要，因此我們采取了兩種方式來應對全量數據同步和增量數據同步。
在全量同步場景中，我們首先創建相同表結構的臨時表，將全量數據導入臨時表后、再利用 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} ...
離線數據加工任務遷移
當前我們已經把離線數倉的數據加工任務直接遷移到 Doris 進行，采用 Doris SQL 進行數據加工處理，通過調度平臺進行任務調度。
以清分流水交易寬表場景為例，過去每天需加工三千萬條數據、在 Hive 離線數倉采用的 TEZ 計算引擎進行數據加工，在分配 2T 的計算資源下，整條鏈路加工耗時長達 2.5 小時。當將數據加工任務遷移至 Apache Doris 后，僅使用過去一半的計算資源，即可將整條鏈路加工耗時縮短為 0.5 小時，整條鏈路執行效率提升 5 倍以上，且單個腳本執行時效也從 8 分鐘提升到 10 秒。
金融級數倉穩定性最佳實踐
當前 Apache Doris 在銀聯商務已廣泛應用于多個業務場景，服務了內部各類經營分析報表、用戶標簽、自助取數平臺等應用，并對外部商戶提供了對賬單、報表、數據報告等多種數據服務，因此集群的穩定性和可用性對于平臺用戶體驗和業務連續性而言至關重要，任何集群故障或不穩定因素都可能導致業務決策受阻、用戶信任度受影響。
因此銀聯商務采取大量措施來保證集群穩定性和可用性，包括多租戶資源隔離、精細權限管理、集群災備以及多種穩定性調優策略。
多租戶資源隔離
在實際業務運行過程中，往往存在多個業務或者不同部門同時查詢同一份數據的情況發生，在有限的資源條件下往往可能因查詢任務件的資源搶占導致查詢性能下降甚至集群不穩定，同時針對組織架構的不同層級對于數據的可見性要求也不一致，因此我們結合自身業務類型以及 Apache Doris 多租戶資源隔離能力進行了深度應用。
單查詢資源限制，保證查詢間資源可控
在對內部多個應用進行梳理后，我們根據業務分析負載對場景和租戶進行了細分，主要劃分為數據加工（ETL）、數據探索（Ad-hoc）、數據看板（Reporting）和數據服務（Data Serving）四個場景。為確保各個場景及租戶之間的獨立性，我們對每個場景的單查詢進行了資源限制。具體來說，我們為每個租戶設置了四類 Doris 賬號，并對賬號的 CPU 和內存使用資源進行了限制，初始值統一設置為 5 CPU，后續則根據各租戶使用情況進行微調，以達到適配的資源分配。目前銀聯商務各場景分配情況如下：
該策略的優點在于，即使單個租戶的資源使用量增加，也只會影響該租戶在特定場景下的使用，不會對其他租戶、其他場景產生任何影響，有效提升了平臺的穩定性。
基于 Resource Tag 的多租戶數據與查詢隔離
而面對總-分公司的數據使用場景，我們采用了基于 Resource Tag 的資源組物理****隔離方式，以確保數據的安全性和獨立性。
目前在 Apache Doris 中存儲了豐富多樣的數據，基于數據安全的角度考慮，對數據可見范圍進行了精細劃分，總公司可以訪問到公司層的全部數據，而分公司只能訪問自身業務范疇內的數據。除此以外，還有部分數據是由總公司授權分公司進行查詢，或者分公司個性化數據需要與總公司數據進行關聯。在這一場景之下，我們采取了 Resource Tag 的資源隔離模式，將數據和集群可用資源單獨劃分開來。
具體而言，我們為分公司配置獨立的資源組，將分公司個性化數據以三副本的方式存儲到獨立資源組中，同時將總公司數據設置為四副本，將其中三副本存儲在總公司資源組中，剩余單副本存儲到分公司獨立資源組中。當分公司查詢總公司數據時，僅會查詢分公司資源組中的單副本數據，通過這樣的方式即保證了數據的安全性，也提高了系統的穩定性及可靠性。具體方案如下：
- 設置 BE 節點標簽：分配總公司資源組和分公司資源組，并在服務器上設置對應標簽。
- 設置數據分布：建表時設置
replication_allocation，同時將總分公司比例設置為 3:1，該比例可結合總分公司的實際使用情況靈活調整。 - 設置用戶資源組：為用戶設置對應的默認資源組，總、分公司使用各自資源組，從而實現總分公司查詢隔離。
更靈活的資源隔離方案
基于 Resource Tag 的資源隔離方案實現的是物理層級的資源隔離，盡管在獨立性方面更佳、但在資源的利用率方面還存在一定的優化空間，并且無法保證進程內更細粒度的資源隔離，因此 Apache Doris 在 2.0 版本中推出了 Workload Group 資源軟限制。
從實現原理來看， Workload Group 通過對工作負載分組管理，將用戶執行的 Query 與 Workload Group 相關聯，可限制單個 Query 在 BE 節點上的 CPU 和內存資源的百分比，并可以配置開啟資源組的內存軟限制。當集群資源緊張時，可自動終止內存占用較大的查詢任務以緩解集群壓力。當集群資源空閑時，當 Workload Group 使用資源超過預設值時，其他 Workload Group 可以共享空閑集群資源，并自動突破闕值、確保查詢任務的穩定執行，通過這一方式實現內存和 CPU 資源的精細化管控。
我們也在持續探索新版本特性與業務的結合，后續對于數據加工、數據探索、數據看板和數據服務等場景的單查詢資源限制可以通過 Workload Group 來實現，并且還可以進一步利用任務優先級和任務排隊機制來保證關鍵業務的優先運轉。
精細用戶權限管理
為了滿足業務需求和法規合規的要求，銀聯商務建立了嚴格的用戶權限管理制度。該制度明確了不同用戶群體的角色和權限，確保了用戶只能訪問其需要的功能和數據。以下為銀聯商務用戶權限管理的方案：
- 用戶權限設置：針對每個分支機構不同場景的不同用戶，為用戶設置不同的數據使用權限。
- 庫、表、行級權限管理：為滿足各分公司權限管理需求，一般會為每個分公司建立視圖，該方式操作繁瑣，且與 Hive 數倉的使用有較大差異，可能需要對表、語句進行修改。通過
ROW POLICY機制可以便捷實現庫、表、行級的權限控制，并可以將原來 Hive 數倉的任務較為無縫地遷移到 Doris 中。 - 列級權限管理：當前采用構建視圖的方式進行列級權限管理。
集群穩定性保障
- SQL 熔斷：平臺對內部用戶開放后，經常會面臨用戶查詢 SQL 不規范消耗過多資源的情況，針對于這種情況，采用 SQL 熔斷機制對高危的 SQL 及時熔斷，以保證集群的穩定運行。
- 導入并發控制：考慮我們經常需將歷史數據同步到平臺中，這就會涉及大量數據修改任務，可能對集群會造成比較大的壓力。因此，我們使用了 Unique Key 模型的 Merge-on-Write 更新模式、啟用了 Vertical Compaction 和 Segment Compaction 并通過調整 Compaction 參數調整，以控制數據導入頻率、減輕集群的壓力。
- 網絡流量控制：針對離線、實時不同場景設置了 QoS ，通過 QoS 策略進一步實現網絡隔離。考慮到銀聯商務內部有上海和武漢兩套集群，異地網絡交互過程中的流量至關重要，因此，我們通過 QoS 策略來實現了精確的網絡隔離操作，確保不同場景下的網絡服務質量與穩定性。
- 監控報警：為滿足公司內部夜班值班監控的要求，我們使用 Doris 與內部監控報警平臺進行對接。將 Doris 相關的監控報警與聲光監控、CU 即時通訊軟件以及郵件進行了對接，實現了對問題的實時監控和處理。
基于 CCR 的集群災備能力
對于金融企業而言，服務穩定性和數據安全性是至關重要的一環，而災備方案是確保業務連續性和數據安全性的重要措施，通過集群災備，能夠在災難或故障發生時迅速恢復業務和數據，最大程度地減少損失和風險。
對于銀聯商務的核心業務數據，我們期望能夠實現跨集群異地的災備，因此我們基于跨集群數據復制能力構建主備集群的雙活方案。正常業務查詢訪問的是主集群，關鍵業務數據會同步寫入至備用集群且保持實時更新，這樣即使某個集群發生宕機事件，也可以迅速切換到備用集群，以快速恢復核心業務和數據。
總結與規劃
面對日益增長的數據處理和分析需求，銀聯商務選擇基于 Apache Doris 構建新一代實時數據倉庫，截至目前 Apache Doris 已經服務了經營分析報表、用戶標簽、自助取數等多個內部業務以及對外商戶數據服務場景。
僅以對賬單查詢場景為例，在半年對賬單場景下數據查詢時效從 8 分鐘降低到 3 秒，提速超 100 倍，在全年對賬單查詢中耗時也縮短至 2 分鐘內，多數典型查詢場景性能提升了 10- 15 倍，整體查詢分析效率得到極大幅度提升。此外，數據導入性能平均提升了 2- 5 倍，數據處理加工速度效率提升了 3- 12 倍，數據應用的時效性得到大幅增強。
通過更高效、更實時、更靈活的數據分析支持，銀聯商務能夠更好地理解市場、把握機會、優化運營，從而實現業務的持續增長和創新發展。未來，銀聯商務還將繼續深入使用 Apache Doris ，并在以下三個方面進行探索和實踐：
- 統一查詢引擎：將 Doris 作為聯邦查詢的統一入口，通過 Multi-Catalog 接入底層各數據源。同時將 Doris 完全作為對外數據服務的統一出口，實現數據查詢服務的統一路由，為用戶提供更便捷、更高效的數據查詢服務。
- 存算分離架構：進一步探索存算分離架構、實現資源的彈性擴縮容，并將離線數倉任務全部遷移到 Doris 中，實現實時化改造以及計算負載的進一步隔離。
- 自動化運維：對接公司內部的業務流程，實現相關工作的自動化運維處理，并完成業務問題的快速排查；基于 Doris 實現更靈活的數據血緣分析，幫助銀聯商務更好地理解數據之間的關系和影響，為業務決策提供更準確的數據管理支持。
