Kafka Connect JDBC 与 Debezium CDC
Ofe*_*Hod 24 sql jdbc cdc apache-kafka-connect debezium
JDBC 连接器和Debezium SQL Server CDC 连接器有什么区别（或任何其他关系数据库连接器）我应该什么时候选择一个而不是另一个，寻找在两个关系数据库之间同步的解决方案？
不确定这个讨论是否应该是关于 CDC 与 JDBC 连接器，而不是 Debezium SQL Server CDC 连接器，甚至只是 Debezium，期待以后的编辑，取决于给定的答案（虽然我的情况是关于 SQL Server 接收器）。
与您分享我对这个主题的研究，这让我想到了这个问题（作为答案）
Ofe*_*Hod 62
本说明重点介绍Debezium SQL Server CDC Connector和JDBC Connector之间的区别，并对Debezium和CDC 进行了更一般的解释。
tl; dr-向下滚动:)
德比西姆
Debezium 仅用作源连接器，记录所有行级更改。
Debezium 文档说：
Debezium 是一组分布式服务，用于捕获数据库中的更改，以便您的应用程序可以查看这些更改并对其做出响应。Debezium 在更改事件流中记录每个数据库表中的所有行级更改，应用程序只需读取这些流以查看更改事件发生的相同顺序。
Debezium Connector for SQL Server 首先记录数据库的快照，然后将行级更改的记录发送到 Kafka，每个表发送到不同的 Kafka 主题。
用于 SQL Server 文档的 Debezium 连接器说：
Debezium 的 SQL Server 连接器可以监视和记录 SQL Server 数据库架构中的行级更改。
第一次连接到 SQL Server 数据库/集群时，它读取所有架构的一致快照。当该快照完成时，连接器不断地将提交到 SQL Server 的更改流式传输并生成相应的插入、更新和删除事件。每个表的所有事件都记录在单独的 Kafka 主题中，应用程序和服务可以轻松使用它们。
卡夫卡连接JDBC
Kafka Connect JDBC 可以用作 Kafka 的源连接器或接收器连接器，支持任何带有 JDBC 驱动程序的数据库。
JDBC 连接器文档说：
您可以使用 Kafka Connect JDBC 源连接器将数据从任何带有 JDBC 驱动程序的关系数据库导入到 Apache Kafka® 主题中。您可以使用 JDBC 接收器连接器将数据从 Kafka 主题导出到任何带有 JDBC 驱动程序的关系数据库。JDBC 连接器支持多种数据库，而无需为每个数据库定制代码。
他们有一些关于在 Microsoft SQL Server 上安装的规范，我发现这些规范与本次讨论无关。
所以如果JDBC Connector同时支持source和sink，而Debezium只支持source（不支持sink），我们理解为了从Kafka写数据到有JDBC驱动（sink）的数据库，JDBC Connector是必经之路（包括SQL服务器）。
现在应该将比较范围缩小到源字段。
JDBC Source Connector Documentation乍一看并没有多说：
通过定期执行 SQL 查询并为结果集中的每一行创建输出记录来加载数据。默认情况下，数据库中的所有表都被复制，每个表都复制到自己的输出主题。数据库被监视新的或删除的表并自动适应。从表中复制数据时，连接器可以通过指定应使用哪些列来检测新的或修改的数据来仅加载新的或修改的行。
进一步搜索以了解它们的差异，在这个使用 Debezium MySQL Connector 作为源和 JDBC Connector 作为接收器的Debezium 博客中，有关于两者之间差异的解释，这通常告诉我们Debezium 提供记录有关数据库更改的更多信息，而 JDBC 连接器提供的记录更侧重于将数据库更改转换为简单的插入/更新命令：
Debezium MySQL 连接器旨在专门捕获数据库更改并提供有关这些事件的尽可能多的信息，而不仅仅是每一行的新状态。同时，Confluent JDBC Sink Connector 旨在根据消息的结构将每个消息简单地转换为数据库插入/更新插入。因此，这两个连接器具有不同的消息结构，但它们也使用不同的主题命名约定和表示已删除记录的行为。
而且，它们有不同的主题命名和不同的删除方法：
Debezium 对代表它管理的每个表的目标主题使用完全限定的命名。命名遵循模式 [logical-name].[database-name].[table-name]。Kafka Connect JDBC 连接器使用简单的名称 [table-name]。
...
当 Debezium 连接器检测到一行被删除时，它会创建两个事件消息：删除事件和逻辑删除消息。删除消息有一个信封，前字段中包含已删除行的状态，后字段为空。墓碑消息包含与删除消息相同的键，但整个消息值为空，Kafka 的日志压缩利用这一点来知道它可以删除任何具有相同键的早期消息。许多接收器连接器，包括 Confluent 的 JDBC 接收器连接器，并不期待这些消息，如果它们看到任何一种消息，就会失败。
这个Confluent 博客更详细地解释了 CDC 和 JDBC 连接器的工作原理，它（JDBC 连接器）每隔固定时间间隔执行对源数据库的查询，这不是一个非常可扩展的解决方案，而 CDC 具有更高的频率，从数据库事务日志流式传输：
连接器的工作方式是通过 JDBC 对源数据库执行查询。它这样做是为了拉入所有行（批量）或自之前更改的行（增量）。此查询以 poll.interval.ms 中定义的时间间隔执行。根据所涉及的数据量、物理数据库设计（索引等）以及数据库上的其他工作负载，这可能不是最具可扩展性的选项。
...
如果做得好，CDC 基本上可以让您将每个事件从数据库流式传输到 Kafka。广义上讲，关系数据库使用事务日志（也称为 binlog 或重做日志，具体取决于 DB 风格），数据库中的每个事件都写入其中。更新一行、插入一行、删除一行——所有这些都进入数据库的事务日志。CDC 工具通常通过利用此事务日志以极低的延迟和低影响提取发生在数据库（或其中的架构/表）上的事件。
这篇博文也说明了CDC和JDBC Connector的区别，主要是JDBC Connector不支持同步删除记录，适合做原型，CDC适合更成熟的系统：
JDBC 连接器无法获取已删除的行。因为，您如何查询不存在的数据？
...
我对 CDC 与 JDBC 的一般指导是 JDBC 非常适合原型设计和精细的低容量工作负载。使用 JDBC 连接器时要考虑的事项：
不提供真正的 CDC（捕获删除记录，需要记录版本之前/之后）检测新事件的延迟持续轮询源数据库的影响（并与所需的延迟进行平衡）除非您从表中进行批量拉取，您需要有可用于发现新记录的 ID 和/或时间戳。如果您不拥有架构，这将成为一个问题。
tl;博士结论
Debezium 和 JDBC 连接器之间的主要区别是：
- Debezium 仅用作 Kafka 源，而 JDBC Connector 可用作 Kafka 源和接收器。
对于来源：
- JDBC Connector 不支持同步已删除的记录，而 Debezium 支持。
- JDBC Connector 每隔固定的时间间隔查询数据库，这不是一个可扩展的解决方案，而 CDC 的频率更高，从数据库事务日志中流式传输。
- Debezium 提供有关数据库更改的更多信息的记录，而 JDBC 连接器提供的记录更侧重于将数据库更改转换为简单的插入/更新插入命令。
- 不同的主题命名。
- 注意：您可能希望将其标记为社区 wiki 帖子。 (6认同)