金融级数据库提升商业银行核心竞争力

2020-05-29 00:00:00 数据 架构 分布式 系统 商业银行

引言

信息处理是银行业的核心,完善的数据和信息管理是商业银行进行有效风险防控和提升金融服务质效的基础。但随着银行业务的快速创新与发展,商业银行传统的IT系统和数据架构在性能和稳定性上均面临新挑战。同时,对于经营风险的银行来说,数据安全牵一发而动全身,业务传导的压力也带来了新的数据安全隐患和问题。在此背景下,商业银行传统数据库无论是从数据安全、性能、灵活可持续性还是性价比来讲,都已显得力不从心。

在大数据时代下,商业银行IT技术架构应向分布式架构转型。以巨杉数据库为代表的金融级数据库,有足够强大的OLTP能力,可为商业银行提供包括海量数据存储管理、高并发数据读写查询、多模数据处理等在内的功能,这是未来数据库发展的核心要求,也是解决商业银行当务之急的重要科技手段。


商业银行的大数据需求

随着商业银行技术和业务的发展,其在大数据技术层面的需求有如下重要变化和特点:

一是商业银行的数据呈现急剧增长,这对数据存储和管理提出了更高要求。以大型商业银行为例,通常它们拥有成百上千个业务系统以及上亿用户的海量数据,且数量呈现指数级增长,从TB级别增加到PB级别,未来很快就会增加至EB级别,这些都需要有效的管理以及实现实时访问。

二是商业银行对数据安全更加重视。当前,商业银行对IT端安全可控要求不断提升,在确保数据不能丢失的同时,还要做好数据的容灾备份以及核心数据系统的“双活”,即在两个数据中心实时进行备份,一旦失去一个中心,所有业务可以及时切换中心继续运行。

三是需要面临高并发业务和高用户量带来的系统压力。随着互联网金融业务的开展,商业银行用户量和用户自身应用权限不断增加,银行持续面临高并发业务和高用户量带来的系统压力。比如,过去银行主要通过柜面接收账单查询,现在则主要依托移动端用户自助查询,在某一峰值的操作量就可能超过过去一整天业务操作量的总和。

四对移动应用响应速度要求更快。在移动互联网用户应用需求迅速增加的背景下,用户对移动应用的响应速度有了更高要求,移动端响应必须做到秒级以下。除此之外,商业银行自身也需要提升大数据技术能力和业务价值,增强自身运营管理能力。

五是技术层面的国产化需求。近年来,银行业在技术方面正在积极进行国产化改造。商业银行在稳定性和安全性上对数据产品要求近乎严苛,但海外产品和开源技术不能完全满足国内用户需求,所以亟需能满足核心系统需求的真正国产自研数据产品。


这里需要特别说明的是,在商业银行的IT架构中,如手机银行、网上银行以及信用卡等主要业务系统,都需要有对应的交易数据库,通常这些传统数据库,在保证交易系统性能的前提下,还需要存储12个月的历史数据以便供实时访问时调用。如今,由于用户希望能够更快地查询过往历史数据,使得容量压力不断增大,传统数据库的扩容不仅大大提高了成本,在并发等要求上也很难真正满足性能提升的需求。

此外,随着银行远程开户、柜面无纸化、双录、会计档案管理等系统的建立和升级,影像系统除了满足商业银行在线业务系统不断提升的访问性能需求外,还需要提供作为在线系统的高可用、灾备甚至“双活”能力,以保证系统数据安全。对于IBM CM等传统数据管理平台,除了扩容成本高昂外,实时和并发能力更难以满足当前需求,也无法实现真正高可用和灾备“双活”,所以商业银行在数据管理上亟待转型。


商业银行银行大数据转型

应用和业务层的压力,给商业银行IT和数据架构带来了新需求和挑战,分布式技术架构转型的需求也就应运而生。商业银行亟需分布式架构转型,主要体现在如下几个方面:

,亟需提升海量数据系统管理弹性。当商业银行系统内数据量急剧增大时,系统需要弹性地扩容以应对PB级别以上的数据管理,这种弹性容量调整可以实现让所有数据保持在线。

第二,亟需提升数据系统管理性能。针对客户的实时需求,商业银行数据系统需要满足高并发业务操作需求,实现海量数据超高性能读写以及实时访问查询。

