《金融信息化研究所：金融業數據庫創新發展報告（2023）（135頁）.pdf》由會員分享，可在線閱讀，更多相關《金融信息化研究所：金融業數據庫創新發展報告（2023）（135頁）.pdf（135頁珍藏版）》請在三個皮匠報告上搜索。

1、 主主 任：任：潘潤紅 副主任：副主任：黃程林、莊文君 編委會成員編委會成員（排名不分先后，按姓氏拼音排序）（排名不分先后，按姓氏拼音排序）：蔡仕志、陳志剛、戴 濤、杜志明、方 興、馮 程、馮文忠、郭志軍、侯 敏、黃海明、李永海、馬波勇、馬曉煦、蘇光牛、王麗靜、王新明、王義成、隗 華、巫建剛、肖靜靜、邢 磊、徐曉劍、徐 翥、楊 陽、俞 楓、張俊喜、張 瑋、張曉強、趙 培 編寫組成員編寫組成員（排名不分先后，按姓氏拼音排序）（排名不分先后，按姓氏拼音排序）：白軍奎、鮑思佳、畢斕馨、曹平國、陳偉紅、程 靜、從平平、崔安頎、管文琦、郭 茁、何 格、黃晨晨、黃 韋、李 凱、李 倩、李瑞超、李文彬、李昕

2、哲、林 海、劉 暢、劉傳友、盧 強、駱君柱、駱 毅、呂偉初、蘇 強、隋東輝、孫存福、孫騰騰、孫 偉、唐思源、王 楓、王富國、王 輝、王鵬沖、王榮鑫、王帥強、王文清、王 栩、王 瑜、王子健、伍 華、夏文勇、肖淑男、嚴 恒、顏 龍、楊 銳、楊征濤、張俊成、張子鑒、趙義斌、周日明、鄒 鵬 主編單位：主編單位：北京金融信息化研究所 中國工商銀行股份有限公司 交通銀行股份有限公司 平安銀行股份有限公司 國泰君安證券股份有限公司 中國太平洋保險（集團）股份有限公司 泰康保險集團股份有限公司 華為云計算技術有限公司 中興通訊股份有限公司 武漢達夢數據庫股份有限公司 天津南大通用數據技術股份有限公司 騰訊云計

3、算(北京)有限責任公司 北京科藍軟件系統股份有限公司 參編單位：參編單位：中國農業銀行股份有限公司 中國銀行股份有限公司 中國建設銀行股份有限公司 中國郵政儲蓄銀行股份有限公司 中信銀行股份有限公司 招商銀行股份有限公司 華夏銀行股份有限公司 北京銀行股份有限公司 上海證券交易所 中信證券股份有限公司 華泰證券股份有限公司 國信證券股份有限公司 中國人壽保險股份有限公司 螞蟻科技集團股份有限公司 阿里云計算有限公司 北京東方國信科技股份有限公司 支持單位：支持單位：平凱星辰（北京）科技有限公司 I 2023 年 2 月，習近平總書記在中共中央政治局第三次集體學習會議時強調，“基礎軟件要從底層和

4、源頭抓起，打好科學儀器、操作系統和基礎軟件攻堅戰”。數據庫作為構建金融信息系統的關鍵環節，成為當前金融領域創新及數字化轉型的一個難點和焦點。近年來，金融機構不斷加大我國成熟數據庫產品應用力度，引入不同類型數據庫產品在多種業務場景實現應用，在支持金融業務創新發展的同時，逐步提升金融業數據庫安全可控能力。但由于我國數據庫產品還存在需要彌補的不足，隨著數據庫改造逐漸深入到核心系統，帶來了選型難度高、實施運維難度大等挑戰，亟需加大產用聯合攻堅、創新應用模式、研發生態工具，推動我國數據庫由“能用”向“好用、易用”邁進。同時，數據能力建設對數據倉庫、非關系型數據庫也提出了新需求，需要加大數據倉庫技術創新，

5、分類推動不同非關系型數據庫應用發展，促進產品成熟落地。此外，金融業大量采用了開源數據庫，面臨開源協議、安全漏洞、知識產權、代碼感染、開源停服斷供等風險，亟需通過加大開源數據庫治理、安全防范、建設行業開源社區等措施進行風險防范。本報告從行業應用情況入手，圍繞當前業界關注的金融核心系統數據庫應用、數據能力提升和開源數據庫風險防控三個領域，總結發展成效經驗，剖析問題與風險，提出發展建議，展望發展趨勢，為金融業數據庫創新發展提供參考借鑒。I 1.1.概述概述 .1 1 2.2.金融業數據庫應用現狀金融業數據庫應用現狀 .2 2 2.1 金融業數據庫應用總體情況.2 2.2 我國數據庫產品在金融業應用取

6、得積極成效.5 3.3.金融業數據庫應用重點領域分析金融業數據庫應用重點領域分析 .7 7 3.1 核心系統數據庫應用分析.7 3.1.1 核心系統對數據庫應用提出更為嚴格需求.8 3.1.2 當前核心系統數據庫應用面臨多重挑戰.9 3.1.3 圍繞關鍵環節推動核心系統數據庫轉型升級.11 3.2 數據庫支持數據能力建設分析.14 3.2.1 不同類型數據庫助力數據能力建設取得積極成效.14 3.2.2 金融業數字化快速發展對數據庫提出新需求.15 3.2.3 分類推動各類數據庫應用創新促進數據能力提升.17 3.3 開源數據庫應用風險分析.18 3.3.1 開源數據庫快速發展并在金融業得到廣

7、泛應用.19 3.3.2 金融業開源數據庫面臨諸多風險.20 3.3.3 多措并舉防范開源數據庫應用風險.23 4.4.金融業數據庫應用展望金融業數據庫應用展望 .2525 4.1 我國主流數據庫產品成熟度將進一步提升.25 4.2 金融核心系統數據庫轉型升級將穩步推進.26 4.3 新技術與業務場景將推動金融數據庫創新發展.26 4.4 金融業開源數據庫應用風險防范仍然不容忽視.27 附錄：金融業數據庫優秀應用案例集附錄：金融業數據庫優秀應用案例集 .2828 1 國家的戰略部署及金融科技發展相關的多個專項規劃，都對關鍵軟硬件信息技術的突破應用、構建自立自強的數字技術創新體系提出了明確目標和

8、要求。金融機構在數字化轉型創新發展中，紛紛加快了信息技術的迭代升級，不斷引入包括數據庫在內新的技術產品，并持續擴大應用廣度和深度，金融業信息技術供應鏈安全整體水平不斷提升。作為核心基礎軟件的數據庫，始終是金融業關注的焦點，也是難點。近年來，傳統集中式、新興分布式數據庫，關系型、非關系型數據庫，聯機事務處理型（OLTP）、聯機分析處理型（OLAP）、混合負載型（HTAP）數據庫，商用數據庫、開源數據庫等在不同業務場景中實現創新應用，推動構建新一代金融 IT 基礎設施，在確保安全穩定的同時，有力支持金融業務創新發展。特別是我國成熟的數據庫技術產品在金融業實現了廣泛應用，并逐步推動在核心系統應用落地

9、，取得顯著成效。但金融業數據庫應用還面臨一些挑戰。一是隨著我國數據庫產品應用向核心系統深入，其性能、功能及穩定性與國際商用主流數據庫產品還存在一定差距，尚不能完全滿足金融業核心系統應用需求；二是數據倉庫、非關系型數據庫對金融業數據能力建設有著重要作用，隨著金融業數字化轉型深入推進，對非關系型數據庫的需求越來越多，對數據倉庫功能、性能、擴展性和安全 2 性提出更高要求，亟需提升產品能力滿足金融業應用需求；三是開源數據庫在金融業應用廣泛，但存在開源協議、安全漏洞、知識產權、代碼感染、開源停服斷供、政策不確定性、掌控及服務能力不足等諸多風險。為推動金融數據庫創新發展，以應對面臨的挑戰和問題，金融信息

10、化研究所組織各方力量，在深入調研、交流研討基礎上，編制金融業數據庫創新發展報告（2023），對金融業數據庫技術應用進行現狀梳理、問題分析、建言獻策及成果展示，為管理決策提供參考，為金融機構創新發展提供支持，為我國數據庫產業發展提供助力，促進金融科技穩步發展和金融數字化轉型深入推進。金融業始終走在 IT 技術應用和發展變革的前列，根據創新發展和安全可控的需要，金融機構普遍采取“先外圍、后核心”的策略推進我國數據庫產品的應用落地。隨著多種類型的數據庫產品在金融領域加快應用，促進了金融業務創新，同時也有力支持了我國數據庫產業的發展。2.12.1 金融業數據庫應用總體情況金融業數據庫應用總體情況 一是

11、集中式數據庫應用占比較高，分布式數據庫應用呈現增一是集中式數據庫應用占比較高，分布式數據庫應用呈現增長趨勢。長趨勢。從產品架構看，金融業數據庫呈現集中式和分布式并存發展態勢。其中，集中式數據庫以其較強的功能黏性、優秀的系 3 統穩定性、良好的軟硬適配能力，目前在金融業的應用仍占據絕大多數份額。但隨著金融業數字化轉型的不斷深入，分布式數據庫因具備依托通用硬件、彈性擴展、內臵高可用等特征，可更有效支持海量、高并發、高吞吐量的新型金融業務應用系統，在金融業的應用占比相較 2022 年調研結果實現了 5.76%的增長。二是二是 OLTPOLTP 數據數據庫應用占比較高，庫應用占比較高，OLAPOLAP

12、 和和 HTAPHTAP 應用需求不應用需求不斷增加。斷增加。金融業務系統的數據處理分為聯機事務處理（OLTP）和聯機分析處理（OLAP）兩類。面向客戶交易類、業務辦理等系統通常選擇 OLTP 類數據庫，而報表類、分析類系統通常選擇 OLAP類數據庫。隨著金融業數字化進程加快，海量數據讓 OLTP 和 OLAP數據庫的邊界越來越模糊并不斷融合，在同一個系統中同時需要OLTP 和 OLAP 能力，即 HTAP 數據庫的需求越來越多。通常 HTAP主要應用分為以 OLTP 為主或以 OLAP 為主的兩種 HTAP 場景。目前在金融業非融合的 OLTP 數據庫占比仍然較高，為 76.83%。同時，不

13、同細分行業中，銀行業和證券業應用 OLAP 和 HTAP 數據庫占比相對較高。詳細情況如圖 1 所示。4 數據來源：金融信息化研究所 圖 1 金融業 OLTP、OLAP、HTAP 數據庫占比情況示意圖 三是非關系型數據庫在金融業加快探索實踐。三是非關系型數據庫在金融業加快探索實踐。金融業具有客戶量大、業務場景復雜等特點，需要存儲處理多種類型數據，如龐大的用戶、賬戶、交易、清算、產品、行情等結構化數據和海量的圖像、視頻、語音等非結構化數據。金融業務需要挖掘海量基礎數據所蘊含的豐富信息資源，如隱藏的用戶偏好、消費習慣、交易習慣、社會關系等，為非關系型數據庫提供了豐富的應用場景，加快了非關系型數據庫

14、創新應用。目前，非關系型數據庫在金融業應用占比已達到 14.58%。相對證券業和保險業，銀行業應用非關系型數據庫占比較高。另外，非關系型數據庫中鍵值數據庫和文檔數據庫應用最廣泛，二者之和占所有非關系型數據庫比例超過 60%；圖數據庫、向量數據庫、時序數據庫開始探索應用，其中時序數據庫在證券業首先開始應用，占比為 4.8%。金融業非關系型數據庫應用占比情況如圖 2 所示。93.93%76.17%77.48%79.48%5.25%12.00%11.83%10.95%0.82%11.83%10.63%9.52%0.00%10.00%20.00%30.00%40.00%50.00%60.00%70.0

15、0%80.00%90.00%100.00%保險業 證券業 銀行業 金融業 OLTP、OLAP和和HTAP數據庫占比情況數據庫占比情況 OLTP數據庫占比 OLAP數據庫占比 HTAP數據庫占比 5 數據來源：金融信息化研究所 圖 2 金融業關系型、非關系型數據庫占比情況示意圖 四是開源數據庫在金融業得到廣泛應用。四是開源數據庫在金融業得到廣泛應用。與閉源商業數據庫相比，開源數據庫具有源碼公開、使用成本低、獲取途徑廣、對外開放、功能豐富等特點。這些優點使得開源軟件得到廣大開發人員的青睞，使用人員可在原有代碼基礎上進行業務適配修改，活躍的社區支持也為日益復雜的業務需求貢獻了越來越多的解決方案，從而

16、使得開源數據庫在金融業實現了廣泛應用。目前，約 90%的金融機構都應用了開源數據庫支撐業務發展，其中主要集中應用在一般業務系統和管理類系統。2.22.2 我國數據庫產品在金融業應用取得積極成效我國數據庫產品在金融業應用取得積極成效 一是我國數據庫產品在金融業應用穩妥推進、持續增長。一是我國數據庫產品在金融業應用穩妥推進、持續增長。金融業始終走在 IT 技術應用和發展變革的前列，根據創新發展和安全可控的需要，金融機構都在以不同的速度和深度嘗試應用我85.42%83.54%89.83%88.23%14.58%16.46%10.17%11.77%0.00%20.00%40.00%60.00%80.0

17、0%100.00%金融業 銀行業 證券業 保險業 關系型、非關系型數據庫占比情況關系型、非關系型數據庫占比情況 關系型數據庫占比 非關系型數據庫占比 6 國數據庫產品支持業務發展。為確保安全生產、順利實施，金融機構普遍采取“先外圍、后核心”的策略推進我國數據庫產品的應用落地，不斷拓展應用廣度和深度。調研顯示，與 2022 年相比，目前應用我國數據庫產品的金融機構數量占比增長約 10%，其中，證券業增幅明顯。二是我國數據庫在金融業應用優勢不斷顯現。二是我國數據庫在金融業應用優勢不斷顯現。金融業應用我國數據庫產品，可針對特殊業務場景采取定制化改造，增強業務系統的服務能力，加快業務系統的響應速度，提

18、升業務系統的吞吐量，本地化服務優勢明顯。同時，我國數據庫產品在金融業的應用，一定程度上降低了企業成本，實現了降本增效。相比國外數據庫高昂的購買費用和后續的技術服務成本，我國數據庫產品后續成本投入相對穩定、成本可控。三是金融業與數據庫產業互相促進、發展共贏的成效顯著。三是金融業與數據庫產業互相促進、發展共贏的成效顯著。金融機構在應用我國數據庫產品時持續進行產品能力測試，識別產品能力上的缺陷并不斷反饋給數據庫廠商，推動數據庫產品能力提升。而且金融業擁有豐富的業務場景，我國數據庫產品在大量的實踐應用以及上下游產業的共同發展中，整體數據庫能力、兼容性能力都有明顯提高。隨著我國數據庫產品成熟度的不斷提升

19、，加快推動了新一代金融 IT 基礎設施建設，不斷夯實金融業數字化創新發展的基石。7 隨著我國數據庫產品在金融業的不斷推廣應用，數據庫改造逐漸深入到核心系統，金融機構普遍認為我國數據庫產品在核心系統應用還有較大提升空間。當前，數字金融快速發展，數據倉庫和非關系型數據庫有力支持了金融機構開展數據挖掘和分析，推動數據能力建設，助力金融業務創新。另外，根據調研統計，約 90%的金融機構使用開源數據庫支撐業務發展，而開源數據庫應用面臨著開源停服、協議風險、安全漏洞等多方面的風險，且大部分金融機構僅具備開源數據庫的日常管理運維能力，僅少量大型金融機構具備代碼級維護及二次開發能力。為此，本章主要從業界關注的

20、核心系統數據庫應用、數據倉庫和非關系型數據庫支撐數據能力建設、開源數據庫應用三個重點方向，從深入應用、加大創新、防范風險三個視角來分析金融業數據庫應用需求、面臨的挑戰，并提出下一步發展建議。3.13.1 核心系統數據庫應用分析核心系統數據庫應用分析 核心系統被喻為金融機構 IT 建設皇冠上的明珠。因其高可用、高可靠，高并發、高實時、高擴展、高安全等特性鮮明，要求提供 7x24 小時不間斷服務能力，在信息系統中具有十分重要的地位，事關金融業務實現、金融安全穩定。因此，進行核心系統數據庫轉型升級牽一發而動全身，需要全面分析轉型需求、面臨的挑戰，總結經驗，推動轉型實施。8 3.1.13.1.1 核心

21、系統對數據庫應用提出更為嚴格需求核心系統對數據庫應用提出更為嚴格需求 一是功能方面，一是功能方面，核心系統新引入的數據庫除了支持傳統數據類型、對象類型、SQL 以及 PL/SQL 等基本功能外，特別需要在驅動、語法、架構等方面實現與現有國際主流數據庫的兼容。且核心系統需要與交易、結算、風控等不同系統進行無縫集成，所以，需要核心系統數據庫支持常用的數據接口和標準協議。同時，對于業務量大、性能要求高的核心系統，需要數據庫適配新一代分布式、共享存儲集群等架構體系。二是在性能方面，二是在性能方面，核心系統對性能的極致要求，需要數據庫具備極強的高并發、高速讀寫能力，以及滿足低延遲、強實時性要求，并具備靈

22、活的擴展性。核心系統數據庫交易處理能力需穩定支持 1 至 2 萬 TPS，峰值支持 2 至 4 萬 TPS。核心系統的 OLTP 場景要求數據庫響應時間能夠達到毫秒甚至亞毫秒級別，OLAP 場景要求數據庫響應時間能夠達到秒甚至毫秒級別。此外，在分布式場景下，對數據庫彈性擴展能力提出更高要求，實現自動在線橫向擴展，擴展后性能呈線性增加，無明顯損耗，且根據業務量的變化實現對數據庫資源的彈性擴/縮容，以應對業務快速增長和海量數據處理需求。三是魯棒性方面，三是魯棒性方面，核心系統數據庫需要具備穩定性、高可靠性和高可用性。在負載、數據量或者其它環境因素急劇變化時，核心系統數據庫依然能提供穩定的、可預期的

23、服務能力。核心系 9 統數據庫需要滿足金融核心業務對數據 100%可靠、99.999%以上的可用性極致要求。同時災備能力要求 RTO 為秒級，RPO 為 0，且要求核心系統數據庫能在線修復或者能自檢測并自愈，保證金融服務的實時性和連續性。四是安全方面，四是安全方面，核心系統的數據不僅包括業務數據，還涉及到客戶的敏感信息，其數據庫在安全方面要具備“3A+E”（認證：Authorization、授權：Authentication、審計：Audit、加密：Encryption)的能力。通過提供數據庫層的身份認證、訪問授權、行為審計，保證正確的人、在正確的時間、以正確的方式訪問正確的數據，并留下訪問痕

24、跡以供事后審計。隨著數據資產化進程的加快，越來越強調精細顆粒度的訪問授權。同時，為了防止數據泄露、失竊，多層次、多場景、基于商用密碼加密算法的支持，對于多層次、靈活顆粒度的數據脫敏、數據遮蔽的支持也必不可少。3.1.23.1.2 當前核心系統數據庫應用面臨多重挑戰當前核心系統數據庫應用面臨多重挑戰 一是我國數據庫產品在核心系統應用還存在多方面能力不一是我國數據庫產品在核心系統應用還存在多方面能力不足。足。與國際主流數據產品相比，我國數據庫產品在 SQL 優化器、全局事務管理、并發控制、列存和行列混存、共享集群、多讀多寫等多個關鍵核心技術上仍然需要打磨和進一步提升；在執行計劃、資源利用、任務并行

25、、算法、IO、存算分離等方面與國際商用主流數據庫產品仍有一定差距。關鍵技術能力欠缺不利于我國 10 數據庫產品在核心系統的順利落地應用。另外，核心系統數據庫需要有強大的技術支持服務體系，以及時解決運行過程中出現的問題，目前我國數據庫相對國際商用主流數據庫在該方面也存在不足。二是我國數據庫產品災備和數據同步水平還難以完全滿足二是我國數據庫產品災備和數據同步水平還難以完全滿足核心系統需求。核心系統需求。根據核心業務系統多活容災建設需求，我國數據庫產品在異地 RPO、故障切換和災難恢復時間等災備能力與核心系統要求還有一定距離。同時，在采用新舊系統并軌運行模式，確保核心系統轉型的平穩過渡，實現核心系統

26、異地容災，以及在核心系統數據庫作為周邊系統為數倉、數據中臺、客服系統等提供實時數據時，都需要進行數據同步，這些對數據庫的數據同步能力提出了很高要求。三是核心系統數據庫創新實施及運維管理難度大。三是核心系統數據庫創新實施及運維管理難度大。首先，由于核心系統安全穩定運行是金融機構安全生產的關鍵，在數據庫創新實踐中選擇新引入的數據庫要慎之又慎，加之目前我國數據庫產品與現有國際商用主流數據庫產品還有一定差距，且數量多、技術路線各異、發展的不平衡等多種因素，給核心系統數據庫選型帶來很大壓力。其次，核心系統已建設多年，在數據處理邏輯方面較多依賴數據庫本身，通過數據庫的存儲過程、函數等實現業務規則中的復雜邏

