1、前言

銀行的核心系統上的交易流水僅會保存近期的數據，此前，英航在櫃面進行賬單查詢時也僅能最多查詢近期的數據。超過的歷史流水，銀行會採用離線存儲的方式將數據歸檔至磁帶庫、光碟庫或者將數據至別的系統。這樣的數據架構歸劃模式使得櫃面系統上很難實現更多的歷史賬單櫃面查詢。

2、面臨的挑戰

如果需要支持客戶的歷史賬單櫃面查詢及列印，那麼則要把全行核心系統所有的歷史流水數據進行統一存儲。歷史賬單櫃面查詢時有一個最重要的前提，那就是不能夠對現有的櫃面核心交易系統產生影響。此前提的存在就使得歷史賬單數據和核心交易系統數據不能夠共用一套系統。

歷史賬單櫃面查詢除了要滿足不影響櫃面核心交易，而且需要能滿足高並發，高實時的查詢。因為銀行一般都有成百上千個營業網點，所以歷史賬單櫃面查詢的並發支持要好。櫃面查詢一般有幾十秒的超時限制，如果查詢超過這個時長，櫃面就會直接把連接斷掉，所以對查詢的實效性要求比較高。歷史賬單的查詢是從整個核心交易的所以歷史交易流水中進行數據查詢的，而且賬單查詢的時間跨度往往是半年，甚至是一年。如此大範圍的查詢帶來的是大結果集的返回，這更是為查詢性能帶來了影響。

針對以上的查詢需求特點，解決方案需要解決以下幾點需求：

1. 海量歷史數據低成本存儲及管理

歷史賬單查詢是從海量歷史數據中進行數據的篩選操作，所以需要先將海量數據進行統一存儲和管理。歷史賬單查詢不需要有如核心交易系統那樣高級別的數據處理需求，所以也不可能像建設核心交易系統那樣進行高配置的硬體資源(如大機)和高成本的投入來構架歷史賬單櫃面賬單查詢系統。

2. 新舊系統數據統一

銀行的各系統在整個歷史中進行了多次的升級改造，這就導致了新舊系統之間數據存儲設計上存在著極大的差異。為了能提供高效、便捷、無縫的歷史賬單數據查詢，新舊系統之間數據的整合也是必不可少。

3. 提供高並發高時效的數據查詢

歷史賬單櫃面數據查詢要能夠滿足上千網點的並發訪問，且要達到秒級返回。歷史賬單查詢時需要能從海量歷史數據中查詢半年甚至一年的數據，這就對數據的查詢提出了很高的性能要求。

3、解決方案

歷史賬單櫃面查詢架構如圖一所示，此架構由下到上可分為歷史賬單數據採集、歷史賬單數據存儲管理以及櫃面查詢網關應用。歷史賬單數據存儲管理是整個歷史賬單櫃面查詢的核心，主要基於SequoiaDB分散式資料庫完成。基於此架構，歷史賬單櫃面查詢實現上千銀行網點的並發實時訪問。

3.1歷史賬單數據採集

歷史賬單數據採集的主要作用是為歷史賬單數據存儲提供歷史賬單櫃面查詢所需的各業務系統數據。歷史賬單數據採集程序通過將新核心、新信用卡及網銀等業務系統準備的歷史數據採集回來，將採集的數據按統一格式進行數據存儲。

3.2歷史賬單數據存儲管理

歷史賬單數據存儲管理主要工作是完成歷史賬單數據的統一規劃、加工和存儲管。歷史賬單數據存儲管理根據採集數據，再結合歷史賬單櫃面數據查詢需求，用SequoiaDB+Spark構建的分布數據處理平台完成數據的規劃、入庫以及加工處理。

1）歷史賬單數據時間序列化管理

