蔡培茂，張申勇，譚忠兵，魏志軍

（北京理工大學珠海學院，珠海519088）

0 引言

賬戶歷史交易數據查詢服務是銀行金融業(yè)務的重要組成部分，主要是指對客戶的銀行卡（借記卡、信用卡等）或者銀行活期存折，在一段時間內發(fā)生存取款業(yè)務交易清單的檢索。賬戶歷史交易數據查詢是銀行信息化系統的不可缺少的功能，也是銀行客戶最常使用的功能之一，對本人交易歷史全貌了解和掌握是銀行客戶的強烈需求。

對于賬戶歷史交易數據查詢功能，業(yè)內傳統解決方案是基于關系型數據庫的，一般采取主機分流做法，即事務型處理和分析型處理分離[1]，也就是事務型業(yè)務處理由核心業(yè)務系統的關系型數據庫來承擔，再建立另外的一個關系型數據庫來專門實現歷史數據存儲與查詢，但在傳統解決方案中，由于關系型數據庫的局限，查詢庫中僅提供最近幾年的客戶交易明細，單次查詢時間段跨度最長為一年左右，其余的交易歷史數據多以光盤庫、磁帶庫的形式存放，這樣的做法查詢效率低且成本高，一般用戶只能查詢近期數據，不能對歷史數據全貌進行方便查詢，并且查詢條件單一，對多條件高級查詢支持不足。近年來，隨著各種便捷支付方式的普及，賬戶交易數據量呈現爆炸性增長，同時，客戶交易數據類型也在快速變化，出現手機銀行、網上銀行、微信銀行等不同使用方式，為了能夠以較高的性能滿足海量交易數據的查詢需求，常常需要采取分庫分表方式或采用分布式關系型數據庫來解決[2]，但這些方式部署、管理、配置復雜，擴容困難，并且造成開發(fā)難度大幅上升。由于傳統關系數據庫可擴展性差、數據模型死板、嚴格事務機制等原因[3]，無法滿足數據量巨大、高并發(fā)、高擴展和高可用的銀行海量歷史交易數據查詢的需求[4]。

近年來，為了獲得靈活的數據模型、分布式和橫向擴展能力，各種新型的、非關系型數據庫應運而生，這些數據庫統稱為NoSQL，NoSQL數據庫類型多樣，包括Redis、HBase、MongoDB等，這些NoSQL數據庫可滿足不同場景的應用需求[5]。為了更好地滿足客戶和監(jiān)管機構等對于歷史交易數據的查詢要求，提高業(yè)務處理能力，改進客戶體驗，本文提出一種基于MongoDB的存儲和查詢銀行海量歷史交易數據的應用解決方案，實現銀行海量歷史交易數據的全量存儲、多條件復雜查詢、高效在線統計計算和系統的可擴展、高可用等。

1 MongoDB的特點

MongoDB是一個基于分布式文件存儲的開源NoSQL文檔數據庫，由C++語言編寫[6]。根據DB-En?gines發(fā)布的2021年2月份的數據庫排名中，MongoDB排名第五，并且分數保持持續(xù)增長。

MongoDB具有高性能、高可用、易橫向擴展、模式靈活、支持索引、支持聚合操作、支持動態(tài)查詢等優(yōu)勢，文件存儲格式是BSON格式，BSON是類JSON的一種二進制形式，支持內嵌的文檔對象和數組對象。而關系型數據庫基于單機架構，模式固定，不容易橫向擴展，難以支撐系統所需要的海量數據。

銀行交易數據具有規(guī)模大、增長速度快、結構易變等特點，查詢要求高可用、高性能和查詢條件復雜等，MongoDB的特點能夠很好地滿足銀行歷史交易數據存儲和查詢的需求，具體如下：

（1）高可用性。MongoDB提供副本集群架構，副本集中一組MongoDB實例保持相同數據集。通過部署副本集群，實現歷史交易數據存儲和查詢系統的自動恢復、故障自動接管、提供7×24小時可用等。

（2）高擴展性。MongoDB提供分片集群架構，分片是指數據拆分并分散存放在不同機器上，為MongoDB實現橫向擴展能力。通過部署分片集群實現歷史交易數據的全量存儲和檢索，使客戶能夠看到其交易歷史全貌，能夠實現系統的平滑擴容。

（3）模式靈活。MongoDB提供靈活的BSON文檔模型，無須預定義模式結構，文檔中的鍵和值無須定義固定的類型和大小，非常適合交易數據結構易變的特點，方便支持新的支付方式，使開發(fā)能夠快速迭代以響應業(yè)務需求的變化。

（4）高性能。MongoDB提供了多樣性的索引支持和多種分片策略。通過設計合理索引和分片鍵、副本集多節(jié)點數據讀取等方法，可以實現歷史交易數據的高并發(fā)訪問和快速響應。