第三,亟需升级数据安全保障。数据安全不仅仅是简单的备份,除了实现数据的持续高可用外,还应支持异地容灾甚至数据中心“双活”,进而保障数据安全。

第四,亟需满足多类型数据处理需求,提升系统效率。在跨业务的融合中,亟需实现对多模数据的统一管理,从结构化数据到半结构化数据再到非结构化数据,进而实现不同类型的数据统一融合管理,从而大大提升系统效率。

第五,亟需简化开发运维节约成本。随着应用的增多,更需要分布式架构支持,进行数据分区管理,实现业务有效隔离。同时,保持系统的弹性、兼容性,大大简化运维开发。

第六,亟需有能力支撑核心业务系统的国产产品。除了数据安全的要求和“技术先进”,对于核心业务,更重要的是对产品代码级具有控制力,这样可以保证产品针对用户共性需求不断进行迭代更新,也带来产品稳定性以及高效强力的技术支持。


针对以上诉求,在分布式架构转型过程中,我认为可采用三种不同的思路:

种思路是“生产系统瘦身”。就是将原有部署在主机集中式系统的存量非核心业务,逐步迁移至开放平台分布式架构系统中。巨杉数据库已经在部分商业银行中参与了此项工作。

第二种思路是对传统架构的完全替换。就是对部署在开放平台并采用传统集中式架构的系统,结合业务特点差异有选择性地实施分布式架构改造。一般来说,只有当传统架构面临必须被替换的痛点时大家才会选择这个方案。

第三种思路是对新服务和新业务直接采用分布式架构。对于近年来新推出的相关业务,可发挥分布式架构等新技术优势和作用,促进产品创新和服务能力提升,也就是新服务新业务直接采用分布式架构,部分直销银行已采用此种思路试水分布式架构。

巨杉金融级数据库助力银行大数据转型案例


【案例1】海量影像数据分布式架构替换 实现数据中心“双活”

近年来,影像系统已经逐渐成为商业银行核心流程的一部分,从过去的非关键系统上升为一级系统或A级系统。某商业银行,由于柜面无纸化、集中授权以及远程开户此类以影像为基础的业务陆续上线,使用传统IBM CM作为影像系统已变得力不从心了。同时,随着数据安全要求,该行还需要对影像数据进行灾备和同城“双活”。

巨杉使用Sequoia CM替代了过去的IBM CM产品,在系统的扩展性、性能、可靠性上均比传统技术有了极大提升。目前,在巨杉的SequoiaCM上该银行已有超过20个影像内容相关系统接入平台,影像数据存储超过2PB。同时,巨杉数据库还实现了同城“双活”,大大增强了数据的安全性、可用性。


【案例2】分布式数据库完美解决千亿数据超高并发实时访问难题

某金融机构对客户的手机APP需要对股民近几年的全部历史股票交易提供在线可查询访问检索功能,数量达数千亿条规模。同时,在系统峰值下还需要提供超过20000TPS的并发操作和毫秒级别的访问速度。任何传统单点架构的数据库产品均无法支撑如此大的并发访问量,但通过巨杉的分布式数据库解决了了该用户的需求。


【案例3】减负核心系统

在某家股份制银行业务系统的交易数据库中,只能保留1年历史数据,超过一年的历史数据只能离线存储在磁带库中。随着该行手机银行、网银和信用卡业务的加速发展,以及规划中的用户端“历史流水查询”,原有交易数据库不堪重负,该行为了避免高成本传统数据库的继续“扩容”,选择了分布式架构改造。

巨杉数据库将该银行包括影像以及业务系统的历史数据从磁带中完全转移至分布式数据库内进行在线归档,同时将存放在生产系统中两年内的数据完全放到分布式数据库进行管理。一方面,实现了已有交易数据库的“减负”,交易系统应对查询所保留的数据可以将降到3个月甚至1个月,进一步释放了交易系统性能。另一方面,可以在分布式架构下将过去几十年积累的离线历史数据实现在线化,随时提供给用户使用和查询。

通过分布式架构的数据平台应用,这家股份制商业银行,节约了超过30%的核心系统计算能力,并且实现了毫秒级别实时查询。同时,分布式数据库也成功减轻了这家商业银行原有的核心系统压力,大大降低了系统继续扩容成本和运维成本。

相关文章