【行業】金融級資料庫提升商業銀行核心競爭力

引言

信息處理是銀行業的核心，完善的數據和信息管理是商業銀行進行有效風險防控和提升金融服務質效的基礎。但隨著銀行業務的快速創新與發展，商業銀行傳統的IT系統和數據架構在性能和穩定性上均面臨新挑戰。同時，對於經營風險的銀行來說，數據安全牽一髮而動全身，業務傳導的壓力也帶來了新的數據安全隱患和問題。在此背景下，商業銀行傳統資料庫無論是從數據安全、性能、靈活可持續性還是性價比來講，都已顯得力不從心。

在大數據時代下，商業銀行IT技術架構應向分散式架構轉型。以巨杉資料庫為代表的金融級資料庫，有足夠強大的OLTP能力，可為商業銀行提供包括海量數據存儲管理、高並發數據讀寫查詢、多模數據處理等在內的功能，這是未來資料庫發展的核心要求，也是解決商業銀行當務之急的重要科技手段。

商業銀行的大數據需求

隨著商業銀行技術和業務的發展，其在大數據技術層面的需求有如下重要變化和特點：

一是商業銀行的數據呈現急劇增長，這對數據存儲和管理提出了更高要求。以大型商業銀行為例，通常它們擁有成百上千個業務系統以及上億用戶的海量數據，且數量呈現指數級增長，從TB級別增加到PB級別，未來很快就會增加至EB級別，這些都需要有效的管理以及實現實時訪問。

二是商業銀行對數據安全更加重視。當前，商業銀行對IT端安全可控要求不斷提升，在確保數據不能丟失的同時，還要做好數據的容災備份以及核心數據系統的「雙活」，即在兩個數據中心實時進行備份，一旦失去一個中心，所有業務可以及時切換中心繼續運行。

三是需要面臨高並發業務和高用戶量帶來的系統壓力。隨著互聯網金融業務的開展，商業銀行用戶量和用戶自身應用許可權不斷增加，銀行持續面臨高並發業務和高用戶量帶來的系統壓力。比如，過去銀行主要通過櫃面接收賬單查詢，現在則主要依託移動端用戶自助查詢，在某一峰值的操作量就可能超過過去一整天業務操作量的總和。

四對移動應用響應速度要求更快。在移動互聯網用戶應用需求迅速增加的背景下，用戶對移動應用的響應速度有了更高要求，移動端響應必須做到秒級以下。除此之外，商業銀行自身也需要提升大數據技術能力和業務價值，增強自身運營管理能力。

五是技術層面的國產化需求。近年來，銀行業在技術方面正在積極進行國產化改造。商業銀行在穩定性和安全性上對數據產品要求近乎嚴苛，但海外產品和開源技術不能完全滿足國內用戶需求，所以亟需能滿足核心系統需求的真正國產自研數據產品。

這裡需要特別說明的是，在商業銀行的IT架構中，如手機銀行、網上銀行以及信用卡等主要業務系統，都需要有對應的交易資料庫，通常這些傳統資料庫，在保證交易系統性能的前提下，還需要存儲12個月的歷史數據以便供實時訪問時調用。如今，由於用戶希望能夠更快地查詢過往歷史數據，使得容量壓力不斷增大，傳統資料庫的擴容不僅大大提高了成本，在並發等要求上也很難真正滿足性能提升的需求。

此外，隨著銀行遠程開戶、櫃面無紙化、雙錄、會計檔案管理等系統的建立和升級，影像系統除了滿足商業銀行在線業務系統不斷提升的訪問性能需求外，還需要提供作為在線系統的高可用、災備甚至「雙活」能力，以保證系統數據絕對安全。對於IBM CM等傳統數據管理平台，除了擴容成本高昂外，實時和並發能力更難以滿足當前需求，也無法實現真正高可用和災備「雙活」，所以商業銀行在數據管理上亟待轉型。

商業銀行銀行大數據轉型

應用和業務層的壓力，給商業銀行IT和數據架構帶來了新需求和挑戰，分散式技術架構轉型的需求也就應運而生。商業銀行亟需分散式架構轉型，主要體現在如下幾個方面：

第一，亟需提升海量數據系統管理彈性。當商業銀行系統內數據量急劇增大時，系統需要彈性地擴容以應對PB級別以上的數據管理，這種彈性容量調整可以實現讓所有數據保持在線。

第二，亟需提升數據系統管理性能。針對客戶的實時需求，商業銀行數據系統需要滿足高並發業務操作需求，實現海量數據超高性能讀寫以及實時訪問查詢。

