小米 MySQL 数据实时同步到大数据数仓的架构与实践

背景

MySQL由于自身简单、高效、可靠的特点，成为小米内部使用最广泛的数据库，但是当数据量达到千万/亿级别的时候，MySQL的相关操作会变的非常迟缓；如果这时还有实时BI展示的需求，对于mysql来说是一种灾难。

为了解决sql查询慢，查不了的业务痛点，我们探索出一套完整的实时同步，即席查询的解决方案，本文主要从实时同步的角度介绍相关工作。

早期业务借助Sqoop将Mysql中的数据同步到Hive来进行数据分析，使用过程中也带来了一些问题：

• 虽然Sqoop支持增量同步但还属于粗粒度的离线同步，无法满足实时性的需求

• 每次同步Sqoop以sql的方式向Mysql发出数据请求也在一定程度上对Mysql带来一定的压力

• 同时Hive对数据更新的支持也相对较弱

为了更有效地连接前端业务数据系统（MySQL）和后端统计分析系统（查询分析引擎），我们需要一套实时同步MySQL数据的解决方案。

小米内部实践

如何能够做到数据的实时同步呢？我们想到了MySQL主从复制时使用的binlog日志，它记录了所有的 DDL 和 DML 语句（除了数据查询语句select、show等），以事件形式记录，还包含语句所执行的消耗时间

下面来看一下MySQL主从复制的原理，主要有以下几个步骤：

1. master（主库）在每次准备提交事务完成数据更新前，将改变记录到二进制日志(binary log)中

2. slave（从库）发起连接，连接到master，请求获取指定位置的binlog文件

3. master创建dump线程，推送binlog的slave

4. slave启动一个I/O线程来读取主库上binary log中的事件，并记录到slave自己的中继日志(relay log)中

5. slave还会起动一个SQL线程，该线程从relay log中读取事件并在备库执行，完成数据同步

6. slave记录自己的binlog   

binlog记录了Mysql数据的实时变化，是数据同步的基础，服务需要做的就是遵守Mysql的协议，将自己伪装成Mysql的slave来监听业务从库࿰