Flink实时数仓同步：快照表实战详解

最新推荐文章于 2024-07-22 09:55:00 发布

2401_84182685

最新推荐文章于 2024-07-22 09:55:00 发布

阅读量342

点赞数 4

文章标签： flink 大数据

本文链接：https://blog.csdn.net/2401_84182685/article/details/138235189

版权

5.2.1、前提介绍

首先，由于实时流水表同步使用Flink-cdc读取关系型数据库，flink-cdc提供了四种模式： “initial”，“earliest-offset”，“latest-offset”，“specific-offset” 和 “timestamp”。本文使用的Flink-connector-mysq是2.3版本，这里简单介绍一下这四种模式：
- initial （默认）：在第一次启动时对受监视的数据库表执行初始快照，并继续读取最新的 binlog。
- earliest-offset：跳过快照阶段，从可读取的最早 binlog 位点开始读取
- latest-offset：首次启动时，从不对受监视的数据库表执行快照，连接器仅从 binlog 的结尾处开始读取，这意味着连接器只能读取在连接器启动之后的数据更改。
- specific-offset：跳过快照阶段，从指定的 binlog 位点开始读取。位点可通过 binlog 文件名和位置指定，或者在 GTID 在集群上启用时通过 GTID 集合指定。
- timestamp：跳过快照阶段，从指定的时间戳开始读取 binlog 事件。
这里采用initial模式作为实时同步方式，先全量后增量，此外由于实时流水表同步需要对 binlog 数据进行解析及判断更新操作类型，因此，Flink CDC SQL 方式的表建立不再满足我们的要求。为了更好地实现这一功能，我们需要采用 API 方式来构建解决方案，代码如下：

import org.apache.flink.api.common.eventtime.WatermarkStrategy;
import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;
import com.ververica.cdc.debezium.JsonDebeziumDeserializationSchema;
import com.ververica.cdc.connectors.mysql.source.MySqlSource;

public class MySqlSourceExample {
  public static void main(String[] args) throws Exception {
    MySqlSource<String> mySqlSource = MySqlSource.<String>builder()
        .hostname("yourHostname")
        .port(yourPort)
        .databaseList("yourDatabaseName") // 设置捕获的数据库， 如果需要同步整个数据库，请将 tableList 设置为 ".\*".
        .tableList("yourDatabaseName.yourTableName") // 设置捕获的表
        .username("yourUsername")
        .password("yourPassword")
        .startupOptions(StartupOptions.timestamp(1685548800000L)) // 从2023-06-01零点处读取binlog
        .deserializer(new JsonDebeziumDeserializationSchema()) // 将 SourceRecord 转换为 JSON 字符串
        .build();

    StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();

    // 设置 3s 的 checkpoint 间隔
    env.enableCheckpointing(3000);

    env
      .fromSource(mySqlSource, WatermarkStrategy.noWatermarks(), "MySQL Source")
      // 设置 source 节点的并行度为 4
      .setParallelism(4)
      .print().setParallelism(1); // 设置 sink 节点并行度为 1 

    env.execute("Print MySQL Snapshot + Binlog");
  }
}

代码摘自mysql-cdc-connector官网示例

5.2.2、全量同步阶段

接下来我们将从全量同步开始逐步演示同步过程，这里我们以2023-06-0日的[Mysql]业务数据为例，此时表数据如下：

id	name	phone	gender	create_time	update_time
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00
3	tom	333	男	2023-06-01 13:00:00	2023-06-01 13:00:00

此时Flink应用启动获取到的数据如下：仅展示一条

{
	"before": null,
	"after": {		 # 实际数据
		"id": 1,
		"name": "jack",
		"phone": "111",
		"gender": "男",
		"create\_time": "2023-06-01T05:00:00Z",  # 该日期是UTC时间,只需增加8小时即可转化为北京时间
		"update\_time": "2023-06-01T05:00:00Z"	# 该日期是UTC时间,只需增加8小时即可转化为北京时间
	},
	"source": {		 # 元数据
		"version": "1.6.4.Final",
		"connector": "mysql",
		"name": "mysql\_binlog\_source",
		"ts\_ms": 0,
		"snapshot": "false",
		"db": "yushu\_dds",
		"sequence": null,
		"table": "user",
		"server\_id": 0,
		"gtid": null,
		"file": "",
		"pos": 0,
		"row": 0,
		"thread": null,
		"query": null
	},
	"op": "r",  	 # 记录每条数据的操作类型[重要]
	"ts\_ms": 1705471382867,
	"transaction": null
}

在我们使用 Flink CDC MySQL 同步数据时，默认采用 initial 模式，这意味着首先进行全量同步，然后再进行增量同步。因此，在区分全量和增量同步时，关键在于观察获取到的数据中的 op 字段。op 字段是用来记录每条数据的操作类型的标志。具体的操作类型如下：
- op=d 代表删除操作
- op=u 代表更新操作
- op=c 代表新增操作
- op=r 代表全量读取，而不是来自 binlog 的增量读取
在 Flink 程序中，只需要通过 op=r 即可筛选出全量数据。在全量数据同步阶段只需将op=r的业务数据直接同步至快照表(之所以全量数据同步至快照表是为了次日凌晨与流水表变更数据合并成完整数据)，流水表在全量阶段无需同步，导入语句如下：

