Debezium 博客

Debezium 从项目一开始就提供了一种直接在 Debezium 内部运行连接器的方式。提供这种功能的方式随着时间的推移而改变，并且仍在不断发展。本文将描述在这方面又一次的演进——Debezium 引擎的新实现。

在上一篇博文中，我们展示了如何利用 Debezium 训练数据库中现有数据上的神经网络模型，并使用此预训练模型对新存入数据库的图像进行分类。在这篇博文中，我们将更进一步——我们将使用 Debezium 从数据库创建多个数据流，其中一个流用于持续学习和改进我们的模型，第二个流用于对数据进行预测。当模型不断改进或调整以适应最近的数据样本时，这种方法被称为在线机器学习。在线学习仅适用于某些用例，实现给定算法的在线变体可能具有挑战性，甚至不可能。然而，在在线学习可行的情况下，它将成为一个非常强大的工具，因为它允许我们实时响应数据变化，并避免了重新训练和重新部署新模型的需要，从而节省了硬件和运营成本。随着数据流越来越普遍，例如随着物联网的出现，我们可以预期在线学习将变得越来越受欢迎。它通常非常适合在可行的情况下分析用例中的流式数据。

在 Debezium 的聊天或邮件列表中，时不时会有人问如何确保 Debezium 产生的记录能够精确一次性传递。到目前为止，Debezium 仅支持至少一次传递。这意味着 Debezium 保证每条变更都会被传递，没有任何丢失或跳过的变更事件。然而，在出现故障、重启或数据库连接中断的情况下，同一个事件可能会被传递多次。典型场景是事件被传递两次——一次在故障/重启之前，第二次在之后。精确一次传递（或语义）提供了更强的保证——每条消息都将被传递，同时不会有任何重复，每条消息都将被精确传递一次。到目前为止，我们的回答是，如果用户需要精确一次传递，他们必须实现自己的去重系统。然而，随着 Kafka Connect 对精确一次传递的支持，我们可以为 Debezium 连接器提供开箱即用的精确一次传递，只需稍作配置即可。

随着 ChatGPT 的近期成功，我们可以观察到人工智能领域和机器学习领域的又一轮兴趣浪潮。这一领域上一次的兴趣浪潮，至少在一定程度上，是由诸如TensorFlow、PyTorch等优秀的机器学习框架以及像Spark这样的通用数据处理框架的出现所引发的，这些框架使得编写机器学习模型变得更加直接。从那时起，这些框架已经成熟，编写模型变得更加容易，正如您将在本文后面看到的。然而，数据集的准备和从各种来源收集数据有时会耗费时间和精力。创建一个完整的管道，该管道可以拉取现有或新创建的数据，对其进行调整，并将其摄取到选定的机器学习库中，这可能是一项挑战。让我们探讨一下 Debezium 是否能帮助完成这项任务，以及如何利用 Debezium 的功能使其更容易。

作为近期 使用变更数据捕获和流处理构建审计日志 博客文章的后续，我们希望通过管理功能扩展此示例，使其能够捕获和修复任何缺失的事务数据。

在上述博客文章中，有一个日志增强服务，用于将“Vegetable”数据库表中插入或更新的数据与事务上下文数据（例如

只要所有更改都通过蔬菜服务进行，这一切都能很好地工作。但情况总是如此吗？

那么维护活动或直接在数据库级别执行的迁移脚本呢？仍然存在大量此类活动，无论是故意的，还是因为这是我们正在努力改变的老习惯……

业务应用程序通常需要维护某种形式的审计日志，即应用程序数据所有更改的持久化跟踪。如果仔细看，带有 Debezium 数据更改事件的 Kafka 主题与之非常相似：它源自数据库事务日志，描述了应用程序记录的所有更改。所缺少的只是一些元数据：数据为何、何时以及由谁更改？在本博文中，我们将探讨如何通过变更数据捕获 (CDC) 提供和公开这些元数据，以及如何使用流处理来丰富实际的数据更改事件以包含此类元数据。

上周宣布Quarkus 以来，在 Java 社区引起了极大的兴趣：它由最优秀的 Java 库和标准构建而成，支持构建基于 GraalVM 和 OpenJDK HotSpot 的 Kubernetes 原生应用程序。在这篇博文中，我们将演示基于 Quarkus 的微服务如何通过 Apache Kafka 消费 Debezium 的数据变更事件。为此，我们将看看如何将我们最近关于Outbox 模式的帖子中的运输微服务转换为基于 Quarkus 的服务。

作为其业务逻辑的一部分，微服务通常不仅需要更新自己的本地数据存储，还需要通知其他服务有关发生的数据更改。Outbox 模式描述了一种安全一致地执行这两项任务的方法；它为源服务提供即时的“读你自己的写”语义，同时提供跨服务边界的可靠的、最终一致的数据交换。