大数据时代基于MongoDB的金融系统建设案例 | MongoDB中文社区

大数据时代背景下金融系统建设面临重重挑战，下边我们分享基于MongoDB建设金融系统的案例。目前该项目已稳定运行4年，经受住了大数据量时的高性能、高可靠的考验，也提升了金融系统的用户体验。

在接到这个项目时，客户主要面临以下一些挑战：历史数据总量大，存储成本高，且原系统随着时间的推移，数据量也越来越多，查询性能也越来越差，再加上计息日之后的查询交易量暴增，已经无法满足下游系统的使用，所以急需寻找一个成本低廉，性能高效稳定且能够解决上述问题的系统建设方案。

为了进一步挖掘存量数据的价值，分担现有交易系统的查询压力，补足交易系统无法支持大时间跨度、大数据量及模糊查询的短板，打通客户360数据共享给交易系统的渠道，客户迫切需要研发一套支持大数据量实时查询、统计、分析服务的可弹性扩展，高可靠，高效率，全行统一的大数据共享系统。

面临的主要挑战

项目研发过程中，我们面临的挑战急需解决的主要问题是：

一、历史存量数据量巨大。我们的金融客户自成立以来，有近400亿的客户交易流水，数据总量高达55TiB，日均写入数据量高达495282656条，日写入数据文件大小300G左右，需向全省2400多个实体网点，提供面向客户的“T+1”实时查询服务。

二、系统需支持可弹性扩展数据量，每天都在增加计算能力和存储容量，需弹性扩展。

三、系统需确保高可靠，大数据共享系统定位是向各类交易系统提供实时查询服务，可靠性要求等同实时交易系统。

四、系统的响应速度必须足够快，大数据共享系统服务的范围广，接入的渠道多，必须确保查询速度足够快。

五、系统需提供全文检索及模糊查询能力，业务人员的数据查询需求广泛，有时也不清晰，需提供引导式查询服务能力。支持大数据量的全文检索及模糊查询能力。

在技术选型的过程，我们结合客户需求，最终选用MongoDB来满足历史数据查询平台，多查询条件表结构低依赖性的需求。在下方的方案介绍部分，我们将一起看下为什么MongoDB可以满足相关需求。

大数据共享系统的设计标准是可向全行所有系统提供“T+1”实时历史数据查询、统计及分析服务，该项目方案需研发设计的方案包括系统架构方案、多渠道集成方案、高可靠方案及高性能方案。具体方案介绍如下：

一、系统架构方案

本系统架构设计的目标是向全行所有交易系统的明细、统计查询提供查询服务，实现查询服务的集中化、标准化管理和服务。因此，系统需要确保高可靠、高性能、可扩展能力，同时，要求既能提供前端设计服务，又能提供API接入服务，总体设计如下图所示：

架构共分五层分别是数据存储、业务管理、数据服务总线、报表开发及服务接入。其中数据存储是采用了开源分布式数据库MongDB，实现了高可靠、可扩展，采用分布式的微服务技术，研发的数据服务总线（DSB）实现了接口服务的统一化和标准化，以及高可靠和高性能，报表开发即功能业务，研发了自助查询服务，是通过研发的敏捷报表前端，实现了前端报表设计服务，能支持业务系统的单点登录集成。服务接入提供了统一、标准化的Https/Http、WebService的API服务。

二、可靠性方案

MongoDB采用分布式部署方式，数据在多个节点中有副本，中间任何一个节点出现异常时，数据不丢失。MongoDB自带HA方案，当主节点宕机后，通过选举生成新的主节点。

ES采用多客户机、多副本、多分片的部署方式，保证数据不丢失的同时提高数据载入效率。

微服务节点采用分布式部署，负载均衡Nginx为其作为代理，任何一个节点出现异常时，其它服务节点可以继续进行工作，负载均衡将新任务分配给其它服务节点继续工作。

其它平台功能提供运行监控，监控界面可以看到运行情况、使用情况、功能管理等，部份功能如数据加载过程出现异常时，通过连接短信平台，即时通知到维护人员需要进行人工处理。

平台管理数据采用PG数据库存储，节点间数据采取全量备份机制，Nginx实现负截均衡，PG服务器任何一个节点数据出现异常时，其他PG服务器可以继续进行工作，并且负载均衡将新任务分配给其他服务器继续工作。