27、輯計算，而這部分程序可移植性差，一般需經過改造才可以在新的異構數據庫上運行，這些改造在切流后容 11 易給系統帶來功能和性能上的風險。再次，為確保業務連續性，核心系統數據庫創新實踐通常采取新老系統并行策略，相關的開發、測試涉及新老兩套系統，為確保新老系統的功能一致性，極大增加了開發測試難度。此外，現有數據庫中存量數據大，遷移工具有限，導致遷移周期長，且由于技術隊伍的不穩定、掌握新技術產品的人員有限，進一步加大了核心系統數據庫創新實施難度。最后，由于運維的整體自動化、智能化水平有限，不同類型技術產品還難以做到統一運維管理，核心系統引入新的數據庫，特別是分布式數據庫架構復雜、集群規模龐大、技術多樣

28、化、運維管理復雜，進一步增加了運維保障難度，為核心系統安全穩定運行帶來隱患。3.1.33.1.3 圍繞關鍵環節推動圍繞關鍵環節推動核心系統數據庫核心系統數據庫轉型升級轉型升級 一是加大產用聯合創新力度一是加大產用聯合創新力度，基于核心系統應用場景打磨優基于核心系統應用場景打磨優 化產品，化產品，提升服務能力提升服務能力。數據庫廠商在自我研發、創新同時，還應進一步加強與金融機構的聯合創新力度，充分利用在核心應用中復雜、高壓、苛刻的場景，對產品進行反復打磨和優化，補齊在核心技術、災備能力、技術服務能力的短板，滿足核心系統數據庫創新實踐需求。同時數據庫廠商需要與操作系統，芯片等數據庫依賴的關鍵軟硬件

29、生態廠商展加大容性適配，并進一步依托我國在存儲、計算、網絡方面已經取得的產業優勢和成熟經驗，聯合創新，實現數據庫產品性能、可用性、集約性的突破。例如 12 在高可用高可靠方面，通過主備架構、多主架構、共享存儲集群、分布式集群等架構，實現數據庫的高可用性和容災能力，設臵自動故障切換和數據同步機制，確保系統在發生故障時能夠快速切換到備用節點，并提供持續的服務。此外，產業側需要提升數據庫服務能力，不僅要提升原廠服務能力，同時也要通過原廠的培訓加大數據庫認證學習，為用戶團隊培養更多的數據庫人才。二是安全與應用并重，合理選型，高效推動核心系統數據庫二是安全與應用并重，合理選型，高效推動核心系統數據庫創新

30、實踐。創新實踐。由于金融業核心系統屬于國家關鍵信息基礎設施，核心系統在選擇新引入數據庫時，首先要考慮金融安全問題，其次考慮業務需求、自身技術實力、成本及數據庫產品特性，綜合評估后進行合理選型。針對傳統核心系統與數據庫采取的緊耦合模式帶來的改造難度風險，核心系統數據庫創新實踐需秉承多品牌的策略，避免形成對單一數據庫技術和產品的綁定。同時，為了提高應用研發和改造效率，降低后續產品收斂升級改造的成本，需要在技術路線、研發標準方面進行統一約束規范，盡量選擇對業務侵入性比較小的數據庫，最大限度實現應用與數據庫解耦。三是加大生態工具的研發應用，支持核心系統數據庫創新實三是加大生態工具的研發應用，支持核心系

31、統數據庫創新實踐。踐。在數據庫遷移方面，梳理核心系統常用數據庫的特性，分析新引入數據庫的實現差異，開發自動化遷移工具，周密設計遷移規則和數據庫處理邏輯的對等轉換模式，對于源數據庫的復雜特性和巨量存儲過程提供自動化遷移能力，以降低遷移改造人工成 13 本。在數據同步復制方面，優化異構數據庫增量數據復制工具，在新老系統并行階段，通過數據同步工具進行業務高峰期增量歸檔數據在異構數據庫間的雙向復制，實現新老系統業務數據的準實時一致，確保故障場景下能及時回切，提升對外服務的連續性。在數據庫開發方面，通過研發友好的功能強大的客戶端工具支持數據庫設計、開發，提升數據庫開發者的工作效率。在測試方面，研發覆蓋單

32、元測試、功能測試、性能測試、生產驗證和測試管理過程的自動化測試工具鏈，降低測試人力投入和測試復雜度，提升測試效率。在數據庫運維方面，通過完備的數據庫運行狀態檢查、監控、備份、恢復接口和工具，為核心系統穩定運行、數據安全提供保障。四是加強核心系統數據庫創新實踐的統籌管理、經驗總結，四是加強核心系統數據庫創新實踐的統籌管理、經驗總結，逐步形成指導行業實踐的方法論。逐步形成指導行業實踐的方法論。金融機構應將核心系統數據庫創新實踐，納入整體“一把手”重大工程規劃中，統籌推進、重點關注，確保資源投入、精心設計、穩步實施。同時建立并行運行機制，明確專業分工，將基礎技術和應用技術分開，安排專人進行版本管理和

33、程序發布工作，減少核心業務應用系統開發人員轉型難度。另外，在進行核心系統數據庫升級優化時，金融機構要充分總結經驗，編寫部署方案、技術方案、數據庫遷移技術指引、數據庫遷移測試白皮書、各類工具使用手冊等涵蓋數據庫升級優化全過程的指導手冊，形成整套的系統性技術資產、解決方案和方法論，以指導后續核心系統數據庫全面升級優化。14 3.23.2 數據庫支持數據能力建設分析數據庫支持數據能力建設分析 在數字化轉型發展中，金融機構需要對海量、多維的數據進行存儲管理、分析，挖掘有效信息支持業務發展和經營決策，離不開數據倉庫、非關系型數據庫的底層技術支撐，從而對數據倉庫的迭代升級、非關系型數據庫應用探索創新提出了

34、更高要求。因此，需要總結不同類型數據庫支持數據能力建設的現狀，分析創新發展需求，并提出下一步發展建議。3.2.13.2.1 不同類型數據庫不同類型數據庫助力助力數據能力建設數據能力建設取得積極成效取得積極成效 一是數據倉庫高效支持金融機構數字化經營。一是數據倉庫高效支持金融機構數字化經營。由于數據倉庫可對異構源數據進行有效集成，面向數據分析場景，支持全局信息共享和決策分析處理，從而受到金融機構的青睞。金融機構通過建設數據倉庫進一步加強對不同業務部門數據的集中存儲管理，為數據存儲、處理、質量管控和安全管控等提供支持，滿足快速增長的海量數據處理、高可用、彈性擴展、動態負載管理、融合分析等應用需求，

35、并基于相關算法、模型、工具，支持數據價值挖掘、分析應用，在精細化客戶管理、風險管理、精準營銷、智能化決策等不同業務場景中發揮高效作用。二是非關系型數據庫為金融機構數據能力建設提供新助力。二是非關系型數據庫為金融機構數據能力建設提供新助力。近年來，非關系型數據庫在海量、復雜關系、多維的數據管理和分析處理中因為查詢速度快、高可用、高可擴展性等優勢，在金 15 融業實現了較快的創新應用。其中鍵值數據庫因數據類型豐富、高吞吐量、低時延而被大家熟悉，在海量并發場景可為業務提供極致的訪問體驗。圖數據庫由于能更好表達數據之間的復雜關聯關系,構建包含實體、事件、概念之間關系的圖模型，進行復雜的路徑分析、社區發

36、現、鏈接預測等，相比關系數據庫能夠更好地展現和處理這類數據，在反欺詐、合規風控、投資信貸決策等場景進行了較多應用探索。向量數據庫針對機器學習和深度學習中數據的向量表示形式，能實現快速查找和檢索，在量化交易，智能風控，個性化投資組合管理以及智能客服、數字人、情感分析、新聞事件挖掘等自然語言處理的不同金融場景中開展應用探索?？傮w來看，非關系數據庫在海量文件存儲、靈活快速查詢、大數據統計分析、分析決策報表、實時分析、高速緩存、影像圖片數據管理、指標標簽管理等領域發揮越來越重要的作用。3.2.23.2.2 金融業數字化快速發展對數據庫提出新需求金融業數字化快速發展對數據庫提出新需求 一是金融業數字化轉

37、型深入推進對數據倉庫的功能、性能、一是金融業數字化轉型深入推進對數據倉庫的功能、性能、擴展性和安全性提出更高要求。擴展性和安全性提出更高要求。在功能方面，要求承載數據倉庫的數據庫系統要支持更大規模的數據存儲管理、服務時效性、混合負載能力等。其中存儲范圍上要容納海量的內外部結構化數據，還要支持對數據湖等系統中存儲的非結構化數據和半結構化數據進行有效管理和高效訪問。數據服務要支持批量服務和實時服務，特別是對分布式架構下 OLTP 與 OLAP 業務融合越來越多的場 16 景，對混合負載（HTAP）能力提出更高要求。在性能方面，金融企業級數據倉庫處理的數據量巨大、查詢條件復雜、服務的業務類型和業務人

38、員眾多，對查詢、響應效率，高并發、批量加工作業時間窗口等提出了更高的要求。在擴展性方面，隨著金融數據量不斷爆發式增長，數據的存儲、計算需求會隨之快速增長，是否具備便捷的擴展、伸縮能力成為金融機構對數據倉庫的剛性需求。在安全性方面，要具備數據丟失或損壞時的恢復能力、對敏感數據的保護能力、以及對人為有意或無意的誤操作的隔離能力，確保數據和系統的安全。二是數字金融快速發展對非關系型數據庫提出更多需求。二是數字金融快速發展對非關系型數據庫提出更多需求。隨著數字金融快速發展，數據規模迅速增長，金融機構對海量數據的深度分析、事務間的復雜關聯分析、數據隨時間的變化分析越發重要；人工智能和深度學習技術和應用的

39、迅速發展，使科學計算中的高維向量數據、影音/圖片/文檔等多媒體的非結構化數據大幅度增加，存儲管理這些多模態信息需求也快速增加，都對非關系型數據庫提出更多的應用需求。其中，鍵值數據庫需要解決海量并發中熱 key 帶來的性能挑戰，權衡性能和數據一致性的影響，進而提供滿足不同業務場景的高性能方案。圖數據庫需要適應目前金融業應用中標準化程度不高、復制性不強的實際，進行靈活創新應用；同時，不同應用場景對不同架構的圖數據庫需求差異較大，要求圖數據庫具備集中式處理和分布式加工兩類處理模式的優勢，以適應復雜的業務需求。而向量數據庫要降低處理 17 金融數據高維特征對性能帶來的影響、平衡成本與性能要求，滿足數據

40、處理和查詢的高實時性要求，對敏感數據進行安全防護，確保數據安全和隱私保護。3.2.33.2.3 分類推動各類數據庫應用創新促進數據能力提升分類推動各類數據庫應用創新促進數據能力提升 一是加大數據倉庫技術創新，不斷提升金融機構數據能力。一是加大數據倉庫技術創新，不斷提升金融機構數據能力。通過利用 MPP 架構、列存儲、智能索引、向量化計算等多種技術，提升在大數據量、多表關聯復雜計算的能力，提升數據吞吐量和查詢計算效率，減少業務決策的停頓等待時間，優化查詢能力。利用湖倉一體架構、存算分離架構，滿足結構化、非結構化數據存儲和計算的多源融合需求，打通多種數據庫之間的壁壘，支持構建統一的數據分析平臺，滿

41、足大數據量、高并發的數據查詢請求，為不同的業務彈性分配所需算力，提升數據吞吐量、并發能力。二是利用二是利用 HTAPHTAP 技術助力混合負載類業務系統建設。技術助力混合負載類業務系統建設。OLTP 與OLAP 并存是金融業應用系統常見的場景。在傳統 OLTP 類型數據庫中，雖能保證高并發讀寫下的數據強一致，但是在多表關聯、大數據量下的數據分析場景中表現稍顯薄弱，尤其是在分布式數據庫場景下。通過在OLTP分布式數據庫上發展的HTAP關鍵技術，實現一套引擎同時支撐業務系統運行和分析決策場景，避免在傳統架構中，在線與離線數據庫之間大量的數據交互，為混合負載 18 場景的應用系統開發提供了便利，大幅

42、提升面向復雜查詢場景的處理能力。三是分類推動不同非關系型數據庫應用發展三是分類推動不同非關系型數據庫應用發展。目前鍵值數據庫在金融業的應用較多，在應用時可針對不同的數據規模和業務場景，合理選擇分布式集群和讀寫分離架構，以滿足海量并發場景的處理能力和業務訪問體驗需求，同時加大鍵值數據庫的高可用架構建設，為業務穩定、連續運行提供強有力的保障。對正在快速應用圖數據庫，注重高效的圖數據處理能力、大規模圖數據分析能力、可視化和全生命周期的管理能力的提升；使用標準的、符合未來發展方向的圖查詢語言，采用支持 ISO GQL 標準語言的圖數據庫產品，提升圖數據庫的標準化水平；針對不同階段和業務場景，合理選擇單

43、機架構或分布式架構圖數據庫，進行合理的資源投入和架構設計。對于向量數據庫，針對高維數據，選擇合適的向量索引方法，以優化數據的查詢性能；對于高維向量數據，進行必要的降維或特征選擇，以減少數據存儲和處理的復雜性，并提高數據處理效率；考慮使用并行計算、分布式集群部署、壓縮技術，以滿足金融數據大規模處理和實時查詢的需求，減少高維向量數據的存儲成本。3.33.3 開源數據庫應用風險分析開源數據庫應用風險分析 經過多年發展、應用，開源數據庫在金融業廣泛應用于各類業務、管理系統，已成為金融業信息系統的重要組成部分。隨著 19 關鍵信息基礎設施領域數據安全問題被提升到國家安全戰略高度，在金融業應用國外開源軟件

44、存在安全隱患的問題已經逐步得到重視。目前，開源數據庫應用除了通用的開源協議風險、安全漏洞風險、知識產權及代碼感染風險外，還面臨新的開源停服、斷供風險，政策的不確定性風險及掌控和服務能力不足風險等，需要全面分析，加強防范。3.3.13.3.1 開源數據庫快速發展并在金融業得到廣泛應用開源數據庫快速發展并在金融業得到廣泛應用 上世紀90年代，隨著MySQL 1.0版本和PostgreSQL的Stable版本的發布，開啟了快速發展和廣泛應用的潮流和趨勢。隨即國內開源數據庫也迅速跟進，阿里、騰訊和華為等分別推出了國內開源數據庫，并逐漸成為國內互聯網行業的主流數據庫。而TiDB、OceanBase、Iv

45、orySQL、PolarDB 等項目相繼推出，越來越多的企業和機構開始應用開源數據庫。我國金融業積極擁抱開源技術，紛紛加入主要開源組織，積極參與開源社區互動，并主動組織實施了多個有影響力的開源項目，取得良好效果。其中 MySQL 應用最為廣泛和深入，應用生態也較為完善。以郵儲銀行為代表 PostgreSQL 應用也取得較好效果。近年來，華為、阿里、螞蟻、騰訊、平凱星辰等我國主要數據庫廠商推出的開源數據庫在金融行業的應用力度逐步加大，為金融機構有效防控單一供應商風險和日益復雜的供應鏈安全風險提供了選擇。20 3.3.23.3.2 金融業金融業開源數據庫面臨諸多風險開源數據庫面臨諸多風險 一是開源

46、協議風險。一是開源協議風險。開源產品通常需要根據特定的開源協議進行發布和分發。不同開源協議的要求和限制差別較大，包括但不限于使用、修改、復制和分發等，給金融機構的選擇、使用和分發帶來困擾。而且開源產品可能嵌套其它開源產品的部分或全部代碼，而這些開源產品可能遵循不同的開源協議，對于用戶而言，這是一個極復雜而且隱蔽的風險。同時，不同開源許可協議之間可能存在混合或者不兼容情況，開源協議可以由開源項目背后的開源基金會或者商業機構根據其商業意圖進行轉換，例如知名數據庫廠商mongodb將 AGPL 協議變更為更為嚴格的 SSPL 協議，在其他一些開源項目中還可以觀察到由開源直接轉為閉源的事件發生，開源許

47、可證的變更也為金融機構判斷評估適用性增加了難度。違反許可證的條款造成違約行為，易導致金融機構面臨知識產權侵權等風險，可能會被權利所有人提起專利訴訟并收取費用，影響較大的案例可能導致金融機構商譽受損。二是安全漏洞風險。二是安全漏洞風險。安全漏洞的發現、披露和解決速度是衡量軟件安全的一個重要指標。開源數據庫是由世界范圍內的個人自愿貢獻代碼，由于錯誤的代碼實現或設計缺陷、開源社區維護度不足、使用者未能及時更新軟件版本等原因，可能存在漏洞和安全問題，導致金融機構在使用開源數據庫過程中面臨數據泄露、身份驗證問題、拒絕服務攻擊等多種安全威脅。開源數據庫往往 21 不會經歷太多實際的業務性測試，遇到問題時可

48、能無法得到及時的修復，解決風險需花費大量的時間。對于金融業來說，特別是對于很多中小金融機構，內部開源技術治理還不夠成熟，缺乏配套的專業人員和工具，而開源數據庫已經將源代碼尤其是內核代碼開放，對黑客而言開源數據庫毫無秘密可守，容易遇到惡意攻擊事件，引發數據泄漏問題，無法從根本上保障金融數據安全。三是知識產權侵權、代碼感染風險。三是知識產權侵權、代碼感染風險。開源數據庫細分為兩種：一種是源代碼由國內數據庫廠商完全自研后選擇開源模式進行市場推廣；一種是國內數據庫廠商封裝了國外開源數據庫內核代碼，在此基礎上二次開發的代碼必須遵守國外開源協議限制，將二次開發的源代碼公開，事實上出現了代碼感染。雖然這兩種

49、數據庫都稱之為開源數據庫，但實際上存在一定差異。前者具備完整的數據庫知識產權，是掌握數據庫核心技術和知識產權后，選擇了開源的商業模式。后者則會被國外開源軟件體系限制，存在知識產權、代碼感染風險，應用到金融機構關鍵業務系統可能會埋下安全隱患，引發數據安全問題。四是開源停服、斷供風險突出。四是開源停服、斷供風險突出。當前，開源軟件供應鏈形勢愈加復雜和多樣化。一旦開源數據庫項目停止開發和維護，金融機構將無法升級數據庫系統和獲取新功能，亦無法得到此開源數據庫相關的技術支持，甚至可能因為缺乏維護導致安全漏洞無法及時修復，會嚴重影響存量信息系統的運行維護，并帶來大量的 22 系統更新需求和額外的成本及風險

50、。目前，接近 90%的金融機構在一般業務和管理類系統應用使用了開源 MySQL，普遍面臨MySQL 5.7 版本的停服問題，導致金融機構被迫轉型升級至更高版本，面臨較大的升級改造壓力。此外，開源數據庫供應鏈風險不斷增大，一旦國家之間的貿易管制政策蔓延到開源項目，金融機構托管在海外的開源代碼資產將面臨凍結風險，也會面臨復雜的司法糾紛等問題。五是政策不確定性風險。五是政策不確定性風險。相對閉源的專利技術，開源數據庫難以通過傳統的專利和知識產權保護手段來證明自己的創新性和價值，使得開源數據庫在獲得資金、政策支持和競爭優勢方面受到限制，也導致開源數據庫在認定中面臨難以評估和認定的困境。目前，金融機構大

51、量使用開源數據庫，開源數據庫能否認定為符合政策要求對金融機構在數據庫產品技術選型、升級迭代策略等方面具有較大影響，導致金融機構在數據庫領域的規劃布局存在較大的不確定性，也面臨較大的技術路線選擇糾錯風險。六是掌控和服務能力不足風險。六是掌控和服務能力不足風險。不同于商業閉源數據庫可提供友好且易于使用的界面和工具，開源數據庫需要金融機構具備較強的掌控能力，開發運維團隊需要理解和掌握數據庫系統的原理、架構、配臵和管理等方面的知識，具備一定的自主解決問題能力，才能確保開源數據庫的順利應用，而大量中小金融機構顯然難以滿足掌控能力要求。同時，對開源社區的貢獻往往屬于開 23 發者的個人行為，并非持續性的機

52、構行為，絕大部分機構依然側重于關注軟件的技術研發維護能力，缺乏主動參與開源工作和貢獻開源生態的意識和動力，導致金融機構面對開源數據庫缺陷與問題時大多處于被動的局面，未能形成良好的產用雙方技術共建能力。另外，相比商業數據庫提供的全面技術支持和售后服務，開源數據庫服務通常依賴于社區支持和開發者社區的幫助，而社區響應的及時性和質量并不一定能夠滿足金融機構的需求。3.3.33.3.3 多措并舉防范開源數據庫應用風險多措并舉防范開源數據庫應用風險 一是加大開源數據庫治理，降低開源數據庫使用風險。一是加大開源數據庫治理，降低開源數據庫使用風險。金融機構需要設臵專人進行開源數據庫治理，對開源數據庫進行合理合

53、法管控，確保合規使用開源數據庫。在選擇開源數據庫時，金融機構首先要考慮其是否安全可控，然后全面考慮其版本穩定性、社區活躍度和更新頻度，對相關工具和插件等開展研究，判斷開源數據庫項目的可持續性和發展前景，積極發展和應用自主開源項目，避免停服、斷供帶來的風險。同時，在引入開源數據庫前，金融機構應進行充分測試和評估，通過搭建測試環境，模擬實際應用場景，進行全場景、全量、重壓的測評，評估數據庫的性能、穩定性和可靠性，減少由于技術局限性和不確定性帶來的風險。另外，配備專業的法律團隊或與外部專業法律機構合作，對開源數據庫的開源協議進行分析、提供專業的法律支持，也可以考慮與開源軟件社區或相應的權威機構進行合

