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

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

1 項(xiàng)目背景介紹

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

影像平臺(tái)主要用來(lái)對(duì)非結(jié)構(gòu)化數(shù)據(jù)進(jìn)行管理，提供跨業(yè)務(wù)系統(tǒng)的數(shù)據(jù)實(shí)時(shí)交換存取服務(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ù)庫(kù)解決海量非結(jié)構(gòu)化數(shù)據(jù)的唯一標(biāo)識(shí)(id)、業(yè)務(wù)屬性描述的存儲(chǔ)、檢索等功能需求。

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

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

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

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

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

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

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

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

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

2 項(xiàng)目建設(shè)需求

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

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

表1：新影像平臺(tái)測(cè)試場(chǎng)景

表2：新影像平臺(tái)獨(dú)立場(chǎng)景測(cè)試結(jié)果

表3：新影像平臺(tái)容量場(chǎng)景測(cè)試結(jié)果

圖3

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

（2）PB 級(jí)的存儲(chǔ)空間管理能力。

（3）以普通硬盤為存儲(chǔ)介質(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ù)庫(kù)，存儲(chǔ)等模塊都支持分布式架構(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ù)的無(wú)縫遷移。項(xiàng)目規(guī)劃架構(gòu)圖如圖2所示。

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

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

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

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

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

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

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

圖5：新影像平臺(tái)疲勞測(cè)試結(jié)果

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

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

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

4.1 對(duì)象存儲(chǔ)方式

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

4.2 多樣化接入方式

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

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

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

4.4 分庫(kù)分表

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

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

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

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

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

5 新影像平臺(tái)測(cè)試情況

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

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

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

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

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

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

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

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

6 影像平臺(tái)遷移方案

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

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

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

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

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

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

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

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

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

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

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

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

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

8 總結(jié)和展望

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