变更数据捕获 (CDC) 是数据工程中的强大工具，在过去几年中在各种组织中得到了巨大的应用。这是因为它能够以非常低的延迟将事务数据库紧密集成到您企业中的许多其他系统中。
CDC 对事务数据库中发生的更改（例如插入、更新和删除）做出响应，并将这些更改实时发送到另一个系统以进行摄取和处理。虽然实现 CDC 解决方案有多种可能的方法，但最强大的方法是基于日志的 CDC，它从数据库的事务日志中检索更改事件。
与其他风格的 CDC（例如定期轮询更改记录）相比，基于日志的 CDC 具有许多优点，包括：
- 延迟极低，同时资源效率高
- 保证永远不会错过任何更改，包括删除
- 对您的源数据模型没有影响
有许多商业和开源软件（OSS）CDC工具，但使用最广泛的OSS CDC平台是Debezium，它提供了许多流行数据库的连接器，例如MySQL，Postgres，SQL Server，Oracle，Cassandra，Google Cloud扳手等。一些数据库供应商已经基于 Debezium 实现了自己的 CDC 连接器，例如Yugabyte和ScyllaDB。
Debezium 的记录格式用于对更改事件进行建模，描述数据记录的新旧状态，并包括源数据库和表名称等元数据以及事务日志文件中的位置。这种格式已成为变更事件数据事实上的标准，受到数据流领域众多项目和供应商的支持。
Debezium 等 CDC 平台经常与流行的数据工程工具（例如用于数据流的 Apache Kafka 和Apache Flink ）一起使用，后者本身支持 Debezium事件格式以进行状态流处理，包括过滤和加入来自各种来源的变更事件流。
在本文中，我将概述变更数据捕获的七个常见用例
1、分析数据平台
CDC 最广泛采用的用途之一是将数据从事务数据库获取到更有效地支持分析处理的系统中。MySQL 或 Postgres 等事务数据库系统经过优化，可以有效地处理数量相对较少的记录上的事务，而OLAP系统则旨在处理可能读取数百万行数据的查询。CDC 提供了一种方法，使 OLAP 数据存储与 OLTP 系统中可能的最新数据保持同步，端到端延迟仅为几秒。
CDC 通常用作数据管道中的组件，将数据更改传播到云数据仓库（例如，通过 Snowpipe或Google BigQuery 的Snowflake ）和数据湖，从而支持数据科学、一般报告和即席查询用例。另一方面，低延迟摄取到实时分析存储（例如 Apache Pinot、Apache Druid 或 Clickhouse）允许您实现应用内分析或实时仪表板等用例。对于涉及频繁更新现有记录（例如可变数据）的用例，针对 upsert 语义优化的存储（例如Pinot或Rockset）通常为 Debezium 事件格式提供定制支持。
2、应用程序缓存
用于提高应用程序性能的常见模式是引入只读数据的本地缓存。这样做的主要挑战之一是保持缓存最新并确保应用程序不会读取过时的数据。CDC 非常适合这里。CDC 实时响应数据库的更改，并将这些更改提供给缓存更新器组件，以确保本地缓存提供最新的视图。
除了 Redis、 Infinispan或 Hazelcast等专用缓存解决方案之外，嵌入式 SQLite 数据库是实现应用程序端缓存的一个有趣的选择，因为它们不仅允许简单的基于键的查找，而且支持通过 SQL 进行全面的查询灵活性。
创建数据的非规范化数据视图然后将其存储在缓存中可能会很有用，而不是按原样缓存原始数据。例如，Apache Flink 可用于连接 RDBMS 中两个表的更改事件流，并从中创建一个嵌套数据结构。这样，就可以非常高效地从缓存中检索数据，而无需执行任何昂贵的读取时连接。
3、全文搜索
与事务数据库系统不太适合直接支持分析工作负载的方式类似，全文搜索也从专门为此目的设计的数据存储中受益匪浅，例如 Elasticsearch 或 OpenSearch。利用特定于搜索的功能（例如词干、规范化、停用词、同义词和缩写）可确保为广泛甚至"模糊"搜索快速提供最相关的结果。
就像上面的缓存示例一样，CDC 非常适合您的架构，可以使您的全文搜索数据存储保持最新。CDC 实时响应对数据库所做的更改，并将更改的数据事件发送到 Apache Flink 等工具，该工具将它们加载到您的搜索系统中。
另一个考虑因素是可能需要创建在 Elasticsearch 等文档存储中使用的嵌套文档结构。
4、审核日志
在企业应用程序中，保留数据的审核日志是一项常见要求，以跟踪数据记录的更改时间和方式。CDC 提供了一种有效的解决方案，因为从数据库事务日志中提取数据更改可以提供以下信息：更改事件流（其中包含针对表执行的所有插入、更新和删除的事件）可以被视为审核日志的简单形式。
然而，这种方法缺乏上下文元数据，例如用户信息、客户端详细信息、用例标识符等。为了解决此限制，应用程序可以通过专用元数据表或以在客户端发出的逻辑解码消息的形式提供元数据。每笔交易的开始。然后可以使用 Apache Flink 进行流处理，将丢失的上下文合并到记录中。
在同一个 Flink 作业中，您现在可以添加接收器连接器，例如将丰富的事件写入 Kafka 主题。或者，根据您的业务需求，丰富的更改事件也可以作为审核日志写入对象存储（例如 S3）或可查询的分析数据存储。
5、连续查询
并非所有查询都需要由 Pinot 或Snowflake等静态存储提供服务。Apache Flink 提供了动态表，这是一种"不断更新并且可以像常规静态表一样查询"的表。但是，与静态表查询相比，动态表上的查询连续运行并生成一个根据输入表的更改不断更新的表，并将结果存储在新的动态表中。
CDC 流可以用作驱动连续查询的源，代表增量更新的物化视图的形式，随着底层数据的变化，始终产生最新的结果。
这允许您创建一个数据管道，将 CDC 数据摄取到 Flink 中，创建连续查询以对 CDC 数据流执行聚合、过滤或模式识别，并且结果可用于实现实时分析和决策。例如，您可以考虑使用服务器发送事件或 Web 套接字等技术将任何更新直接推送到连接的 Web 浏览器中的仪表板，从而完全避免对任何中间查询层的需要。
6、微服务数据交换
作为业务逻辑的一部分，微服务通常不仅需要更新自己的本地数据存储，还需要通知其他服务已发生的数据更改。发件箱模式（使用 CDC 实现）是一种让服务以安全一致的方式执行这两项任务的方法，避免不安全的双重写入的陷阱。
CDC 非常适合响应发件箱表中的新条目并将其流式传输到消息服务（例如 Apache Kafka）以传播到其他服务。通过仅修改单个资源（源微服务自己的数据库），可以避免同时更改不共享一个公共事务上下文的多个资源时出现的任何潜在不一致情况。
如果您使用 Postgres，那么您甚至不需要定制发件箱表来实现发件箱模式。借助逻辑解码消息，您可以将发件箱事件专门插入到事务日志中，然后可以使用 Debezium 等 CDC 工具检索和传播这些事件。
7、整体架构到微服务的迁移
通常，您不会从头开始构建应用程序，但现有的应用程序环境需要发展和扩展。在这种情况下，可能有必要从现有的整体架构迁移到一组松散耦合的微服务，从而拆分现有的整体架构。为了避免大爆炸迁移的风险，建议采取渐进的方法，一次提取一项服务。这种方法也被称为"扼杀者无花果模式"，因为新服务围绕旧应用程序增长，随着时间的推移"扼杀"它。
这样做时，旧的整体服务和新服务将共存一段时间。例如，您可以首先将某些数据（例如客户的订单历史记录）的读取视图提取到新的微服务，而整体应用程序继续处理数据写入。然后，您可以使用 CDC 将数据更改从整体传播到提供读取视图的服务。