54、作，以獲取有關開源協 24 議和風險管理的專業建議和支持，從源頭上降低可能存在的知識產權風險。二是提升開源數據庫安全防范水平，確保安全生產。二是提升開源數據庫安全防范水平，確保安全生產。金融機構應加快建立軟件成分清單生成與使用規范，標準化軟件成分和軟件成分可視化流程，保證組件透明理念的落實。同時，金融機構應配備專業的安全檢測工具、漏洞掃描工具和安全人員，對開源數據庫進行定期檢查，發現潛在的漏洞和安全風險，并進行妥當評估、處臵和回顧，結合安全可信白名單機制、風險預警與情報收集機制，保證內部環境安全。充分利用第三方代碼檢測和第三方安全評估機構的力量，獲得開源數據庫代碼自主率、獨立的安全建議和解決方

55、案。通過使用強密碼、多因素身份驗證和訪問控制列表等方法，限制對開源數據庫的訪問權限，避免未經授權的訪問。通過安全教育和培訓，提高開發人員和管理員的安全意識，了解并學習常見的安全威脅、攻擊方式及防范措施，提高對安全問題的警惕性。三是推動金融開源數據庫社區建設，全面提升對開源數據庫三是推動金融開源數據庫社區建設，全面提升對開源數據庫的掌控和服務能力。的掌控和服務能力。在行業主管部門的指導下，由權威的第三方行業組織推動建設金融開源數據庫社區，加強產學研用多方協作，充分調動行業機構力量，引導生態鏈各方積極參與開源社區。同時，依托社區對開源數據庫進行測試評估、漏洞風險通告，組織開展開源數據庫的技術交流、

56、研討，并通過開源社區博客、視頻 25 教程、在線文檔等資源，提升金融機構對開源數據庫的掌控能力。另外，要特別重視鼓勵金融機構積極參與開源社區的活動，如報告漏洞、提出建議、參與開發、與開發者合作解決問題以及貢獻代碼等，獲取更多有關開源數據庫的信息，助力金融機構開源數據庫技術人才培養，并獲取社區對開源數據庫使用的更好服務。未來三至五年是金融業數據庫創新發展的關鍵時期，也是高成長時期，無論從廣度、還是深度上都將迎來巨大的突破和發展，我國數據庫產品也將隨著大量應用驗證不斷成熟，實現從“可用”向“好用”轉變。隨著技術演進變化，數字化、智能化普及，不同類型數據庫應用創新力度不斷加大，數據庫領域基于分布式、

57、云原生、人工智能等技術加持，進一步加快能力提升，更高效支持“數字金融”發展。4.14.1 我國主流數據庫產品成熟度將進一步提升我國主流數據庫產品成熟度將進一步提升 隨著核心系統數據庫轉型加速，金融機構會持續加大對數據庫產品的投入力度，為產業側提供開發和優化數據庫產品的動力和資源，盡快彌補我國數據庫產品在功能、性能、異地災備、數據同步等核心技術能力的差距，豐富配套工具，降低實施運維難度，推動我國數據庫產品的成熟和穩定。同時，基于核心系統特性及其他非數據庫技術要求，也將倒逼數據庫服務能力提升，支 26 持更為便捷、高效的數據庫應用開發、運維及安全防護，推動我國數據庫由“能用”向“好用、易用”轉變。

58、另外，基于豐富的金融數據庫應用實踐，不斷完善金融數據庫應用相關標準規范，提升產品的標準化水平和快速復制能力，適應金融業快速發展的需要。4.24.2 金融核心系統數據庫轉型升級將穩步推進金融核心系統數據庫轉型升級將穩步推進 金融業數據庫轉型模式由政策驅動轉向自覺行動。在主管部門的直接指導、推動下，金融業完成了多輪轉型試點，實現了從“0”到“1”的突破。且隨著國際形勢愈加的復雜多變，全行業實現了從上至下理念的轉變、認識的提升，確保關鍵軟硬件技術供應鏈安全穩定已成為上下共識。經過近幾年積累，我國數據庫技術產品供給能力明顯提升，應用生態不斷完善，大量試點應用為金融核心系統數據庫轉型提供了寶貴的可借鑒經

59、驗，金融機構必將直面核心系統數據庫轉型的“硬骨頭”。同時，主管部門將根據需要適時進行指導，提供數據庫等關鍵軟硬件技術應用的政策支持。在各方的共同推動下，我國數據庫產品必將在金融核心系統實現快速深入應用、突破發展，切實提升安全可控水平。4.34.3 新技術與業務場景將推動金融數據庫創新發展新技術與業務場景將推動金融數據庫創新發展 隨著數字化轉型深入推進，金融數據庫創新將迎來新一輪高潮。數據倉庫、數據湖、大數據等技術融合應用創新，不斷提高 27 支持數據能力建設的水平。不同類型的非關系型數據庫加快應用創新，適應數字經濟時代海量、多維數據處理及不同細分場景的應用要求。同時，數據庫也將逐步從分布式向云

60、原生轉型，提供超大并發支持能力和更強大彈性伸縮能力?；谌斯ぶ悄艿臄祿?AI 優化器、AI 分析引擎，AI 自治運維系統等，將全面提升數據庫的查詢、交易處理速度，提供更智能、準確的業務洞察和風險評估能力，實現高效的自動化數據庫運維。4.44.4 金融業開源數據庫應用風險防范仍然不容忽視金融業開源數據庫應用風險防范仍然不容忽視 針對多年積累的存量開源數據庫，金融機構還需進一步摸清家底，形成開源數據庫底層和源頭清單，對開源數據庫進行合規治理，根據自身情況適時考慮是否收縮技術棧。同時，重點關注斷供、停服風險，并持續加強協議風險、安全漏洞風險防范，確保安全生產。對于開源數據庫使用的政策不確定性、掌控

61、和服務能力不足的風險，需要加強政產學研用的合作力度，充分交流研討，多方協同，形成應用共識，并通過加大開源社區、應用生態建設，確保開源數據庫在金融業的順利應用。隨著管理部門的大力支持和推動，行業標準規范的及時跟進和發布，數據庫產業的巨大投入和快速迭代，金融機構的積極響應和快速推廣，科研院所對數據庫人才的培養，以及政產學研用聯合攻關，將推動金融業數據庫創新向深入發展。行則必至，做則必成，金融業數據庫創新發展只待時日、花開有時。一、政策性銀行及開發性金融機構一、政策性銀行及開發性金融機構 .1 1 案例一：國家開發銀行基于 CirroData 和 BEH 的大數據平臺建設應用實踐.1 二、國有大型銀

62、行二、國有大型銀行 .5 5 案例二：工商銀行分布式數據庫 GaussDB 應用實踐.5 案例三：農業銀行大數據平臺 GBase 8a 應用實踐.13 案例四：中國銀行數據倉庫 GBase 8a 應用實踐.16 案例五：建設銀行核心系統 GoldenDB 應用實踐.16 案例六：交通銀行核心系統 OceanBase 應用實踐.23 案例七：郵儲銀行新一代個人業務核心系統 GaussDB 應用實踐.26 三、股份制銀行三、股份制銀行 .2929 案例八：平安銀行信用卡核心系統 TDSQL 應用實踐.29 案例九：光大銀行新一代信用卡核心系統 GoldenDB 應用實踐.33 四、城市商業銀行四、

63、城市商業銀行 .3636 案例十：北京銀行分布式核心系統 TiDB 應用實踐.36 案例十一：北京銀行分布式核心核算引擎 OceanBase 應用實踐.39 案例十二：北京銀行基于 CirroData 和 BEH 的湖倉一體建設應用實踐 41 案例十三：貴陽銀行信用卡管理平臺 SUNDB 應用實踐.46 案例十四：江西銀行企業網銀系統 SUNDB 應用實踐.50 案例十五：湖北銀行新核心業務系統中達夢柔性遷移雙活應用實踐.55 案例十六：四川銀行金融核心業務反洗錢系統 GBase 8s 應用實踐.58 案例十七：秦皇島銀行分布式核心系統 TDSQL 應用實踐.61 案例十八：梅州客商銀行新核心

64、業務系統中達夢高容災可用性應用實踐.65 案例十九：某銀行核心業務領域 GBase 8c 多模多態分布式數據庫應用實踐.68 五、農村商業銀行五、農村商業銀行 .7272 案例二十：廣東農信數據庫聯合實驗室企業網銀和銀企直連 SUNDB 應用實踐.72 案例二十一：浙江農商銀行“豐收互聯”TDSQL 存算分離應用實踐.75 六、證券機構六、證券機構 .7979 案例二十二：中信建投 OTC 核心業務系統中達夢集中式 HTAP 應用實踐.79 案例二十三：國泰君安證券新一代分布式核心交易系統 GoldenDB 應用實踐.82 案例二十四：申萬宏源證券阿里云數據倉庫 AnalyticDB 應用實踐

65、.86 七、保險機構七、保險機構 .9090 案例二十五：中國人壽數據庫遷移實踐.90 案例二十六：中國太平洋保險核心系統 OceanBase 應用實踐.96 1 一、一、政策性銀行及開發性金融機構政策性銀行及開發性金融機構 案例一案例一：國家開發銀行基于國家開發銀行基于 CirroDataCirroData 和和 BEHBEH 的大數據平臺建的大數據平臺建設應用實踐設應用實踐 一、一、應用場景應用場景 國家開發銀行在分析系統領域使用了 TD、Oracle 等多種數據庫，來滿足各類場景要求，但在很多場景中仍受限較多，要么功能不能滿足，要么性能不能滿足，為此經過多個實際應用系統的實用驗證，最終采

66、用東方國信的 CirroData 和 BEH 構建了全行級的大數據平臺，支撐全行的數據應用。應用場景的示范舉例：數據整合：基于大數據平臺建設實現業務歷史數據的集中和歷史保留，并能方便地提供查詢；數據查詢：查詢平臺從 TeraData 平滑遷移到 CirroData，并提升了查詢效率；高性能處理：主動探索系統基于傳統技術和大數據技術無法達標，通過 CirroData 實現業務需要功能，且做到 3 秒返回結果；功能提升：支持百億級記錄表快速、關聯查詢，使查詢效率低、無法查詢出結果的性能獲得顯著提高，可在分鐘級獲得查詢結果；目前，累計部署服務器超過 300 臺，有效存儲空間超過 10PB，2 且使用

67、常規的高性價比服務器，綜合成本得到大幅降低。二、二、總體方案總體方案 大數據平臺整體規劃如下圖所示：圖 1 數據架構圖 整個儲算平臺分為三部分：1.首先是基礎數據區，里面包含了結構化數據和非結構化數據。結構化數據中包含了臨時數據區，為全平臺中統一的臨時數據；貼源數據區為按系統保留的每日的原始數據；主題模型數據區為傳統數據倉庫的模型數據；匯總數據區為傳統數據倉庫的匯總層數據；維度寬表數據區為統一的企業級維度模型數據。貼源數據、主題模型數據、匯總數據、維度寬表數據是全行級的公共數據。其上面數據集市區存儲多個數據集市，存儲面向某個業務條線或業務板塊公共的數據。這些構成了全行的基礎數據。2.基礎數據區

68、上面是應用數據區，里面存放應用系統專用的數據。3 3.元數據區，存放數據平臺的統一的元數據信息。在技術上，結構化數據存儲統一采用新一代 MPP 數據庫存儲，非結構化數據目前采用大數據技術存儲，即 HDFS+ES+Hbase等組件進行存儲，一般大文件可直接放到 HDFS 上，小文件建議存到 Hbase 中，未來還可引入 OSS 對象存儲。而數據的采集、處理和特定計算可依托 Hadoop 生態組件實現，從而實現新一代 MPP數據庫和 Hadoop 生態的有機結合。三、三、難點問題及應對舉措難點問題及應對舉措 該銀行采用新一代 MPP 數據庫 CirroData 和 Hadoop 發行版BEH 產品

69、，并在此基礎上開發了全套完整配套產品和解決方案，解決了自身的如下痛點問題：統一部署：CirroData 和 BEH 可以統一部署，使用一套分布式文件系統，可以按需部署，避免了傳統的數據庫和Hadoop 必須獨立部署，數據底層共享，大大減少處理環節，增加數據共享能力；集中統一存儲：避免了企業內數據在多個組件中冗余存放，以解決不同場景問題，結構化數據主要存儲在 CirroData中，非結構化數據主要存儲在大數據組件中，在企業內形成標準化規范，并支持大部分數據應用場景，大大簡化了企業內數據管理的復雜度和冗余存放；開發統一化：由于大部分操作尤其 90%以上是對結構化數據處理，均可基于 CirroDat

70、a 產品完成，因此大部分開發 4 人員只需掌握這一個產品，且以 SQL 操作為主，大大降低企業的學習成本；完善遷移工具：基于 CirroData 和 BEH 開發了數據遷移、數據核對、程序遷移、調度遷移等配套產品，實現應用系統的快速遷移；成本降低：CirroData 支持 X86 服務器和多種我國設備產品，并有多個實際案例，整體使用成本大大降低；配套解決方案：除了產品以外，東方國信湖倉一體解決方案包含咨詢規劃能力、專業開發實施、專業運維服務和配套產品，提供全面服務，保證了湖倉一體平臺的持續建設。四、四、應用成效及經驗應用成效及經驗 從使用 TeraData、Oracle 等多個傳統數據庫產品，

71、到集中使用了 BEH 和 CirroData 產品，建設了統一的儲算平臺，已經落地了數據湖區、倉庫區、集市區、應用區、實時區、非結構化區等，在此基礎上新建或遷移了主動探索等幾十個相關應用系統。大數據平臺項目的建設逐步統一技術路線，標準化了開發流程和規范，提升了面向業務的響應時效，滿足了之前不能實現或實現困難的系統和功能。5 二、二、國有國有大型銀行大型銀行 案例案例二：二：工商工商銀行分布式數據庫銀行分布式數據庫 GaussDBGaussDB 應用實踐應用實踐 一、一、應用場景應用場景 工商銀行經過技術攻關與創新實踐，充分驗證了傳統集中式數據庫向分布式數據庫轉型的可行性，為大型商業銀行核心系統

72、安全可控轉型走出了寬闊的道路。未來，工商銀行將持續圍繞分布式數據庫的創新運用，協同華為持續開展聯合創新和技術攻關，夯實工行數字基建基礎支撐，形成金融行業傳統集中式數據庫轉型最佳實踐，通過技術沉淀和轉型實踐經驗總結，識別行業共性需求，形成高效可控低成本的數據庫平滑轉型技術方案及配套工具，為金融同業提供轉型的良好借鑒，助力中小金融機構加快自身數據庫轉型進程，共建金融科技新生態，推動金融業實現高水平科技自立自強。二、二、總體方案總體方案 （一）項目實施模式 對于大型 Oracle 應用系統，一般會采用雙軌并行的模式。具體實施方式如下：1.存量數據遷移階段：采用 DRS 數據復制工具，完成存量數據遷移

73、。2.技術驗證階段：以技術驗證為主，將業務聯機、批量雙寫，切流部分查詢交易，觀察 GaussDB 數據庫運行情況。6 雙庫并行期間將非雙寫的表做單向增量數據同步。圖 1 雙庫并行，數據增量同步 3.全功能切流階段：GaussDB 承接業務日常聯機和批量數據處理，通過灰度引流，按試點維度（機構或客戶）逐步推廣，并可實現試點維度 GaussDB 和 Oracle 庫快速互切。圖 2 全面切流，GaussDB、Oracle 快速互切 4.單軌運行階段：在 GaussDB 全面承接業務并穩定運行半年后，將采用單軌運行的方式，并下線老的 Oracle 數據庫。應用采用 Java 攔截器特性進行雙寫。圖

74、3 Java 攔截器雙寫 該方案利用 Java 攔截器特性，適用于 Java 類應用。應用側需要改造做雙寫表，利用 DRS 繼續同步應用相關參數表，由于GaussDB 的數據有延遲，比對的數據以成功寫入 GaussDB 的部分 7 為基準，反向與 DB2/Oracle 的數據進行校驗。Java 攔截器Interceptor 原理：攔截器是動態攔截 Action 調用的對象。它提供了一種機制使開發者可以定義在一個 Action 執行的前后執行的代碼，也可以在一個 Action 執行前阻止其執行。應用通過攔截器，對業務的 Controller 請求進行攔截，執行雙寫邏輯。（二）實施周期 整體項目周

75、期約 5 個月，關鍵里程碑節點如下：圖 4 實施周期（三）數據遷移 對原系統數據采用全量數據+增量數據遷移的策略。使用DRS數據復制服務。對于全量數據遷移，通過 select 的方式將源庫的全量數據導出；調用 GaussDB 的 copy 接口批量寫入目標庫；可對單表根據主鍵進行進一步分片，每個分片作為獨立的同步單元，并發執行同步效率 100MB/s。對于增量數據遷移，通過 Oracle LogMiner 解析數據庫日志，DRS 將抓取到的數據落盤存儲，讀取落盤數據，重構成對應的 SQL 語句在目標庫回放。在數據遷移的過程中，主要遇到的問題有兩個：1.性能達不到性能要求。2.增量遷移表需要有唯

76、一索引。8 針對第一個問題，一種方式是采用 LogMiner 的方式，但需要解決抓取 lob 不全，不支持無主鍵表等問題。圖 5 LogMiner 方案 一種方式是采用 Xstream 的方式，該方式需要 Oracle ogg license，在推廣上有一定局限性。圖 6 Xstream 方案 還有一種是通過 CDC 到 kafka，再到 GaussDB 的方式，這種方式技術棧較復雜，并且鏈路較長，穩定性待驗證。圖 7 CDC、Kafka 方案 最終選擇第一種方案進行實施，版本做了針對性的優化，滿足同步性能。針對第二個問題，通過增加主鍵或唯一鍵的表;早批文件加載臨時表，可以不同步;純技術備份表

77、進行 DROP 三種方式進行解決。三、三、難點問題及應對舉措難點問題及應對舉措 從傳統數據庫往分布式數據庫轉型的過程中，面臨如下痛點：9 1.高可用挑戰大：業界常用的數據庫方案只能部署在跨園區的單 Region 中，不能滿足高等級應用的高可用要求。2.性能容量挑戰大：大型業務系統高峰期 TPS 近萬/秒，單庫幾十 T，對基礎設施及數據庫的性能容量提出了較大的挑戰。3.擴展性不足：傳統的集中式數據庫由于架構限制，往往采用一主一備，即使是 Oracle RAC，由于共享存儲的限制，也最多只能擴展 2 到 4 個節點，單集群的容量容易出現瓶頸。4.安全性有待提升：近年來隨著大眾對保護個人信息意識的提

78、升，以及各國家地區紛紛出臺數據安全相關的政策法規，如何保護數據安全隱私的問題受到重大的關注，同時也是工業界與學術界研究的熱點問題。5.數據同步挑戰大：大型業務系統高峰期超過幾百 G/小時數據歸檔量，對新舊系統雙庫并行期間的數據同步效率要求極高。6.數據庫對象遷移成本高：Oracle應用存量存儲過程量大，重構成本高，特別是大型業務系統，普遍使用多個 Oracle 庫，存儲過程行數達到千萬級，業界常見的遷移工具的存儲過程自動化遷移率 70%左右，大型 Oracle 應用轉型應用改造成本非常高?？赏ㄟ^如下關鍵舉措應對轉型過程中面臨的痛點問題：1.提升服務連續性：對標主機 AB 站點雙活方案，對 Ga

79、ussDB承載大型業務系統 Oracle 數據庫轉型的部署方案開展聯合創新，實現同城雙集群+Dorado 存算分離的部署架構。2.降低遷移開發成本：建設完善的自動化遷移工具，通過內 10 核兼容（或提供對等能力）+工具自動化轉換，形成低成本、風險可控的應用遷移技術方案。3.提升測試效率：建設 GaussDB 自動化測試配套工具，支撐轉型應用存量 Oracle 存儲過程測試案例向 GaussDB 遷移并實現自動化測試，降低測試人力投入，提升測試效率。4.提升數據復制效率：優化數據復制工具，滿足灰度切流雙庫并行期間大型業務系統高峰期的數據歸檔量的同步效率。四、四、應用成效及經驗應用成效及經驗 工商

80、銀行 Oracle 數據庫轉型項目，自 2019 年引入 GaussDB以來，已在包括實物貴金屬、中間業務系統等近 40 個業務系統試點上線，覆蓋辦公系統、一般業務系統和關鍵業務系統各類典型業務場景，初步形成一套涵蓋工行主要商用交易型數據庫（Oracle、DB2、SQL Server）的轉型方案。轉型成效 1：聯合創新，夯實數據庫核心承載能力 一是數據可靠性高?；谌W存集中存儲實現計算與存儲分離，軟硬協同，具備 PB 級海量數據存儲能力和企業級高可靠能力。二是系統可用性高。具備同城雙園區+異地園區部署能力，園區內故障場景 RPO=0、RTO60 秒，同城園區級故障場景 RPO=0、RTO18