歷史賬單數據作為用戶的歷史交易流水數據，存在很強的時間特性。針對此時間特性的數據，採用時間序列化的方式可以很好的展示和管理銀行自發生交易以來每個時間節點的歷史賬單數據。SequoiaDB資料庫表的時間序管理機制能很好的支持和完成歷史賬單數據的時間序列化存儲和管理，同時也能為歷史賬單數據時間範圍提供高效的查詢。如將核心歷史賬單數據根據硬體資源、歷史賬單交易聚集情況以及櫃面查詢使用情況按年或者月進行合理的時間序列化存儲和管理。櫃面操作員在進行歷史賬單數據查詢時可以根據條件中的時間範圍快速精準的定位到賬單數據，高效快速的查出數據給客戶。

2）舊系統賬單數據整合統一

由於新舊系統的更替及舊系統設計的歷史性，同一套系統的新舊系統數據表結構存在極大的差異，且舊系統數據在存儲大量歷史數據的情況下也不利用數據的查詢。為了實現新舊系統數據統一和高效快速的查詢，歷史賬單數據在存儲時會需要根據歷史賬單數據查詢需求對舊數據進行整合加工處理。數據加工通過Spark分析框架將存儲於SequoiaDB中的數據根據新舊系統結構的統一規劃完成數據加工處理，如將多張歷史賬單數據流水表打平成為一張數據流水表，然後提供櫃面快速的查詢。

3）索引查詢樹規劃管理

歷史賬單數據除了存在時間特點外，還存在數據量非常大的特點。從海量的歷史流水數據中使用表掃描的方式進行查詢肯定是不現實的，所以為數據規劃索引就顯得特別的重要，其直接決定了歷史賬單櫃面查詢的性能。SequoiaDB除了支持單鍵索引，同時也支持多鍵聯合索引。在進行索引查詢樹的規劃時，需要根據機器內存、查詢的條件、數據分布情況和查詢結果集等因素進行索引的合理規劃，從而提高查詢的性能。如果索引查詢樹規劃不夠合理，不僅無法提高查詢性能，反而會降低查詢性能，甚至會導致大量隨機I/O，造成I/O擁堵，從而影響別的查詢請求。

4）數據高效緩存處理機制

眾所周知，歷史賬單數據是持久化存儲至磁碟上的，歷史流水的寫入與查詢實質是對磁碟進行寫讀操作。數據在進行讀寫過程中，內存與磁碟進行著頻繁的交互。因為磁碟是低效存儲，所以在數據讀寫過程中，數據讀寫的瓶頸往往是在磁碟的I/O上。為了優化處理此問題，SequoiaDB結合Linux的MMAP數據緩存機制對數據進行了數據的高效緩存處理，如索引數據等數據。除了對索引數據進行緩存外，常用的歷史賬單數據也會進行緩存處理，以提供給櫃面快速高效的查詢。

3.3 櫃面查詢網關應用

櫃面查詢網關應用主要是對各類業務系統進行對接及管理操作，如核心、信用卡以及網銀等數據。櫃面查詢網關會記錄櫃面查詢的具體情況，如櫃面查詢請求數、後台數據處理數據等。同時，它還對整個櫃面網關查詢進行超時設置，對於查詢超出規定時長的請求，會直接進行中斷處理。

4、項目成果

4.1海量數據低成本存儲

SequoiaDB資料庫採用分散式架構，只需要普通X86 PC Server即可完成海量數據的高效存儲。由於業務數據存在離線化、海量化、分散性及查詢低頻性等特點，所以廉價的在線存儲架構使離線數據實現在線化成為可能。

4.2歷史賬單數據統一存儲管理

歷史賬單櫃面查詢涉及多個業務系統，所以對多個業務系統數據的規劃存儲和統一管理則顯得非常重要。SequoiaDB的Domain功能及元數據信息的有效管理很好的實現了多系統數據的統一存儲及管理。

4.3櫃面賬單實時查詢

歷史賬單櫃面查詢的數據存儲在SequoiaDB分散式資料庫之後，歷史數據可以進行實時查詢。SequoiaDB分散式存儲+多鍵聯合索引機制完成一個歷史賬單櫃面查詢請求任務秒級返回的結果。

推薦閱讀：

相关文章