民生銀行基于分布式數(shù)據(jù)庫的影像平臺建設(shè)

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

1 項目背景介紹

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

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

這種架構(gòu)利用傳統(tǒng)數(shù)據(jù)庫解決海量非結(jié)構(gòu)化數(shù)據(jù)的唯一標(biāo)識(id)、業(yè)務(wù)屬性描述的存儲、檢索等功能需求。

民生銀行影像平臺在此架構(gòu)上運行了將近10年，承載了數(shù)十個業(yè)務(wù)系統(tǒng)的影像數(shù)據(jù)管理，數(shù)據(jù)量已經(jīng)遠(yuǎn)遠(yuǎn)超過了上述傳統(tǒng)方案的設(shè)計容量上限，為了滿足日益增長的交易量和遠(yuǎn)程銀行等非現(xiàn)場業(yè)務(wù)的發(fā)展，基于傳統(tǒng)IOE模式的影像平臺已經(jīng)無法滿足要求。此架構(gòu)下，系統(tǒng)存在以下問題：

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

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

圖1：傳統(tǒng)影像平臺架構(gòu)

圖2：項目規(guī)劃架構(gòu)圖

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

（4）文件數(shù)據(jù)量太大，無法采用常規(guī)的文件備份方案。

（5）以時間為條件進(jìn)行數(shù)據(jù)生命周期管理，離線數(shù)據(jù)部分使用磁帶進(jìn)行存儲。一旦對離線數(shù)據(jù)發(fā)生訪問，響應(yīng)時間超過10 分鐘

（6）采用國際廠商的產(chǎn)品，在獲得穩(wěn)定的技術(shù)支持、應(yīng)用改造和產(chǎn)品升級等問題上，成本比較高。

2 項目建設(shè)需求

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

基于業(yè)務(wù)預(yù)期，在對未來10年數(shù)據(jù)量的估算基礎(chǔ)上，我行針對影像平臺技術(shù)架構(gòu)改造提出了如下技術(shù)需求：

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

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

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

圖3

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

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

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

（4）非結(jié)構(gòu)化數(shù)據(jù)的多副本災(zāi)備。以多副本的方式保存系統(tǒng)中的數(shù)據(jù)，提高數(shù)據(jù)安全性。

（5）海量非結(jié)構(gòu)化數(shù)據(jù)的異地災(zāi)備。支持跨數(shù)據(jù)中心的數(shù)據(jù)災(zāi)備能力。

（6）支持同城雙活的分布式架構(gòu)。

（7）數(shù)據(jù)庫，存儲等模塊都支持分布式架構(gòu)?？梢栽诰€不間斷業(yè)務(wù)的橫向擴(kuò)展。

（8）支持?jǐn)?shù)據(jù)生命周期管理。

（9）穩(wěn)定的獲得產(chǎn)品技術(shù)支持和定制開發(fā)。

（10）兼容傳統(tǒng)的架構(gòu)。

（11）便于現(xiàn)有生產(chǎn)數(shù)據(jù)的無縫遷移。項目規(guī)劃架構(gòu)圖如圖2所示。

3 分布式數(shù)據(jù)存儲平臺架構(gòu)選型

在新的影像平臺架構(gòu)設(shè)計中，根據(jù)影像平臺的特點，核心問題在于解決數(shù)據(jù)庫和內(nèi)容存儲兩個功能模塊的選型。根據(jù)行內(nèi)現(xiàn)有應(yīng)用使用到的技術(shù)，通過以下的技術(shù)對比，得到了每個技術(shù)的優(yōu)勢和劣勢。如圖3所示。

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

圖4：新影像平臺邏輯架構(gòu)圖

HBase 是基于Hadoop 的分布式鍵值數(shù)據(jù)庫，在行內(nèi)幾個項目中也用作非結(jié)構(gòu)化數(shù)據(jù)的解決方案。但是由于其設(shè)計上的初衷更多是面向結(jié)構(gòu)化數(shù)據(jù)的使用場景，在非結(jié)構(gòu)化數(shù)據(jù)量較大的時候，系統(tǒng)性能及穩(wěn)定性不太理想。

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