81、0 秒，同城雙園區故障場景切換到異地園區 RPO60 秒、RTO600 秒。三是集群性能高。同城主備集群間采用磁盤級復制實現增量日志強同步，日志同步效率提升一倍以上，降低了主備同步對主集群性能的影響，基于 2 路國芯服務器最小規模主備集 11 群部署，TPMC 達到 68 萬（約 2.5 萬 TPS）。四是服務連續性能力高。具備業務不中斷前提下主備集群數據庫版本輪換升級和應用版本灰度升級能力，滿足了核心應用 7*24 小時服務連續性要求。轉型成效 2：應用創新，錘煉數據庫平滑遷移能力 工商銀行聚焦傳統數據庫與應用耦合度高的難點，聯合華為進行突破，構建了整套的自動化工具鏈：一是實現跨異構數據庫的

82、自動遷移。針對部分傳統集中式數據庫特有的數據庫對象、高級特性和非標準 SQL 語法，通過建設配套的自動化數據庫遷移工具，提前評估和規劃遷移工作進程，識別遷移風險，再通過工具自動化進行語法轉換和邏輯校驗，降低遷移成本、控制遷移風險，快速低成本地實現從商業專用平臺向開放創新平臺的遷移，自動遷移成功率和編譯通過率均可達95%以上。二是實現異構數據庫轉型全過程的自動化測試。工商銀行建設了覆蓋單元測試、功能測試、性能測試和測試管理等研發測試全過程的自動化測試工具鏈，一方面通過 SQL 解析、分支預測等技術實現技術測試自動化，另一面復用存量業務測試資產實現業務功能測試自動化，整體自動化測試覆蓋率可達 80

83、%。三是實現試運行階段生產環境測試驗證的系統級解決方案。研發交易錄放工具，在試運行階段，先在舊系統抓取流量，然后在新系統分別進行一致性流量回放和性能回放實現功能和性能 12 的驗證：首先，一致性回放將抓取到的 SQL 按源庫的執行順序以事務為單位在新系統進行回放，實現業務功能全覆蓋測試，保證新舊系統功能完全對等；第二，性能回放把抓取到的 SQL 按照一定規則分發進行多線程并發回放，以接近實際生產業務壓力的速度回放到新系統，進行性能、可用性及可靠性測試，確保新舊系統可完整承載業務壓力。四是實現新舊系統并行階段數據一致性的系統級解決方案。優化異構數據庫增量數據復制工具，在雙庫并行階段，新舊系統均有

84、業務流量，通過數據復制工具進行業務高峰期增量歸檔數據在異構數據庫間的雙向復制，實現新舊系統業務數據的準實時一致，確保故障場景下能及時回切，提升對外服務的連續性。轉型成效 3：資產沉淀，形成普適性的一體化解決方案 工商銀行協同華為公司組建涵蓋數據庫技術研究、研發、測試等方向跨開發中心多地的攻關團隊，在傳統集中式數據庫轉型實踐中，充分總結經驗，編寫了轉型部署方案、轉型技術方案、數據庫遷移技術指引、數據庫遷移測試白皮書、各類工具使用手冊等涵蓋數據庫轉型全過程的指導手冊，形成了整套的系統性技術資產和解決方案，開拓了傳統集中式數據庫轉型工作的新思路、新方法，初步形成了一套無需整體重構 Oracle 存儲

85、過程邏輯，低成本、高效可控的轉型技術方案。13 案例三：農業銀行大數據平臺案例三：農業銀行大數據平臺 GBase 8aGBase 8a 應用實踐應用實踐 一、一、應用場景應用場景 中國農業銀行大數據平臺是自主搭建的全行級數據采集、加工、服務一體化系統。數據來源于核心、信貸、財會、風險管控等近百個源系統，經過清洗轉換、拼接整合、匯總加工后形成高價值密度的數據模型，面向全行各大業務領域和場景，提供大數據深度分析和挖掘，全面支撐資產負債、運營管理、風險管理、數據報送等各項業務領域應用，為業務提質增效提供有力支撐。二、二、總體方案總體方案 中國農業銀行大數據平臺基于 GBase 8a MPP Clus

86、ter（以下簡稱 MPP 數據庫）+Hadoop 技術棧建立創新混搭式基礎軟件架構，自下而上分為數據處理層、模型指標層、數據集市層以及分析展示層。圖 1 大數據平臺架構圖 數據處理層使用 Hadoop 集群接收并處理各類業務源系統的結構化數據文件，完成數據的清洗轉換以及拉鏈表的加工；模型 14 指標層、數據集市層采用 MPP 數據庫構建，形成了企業級統一數據視圖，面向特定業務領域提供定制化數據集合；各應用在分析展示層利用數據集合完成對數據的挖掘、分析和展示。MPP 數據庫和 Hadoop 混搭式的總體架構，根據目標數據特點分層處理，充分發揮各自技術優勢，高效應對海量數據的管理和流轉。三、三、難

87、點問題及應對舉措難點問題及應對舉措 （一）大規模數據需求加劇集群資源競爭。采用 MPP 數據庫虛擬集群技術對多個虛擬子集群進行統一管理，各虛擬集群在整個物理集群范圍內獨立運行，實現數據隔離、資源隔離、故障隔離；同時各虛擬集群共享統一的入口，支持跨虛擬集群數據訪問和權限管理，實現多租戶業務的整體調度，維護全局大規模數據視圖。（二）MPP 數據庫在特定服務器上性能表現不及預期。根據目標服務器 NUMA（Non-Uniform Memory Access，非一致性內存訪問）架構特點，采用數據庫計算實例與 NUMA 內核綁定技術，在單服務器上部署多個 MPP 數據庫運行實例。多實例部署可充分發揮 NU

88、MA 服務器的性能，降低大數據計算場景下跨NUMA 節點內存訪問帶來的性能損耗，大幅提升大數據平臺的計算性能。（三）海量數據對面向業務連續性的容災要求不斷提升。為配備高等級跨地域容災能力，在基礎環境方面，使用磁盤RAID 技術、冗余電源、網卡綁定、多機架高可用等保障運行環 15 境穩定；在集群級高可用方面，創新性地提出和實現支持 PB 級海量數據增量同步的異步雙活解決方案，并成功應用于系統災備、機房搬遷等場景中，實現大數據平臺同城機房間、異地機房間的超大規模數據同步、主備集群切換，保障業務穩定運行。（四）內外部數據管理對數據安全保障提出更高要求。平臺利用 MPP 數據庫安全功能特性，進行數據加

89、密與安全管理。一是對重點應用中高安全性要求的表，在建表時按需使用加密關鍵字，對表級或列級數據進行加密；二是基于 MPP 數據庫用戶認證和權限管理能力，結合行內用戶安全管理基礎設施，搭建可視化工具對集群級、庫級、表級、字段級等權限進行管控，實現數據安全分級管理。四、四、應用成效及經驗應用成效及經驗 中國農業銀行大數據平臺已平穩運行近十年，系統部署架構、高可用方案、數據安全方案等不斷創新發展，為同業推進大數據體系建設提供了有效借鑒。目前已部署 MPP 數據庫集群近百套，節點總規模超四千臺，為總量達幾十 PB 的海量數據提供管理和服務；T+1 雙活機制利用主集群閑暇時段進行數據高效同步，充分保障了集

90、群級高可用性，是金融機構應用 MPP 數據庫進行海量數據處理的優秀實踐案例。16 案例四：中國銀行數據倉庫案例四：中國銀行數據倉庫 GBase 8aGBase 8a 應用實踐應用實踐 一、一、應用場景應用場景 中國銀行以數字化轉型為契機，構建“三橫兩縱一線”的新型數字資產運營服務體系，“三橫”是搭建集團統一數據平臺，以“數據+分析+展現”的三層架構，為數據資產的共享、分析應用、服務提供和價值創造提供全面、敏捷、精細的能力支撐，數據倉庫是數據層的重要組成部分。中國銀行使用 GBase 8a MPP Cluster 集群承載數據倉庫、風險數據集市、審計系統、SAS 模型管理平臺、監控標準化數據報送

91、平臺、報表系統等數十套應用，累計部署千余臺服務器，管理數十PB數據量。中國銀行在2020年啟動GBase 8a MPP Cluster環境的全面改造，包括硬件服務器、操作系統等。二、二、總體方案總體方案 中國銀行 GBase 8a MPP Cluster 環境的創新改造分為新建環境和已有環境的遷移改造。首期全棧創新改造基于新建的數據湖倉項目進行，使用GBase 8a MPP Clsuter 作為數據倉庫面向海量數據分析型應用領域，進行數據復雜分析和作業加工；Hadoop 集群作為數據湖負責數據匯聚、貼源數據清洗和沉淀歷史數據資產。數據湖倉項目中共部署 GBase 8a MPP Cluster

92、集群近 400 節點，使用 190多臺海光芯片服務器和麒麟操作系統，采用多實例部署方式每臺 17 海光芯片服務器上部署兩個 GBase 8a 計算節點實例。對基于 Intel 服務器的 GBase 8a MPP Cluster 集群，通過服務器遷移、集群升級方式完成創新應用環境的升級。將 GBase 8a MPP Cluster 的數據文件通過備份恢復方式遷移到海光芯片服務器上，之后對海光芯片服務器上的 GBase 8a MPP Cluster集群進行版本升級和創新應用平臺優化配臵。三、三、難點問題及應對舉措難點問題及應對舉措 中國銀行創新改造過程中面臨如下幾方面的問題，通過銀行與 GBASE

93、 廠商、芯片及服務器廠商、操作系統廠商緊密合作制定解決方案并最終成功解決問題。1.自主可控芯片單核計算性能低，GBase 8a MPP Cluster對 SQL 執行的每個階段都可以多線程并行，充分發揮海光等芯片的多核特性提升性能。2.NUMA 架構服務器跨 NUMA Node 內存訪問性能損耗大，采用多實例部署方式，在一個海光芯片服務器上部署兩個計算節點實例，每個節點實例綁定一組相鄰的 NUMA Node，降低跨 NUMA Node 內存訪問帶來的性能損耗，同時提高了服務器資源的利用率；在每個芯片服務器上部署兩個計算實例，達到與 Intel 服務器同等的性能。四、四、應用成效及經驗應用成效及

94、經驗 GBase 8a MPP Cluster 助力中國銀行完成了全部 Intel 服務器環境下 GBase 8a MPP Cluster 集群環境的全棧創新升級。18 通過產品的適配優化，確?；趧撔聭闷脚_的大數據查詢分析性能不下降。1.提升性能，實現我國芯片平臺與 Intel 服務器的一比一創新升級 GBase 8a MPP Cluster 針對創新應用平臺進行了全面的優化改造，通過多實例部署、編譯參數優化、硬件加速優化提升GBase 8a 在 NUMA 架構的自主可控芯片服務器整體性能，相比于優化前性能大幅度提升。2.提升適配性，滿足全棧創新應用平臺要求和異構混搭需求 GBase 8a

95、 MPP Cluster 實現了對全棧創新應用平臺的適配，支持海光芯片、鯤鵬芯片、飛騰芯片、申威芯片等服務器，支持銀河麒麟、統信 UOS、中科方德等操作系統；支持異構平臺混搭，滿足用戶對于多種異構的自主可控服務器的使用需求、Intel 服務器利舊的使用需求、異構平臺雙活的需求。3.滿足高可用能力要求 GBase 8a MPP Cluster 的管理集群、數據集群都采用多活架構，無單點故障；支持在線節點替換，優化在線節點替換性能大幅度提升；在創新應用環境建設初期，偶發的服務器故障不影響集群運行，不中斷業務，故障節點處理更平滑。19 案例五：建設銀行核心系統案例五：建設銀行核心系統 GoldenD

96、BGoldenDB 應用實踐應用實踐 一、一、應用場景應用場景 建設銀行現有對私核心采用 GoldenDB 分布式數據庫，實現Z 系列主機為代表的現有對私核心系統進行分布式改造。新核心承接承載 8 億用戶信息、存款、貸款、轉賬等核心關鍵應用。2021年 3 月實現全網并網運行，2022 年 12 月完成十個省分公司對私客戶在 GoldenDB 分布式數據庫投產，系統投產至今運行穩定。二、二、總體方案總體方案 建設銀行分布式系統總體技術架構包含應用路由、服務集成代理、配臵中心、分布式數據庫等主要組件。其中分布式數據庫組件使用 GoldenDB 分布式數據庫。各組件構成有機整體，實現大型系統靈活路

97、由和高并發處理能力。具體如下：圖 1 應用總體技術架構 應用路由應用路由負責交易請求的跨平臺路由，查詢配臵中心接口，如屬于本地 Region 的交易請求，發往本地應用集成代理層就地處理，否則將請求轉發至交易歸屬 Region 的應用路由，后者接 20 收到請求后會將請求轉發給與其同 Region 的服務集成代理處理。服務集成代理服務集成代理負責跨系統事務一致性處理。服務集成代理會將單筆轉賬交易拆解成一筆轉出交易和一筆轉入交易，每筆交易都會同時準備好相應的沖正交易數據。此外，在系統投產過程中，一支業務的部分數據還在主機平臺，部分數據在分布式平臺，這種情況也由服務集成代理跨平臺協調一致。產品服務層

98、產品服務層提供銀行業務的具體服務，包含各產品服務，是整個信息系統的主要業務組件，包括主機平臺、C 平臺和 JAVA平臺。開放平臺上引入 GoldenDB 分布式數據庫，承載原來主機平臺上的數據庫服務。GoldenDBGoldenDB 分布式數據庫分布式數據庫提供大規模數據存儲和高并發數據庫訪問能力。GoldenDB 實現數據多分片、彈性擴容和分布式事務強一致讀寫，通過數據多副本、快同步、分組管理、備份恢復等技術，實現大規模數據庫的高可用、高可靠，以及多地多中心容災能力。全網對私核心有 8 億用戶數據，百 T 級別數據規模，并發處理要求高，系統采用大單元機制，在一套 GoldenDB 集群下創建

99、四個租戶集群(見下圖 C1 到 C4),每個租戶有 25 個數據分片，分別部署在四個數據中心。同一數據中心內的請求均由同一數據庫租戶處理，無需應用層協調分布式事務，這顯著降低跨服務集成代理跨子系統處理的業務吞吐量，減少資源壓力。21 圖 2 對私核心業務數據庫系統框架 三、三、難點問題及應對舉措難點問題及應對舉措 降低應用分布式處理壓力。降低應用分布式處理壓力。引入 GoldenDB 分布式數據庫前，原方案采用細粒度單元設計，平均每個分行為一到兩個單元。在該方案下服務集成代理需要協調數十套單元間事務一致性，既要負責處理跨分行之間的事務操作，同時要負責處理同一家分行跨多個服務單元的事務操作，應用

100、的分布式事務調度壓力過大。綜合決策后，基于 GoldenDB 數據庫調整為大單元設計，即將全國用戶按區域分成四個大片區，片區內用戶的轉賬等分布式事務交給數據庫處理，簡化后服務集成代理的分布式處理壓力大大減少。簡化配臵中心數據管理。簡化配臵中心數據管理。項目初始設計方案采用集中式數據庫進行小單元設計，由于數據庫單元數量過多，需要在配臵中心上配臵大量業務處理單元的定位信息和路由數據,維護和變更復雜。通過 GoldenDB 的多租戶管理、租戶內分布式強一致處理能力，將全網用戶集中到四個大單元，大大簡化了業務處理單元 22 的定位信息和路由數據，路由信息未來十年無需修改。四、四、應用成效應用成效 建設

101、銀行于2021年3月基于GoldenDB實現對私核心全國并網運行，到 2022 年 12 月已有十個省分公司對私客戶在 GoldenDB分布式數據庫投產，對私核心請求達 8000+TPS，系統投產至今運行穩定。本項目實現兩地 4AZ 多地多活部署、性能容量線性擴展，解決了應用從主機平滑遷移到分布式數據庫的難題，滿足業務未來發展需求，是國內大型銀行 Z 系列主機核心應用系統多地多活分布式改造的典型實踐案例，可為其他大中型銀行提供借鑒參考。23 案例六：交通銀行核心系統案例六：交通銀行核心系統 OceanBaseOceanBase 應用實踐應用實踐 一、一、應用場景應用場景 貸記卡作為滿足人民美好

102、生活需要的金融載體，在暢通市場循環、產業循環中持續發揮重要作用，且客戶群體廣泛，具有示范代表意義。交通銀行貸記卡核心系統支撐著交行上億客戶交易，從大型主機下移到 x86 服務器，數據庫升級至我國原生分布式數據庫 OceanBase，實現了貸記卡核心系統的高性能、高擴展、高可用。二、二、總體方案總體方案 交通銀行核心貸記卡系統采用單元化多機房多活整體解決方案，OceanBase 數據庫提供兩地四中心五副本+主備庫高可用方案，備集群部署在兩地，提供城市級的容災方案。系統采用單元化微服務架構，控制故障影響范圍，減少故障爆炸半徑。新一代分布式云計算平臺是交通銀行分布式信息系統建設關鍵“底座”，也是未來

103、分布式技術框架的核心。結合貸記卡系統重構建設，新云平臺按照全行一體化協同、一體化運維、一體化分布式技術棧的建設要求，對城市 A 中心、同城中心、城市 B中心和測試云等多個環境進行規劃和建設。交通銀行的架構方案采用阿里云+SOFA+OceanBase單元化多機房多活整體解決方案。OceanBase 提供兩地四中心五副本+主備庫高可用方案。OceanBase 采用同城三機房容災部署架構+異 24 地主備集群架構。其中 OceanBase 主集群采用“2+2+1”五副本方式部署，通過 Paxos 協議保證同城三機房數據強一致性；同時上海同城機房多活，可按照流量比例進行調撥。比較特殊的是，因為應用系統

104、只是簡單的主備架構，不能夠像 OceanBase 一樣是多地多中心，為了防止主機房出現雙斷，OceanBase 除了在某城市有一個備份集群，還在主機房增加了一個備份集群。這種部署也顯示了 OceanBase 的靈活性。三、三、難點問題及應對舉措難點問題及應對舉措 交通銀行原貸記卡核心系統使用 IBM 大型機+CICS+DB2 for zOS 的技術體系，整體架構穩定但技術棧封閉、很難水平擴展，且 IT 投入巨大，無法滿足快速增長的業務量和快速響應各種新的業務需求。此外，一是容災標準高。交通銀行貸記卡核心系統支撐著交行上億客戶交易，需要滿足 7x24 小時持續服務，高可用容災要求達到 5 級。二

105、是建設成本高。原有核心系統基于傳統大機和 DB2 數據庫的封閉模式運行架構，IT 建設成本高昂。三是備機房資源浪費。近年來隨著業務并發量的不斷增加，數據庫系統處理能力不足的問題凸顯。冷備機房隨時待命但不提供數據服務，資源利用率低。交通銀行采用 OceanBase 作為其分布式信息系統建設關鍵“底座”和核心，幫助交通銀行整體 IT 體系向新一代云平臺、分布式架構全面轉型。25 四、四、應用成效及經驗應用成效及經驗 交通銀行貸記卡核心系統“大機下移分布式”，降低了主機mips 的消耗，每年節約 IT 成本數千萬元。貸記卡核心系統實現兩地四中心 5 級容災，滿足 7x24 小時服務要求。采用單元化微

106、服務架構，控制故障影響范圍，減少故障爆炸半徑。采用跨中心分布式單元化批量運行框架，實現核心系統雙中心同時跑批、多單元并行處理，解決單元化文件拆分合并、跨機房文件傳輸等難點，提升資源利用率和批處理效率。交通銀行貸記卡系統屬于 A 類核心業務系統，其上云實現了國有大行核心系統從 IBM 大機集中式架構，向云上分布式單元化金融級架構的技術轉型。目標支撐上億卡量，千萬級別的日均交易量，并通過“同城雙活+異地災備”的兩地三中心容災架構，確保核心業務 RPO 為 0。生產環境性能測試已達到金融類交易6000TPS+非金融類交易 20000TPS 的目標值。26 案例七：郵儲銀行新一代個人業務核心系統案例七

107、：郵儲銀行新一代個人業務核心系統 GaussDBGaussDB 應用實踐應用實踐 一、一、應用場景應用場景 核心系統是銀行 IT 系統建設的重中之重，是一家銀行的大腦和心臟。其中，統一查詢系統是核心系統中的重要組成部分，該系統承載著柜員和客戶關于歷史交易明細、賬戶信息等多個場景的查詢以及實時收支分析的任務。系統擁有百 TB 級的海量歷史數據、千億級單表數據量，高峰期需面對上萬的用戶并發量，規模龐大、場景復雜、數據量巨大的業務特點對數據庫大容量、高并發、高可用、高性能提出了極高的要求，這些要求，對任何傳統商業數據庫來說都是巨大挑戰。二、二、總體方案總體方案 （一）項目實施模式 雙軌。舊核心和新核

108、心進行并跑，逐步將舊核心數據遷移到新核心，直到完全替代。（二）實施周期 2019 年 9 月：新一代個人新核心建設啟動 2021 年 4 月：技術平臺投產 2021 年 7 月：運維平臺投產 2021 月 10 月：首批業務投產（國際匯款）2022 年 4 月：新核心全功能投產 27 （三）數據遷移 原系統數據通過離線 CSV 文件導入的方式導入新系統，通過白名單方式進行逐批次的客戶遷移，進行路由策略配臵。三、三、難點問題及應對舉措難點問題及應對舉措 從傳統數據庫往分布式數據庫轉型的過程中，面臨如下痛點問題：1.高可用挑戰大：業界常用的數據庫方案只能部署在跨園區的單 Region 中，不能滿足

