在现有的架构中做大数据分析,第一步面临的问题就是数据如何从关系型数据库到非关系数据库,网上有很多的解决方案,我们也经过了很多的摸索,经历了三套方案的实践,最终使用了canal。这是我们大数据部门的一个同事张同睿写的文章,分享给大家,如果感兴趣后面可以进一步的介绍。
需求背景
近年来,微服务概念持续火热,网络上针对微服务和单体架构的讨论也是越来越多,面对日益增长的业务需求是,很多公司做技术架构升级时优先选用微服务方式。我所在公司也是选的这个方向来升级技术架构,以支撑更大访问量和更方便的业务扩展。
发现问题
微服务拆分主要分两种方式:拆分业务系统不拆分数据库,拆分业务系统拆分库。如果数据规模小的话大可不必拆分数据库,因为拆分数据看必将面对多维度数据查询,跨进程之间的事务等问题。而我所在公司随着业务发展单数据库实例已经不能满足业务需要,所以选择了拆分业务系统同时拆分数据库的模式,所以也面临着以上的问题。本文主要介绍多维度数据实时查询解决方案。当前系统架构和存储结构如下:
解决思路
-
要对多数据库数据进行查询,首先就需要将数据库同步到一起以方便查询
-
为了满足大数据量数据需求,所以优先选择NOSQL数据库做同步库
-
NOSQL数据库基本无法进行关联查询,所以需要将关系数据进行拼接操作,转换成非关系型数据
-
业务多维度查询需要实时性,所以需要选择NOSQL中实时性相对比较好的数据库:MongoDB
根据以上思路,总结数据整合架构如下图所示:
解决方案
目前网上一些数据同步案例分两种:MQ消息同步和binlog数据读取同步
先说MQ消息同步,该同步方式我所在公司试用过一段时间,发现以下问题:
-
数据围绕业务进行,对业务关键性数据操作发送MQ消息,对业务系统依赖性比较高
-
对于数据库中存量数据需要单独处理
-
对于工具表还需要单独维护同步
-
每次新增数据表都需要重新添加MQ逻辑
考虑到以上问题,用MQ方式同步数据最优解决办法
使用binlog 数据读取方式目前有一些成熟方案,比如tungsten replicator,但这些同步工具只能实现数据1:1复制,数据复制过程自定义逻辑添加比较麻烦,不支持分库分表数据归集操作。综上所述,最优方案应该是读取后binlog后自行处理后续数据逻辑。目前binlog读取binlog工具中最成熟的方案应该就是alibaba开源的canal了。
canal
canal是阿里巴巴mysql数据库binlog的增量订阅&消费组件 。阿里云DRDS、阿里巴巴TDDL 二级索引、小表复制. 都是基于canal做的,应用广泛。canal原理相对比较简单:
-
canal模拟mysql slave的交互协议,伪装自己为mysql slave,向mysql master发送dump协议
-
mysql master收到dump请求,开始推送binary log给slave(也就是canal)
-
canal解析binary log对象(原始为byte流)
canal介绍: https://github.com/alibaba/canal/wiki
我使用的是canal的HA模式,由zookeeper选举可用实例,每个数据库一个instance,服务端配置如下:
目录:
conf database1 -instance.properties database2 -instance.properties canal.properties
canal.instance.mysql.slaveId =instance.properties 1001 canal.instance.master.address = X.X.X.X:3306 canal.instance.master.journal.name = canal.instance.master.position = canal.instance.master.timestamp = canal.instance.dbUsername = canal canal.instan