数随心动,沃趣QMatrix企业多云数据流计算平台!

发布时间:2020-06-01 | 信息来源: | 发布作者:沃趣科技




数据,是流动的, 

你信或者不信,他一直就是! 


如果能跟踪一条数据的流转轨迹,从产生到最后的沉淀,到底经过了哪些系统,小编君相信这条线会是蜿蜒曲折的。


曾几何,我们的数据架构还非常简洁,多个业务系统共享一套数据库,交易事务和报表分析的界限还不是那么清晰,那时数据共享的效率是最高的,近些年随着互联网大数据,人工智能AI,万物互联各种业务场景的丰富,企业数据已经成几何指数增长,有统计数据指出,人类近10年产生的数据量,远超以前所有数据量的总和。现今,出于性能扩展,安全隔离,容灾备份等各种需求的考虑,数据架构可谓是环肥燕瘦,各有千秋!


小编君在IT圈厮混多年,各种数据架构走马观花,也略有体验,对于数据的流动共享带来的业务价值,感触良多,这里不谈宏观层面的道法儒,单就具体的业务场景,我可以分享下自己的看法。


 1  分布式数据库的数据传输

在集中式架构中,数据就地存储,就地分析消费,称得上100%的实时Ad-hoc Query,Oracle RAC结合硬件加速堪称这一架构的典范,在TB数量级的联机分析混合需求上还是可以满足不少用户的,最关键一点,节省了开发成本,让用户可以把精力放在业务实现上。但随着数据规模的增加,为提升系统扩展性和可用性,逐渐采用分布式数据库来承担OLTP业务交易,数据一旦分片到物理主机,集中式查询分析就是个问题,这批数据如何能够快速,实时的传输到分析平台,就成了个硬需求。


 2  外围的数据消费升级

前台系统产生的交易数据,需要被多个下游系统消费,比如搜索引擎希望实时的build增量数据,提高准确性,或者缓存系统需要实时加载刷新,提升命中率,也许你可以说应用做紧耦合交数就好了,但现在业务开发的精力在业务,你没法要求他在完成业务逻辑的时候,还记得同步好缓存和搜索,况且紧耦合也是现在不大推崇的架构模式。


 3  容灾备份的需求升级

单就数据库这个场景,我们很容易想到Oracle DataGuard,MySQL Master/Slave,PostgreSQL复制,随着分布式架构的引入,你会面临做局部还是做整体的问题,这个变化是很微妙,也很有意思的,例如100台MySQL分布式数据库集群,同城异地做容灾解决方案,用什么?很简单,用Master/Slave,构建100条复制链路,做好自动化运维监控管理工具,处理好数据的延迟告警,不定期切换演练,这确实是实际可行的方案,但这是从DBA运维角度在解决问题,用户会怎么看这个问题呢?对于他来说,100台MySQL+路由中间件,构成了一个BigDB,这是一个整体,他不想再割裂成一个个分片去做这种紧耦合的局部同步,他的容灾也不一定是严格对等的,主机房100台MySQL服务器,备机房也许只需要70台,一个机器堆几个实例?一个实例堆几个schema db?不在BigDB层面做解耦,这个需求实现起来是很痛苦的,如果有一条超级数据传输管道,衔接主备机房的两套BigDB,这个问题会得到很大缓解。


 4  多云环境下的数据交互
云是稳定的,但不总是!有时候鸡蛋不想放在一个篮子里,或者出于企业数据监管的要求,用户会想到多云,小编君也有一个设想,能否主库在阿里云,备库在腾讯云,安全性可以提升一个量级,但这个已经远超技术架构的范畴。所以能够有一个管道应用,打通多云间的数据通道,让用户在上云下云时,不为数据的传输而烦恼,是非常有价值的。

 5  大环境的变化

中美贸易战,华为中兴的技术封锁,数据库翘楚Oracle在国内大规模裁员,这些事情凑在一起,着实对国内IT圈产生了不小的影响。天下苦秦久矣,小编君一直认为,随着商业数据库市场逐步被蚕食,以后数据信息的存储一定是多元化的,数据基础架构也会进入诸侯纷争的混沌时代,如今来了一剂催化剂,这个过程一定会加快,未来各种异构数据平台的共存会是个常态,平台间的的数据流动,更是个常态。


