民生银行基于分布式数据库的影像平台建设

文/周鹏 朱彬 王健 孔再华 梁田

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 总结和展望

通过分布式技术，民生银行新影像平台具备了海量非结构化数据的实时服务能力，增强了系统平行扩展的能力，增强了系统稳定性，为远程银行业务提供实时的音视频访问能力，同时也探索了分布式技术在该场景下的最佳实践，在过程中创造性的解决了很多技术问题，无论是在业务支持还是在技术推广上都具有现实意义。