首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

海科融通数据中心技术架构演进

在海科融通第四代平台开发过程中,数据中心项目作为新平台的核心项目之一,经历了从无到有到发展的一系列过程。在这个过程中,数据中心在技术架构上也进过了一些列演进。此文简要揭露一下数据中心技术架构演进过程。

背景

技术是服务于业务的,没有业务需求的技术架构是无源之水。数据中心项目也是在新平台业务平台的需要而产生的。

海科新平台是根据微服务化设计思想来设计的。业务系统根据业务模型拆分出几十个服务系统提供服务,为了配合为微服务化设计,数据库也是根据微服务化系统来设计的,每个基础服务对应专属数据库。为了满足大数据量高并发的需要,在部分微服务化数据库中,用到了分库分表的设计思想。

在数据库分裂的同时,业务系统不能按照微服务化思想设计,业务模式需要保持不变,旧系统中需要的多维度数据查询依然是必要的查询需求,实时性也不能有太大的改变。

基于以上需求,数据中心孕育而生

探索期

数据中心调研

如上图所示:

在当前主流数据仓库产品中,数据加工速度和数据管理能力是不可兼得的

每一中数据存储产品都有自己特定的应用场景

流计算在处理海量数据实时处理最佳的选择

结合初步数据调研,HBase和MongoDB在当前在性能上是满足我们最初需求最佳选择

HBase初探

列存储模式,基于HDFS文件存储,使用列蔟概念,单条数据更新性能相对比较弱

有唯一主键RowKey,原生不支持索引,可以使用第三方索引

数据模型设计困难,根据列查询缓慢,rowkey难于设计,无法预测查询维度

使用成本比较高,部署成本较高,集成第三方索引复杂,学习曲线比较陡峭,开发成本比较高

基于以上原因,HBase未作为业务数据主仓库作为存储介质

MongoDB选择

面向文档存储,基于Bson存储,支持多种数据类型

支持索引,支持自建索引,支持组合索引

热点数据缓存,数据查询性能强,更新性能不弱,支持分片模式横向扩展

数据运维方便,具备完善的运维工具,支持可视化客户端工具

数据模型灵活,支持子文档和数组文档,支持聚合查询方法多样

使用成本较低,集群搭建简单稳定,功能开发简单,学习曲线平缓

基于以上数据对比,我们最终选择mongDB作为业务数据主仓库

成型期

消息队列数据同步

在最初的技术架构中,采用业务消息数据同步的方式,如下图:

在各种业务系统埋点,监控数据变动

在数据变动是,发送变动数据到RabbitMq消息中

启动系统监听RabbitMq消息并解析

保存数据到MongoDB数据库

这种架构结构简单,但并部可靠。原因如下

对业务系统侵入性强,每次数据变动都需要发送MQ消息

无法保证数据一致性,业务系统变更,系统稳定性等因素都会影响数据一致性

消息中间件压力比较大,数据量大是消息中间件压力大,数据量不可控

基于以上原因,我们有了下面的解决方案(BINLOG事件同步)

BINLOG事件同步(canal)

启动 canal server,模拟数据库从库

提取Mysql数据库BinLog数据并解析DML消息

启动canal client,订阅DML消息

将DML消息数据转换成MongoDB入库数据

保存数据到MongoDB数据库中

这种技术架构结构完美解决了上一个方案所有的问题

数据同步与平台业务完全解耦,零依赖

数据最终一一致,BinLog数据是事务执行成功后的数据

数据模型灵活,元数据与Mysql数据1:1复制,整合数据模型灵活

数据模型建立

为什么要建立数据模型?

由于非关系型数据库基本都不支持数据表关联查询,MongoDB也不支持,所以需要在使用之前建立数据模型,以满足各种业务需求

如何建立数据模型呢?

数据模型的作用就是满足各种运营需求。所以我们第一版的数据模型是完全依赖运营系统建立起来的,运营系统的数据查询维度最多。为了兼容后续需求变更,数据模型是以mysql元数据(行数据)为基本单位,数据冗余比较多,但胜在兼容性强,模型组合简单

数据模型要求

由于随着数据规模的变大,更新数据模型会越来越困难,所以对于数据模型的第一版数据模型有一个硬性要求,要满足90%业务需求

发展期

数据同步工具(canal)优化

在基本数据模型建立完成以后,就需要考虑优化的问题。优化方式如下图:

如图所示,优化的方式如下:

将旧的server-client模式的系统集成成一个系统

将三组集群改成两组

这样做的原因是:

1.由于Binlog的日志属性,数据都是有时间顺序的。canal集群模式服务端和客户端节点都只会有一个节点在运行

2.合并server和client 可以将部署工作量减半,服务器资源使用减半,并且省去了服务端可客户端传输过程

优化后每开一条业务线需要部署的系统从6个变成2个,一个主节点,一个备份节点

数据多线同步

随着业务线扩展,数据消息同步也同时跟进进行了扩展,如下图

得益于对数据同步工具的优化,在公司业务扩展时,数据同步项目对服务器消耗并没有对公司服务器资源做过多的消耗,部署工作也方便了很多,极大的节省了公司的人力物力

未来

HBase实时数据线

在满足基本业务需求的同时,我们并没有满足当下,正在积极部署新的数据线,以实现对数据的实时流计算

启动canal-kafka 服务,模拟数据库从库获取数据

发送数据消息到kafka中

使用Spark Stream接收数据消息

实时分析数据到HBase指标库中

保存数据到HBase历史库中

实时流数据计算在风险管控,合规管理,反洗钱等方面都有得天独厚的优势。在实时流数据计算完成以后必然会推动海科融通业务实力的进步

数据增值服务

海科融通在收单支付行业已经有十多年的历史了,有着巨大的历史数据。对于大数据蓬勃发展的今天,这些数据是一个并未被开发的金矿,如何让这些数据产生额外的价值是我们以后工作的重点

结术语

满足运营需求不是终点

对技术的追求没有止境

想象力有多大,数据价值就有多大

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180907G0J4HI00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券