构建企业CDC数据湖解决方案 -DZone

CDC（Change Data Capture）是一个软件过程，它捕获源数据库中所做的更改（DDL 和 DML）以同步另一个数据存储库，例如数据库、内存缓存、数据仓库或数据湖。CDC 用于本文不会讨论的其他有趣且免费的用例，例如：

CQRS 模式：其中一种实现涉及具有单独的写入（命令）和读取（查询）数据库和数据模型。写层支持插入、更新和删除操作，读层支持查询数据操作。CDC 允许我们将命令操作从写数据库复制到读数据库。
分析微服务：提供更改事件流以跟踪何时以及发生哪些更改并分析行为模式。

CDC 是一个很好的解决方案，有四种常见的场景：

OLAP数据库迁移：在我们将所有或部分工作负载从当前数据仓库迁移到新的 OLAP 解决方案的情况下。CDC 允许我们将相同的数据复制到两个系统并使迁移更容易。如今，许多公司正在将工作负载从 OnPremise 数据仓库迁移到数据云解决方案。
将信息从OLTP 数据库复制到 OLAP数据库：将数据从我们的操作数据库复制到数据仓库或数据湖。
数据库即服务：为分析沙箱或预生产沙箱提供我们数据库的副本。
从单体到微服务的迁移：应用扼杀者模式将我们的单体应用程序逐步迁移到微服务。在第一阶段复制两个应用程序共存所需的一些数据集。

企业CDC解决方案

基于此，我们提出以下解决方案架构：

Debezium 作为 Source连接器：这一块将是负责读取从我们的源数据库引擎的变化，并将它们发送到通道。它将作为连接器部署在我们的Kafka Connect Cluster 中。
卡夫卡作为 Channel：它提供了可以在被部署用于事件的生产/消耗和大的生态系统的连接器广泛的API沿着中间存储卡夫卡连接或在另一平台上。
Kafka Sink JDBC（通过Confluent）与 Event flattering SMT (by Debezium)作为Sink Connector：该连接器允许我们在目标数据库上执行复制，有几个配置参数。作为用于全球目的的通用解决方案，它是一个不错的选择。在其他情况下，例如 Snowflake 或其他云服务，JDBC 连接器的成本效益和性能比供应商本身提供的其他策略更差。评估切换到供应商本身提供的连接器而不是使用通用 JDBC 的成本收益是很重要的。
Kafka Connect 作为连接器平台：它提供了一个框架，可以基于简单的配置将连接器部署为插件，并与我们的 Kafka 完全集成。这是一个非常好的选择，因为它允许我们标准化接收器/源连接器管理，例如 Debezium 复制操作和 JDBC 接收器连接器。

在数据量大、技术多样的复杂环境中，向新的数据平台提供数据是一个很大的挑战。但真正的挑战是在提供这些数据的同时确保组织做出有价值的决策所需的质量。

准确性、一致性、唯一性或及时性是衡量我们数据质量的一些指标。在我们看来，CDC 而不是其他解决方案，可以让我们以一种相对简单的方式来规范数据摄取并确保数据质量。

Recommend