109、高等級應用的高可用要求。2.性能容量挑戰大：大型業務系統高峰期 TPS 近萬/秒，單庫幾十 T，對基礎設施及數據庫的性能容量提出了較大的挑戰。3.擴展性不足：傳統的集中式數據庫由于架構限制，往往采用一主一備，即使是 Oracle RAC，由于共享存儲的限制，也最多只能擴展 2 到 4 個節點，單集群的容量容易出現瓶頸。4.安全性有待提升：近年來隨著大眾對保護個人信息意識的提升，以及各國家地區紛紛出臺數據安全相關的政策法規，如何保護數據安全隱私的問題受到重大的關注，同時也是工業界與學術界研究的熱點問題。5.數據同步挑戰大：大型業務系統高峰期超過幾百 G/小時數據歸檔量，對新舊系統雙庫并行期間的數

110、據同步效率要求極高。華為云 GaussDB 采用行業先進的全并行分布式架構，通過多個節點并行分擔系統壓力，提供極致吞吐量；還擁有超大存儲容量，支持事務的強一致性；在數據保護方面，提供兩地三中心的 28 容災方案和多層級冗余保障數據的實時安全，實現系統無任何單點故障。四、四、應用成效及經驗應用成效及經驗 系統上線后可支撐海量交易、彈性伸縮、金融核心級高可靠和高可用，可具備為全行 6.5 億個人客戶、4 萬個網點提供日均20 億筆，峰值 6.7 萬筆/秒的交易處理能力。郵儲銀行新一代個人業務核心系統全面投產上線，使郵儲銀行科技金融再添一部新引擎，將為郵儲銀行提供源源不斷的科技動能，加速建設“一流大

111、型零售銀行”。同時鯤鵬、openGauss開源數據庫與 GaussDB 分布式云數據庫將繼續全力支持郵儲銀行數字化升級，共同為同業積累經驗，探明路徑，樹立標桿。該系統同時采用企業級業務建模和分布式微服務架構，是中國銀行業金融科技關鍵技術可控的重大實踐。業務處理性能 5 倍提升，由原來的 1 萬筆/秒提升到 5.5 萬筆/秒，支取響應提升25%，查詢響應提升 27%。支持 500T 超大數據存儲，10 年超長數據查詢范圍。29 三、三、股份制銀行股份制銀行 案例八：平安銀行信用卡核心系統案例八：平安銀行信用卡核心系統 TDSQLTDSQL 應用實踐應用實踐 一、一、應用場景應用場景 平安銀行早期

112、的系統建設以 IOE 架構為主，近年來隨著業務快速發展，系統的數據量和負載爆發增長，平安銀行系統升級改造時選擇了具有彈性擴容、高可用、高性能等優勢的分布式數據庫,可以有效的支持海量、高并發、高吞吐量的新型金融業務應用系統。其中平安銀行信用卡新核心是我們探索應用我國分布式數據庫并應用核心業務系統的具有里程碑意義的一步。二、二、總體方案總體方案 平安銀行信用卡新核心選用騰訊云企業級分布式數據庫TDSQL，構建了一套能夠快速實現業務交付且靈活富有彈性的核心系統來替代以傳統集中式數據庫為主的老核心系統，同時建設了一整套企業級全棧式服務化的技術中臺。數據庫采用典型的兩地三中心、一主五備的部署架構，實現了

113、同城多活、異地容災、一鍵切換等需求，提高系統的并發處理、隔離故障和靈活擴展能力，具備讀寫分離、自動分片、主備強一致、實時監控、實時冷備等功能；在運維層面，基于 TDSQL 建設一套全鏈路的分布式運維工具。30 圖 1 部署架構 信用卡新核心系統采用單元化 DSU 分布式架構，基于私有云和 PaaS 平臺建設，應用微服務化，拆分解耦。DSU 整體設計邏輯采用按客戶維度進行分片，由 GNS 去負責解析，完成分片，由DLS 實現分片的路由，分片內部實現自包含，客戶的業務均可以在單個分片完成，包括交易授權、用卡業務，也包括批量業務。圖 2 信用卡業務單元架構 三、三、難點問題及應對舉措難點問題及應對舉

114、措 31 分布式單元化架構的采用會帶來的主要問題：1.分布式架構建設和改進的工作量大，需要配套建設的分布式工具也很多。2.過度單元化可能會帶來很多問題，比如上下游業務不均衡帶來的小業務被動單元化，以及單元化帶來的應用層和數據庫層的資源浪費等。應對措施：1.平安銀行信用卡新核心單元化架構基于專門打造的分布式 PaaS 平臺，應用在進行單元化分布式改造時盡可能只關注業務邏輯的實現，而平臺架構、數據庫和各種工具交給 PaaS 層。2.數據操作盡可能規避分布式事務，以保證系統的健壯性。在業務邏輯上，盡可能實現單元內業務自包含。如果一定要進行分布式事務，考慮在框架層支持，如果框架層也不能支持時由業務保證

115、。3.在 DSU 之外，為了滿足聚合查詢、分析、歸檔需求，建設一套 Sharding 版的 TDSQL，用于實現聚合的查詢，支持全量、增量以及實時的數據同步；同時為了完成數據歸檔，建設了一套Hadoop 集群作為歸檔數據平臺。四、四、應用成效及經驗應用成效及經驗 平安銀行信用卡新核心是由大型機集中式架構遷移到PC 服務器分布式架構系統的成功案例，業務系統完全自主可控。在成本方面，根據實際的測算，以 5 年為周期，新核心系統相比老 32 系統成本節約近 70%，節省費用超 10 億。在可靠性方面，通過可視化分布式調度平臺，支持金融級高可用，同城雙活異地災備，故障場景下秒級切換。在性能方面，能夠支

116、持 10 萬+業務作業統一處理、跨地域分布式調度以及可視化管理，滿足金融級核心系統的要求，支持 10 萬 TPS 交易高并發，相比老系統的交易處理能力提升了數十倍，日終業務批處理小時級時效。2020 年上線至今，已經穩定運行 3 年，經歷了各種節日或者業務促銷，以及各種各樣的軟、硬件故障，總體運行情況符合預期。同時，經過多年的探索和實踐，平安銀行已經基本掌握了一整套適用于各種業務場景的分布式架構，在分布式數據庫應用場景上也將不斷擴展、深入，加大我國數據庫的應用力度、加快原有系統升級改造，推動金融業數據庫創新向深入發展。33 案例九：光大銀行新一代信用卡核心系統案例九：光大銀行新一代信用卡核心系

117、統 GoldeGoldenDBnDB 應用實踐應用實踐 一、一、應用場景應用場景 光大銀行原有信用卡核心系統受限于傳統主機核心系統的業務與應用架構，在整體業務規模加速增長的趨勢下，難以有效支撐銀行信用卡業務快速、靈活、彈性與創新的發展需要，為此基于 GoldenDB 分布式數據庫建設新一代信用卡綜合管理系統。新一代綜合業務管理系統面向全網用戶實現賬戶管理、信用卡申請處理、信用卡授權模塊、交易管理、分期支付、會計處理、國際卡組織清算等信用卡業務服務。二、二、總體方案總體方案 光大銀行信用卡新一代綜合業務管理系統使用單元化設計、多地多活等先進設計理念，將原有的核心業務按照客戶維度劃分為六個業務單元

118、、一個灰度單元和一個全局單元。六個業務單元分別部署在不同的數據中心接管業務，并且在其他數據中心具有災備能力。本地多中心能夠實現數據的實時一致性復制，保證本地任何一個數據中心與主中心都能實現 RP0=0，災備中心可以實現準實時災備。該技術架構可以實現業務按照單元化進行靈活處理，控制故障半徑，數據中心資源使用率高，支持灰度升級，在極端情況下一個數據中心即可承載全部業務。34 圖 1 信用卡新一代綜合業務管理系統架構 三、三、難點問題及應對舉措難點問題及應對舉措 新應用迭代投產前如何進行生產試運行驗證，是單元化方案的關鍵技術挑戰。項目組通過多種參考方案對比和行內論證，最終使用灰度客戶數據，基于 Go

119、ldenDB 多租戶實現灰度單元方案，創建獨立的 GoldenDB 租戶單元，將銀行職員作為受控灰度驗證的客戶群，存儲于灰度租戶單元中。每次應用新版本發布前，先在該灰度單元進行灰度發布，驗證沒有問題后再發布到其他業務服務單元上?；叶葐卧O計具有靈活的可用性，故障不會影響其他業務服務單元的運行和服務質量；同時用于灰度驗證的都是受控客戶，從內部的銀行職員開始驗證，整個灰度發布過程更加可控；該方案灰度用戶總是在灰度單元里，每次灰度發布時無需數據搬遷，管理機制更加簡單一致。四、四、應用成效應用成效 光大銀行信用卡新一代綜合業務管理系統于 2023 年 3 月上線，支持 1 億客戶量、2 億卡量，支持日

120、常金額交易 1000tps，35 電商活動高峰期 5000tps，查詢維護類交易 6000tps，授權交易平均響應時延小于 60ms，查詢維護類交易響應時間小于 50ms，每日主批運行時間小于 2 小時。系統提供有效的安全保密措施，確保系統和數據資源的安全，應用和數據庫均具備良好的在線擴容能力，極大提升了該銀行信用卡業務處理性能，很好支持信用卡業務的需求和信用卡核心技術創新的持續演進，提升以數據為驅動的數字化轉型升級能力。36 四、四、城市商業銀行城市商業銀行 案例十：北京銀行分布式核心系統案例十：北京銀行分布式核心系統 TiDBTiDB 應用實踐應用實踐 一、一、應用場景應用場景 面對海量數

121、據、高并發的挑戰，北京銀行分布式核心系統采用“微服務架構+分布式數據庫”的建設方案，構建起一套支持高并發、高可用、可橫向擴展的分布式核心系統解決方案。對接網聯支付清算平臺、銀聯無卡快捷支付平臺、金融服務互聯平臺、網貸業務平臺等多個核心金融業務場景，實現了將分布式數據庫解決方案應用于銀行核心類業務場景。二、二、總體方案總體方案 兩地三中心部署 TiDB 集群，采用主從的多活架構，主集群作為生產集群承擔日常的生產服務，主從之間采用 Kafka 同步 Binlog 的形式進行數據同步。圖 1 分布式數據庫架構圖 37 北京銀行首先在網聯支付清算平臺和銀聯無卡快捷支付系統引入 TiDB 分布式數據庫，

122、以便更好地迎接互聯網金融帶來的大數據量和高并發的挑戰。系統投產之后，已經成功應對兩次雙十一挑戰。北京銀行 IT 團隊進行多次線上的運維操作，包括版本升級、打補丁等，利用 TiDB 分布式數據庫的多副本特性實現“運維零中斷”的操作。隨著系統升級，北京銀行的網聯業務鏈，包括上游的手機銀行到網聯、銀聯無卡快捷支付業務中臺，到后臺的金融日歷、查詢服務都已經進行了分布式架構的升級，完成了與 TiDB 的對接。三、三、難點問題及應對舉措難點問題及應對舉措 隨著業務的快速增長，數據庫成為基礎設施鏈條里面最大的瓶頸。在大規模數據和高并發場景下，需進行數據庫分布式改造。北京銀行使用 TiDB 分布式數據庫系統承

123、載業務，解決在大數據量高并發壓力下的處理性能瓶頸。利用分布式系統的敏捷擴展能力提升交付運營效率，實現在線彈性資源伸縮，支持跨數據中心雙活的數據庫系統架構，并利用行列共存的方式，解決 OLTP 和OLAP 場景不同的業務需求。四、四、應用成效及經驗應用成效及經驗 北京銀行分布式核心系統建設項目榮獲 2020 年度亞洲銀行家“中國最佳核心銀行技術實施”大獎，從四個方面全面提升北京銀行的金融服務能力：38 1、提升系統性能 通過分離處理功能、分散處理壓力、擴展處理能力等措施，保障海量數據、高并發的業務場景對接，大幅提升交易處理效率。2、滿足安全要求 基于一致性算法保證交易數據的強一致性，依托數據日志

124、的備份恢復能力，提升數據的可追溯性，滿足監管要求，提高自動化運維能力。3、具備在線橫向擴展能力 5 小時內實現 5 億條數據的在線擴縮容，整個過程對業務系統無侵入，保證了在線業務的連續性。4、提升金融服務能力 分布式核心系統具備產品快速創新、差異化服務等能力，助力商業銀行構建以客戶體驗為中心、產品豐富、核算分離的核心業務系統。39 案例案例十一：北京銀行分布式核心核算引擎十一：北京銀行分布式核心核算引擎 OceanBaseOceanBase 應用實踐應用實踐 一、一、應用場景應用場景 針對數字化轉型重點任務，北京銀行分布式核心系統采用分布式數據庫升級改造建設方案，其中核算引擎系統作為承載北京銀

125、行全行級的、統一的、標準化的、可靈活配臵核算規則的會計核算平臺，是北京銀行分布式數據庫升級改造的重點系統之一。二、二、分布式改造優化方案分布式改造優化方案 核算引擎分布式數據庫升級改造項目，采用將主任務拆分為多個子任務，多 POD 并行調用方案，經過負載均衡服務，發送至分布式數據庫多副本多服務器內，充分利用分布式數據庫架構，調用所有數據節點計算資源，并行處理大規模計算任務。圖 1 北京銀行分布式核心核算引擎系統架構圖 三、三、難點問題及應對舉措難點問題及應對舉措 隨著業務的快速增長，銀行內部的日終、月終匯總計算面臨著海量數據計算需求的艱難挑戰，分布式數據庫的優勢在于大規模數據和高并發場景下的

126、OLTP 類業務處理，但 OLAP 類海量數據 40 計算仍與集中式數據庫存在性能差距。為應對分布式數據庫升級改造后的性能下降，項目組針對分布式數據庫架構特點，采用串行任務拆分為并行執行、源表復制至目標端場景改造為表組綁定分區、單筆循環改為批量提交等策略，解決了分布式數據庫數據分散導致 AP 類計算請求性能底下的問題，同等數據量級下執行效率甚至超過了原集中式數據庫。四、四、應用成效及經驗應用成效及經驗 北京銀行分布式核心核算引擎 OceanBase 應用實踐，彌補了北京銀行 OLAP 系統進行分布式數據庫升級改造的技術短板，成為了分布式數據庫開發設計、性能調優的優秀案例，從三個方面全面提升北京

127、銀行的金融服務能力：1.提升系統性能 充分利用分布式數據庫特征，分散處理壓力，針對海量數據計算需求，提升處理效率。2.具備在線橫向擴展能力 分布式數據庫多節點計算，針對業務發展導致的數據量增長場景，快速擴充服務器資源。3.提升金融服務能力 分布式數據庫自帶的多副本架構，具備兩地三中心五副本等容災能力，為北京銀行節能增效，數字化轉型提供有效支撐。41 案例十二：北京銀行基于案例十二：北京銀行基于 CirroDataCirroData 和和 BEHBEH 的湖倉一體建設應的湖倉一體建設應用實踐用實踐 一、一、應用場景應用場景 北京銀行在分析系統領域使用了 GP、Netezza、Oracle 等多種

128、數據庫，來滿足各類場景要求，且還不能很好的滿足業務的功能需求和性能需求。為此經過全方位的充分驗證測試，最終采用東方國信的 CirroData 和 BEH 進行了全面升級優化，建設了真正意義上湖倉一體的大數據云平臺。大數據云平臺實現了如下重要功能：數據查詢支持：查詢平臺從Netezza平滑遷移到CirroData，并提升了查詢效率；數據服務支持：每天調用量超過幾千萬次，響應時間為 100毫秒以內，并發支持 1000 以上；高性能處理支持：公檢法系統遷移到 CirroData 后，處理性能提高接近 100 倍，原來 1 個多小時的任務縮小為 1 分鐘。目前，累計部署服務器 500 臺以上，有效存儲

129、空間超過 7PB，且使用常規的高性價比服務器，綜合成本得到大幅降低。二、二、總體方案總體方案 北京銀行大數據云平臺整體規劃如下：42 圖 1 部署規劃圖 根據業務需求劃分多個集群，其中數據湖區單獨部署一個集群，部署 CirroData，存放貼源數據。倉庫集市區單獨部署一個物理集群，在此集群上部署兩個獨立的 CirroData 集群，分別存放數據倉庫和數據集市。實時數據區單獨部署一個集群，采用BEH 和 CirroData 混合部署，滿足各類實時場景需求。應用服務器單獨部署一個集群，采用 BEH 和 CirroData 混合部署，滿足各類應用場景實際需求。沙箱區單獨部署一個集群，采用 BEH 和

130、CirroData 混合部署，滿足各類實時場景需求。以上集群均采用常規高性價比服務器。歷史區單獨部署一個集群，主要部署CirroData，存放歷史數據，采用低計算高存儲的服務器，降低存儲成本。另外非結構化數據平臺單獨一個集群，主要部署BEH，存放非結構化數據。對于數據湖和數據倉庫、數據集市的存儲規劃如下圖所示：43 圖 2 數據架構圖 儲算平臺分為三部分：1.首先是基礎數據區，里面包含了結構化數據和非結構化數據。結構化的貼源數據對應傳統的 ODS，加上原始的非結構化數據對應常規概念的數據湖；主題模型數據和匯總數據對應傳統的數據倉庫；數據集市區對應傳統的多個數據集市；維度寬表數據對應數據中臺中的

131、企業級維度模型。2.基礎數據區上面是應用數據區，里面存放應用系統專用的數據。3.還有元數據區，存放數據平臺的統一的元數據信息。在技術上，結構化數據存儲統一采用新一代 MPP 數據庫存儲，非結構化數據目前仍建議采用大數據技術存儲，如 HDFS+ES+Hbase 等組件進行存儲，一般大文件可直接放到 HDFS 上，小文件建議存到 Hbase 中，未來還可引入 OSS 對象存儲。而數據的采集、處理和特定計算可依托 Hadoop 生態組件實現，從而實現新一代 MPP 數據庫和 Hadoop 生態的有機結合。44 三、三、難點問題及應對舉措難點問題及應對舉措 北京銀行采用新一代 MPP 數據庫 Cirr

132、oData 和 Hadoop 發行版 BEH 產品，并在此基礎上開發了全套完整配套產品和解決方案，解決了自身的如下痛點問題：統一部署：CirroData 和 BEH 可以統一部署，使用一套分布式文件系統，可以按需部署，避免了傳統的數據庫和Hadoop 必須獨立部署，數據底層共享，大大減少處理環節，增加數據共享能力；集中統一存儲：避免了企業內數據在多個組件中冗余存放，以解決不同場景問題，結構化數據主要存儲在 CirroData中，非結構化數據主要存儲在大數據組件中，且確定 ES、Solr 或 OSS 等，在企業內形成標準化規范，而 CirroData的處理性能和聯機查詢性能也保證了企業內的大部分

133、應用場景，只是針對特定數據的特定應用場景才需要使用特定組件進行數據緩存，而且是單向處理，大大簡化了企業內數據管理的復雜度和冗余存放；開發統一化：由于大部分操作尤其 90%以上是對結構化數據處理，均可基于 CirroData 產品完成，因此大部分開發人員只需掌握這一個產品，且以 SQL 操作為主，大大降低了企業的學習成本；成本降低：CirroData 支持 X86 服務器和多種我國設備產品，并有多個實際案例，整體使用成本大大降低，完全可 45 以以最優性價比在全企業推廣，支持多種場景；配套解決方案：除了產品以外，東方國信湖倉一體解決方案包含咨詢規劃能力、專業開發實施、專業運維服務和配套產品，提供

134、全面服務，保證了湖倉一體平臺的持續建設。四、四、應用成效及經驗應用成效及經驗 從使用 Oracle、Netezza、GP 等多個傳統數據庫產品，到集中使用了 BEH 和 CirroData 產品，建設了統一的數據湖，已經落地了數據湖區、倉庫集市區、應用數據區、沙箱數據區、歷史數據區、實時數據區等，建設了數據沙箱平臺、數據服務平臺、實時數據平臺、非結構化數據平臺、數據開發平臺、運營監控平臺、對公數據集市等多個數據集市，新建或遷移了公檢法查詢等幾十個相關應用系統。數據湖項目的建設逐步統一技術路線，標準化了開發流程和規范，提升了面向業務的響應時效，滿足了之前不能實現或實現困難的系統和功能。46 案例

135、十三：貴陽銀行信用卡管理平臺案例十三：貴陽銀行信用卡管理平臺 SUNDBSUNDB 應用實踐應用實踐 一、一、應用場景應用場景 貴陽銀行信用卡管理平臺項目結合貴陽銀行信用卡業務發展方向，采用信息技術解決方案，包括操作系統、中間件以及數據庫等關鍵技術，建設了信用卡管理平臺。在保證信用卡檔案管理線上化安全性的基礎上，平臺整合各信用卡業務平臺，支持貴陽銀行信用卡檔案的統一管理。減少信用卡部日常人工操作，降低人力成本及操作風險；最終實現對檔案的長期保存、智能查詢和科學管理。貴陽銀行總行信用卡部、管理行以及其下屬的分支行，共計約 200 多家機構使用信用卡管理平臺進行檔案相關的管理工作。使用的功能和場景

