【Flink& Flick CDC】学习笔记

---

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技术方案对比（只梳理了目前中小型公司常用）

我公司使用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【例如下面】（如何修改自行百度吧 ，这个东西一般不会动）

Operator ID | State
------------+------------------------
source-id   | State of StatefulSource
mapper-id   | State of StatefulMapper

Savepoint 和 Checkpointing 的区别

通过文档和上面的大致功能，savePoints和checkpoint的和文档中的解释，最大区别似乎就是这个

• savePoints【用户触发】
• checkpoint【Flink触发】

还有一个需要注意的，如果出发了checkpoint 会自动删除，但是savepoint 不会自动删除，除非用户制定了savenpoint的删除时机，还是用户在Flink是第一公民。