酷播亮新聞
作者介紹：周鵬，現就職於中國民生銀行信息科技部，負責全行數據庫維護及分佈式數據庫平台建設等工作，具有多年的數據類系統架構設計及調優經驗。 對於新型分佈式數據庫、大數據生態系統研究具有濃厚興趣。
前言
此前，金融信息化建設主要依托原有集中型IT 架構進行維護擴展，系統規模及復雜程度呈指數級增長，各類瓶頸逐漸暴露，日益增長的數字金融需求同舊式的系統架構缺陷之間的矛盾 愈加凸顯。 中國人民銀行、中國銀行保險監督管理委員會等金融監管部門逐漸推出分佈式轉型政策要求，金融企業開始興起分佈式轉型浪潮。
民生銀行作為中國第一家非國有企業所有的銀行以及中國領先的零售銀行，管理的總資產為 3.2 萬億人民幣，運營 33 家分支和超過 700 家銀行網點。 在業務創新和技術創新上，民生銀行一直走在業界的前列，尤其在人工智能、大數據領域，民生銀行做出了很多積極的嘗試，取得了不錯的成效。
銀行分佈式轉型需求
應用和業務層的壓力，給商業銀行IT和數據架構帶來了新需求和挑戰，分佈式技術架構轉型的需求也就應運而生。 商業銀行亟需分佈式架構轉型，主要體現在如下幾個方面：
· 提升海量數據系統管理彈性。 當商業銀行系統內數據量急劇增大時，系統需要彈性地擴容以應對PB級別以上的數據管理，這種彈性容量調整可以實現讓所有數據保持在線。
· 提升數據系統管理性能。 針對客戶的實時需求，商業銀行數據系統需要滿足高並發業務操作需求，實現海量數據超高性能讀寫以及實時訪問查詢。
· 升級數據安全保障。 數據安全不僅僅是簡單的備份，除了實現數據的持續高可用外，還應支持異地容災甚至數據中心“雙活”，進而保障數據安全。
· 滿足多類型數據處理需求，提升系統效率。 在跨業務的融合中，亟需實現對多模數據的統一管理，從結構化數據到半結構化數據再到非結構化數據，進而實現不同類型的數據統一融合管理，從而大大提升系統效率。
· 簡化開發運維節約成本。 隨著應用的增多，更需要分佈式架構支持，進行數據分區管理，實現業務有效隔離。 同時，保持系統的彈性、兼容性，大大簡化運維開發。
· 有能力支撐核心業務系統的國產產品。 除了數據安全的要求和“技術先進”，對於核心業務，更重要的是對產品代碼級具有控制力，這樣可以保證產品針對用戶共性需求不斷進行迭代更新，也帶來產品穩定性以及高效強力的 技術支持。
民生銀行新一代數據庫應用情況
目前，在數據庫領域，民生銀行新一代數據庫的應用目前主要分為三個領域。
1)數據庫分庫分錶
針對數據彈性擴容和性能、高可用等要求，我們也針對數據庫進行了分庫分錶改造。 目前已經實現Oracle、IBM DB2以及MySQL數據庫的分庫分錶改造，總分庫數超過15，分錶數超過500張。
2)傳統數據庫的跨中心分佈和雙活
我們針對IBM DB2等傳統關係型數據庫產品進行了跨中心分佈和雙活的改造。 提升總體安全性，提升RTO，RPO，實現“5個9” ，降低風險提高效率，操作過程更簡單透明，同時大大提高軟硬件資源利用率，節約了建設成本。
3)新型分佈式數據庫產品使用
除了傳統數據庫的分佈式改造，民生銀行也積極嘗試新型分佈式數據庫產品。 如國內的分佈式數據庫SequoiaDB，目前已經在海量數據查詢、分佈式影像平台和歸檔數據管理等在線業務系統中規模部署使用。
分佈式NewSQL創新實踐
當前分佈式架構轉型的改造已經取得相當成效，但隨著我行各類業務負載的不斷增大，以及直銷銀行、互聯網金融和人工智能等創新業務的拓展，同時分佈式數據庫應用也需要向更 核心的業務系統推進。 當前方案面臨新的挑戰：
· 開發運維成本： 分庫分錶方案，在擴展性和性能、並發上仍有瓶頸，且開發投入的各項成本高。 分庫分錶的方案需要預先根據業務對數據庫進行切分，這樣的方案喪失了較多的彈性，同時在運維層面，也需要投入不小的人力。
· 降低使用和運維成本： MySQL兼容性。 開源數據庫MySQL目前在互聯網行業應用較廣，許多應用也基於MySQL開發，但是目前的分佈式數據庫很多沒有實現完全的MySQL兼容，因此在實際投產後，實際的使用和運維成本更高了。
· 進入核心業務場景： 使用開源數據庫、中間件方案，由於沒有商業化廠商的支持和行業積累，穩定性沒有保證，再進入核心業務系統時存在一定風險。
· 國產化要求：在分佈式數據庫領域，不能過分依賴海外開源產品，需要著重考察國內自主可控的分佈式數據庫產品。
針對上述需求，我們在分佈式NewSQL的創新實踐中，經過測試和對比，我們最終選擇巨杉的SequoiaDB。 SequoiaDB 3.0 版本，目前已經實現完整協議級別MySQL兼容，可以在數據庫層面做到分佈式並且對已有業務全兼容。 同時，巨杉在金融行業已經有過大規模使用考驗，在產品成熟度上更可靠。
分佈式NewSQL數據庫平台，在使用SequoiaDB 3.0 後，體現了幾大業務優勢：
· 分佈式可擴展性：存儲層的分佈式數據引擎，可以實現數據量的彈性擴容，靈活應對業務需求的調整。
· 微服務架構：整個平台參考了微服務架構，接入層的SQL實例和存儲層的存儲節點都可以進行自由的配置，應用可以按需選擇SQL實例和存儲節點。
· MySQL完全兼容：接入層實現了完全協議級兼容MySQL，應用無縫對接，大大降低使用和運維成本。
業務場景測試結果
為了體現NewSQL平台的優勢，我們選取了SequoiaDB在幾個主要業務場景下的一些測試數據進行說明，這些業務場景可以代表我行的許多重要交易場景：
· 渠道複雜查詢場景
此場景以查詢為主，查詢語句較複雜，涉及4張表的關聯，其中包括2張大的流水錶的關聯操作，每張表記錄數達到數億條，最終匹配結果達到數百條記錄。
在實際測試中系統的業務處理能力仍然可達到平均每分鐘3,916.45筆，並且運行過程系統的吞吐量表現非常平穩。
· 高頻交易流水查詢場景
此場景以高頻查詢為主，主要針對近期的流水記錄，查詢頻率較高。 共涉及3張表，其中小流水錶和資料表記錄條數分別為3000萬條，大流水錶為3億條。
通過測試，在該場景下，每分鐘的業務處理能力可達到1,886,184.03筆，如此高的吞吐量仍然能夠在整個過程中持續保持平穩。
· 櫃檯業務辦理場景
此業務以查詢和更新為主，執行頻率高，對響應時間要求高。 其中查詢業務涉及3張表，其中兩張資料表為1000萬，3000萬條數據，維度表數據為1萬條;更新操作則涉及資料表1000萬條記錄和維度表1萬條記錄。
混合查詢和更新，在執行過程中可能出現不同事務對同一條記錄的讀寫衝突，因此吞吐量表現出現一些小幅度波動，但總體平均每分鐘的業務處理仍然可達到51,090.03筆。
· 計費業務場景
此業務場景以插入、更新和查詢為主，執行頻率高，對響應時間要求高。 其中查詢涉及兩張資料表和兩張維度表，資料表記錄數分別為1000萬與3000萬;插入操作涉及兩張流水錶，記錄數分別為3000萬與900萬;更新則涉及一張維度表 與一張流水錶，記錄數約為1萬與1億。
業務場景較為複雜，每筆業務至少包含50餘個數據庫操作，混合著插入、更新以及查詢等多種操作，平均每分鐘的業務處理仍然可達到9,861.57筆。 ，相對波動也比較小。
小結
SequoiaDB 3.0 的MySQL兼容性較為優秀，擴展能力較好，總體性能滿足重要交易系統的要求。 後續，我們將會把更多現有分庫分錶方案難以處理的業務向NewSQL平台遷移。
我們也會持續評估未來大規模使用分佈式數據庫的可能性，充分發揮NewSQL數據庫的優勢，幫助我們的業務、技術創新，同時也希望我行在分佈式數據庫建設過程中的可以分享更多成功經驗 。