• 快捷搜索
  • 全站搜索

分布式数据库应用趋势分析

2017-12-26 16:53:38作者:广州巨杉软件开发有限公司董事长、CTO王涛编辑:金融咨询网
从数据库的角度出发,尽管如DB2 DPF、Teradata等传统MPP数据库同样使用分布式架构,但新型基于PC服务器的分布式架构早已经脱离单纯的数仓领域,被应用到包括数据分析、交互式处理、大数据计算、流计算等多种不同业务场景。

分布式数据库发展历程

  伴随着银行信息化建设不断深入和提高,越来越多的业务与应用开始认真考虑,使用PC服务器与分布式架构替换传统集中式架构的可行性。从数据库的角度出发,尽管如DB2 DPF、Teradata等传统MPP数据库同样使用分布式架构,但新型基于PC服务器的分布式架构早已经脱离单纯的数仓领域,被应用到包括数据分析、交互式处理、大数据计算、流计算等多种不同业务场景。

  一般来说,前端应用、中间件以及后端存储几大模块中,前端应用与中间件在分布式演进道路中比较简单易行。而后端存储,尤其是数据库存储部分,使用分布式架构替换传统集中式架构,在技术上则存在诸多挑战。

  总体来看,最近几年中,分布式数据库产业在迅速蓬勃发展,市面上涌现出一大批优秀的MPP与NoSQL数据库,并且在互联网金融、移动互联网等领域得到了大规模的应用。同时,由于微服务架构开始越来越多地被人们所熟悉,当一些新型业务在采用微服务体系构建时,其服务之间的通讯往往使用JSON数据结构,存储模型也往往更加贴近应用逻辑,在数据层面做到“面向对象”。这使得新型分布式数据库在微服务体系中更多地被用于替换传统关系型数据库。

  这意味着从技术上说,分布式数据库已经可以在低延时、大并发的交易类型中占据核心位置,只不过传统银行业想要规模性引进分布式数据库,还需要一段时间的锤炼与洗礼。

分布式数据库替换传统关系型数据库

  在金融行业数据库向分布式架构前进的道路上,基本所有管理决策人员所秉承的理念都是长期看好、谨慎行动的方针。一般来讲,使用新型分布式数据库在业界存在两种思路。第一类方式是将使用传统关系型数据库产生严重瓶颈的应用迁移到分布式数据库中,使用新型技术来解决已有问题;第二类方式则是以全新的项目入手,整体应用架构设计之初就秉承分布式理念,使用分布式数据库得到存储部分的高可用及水平扩张能力。

  这两类方式在实施的过程当中,各自存在一些不同的风险点需要实施人员注意。

  第一类方式,应用迁移至分布式数据库,必然涉及已有应用的迁移与改造问题。数据库的迁移是应用程序改造中最为庞大的工程。基本所有应用在开发之初,都会确定所使用数据库的类型,这样应用程序开发人员可以根据底层数据库适当使用其特有的机制进行优化。例如,一些Oracle绑定的应用程序可能使用到大量的PLSQL存储过程,这使得应用程序从Oracle迁移到其他关系型数据库成为了几乎不可能的任务。因此,在进行应用程序迁移的项目中,首先需要评估该应用程序的开发到底使用到多少之前数据库所特有的机制和功能。其次,不同的数据库拥有各自的适用场景。所有应用程序开发之初,选型时会根据业务场景类型的不同而使用不同的数据库。因此,在考虑对已有应用改造的过程中,新引入的数据库是否能够适应该类型的业务场景,同时还需要考虑的要素包括性能、一致性、事务支持性、并发度等软指标。最后,开发人员对新型数据库的接受与掌握程度直接影响迁移的时间与成本。现在几乎没有任何分布式数据库能够做到100%兼容传统Oracle或DB2。因此在对于新型数据库SQL语法的掌握、性能的调优、测试的完善程度等不同部分都需要额外关注,做好完善的前期工作,避免在应用迁移到一半以后发现困难重重。

  因此,对于已有应用向分布式数据库迁移的过程当中,实施人员会遇到诸多的挑战,并且并不是所有的应用都适合进行迁移,一些在设计之初就与底层数据库紧耦合的应用可能直接重新开发新的版本是更好的选择。