（5）復雜查詢。MongoDB支持豐富的查詢語言、數據聚合框架等，能夠滿足歷史交易數據多條件復雜查詢的需要，這也是MongoDB相對其他NoSQL數據庫的優(yōu)勢，如：HBase。

2 系統架構

交易數據查詢具有大量高并發(fā)讀操作的特征，傳統主機架構性能擴展不易、成本高，為了降低核心業(yè)務系統的壓力，業(yè)界普通采用主機分流。根據對Mon?goDB特點的分析，這里采用MongoDB作為主機分流數據庫，將業(yè)務數據從現有主機或Oracle等關系型數據庫實時同步復制到MongoDB，以實現客戶對交易數據查詢或統計分析，系統架構如圖1所示。

圖1 系統架構

圖1 系統架構各組成部分說明如下：

（1）核心業(yè)務系統。該系統是現有銀行核心業(yè)務系統，承擔銀行核心交易事務處理，交易數據存儲在關系型數據庫中，包括賬戶交易明細、客戶回單信息、賬戶基本信息、客戶基本信息等最新數據。

（2）采集層。該層實現從核心業(yè)務系統的異構數據庫中實時同步數據到MongoDB中，這里使用Kafka實時監(jiān)聽核心業(yè)務系統中數據變動并同步至Mon?goDB。Kafka是由Apache軟件基金會開發(fā)的一個開源的、高吞吐量的分布式發(fā)布訂閱消息系統[7]，非常適合實時數據的傳輸。采集層也可以采用市場上一些專門針對MongoDB的同步數據產品。

（3）數據層。該層采用MongoDB的副本集群、分片集群來存儲海量歷史交易數據，以實現高可用、高性能、高擴展等系統特性。MongoDB集群架構如圖2所示。

（4）業(yè)務層。該層是查詢業(yè)務的實現層，一般采取分層架構以實現系統功能的低耦合、高內聚的設計要求，如：數據訪問層的職責是通過MongoDB驅動程序訪問MongoDB中的數據；邏輯層的職責是根據客戶請求實現業(yè)務邏輯的處理；控制層職責是適配不同客戶端，實現請求流程控制與跳轉。

（5）客戶端。用戶可以通過不同方式訪問系統功能，如：手機App、網上銀行、微信小程序、柜員機、銀行內部系統等。

在系統架構中，數據層中MongoDB的部署模式是需要重點考慮的部分，為保證生產過程的高可靠和高可擴展，需要結合MongoDB副本集和分片機制來搭建MongoDB的分布式集群架構，如圖2所示。

圖2 MongoDB集群架構

為了實現交易數據查詢系統的自動容錯、自動故障恢復[8]和高可用，需要部署MongoDB副本集群，一般典型的副本集由3個以上具有投票權的節(jié)點組成，由于副本集中的節(jié)點都有可能成為主節(jié)點，所以副本集中的節(jié)點的硬件配置要保持一致。副本集除了實現高可用外，還有以下附加作用，如數據分發(fā)、讀寫分離和異地容災等，所以副本集中成員節(jié)點的數量需要根據系統實際需求進行增減，但不能少于3個節(jié)點。

分片集群可以有效解決性能和擴容問題，但是分片需要更多的機器，管理復雜，因此在數據規(guī)模不大的情況下，使用副本集的方案就夠了[9]，不需要使用分片集群，然而，隨著時間的推移和各類便捷的支付方式的普及，會出現數據量快速增長、訪問性能下降等問題，同時，為了實現歷史交易數據的全量存儲和檢索目標，最終是需要分片集群來解決的。分片群集的規(guī)模需要根據所需存儲數據總量、并發(fā)量總數、緩存數據大小等因素來綜合規(guī)劃和確定。

為了提高路由的可用性和實現負載均衡，路由節(jié)點至少2個，可根據實際并發(fā)訪問情況增加更多的路由服務器節(jié)點。

配置服務器存儲了分片集群的元數據，為了保證高可用，所以配置服務器同樣必須部署成副本集。

3 數據模型

銀行業(yè)務中存在各種不同類型的賬戶，如：借記卡、信用卡、股票賬戶、基金賬戶等，每種賬戶的交易數據類型也不相同，并且隨著業(yè)務的開展，還會出現新的賬戶類型和新的交易數據類型，因此存儲交易數據的數據模型必須靈活和支持彈性擴展，以適應新業(yè)務發(fā)展需要。MongoDB是無模式數據庫，提供非常靈活的文檔數據模型，完全能滿足銀行業(yè)務的這種需求。MongoDB的BSON文檔是一種模式自由的存儲形式，能夠動態(tài)地添加數據項，靈活性很高。

交易數據大多數情況下涉及客戶信息、賬戶信息和交易明細三類。為了獲得高效率的查詢，設計兩個集合來存儲主要數據：客戶賬戶集合customer和交易明細集合txdetail。

