民生銀行基于分布式數據庫的影像平臺建設

文/周鵬 朱彬 王健 孔再華 梁田

1 項目背景介紹

遠程銀行已經成為未來的發展方向，民生銀行線下業務線上替代率位于業界前列。遠程銀行業務的推廣需要一個強大的數據后臺來保證非結構化音視頻文件的實時讀取，影像平臺為我行后臺重要支撐系統，向各業務系統提供影像等非結構化數據實時查詢和上傳服務，平臺接入了50 多個業務系統，保存文件數超過20 億，總文件大小約300T，每天查詢量超過100 萬次，吞吐量超過400G。

影像平臺主要用來對非結構化數據進行管理，提供跨業務系統的數據實時交換存取服務，以及非結構化數據的全生命周期管理，業界主流的做法大多是以成熟的套裝軟件（如EMC Documentum 和IBM Content Manager, IBM FileNet 等）為基礎進行建設。軟件架構基于以下主流模式（圖1）。

這種架構利用傳統數據庫解決海量非結構化數據的唯一標識(id)、業務屬性描述的存儲、檢索等功能需求。

民生銀行影像平臺在此架構上運行了將近10年，承載了數十個業務系統的影像數據管理，數據量已經遠遠超過了上述傳統方案的設計容量上限，為了滿足日益增長的交易量和遠程銀行等非現場業務的發展，基于傳統IOE模式的影像平臺已經無法滿足要求。此架構下，系統存在以下問題：

（1）十億級別數據記錄的訪問和檢索效率。即使數據管理上采用分表處理，仍需要處理億級記錄。

（2）百TB 級數據的存儲成本。數百TB的存儲空間，高端存儲的硬件成本過高。

圖1：傳統影像平臺架構

圖2：項目規劃架構圖

（3）應用可以支持集群部署，但數據庫和存儲部分不支持分布式，帶來單點瓶頸。

（4）文件數據量太大，無法采用常規的文件備份方案。

（5）以時間為條件進行數據生命周期管理，離線數據部分使用磁帶進行存儲。一旦對離線數據發生訪問，響應時間超過10 分鐘

（6）采用國際廠商的產品，在獲得穩定的技術支持、應用改造和產品升級等問題上，成本比較高。

2 項目建設需求

近幾年，隨著分布式技術的成熟和普及，利用新型分布式技術解決影像平臺問題成為可能。

基于業務預期，在對未來10年數據量的估算基礎上，我行針對影像平臺技術架構改造提出了如下技術需求：

表1：新影像平臺測試場景

表2：新影像平臺獨立場景測試結果

表3：新影像平臺容量場景測試結果

圖3

（1）百億級別的數據記錄唯一標識快速檢索能力。數據管理上，單表至少能處理億級記錄檢索。

（2）PB 級的存儲空間管理能力。

（3）以普通硬盤為存儲介質的低成本方案。

（4）非結構化數據的多副本災備。以多副本的方式保存系統中的數據，提高數據安全性。

（5）海量非結構化數據的異地災備。支持跨數據中心的數據災備能力。

（6）支持同城雙活的分布式架構。

（7）數據庫，存儲等模塊都支持分布式架構。可以在線不間斷業務的橫向擴展。

（8）支持數據生命周期管理。

（9）穩定的獲得產品技術支持和定制開發。

（10）兼容傳統的架構。

（11）便于現有生產數據的無縫遷移。項目規劃架構圖如圖2所示。

3 分布式數據存儲平臺架構選型

在新的影像平臺架構設計中，根據影像平臺的特點，核心問題在于解決數據庫和內容存儲兩個功能模塊的選型。根據行內現有應用使用到的技術，通過以下的技術對比，得到了每個技術的優勢和劣勢。如圖3所示。

HDFS 作為Hadoop 技術棧的基礎產品，行內使用廣泛。但影像平臺更多的技術操作是數據插入和查詢，且影像文件大部分是小文件，因此HDFS 并太適合。

圖4：新影像平臺邏輯架構圖

HBase 是基于Hadoop 的分布式鍵值數據庫，在行內幾個項目中也用作非結構化數據的解決方案。但是由于其設計上的初衷更多是面向結構化數據的使用場景，在非結構化數據量較大的時候，系統性能及穩定性不太理想。

Ceph 和Swift 的對象存儲方案也是最近比較流行的方案，但是成熟度較差，并不適用于影像平臺這種重要交易系統。

SequoiaDB 巨杉數據庫是國產的分布式數據庫，在行內歷史數據查詢平臺等應用上作為數據庫使用，也是項目的選型產品之一。巨杉數據庫支持對非結構化內容數據及其索引元數據的統一存儲和管理，消除了傳統內容管理系統同時管理關系型數據庫和文件系統所帶來的管理負擔，支持橫向擴展，適用于高并發、低時延的在線訪問場景。

圖5：新影像平臺疲勞測試結果

基于上述的分析，并綜合考慮產品的研發能力，技術支持服務能力，行內使用情況等因素，最終，項目采用了基于巨杉數據庫的內容管理解決方案。

4 新影像平臺應用架構

新影像平臺的應用邏輯架構圖如圖4所示。

4.1 對象存儲方式