136、包括總行檔案管理員、檔案操作員每日查看業務辦理流水，包括客戶申請卡片、投訴、寄遞、客戶信息修改、賬務類、核銷等不同類型的業務，然后查看流水關聯的影像，包括申請表、身份證信息、收入證明、房產證明、電核錄音、主卡人職務證明材料等不同的材料，并對差錯檔案下發資料缺失、或者資料與實際不符等補錄任務，分支行再在管理行的監督下進行檔案的補錄以及上傳，最后由總行審批無誤后進行檔案的歸檔，以及對檔案進行查詢、下載以及調閱等應用。二、二、總體方案總體方案 貴陽銀行采用云上鯤鵬服務器 RH220T（芯片 HUAWEI Kunpeng 47 920 5220）、統信 UOS1020E 操作系統、科藍 SUNDB 5

137、.0 數據庫、東方通 TongWeb7.0.4.4 中間件的技術路線。系統采用前后端分離技術，按照模塊化開發、通過輕量化的 RPC 框架進行通信。貴陽銀行信用卡管理系統支持分布式部署和支持集群部署方式，提供靈活的可擴展能力。支持負載均衡處理機制，有效避免單點故障，以滿足災備部署要求。系統支持生產服務器與備份服務器同時投產的雙活模式，災備建設能支持雙活中心部署的運營模式，同時本系統采用前端業務分離部署，根據需求通過網絡對松散耦合的粗粒度應用組件進行分布式部署、組合和使用,使用服務的方式暴露接口,可高效快速的集成其他微服務系統,減少風險、人員成本和系統壓力，從而保證了部署的易操作性、可復制性以及可

138、參考性。最終在完成信息安全和創新目標的同時，實現小而自治，高內聚、低耦合，從而降低系統的復雜性，大幅降低系統建設、運維、升級帶來的風險和成本。圖 1 總體方案圖 48 三、三、難點問題及應對舉措難點問題及應對舉措 貴陽銀行信用卡部現狀，目前檔案管理流程最主要的痛點在于紙質檔案收集繁瑣，審批周期長，且不便于對檔案管理這類保密性工作進行業務監督。因此建設本系統最主要的目的是解決安全可控問題，并解決業務問題。1.安全可控問題，基于創新技術軟硬件底層架構和全周期生態體系，解決核心技術關鍵環節安全可控的問題。2.業務上檔案收集、審批流程長等問題，通過優化流程、信息化采集等技術手段解決。3.大字段數據類型

