小米 MySQL 数据实时同步到大数据数仓的架构与实践
背景
MySQL由于自身简单、高效、可靠的特点,成为小米内部使用最广泛的数据库,但是当数据量达到千万/亿级别的时候,MySQL的相关操作会变的非常迟缓;如果这时还有实时BI展示的需求,对于mysql来说是一种灾难。
为了解决sql查询慢,查不了的业务痛点,我们探索出一套完整的实时同步,即席查询的解决方案,本文主要从实时同步的角度介绍相关工作。
早期业务借助Sqoop将Mysql中的数据同步到Hive来进行数据分析,使用过程中也带来了一些问题:
虽然Sqoop支持增量同步但还属于粗粒度的离线同步,无法满足实时性的需求
每次同步Sqoop以sql的方式向Mysql发出数据请求也在一定程度上对Mysql带来一定的压力
同时Hive对数据更新的支持也相对较弱
为了更有效地连接前端业务数据系统(MySQL)和后端统计分析系统(查询分析引擎),我们需要一套实时同步MySQL数据的解决方案。
小米内部实践
如何能够做到数据的实时同步呢?我们想到了MySQL主从复制时使用的binlog日志,它记录了所有的 DDL 和 DML 语句(除了数据查询语句select、show等),以事件形式记录,还包含语句所执行的消耗时间
下面来看一下MySQL主从复制的原理,主要有以下几个步骤:
master(主库)在每次准备提交事务完成数据更新前,将改变记录到二进制日志(binary log)中
slave(从库)发起连接,连接到master,请求获取指定位置的binlog文件
master创建dump线程,推送binlog的slave
slave启动一个I/O线程来读取主库上binary log中的事件,并记录到slave自己的中继日志(relay log)中
slave还会起动一个SQL线程,该线程从relay log中读取事件并在备库执行,完成数据同步
slave记录自己的binlog
binlog记录了Mysql数据的实时变化,是数据同步的基础,服务需要做的就是遵守Mysql的协议,将自己伪装成Mysql的slave来监听业务从库,完成数据实时同步。
结合小米内部系统特点,构建了Mysql数据同步服务–-LCSBinlog,作为一种独立的数据接入方式整合在Talos Platform中,Talos Platform作为大数据集成的基础解决方案,以自研消息队列Talos为数据总线,连接各种系统为主要目标,提供丰富的数据Source输入和数据Sink输出,并且Talos天然支持流式计算,因此业务可以充分利用Talos Platform互联互通的特性,并结合自身的业务需求实现更加高阶的业务场景。
上图是Talos Platform中的整体流程架构,其中标红部分是目前LCSBinlog在小米内部使用最广泛的一条链路:Mysql ---> Talos ---> Kudu ---> BI,数据同步到kudu后借助Sparksql查询引擎为上层BI系统提供即席查询服务,Kudu和Sparksql的整合细节可以参见往期内容:告别”纷纷扰扰”—小米OLAP服务架构演进
LCSBinlog服务的主体架构
服务一共有两种角色
Master :主要负责作业的调度,
Worker: 主要完成具体的数据同步任务
在Worker上运行两种作业:
BinlogSyncJob:每一个mysql库都会对应这样一个Job,将binlog日志完整地写入到服务创建的Talos topic中
MysqlSyncJob:同步历史数据,消费binlog数据,过滤特定库表数据实时同步至用户配置的topic中
服务整体依赖于Zookeeper来同步服务状态,记录作业调度信息和标记作业运行状态;在kudu表中记录作业同步进度
控制流程如下:
Worker节点通过在Zookeeper上注册告知自己可以被调度
通过在Zookeeper上抢占EPHEMERAL临时节点实现Master的HA
用户在融合云(Web)上注册BinlogSource同步任务
Master周期性从配置服务读取Binlog同步作业配置
Master更新Zookeeper中的调度信息
Worker节点 根据Zookeeper上的调度信息启动新分配任务,停止配置失效任务;作业启动后完成数据实时同步并周期性将同步进度记录在kudu中
服务上报监控信息到Falcon平台,作业异常退出发送报警邮件
如何保障数据正确性
>>>>
顺序性
用户配置的每一个BinlogSource 都会绑定一个Talos的topic,在进行消费的时候需要保证同一条mysql记录操作的顺序性,消息队列Talos是无法保证全局消息有序的,只能保证partition内部有序。
对于配置分库分表或者多库同步任务的BinlogSource,服务会根据库表信息进行hash,将数据写入相应的partiton,保证同一张表的数据在一个partition中,使得下游消费数据的顺序性;
对于单表同步的作业目前使用一个partition保证其数据有序。
>>>>
一致性
如何保证在作业异常退出后,作业重新启动能够完整地将mysql中的数据同步到下游系统,主要依赖于以下三点
服务会记录作业同步的offset,重启后从上次commit的offset继续消费
Binlog数据的顺序性保证了即便数据被重复消费(未commit的数据),也能对同一条记录的操作以相同的顺序执行
下游存储系统kudu,Es ,Redis基于主键的操作能够保证binlog重复回放后数据的最终一致性
应用场景
有了这份数据我们可以做些什么事情呢,本节例举了几种常见的应用场景
>>>>
实时更新缓存
业务查询类服务往往会在mysql之上架设一个缓存,减少对底层数据库的访问;当mysql库数据变化时,如果缓存还没有过期那么就会拿到过期的数据,业务期望能够实时更新缓存;
利用binlog服务,根据策略实时将数据同步到redis中,这样就能够保证了缓存中数据有效性,减少了对数据库的调用,从而提高整体性能。
>>>>
异步处理,系统解耦
随着业务的发展,同一份数据可能有不同的分析用途,数据成功写入到mysql的同时也需要被同步到其他系统;如果用同步的方式处理,一方面拉长了一次事务整个流程,另一方面系统间也会相互影响
数据在mysql中操作成功后才会记录在binlog中,保证下游处理到时的一致性;使用binlog服务完成数据的下发,有助于系统的解耦
关于异步处理,系统解耦在消息队列价值思考一文中有更深入的解读
>>>>
即席查询的BI系统
就如文章开篇提到的,mysql在一定场景下的性能瓶颈,mysql数据同步到kudu后可以借助sparksql完成性能的提升
因为同样是sql接口,对使用者的切换成本也是较低的,数据同步到更适合的存储中进行查询,也能够避免因大查询而对原mysql库其他查询的影响
目前小米内部稳定运行3000+的同步作业,使用binlog服务同步数据到kudu中;小米内部BI明星产品XDATA借助整套同步流程很好地支持了运营、sql分析同学日常统计分析的需求
如何使用Binlog数据
用户接入数据的时候要求mysql库开启binlog日志格式必须为Row模式:记录的是每一行记录的每个字段变化前后的值,虽然会造成binlog数据量的增多,但是能够确保每一条记录准确性,避免数据同步不一致情况的出现
最终通过监听binlog日志,LCSBinlog服务将数据转换成如下的数据结构,写入用户注册的Topic中, 目前Sink服务使用SparkStreaming实时转储数据到kudu中,后续也将逐步迁移到Flink上以提升资源利用、降低延迟
业务用户也可以根据我们提供的数据格式,实时消费Talos数据以实现更复杂的业务逻辑,下表为每一种数据操作,是否保存修改前后的列表
疑难杂症
下面分享2个上线后遇到的有趣问题
>>>>
数据不一致问题,业务使用唯一索引
业务接入一段时间后, 发现部分表会偶尔存在kudu表的数据条目数多于同步的mysql表的数据条目数,我们将多出来的数据与mysql产生的binlog日志经过一一对比,发现用户在mysql表中设置了唯一索引,通过唯一索引修改了主键,而kudu中的数据是通过主键标识或更新一条记录的,于是update操作变成了insert操作,这就造成了原来的1条记录变成了2条。
解决办法:对于这种类型的表,LCSBinlog服务会把一次Update操作转换成一条Delete数据和一条Insert数据
>>>>
Full Dump同步历史数据时,客户端超时
服务刚上线的时候,通过jdbc 执行sql的方式完成全量历史数据的同步,在同步的过程中会发现dump任务会卡顿很长时间才会返回结果,当数据量很大会出现超时同步失败的情况,会造成数据的延迟。调研后发现使用mysql官方jdbc在客户端查询数据的时候,默认为从服务器一次取出所有数据放在客户端内存中,fetch size参数不起作用,当一条SQL返回数据量较大时可能会出现OOM
解决办法:当statement设置以下属性时,采用的是流数据接收方式,每次只从服务器接收部份数据,直到所有数据处理完毕。优化后历史数据同步稳定运行,对mysql端的压力也很小
总结
MySQL以Binlog日志的方式记录数据变化,基于流式数据的Change Data Caputre (CDC)机制实现了LCSBinlog服务,
本文主要对LCSBinlog的服务架构、应用场景以及在小米内部的实践经验进行了介绍,也和大家分享了我们实际中遇到的问题和解决方案,希望能够帮助到大家理解服务的原理,带来启发,也欢迎大家和我们一起交流。
小米 MySQL 数据实时同步到大数据数仓的架构与实践相关推荐
- binlog流程 mysql_小米 MySQL 数据实时同步到大数据数仓的架构与实践
背景MySQL由于自身简单.高效.可靠的特点,成为小米内部使用最广泛的数据库,但是当数据量达到千万/亿级别的时候,MySQL的相关操作会变的非常迟缓:如果这时还有实时BI展示的需求,对于mysql来说 ...
- 什么是数据实时同步,为什么数据实时同步很重要
随着云成为前所未有的数据供应渠道,数据准确性.一致性和隐私性的重要性与日俱增.看似轻微的数据错误或故障可能会产生重大负面影响.但是,对数据进行排序并将其与现有,然后定期解析数据实时同步,同时保持数 ...
- 美团 数据实时化是广告行业数仓建设的主流趋势
内容摘要 数据实时化是数仓建设的趋势,相对于离线数仓,实时数仓能够给管理者.业务分析人员提供反应业务变化的实时数据,监控收入等关键指标的波动,及时根据市场热点变化调整运营策略,通过实时算法决策,提供更 ...
- 百分点“数据隧道”玩转大数据平台实时数据复制
实时数据复制技术在银行.电信.保险.政务和电商等领域应用非常广泛. 比如银行领域的收单业务涉及收单行.银行卡组织及发卡行的数据同步.收单行的数据需要传输到银行卡组织,再由银行卡组织传输给发卡行. 如果 ...
- 【达梦数据库】数据实时同步软件 + 数据对比工具
文章目录 前言 一.数据实时同步软件 1.1 简单介绍 1.2 模块说明 二.数据对比工具 2.1 简单介绍 2.2 架构说明 三.DMETL vs DMHS 总结 前言 达梦数据实时同步软件(DMH ...
- 小米技术分享:Mysql数据实时同步实践
背景 MySQL由于自身简单.高效.可靠的特点,成为小米内部使用最广泛的数据库,但是当数据量达到千万/亿级别的时候,MySQL的相关操作会变的非常迟缓:如果这时还有实时BI展示的需求,对于mysql来 ...
- Mysql数据实时同步实践
关于小米内部使用的数据库你知道多少?(文末有福利) 往期文章回顾:Flink流式计算在节省资源方面的简单分析 背景 MySQL由于自身简单.高效.可靠的特点,成为小米内部使用最广泛的数据库,但是当数据 ...
- mysql 同步到es_mysql数据实时同步到Elasticsearch
业务需要把mysql的数据实时同步到ES,实现低延迟的检索到ES中的数据或者进行其它数据分析处理.本文给出以同步mysql binlog的方式实时同步数据到ES的思路, 实践并验证该方式的可行性,以供 ...
- mysql 同步 es_mysql数据实时同步到Elasticsearch
业务需要把mysql的数据实时同步到ES,实现低延迟的检索到ES中的数据或者进行其它数据分析处理.本文给出以同步mysql binlog的方式实时同步数据到ES的思路, 实践并验证该方式的可行性,以供 ...
最新文章
- 解决sharepoint 2010浏览器在线浏览Word出错
- 把委托说透(2):深入理解委托
- linux ftp配置chroot,vsftp chroot 设置
- PuTTY 远程连接矩池云GPU主机
- DisSent: Learning Sentence Representations from Explicit Discourse Relations
- 数据分析的升级版本--excel数据对比--整体思路
- ERROR 1129 (HY000): mysqladmin flush-hosts
- CNware防DDOS攻击介绍--云宏
- 直观理解图像的分形维数附matlab实现
- element-this.$confirm确定-取消位置交换
- dhcp authoritative参数作用
- go语言命令入门之env(操作环境信息)
- el-progress入门学习
- 拉文大学计算机科学,美国研究生语言双录取,这些大学有你中意的吗?
- vue.runtime.esm.js?2b0e:619 [Vue warn]: Error in v-on handler (Promise/async): “Error: 失败“found in
- 目前国内常用的无纸化会议系统——迅控无纸化
- 网站服务器发生故障,全国DNS服务器发生故障
- LeetCode-70. 爬楼梯(java)
- 第一章 行列式 第七节 克拉默法则
- 华为手机怎么找回桌面计算机,华为手机界面文件夹消失如何恢复