INSERT INTO example_user_snapshot (id, dt, name, phone, gender, create_time, update_time)
VALUES
    (1, '2023-06-01', 'jack', 111, '男', '2023-06-01 13:00:00', '2023-06-01 13:00:00'),
    (2, '2023-06-01', 'jason', 222, '男', '2023-06-01 13:00:00', '2023-06-01 13:00:00'),
    (3, '2023-06-01', 'tom', 333, '男', '2023-06-01 13:00:00', '2023-06-01 13:00:00');

此时doris快照表数据如下所示：

id	dt	name	phone	gender	create_time	update_time
1	2023-06-01	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00
2	2023-06-01	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00
3	2023-06-01	tom	333	男	2023-06-01 13:00:00	2023-06-01 13:00:00

此时doris流水表数据如下所示：全量阶段流水表无需同步

id	update_time	dt	create_time	name	phone	gender	op	before	binlog
NULL	NULL	NULL	NULL	NULL	NULL	NULL	NULL	NULL	NULL

5.2.3、增量同步阶段

这里我们以2023-06-02日的[Mysql]业务数据为例，新增了一名tony用户，且更改了tom的手机号，此时表数据如下：

id	name	phone	gender	create_time	update_time
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00
3	tom	444	男	2023-06-01 13:00:00	2023-06-02 09:00:00
4	tony	555	男	2023-06-02 10:00:00	2023-06-02 10:00:00

此时Flink应用获取到的数据如下：

# 新增tony变更数据如下
{
	"before": null,
	"after": {
		"id": 4,
		"name": "tony",
		"phone": "666",
		"gender": "男",
		"create\_time": "2023-06-02T02:00:00Z",
		"update\_time": "2023-06-02T02:00:00Z"
	},
	"source": {
		# 元数据信息忽略
	},
	"op": "c", # 操作类型
	"ts\_ms": 1706768344113,
	"transaction": null
}
# tom手机号333->444变更数据如下
{
	"before": {
		"id": 3,
		"name": "tom",
		"phone": "333",
		"gender": "男",
		"create\_time": "2023-06-01T05:00:00Z",
		"update\_time": "2023-06-01T05:00:00Z"
	},
	"after": {
		"id": 3,
		"name": "tom",
		"phone": "444",
		"gender": "男",
		"create\_time": "2023-06-01T05:00:00Z",
		"update\_time": "2023-06-01T23:00:00Z"
	},
	"source": {
		# 元数据信息忽略
	},
	"op": "u", # 操作类型
	"ts\_ms": 1706768454904,
	"transaction": null
}

当 Flink 同步程序接收到 op=c/u/d 表示增量更新数据时，提取其中的 op、before 和 after 数据。接着将这些信息拼装成 Doris 的 INSERT 语句后插入到流水表中，此时流水表数据如下所示：

id	update_time	dt	create_time	name	phone	gender	op	before	binlog
4	2023-06-02 10:00:00	2023-06-02	2023-06-02 10:00:00	tony	555	男	c	NULL	{“before”:null,“after”:{“id”:4,“name”:“tony”,“phone”:“666”,“gender”:“男”,“create_time”:“2023-06-02T02:00:00Z”,“update_time”:“2023-06-02T02:00:00Z”},“source”:{“version”:“1.6.4.Final”,“connector”:“mysql”,“name”:“mysql_binlog_source”,“ts_ms”:1706768344000,“snapshot”:“false”,“db”:“yushu_dds”,“sequence”:null,“table”:“user”,“server_id”:2307031958,“gtid”:“71221bfd-56e8-11ee-8275-fa163e4ecceb:33719321”,“file”:“3509-binlog.000191”,“pos”:643757739,“row”:0,“thread”:null,“query”:null},“op”:“c”,“ts_ms”:1706768344113,“transaction”:null}
3	2023-06-02 08:00:00	2023-06-02	2023-06-02 13:00:00	tom	444	男	u	{“id”:3,“name”:“tom”,“phone”:“333”,“gender”:“男”,“create_time”:“2023-06-01T05:00:00Z”,“update_time”:“2023-06-01T05:00:00Z”}	{“before”:{“id”:3,“name”:“tom”,“phone”:“333”,“gender”:“男”,“create_time”:“2023-06-01T05:00:00Z”,“update_time”:“2023-06-01T05:00:00Z”},“after”:{“id”:3,“name”:“tom”,“phone”:“444”,“gender”:“男”,“create_time”:“2023-06-01T05:00:00Z”,“update_time”:“2023-06-01T23:00:00Z”},“source”:{“version”:“1.6.4.Final”,“connector”:“mysql”,“name”:“mysql_binlog_source”,“ts_ms”:1706768454000,“snapshot”:“false”,“db”:“yushu_dds”,“sequence”:null,“table”:“user”,“server_id”:2307031958,“gtid”:“71221bfd-56e8-11ee-8275-fa163e4ecceb:33719761”,“file”:“3509-binlog.000191”,“pos”:692873739,“row”:0,“thread”:null,“query”:null},“op”:“u”,“ts_ms”:1706768454904,“transaction”:null}

