Kafka Connect JDBC 与 Debezium CDC

Posted 2023-03-23

【中文标题】Kafka Connect JDBC 与 Debezium CDC

【英文标题】：Kafka Connect JDBC vs Debezium CDC

【发布时间】：2020-07-09 13:02:32

【问题描述】：

JDBC Connector 和 Debezium SQL Server CDC Connector（或任何其他关系数据库连接器）之间有什么区别？我什么时候应该选择一个而不是另一个，寻找在两个关系数据库之间同步的解决方案？

不确定这个讨论是否应该是关于 CDC 与 JDBC 连接器，而不是 Debezium SQL Server CDC 连接器，甚至只是 Debezium，期待稍后的编辑，取决于给定的答案（虽然我的案例是关于 SQL Server sink） .

与您分享我对这个主题的研究，这让我想到了这个问题（作为答案）

【参考方案1】：

此解释侧重于Debezium SQL Server CDC Connector 和JDBC Connector 之间的区别，对Debezium 和CDC 进行更一般的解释。

tl;dr- 向下滚动 :)

---

地贝齐姆

Debezium 仅用作源连接器，记录所有行级更改。Debezium Documentation 说：

Debezium 是一组分布式服务，用于捕获您的 数据库，以便您的应用程序可以看到这些更改并做出响应 给他们。 Debezium 记录每个数据库中的所有行级更改 更改事件流中的表，应用程序只需读取这些 流以与它们相同的顺序查看更改事件 发生了。

Debezium Connector for SQL Server 首先记录数据库的快照，然后将行级更改记录发送到 Kafka，每个表到不同的 Kafka 主题。Debezium Connector for SQL Server Documentation 说：

Debezium 的 SQL Server 连接器可以监控和记录行级 SQL Server 数据库架构的变化。

第一次连接到 SQL Server 数据库/集群时，它读取 所有模式的一致快照。当该快照是 完成后，连接器不断流式传输之前的更改 提交到 SQL Server 并生成相应的插入、更新和 删除事件。每个表的所有事件都记录在一个 单独的 Kafka 主题，它们可以很容易地被 应用程序和服务。

---

Kafka 连接 JDBC

Kafka Connect JDBC 可以用作 Kafka 的源连接器或接收器连接器，支持任何带有 JDBC 驱动程序的数据库。JDBC Connector Documentation 说：

您可以使用 Kafka Connect JDBC 源连接器来导入数据 从任何具有 JDBC 驱动程序的关系数据库到 Apache Kafka® 话题。您可以使用 JDBC 接收器连接器从 Kafka 导出数据 任何带有 JDBC 驱动程序的关系数据库的主题。 JDBC 连接器支持多种数据库，无需 每个人的自定义代码。

他们有一些specifications about installing on Microsoft SQL Server，我认为与本次讨论无关。

因此，如果 JDBC 连接器同时支持源和接收器，而 Debezium 仅支持源（而不是接收器），我们理解为了将数据从 Kafka 写入具有 JDBC 驱动程序（接收器）的数据库，JDBC 连接器是要走的路（包括 SQL Server）。

现在应该只将比较范围缩小到源字段。JDBC Source Connector Documentation 乍一看并没有多说：

通过定期执行 SQL 查询并创建一个 结果集中每一行的输出记录。默认情况下，所有表 在一个数据库中被复制，每个到它自己的输出主题。数据库 监视新表或已删除表并自动适应。什么时候 从表中复制数据，连接器只能加载新的或修改的 通过指定应该使用哪些列来检测新的或 修改数据。

---

进一步搜索以了解它们的差异，在这个使用 Debezium mysql 连接器作为源和 JDBC 连接器作为接收器的Debezium blog 中，有一个关于两者之间差异的解释，它通常告诉我们Debezium 提供有关数据库更改的更多信息的记录，而 JDBC Connector 提供更专注于将数据库更改转换为简单的插入/更新命令的记录：

Debezium MySQL 连接器旨在专门捕获 数据库更改并提供尽可能多的信息 这些事件不仅仅是每一行的新状态。同时， Confluent JDBC Sink 连接器旨在简单地将每个 根据结构将消息插入/更新插入数据库 信息。因此，这两个连接器具有不同的结构 消息，但它们也使用不同的主题命名约定和 表示已删除记录的行为。

