Debezium 博客
Debezium 从项目一开始就提供了一种直接在 Debezium 内部运行连接器的方式。提供这种功能的方式随着时间的推移而改变，并且仍在不断发展。本文将描述在这方面又一次的演进——Debezium 引擎的新实现。
在上一篇博文中，我们展示了如何利用 Debezium 使用数据库中的现有数据训练神经网络模型，并使用这个预训练模型对新存储到数据库中的图像进行分类。在这篇博文中，我们将更进一步——我们将使用 Debezium 从数据库创建多个数据流，并使用其中一个流进行持续学习和改进我们的模型，而第二个流用于对数据进行预测。当模型不断得到改进或根据最近的数据样本进行调整时，这种方法被称为在线机器学习。在线学习只适用于某些用例，实现给定算法的在线变体可能具有挑战性，甚至不可能。然而，在在线学习可行的情况下，它会成为一个非常强大的工具，因为它允许人们实时响应数据变化，并避免了重新训练和重新部署新模型的需要，从而节省了硬件和运营成本。随着数据流变得越来越普遍，例如随着物联网的出现，我们可以预期在线学习将变得越来越流行。它通常非常适合分析用例中的流式数据。
随着 ChatGPT 的最新成功，我们可以看到人工智能领域和机器学习的兴趣再次高涨。该领域上一波兴趣的产生，至少在一定程度上是由于像TensorFlow、PyTorch这样的优秀机器学习框架，或者像Spark这样的通用数据处理框架的出现，使得编写机器学习模型变得更加简单。从那时起，这些框架已经成熟，编写模型变得更加容易，正如您将在本文后面看到的。然而，数据集的准备和从各种来源收集数据有时会花费时间和精力。创建一个完整的管道，能够提取现有或新创建的数据，对其进行调整，并将其摄取到选定的机器学习库中，这可能具有挑战性。让我们探讨一下 Debezium 是否能帮助完成这项任务，并了解如何利用 Debezium 的功能使其更容易。
本文是三部分系列文章的一部分，旨在探讨如何使用 Debezium 和 Oracle LogMiner 从 Oracle 数据库摄取变更。如果您错过了第一部分，可以在 这里 查看。
在第二部分中，我们将基于第一部分的内容，使用 Zookeeper、Kafka 和 Kafka Connect 部署 Oracle 连接器。我们将讨论连接器的各种配置选项以及它们的重要性。最后，我们将实际演示连接器如何工作！
本文是三部分系列文章的一部分，旨在探讨如何使用 Debezium 和 Oracle LogMiner 从 Oracle 数据库摄取变更。在本系列文章中，我们将探讨设置 Debezium for Oracle 的概念验证 (POC) 部署的所有步骤。我们将讨论设置和配置，以及多租户的细微之处。我们还将深入探讨您可能需要了解的任何已知陷阱和注意事项，以及如何调试特定问题。最后，我们将讨论性能和监控，以维护健康的连接器部署。
通过本次演练，我们希望向您展示部署 Debezium for Oracle 的简单性。本系列的安装和设置部分可能看起来相当复杂，但其中许多步骤可能已经在现有的环境中存在。我们将逐一介绍每个步骤，解释如果您使用容器镜像部署，每个步骤的必要性。
Apache Kafka 2.8 让我们得以一窥这个广泛使用的事件流平台的无 ZooKeeper 的未来：它附带了KIP-500（“用自管理的元数据仲裁器替换 ZooKeeper”）的预览版，您现在可以运行 Kafka 集群，而无需设置和操作 Apache ZooKeeper。这不仅从操作角度简化了 Kafka 的运行，新的元数据仲裁器实现（命名为“KRaft”，Kafka Raft 元数据模式）还应该提供更好的扩展性，例如在处理大量主题和分区时。
Kafka Streams 是一个用于开发基于 Apache Kafka 的流处理应用程序的库。引用其文档，“Kafka Streams 应用程序通过拓扑实时处理记录流，以逐条记录的方式持续、并发地处理数据”。Kafka Streams DSL 提供了一系列流处理操作，例如 map、filter、join 和 aggregate。
Kafka Streams 中的非键连接
Debezium 的 CDC 源连接器可以轻松地捕获数据库中的数据变更，并近乎实时地将其推送到 Elasticsearch 等接收系统。默认情况下，这会在源数据库的表、相应的 Kafka 主题以及接收端的数据表示（例如 Elasticsearch 中的搜索索引）之间产生一对一的关系。
在 1:n 关系的情况下，例如客户表和地址表之间，消费者通常对一种数据视图感兴趣，该视图是单个、嵌套的数据结构，例如表示客户及其所有地址的单个 Elasticsearch 文档。
这就是 KIP-213（“Kafka 改进提案”）及其外键连接能力的作用所在：它是在 Apache Kafka 2.4 中引入的，“以弥合 Streams 中的 KTables 与关系数据库中的表之间的语义差距”。在 KIP-213 之前，为了连接两个 Debezium 变更事件主题的消息，您通常需要手动重新键入至少一个主题，以确保连接的双方使用相同的键。
得益于 KIP-213，这不再需要了，因为它允许在从 Kafka 消息值中提取的字段上连接两个 Kafka 主题，以完全透明的方式自动处理所需的重新键入。与之前的方法相比，这大大减少了从 Debezium 的 CDC 事件创建聚合事件的工作量。
Outbox，就像我电子邮件客户端中的那个文件夹一样？不，不完全是，但有一些相似之处！
Outbox 这个术语描述了一种模式，它允许独立组件或服务执行读取您自己的写入语义，同时在组件或服务边界之间提供对这些写入的可靠、最终一致的视图。
您可以在我们的博客文章《使用 Outbox 模式实现可靠的微服务数据交换》中阅读有关 Outbox 模式及其在微服务中的应用的更多信息。
那么，Outbox 事件路由器到底是什么？
作为近期 使用变更数据捕获和流处理构建审计日志 博客文章的后续，我们希望通过管理功能扩展此示例，使其能够捕获和修复任何缺失的事务数据。
在上述博客文章中，有一个日志增强服务，用于将“Vegetable”数据库表中插入或更新的数据与事务上下文数据（例如
-
事务 ID
-
执行操作的用户名
-
实际更改背后的用例，例如“创建蔬菜”
只要所有更改都通过蔬菜服务进行，这一切都能很好地工作。但情况总是如此吗？
那么维护活动或直接在数据库级别执行的迁移脚本呢？仍然存在大量此类活动，无论是故意的，还是因为这是我们正在努力改变的老习惯……
让我们谈谈 TOAST。吐司？不，TOAST！
那是什么？TOAST (The Oversized-Attribute Storage Technique，超大属性存储技术) 是 Postgres 中的一种机制，它将大型列值存储在多个物理行中，从而绕过了 8 KB 的页面大小限制。
通常，TOAST 存储对用户是透明的，所以您真的不必关心它。但是有一个例外：如果表行已更改，则使用 TOAST 机制存储的任何*未更改*值都不会包含在 Debezium 从数据库收到的消息中，除非它们是表复制身份的一部分。因此，这种未更改的 TOAST 列值将不会包含在发送到 Apache Kafka 的 Debezium 数据变更事件中。在本文中，我们将讨论处理这种情况的不同策略。
业务应用程序通常需要维护某种形式的审计日志，即应用程序数据所有更改的持久化跟踪。如果仔细看，带有 Debezium 数据更改事件的 Kafka 主题与之非常相似：它源自数据库事务日志，描述了应用程序记录的所有更改。所缺少的只是一些元数据：数据为何、何时以及由谁更改？在本博文中，我们将探讨如何通过变更数据捕获 (CDC) 提供和公开这些元数据，以及如何使用流处理来丰富实际的数据更改事件以包含此类元数据。
这是 Apache Pulsar PMC 成员兼 Comitter 翟嘉（Jia Zhai）的客座博文。
Debezium 是一个开源的变更数据捕获（CDC）项目。它基于 Apache Kafka Connect 构建，并支持多种数据库，如 MySQL、MongoDB、PostgreSQL、Oracle 和 SQL Server。 Apache Pulsar 包含一套基于 Pulsar IO 框架的 内置连接器，它与 Apache Kafka Connect 是对应的。
从 2.3.0 版本开始，Pulsar IO 开箱即用地支持 Debezium 源连接器，因此您可以利用 Debezium 将数据库中的变更流式传输到 Apache Pulsar。本教程将引导您完成 Debezium MySQL 连接器与 Pulsar IO 的设置。
作为其业务逻辑的一部分，微服务通常不仅需要更新自己的本地数据存储，还需要通知其他服务有关发生的数据更改。Outbox 模式描述了一种安全一致地执行这两项任务的方法；它为源服务提供即时的“读你自己的写”语义，同时提供跨服务边界的可靠的、最终一致的数据交换。
Hibernate ORM / JPA 的二级缓存是一种经过验证且高效的提高应用程序性能的方法：缓存只读或很少修改的实体可避免数据库往返，从而提高应用程序的响应时间。
与一级缓存不同，二级缓存与会话工厂（或 JPA 中的实体管理器工厂）相关联，因此其内容在事务和并发会话之间共享。理所当然，如果缓存的实体被修改，相应的缓存条目也必须被更新（或从缓存中清除）。只要数据更改是通过 Hibernate ORM 完成的，就无需担心：ORM 会自动更新缓存。
然而，当绕过应用程序（例如，直接修改数据库中的记录）时，事情就会变得棘手。此时，Hibernate ORM 无法知道缓存的数据已过时，因此有必要显式使受影响的条目失效。一种常见的做法是提供一些管理员功能，允许清除应用程序的缓存。为了使其正常工作，切勿忘记调用该失效功能至关重要，否则应用程序将继续使用过时缓存的数据。
在下文中，我们将探讨一种缓存失效的替代方法，该方法可以可靠且完全自动化地工作：通过利用 Debezium 及其变更数据捕获（CDC）功能，您可以直接在数据库中跟踪数据更改并对已应用的任何更改做出反应。这允许近实时地使受影响的缓存条目失效，而不会因遗漏更改而导致过时数据的风险。如果某个条目已从缓存中移除，Hibernate ORM 将在下次请求时从数据库加载该实体的最新版本。
在数据更改后更新外部全文搜索索引（例如 Elasticsearch）是变更数据捕获 (CDC) 非常流行的用例。
正如我们在一段时间前的 博客文章 中讨论过的，Debezium 的 CDC 源连接器与 Confluent 的 Elasticsearch 接收器连接器 的结合，可以轻松地在 MySQL、Postgres 等数据库中捕获数据更改，并近乎实时地将它们推送到 Elasticsearch。这导致源数据库中的表与 Elasticsearch 中的相应搜索索引之间存在 1:1 的关系，对于许多用例来说是完全可以的。
但是，如果您想将整个聚合数据放入单个索引中，情况会更具挑战性。例如，一个客户及其所有地址；这些通常存储在关系型数据库的两个单独的表中，通过外键连接，而您只想在 Elasticsearch 中有一个索引，其中包含具有嵌入式地址的客户文档，从而允许您根据地址高效地搜索客户。
继我们最近讨论的 基于 KStreams 的解决方案 之后，我们想在本文中介绍一个通过应用程序层驱动物化此类聚合视图的替代方案。
大多数情况下，Debezium 用于将数据更改流式传输到 Apache Kafka。但如果您使用的是其他流式传输平台，例如 Apache Pulsar，或者云原生解决方案，例如 Amazon Kinesis、Azure Event Hubs 等等呢？您仍然可以受益于 Debezium 强大的变更数据捕获 (CDC) 功能，并从 MySQL、Postgres、SQL Server 等数据库中摄取更改吗？
事实证明，只需一点粘合代码，就可以做到！接下来，我们将讨论如何使用 Debezium 捕获 MySQL 数据库中的更改，并将更改事件流式传输到 Kinesis，这是一个在 Amazon 云中提供的完全托管的数据流服务。
