目录
方案2:三个时间点,T0开始订阅,T1是做初始化,T2是进行增量merge(第一次merge)
前言
之前探讨的,整理一下简单的思路
mysql -> hive 进行同步。
主要的问题点在于,订阅增量 以及初始化,之间是有时间间隔的。
怎么做才能保证数据的准确性
前提:都是通过canal 读取binlog。
canal进行抽数。弄到kafka 然后flink进行消费。
解决方案
方案1. 可以使用flink cdc进行消费
https://blog.csdn.net/u011532105/article/details/109644444
作者:收数佬
大概就是这么个新东西,在1.11之后才出现的。不过没有仔细调研,后面可以读读看。
-
mysql开启binlog
-
canal同步binlog数据写入到kafka
-
flink读取kakfa中的binlog数据进行相关的业务处理。
Apache Flink CDC可以直接从数据库获取到binlog供下游进行业务计算分析。简单来说链路会变成这样
这个还是很酷的,相当于直接处理binlog,不再通过canal与kafka进行同步,而flink直接进行处理mysql的数据。节省了canal与kafka的过程。
出问题的情况就会变少。
Flink 1.11中实现了mysql-cdc与postgre-CDC,也就是说在Flink 1.11中我们可以直接通过Flink来直接消费mysql,postgresql的数据进行业务的处理。
使用场景
数据库数据的增量同步
数据库表之上的物理化视图
维表join
其他业务处理
但是我觉得还是会有一些坑的,比如长事务问题,直接读取binlog,那么处理语义上面怎么去区分 insert 和update等等 还有dml。
是否足够成熟什么的
方案2:三个时间点,T0开始订阅,T1是做初始化,T2是进行增量merge(第一次merge)
我们的做法,先进行数据初始化。
三个时间点:
T0 T1 T2
T0开始订阅,T1是做初始化,T2是进行增量merge(第一次merge)
所以其实是冗余,多订阅了一部分数据,那么进行数据merge也不会有什么问题。
关于binlog怎么看:
我们可以show master status 可以知道binlog的文件名,
然后知道对应的点位,
mysql 其实也会把binlog 弄到OSS上面。
(我们mysql的binlog会同步到oss上面,但是本地文件是放了几个小时,根据文件大小不同,放得时间也不一样,所以找数据是可以找到的)