分布式数据库支撑新业务

  第二类方式是将新业务直接建立在分布式数据库的思路,是当今业界成功案例较多的主流方式。一些直销银行、双录系统、内部云平台管理监控、大数据数据湖等新型业务可以直接考虑使用分布式数据库作为底层存储。这种方式可以完全避免应用程序设计的历史包袱,不存在将已有SQL向新平台迁移时所出现的性能下降或语法改写等问题。

  但这种方式也存在挑战。最重要的挑战是对于新业务行方没有历史经验或者数据可以借鉴,很难直接固定出一些业务指标进行硬性规范。例如,笔者之前参与过一个证券项目,其在线业务部分实时并发处理指标从设计讨论之初的每秒3000到后期确定的每秒几万,跨度有十几倍的差距。行业IT或业务人员对一些新型互联网金融类型业务理解的不到位,可能会造成项目初期设计与最终交付时存在巨大差异,从而导致对新型数据库选型和评估更加困难。

  新类型的应用在部署和规划时,也应该秉承风险低、投入小、见效快三个基本原则,以类似互联网应用开发的思路做到小步快跑、频繁迭代、快速试错,从而避免使用新技术时可能遇到的困难和误区。一般来说,第一批使用新技术的应用最好能够规划为4~6个月的周期,在相对可控的资金与时间投入下进行设计与开发。

  新类型业务可以分为内部与外部两类应用。从风险上来看,肯定是内部应用所造成的风险相对较小。因此业界大多数使用新技术的应用首先会围绕内部数据进行。当新技术在企业内得到一定程度的验证后才会进行外部应用的调整和改造。当然,业界也存在很多对外的新业务由于需求不得不直接使用分布式数据库,才能够满足其并发性、实时性与吞吐量的要求。

  常见的使用分布式数据库的内部应用包括数据平台类、内部管控类、风险管理类、精准营销类等应用。

  数据平台:数据平台类应用多为大数据平台、近线数据平台、数据湖、归档平台等将企业中不同部门的原始数据进行统一汇总类型的应用。这类应用的主要目的一方面可以为企业建立统一的原始数据汇总集市,让整个企业中所有业务的历史数据做到在线化与可操作化,在某种程度上可以替代传统磁带的功能。另一方面可以将这些数据提供给行内外的用户直接访问。例如对于行内用户可以进行跨业务和部门的自由查询分析平台,对行外用户则可以做到对于交易历史明细的全时间轴查询。

  内部管控:内部管控类应用主要围绕企业内部IT系统、人员考核系统等业务构成。一般来说,这类业务会产生大量的系统或操作日志。对这些日志的归档与分析则是该类应用主要解决的业务问题。

  风险管理:风险管理类应用部分引入流计算技术,将一些传统事后分析的业务场景前移做到事中监控。例如对于网银、手机APP等渠道进行的交易使用流处理技术,结合NoSQL数据库做到交易行为监控,直接阻拦或对可疑交易提出告警。

  精准营销:精准营销类应用则是结合用户画像、零售等系统,在不同渠道进行广告推送、产品推荐等业务。该类应用的核心是数据与模型的准确性,才能对正确的人在合适的时间推荐正确的产品,否则仅功能存在而业务价值上不一定能够迅速体现出巨大的效果。

  除了上述一些内部系统,金融行业中很多外部系统也可以考虑使用分布式数据库进行搭建。譬如影像类应用、直销银行类应用、生产库瘦身类应用都可以考虑使用分布式存储、MPP数据库以及NoSQL数据库等技术。

  影像:影像类应用主要解决的问题是随着互联网金融业务的加速,越来越多的金融机构开始提供远程开户、虚拟柜员、VTM等类型的业务。根据监管要求,这类远程操作的业务需要进行视频与音频的录音录像功能。而存储音视频所需要的空间与传统仅存储票据证件类型的业务相比,对于带宽、存储量以及吞吐量的要求存在巨大提升。因此,很多企业中使用的传统ECM系统无法满足新业务的需求,因而使用新型分布式数据库或存储替代传统ECM是一个较好的选择。

  直销银行:直销银行根据不同企业和机构具体规划的不同,可以考虑使用开源关系型数据库与NoSQL数据库混搭的方式。其中,核心账务、交易、结算等传统业务可以考虑使用开源关系型数据库构建,而一些优惠券、营销、日志类业务则可以使用分布式NoSQL数据库构建。

  生产瘦身:生产库瘦身则是一些以使用新技术将传统业务部分剥离核心库的思路,可以按照时间维度或业务维度进行切分。例如,对于历史数据查询类业务可以考虑将三个月内数据查询依然使用核心库,三个月外的数据归档到分布式数据库的方式,做到冷热数据隔离;另外有的企业则构建了“用户资产视图”等业务,将生产库中多表数据使用NoSQL数据库进行统一汇总,提供准实时的统一资产查询服务。

(文章来源:金融电子化杂志)

扫码即可手机
阅读转发此文

本文评论

相关文章