客戶賬戶集合customer的文檔格式示例如下：

交易明細集合txdetail的文檔格式示例如下：

以上文檔示例僅包括交易數據中最常用的基本信息，對于單據、證件影像數據，由于一般查詢不會用到這些數據，因此應該設計單獨的集合來存儲，同時考慮在MongoDB中BSON文檔有16MB大小的限制，所以，需要保存到MongoDB的GridFS中[10]。

4 索引與分片鍵

在基于MongoDB數據庫的系統中，索引和分片鍵是非常關鍵的，下面結合銀行海量歷史交易數據查詢的應用特點給出主要索引和分片鍵的設計策略。

4.1 索引設計

為了避免全集合掃描，提高查詢性能，MongoDB提供了索引機制。在交易數據查詢中，最常見的查詢場景是根據賬戶編號、交易時間范圍、交易金額范圍等多個條件組合來查詢交易明細集合txdetail，并且根據交易時間倒序排列，所以需要創(chuàng)建一個包含這些查詢條件字段的組合索引。

MongoDB索引采用B-樹結構，因此組合索引中的索引字段順序非常重要，組合索引中索引字段的最佳排序方式是精確匹配的字段在前面、排序條件字段在中間，范圍匹配的字段在最后。對于交易數據查詢，賬戶編號是精確匹配、交易時間和交易金額是范圍匹配、而交易時間常用于排序，所以對交易明細集合txdetail創(chuàng)建這個主要索引：db.txdetail.createIndex（{account_no:1，tx_date:-1，tx_amount:1}）。

4.2 分片鍵設計

為了存儲和處理海量歷史交易數據，需要借助MongoDB分片機制來實現。在MongoDB的分片集群中，分片鍵的設計是非常關鍵的，分片鍵決定了數據分布方式，直接影響集群的性能。設計分片鍵時需要綜合考慮分片鍵的基數、分片鍵值分布、定向訪問等因素，通常選擇基數大、數值分布均勻、對主要查詢具有定向能力的一個或多個字段組合來作為分片鍵。

交易明細集合txdetail會隨著時間的推移，數據量會快速增長，達到非常大的規(guī)模，因此該集合需要進行分片。同時，大部分場景是根據賬戶編號、交易時間范圍來查詢交易數據。本系統的分片鍵設計應達到“分散寫”和“集中讀”的目標，從而提高系統性能?！胺稚憽笔侵笍暮诵臉I(yè)務系統同步數據至MongoDB集群時，數據能夠均勻地分布到集群中各分片服務器中，避免因總寫某一分片服務器和某一分塊而導致出現熱點問題和超大塊問題；“集中讀”是指同一個賬戶的交易數據總是在同一個分片服務器中，查詢時能夠直接定向到該分片服務器進行數據讀取，而不需要將查詢分發(fā)到不同的分片服務器。

綜上所述，對交易明細集合txdetail采用“交易賬戶編號+交易時間”作為分片鍵，“交易賬戶編號”在前面能實現“集中讀”的目標，而加上“交易時間”能夠增大分片鍵值基數，避免出現超大塊問題，實現“分散寫”的目標，操作命令如下：

對數據庫啟用分片：sh.enableSharding（"數據庫名"）

對交易明細集合txdetail建立索引（前面已創(chuàng)建）：

db.txdetail.createIndex（{account_no:1，tx_date:-1}）

對交易明細集合txdetail建立分片：sh.shardCollec?tion（"數據庫名.txdetail"，{account_no:1，tx_date:1}）

5 實現效果

MongoDB提供多種語言的驅動程序API，如：Java、Python等，可以采用這些語言來實現業(yè)務層，以下給出的Mongo Shell操作指令，可以很容易轉化為相應開發(fā)語言API的調用。

圖3 展示了歷史交易數據查詢的常見查詢條件，其中基于賬戶、交易時間范圍是最常用的查詢，該查詢的Mongo Shell操作指令如下：

圖3 查詢條件

圖4 展示了歷史交易數據查詢結果，其中本頁統計交由客戶端實現，本次查詢收支金額總計則由Mon?goDB的聚合框架來實現，具體Mongo Shell操作指令如下：

圖4 查詢結果

6 結語

本文給出了基于MongoDB實現銀行海量歷史交易數據查詢的解決方案，通過對歷史交易數據查詢業(yè)務分析，結合MongoDB高可用、高性能、高擴展和模式靈活等特點，設計了系統架構、數據模型、合適的索引、分片鍵和系統實現效果。該方案能夠實現銀行交易數據查詢能力從1年提升至10年或甚至全量數據，實現毫秒級快速響應，大大提升用戶體驗，并能夠節(jié)省大量系統維護時間，提供7×24持續(xù)服務。另外，通過Mon?goDB存儲了全量的客戶信息和交易明細，為銀行實現業(yè)務創(chuàng)新和為客戶提供個性化服務奠定了基礎。