|NO.Z.00006|——————————|BigDataEnd|——|Hadoop&实时数仓.V06|——|项目.v06|Canal同步业务数据|环境准备|初始Canal|

一、Canal同步业务数据

### --- 环境准备

~~~     Hadoop、HBASE、Flink、ClickHouse、MySQL、Canal、Kafka

### --- 初始Canal：什么是 Canal

~~~     阿里巴巴B2B公司，因为业务的特性，卖家主要集中在国内，买家主要集中在国外，
~~~     所以衍生出了杭州和美国异地机房的需求，
~~~     从2010年开始，阿里系公司开始逐步的尝试基于数据库的日志解析，
~~~     获取增量变更进行同步，由此衍生出了增量订阅&消费的业务。
~~~     Canal是用java开发的基于数据库增量日志解析，提供增量数据订阅&消费的中间件。
~~~     目前，Canal主要支持了MySQL的binlog解析，
~~~     解析完成后才利用Canal client 用来处理获得的相关数据。
~~~     （数据库同步需要阿里的otter中间件，基于Canal）。

二、使用场景：

原始场景:阿里otter中间件的一部分otter是阿里用于进行异地数据库之间的同步框架Canal是其中一部分。

常见场景1：更新缓存

场景2：抓取业务数据新增变化表，用于制作拉链表：订单表,6月20号有3条记录：

订单创建日期	订单编号	订单状态
2012-06-20	001	创建订单
2012-06-20	002	创建订单
2012-06-20	003	支付完成

到6月21日，表中有5条记录：

订单创建日期	订单编号	订单状态
2012-06-20	001	支付完成(从创建到支付)
2012-06-20	002	创建订单
2012-06-20	003	支付完成
2012-06-21	004	创建订单
2012-06-21	005	创建订单

到6月22日，表中有6条记录：

订单创建日期	订单编号	订单状态
2012-06-20	001	支付完成(从创建到支付)
2012-06-20	002	创建订单
2012-06-20	003	已发货(从支付到发货)
2012-06-21	004	创建订单
2012-06-21	005	支付完成(从创建到支付)
2012-06-21	006	创建订单

在数据仓库中设计成历史拉链表保存该表

订单创建日期	订单编号	订单状态	dw_begin_date	dw_end_date
2012-06-20	001	创建订单	2012-06-20	2012-06-20
2012-06-20	001	支付完成	2012-06-21	9999-12-31
2012-06-20	002	创建订单	2012-06-20	9999-12-31
2012-06-20	003	支付完成	2012-06-20	2012-06-21
2012-06-20	003	已发货	2012-06-20	9999-12-31
2012-06-21	004	创建订单	2012-06-21	9999-12-31
2012-06-21	005	创建订单	2012-06-21	2012-06-21
2012-06-21	005	支付完成	2012-06-22	9999-12-31
2012-06-22	006	创建订单	2012-06-22	9999-12-31

~~~     dw_begin_date表示该条记录的生命周期开始时间，dw_end_date表示该条记录的生命周期结束时间；
~~~     dw_end_date = '9999-12-31'表示该条记录目前处于有效状态；
~~~     如果查询当前所有有效的记录，则select * from order_his where dw_end_date = '9999-12-31'
~~~     如果查询2012-06-21的历史快照，
~~~     则select * from order_his where dw_begin_date <= '2012-0621' and end_date >= '2012-06-21'，
~~~     这条语句会查询到以下记录和源表在6月21日的记录完全一致

订单创建日期	订单编号	订单状态	dw_begin_date	dw_end_date
2012-06-20	001	支付完成	2012-06-21	9999-12-31
2012-06-20	002	创建订单	2012-06-20	9999-12-31
2012-06-20	003	支付完成	2012-06-20	2012-06-21
2012-06-21	004	创建订单	2012-06-21	9999-12-31
2012-06-21	005	创建订单	2012-06-21	2012-06-21

### --- 场景3：抓取业务表的新增变化数据，用于制作实时统计。

~~~     # Canal的工作原理：复制过程分成三步：
~~~     Master主库将改变记录写到二进制日志(binary log)中
~~~     Slave从库向MySQL master发送dump协议，
~~~     将master主库的binary log events拷贝到它的中继日志(relay log)；
~~~     Slave从库读取并重做中继日志中的事件，将改变的数据同步到自己的数据库。
~~~     Canal的工作原理很简单，就是把自己伪装成slave，假装从master复制数据。

三、MySQL的binlog

### --- 什么是binlog

~~~     MySQL的二进制日志可以说是MySQL最重要的日志了，
~~~     它记录了所有的DDL和DML(除了数据查询语句)语句，
~~~     以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。
~~~     一般来说开启二进制日志大概会有1%的性能损耗。二进制有两个最重要的使用场景:
~~~     其一：MySQL Replication在Master端开启binlog，
~~~     Mster把它的二进制日志传递给slaves来达到master-slave数据一致的目的。
~~~     其二：自然就是数据恢复了，通过使用MySQLbinlog工具来使恢复数据。
~~~     二进制日志包括两类文件：
~~~     二进制日志索引文件（文件名后缀为.index）用于记录所有的二进制文件，
~~~     二进制日志文件（文件名后缀为.00000*）
~~~     记录数据库所有的DDL和DML(除了数据查询语句)语句事件。

### --- binlog的开启

~~~     # 在MySQL的配置文件(Linux: /etc/my.cnf , Windows: \my.ini)下,修改配置在[mysqld] 区块，设置/添加
~~~     # 这个表示binlog日志的前缀是mysql-bin ，以后生成的日志文件就是 mysql-bin.123456 的文件后面的数字按顺序生成。 每次MySQL重启或者到达单个文件大小的阈值时，新生一个文件，按顺序编号。
log-bin=mysql-bin

### --- binlog的分类设置

~~~     # 在配置文件中可以选择配置
~~~     # MySQL binlog的格式有三种，分别是STATEMENT,MIXED,ROW。
binlog_format=row

### --- 区别：

~~~     # statement
~~~     语句级，binlog会记录每次一执行写操作的语句。
~~~     相对row模式节省空间，但是可能产生不一致性，比如：update tt set create_date=now()
~~~     如果用binlog日志进行恢复，由于执行时间不同可能产生的数据就不同。
~~~     优点： 节省空间
~~~     缺点： 有可能造成数据不一致。

~~~     # row

~~~     行级， binlog会记录每次操作后每行记录的变化。
~~~     优点：保持数据的绝对一致性。因为不管sql是什么，引用了什么函数，他只记录执行后的效果。
~~~     缺点：占用较大空间。

~~~     # mixed

~~~     statement的升级版，一定程度上解决了，
~~~     因为一些情况而造成的statement模式不一致问题在某些情况下譬如：
~~~     当函数中包含 UUID() 时；
~~~     包含 AUTO_INCREMENT 字段的表被更新时；
~~~     执行 INSERT DELAYED 语句时；
~~~     用 UDF 时；
~~~     会按照 ROW的方式进行处理
~~~     优点：节省空间，同时兼顾了一定的一致性。
~~~     缺点：还有些极个别情况依旧会造成不一致，
~~~     另外statement和mixed对于需要对binlog的监控的情况都不方便。

Walter Savage Landor:strove with none,for none was worth my strife.Nature I loved and, next to Nature, Art:I warm'd both hands before the fire of life.It sinks, and I am ready to depart

——W.S.Landor