Flink的实时同步(转载官方文档)
Flink的实时同步(转载官方文档)
根据数据源的数据是否实时变化可以把数据同步分为离线数据同步和实时数据同步，上面介绍的断点续传就是离线数据同步里的功能，实时采集其实就是实时数据同步，当数据源里的数据发生了增删改操作，同步任务监听到这些变化，将变化的数据实时同步到目标数据源。除了数据实时变化外，实时采集和离线数据同步的另一个区别是：实时采集任务是不会停止的，任务会一直监听数据源是否有变化。
基于binlog的实时采集
目前FlinkX支持实时采集的插件有KafKa，binlog插件，binlog插件是专门针对mysql数据库做实时采集的，如果要支持其它的数据源，只需要把数据打到Kafka，然后再用FlinkX的Kafka插件消费数据即可，比如oracle，只需要使用oracle的ogg将数据打到Kafka。
这里我们专门讲解一下mysql的实时采集插件binlog。
binlog
binlog是Mysql sever层维护的一种二进制日志，与innodb引擎中的redo/undo log是完全不同的日志；其主要是用来记录对mysql数据更新或潜在发生更新的SQL语句，并以"事务"的形式保存在磁盘中。
binlog的作用主要有：
-
复制：MySQL Replication在Master端开启binlog，Master把它的二进制日志传递给slaves并回放来达到master-slave数据一致的目的；
-
数据恢复：通过mysqlbinlog工具恢复数据；
-
增量备份；
MySQL主备复制
有了记录数据变化的binlog日志还不够，我们还需要借助MySQL的主备复制功能：主备复制是指 一台服务器充当主数据库服务器，另一台或多台服务器充当从数据库服务器，主服务器中的数据自动复制到从服务器之中。
主备复制的过程：
-
MySQL master 将数据变更写入二进制日志( binary log, 其中记录叫做二进制日志事件binary log events，可以通过 show binlog events 进行查看)；
-
MySQL slave 将 master 的 binary log events 拷贝到它的中继日志(relay log)；
-
MySQL slave 重放 relay log 中事件，将数据变更反映它自己的数据；
canal
有了binlog日志数据和MySQL的主备复制功能，我们只需要模拟一台Slave，将接收到的binlog数据解析出来就可以做到实时采集MySQL的数据变化，阿里巴巴贡献的canal组件就实现了这样的功能。
canal工作原理：
-
canal模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送dump 协议
-
MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即 canal )
-
canal解析 binary log 对象(原始为 byte 流)
写入Hive
binlog插件可以监听多张表的数据变更情况，解析出的数据中包含表名称信息，读取到的数据可以全部写入目标数据库的一张表，也可以根据数据中包含的表名信息写入不同的表，目前只有Hive插件支持这个功能。
Hive插件目前只有写入插件，功能基于HDFS的写入插件实现，也就是说从binlog读取，写入hive也支持失败恢复的功能。
写入Hive的过程：
-
从数据中解析出MySQL的表名，然后根据表名映射规则转换成对应的Hive表名；
-
检查Hive表是否存在，如果不存在就创建Hive表；
-
查询Hive表的相关信息，构造HdfsOutputFormat；
-
调用HdfsOutputFormat将数据写入HDFS；