上述需求,从单体细节看,都有解决方案,各不相同,但从长远规划看,企业需要有一个数据总线,他可以作为数据核心枢纽,整合参差不齐的数据传输需求,统一数据接口。json/xml很大程度的意义在于让他让各个系统用普通话来交流,界面整齐划一,数据总线的建立,也有这层的含义,这是一种数据交互语义上的优雅与简洁。




小编所在的公司沃趣科技,致力于提供全栈式的数据库解决方案,已经累计服务客户500+,我们经过自己不断的思考与总结,也结合了客户的实际业务场景,研发出了QMatrix数据传输平台,并且已经在国内最大的省级电信公司上线,在其核心系统去IOE的过程中,承载了客户中心、结算中心、账务中心、CPC、充值中心,数据稽核、数据直采等十四大业务系统的数据流转,同时也实现了其同城异地双中心的数据传输同步。这里可以给大家分享介绍下我们对QMatrix建立的一些心得和想法。


 1  平台性能

性能就像口袋里的铜子儿,没人会嫌多,平台的意义在于实现数据的汇聚和共享,如果平台本身是瓶颈,他就失去了意义,很多用户不愿意做这种集中式的数据汇聚,就是担心他只是个正确的想法,而不是个落地的现实,好在我们现在的数据基础架构已经发生了不少由量到质的革新,很多以前认为无法逾越的障碍,现在已经不是问题。这就像在早期,大家都认为手机看视频是件很扯的事情,网速太慢,体验极差,但随着移动4G的普及,基础设施的改善,现在已经是件理所当然的事,所以小编君的思路是做架构一定是以发展的眼光来物色你手里的积木。经过实际测试,QMatrix自身轻松支持亿级日活数据的写入,这为数据的汇聚提供了有力性能保障。


 2  平台灵活度

在引入分布式架构后,数据的传输关系会变得错综复杂,绝非以前的表对表单线模式,例如一张业务表可能实际对应了128个分片实体表,但是业务是不去关心底层复杂的实体表逻辑的,我们在数据传输中也需要做到对业务是统一的业务表,对平台是128张实体分片表,另外由于对接的下游数据中心较多,每个中心对数据的取数逻辑都不尽相同,平台需要对汇聚的数据再做分流,每个数据流还要具备一定的逻辑转换能力。目前QMatrix已经可以支持可配置化的数据汇聚/分离策略,包括可外挂的数据转换逻辑定义,最大限度的满足业务需求。


 3  平台的连接范围

前面已经说过,数据架构以后会是多元化的,所以数据传输平台必须能够连接更多的数据架构,这个连接不仅仅只是功能上的连通,你还需要适配每个数据架构自身的特性,比如对于分布式的MySQL,由于已经是均匀的数据分片,每张实体表的数据不会太多,我们只需要考虑表级别的并发就可以满足性能需求,而Oracle是集中式的老架构,单张表就有上亿的数据规模,这个时候你得考虑单表内部的数据分片,使用PK范围,还是基于Oracle ROWID的物理范围,包括全量/增量的事务一致性处理方式,都是不一样的,所以连接是一个长期持续的细致活,平台要想成为正真的数据管道,这一步是少不了的,目前QMatrix已经对接了Oracle/MySQL/PostgreSQL / SQLServer / Kafka / HBase/Hive / HDFS 等多个平台及外围工具,小编君也知道这还远远不够,路漫漫,修远兮!!!


 4  平台的数据准确性

数据经由你的平台流转到了其他地方,你怎么保证两边的数据是一致的?这个世界足够复杂,当你不覆盖所有细节时,就有足够多的意外,所以一致性是相对的,我们需要在最大范围内保证这个一致性,。QMatrix平台已经自带QCheckX校验模块,可以实现Oracle/MySQL/PostgreSQL/平面数据文件的动态静态校验,在配置模式上也最大程度满足用户实际需求,例如一个分布式MySQL集群和一个集中式Oracle数仓,我们只需一些简单的配置组合,就可实现这种异构数据平台的校验。目前每天经由QCheckX校验对比的数据高达150亿,同时我们也研发支持了一键式错误结果repair功能,让整体传输更稳健。




最后的结语


在这个纷繁芜杂的信息世界中,数据的流通与共享,会产生更高的业务价值,企业不应该被具体的某项基础架构束缚,甚至绑架,他们应该有更多选择的权利,可以自由,灵活,开放的组织数据。借用一句广告词:


我们不生产数据,我们只是数据的搬运工,选择沃趣,数随心动!!!



沃趣科技,让客户用上更好的数据库技术!