大咖专栏 | 让你的数据库流动起来 – 利用MySQL Binlog实现流式实时分析架构

大咖专栏

大咖专栏主要刊登亚马逊AWS诸位大咖亲自撰写的Blog，内容涉猎广泛，话题讨论前沿，且与实战紧密相连。我们非常欢迎小伙伴们在评论区留言，与大咖互动交流！

今天为大家撰文的大咖，是我们的AWS解决方案架构师——肖凌老师。

肖凌

AWS解决方案架构师

肖凌负责基于AWS的云计算方案架构的咨询和设计，同时致力于AWS云服务在国内和全球的应用和推广，在大规模并发后台架构、跨境电商应用、社交媒体分享 、Hadoop大数据架构以及数据仓库等方面有着广泛的设计和实践经验。在加入AWS之前曾长期从事移动端嵌入式系统开发。他曾任职IBM服务器开发工程师，并负责IBM亚太地区企业级高端存储产品支持团队，对基于企业存储应用的高可用存储架构和方案有深入的研究。

数据分析特别是实时数据分析，已经越来越多的成为各行各业的分析要求与标准——例如，（新）零售行业可能希望通过­­线下POS数据与实时门店客流流量的进行实时结合与分析，实现商品销售、销量、种类等等的实时预测； 在线广告平台期望通过广告(Impression)总类、数据量以及基于时间的点击（Click）量，计算实时的广告转化率(Conversion Rate)；物联网的用户想通过实时分析线下的状态设备与设备采集的数据，进行后台的计算与预判——例如做一些设备维修的提前预警(Predicative Failure Analysis)与线下用户的使用习惯；电商平台或者是在线媒体需要给终端用户提供个性化的实时推荐等等。

纵观这些业务系统，从数据流的角­­度看，往往数据架构可以分为前后端两个部分：前端的业务数据与日志收集系统（其中业务数据系统一般都是利用关系型数据库实现，例如 MySQL，PostgreSQL）与后端的数据分析与处理系统 （例如ElasticSearch 搜索引擎、Redshift数据仓库、基于S3的Hadoop系统等等，或者基于Spark Stream的实时分析后端）。

“巧妇难为无米炊”，实时数据分析的首要条件是实现实时数据同步，即从上述前端系统到后端系统的数据同步。具体来讲包含两个要求（根据业务场景的不同，实时性会有差异）：

1.    实时 

2.    异构数据源的增量同步。

实时的要求容易理解，无非是前后端系统的实时数据ETL的过程，需要根据业务需求，越快越好。所谓异构数据源的增量同步是指：前端产生的增量数据（例如新增数据、删除数据、更新数据，主要是基于业务数据库的场景，日志相对简单，主要是随时间的增量数据）可以无缝的同步到后端的数据系统，例如ElasticSearch，S3或者Redshift等。 显然，这里的挑战主要是来自于异构数据源的数据ETL——直白一点，就是怎么把MySQL（或者其他RDBMS）实时的同步到后端的各类异构数据系统。因为，MySQL的表结构的存储不能简单的通过复制操作实现数据同步。

业界典型的做法大概可以归纳为两类：

1.    通过应用程序双写的架构 (Application Dual-writes)  。
2.    利用流式架构实现数据同步，即基于流式数据的Change Data Caputre (CDC) 。

双写架构实现简单，利用应用逻辑实现，但是要保证数据一致性相对复杂（需要通过二阶段提交实现 – two phase commit），而且，架构扩展相对比较困难——例如增加新的数据源，数据库等。

利用流式数据重构数据，越来越成为很多用户与公司的实时数据处理的架构演化方向。 MySQL的Binlog，以日志方式记录数据变化，使这种异构数据源的实时同步成为可能。 今天，我们主要讨论的是如何利用MySQL的Binlog实现流式数据同步。

MySQL Binlog数据同步原理

讲了这么多，大家看张图，我们先了解一下MySQL Binlog的基本原理。

MySQL的主库（Master）对数据库的任何变化（创建表，更新数据库，对行数据进行增删改），都以二进制文件的方式记录与主库的Binary Log（即Binlog）日志文件中。从库的IO Thread异步地同步Binlog文件并写入到本地的Replay文件。SQL Thread再抽取Replay文件中的SQL语句在从库进行执行，实现数据更新。 

需要注意的是，MySQL Binlog 支持多种数据更新格式——包括Row，Statement，或者mix（Row和Statement的混合）。我们建议使用Row这种Binlog格式（MySQL5.7之后的默认支持版本），可以更方便更加实时的反映行级别的数据变化。

如前所述，MySQL Binlog是MySQL主备库数据同步的基础，因为Binlog以日志文件的方式，记录了数据库的实时变化，所以我们可以考虑类似的方法 – 利用一些客户端工具，把它们伪装成为MySQL的Slave（备库）进行同步。

基于Binlog的流式日志抽取的架构与原理

在我们这个场景中， 我们需要利用一些客户端工具“佯装”成MySQL Slave，抽取出Binlog的日志文件，并把数据变化注入到实时的流式数据管道中。我们在管道后端对Binlog的变化日志，进行消费与必要的数据处理（例如利用AWS的Lambda服务实现无服务器的代码部署），同步到多种异构数据源中——例如 Redshift, ElasticSearch, S3 (EMR) 等等。具体的架构如下图所示：

这里需要给大家介绍一个比较好的MySQL的Binlog的抽取工具 Maxwell’s Daemon。这款由Zendesk开发的开源免费(http://maxwells-daemon.io/) Binlog抽取工具可以方便的抽取出MySQL（包括AWS RDS）的变化数据，方便的把变化数据以JSON的格式注入到后端的Kafka或者Amazon Kinesis Stream中。我们把RDS MySQL中的Binlog输出到控制台如下图所示（ 下图表示从employees数据库的employees数据表中，删除对应的一行数据）：

在上述架构中，我们利用Lambda实时读取Amazon Kinesis Stream中的MySQL Binlog日志，通过Kinesis Firehose实时地把MySQL binlog的结构数据自动化地同步到S3和Redshift当中。

值得注意的是，整个架构基于高可用和自动扩展的理念 – Kinesis Stream（ 高可用），Lambda（Serverless与自动扩展），Kinesis Firehose(兼具高可用与自动扩展)。Kinesis Stream作为统一的一个数据管道，可以通过Lambda把数据分发到更多的数据终点 – 例如，ElasticSearch或者DynamoDB中。

接下来我们会介绍：

动手构建实时数据系统的具体步骤
具体分为六个步骤

请感兴趣的童鞋
马上点击“阅读原文”

或扫描/长按识别下方的二维码

阅读完整版文章

Step by step的学起来吧！