本文介绍: sourceConnector.jar,将源数据导入至KafkatopicsinkConnector.jar,将Kafka topic中的数据导入目标源但是Kafka没有提供特别丰富的connector,那么Debezium就出现了。你可以把Debezium简单理解成是CDC技术的一种实现,并提供了很多数据库sourceConnector.jarsinkConnector.jar

背景

平时一些业务场景可能需要我们多个系统之间进行业务同步,典型的场景如下几种

  1. 数据表同步至ElasticSearch提高搜索速度
  2. 一张表的数据需要多个数据库之间进行同步多个数据库可能是同一种数据库,也可能本文中的例子一样,是不同数据库之间进行同步
  3. 在同一个数据库不同的表进行同步例如表A中新增数据时,我们需要在表B中进行一些数据操作

上述3个场景的共同要求基本都是,当数据源有新数据时,我们希望马上同步目标,尽量减少延迟;在同步期间尽量减少对数据源影响

解决方案

场景

对于场景一,我们可以使用解决方案是Logstash的Jdbc插件。该插件的基本原理是,通过SQL和定期查询,获得新数据之后,送到ES中。但这种解决方案存在一定的延时,并且如果没新增数据,频繁查询是没必要的。

如果数据库是MySQL,也可以选择阿里的cannal,这样解决了上述问题。现实情况可能是,我们在用PostgreSQL,所以只能选择Logstash

场景

对于场景二,如果是同一种数据库例如Mysql还是可以选择阿里cannal。 但是对于其他数据库例如是Oracle和PostgreSQL,就没办法了

场景

对于场景三,现有数据库中,无论哪个数据库,我们都可以使用Trigger-触发器实现。但触发器增加了原本的SQL的执行时间,同时增加触发器需要更改对应的表结构。另一种方案是使用代码,在代码中进行处理,但这样增加了复杂度

从目前解决的方案来看,都不是很完美。

CDC-Change Data Capture如何解决上述问题

CDC工作原理

每种数据库都有一个至关重要日志用来记录数据库中所有修改操作

  1. Oracle数据库日志是Redo Log
  2. MySQL数据库日志是Binary Log
  3. PostgreSQL数据库的日志是Write Ahead Log

通过监控这些日志,当源数据库发生改变时,监控该日志的软件识别提取其中的数据变更操作。当数据库中的数据发生插入更新删除时,CDC会捕获记录这些变更操作的详细信息,包括受影响的表、修改前后的值以及执行操作的时间戳等。这些变更数据可以传递给其他系统应用程序以便它们可以根据这些变更进行相应的处理

CDC不需要对源数据库进行更改,并且不会对源数据库造成性能损耗。

Kafka Connect 和 Debezium简单介绍

Kafka Connect需要两个connector

  1. sourceConnector.jar,将源数据导入至Kafka的topic
  2. sinkConnector.jar,将Kafka topic中的数据导入目标

但是Kafka并没有提供特别丰富的connector,那么Debezium就出现了。

你可以把Debezium简单理解成是CDC技术的一种实现,并提供了很多数据库的sourceConnector.jar和sinkConnector.jar

场景二的例子,将Oracle数据库的数据通过CDC方式同步至PostgrSQL中

为了完成此demo,我们需要

  1. 一个节点kafka集群
  2. 安装Oracle数据库和PostgreSQL数据库
  3. debezium
  4. docker环境

dockercompose文件以及如何配置全部在GitHub上,想要自己体验一下的同学,请按照仓库中的步骤一步一步运行即可。如有问题可在本博文留言即可

使用Debezium遇到问题排查思路

核心思路就一条仔细阅读 Debezium官方的Connector文档,特别是每个Connector的第一部分How the connector works

场景一和场景三的实现思路

理解了上述CDC部分,并且如果你能一步一步跟着源码自己动手体验一次。 那么你会很容易知道如何处理场景一和场景三,场景一和场景三无非是使用不同sourceConnector.jar和sinkConnector.jar,那么我们的问题就变成了怎么找这些jar包?

confluent hub搜索即可,提供了大量的jar包,包括Elasticsearch相关sourceConnector、sinkConnector。每个jar包都有对应文档

ETL(Extract, Transform, and Load)和Flink CDC

实际业务场景复杂多样,可能不光光是原封不动的复制数据,特别是有一些复杂报表的场景。我们需要不同数据表的进行同步,并在同步过程中将多个表的数据组织在一起,形成一条有效记录然后导入目标源,上述过程就是ETL

Flink CDC基于Flink的实现方案,我本人并没有使用过它,这里提一下主要是觉得可能对看博文的你做技术决策有些帮助,根据自己的实际情况去选择适合自己技术方案。

写在最后

因为我也是才开始慢慢使用CDC解决部分业务场景,所以目前关于Debezium和Kafka Connect的最佳实践没有特别好的经验分享基于这个原因本篇博文没有太多可供参考的经验,仅仅介绍CDC的思想、提供一些基础示例不同解决方案的思考思路

参考资料

原文地址:https://blog.csdn.net/dghkgjlh/article/details/134751835

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任

如若转载,请注明出处:http://www.7code.cn/show_30158.html

如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱suwngjj01@126.com进行投诉反馈,一经查实,立即删除!

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注