因增量数据无需同步至快照表，故此时快照表与之前06-01号一样保持不变，快照表数据如下：

id	dt	name	phone	gender	create_time	update_time
1	2023-06-01	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00
2	2023-06-01	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00
3	2023-06-01	tom	333	男	2023-06-01 13:00:00	2023-06-01 13:00:00

5.2.4、合并阶段

在合并阶段，我们将流水表前一天的数据与快照表中前两天的数据进行整合，最终得到前一天的全量数据，并将其写入至快照表的前一天分区。

合并任务会在满足以下任意一个条件时触发：

当binlog数据中的日期为第二天。
当凌晨过了5分钟（这是一个自定义的时间阈值）。

第二个条件的存在是因为业务数据很可能在凌晨00:00 ~ 00:05 分之间没有增量数据。因此，即使在没有业务数据同步的情况下，我们仍然可以通过第二个条件触发合并阶段，确保数据的完整性和准确性。

这里我们假设2023-06-03 00:05:00 触发合并阶段为例，此时业务数据如下所示：

id	name	phone	gender	create_time	update_time
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00
3	tom	444	男	2023-06-01 13:00:00	2023-06-02 09:00:00
4	tony	555	男	2023-06-02 10:00:00	2023-06-02 10:00:00

flink程序中无新增数据，但由于满足第二个触发条件，在flink程序中将会触发合并任务[可用单独线程实现]，此时执行的doris合并语句如下：

INSERT INTO example_user_snapshot (id, dt, name, phone, gender, create_time, update_time)
SELECT
    id,
    '2023-06-02' as dt, -- 通过固定dt字段值从而写入快照表p20230602分区中
    name,
    phone,
    gender,
    create_time,
    update_time
FROM (
         SELECT
             snap.id,
             snap.name,
             snap.phone,
             snap.gender,
             snap.create_time,
             snap.update_time
         FROM example_user_snapshot PARTITION p20230601 snap
    LEFT JOIN example_user_stream PARTITION p20230602 stream ON snap.id = stream.id
         WHERE stream.id IS NULL
         UNION
         SELECT
             id,
             name,
             phone,
             gender,
             create_time,
             update_time
         FROM (
             SELECT
             id,
             name,
             phone,
             gender,
             create_time,
             update_time,
			 -- 使用窗口函数的目的是处理流水表中可能存在多条相同id的记录，例如tom在06-02日更改多次手机号则会有多条相同id的数据，故此窗口函数用于确保选择每个id对应的update\_time最大的记录；如果流水表设计的unique key = (id) 则不会出现重复情况无需此处的窗口函数。
             ROW_NUMBER() OVER (PARTITION BY id ORDER BY update_time DESC) AS row_num 
             FROM example_user_stream PARTITION p20230602
             ) ranked
         WHERE row_num = 1
     ) AS temp;

该 SQL 查询是先获取两表联接中未更新的数据，与已更新的数据合并，最后写入到快照表中，确保了 2023-06-02 分区的数据是完整的全量数据。

若想详细剖析此sql的运算逻辑可参考笔者另一篇文章：数仓日常维护：剖析每日增量同步的内部机制

此时快照表的数据如下：

id	dt	name	phone	gender	create_time	update_time
1	2024-02-02	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00
2	2024-02-02	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00
3	2024-02-02	tom	333	男	2023-06-01 13:00:00	2023-06-01 13:00:00
1	2024-02-03	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00
2	2024-02-03	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00
3	2024-02-03	tom	555	男	2023-06-02 13:00:00	2023-06-02 09:00:00
4	2024-02-03	tony	555	男	2023-06-02 10:00:00	2023-06-02 10:00:00

用户可以通过如下语句查询2023-06-02全量数据：

SELECT \* FROM example_user_snapshot PARTITION p20230602;

1	2024-02-03	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00
2	2024-02-03	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00
3	2024-02-03	tom	555	男	2023-06-02 13:00:00	2023-06-02 09:00:00
4	2024-02-03	tony	555	男	2023-06-02 10:00:00	2023-06-02 10:00:00

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

06-02 10:00:00 | 2023-06-02 10:00:00 |

[外链图片转存中…(img-bW2OH5Ce-1714150961377)]
[外链图片转存中…(img-et73Q1BU-1714150961378)]
[外链图片转存中…(img-03k0yPuG-1714150961378)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

2401_84182685

关注

4
点赞
踩
8

收藏

觉得还不错? 一键收藏
0
评论
Flink实时数仓同步：快照表实战详解

首先，由于实时流水表同步使用Flink-cdc读取关系型数据库，flink-cdc提供了四种模式： “initial”，“earliest-offset”，“latest-offset”，“specific-offset” 和 “timestamp”。initial（默认）：在第一次启动时对受监视的数据库表执行初始快照，并继续读取最新的 binlog。：跳过快照阶段，从可读取的最早 binlog 位点开始读取。
复制链接

扫一扫