滴滴基于Binlog的采集架构与实践

桔妹导读：大数据是这个时代赋予我们的强大引擎，在数字化大潮中 ，借助数据驱动的方法推动业务乘风破浪，几乎是每家公司的核心战略。数据驱动的落脚点是数据，能否将组织或业务运行过程中的信息，进行有效收集并组织成信息流，是数据驱动的基石所在。本文分享了滴滴数据体系建设过程中，MySQL这一类数据源的采集架构和应用实践。 

1. 

背景

关系模型构建起整个数据分析的基石，关系型数据库作为具体实现、采集MySQL数据接入Hive是很多企业进行数据分析的前提。如何及时、准确的把MySQL数据同步到Hive呢？

一般解决方案是使用类似Sqoop的工具，直连MySQL去Select数据存储到HDFS，然后把HDFS数据Load到Hive中。这种方法简单易操作，但随着业务规模扩大，不足之处也逐步暴露出来：

• 直连MySQL查询，对于数据库压力较大（如订单表、支付表等），可能直接影响在线业务

• 数据整体就位时间（尤其大表）不满足下游生产需求

• 扩展性较差，对于分表、字段增减、变更等的支持较弱

• 拉取的数据是该时刻的镜像，无法获取中间变化情况

为解决上述问题，我们引入Binlog实时采集 + 离线还原的解决方案，本文将从这两个方面介绍整个数据的接入流程。

 

2. 

整体数据流程

整体数据流程如上图所示，数据收集部分使用定制化Canal组件（基于阿里开源项目）收集binlog日志并做格式转换，然后通过消息队列传输并落地到HDFS，最后对HDFS上的binlog进行清洗还原入库。

如果是增量接入，上述操作就完成了一次入库流程。针对全量接入或者回溯历史数据，因为缺少历史binlog日志（发起采集时才开始收集）无法还原历史数据，此时需要借助离线一次性拉取，流程如下：

• 按照上述流程采集binlog日志增量入HDFS

• 使用离线一次性拉取一份历史全量数据，按字段还原到Hive作为基点（即第一个接入周期的数据）

• 使用前一个接入周期的全量数据和本周期的增量binlog做merge形成该周期内的数据。

相比一般解决方案，其优点比较明显，主要表现在：

• 基于Binlog日志的数据还原，与在线业务解耦

• 采集通过分布式队列实时传递，还原操作在集群上实现，及时性及可扩展性强

• Binlog日志包括了增、删、改等明细动作，支持定制化的ETL

3. 

Binlog

MySQL Binlog是二进制格式的日志文件，用来记录数据库的数据更新或者潜在更新(比如DELETE语句执行删除而实际并没有符合条件的数据)，主要用于数据库的主从复制以及增量恢复。

一共有两种类型二进制记录方式：

• Statement模式：每一条会修改数据的sql都会被记录在binlog中，如inserts, updates, deletes。