三、高性能方案

性能优化原则：提高并行处理能力、减少不必要的数据处理、常用索引设置等。

MongoDB、PG、Elasticsearch采用分布式部署，增加数据存取并行处理服务器数量，增加数据存取效率；

微服务框架基于负载均衡器，实现高负载高并发高转发高可靠；

数据按日期分表，既保留历史数据，又提高了了当前数据的查询性能；

提供必要的预处理，处理工作分到系统空闲时间，减少查询时重复处理，降低用户等待时间。为常用查询条件映射字段构建索引，提高查询性能。

经过近一年的持续攻关，本项目从技术上和业务支撑上都有较多的突破创新,做到了六个“首次”：

一、首次使用开源分布式数据库MongDB服务联机交易。经过近半年的生产环境考验，在大数据量、高并发的环境下，达到了零故障。

二、首次使用微服务技术研发了分布式的面向全行所有系统的数据服务总线（DSB，Data Services Bus）。在渠道接入开发过程中，开发效率显著提高。

三、首次使用开源的ElasticSearch中间件实现了信贷业务全量数据的全文检索。经过总结分析我行信贷业务全量数据，提炼出了近3000个核心关键词及词组，建立了信贷业务的词库，实现了全文检索功能。

四、首次使用统计分析方法，持续提升用户操作体验。首次应用技术手段，落实以用户为中心的思想，实现了根据用户操作习惯，自动动态调整前端界面排列。

五、首次实现了业务人员可在线自定义查询。涉及查询条件、计算方式等，业务人员更方面、快捷、精准的获取数据，以便进行分析。

六、首次将近400亿的历史流水提供至全省所有网点，向客户提供“T+1”历史数据实时查询，有效提升了客户服务质量。

该系统架构是采用了开源分布式数据库MongDB用于数据存储、统计及分析，应用微服务技术，研发了数据服务总线（DSB），用于服务外部系统的数据查询分析，并集成了Elasticsearch 实现全行的文本资料搜索引擎。技术特点分析如下：

一、可扩展。开源分布式数据库MongDB的存储和计算能力可在线扩展，能保障业务连续性。

二、高可靠。经过实践验证，当集群节点故障时，对业务无任何影响，恢复过程中，用户无感知。并且，因DSB采用分布式集群的架构，不但能确保API的可靠性，性能也有足够的保障。

三、高性能。在大数据量的实际情况下，性能足够支持联机交易查询，生产实际情况达到了日均访问量100W+，并发达到200的毫秒响应，并且，随着数据量的持续增加，相比传统小机加关系型数据库的方案，性能优势越发显著。

四、接入高效。研发的微服务技术支持的DSB，后台准备好数据后，前端只需按标准调用API即可，开发效率极高。

五、前端报表实现了动态调整。根据后台记录的用户操作日志，采用统计分析方法，根据用户的操作习惯，实现了T+30的自动化调整前端查询条件的动态自动排列。

运营情况

系统上线稳定运营已经4年了，单点集成技术接入了信贷管理系统，通过DSB接入了柜面、智慧柜台、移动营销终端、厅堂管理系统、票据管理系统、电子档案系统和秒贷系统。截止当前，日均访问量100W+，最高并发数达到了200。特别是柜面和秒贷系统的接入，直接提供了联机交易服务，根据实际运营情况监控显示，前端响应效率达到了毫秒级，可靠性是零故障，这为后续全系统接入奠定了坚实的基础。

系统运行过程中，针对提供“T+1”数据服务的大数据量复杂查询，实时监控响应效率，以及系统资源使用情况，并采用统计分析方法，分析用户使用习惯日志，优化查询，响应效率显著提升。同时，通过研发了面向全信贷业务数据的全文检索功能，引导用户精准定位所关注的数据，进一步提升了用户获取数据的效率，降低查询过程中的工作量，用户反响极好。

项目成效

项目上线已经4年了，不但获得了用户的认可，也经受住了大数据量时的高性能、高可靠的考验。成效如下：

经济效益方面：系统采用了8台X86服务器，向全省提供了近400亿数据的实时查询，相比采用传统的小机+关系型数据库的方案，不但节省了硬件成本，还节省了数据库的采购成本，具有极高的性价比。并且，由于采用了微服务接口，极大的节省了接入系统的服务接口开发成本。

