文章目录
- Flink
- [Flink CDC](#Flink CDC)
- 关于转换算子的解释(Transformation)
- [Flink CDC 与 Debezium 有何关系](#Flink CDC 与 Debezium 有何关系)
- [Savepoint 和 Checkpointing](#Savepoint 和 Checkpointing)
- [Savepoint 和 Checkpointing 的区别 ![请添加图片描述](https://i-blog.csdnimg.cn/direct/8834c721df794978bde12e4e764ed946.png)](#Savepoint 和 Checkpointing 的区别 )
Flink
Flink是一个无边界 流式计算引擎。Flink一共有4中API
-
SQL(目前主流都使用这种的,高级用法,不需要上传任何代码,只需要写SQL就好了)
-
Table API【目前公司使用的API(比较低级)】
-
DataSteam/DataSet API【自己写算子】
-
StatefulSteam Processing 【最低版本得,(针对实时性较高得数据计算)】
Flink CDC
是一个基于流的数据集成工具,旨在为用户提供一套功能更加全面的编程接口(API)。
该工具使得用户能够以 YAML 配置文件的形式,优雅地定义其 ETL(Extract, Transform, Load)流程,
并协助用户自动化生成定制化的 Flink 算子并且提交 Flink 作业。 Flink CDC 在任务提交过程中进行了优化,
并且增加了一些高级特性,
如表结构变更自动同步(Schema Evolution)、
数据转换(Data Transformation)、
整库同步(Full Database Synchronization)
以及 精确一次(Exactly-once)语义。
二者关系承上启下,通俗来讲 Flink是计算引擎 CDC 可以理解为是一个"数据连接器"【先统一数据格式,使得Flick可以接受不同类型的数据库的数据】
开源的CDC技术方案对比(只梳理了目前中小型公司常用)
支持功能/产品 | FlinkCDC | Debezuim | DataX | Canal |
---|---|---|---|---|
CDC机制 | 基于日志 | 基于日志 | 主动查询 | 基于日志 |
是否支持增量 | 支持 | 支持 | 不支持 | 支持 |
是否支持全量 | 支持 | 支持 | 支持 | 支持 |
是否分布式 | 是 | 否 | 否 | 否 |
我公司使用FlickCDC是最优选择,而且社区相比Canal相比长期更加活跃。
关于转换算子的解释(Transformation)
一个的大数据处理的工具肯定会有自己的Transformation,可以理解为每个大数据处理的一个通用的处理逻辑,类似于Hadop的MapReduce... (可以理解为JDK8 Stream 中的一些API)
Flink CDC 与 Debezium 有何关系
1、Flink CDC:Flink CDC 是 Apache Flink 生态系统中的一部分,旨在通过 Flink 连接器实现对数据库中变更数据的捕获。Flink CDC 使得用户可以将数据库中的变更数据作为 Flink 流处理应用程序的输入,从而实现实时数据处理。
2、Debezium:Debezium 是一个独立的开源项目,专注于提供 Change Data Capture(CDC)的解决方案。Debezium 支持多种数据库,包括 MySQL、PostgreSQL、MongoDB 等。它通过连接到数据库的事务日志,实时捕获数据库中的变更,然后将这些变更事件发送到消息队列(如 Apache Kafka)中。
3、Flink CDC 与 Debezium 关系:Flink CDC 可以与 Debezium 集成,将 Debezium 发送到 Kafka 中的变更事件作为 Flink 应用程序的输入。这种集成使得用户可以利用 Debezium 提供的数据库变更捕获能力,并通过 Flink 进行更复杂的实时数据处理。
4、Debezium Connector for Flink:Debezium 还提供了一个特殊的连接器,称为 Debezium Connector for Flink,它允许直接将 Debezium 捕获到的变更事件发送到 Flink 中。这样,用户可以直接从 Flink 中处理 Debezium 产生的 CDC 数据,而不需要经过 Kafka。
总体而言,Flink CDC 和 Debezium 在数据变更捕获方面有一些重叠,但它们的关系是可以互相配合使用的。使用 Debezium 可以提供丰富的数据库支持和 CDC 功能,而使用 Flink 则可以进行更灵活和复杂的流处理
2024年9月11日 1.20.0的版本已经支持了很多的的格式【不仅仅是Debezium】
由于使用了FlikCDC 使用了 Debezium 作为连接MYSQL,然后在查看了Debezium 对于SQL 的conntctor的解释:
说明FlikCDC也是伪装成了MySQL得一个从节点,定时读取二进制binlog文件机械能数据变更以及推送。只不过Debezium铜通过Kafaka得Topic类型进行推送变更消息。
FlickCDC官方文档 中支持可以通过MySQL的配置文件来指定全量同步后进行增量同步,还是全量同步还是指定时间后的binlog文件。
下面翻译了上面不同状态的含义:
- initial (默认):在第一次启动时对受监视的数据库表执行全量同步,并继续读取最新的
binlog【也就意味着如果你在初次启动的时候,不指定checkpoint,将重新全量同步】 - earliest-offset:跳过快照阶段,从可读取的最早 binlog 位点开始读取
- latest-offset:首次启动时,从不对受监视的数据库表执行快照, 连接器仅从 binlog
的结尾处开始读取,这意味着连接器只能读取在连接器启动之后的数据更改。 - specific-offset:跳过快照阶段,从指定的 binlog 位点开始读取。位点可通过 binlog 文件名和位置指定,或者在
GTID 在集群上启用时通过 GTID 集合指定。 - timestamp:跳过快照阶段,从指定的时间戳开始读取 binlog 事件
Savepoint 和 Checkpointing
Checkpointing:
-
Checkpointing 是 Flink 的自动机制,用于定期对流处理作业的状态进行快照,并将这些快照存储到配置的持久化存储中。
Checkpointing 确保了作业在发生故障时可以从最近的检查点恢复,保证数据的一致性和作业的容错性。
Checkpoint 的频率和行为(如精确一次或至少一次处理语义)可以在作业配置中设置。
Savepoint:
-
Savepoint 是 Flink 作业的手动快照,通常在作业停止时由用户触发,或者可以通过配置自动定期创建。
Savepoint 可以用于作业的升级、迁移或恢复到特定状态,因为它们包含了作业的完整状态和配置信息。
Savepoint 是检查点的一种,但通常用于管理目的,而不是实时故障恢复。
文档的意思就是,会有一个所谓算子ID的概念,这个东西是实现SavePoint的核心逻辑,
这个东西和前面的算子(Transformation)是一个东西,当你使用的是一些较高的API的时候,Flink就会随机生成【笔者猜测可能是一个基于Flick分布式节点计算的出的一个值】算子的 ID 通常是内部由 Flink 的作业调度器自动生成和管理的。
这是因为 Flink 的设计理念是让用户专注于逻辑层面的数据处理,而不需要关心底层的执行细节。
给出"highly recommended" (强烈建议 🤣)按照规则分配"算子id",如果不按照规则来 ,可能会导致未来的版本你所生产的算子id不支持Flink的SavePoint【例如下面】(如何修改自行百度吧 ,这个东西一般不会动)
go
Operator ID | State
------------+------------------------
source-id | State of StatefulSource
mapper-id | State of StatefulMapper
Savepoint 和 Checkpointing 的区别
通过文档和上面的大致功能,savePoints和checkpoint的和文档中的解释,最大区别似乎就是这个
- savePoints【用户触发】
- checkpoint【Flink触发】
还有一个需要注意的,如果出发了checkpoint 会自动删除,但是savepoint 不会自动删除,除非用户制定了savenpoint的删除时机,还是用户在Flink是第一公民。