银行影像内容管理平台选型,是传统的Oracle/DB2架构,还是分布式文档数据库,还是基于Hadoop的大数据平台?

关于银行的影像内容管理平台选型,是传统的Filenet&Oracle/DB2架构,还是分布式文档数据库,还是基于Hadoop的大数据平台?银行IT从业人员都非常熟悉影像平台这个系统,它是为开户、理财、票据、信贷等业务系统提供非结构化&半结构化影像数据存取的平台,传统都以IBM的Filene...显示全部

关于银行的影像内容管理平台选型,是传统的Filenet&Oracle/DB2架构,还是分布式文档数据库,还是基于Hadoop的大数据平台?

银行IT从业人员都非常熟悉影像平台这个系统,它是为开户、理财、票据、信贷等业务系统提供非结构化&半结构化影像数据存取的平台,传统都以IBM的Filenet&关系型数据库为基本架构,
但是随着影像数据的快速膨胀,这些数据再次读取的效率明显下降,主要原因在于文件树的存储架构和数据量级的不匹配,另外结构化信息和非结构化信息分离的架构也导致了数据安全性及存取复杂度的提高。
另外企业也为此需要付出更多的NAS存储空间成本。因此大家开始探寻一条新的路子,大家开始关注文档数据库,比如以MongoDB为基础的各类产品;也有人开始关注大数据平台,例如以hadoop为基础的各类产品。部分企业早已开始了尝试。那么,从以下几个维度来看,这几种架构哪一个更适合金融企业呢?

  1. 投资成本维度。
  2. 平台可靠性维度。
  3. 横向扩展能力维度。
  4. 与银行应用衔接复杂程度的维度。
  5. 运维复杂度维度。
收起
参与89

查看其它 16 个回答atpeace331的回答

atpeace331atpeace331数据库管理员银行

个人建议如下,能力经验有限,还请各位专家多多指正,在此谢过!

    1、由于银行影像内容管理平台的主要数据类型是 半结构化的影像数据 并且 随着银行互联网业务的迅猛发展需要影像平台的资源能够弹性地横向扩展及很高的图像读取性能。因此 传统的Oracle/DB2架构这种集中式一体化的架构及 有限的非关系数据结构的支持能力肯定是不适合作为 银行影像内容管理平台的!

    2、Hadoop 虽然是分布式架构,满足横向扩展能力,但是前期要针对Hadoop 特点进行影像平台开发,后期需要专门的技术人员进行运维,否则稳定性很难保障,人员投入成本会很高!

    3、分布式文档数据库,倒是一个非常不错的方案, 影像内容管理平台的开发成本相比  Hadoop 方案降低不少,而且在分布式文件存取性能,资源的弹性横向扩展,自动化运维方面都有着不错的表现!我们这边主要使用的  SequoiaDB  巨杉数据库,一款非常赞的国产的文档型分布式数据库!
    创始人 王涛,本 IBM DB2社区的远古大神wangzhounew,原 IBM 多伦实验室的专家!
    以下是他们影像平台的方案,您可以参考下:

金融影像平台应用

金融行业在业务运营中会产生大量纸质凭证,在信息化处理和监管要求下,这些纸质的凭证都需要扫描成影像文件并长期保存。随着互联网金融、流程银行、直销银行、移动作业以及集中作业中心等理念的深入推广,银行、保险等金融机构普遍需要建设统一的影像管理平台。

影像系统主要有以下的特点:

  • 总体数量大:不同银行的规模,业务种类和上线的时间不同,业务系统中存放的文件数量往往达到千万级甚至数亿级。
  • 存储成本高:影像系统占用的存储空间以TB为计,最高甚至达到PB级别,要同时为支持影像文件大量存取,以及要支持多业务系统,因此系统对于存储设备的I/O要求较高,造成影像平台系统存储成本居高不下,逐年递增。
  • 生命周期管理不易:影像文件的存取通常发生在3个月内,一年后的查询调阅机率低,通常要定期卸载历史数据,使用冷介质进行离线管理,但数据可用性没保障。
  • 备份时间长:数据需要备份保护,但海量小文件的备份效率很低,耗时较长,全量备份往往会超过备份窗口所能提供的时间。
  • 历史影像文件查询难:因存储成本较高,对历史影像会进行离线归档,使得历史影像文件的查询调阅需要耗费大量的人力成本来完成,无法保证“快速响应”。
  • 数据量逐年增加:随着业务品种的拓展、网点数目的增加、移动作业的新需求等,数据量随时间呈显著上升的趋势。这导致生产系统容量需求不断增加,需要不断扩容。

                                              基于SequoiaCM搭建的影像平台简要架构

针对这些挑战,基于SequoiaCM构建的金融行业新一代影像系统,全面解决了这些问题。包括柜面无纸化系统、会计影像系统等等。SequoiaCM搭建的影像平台能够提供给客户的价值包括:

  • 影像数据弹性扩展:影像数据的存储和计算资源随业务需求动态调整,实现PB级别以上的存储,影像数据持续在线;
  • 内容管理:丰富的内容管理功能,包括生命周期管理,内容数据存取,批次服务,版本控制以及检入检出服务等功能。
  • 统一管理:影像文件数据和元数据统一存储,提升应用性能且简化运维;
  • 自由检索:对于海量影像数据,做到多维度自由检索与实时查询,毫秒级别的查询效率;
  • 数据安全:实现同城“双活”以及“异地容灾”需求,内容数据保证长效、安全、可用,数据安全保障大大增加,同时满足“两地三中心”等行业监管要求。
  • 降低成本:采用低成本的通用硬件设备以及分布式架构,大幅度降低整体拥有成本(TCO)至原有ECM方案的1/3;
银行 · 2021-07-02
  • 我在想,如果用MongoDB,是不是会更好呢? 从横向的扩展性上、数据切片的灵活度上,运维的复杂度上,感觉MongoDB更有优势。 另外,这个已经使用文档数据库案例的银行,他们运行的如何?稳定性上以及缺陷的优化补丁方面做得工作是不是很多?
    2021-07-07
  • 如果团队有丰富的 MongoDB 开发运维经验,当然可以使用 MongoDB来替代;我这边之所以选择巨杉数据库,除了产品优秀以外,还有就是厂商服务、技术支持保障这块。我们这边的测试、生产环境影像平台在巨杉上跑了3、4年了,很稳定,目前没啥问题。
    2021-07-08
  • 应用是谁家的?中科金财?应用改动大不大?
    2021-07-12
  • 应用是信雅达做的。如果是基于原有系统改造的话,这个应用改造最好和厂商探讨评估下。
    2021-07-13

回答者

atpeace331
数据库管理员银行

atpeace331 最近回答过的问题

回答状态

  • 发布时间:2021-07-02
  • 关注会员:22 人
  • 回答浏览:6132
  • X社区推广