上一章節已經詳細描述，采用巨杉分布式數據庫作為對象存儲平臺，并且引入了讀寫分離的機制。例如，音視頻文件較大，為了避免高并發的讀寫引發磁盤I/O 沖突，保證服務的實時性，在底層根據不同類型數據的訪問特性進行了讀寫分離，在物理上對讀寫操作隔離，邏輯上通過應用層對外透明，業務系統無感知。

4.2 多樣化接入方式

提供多種接入方式，包括對接系統采用SDK 調用web service 方式；對接終端采用控件方式；非實時的海量數據采用批量方式。三種方式滿足不同的業務需求，同時也分散了單一類型情況下的服務壓力。其中SDK 方式根據上傳文件大小，自動選擇最高效的協議報文。控件方式采用隨機加密技術，在保證端到端高效的基礎上，也保證了數據的安全性。

4.3 動態資源隔離

由于接入系統多，為了避免各系統之間爭搶資源，設計了資源管理模塊，各系統服務資源單獨配置且互相隔離，通過服務流量控制可以動態調整各服務的資源使用配比并實時生效。

4.4 分庫分表

根據系統類型進行分類，將分類后的數據分表存儲，減少對單表的壓力。

4.5 海量數據準實時災備

采取應用層實現同城雙活的技術方案，使用activeMQ 消息隊列實現同城數據準實時同步，同步任務具備自動重試機制。

4.6 智能數據路由

為了保證遷移過程中能夠滿足前端系統復雜的跨系統訪問需求，設計了多層次的數據路由服務。支持不同類型的數據存儲平臺。

5 新影像平臺測試情況

在確定了數據存儲架構和應用架構之后，我行基于此方案進行了開發測試。

測試環境應用服務器采用了2 個節點，分布式數據庫集群采用了8 個物理節點，測試鋪底數據規模：影像流水近千萬，影像流水分兩類，流水A 含10 個影像文件(8 個20K，2 個200K)，流水B 含1 個影像文件（大小20M），兩類流水的比例大約300：1。

根據目前生產運行情況，及對未來幾年業務增長情況預測，測試場景設計如表1所示。

在獨立測試場景下，分別測試webservice按流水上傳，webservice 按流水下載，消息服務按流水上傳和消息服務按流水下載，得到的測試結果如表2所示。成功率基本達到100%，TPS 滿足指標要求。

在容量測試場景下，webservice 上傳、webservice 下載、消息服務上傳和消息服務下載等事務根據生產實際情況按比例混合，得到的測試結果如表3所示。成功率基本達到100%，TPS 滿足指標要求。

在疲勞測試場景下，連續2 天，200 個并發用戶，系統處理能力和交易響應時間基本保持穩定，測試過程中未出現宕機、內存泄露、性能下降等問題。

選取其中一組的測試結果分析得到：系統總平均處理能力為 208.404 筆/秒，12 小時內共完成交易 9020379 筆。疲勞測試結果如圖5。

通過以上測試結果可以看出，在新的影像平臺架構下，獨立場景、容量場景及疲勞場景，測試結果均能夠滿足生產的需求。

6 影像平臺遷移方案

測試完成并達到預期的測試結果后，我行開始積極準備在生產上對數據進行遷移。實施數據遷移方案的三個總體原則：

（1）舊存儲到新存儲無縫切換，不影響業務運營；

（2）數據遷移過程不需要多次維護窗口，不影響業務運營；

（3）簡單修改應用即可適應新存儲架構。

基于以上的原則，我們的遷移方案主要包括以下幾個大的階段：

（1）新應用上線和巨杉數據庫集群擴容；

（2）子系統增量數據分批次遷移至新環境；

（3）子系統存量數據遷移至新環境。

子系統增量數據遷移過程，為了避免全局風險，我們制定了分批次遷移測策略。將接入的業務系統按重要性和每日數據增量大小分為三個批次，在變更窗口進行系統切換。切換后新增的數據落入到新的分布式數據庫中，數據訪問通過應用的數據路由層，先判斷數據的存儲位置，再進行數據的訪問，數據遷移工作對業務系統透明。

子系統存量數據的遷移是整個遷移過程中耗時最長的一個階段，我們開發了數據遷移程序，將子系統的存量文件遷移到新的分布式數據庫中，同時更新路由表數據和元數據，并記錄遷移進展。遷移程序還具有數據校驗功能，以確保數據遷移的結果正確。

待所有舊環境中的數據都遷移至新環境，并驗證數據正確，數據遷移工作全部完成。

7 新架構生產運行情況

經過近一年時間的遷移，目前影像平臺已經全部運行在新系統上。接入業務系統超過50 個，日均業務量每天超過100w 筆，日均下載量每天超過200GB，日均上傳量每天超過100GB。新系統整體運行平穩。

8 總結和展望

通過分布式技術，民生銀行新影像平臺具備了海量非結構化數據的實時服務能力，增強了系統平行擴展的能力，增強了系統穩定性，為遠程銀行業務提供實時的音視頻訪問能力，同時也探索了分布式技術在該場景下的最佳實踐，在過程中創造性的解決了很多技術問題，無論是在業務支持還是在技術推廣上都具有現實意義。