而且，它们有不同的主题命名和不同的删除方法：

Debezium 使用完全限定的命名来表示目标主题 它管理的每个表。命名遵循模式 [逻辑名].[数据库名].[表名]。卡夫卡连接 JDBC 连接器适用于简单名称 [table-name]。

...

当 Debezium 连接器检测到一行被删除时，它会创建两个 事件消息：删除事件和墓碑消息。删除 邮件有一个信封，其中包含已删除行的状态 before 字段和一个为 null 的 after 字段。墓碑消息 包含与删除消息相同的键，但包含整个消息值 为 null，Kafka 的日志压缩利用这个来知道它可以 删除任何具有相同密钥的早期消息。多个水槽 连接器，包括 Confluent 的 JDBC Sink 连接器，不是 期待这些消息，如果他们看到任何一种都会失败 的消息。

这个Confluent blog 详细解释了 CDC 和 JDBC 连接器的工作原理，它（JDBC 连接器）每隔固定的时间间隔对源数据库执行查询，这不是非常可扩展的解决方案，而 CDC 的频率更高，从数据库事务日志：

连接器的工作原理是通过 JDBC 对 源数据库。它这样做是为了拉入所有行（批量）或那些 与以前相比发生了变化（增量）。该查询在 在 poll.interval.ms 中定义的时间间隔。根据数据量 涉及的物理数据库设计（索引等）和其他 数据库上的工作负载，这可能不是最可扩展的 选项。

...

如果做得好，CDC 基本上可以让您流式传输每个事件 从数据库到 Kafka。广义地说，关系数据库使用 事务日志（也称为 binlog 或 redo log，具体取决于 DB 风味），数据库中的每个事件都写入其中。更新一个 行，插入一行，删除一行——这一切都进入数据库的 事务日志。 CDC 工具通常利用这个来工作 以非常低的延迟和低影响提取事务日志 数据库（或其中的模式/表）上发生的事件 它）。

这篇博文还说明了CDC和JDBC Connector的区别，主要是说JDBC Connector不支持同步删除的记录因此适合原型设计，CDC适合更成熟的系统：

JDBC 连接器无法获取已删除的行。因为，你怎么 查询不存在的数据？

...

我对 CDC 与 JDBC 的总体看法是 JDBC 非常适合原型设计， 和精细的低容量工作负载。使用 JDBC 时要考虑的事项 连接器：

不提供真正的 CDC（捕获删除记录，需要之前/之后 记录版本）检测新事件的延迟 轮询的影响 源数据库不断（并与所需的平衡 延迟）除非您从表中进行批量拉取，否则您需要 具有可用于发现新记录的 ID 和/或时间戳。如果 您不拥有架构，这将成为一个问题。

---

tl;dr 结论

Debezium 和 JDBC Connector 的主要区别是：

Debezium 仅用作 Kafka 源，而 JDBC 连接器可用作 Kafka 源和接收器。

来源：

JDBC 连接器不支持同步已删除的记录，而 Debezium 支持。 JDBC 连接器每隔固定时间间隔查询一次数据库，这不是非常可扩展的解决方案，而 CDC 的频率更高，从数据库事务日志中流式传输。 Debezium 提供有关数据库更改的更多信息的记录，而 JDBC 连接器提供的记录更侧重于将数据库更改转换为简单的插入/更新命令。 不同的主题命名。

【讨论】：

注意：您可能希望将此标记为社区 wiki 帖子。

这写得非常好，并且在了解哪些选项更适合您方面非常有用..非常感谢

在 Debezium MSSQL 连接器的上下文中，在决定 JDBC 还是 CDC 时，是否需要考虑最大任务数？ "应该为此连接器创建的最大任务数。SQL Server 连接器始终使用单个任务，因此不使用此值，因此默认值始终可以接受。"

写得好，请注意，JDBC sink 连接器现在允许通过使用 tombstone 记录删除记录。

【参考方案2】：

简单地说，CDC 是一种基于日志的流式传输，类似地 kafka connect jdbc 源连接器是基于查询的流式传输.. :)