社会效益方面：本系统在研发过程中特别强调了用户体验，特别是首次向用户提供了信贷全量业务数据的全文搜索功能，性能高效，亿级数据秒级响应，用户反映很好，极大的提高了用户使用系统开展业务分析的积极性。并且，研发了基于微服务架构的DSB（数据服务总线），极大的降低了其他系统接入时开发的工作量，技术人员反响积极。

小结

在整个项目研发过程中，为了降低对其他需服务系统的影响，提高项目研发的质量，以及提高服务接入的效率和规范，积累的经验有：

一、制定标准极其重要。标准包括微服务接口标准、数据存储标准、项目开发标准、系统集成标准。各类标准的制定，极大的提高项目开发质量、接口开发效率和服务接入效率，有效的保障了项目能够按时按质交付。

二、性能优化经验需不断积累。性能优化涉及到数据分片存储策略设计、索引策略设计、数据库数据CHUNK的持续监控、缓存策略设计、微服务接口策略设计等。索引设计应根据用户的查询访问日志记录进行统计分析，进行索引字段调整；数据分布不均时，响应性能下降明显，需持续监控CHUNK；

三、项目过程管理不容懈怠。由于是第一次选用分布式开源数据库，并且数据量特别巨大，在项目研发过程中，碰到了很多的难题，各类标准制定、性能benchmark都是从0到1的过程，然而，我们始终坚持，提升用户体验为核心，不断持续优化系统操作体验和性能，这是整个团队对项目过程管理的严格把控不可或缺的。

随着互联网行业的蓬勃发展，各场景各类数据也越来越多，MongoDB是为大数据而生的，提供sharding机制用于实现业务的水平扩展。应该说sharding提供了完善的业务数据和负载水平扩展的机制，对于物联网、日志系统、历史数据系统和监控系统这类包含TB级海量数据的应用场景，使用MongoDB sharding是个不错的选择。

在生产环境中，sharding并不是必须的，并不是新业务起来的时候就马上部署sharding集群，只有当业务的数据量达到单个复制集无法支撑、或者业务的负载超过了复制集的服务能力的时候，才考虑部署sharding，毕竟相比复制集，sharding在部署和管理上都复杂很多。MongoDB复制集可以平滑升级到shard，所以当你真正需要sharding时，可以参考官方文档（Convert a Replica Set to a Sharded Cluster）进行操作，文档中提供了详细的升级步骤。

目前开源数据库众多，大家可选的余地很大，就会出现这样的问题，这些数据库哪个更好？其实这是一个伪命题，脱离了具体的业务场景来讨论好坏是纸上谈兵，没有最好的，只有最合适的，谁也无法保证完全取代谁，各数据库都在不停地完善自身。相信随着社区的发展与产品的不断迭代，MongoDB也会发展的越来越好。

总结起来，如果你的业务满足一个或多个特点，那么选择MongoDB是个正确的决定：

• 无需要跨文档或跨表的事务及复杂的join查询支持 // 目前已经支持事务，join的支持也越来越好（考虑版本）。
• 敏捷迭代的业务，需求变动频繁，数据模型无法确定。
• 存储的数据格式灵活，不固定，或属于半结构化数据。
• 业务并发访问量大，需数千的QPS。
• TB级以上的海量数据存储，且数据量不断增加。
• 要求存储的数据持久化、不丢失。
• 需要99.999%的数据高可用性，需要大量的地理位置查询、文本查询。

作者: 张志刚

广州云本开源软件有限公司系统架构师

团队介绍：

广州云本开源软件有限公司，致力于为客户提供基于开源软件的企业级服务，包括系统建设，软件研发，开源软件远程支持服务、开源软件使用治理、开源系统抢修、开源系统调优、开源系统巡检、开源数据库服务、开源架构设计、开源定制服务、开源主题培训和开源技术规范文档，解决企业在开源运维上所遇到的问题。

2021年MongoDB中文社区杭州大会就在下周六，诸多MongoDB技术分享和一手实践干货在现场等你来！

添加小芒果微信（ID：mongingcom）进入中文用户组技术交流群。