SequoiaDB 巨杉數(shù)據(jù)庫是國產(chǎn)的分布式數(shù)據(jù)庫，在行內(nèi)歷史數(shù)據(jù)查詢平臺等應(yīng)用上作為數(shù)據(jù)庫使用，也是項目的選型產(chǎn)品之一。巨杉數(shù)據(jù)庫支持對非結(jié)構(gòu)化內(nèi)容數(shù)據(jù)及其索引元數(shù)據(jù)的統(tǒng)一存儲和管理，消除了傳統(tǒng)內(nèi)容管理系統(tǒng)同時管理關(guān)系型數(shù)據(jù)庫和文件系統(tǒng)所帶來的管理負(fù)擔(dān)，支持橫向擴(kuò)展，適用于高并發(fā)、低時延的在線訪問場景。

圖5：新影像平臺疲勞測試結(jié)果

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

4 新影像平臺應(yīng)用架構(gòu)

新影像平臺的應(yīng)用邏輯架構(gòu)圖如圖4所示。

4.1 對象存儲方式

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

4.2 多樣化接入方式

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

4.3 動態(tài)資源隔離

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

4.4 分庫分表

根據(jù)系統(tǒng)類型進(jìn)行分類，將分類后的數(shù)據(jù)分表存儲，減少對單表的壓力。

4.5 海量數(shù)據(jù)準(zhǔn)實時災(zāi)備

采取應(yīng)用層實現(xiàn)同城雙活的技術(shù)方案，使用activeMQ 消息隊列實現(xiàn)同城數(shù)據(jù)準(zhǔn)實時同步，同步任務(wù)具備自動重試機(jī)制。

4.6 智能數(shù)據(jù)路由

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

5 新影像平臺測試情況

在確定了數(shù)據(jù)存儲架構(gòu)和應(yīng)用架構(gòu)之后，我行基于此方案進(jìn)行了開發(fā)測試。

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

根據(jù)目前生產(chǎn)運行情況，及對未來幾年業(yè)務(wù)增長情況預(yù)測，測試場景設(shè)計如表1所示。

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

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

在疲勞測試場景下，連續(xù)2 天，200 個并發(fā)用戶，系統(tǒng)處理能力和交易響應(yīng)時間基本保持穩(wěn)定，測試過程中未出現(xiàn)宕機(jī)、內(nèi)存泄露、性能下降等問題。

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

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

6 影像平臺遷移方案

測試完成并達(dá)到預(yù)期的測試結(jié)果后，我行開始積極準(zhǔn)備在生產(chǎn)上對數(shù)據(jù)進(jìn)行遷移。實施數(shù)據(jù)遷移方案的三個總體原則：

（1）舊存儲到新存儲無縫切換，不影響業(yè)務(wù)運營；

（2）數(shù)據(jù)遷移過程不需要多次維護(hù)窗口，不影響業(yè)務(wù)運營；

（3）簡單修改應(yīng)用即可適應(yīng)新存儲架構(gòu)。

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

（1）新應(yīng)用上線和巨杉數(shù)據(jù)庫集群擴(kuò)容；

（2）子系統(tǒng)增量數(shù)據(jù)分批次遷移至新環(huán)境；

（3）子系統(tǒng)存量數(shù)據(jù)遷移至新環(huán)境。

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

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

待所有舊環(huán)境中的數(shù)據(jù)都遷移至新環(huán)境，并驗證數(shù)據(jù)正確，數(shù)據(jù)遷移工作全部完成。

7 新架構(gòu)生產(chǎn)運行情況

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

8 總結(jié)和展望

通過分布式技術(shù)，民生銀行新影像平臺具備了海量非結(jié)構(gòu)化數(shù)據(jù)的實時服務(wù)能力，增強(qiáng)了系統(tǒng)平行擴(kuò)展的能力，增強(qiáng)了系統(tǒng)穩(wěn)定性，為遠(yuǎn)程銀行業(yè)務(wù)提供實時的音視頻訪問能力，同時也探索了分布式技術(shù)在該場景下的最佳實踐，在過程中創(chuàng)造性的解決了很多技術(shù)問題，無論是在業(yè)務(wù)支持還是在技術(shù)推廣上都具有現(xiàn)實意義。