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

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

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

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

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

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

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

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

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

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

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