139、轉換問題，源數據使用特定的大字段，遷移 SUNDB 時面臨接口不兼容情形，為避免較多的代碼修改，由SUNDB 開發兼容性接口解決。四、四、應用成效及經驗應用成效及經驗 貴陽銀行基于信息安全基礎軟硬件、SUNDB 數據庫構建的信用卡管理系統，完美地承載了信用卡管理業務的需求，促進了數字化業務發展，增強了數字化業務競爭實力。貴陽銀行信用卡業務系統自建設之初，就對系統的可靠性、安全性和系統性均提出了極為嚴格的要求?？扑{軟件采用 SUNDB數據庫針和微服務方式管理，能夠根據業務需要動態橫向擴展，保證了系統的高性能的靈活擴展性。此外還部署了實時同步系統，保證了數據災備的同時，也提供了實時全量備份。49

140、圖 2 數據庫架構圖 50 案例十四：江西銀行企業網銀系統案例十四：江西銀行企業網銀系統 SUNDBSUNDB 應用實踐應用實踐 一、一、應用場景應用場景 江西銀行選擇科藍軟件對企業網銀系統進行技術架構升級以及業務重構，聯合建設基于全棧創新技術的企業銀行系統，提高金融產品研發效率，提升客戶業務處理能力。江西銀行企業網銀通過對傳統單體應用的電子渠道系統進行了深度分析與重構，建設基于分布式微服務架構的中臺化電子渠道統一平臺，具有顯著的業務效果。首先是增強了系統的并發能力和橫向擴展能力。其次是前端引入客戶端的熱更新及灰度發布能力，實現客戶端無感更新，且功能布局可通過后管進行動態調整，隨時隨地高效地響

141、應客戶需求變化，提升客戶體驗。江西銀行基于我國基礎軟硬件，采用虛擬化技術、分布式微服務架構、SUNDB 分布式數據庫，并按照分布式數據庫特點進行數據模型設計，充分發揮分布式數據庫的計算、存儲的優勢，支撐用戶高并發、高性能的需求，達到應用、存儲的主機下移的目標，并真正實現了基礎軟硬件的自主可控，同時避免了不必要的硬件資源浪費。二、二、總體方案總體方案 江西銀行企業網銀系統采用科藍“雙魚座”中臺，支持分布式微服務；數據庫采用科藍自主知識產權的 SUNDB 分布式數據庫；操作系統和 CPU 也采用我國的成熟產品。整合 PC 網銀、APP 客 51 戶端、現金管理用戶體系，打造企業互聯網統一平臺，并需

142、支持IPV6 和全棧商用密碼算法。圖 1 總體方案圖 企業網銀系統是行內第一個創新技術的關鍵系統，采用了微服務架構、分布式數據庫等技術，同時也是業內基于全棧創新技術的關鍵類系統的案例之一。1.基礎軟硬件創新，包括服務器、操作系統、數據庫、中間件等全面創新，擺脫對國外廠商的依賴，產品服務的可持續性不受外部環境因素影響。2.通過使用 SUNDB 分布式數據庫實現計算下沉，實現數據存儲層的線性水平擴展能力。3.使用 SUNDB 分布式數據庫進行業務數據的存儲，并按照分布式數據庫特點進行數據模型設計，確保發揮分布式數據庫的最大優勢。4.通過應用的分布式微服務架構，實現計算能力的下移，并且能夠實現線性擴

143、展、穩定性運行、性能提升和高可用，避免對 52 主機計算能力的依賴。5.構建開放敏捷的全新技術體系框架，滿足未來的 IT 發展和業務需求，滿足數字化轉型所需要的彈性、敏捷和協同共享等。三、三、難點問題及應對舉措難點問題及應對舉措 江西銀行升級改造過程中面臨如下幾方面的問題，通過江西銀行與 SUNDB 廠商、服務器廠商、操作系統廠商的緊密合作，完成問題解決方案和問題解決。1.數據同步問題，基于小型機的DB2與基于創新CPU的SUNDB解析數據的方式不同(大小端格式問題)，小端序系統和大端序系統通信時會發生數據解析錯誤，因此在發送數據前，要將數據轉換為統一的格式。2.分布式數據模型設計問題，傳統數

144、據庫在進行數據模型設計時可以按照數據庫設計范式，分布式數據庫因為將數據進行了分布，業務操作會涉及到跨節點的分布式事務，系統性能受到很大的挑戰，為保障系統的整體性能，減少分布式事務、同時減少應用的改造是分布式數據庫數據模型設計的最大問題。因此通過梳理業務數據特點及歸納，依據分布式數據庫的分區能力制定數據模型設計規范，同時進行實際測試驗證，確保分布式數據模型的設計合理、高效。3.我國服務器產品初始化問題，我國服務器產品的應用場景相對較少，尤其是作為最為重要的數據庫服務器，所以服務器在初始化時對內存的初始化通常為小頁且不能手動調整，而數據庫 53 通常采用大頁。對于采用小頁的數據庫，通常會有性能上問

145、題。通過聯系廠商，反饋問題，升級版本解決。4.我國操作系統安裝包問題，我國操作系統的生態還不夠成熟，對于一些在 centos 上較為常用的軟件包、lib 等，在操作系統上存在找不到或版本不匹配的情形，通過與廠家的反饋得到解決。5.開發語言、框架、接口等問題，SUNDB 支持主流的開發框架和標準的數據庫接口，但在開發過程中難免遇到使用較為小眾、新興的開發框架與接口的問題。評估后，通過開發解決。四、四、應用成效及經驗應用成效及經驗 江西銀行基于我國基礎軟硬件產品，科藍采用虛擬化技術、分布式微服務架構、SUNDB 分布式數據庫，并按照分布式數據庫特點進行數據模型設計，充分發揮分布式數據庫的計算、存儲

146、的優勢，支撐用戶高并發、高性能的需求，達到應用、存儲的主機下移的目標，并真正實現了基礎軟硬件的安全可控，同時避免了不必要的硬件資源浪費。1.性能提升 主機下移改造的業務應用系統功能滿足業務要求，整體系統可靠性達到 99.99%以上，滿足金融行業業務雙活、性能提升、穩定運行的要求；2.創新基礎軟硬件 創新基礎軟硬件包括：服務器、操作系統、數據庫、中間件 54 等，全面符合創新要求，擺脫對國外廠商的依賴，產品服務的可持續性不受外部環境因素影響。3.技術先進性 構建開放敏捷的全新技術體系框架，滿足未來的 IT 發展和業務需求，滿足數字化轉型所需要的彈性、敏捷和協同共享等。使用 SUNDB 分布式數據

147、庫進行業務數據的存儲，并按照分布式數據庫特點進行數據模型設計，確保發揮分布式數據庫的最大優勢。55 案例十五：湖北銀行新核心業務系統中達夢柔性遷移雙活應用案例十五：湖北銀行新核心業務系統中達夢柔性遷移雙活應用實踐實踐 一、一、應用場景應用場景 對標某些銀行核心業務系統 Oracle RAC+DataGuard 高可用架構升級改造場景，某些銀行核心業務應用場景主要是 OLTP交易型+報表分析型混合業務場景，具有交易復雜度高、數據強一致性要求高、響應時間延時低、高可用性，以及交易型和分析型混合業務場景等特點，此項目銀行核心業務系統主要涉及到柜面系統、網銀系統、支付系統、銀行卡系統、信貸系統、風險管

148、理系統、報表系統等。整體系統處理能力大約在 2000-5000TPS，響應時間在 100 毫秒以內，以及需要滿足同城兩中心或異地三中心高可用容災架構。二、二、總體方案總體方案 本項目在選型階段，采用先課題研究，后應用實施；先實驗室場景，后生產實測的路線，有序穩步推進。在進行數據庫選型階段，除了考慮常規技術標準，湖北銀行結合自身業務需求、應用場景進行綜合考量，著重考察不同維度最終選擇達夢數據庫，具體考察內容包括銀行業務發展要求、降低項目風險與產品集成開發難度、技術服務能力、開發運維成本壓力、數據庫安全可靠、原創、銀行業監管要求等。關于實施和上線，湖北銀行新核心業務系統主要分為兩個階 56 段，第

149、一階段是 2019 年實現了 Oracle 和達夢雙中心雙活運行，達夢數據庫承擔了包括手機銀行、柜面、微信、支付寶在內新核心系統的 80%讀業務,并且已在總線 ESB 系統的流水庫和配臵庫完全使用達夢數據庫，投入實際生產。第二階段是 2023 年準備完成從達夢集中式讀寫分離集群向達夢共享存儲集群轉換，對等原 Oracle RAC+DataGuard 高可用架構，遷移到達夢共享存儲集群 DSC+數據守護集群 Datawatch，實現第一階段同城兩中心的容災高可用架構。三、三、難點問題及應對舉措難點問題及應對舉措 本項目中銀行核心系統交互面廣、層次結構復雜，數據庫遷移風險難度大，如何實現循序漸進遷

150、移改造、如何能夠出現任何問題，立刻回退到原 Oracle 數據庫，保障業務持續性，這是湖北銀行新核心業務系統遷移中突出的問題。本項目先通過實驗室課題研究，后生產實測方式，有序穩步推進，首先，基于達夢全面支持 ANSI SQL 標準，快速實現數據從 ORACLE 向 DM 的移植，實現了低成本的應用改造。其次，本項目采用柔性替代的雙中心雙活解決方案，應用雙寫模式，實現了原 Oracle 和達夢的雙活，達夢數據庫分階段逐漸分擔 Oracle業務，第一階段已經完成80%生產系統讀業務在達夢數據庫運行，第二階段，準備完成數據庫集群從達夢讀寫分離集群向達夢共享存儲集群的升級，同時完成基于達夢數據庫的同城

151、兩中心容災部署，最終銀行核心業務系統實現安全穩定的柔性遷移改造。57 四、四、應用成效及經驗應用成效及經驗 作為第一批在核心交易系統中采用我國數據庫產品的湖北銀行，本項目獲得銀監會銀行科技發展獎二類獎。新核心業務系統的上線，對湖北銀行在對優化客戶體驗、提升服務效率、防控操作風險等方面，具有重要作用：1.經實測數據的驗證，達夢作業效率達 2000 TPS 以上，與 ORACLE 保持一致，提升了新核心系統的可用性和并發處理能力。新核心系統投產上線后，湖北銀行個人開立賬戶只需 90 秒，大幅優化客戶體驗、提升服務效率。2.達夢數據庫架構實現應用“雙活”，可無縫切換數據庫，確保系統運行安全。做到撤換

152、對業務而言“無感知”，對新核心業務連續性“零影響”。3.達夢幫助提升核心業務系統安全性。達夢數據庫擁有自主知識產權，幫助用戶減輕信息安全隱患，避免了知識產權糾紛。4.達夢幫助提升核心系統經濟可行性。在同等處理能力的情況下，大幅降低成本，使湖北銀行擁有新的市場選擇。在硬件方面，從 IOE 架構向 X86 服務器轉型，節約高額硬件支出成本。5.在人力成本和開發成本方面，由于達夢數據庫全面支持 ANSI SQL 標準和主流編程語言接口，能較好的嵌入業務應用，二次開發成本大幅降低。同時，通過與達夢合作，推動湖北銀行在我國數據庫領域、金融科技領域關鍵技術的知識儲備和人才培養。58 案例十六：四川銀行金融

153、核心業務反洗錢系統案例十六：四川銀行金融核心業務反洗錢系統 GBase 8sGBase 8s 應用應用實踐實踐 一、一、應用場景應用場景 四川銀行作為四川省首家也是唯一一家省級法人銀行，是在成渝地區雙城經濟圈上升為國家戰略的背景下，未來西部經濟的發展最重要的金融支持單位。反洗錢工作是維護金融體系的穩健運行，維護公平公正的市場經濟秩序的客觀要求，對打擊腐敗等違法犯罪具有重要意義。反洗錢系統基本覆蓋全行各種交易數據，對歷史海量數據進行存儲和計算的能力于數據庫是很大考驗。反洗錢系統以 OLAP+OLTP 使用場景，每天進行大額、風險評級、可疑案例分析，并對命中結果上報人民銀行。二、二、總體方案總體方

154、案 該系統搭載全棧創新軟硬件平臺，采用華為鯤鵬服務器，中標麒麟操作系統，數據庫為 GBase 8s 企業版并采用 GBase 8s 兩節點 HAC 高可用主備集群解決方案。當數據庫主節點出現故障情況下，備節點可以在 1 分鐘內自動切換為主機，切換對應用系統完全透明，提升了集群災備高可用能力，同時借助讀寫分離模式，HAC 備節點分擔了主節點的讀負載，保證了主節點的資源利用，滿足 RPO=0，RTO60s 的高可用能力。59 圖 1 四川銀行反洗錢系統邏輯架構圖 在系統研發和改造期間，南大通用安排了專業的售后團隊和研發團隊在四川銀行現場駐場提供最強有力的技術保障，在項目整體適配過程中出現過一些功能

155、上的問題。南大通用通過快速迭代產品補丁的方式進行問題迅速應對。在項目期間先后升級了 4個補丁版本，最終提供保證了功能、性能、穩定性的版本，滿足了上線要求。并在 2023 年 3 月 29 日正式上線投產，實現了反洗錢系統在全棧創新環境下平穩高效的運行。目前業務數據量在1T 左右，預估近 5 年總數據量持續增長至 3T。三、三、難點問題及應對舉措難點問題及應對舉措 1.處理語法兼容問題：原系統 Oracle 遷移到 GBase8s，異構數據庫存在語法和數據類型上的差異，需要調整 SQL、函數的創建及使用方式。2.批量任務 SQL 優化：處理復雜 SQL 執行效率上的優化，調整合理的索引創建方式。

156、在性能壓測階段，出現了同樣 SQL 語句在 Oracle 和 GBase8s 中運行時間差異大的問題。經過技術專家 60 分析定位其核心原因為兩款數據庫產品的查詢優化器算法上差異導致。通過優化 SQL 寫法，在保證結果集正確一致的前提下，優化后的 SQL 執行效率有了顯著的提升，單個處理任務涉及 6 條上億級大表的多表關聯查詢 SQL，通過優化調整，運行耗時從單次 12 個小時提升至 3 小時左右，超越原有系統處理效率，超過整體系統的性能標準預期。四、四、應用成效及經驗應用成效及經驗 1.提升系統性能 GBase 8s 的引入提高了用戶反洗錢工作的運行效率，降低了運營管理的難度，通過優化調整，

157、運行耗時從單次 12 個小時提升至 3 小時左右，超越原有系統處理效率。2.提升金融服務能力 GBase 8s 在四川銀行反洗錢系統的成功實踐，是 GBASE 南大通用在金融領域扎根做實的又一有力印證，同時也為金融機構實現創新升級改造和 IT 系統的迭代演進的統一發展提供了典范。3.滿足合規性要求 基于強一致特性和高可用技術保障了反洗錢業務的合規性，極大增強了數據存儲和計算的準確和連貫。61 案例十七：秦皇島銀行分布式核心系統案例十七：秦皇島銀行分布式核心系統 TDSQLTDSQL 應用實踐應用實踐 一、一、應用場景應用場景 秦皇島銀行成立于 1998 年，由秦皇島市 21 家城市信用社和聯社

158、組建而成，是市屬唯一國有控股法人金融企業。秦皇島銀行緊跟金融科技發展趨勢，順應現代銀行變革潮流，著力打造區域性精品銀行重大戰略部署，為數字化轉型奠定堅實基礎，依據秦皇島銀行信息科技三年戰略發展規劃，于 2021 年 4 月啟動了新一代分布式核心系統建設。此次項目建設歷時 15 個月，涉及 1個核心系統建設和 63 個外圍系統同步升級改造，規模大，范圍廣，難度高前所未有。二、二、總體方案總體方案 新一代分布式核心系統采用分布式微服務架構，包括存款、貸款、產品、運營、客戶、核算引擎等微服務，每個微服務相對獨立運行和能夠對外提供服務。新系統首次使用騰訊云分布式數據庫 TDSQL，同時采用了網關熔斷、

159、應用熔斷、優雅停機等技術進一步提高系統的穩定性。新一代分布式核心系統建設采用基于雙中心雙活架構設計，新系統實現了注冊中心、Redis、聯機應用、批量處理及運維管理的雙活架構部署，對于應用系統來說，各個節點都支持雙中心雙活部署模式。本次項目建設實現了核心系統及相關配合改造系統的全局 62 流水號、統一錯誤碼、統一日志等架構規范，落實了超時處理、參數同步、統一對賬等技術要求，為秦皇島銀行后續系統建設打下了堅實的基礎。在分布式數據庫 TDSQL 集成方面，秦皇島銀行采用了逐級逐層實施的創新路線：基礎功能與適配要求分析（業務系統函數、語義 SQL、單表數據與壓力承擔、指標計算與設計）；集成架構設計（數

160、據庫架構選擇，涉及災備、雙活、主備等設計）；系統兼容改造（業務系統語法部分調整；TDSQL 參數與解析層應用調整）；版本驗證（基于聯機業務、批量業務、EOD 業務、數據傳輸與同步業務驗證以及事務處理能力、索引能力）；基礎架構驗證（高可用、延遲、全鏈路等）；安全架構驗證（數據環境遷移、加解密安全與效率、角色權限管控等）。圖 1 秦皇島銀行核心系統分布式數據庫建設示意圖 基于逐級逐層實施的創新路線，秦皇島銀行通過關鍵系統選擇，基礎和高階語法分析、高可用架構、連續性設計與驗證、業務場景驗證等分階段分步驟的建設方法，既保障了秦皇島銀行系統建設周期和特點，又在風險可控條件下進行了前瞻探索和實踐 63 驗

161、證，從而確保本項目的成功落地。三、三、難點問題及應對舉措難點問題及應對舉措 在構建分布式核心系統的過程中，秦皇島銀行面臨著諸多挑戰，如何實現傳統數據庫海量數據向我國數據庫產品的無損遷移是此次系統建設的難點所在。這是秦皇島銀行有史以來規模最大、范圍最廣、難度最高的一次系統升級，同時也是河北省首家在傳統核心業務場景下使用我國數據庫產品的城商行。隨著國際局勢和疫情變化，秦皇島銀行發展既要滿足科技創新要求，又要保持穩定基礎的關鍵技術自主可控的路線?；诖?，秦皇島銀行于 2021 年 4 月啟動分布式核心系統建設，在 15 個月內完成1個核心系統和63個外圍系統更新換代，提升運營基礎、服務能力、產品工具

162、、風險防控、創新引擎等多領域支撐能力。四、四、應用成效及經驗應用成效及經驗 新一代分布式核心系統是河北省首家在核心系統應用我國數據庫產品 TDSQL 的案例。新系統同時采用了網關熔斷、應用熔斷、優雅停機、同城雙活、彈性擴縮容等技術進一步提高系統的穩定性。新一代分布式核心系統建設不僅滿足了原有核心系統全部功能覆蓋及新業務需求全面增強兩大策略要求，而且同時實現了統一參數管理、業務流程優化、風險防控加強、多賬戶管理、彈性組織支持、精細化管理、差異化定價、產品快速創新、IT 系統加固等 9 大目標。64 新一代分布式核心系統整體處理能力可達到 2000TPS，支持每日億級交易量，動賬類交易平均響應時間

163、在 300 毫秒之內，查詢類交易平均交易響應時間在 100 毫秒之內，日終批量時間平常日縮短至 30 分鐘左右，季度結息日縮短至 40 分鐘左右，10 萬筆社保批量代發 96 秒完成。新一代分布式核心系統建設是秦皇島銀行改革發展的標志性工程，秦皇島銀行將依托新核心建設成果，全面提升數字化創新能力，運用金融科技手段為客戶提供更加優質便捷的金融服務，更好的發揮金融保障作用，助力“六穩”“六?！?，護航實體經濟穩增長。65 案例十八：梅州客商銀行新核心業案例十八：梅州客商銀行新核心業務系統中達夢高容災可用性務系統中達夢高容災可用性應用實踐應用實踐 一、一、應用場景應用場景 本項目對標集中式 Oracl

164、e RAC+DataGuard 高可用架構的升級改造的金融核心業務系統，其應用場景主要具有交易復雜度高、數據強一致性要求高、響應時間延時低、高可用性等特點，如在線事務交易型 OLTP 業務場景或大量 OLTP+少量 OLAP 混合新型業務場景等，如交易型和報表業務的銀行核心業務系統。二、二、總體方案總體方案 選型中考察 8 家數據庫廠家不同類型數據庫產品，包括集中式、分布式和云數據庫，結合了自身業務需求和應用場景，著重考察數據庫安全可控原創性、銀行業監管要求、銀行業務發展要求、開發運維成本壓力、技術服務能力、降低項目風險、與 Oracle產品兼容性、產品集成開發難度等多個維度進行數據庫選型，最

165、終選擇達夢數據庫作為唯一一家入圍的數據庫廠商參與梅州客商銀行新核心系統改造項目建設。關于實施和上線，根據梅州客商銀行的具體實施安排，分為兩個階段：2019 年 1 月-2020 年 8 月，完成部分核心業務系統雙軌運行；第二階段：2023 年 3 月至今，實現了部分核心業務系統單軌運行和高可用部署，目前仍在不斷快速擴大單軌運行范圍。整體實施工作中，主要完成了開發階段的模塊深度解耦、不同階 66 段功能和性能測試、不同階段的遷移實施、雙軌運行和單軌運行等。三、三、難點問題及應對舉措難點問題及應對舉措 針對銀行核心業務系統中大量的 Oracle RAC+DataGuard架構，我國數據庫產品真正實

166、現對標國外此產品的研發難度比較大，周期比較長，以及是否滿足修改少量代碼的兼容性，如何實現安全穩定的升級改造，如何沿用之前成熟的技術儲備實現遷移改造之后的開發、測試和運維等問題，一直是金融核心業務系統比較關注的問題。通過梅州客商銀行核心業務系統的升級改造項目，探索式的解決了類似的一些問題：對標 Oracle RAC+DataGuard 高可用架構，達夢數據庫共享存儲集群 DSC 和數據守護集群 DataWatch的組合架構可以實現對等國外商業數據庫能力；同種類型數據庫升級改造，更好實現了驅動、語法、架構型態的兼容性，帶來更少的業務侵入性；以及大量實踐升級改造中打磨的雙軌遷移相關工具，如數據實時同

167、步工具等，保障升級改造的安全穩定；其次，基于對標 OracleRAC+DG 的數據庫的良好兼容性和技術延續性，實現了復用積累的運維管理技術，使用了之前成熟的運維習慣，以及從集中式到集中式的相同類型數據庫升級改造，降低了后期測試、開發的難度，避免了兩種或多種測試、開發、運維的雙倍的成本壓力。67 四、四、應用成效及經驗應用成效及經驗 梅州客商銀行核心業務系統遷移改造項目，通過創新軟件、本土化管理工具、完善的用戶手冊、以及高效原廠服務等保障了系統單軌安全穩定運行，具體成效及經驗如下：1.通過部署我國共享存儲集群+集中式主備的異地兩中心高可用架構，單軌穩定運行半年多。2.集中式到集中式的同種對標數據

168、庫的升級改造，共享存儲集群+集中式組合架構，實現了架構、語法、存儲結構等不同層面的良好兼容性，對應用侵入性比較少，同時在確保安全穩定升級改造的同時降低了后期開發、測試和運維管理等成本。通過此項目積累了我國數據庫產品技術儲備，制定了類似基于達夢數據庫的信息系統運維技術規范 等一系列技術資源儲備，其次逐漸培養出我國數據庫人才隊伍，金融用戶的技術團隊很多獲得了達夢數據庫管理員認證等。68 案例十九：某銀行核心業務領域案例十九：某銀行核心業務領域 GBase 8cGBase 8c 多模多態分布式數多模多態分布式數據庫應用實踐據庫應用實踐 一、一、應用場景應用場景 隨著移動互聯網的興起，互聯網金融蓬勃發

169、展，各商業銀行在基于自身優勢的基礎上，逐步結合移動互聯網技術和業務模式探索互聯網支付、消費金融和財富管理等業務領域的互聯網化，尋求具備云原生、分布式以及全棧創新升級能力的可落地解決方案。2022 年，南大通用 GBase 8c 多模多態數據庫助力銀行科技創新，逐步實現了該銀行對公/零售信貸業務、風控業務、未來銀行、互聯網中臺等多個業務系統的分布式探索和創新升級。二、二、總體方案總體方案 為達到安全可控的建設目標，本項目搭載全棧安全可控軟硬件平臺，采用華為鯤鵬服務器、中標麒麟操作系統和東方通中間件，數據庫則采用了南大通用 GBase 8c 多模多態數據庫。根據客戶的需求情況，項目最終基于 GBa

170、se 8c 的分布式部署形態打造了針對性解決方案。業務系統通過 GBase 8c 的 CN（協調節點）訪問集群，核心業務數據水平分片，當數據主分片出現故障時，同城備數據分片可以在 30 秒內完成主分片切換，異地備數據分片可在 60 秒內完成主分片切換。切換過程對應用系統完全透明，業務中斷時間短，數據無損失，用戶感知好，同時具備了負載均衡、讀寫分離等效果，既提升整條鏈路的數據訪問并發能力，又 69 滿足了整體業務的高可用特性。圖 1 某銀行分布式平臺邏輯架構圖 三、三、難點問題及應對措施難點問題及應對措施 在本項目建設期間，用戶的核心建設目標，同時也是分布式數據庫在金融核心領域應用上的難點問題，

171、主要包括：億行級表響應時間要求為毫秒級，以滿足平臺業務高峰時期的處理能力；系統故障時必須具備秒級自動快速切換的能力，無需手動干預；數據庫必須具備平滑擴展的能力，以便于支撐未來數據量的巨大增長；必須滿足 724 小時的業務連續性需求，并且平滑升級業務不中斷；要求數據庫對安全可控硬件平臺的全適配能力。為實現用戶的核心訴求，GBase 技術實施團隊從產品特性和 70 部署方式兩個角度來滿足客戶核心訴求：與應用系統開發團隊一起，分析業務流程，對全部核心業務數據進行數據分布規劃，并且針對分布式的部署方式進行存儲過程等數據庫對象的定向優化，滿足性能要求；設計并實施了兩地三中心容災部署方案，同城兩中心，異地

172、災備中心，并且通過對內部高可用策略的配臵和優化確保高可用穩定可靠；從 CPU、服務器、操作系統、中間件到數據庫進行全鏈路適配，并在本項目場景下充分測試，實現了全棧安全可控的綜合解決方案。四、四、應用成效及經驗應用成效及經驗 本項目已完成 GBase 8c 集群的初步應用，匯聚了該銀行互聯網中臺業務、對公/零售信貸業務、風控業務等系統的全業務數據，從安裝部署、數據遷移、在線升級、在線擴/縮容、應用切換，再到故障演練、壓力測試、性能調優，南大通用提供了全程技術支持，最終保障上述各業務系統的應用開發、遷移和平滑上線。1.顯著提升了原有系統的性能與高可用能力。整體數據層解決方案創新升級后，GBase

173、8c 以分布式的架構同時在業務性能、并發吞吐量、響應時間及高可用方面實現了全面的提升，在滿足當下性能需求的同時，未來也可通過水平擴容的方式來繼續擴展對業務負載的承載能力，達到客戶預期，獲 71 得客戶好評。2.實現了分布式數據庫、微服務架構等創新技術在銀行核心系統的落地。為促進行業技術架構發展，起到積極的表率作用，GBase 8c產品和技術支持團隊在該銀行豐富的業務場景基礎上，配合完成了對微服務架構、分布式數據庫、金融云應用等關鍵基礎設施進行獨立可控的創新研究，為穩步實現銀行數字化、智能化、生態化建設目標做出技術探索與保障。3.幫助客戶打造了完善的金融安全可控生態環境。GBase 8c 數據庫

174、支持國內所有安全可控服務器、操作系統和存儲設備，100%滿足銀行業客戶對安全可控的要求，為客戶核心業務系統的數據安全提供有力保障。在為用戶提供更好性價比產品的同時，通過更全面的安全可靠能力向用戶提供產品定制性開發、優化等服務，使產品更加成熟和滿足實際業務需要，在保證業務系統處理效率的基礎上，提供了良好的業務拓展性，也提高了金融高密級業務系統的安全性。72 五、五、農村商業銀行農村商業銀行 案例二十：廣東農信數據庫聯合實驗室企業網銀和銀企直連案例二十：廣東農信數據庫聯合實驗室企業網銀和銀企直連SUNDBSUNDB 應用實踐應用實踐 一、一、應用場景應用場景 廣東省農村信用社聯合社與科藍軟件成立數

175、據庫聯合實驗室，旨在探索安全可控的數據庫，助力銀行的數字化轉型。廣東省農村信用社聯合社選取銀企直連應用場景，基于科藍軟件 SUNDB 分布式數據庫，以提升銀企直聯的功能完備性、對接便利性和多渠道協同能力為聯合驗證的范疇。目標是全面提升銀企直聯服務能力。建立對公服務渠道間的協同機制。實現企業網銀、企業手機銀行、銀企直聯和開放銀行渠道間審批流程上的協同，提升直聯對接效率。二、二、總體方案總體方案 廣東省農村信用社聯合社在該項目中，基于我國的服務器產品和操作系統，中間件采用科藍 PE 平臺，數據庫使用了科藍完全自主知識產權的 SUNDB 分布式數據庫。平臺內部采用統一、規范的 Context 傳遞參

176、數，將銀企直連和企業網銀進行整合統一。為確保應用的正常運行和平穩過度，降低應用適配改造風險，數據庫采用 DB2 和 SUNDB 分布式數據庫并行。將部分相對獨立模塊的業務數據落地在科藍的 SUNDB 數據庫，其余部分數據還是保留在原 DB2 數據庫中。73 圖 1 總體方案圖 圖 2 原始方案圖 三、三、難點問題及應對舉措難點問題及應對舉措 由于 DB2 和 SUNDB 數據庫同時并行，數據分別保存在這兩個庫中，針對這兩個數據庫中的表有關聯操作的時候，無法直接在數據庫 SQL 層面進行關聯，只能通過應用層面來實現。1.針對一個業務流程中有同時操作兩個庫表的場景，我們在應用代碼層面通過回調方式保

177、證事務的一致性。2.對原來直接多表聯查（現在跨庫多表聯查）的，同時注入 74 DB2 和 SUNDB 數據庫的數據源，在 SQL 層面進行拆分，查詢之后再進行組裝，減少前端前臺的應用改造。3.數據庫性能、存儲瓶頸和成本。采用傳統集中式數據庫DB2，存在性能和容量的瓶頸上限問題，并且高度依賴高端設備，一般需要小型機和大型存儲來保證數據庫的性能和系統的穩定，采購成本、維護成本都比較高。通過使用 SUNDB 分布式數據庫實現計算下沉、減少應用與數據庫的交互次數，縮短業務處理鏈路，最終實現業務處理性能的優化。通過使用引入 SUNDB 分布式數據庫，實現數據存儲層的線性水平擴展支撐能力。解決存儲瓶頸和成

178、本問題。四、四、應用成效及經驗應用成效及經驗 采用基于國家信息安全要求的 ARM、X86 等創新 CPU 架構整機、操作系統的基礎軟硬件，銀企直連通過科藍 PE 平臺產品和科藍 SUNDB 數據庫的結合。完成了銀企直連由獨立應用到與企業網銀結合的平滑升級，豐富了銀企直聯能力，實現了企業網銀、企業手機銀行、銀企直聯跨渠道間審批流程上的協同，提升客戶對接效率和對接體驗，降低對接和服務成本，拓展了銀企直聯服務客群。75 案例二十一：浙江農商銀行“豐收互聯”案例二十一：浙江農商銀行“豐收互聯”TDSQLTDSQL 存算分離應用存算分離應用實踐實踐 一、一、應用場景應用場景 浙江農商聯合銀行是全省規模最

179、大、網點覆蓋最廣、服務人員最多的金融機構，并打造豐收互聯 APP 線上金融服務產品，從金融擴展到政務、民生、生活、商戶等領域，將金融服務深入到每一個人的生活場景中。到 2023 年 3 月，月活躍人數超過 700萬。浙江農商聯合銀行采用 TDSQL 承載“豐收互聯”APP 應用，通過分布式數據庫超強擴展性應對快速增長的訪問需求。為應對日益增長的建設、運維成本，浙江農商聯合銀行聯合 TDSQL 和華為存儲，啟動“豐收互聯”系統存算分離改造。二、二、總體方案總體方案 浙江農商聯合銀行采用 TDSQL 多主多備+存算分離方案，采用華為 OceanStor Dorado 全閃存共享存儲存放所有數據。數

180、據庫服務器集群包含 8臺服務器，包含 2個 TDSQL主節點，6 個備節點，其中主節點可提供讀寫，備節點提供只讀服務。由于“豐收互聯”查詢類業務居多，2 主 6 備可提供最優性能。8 臺數據庫節點數據全部存儲在華為 OceanStor Dorado 全閃存共享存儲上。OceanStor Dorado 可提供 RAID、雙活等高可用保障能力，采用全 NVMe SSD 替代現網 SAS SSD，提供高性能 76 讀寫服務；此外，OceanStor Dorado 可提供慢盤隔離、故障預測等高效運維能力，確保業務系統穩定高效運行。三、三、難點問題及應對舉措難點問題及應對舉措 浙江農商聯合銀行改造初期采

181、用基于服務器本地盤存儲的存算一體架構，并很快面臨三大問題。通過與華為存儲、騰訊TDSQL 緊密合作，逐步明確解決思路并解決問題。一是業務連續性降級。業務連續性是金融行業的生命線。根據銀行業信息系統災難恢復規劃要求，AB 類業務遭遇災難時，業務中斷需要低于 15 分鐘，且數據 0 丟失。但由于服務器可靠性不足，故障后本地盤數據無法訪問，分布式數據庫只能通過多個服務器上存放多套副本提升可靠性，難以兼顧業務快速恢復和副本間數據 0 丟失，造成核心系統業務連續性降級。二是能耗上升。雙碳目標提出后，中共中央對金融業綠色低碳發展工作提出具體要求。但分布式數據庫采用多副本，數據量急劇膨脹數倍，加上服務器盤無

182、法共享導致被迫使用小容量盤，現網硬盤數量、服務器數量驟增，能耗快速上升，難以滿足金融行業綠色低碳發展要求，也導致運營成本上升。三是運維管理困難。服務器本地盤數量眾多，當硬盤進入亞健康狀態，服務器可能進入“半死不活”狀態，即業務繼續運行，但響應時延飆升；這種狀態下，數據庫不會觸發主從切換，但整系統性能嚴重下降，需要人工發現并手動處理。由于服務器缺乏故障定位能力，管理人員需要反復進行插拔盤對比測試，甚至替 77 換掉所有硬盤才能定位亞健康盤，導致業務受影響時間長、運維成本高。四、四、應用成效及經驗應用成效及經驗 浙江農商聯合銀行采用基于華為 OceanStor Dorado 全閃存存儲和騰訊 TD

183、SQL 數據庫的存算分離架構方案，彰顯三大優勢：首先，企業級共享存儲大幅提升數據庫可靠性。相比于服務器，企業級存儲架構可靠性更高，比服務器高出兩個數量級，且不會因為服務器故障而導致數據丟失。當分布式數據庫節點故障，只需要在健康節點拉起新的數據庫實例即可完成補從，無需全量恢復數據，集群恢復時間從數小時降低至數分鐘，且無需擔心數據一致性問題。其次，企業級共享存儲大幅提升資源利用率。由于企業級存儲大幅提升數據可用性，分布式數據庫無需多副本，可降低至兩副本甚至單副本，存儲資源利用率大幅提升；另一方面，企業級存儲每 U 空間容納盤數比服務器多 50%200%，且資源可供多個服務器共享，可大幅減少服務器數

184、量，提升服務器資源利用率。第三，企業級共享存儲大幅提升運維管理效率。企業級存儲可為 NVMe SSD 提供 RAID 保護，3 盤故障甚至整個硬盤框故障業務無影響，大幅降低運維事故發生風險；企業級存儲也能提供硬盤故障的預測、告警及修復建議，大幅降低因硬盤亞健康問題帶來的系統卡頓的幾率以及故障定位及消除難度，運維效率大幅提升。78 該方案通過節點故障、存儲控制器故障、接口卡故障、三盤同時故障等多個極端故障條件測試，業務無中斷；在“豐收互聯”現網測試中，存算分離架構方案在查詢內場景下平均性能提升50%。能效方面，該方案資源利用率提升 30%+，成本降低 40%+，并極大的降低能源消耗，達成綠色節能

185、的目標。79 六、六、證券機構證券機構 案例二十二：中信建投案例二十二：中信建投 OTCOTC 核心業務系統中達夢集中式核心業務系統中達夢集中式 HTAPHTAP應用實踐應用實踐 一、一、應用場景應用場景 中信建投 OTC 核心業務系統，應用場景主要特點是高并發OLTP 交易業務為主與類 OLAP 業務（實時清算等）交織的 HTAP新型混合業務場景，具體高并發查詢、復雜事務邏輯的業務處理、大批量數據的 Merge 和 Update 高耗時業務、歷史數據高耗時查詢、以及高頻率跑批業務數據分析等多種復雜業務交織的 HTAP類型應用場景。二、二、總體方案總體方案 證券核心業務系統選型中滿足我國軟硬件

186、能力基礎上，結合證券核心業務系統中 OLTP 為主和 OLAP 為輔的交織的 HTAP 混合業務場景特點，選擇底層 ARM 芯片服務器，通過對三家不同數據庫廠商的數據產品的性能、兼容性等能力的選型測試等，最終選擇集中式主備架構的達夢數據守護集群 DataWatch 來處理證券核心業務系統的 HTAP 混合業務場景。實施和上線過程中，最初從 2022 年 9 月開始選型測試，2023年 3 月開始針對達夢數據庫進行多輪功能和性能測試、進行分階段的性能優化、故障切換測試、以及雙軌遷移的數據實時同步工具測試等，目前已經完成了核心業務系統的部分模塊的遷移上線，80 還在快速穩定推進后續模塊的遷移上線中

187、。三、三、難點問題及應對舉措難點問題及應對舉措 針對證券核心業務系統中 HTAP 的多種業務場景，新型混合應用場景中眾多業務特點的性能優化內容的側重點不同，同一份數據不同的使用方式，需要平衡 OLTP 和 OLAP 之間的優化矛盾，如 OLTP 業務中為了提升性能創建索引，而 OLAP 業務上百萬行表的索引反而影響性能等。在具體實施中，需要根據具體業務特點，有針對性的進行性能優化。其次，HTAP 新型混合業務場景，資源隔離和限制尤其重要，針對此問題，此項目通過特定 CPU 架構，操作系統和數據庫相互配合完成性能優化，以及通過資源綁定等技術，實現更好的資源限制和一定程度的資源隔離，保障了證券核心

188、業務系統 HTAP 混合業務場景中 OLTP 和 OLAP 的穩定運行。四、四、應用成效及經驗應用成效及經驗 證券核心業務系統中 HTAP 新型混合業務場景，我國集中式數據庫，經過軟硬件優化和資源限制隔離等，優化后的核心業務系統實現了如下應用成效和經驗：1.針對證券核心業務 OLTP 和 OLAP 交織的 HTAP 新型混合業務場景，我國集中式數據庫滿足了眾多復雜業務需求，包括高并發查詢、復雜事務處理、大批量數據的 Merge 和 Update 業務、歷史數據高耗時查詢、以及高頻率跑批業務數據分析等。2.達夢數據守護集群實現了 OLTP 業務整體性能平均提升 75%81 左右，OLAP 業務整

189、體性能平均提升 90%左右，優化后整體平均性能與之前 Oracle 性能基本持平。3.HTAP 新型混合業務場景的應用層面，通過規劃不同業務邏輯先后順序、交織出現 OLTP 和 OLAP，盡量減少了 OLTP 和 OLAP業務同時操作，讓復雜的問題變得相對簡單。證券核心業務系統在我國集中式數據庫中的實踐應用，提升了數據庫的安全可靠能力。82 案例二十三：國泰君安證券新一代分布式核心交易系統案例二十三：國泰君安證券新一代分布式核心交易系統GoldenDBGoldenDB 應用實踐應用實踐 一、一、應用場景應用場景 當前證券行業核心交易系統架構多以應用加分庫方案構建多套核心節點部署架構，面臨著核心

190、架構擴展性差、系統耦合度高、部署時間長等問題，整體架構過于復雜容易帶來傳導性風險，在信息安全保護的背景下，需要尋找可替代的 GCH 產品。國泰君安采用 GoldenDB 分布式數據庫建設新一代分布式核心交易系統，有效解決上述技術難題，支持千萬級全量交易客戶，覆蓋融資融券、現貨、ETF、港股通等全交易業務品類，支撐 1500 萬+賬戶的容量需求，并且支持全 GCH 平臺部署。二、二、總體方案總體方案 新一代分布式核心交易系統替換了此前 12 組 SQLServer 數據庫分庫分表構成的傳統核心架構，同時支持低延時交易、橫向擴展、異地災備能力。整個系統包含交易、風控、行情等多個子系統，Golden

191、DB 承接來自于各個子系統的數據處理能力。83 圖 1 新一代核心交易系統架構 國泰君安交易平臺與分布式數據庫 GoldenDB 形成兩條主線連接：一條是低延時交易組件通過DA、DP與GoldenDB進行交互，保證整個核心交易全流程；另一條是 BOS 運維/運營管理等系統與 GoldenDB 做各種對接復雜查詢、修改等工作。上層分布式業務（含核心交易場景的數據上下場、復雜 SQL 查詢等多種業務場景）將請求發送給 GoldenDB 的統一接口，由統一接口層下發處理，GoldenDB 承擔兩條路線下的語法樹生成、路由分發、語句拆解、解析落盤等操作。此過程對應用透明，業務層面只需要做業務邏輯處理。

192、圖 2 兩地三中心高可用容災架構 84 系統各業務組件及 GoldenDB 數據庫基于兩地三中心容災架構部署，組件和數據庫發生故障時可自動完成切換，具備機房級、城市級高可用能力。三、三、難點問題及應對舉措難點問題及應對舉措 通過GoldenDB分布式數據庫HTAP能力解決證券復雜查詢和聯機交易混合處理難題。證券應用中 OLAP 類業務的復雜統計查詢 SQL 開銷高、耗時過長，直接影響 OLTP 類業務，導致后者卡頓。針對 OLAP 業務影響 OLTP 業務的問題，GoldenDB 引入 MPP數據分析引擎，專門處理部分 OLAP 類復雜 SQL 語句，在 SQL 上加注解或者連接不同的計算層節

193、點，將部分分析類 SQL 與 OLTP業務在物理層面上隔離開，確保部分耗時過長的 SQL 不會影響到正常業務。針對表關聯時出現的耗時過長的問題，例如分片表之間的關聯，分片表與普通表之間的關聯，會涉及到不同節點間的數據讀取、傳輸與計算，性能表現不佳。通過對全量 SQL 的梳理、將部分配臵數據表和基礎信息表修改為全局表、合理設計索引和關聯方式等措施，將 SQL 強制下推到底層數據節點，減少跨節點的數據交互，減少響應時延，有效解決了性能問題。四、四、應用成效應用成效 歷經一年多時間的努力，國泰君安基于 GoldenDB 分布式數據庫完成新一代分布式核心交易系統在生產環境中的全棧軟硬件適配驗證，于 2

194、022 年 8 月完成投產上線，實現 1500 萬賬戶下 85 DP 整體持續寫入性能 30 萬行/秒、DA 持續寫入性能 500 萬行/秒的目標，助力新一代核心交易系統的能力提升。順利完成投產目標后，為了適應證券行業核心系統的海量數據支撐需求，GoldenDB 進一步實現了高并發壓力處理情況下實現低資源使用率、采用新傳輸協議提升大批量數據短時間快速上場效率、優化HTAP 引擎滿足超復雜 SQL 場景下并行計算下的低時延要求等系列技術革新。國泰君安基于 GoldenDB 數據庫實現的新一代分布式核心交易系統為證券行業核心系統首個案例，該方案可作為全行業推廣，切實推動證券行業信息技術創新生態建設

195、。86 案例二十四：申萬宏源證券阿里云數據倉庫案例二十四：申萬宏源證券阿里云數據倉庫 AnalyticDBAnalyticDB 應用應用實踐實踐 一、一、應用場景應用場景 國內領先的券商企業申萬宏源證券成功完成了商業數據倉庫 Teradata 向阿里云云原生數據倉庫 AnalyticDB 的平滑升級，這一升級不僅實現了大數據分析、大贏家官方 APP、報表分析等多種復合業務應用場景的支持，還在確保安全可控的前提下，實現了成本和風險的雙重降低，顯著提升了工作效率和數據處理能力。二、二、總體方案總體方案 項目總體遷移工作按照“統一規劃，階段實施，平穩有序，風險可控”的原則實施，分兩個階段完成原數據倉

196、庫到新數據倉庫的遷移，更高效地為業務提供數據存儲、計算、數據服務能力，滿足企業未來業務快速發展的需要，項目采取分期實施。87 圖 1 遷移方案架構圖 整體方案中，降低實施風險和提高平滑度，對原有作業調度平臺進行適配改造支持 AnalyticDB。利用阿里云提供的自動化遷移工具，將 Teradata 數據倉庫遷移到 AnalyticDB，包括數據庫對象和數據、用戶以及權限體系；針對主要是實時數據文件集成，需要參照 Teradata 平臺的實時文件集成程序提供公共程序，將 CDC 服務器上的實時數據文件集成到 AnalyticDB 平臺的 AUD審計表和貼源表。ETL 腳本遷移和接口文件導出程序遷

197、移，參照Teradata 平臺模式提供公共導出程序，從 ADB PG 導出數據文件 88 對下游提供數據服務。通過申萬宏源的案例，阿里云針對 TD 的遷移，提供了一套完成的遷移實施方案，包括數據遷移、模型遷移、腳本遷移和數據校驗。三、三、難點問題及應對舉措難點問題及應對舉措 本次實施涉及從Teradata數據倉庫向阿里AnalyticDB數據倉庫的遷移。在整體方案中，需要關注以下幾點難點及應對措施。首先是原有作業調度平臺的適配改造。需要充分評估原平臺的定制化開發情況，對其進行必要的技術改造，以適配AnalyticDB 的功能和性能需求。在改造后確保作業調度與新數據倉庫能夠緊密聯動。其次是 Te

198、radata 數據倉庫中的對象、數據、用戶和權限的全面遷移。利用阿里云提供的數據庫遷移工具，進行 Teradata 自動化遷移，遷移后驗證權限和數據一致性，確保平滑過渡。另外實時數據文件集成程序需要重新設計實現。參考 Teradata 的設計思路，在 AnalyticDB 實現同類的實時集成組件，保證實時數據遷入。同時既有的 ETL 腳本和接口程序需要改造。保留 Teradata 中優化的腳本設計思路，在 AnalyticDB 實現同功能程序，經驗證后使用。最后還需全面校驗遷移后的數據完整一致性，按阿里云的標準流程，采用必要的程序或查詢對比數據，以確保遷移質量。通過以上關鍵措施，可以確保 Te

199、radata 到 AnalyticDB 的平穩遷移，降低實施風險。89 四、四、應用成效應用成效 通過采用阿里云云原生數據倉庫 AnalyticDB 進行升級，申萬宏源證券取得了顯著的應用成效和寶貴的經驗。首先，AnalyticDB 的實時處理能力和高可擴展性大幅提升了數據倉庫系統的性能，使申萬宏源能夠應對日益龐大的市場數據要求。數據處理性能提升了 1 倍以上，并能夠支持數萬張核心表，為申萬宏源的運營和業務發展提供了可靠的基礎設施環境。其次，基于 AnalyticDB 等阿里云產品構建的數據倉庫成為申萬宏源數字化轉型的重要底座。這個數據倉庫不僅滿足了申萬宏源對大規模數據實時處理的需求，還提供了

200、高度可靠的數據存儲和計算能力。數據倉庫為申萬宏源構建智能化的風險管理、投資分析和決策支持系統提供了強大支持。在實施過程中，申萬宏源充分發揮了阿里云的先進技術和強大資源的優勢，通過與阿里云團隊的緊密合作，成功完成了數據模型從原數據倉庫平滑遷移至新平臺的轉換。同時，在確保數據安全可控的前提下，申萬宏源實現了成本和風險的雙重降低，并顯著提升了工作效率和數據處理能力。申萬宏源證券借助阿里云云原生數據倉庫 AnalyticDB 的應用成效和經驗是顯著的。它不僅提升了數據倉庫系統的性能，支持了大規模數據處理和分析，為數字化轉型奠定了堅實基礎。90 七、七、保險機構保險機構 案例二十五：中國人壽數據庫遷移實

201、踐案例二十五：中國人壽數據庫遷移實踐 中國人壽保險股份有限公司數據庫遷移方案融合了分層解耦的技術架構、多路并進的數據架構和標準統一的實施步驟。通過一年的艱苦努力，完成包括核心業務在內的全部業務系統數據庫創新升級，實現從傳統主備架構到分布式架構的技術革新，探索出可復制的大型金融企業數據庫升級路徑，帶動了信息技術創新產業的快速發展。一、一、應用場景應用場景 數據庫遷移解決方案從全面應用技術革新出發，自主建立了一套分層分步實施的方法路徑，實現數據庫層的平滑遷移、企業技術架構的轉型升級。經過實踐驗證，該方案具有高度的普適性，可用于常規單體系統，也可用于關聯復雜的大型系統。1.填補經驗空白：首創分層實施

202、策略，配套歸納總結從評估、改造、遷移到運維的全流程實施路徑，方案成熟可復制且工具完善，避免其他單位從 0 到 1 的探索投入。2.加速實施進程：一年時間完成數百個關鍵業務數據庫遷移改造，幫助企業高速穩定實現數據庫技術創新升級。3.適應多種場景：通過分層分步、以點帶面的方法論，結合高效完善的工具棧，全面滿足具有業務條線眾多、關聯調用復雜、用戶訪問量大等特征的企業要求。91 4.保證業務連續性：通過靈活的技術架構和完善的應急預案，保證數據庫遷移過程中，業務不停、數據不斷。二、二、總體方案總體方案 整體方案分為技術架構、數據架構和實施步驟三個方面。（一）技術架構 以分層解耦為主要特點。應用系統按照基

203、礎硬件、操作系統、數據庫、中間件、應用程序和客戶端等分層，每個層次均可獨立開展創新升級。對于數據庫層而言，其重點是解除數據庫與操作系統、中間件之間的耦合，避免數據庫層“過重”導致難以升級。一是通過三層架構、平臺化改造，簡化應用和數據庫開發模式；二是通過建立 PaaS平臺和應用微服務化改造，進一步解耦應用和數據庫，使應用小型化、不再局限于使用一個大型的數據庫；三是通過 DevOps、自動化測試等研發體系，極大提升了開發測試、系統集成和應用交付的速度。（二）數據架構 以注重供應鏈安全、多技術路線齊頭并進為原則。根據業務特性和產品特點，對多類數據庫產品進行應用場景化選型，形成多條技術路線齊頭并進的格

204、局。1.交易類：核心業務、銷售支持、客戶服務、經營管理等交易類應用系統，使用具備支持高事務處理及高可用能力的數據庫產品，應用輕量化，不限定單一數據庫產品。92 2.分析類：商務智能、監管報送、財務精算等分析類應用系統，使用具備海量數據處理及高可用能力的數據倉庫產品。3.實時數據交換：交易類與分析類應用之間基于實時數據同步框架實現數據的流通，從而形成了基于新架構數據庫的完整的企業級數據存儲、流轉和消費解決方案。（三）實施步驟 以標準統一和風險可控為指導。建立數據庫遷移實施的統一規范和標準，遵循評估-實現-控制-分析改進的科學方法論，開展有序遷移，大幅降低單個系統的遷移風險。整個實施步驟包括兼容性

205、評估、負載評估、適配改造、存量增量遷移、反向回流、數據驗證、持續監控和在線壓測等 8 大環節，以及規范細化的 98 個子任務，結合系統上線前 5 倍峰值壓測，保證了遷移風險最小化。三、三、應用成效及經驗應用成效及經驗 （一）技術優勢 1.自主程度：自主可控比例 100%，數據庫使用達夢、Oceanbase、PolarDB、高斯 200 等；芯片使用海光、鯤鵬。2.降本增效：基于分布式架構的并行計算能力，資源使用效能和業務計算效率均提升數倍，數據庫、服務器、存儲等成本投入年均節省上億元。3.容災可靠：全面應用分布式技術架構，支持三地五中心部 93 署，滿足不同級別、不同粒度的容災要求，數據高可靠

206、 RPO=0，業務高可用 RTO5 分鐘。4.風險可控：整體方案成熟可靠，遷移前評估充分，遷移中全面檢查且高效可回退，遷移后監控完善且保障充分。（二）應用效果 該方案實現公司僅用一年時間就全面完成核心交易、個險銷售、多元銷售、客戶服務、經營管理、技術數據、辦公管理等 7大領域數百個數據庫的優化改造，業務處理平穩連續，用戶體驗穩中有升，也入選了工信部組織的“2021 年數字技術融合創新應用優秀實踐案例”。1.成本方面 1）服務器設備選擇基于通用硬件的機架式服務器作為機房上架標準，以分布式架構的容錯能力來降低對高性能高可靠性設備的需求，年均節省上億元。2）存儲方面得益于新技術的數據高壓縮比，遷移后

207、核心業務數據容量下降 78%，大幅提升了存儲的使用效能。2.性能方面 數據庫層實現了彈性管理、敏捷交付、高效計算等特性。1）業務處理方面 聯機交易、數據分析等核心指標遷移前后對比，普遍實行提升。其中，在線分析效率提升 2 倍，離線分析效率提升近 6 倍。2）資源管理方面 94 敏捷交付：數據庫以資源池的方式管理和分配，提供統一便捷的管控平臺，資源交付效率提升 5 倍以上。彈性伸縮：數據庫產品基于云原生架構，具備橫向及縱向的彈性擴縮容能力，對應用透明且數據自動均衡，通過資源池的統一調度，應對業務沖刺等突發場景的伸縮效率提升 10 倍以上。3.運維體系方面 產品的運維能力建設已經成熟，滿足金融級業

208、務對易管理、高可用、高可靠等業務連續性運營的需要。1）容災可靠性：災備架構由主備模式提升為支持三地五中心部署，滿足設備級、機房級、城市級等多級故障下的高可靠性保障。2）數據安全性：業務數據多副本存儲，在分布式環境滿足數據強一致性要求，RPO=0。3）業務連續性：數據庫采用分布式架構，節點異常自動切換，RTO5 分鐘，生產事件處理時長從小時級縮短到分鐘級。4）數據時效性：各數據庫產品均具備數據流同步能力，且滿足秒級時效性要求，支持企業數據高效流動。（三）示范效應 數據庫遷移解決方案是一套充分驗證、大量落地、完整成熟的方案。對于金融保險同業的信息技術創新應用都具有極大的參考和推廣價值，通過與產業側

209、協同共建，有力帶動了產品的快速成熟和生態的快速發展。95 1.全面升級 填補了數據庫創新升級大規模實施經驗的空白，基于大批量、高強度的應用實踐，確定了 OceanBase-海光、達夢-海光、PolarDB-鯤鵬、高斯 200-鯤鵬的組合模式，以實際效果證明了新架構產品的可用及好用，探索出一條科學有效、安全彈性、可復制、可推廣的成功路徑。2.生態共建 促進新架構數據庫的完善，幫助其產品從功能、性能、穩定性和周邊生態方面發現和解決數百個問題和場景需求，公司提出產品優化需求數量占相關數據庫總需求的 25%。3.產金共贏 該方案是金融行業與數據庫產業攜手共贏的典型案例，既完成了金融行業科技能力重塑再出

210、發，也實現了相關產業場景孵化促成熟。一方面，公司以此為契機實現了技術自主掌控和架構全面革新，通過科技全員參與，培養了數百名的新架構數據庫專家；另一方面，數據庫廠商獲得了“金融首創、行業規模首屈一指”等具有標桿意義的實踐經驗，實施方案日趨成熟，產品能力更加完善，產品生態不斷豐富，行業影響顯著提升。96 案例二十六：中國太平洋保險核心系統案例二十六：中國太平洋保險核心系統 OceanBaseOceanBase 應用應用實踐實踐 一、一、應用場景應用場景 中國太平洋保險 OceanBase 數據庫支持多種保險業務，典型應用系統有核心客服系統、核心壽險理賠系統和保監會稽核接口系統?？头到y涵蓋子公司業

211、務服務入口，為超過 2000 坐席提供系統服務，對接周邊系統 200 余個。同時，系統提供 7*24 小時服務，系統可用性要求全年 99.9%以上，因此是太保最復雜、最核心的系統之一。壽險理賠系統是典型的 OLTP 系統，承擔壽險保單理賠全流程功能，應用主要特點是以交易為主的作業流程，業務訪問量大。壽險保監會稽核接口系統是典型的 HTAP 系統，按照保監會稽核接口要求，后臺批處理生成各類業務信息，并上報給保監會稽核檢查。二、二、總體方案總體方案 中國太平洋保險從 2021 年初啟動分布式數據庫的調研工作，從功能、性能、易用性、完整性、可移植性、可靠性、擴展性、安全性等指標進行綜合評估，最終選擇

212、 OceanBase 數據庫。太保集團與 OceanBase 共同確定改造目標是“將傳統商用數據庫主備架構，升級為分布式架構，重點破除數據庫與操作系統、中間件之間的強耦合”。97 太平洋保險根據系統特點規劃為“以交易為主”（如核心壽險理賠系統是典型的 OLTP 系統）和“以批處理計算為主”（如壽險保監會稽核接口系統是典型的 HTAP 系統）的兩類數據庫集群，分別管理分布式數據庫資源。為避免集群過大造成的合并開銷，集群規模多采用 2-2-2，最大不超過 6-6-6，租戶的 Primary Zone 交錯分布在不同 Zone 服務器上，以充分利用服務器資源，保障交易集群的業務響應性能。三、三、難點

213、問題及應對舉措難點問題及應對舉措 太平洋保險 Oracle 數據庫的應用存量大、使用復雜度高。在代碼不改動或者少改動，并保障業務系統穩定安全的前提下，進行分布式數據庫的升級改造，難度極大。遷移的核心系統“P17客戶服務系統”，業務場景繁瑣，又是 7*24 小時服務平臺，對高并發和業務穩定性要求極高。該系統歷史久遠，使用多個技術框架，涉及眾多上下游系統接口。同時，系統與 Oracle 產品耦合度高，存儲過程總代碼量近百萬行。除數據庫外，配套使用的周邊產品對 Oracle 也有深度依賴，適配改造復雜度極高。OceanBase 數據庫對 Oracle 語法的強兼容特性，在遷移過程中起到了重大作用，兼

214、容度高，降低了應用改造工作量。與此同時，利用自研的數據庫應用改造評估工具“指南針”，自動識別改造項，并給出改造建議，縮短了人工識別改造點時間。四、四、應用成效應用成效及經驗及經驗 截至 2022 年，太平洋保險已有包括核心應用系統在內的 80 98 余個應用系統使用了 OceanBase 數據庫方案，覆蓋各種保險業務、運營及客戶服務的環節。應用系統利用數據庫系統的無損容災和異地多活技術，將Paxos 一致性算法運用于數據庫主備副本之間的同步，在多數派副本正常的情況下，保證數據零丟失，服務不中斷。自投產上線以來，持續平穩運行，廣泛服務于數千名柜面人員、百萬業務人員和億級外部客戶，不僅為用戶提供了

215、高效穩定的應用體驗，在提升業務效率、節省存儲空間、降低采購和運維成本等方面成效顯著。其中，“P17 客戶服務系統”，實現業務成功交易率不低于99.99%、交易總平均響應時間小于 1 秒、整體并發量 1500 人等預期指標。壽險保監會稽核接口系統，利用 OceanBase 實現單一引擎支持高性能混合負載（HTAP）應用，并通過基于時間片的混合負載調度技術，解決混合負載的資源隔離問題，相同計算資源的批處理操作時間節省 62%，監管報送批量場景性能提升 3 倍。壽險營銷員系統，利用 OceanBase 水平擴展的分布式事務處理技術能力，將數據均勻分布到多臺機器，保證分布式事務特性的前提下，解決單機計

216、算資源不足無法滿足需求的問題。智能決策服務平臺和壽險統一承保平臺，利用 OceanBase 單集群內同時兼容MySQL 和 Oracle 兩種主流數據庫生態，智能決策服務平臺（MySQL租戶）與壽險統一承保平臺（Oracle 租戶）共用集群，實現分散業務系統的整合，最大程度降低現有系統的擴展和遷移改造成 99 本，保護技術無形資產。太平洋保險 OceanBase 分布式數據庫方案投產后，數據庫軟件維保費用大幅降低，業務系統高性能、高穩定性地運行。利用OceanBase 的高級壓縮技術，存儲容量平均節省 80%以上，分析型數據加工處理能力提升 10 倍，每年可節省設備投入數億元。升級后的應用系統，構建起全面實時數據處理和服務能力；彈性擴縮容、處理速度、數據加工能力均實現大幅提升，為太平洋保險的數字化轉型奠定了堅實的技術基礎。100