Debezium 博客
“如何添加一个新表来开始捕获其更改？”
这是我们社区中最常见的问题之一。
如果你问《银河系漫游指南》，万事万物的答案是42。遗憾的是，在现实世界中，事情并没有那么简单。真正的答案是：这取决于具体情况。
在这篇文章中，我不仅想通过讲解不同的场景来提供一个答案，还想解释其背后的原因。
许多从事数据流工作的工程师都不是 SQL 专家。所以你可能会问自己：什么是 CTE？更重要的是，什么是 CTE 查询，它们有什么用，以及它们如何帮助你处理 Debezium？
在本文中，我们将回答这些问题，探讨 Debezium Oracle 连接器如何利用 CTE 查询，并讨论涉及的优点和权衡。
当我开始研究 Debezium 时，我脑海中浮现出两个问题：能否构建 Debezium 的原生版本？我能否在不依赖额外基础设施的情况下，直接在我的微服务中接收变更数据捕获 (CDC) 事件？
这促使我们开发了一个新的 Debezium 流：我很高兴地宣布 **Debezium Extensions for Quarkus** 的第一个版本！
还记得调试数据流管道就像在证据不断移动的犯罪现场玩侦探游戏吗？现在，拿起你的放大镜，因为我们将把你变成流媒体世界的夏洛克·福尔摩斯。在我们介绍了 Debezium 与 OpenLineage 的集成 后，是时候卷起袖子，深入进行一些真正的侦探工作了。我们将构建一个完整的订单处理管道，使用 Debezium 捕获数据库更改，通过 Apache Flink 处理它们，并使用 OpenLineage 和 Marquez 跟踪每一条数据血缘信息——因为丢失数据就像丢失钥匙，在生产环境中只会更令人尴尬。
案例定义
在此次展示中，我们演示了如何利用血缘元数据来排除数据管道中的问题。我们的电子商务订单处理管道，尽管简单，但有效地说明了血缘元数据在操作监控和调试方面的优势。我们将模拟 Debezium 连接器中的配置更改，该更改导致订单处理作业跳过记录。使用血缘图，我们将遍历管道组件以确定问题的根本原因，并了解元数据跟踪如何实现更快的故障排除。
如今的数据格局与过去集中式数据库和简单 ETL 流程已大不相同。当今的组织在多样化的数据源、实时流处理、微服务架构和多云部署的环境中运行。最初从运营系统到报告数据库的简单数据流，已经演变成复杂的互联管道、转换和依赖网络。从 ETL 到 ELT 模式的转变、数据湖的采用以及 Apache Kafka 等流媒体平台的普及，为数据处理带来了前所未有的灵活性。然而，这种灵活性也付出了代价：理解数据如何在这些系统中移动、转换和演变变得越来越具挑战性。
理解数据血缘
数据血缘是指跟踪数据从源头到最终目的地的流动和转换的过程。它本质上映射了数据的“生命周期”，显示了它的来源、如何被改变以及它在数据管道中的去向。这包括记录数据在其旅程中经历的所有转换、连接、拆分和其他操作。
其核心在于，数据血缘回答了关键问题：这些数据来自哪里？它们经历了哪些转换？哪些下游系统依赖于它？当问题出现时，团队应该将调查重点放在哪里？
一年前，我们开始了创造一种现代变更数据捕获方法的令人难以置信的旅程。我们渴望创造一个工具，让您可以专注于您的数据，通过基于管道的方法定义它如何从源流向目的地。所有这一切都配有一个全新的现代用户界面，以简化与其的交互。
我们将其命名为 Debezium Management Platform，或者如果您愿意，也可以简称为 Debezium Platform。
我们很高兴 Debezium 3.1 是这项多年努力的第一个正式版本。
在复制用于分析的业务数据方面，变更数据捕获 (CDC) 是黄金标准。它提供了可伸缩性、近乎实时的性能，并捕获所有数据修改，确保您的分析数据集始终保持最新。Debezium 是该领域的领先工具，它可以连接到各种数据库，并以 JSON 和 Avro 等多种格式导出 CDC 事件，从而轻松与不同系统集成。
虽然 Debezium 本身是一个基于 Java 的项目，但数据工程领域越来越依赖 Python。这篇博文演示了如何利用 Debezium 在 Python 环境中使用 pydbzengine。我们将探讨如何使用这些技术来构建一个健壮且可扩展的 CDC 解决方案。
在本篇文章中，我们将讨论一个 CDC-CQRS 管道，它连接了一个规范化的关系型数据库（MySQL）作为命令数据库，以及一个反规范化的 NoSQL 数据库（MongoDB）作为查询数据库，通过 Debezium & Kafka-Streams 实现 DDD Aggregates 的创建。