第三，亟需升級數據安全保障。數據安全不僅僅是簡單的備份，除了實現數據的持續高可用外，還應支持異地容災甚至數據中心「雙活」，進而保障數據安全。

第四，亟需滿足多類型數據處理需求，提升系統效率。在跨業務的融合中，亟需實現對多模數據的統一管理，從結構化數據到半結構化數據再到非結構化數據，進而實現不同類型的數據統一融合管理，從而大大提升系統效率。

第五，亟需簡化開發運維節約成本。隨著應用的增多，更需要分散式架構支持，進行數據分區管理，實現業務有效隔離。同時，保持系統的彈性、兼容性，大大簡化運維開發。

第六，亟需有能力支撐核心業務系統的國產產品。除了數據安全的要求和「技術先進」，對於核心業務，更重要的是對產品代碼級具有控制力，這樣可以保證產品針對用戶共性需求不斷進行迭代更新，也帶來產品穩定性以及高效強力的技術支持。

針對以上訴求，在分散式架構轉型過程中，我認為可採用三種不同的思路：

第一種思路是「生產系統瘦身」。就是將原有部署在主機集中式系統的存量非核心業務，逐步遷移至開放平台分散式架構系統中。巨杉資料庫已經在部分商業銀行中參與了此項工作。

第二種思路是對傳統架構的完全替換。就是對部署在開放平台並採用傳統集中式架構的系統，結合業務特點差異有選擇性地實施分散式架構改造。一般來說，只有當傳統架構面臨必須被替換的痛點時大家才會選擇這個方案。

第三種思路是對新服務和新業務直接採用分散式架構。對於近年來新推出的相關業務，可發揮分散式架構等新技術優勢和作用，促進產品創新和服務能力提升，也就是新服務新業務直接採用分散式架構，部分直銷銀行已採用此種思路試水分散式架構。

巨杉金融級資料庫助力銀行大數據轉型案例

【案例1】海量影像數據分散式架構替換 實現數據中心「雙活」

近年來，影像系統已經逐漸成為商業銀行核心流程的一部分，從過去的非關鍵系統上升為一級系統或A級系統。某商業銀行，由於櫃面無紙化、集中授權以及遠程開戶此類以影像為基礎的業務陸續上線，使用傳統IBM CM作為影像系統已變得力不從心了。同時，隨著數據安全要求，該行還需要對影像數據進行災備和同城「雙活」。

巨杉使用Sequoia CM替代了過去的IBM CM產品，在系統的擴展性、性能、可靠性上均比傳統技術有了極大提升。目前，在巨杉的SequoiaCM上該銀行已有超過20個影像內容相關係統接入平台，影像數據存儲超過2PB。同時，巨杉資料庫還實現了同城「雙活」，大大增強了數據的安全性、可用性。

【案例2】分散式資料庫完美解決千億數據超高並發實時訪問難題

某金融機構對客戶的手機APP需要對全國股民近幾年的全部歷史股票交易提供在線可查詢訪問檢索功能，數量達數千億條規模。同時，在系統峰值下還需要提供超過20000TPS的並發操作和毫秒級別的訪問速度。任何傳統單點架構的資料庫產品均無法支撐如此大的並發訪問量，但通過巨杉的分散式資料庫解決了了該用戶的需求。

【案例3】減負核心系統

在某家股份制銀行業務系統的交易資料庫中，只能保留1年歷史數據，超過一年的歷史數據只能離線存儲在磁帶庫中。隨著該行手機銀行、網銀和信用卡業務的加速發展，以及規劃中的用戶端「歷史流水查詢」，原有交易資料庫不堪重負，該行為了避免高成本傳統資料庫的繼續「擴容」，選擇了分散式架構改造。

巨杉資料庫將該銀行包括影像以及業務系統的歷史數據從磁帶中完全轉移至分散式資料庫內進行在線歸檔，同時將存放在生產系統中兩年內的數據完全放到分散式資料庫進行管理。一方面，實現了已有交易資料庫的「減負」，交易系統應對查詢所保留的數據可以將降到3個月甚至1個月，進一步釋放了交易系統性能。另一方面，可以在分散式架構下將過去幾十年積累的離線歷史數據實現在線化，隨時提供給用戶使用和查詢。

通過分散式架構的數據平台應用，這家股份制商業銀行，節約了超過30%的核心系統計算能力，並且實現了毫秒級別實時查詢。同時，分散式資料庫也成功減輕了這家商業銀行原有的核心系統壓力，大大降低了系統繼續擴容成本和運維成本。