如何应用变更数据捕获CDC将数据从生产数据库可靠地迁移到其他系统?
OLTP 数据库中积累的操作数据通常需要取出来执行事务处理以外的有用任务。这包括将数据移出数据仓库、更新缓存、仪表板等。
更改数据捕获 (CDC)是观察写入数据库的所有数据更改并以可以将它们复制到下游系统以用于其他目的的形式提取它们的过程。
在本文中，我将讨论一些适用 CDC 的实际用例。大多数示例都与 Debezium 有关，它是基于 Kafka 构建的开源 CDC 引擎。
1. 能有助于缓存失效
Redis和Memcached等键值存储用作缓存以加快读取速度。通常，他们将预先计算的 SQL 查询结果保存在内存中，以便可以消除对数据库的后续访问。
缓存最大的挑战是如何让缓存的数据与源数据保持一致。例如，源数据库中的记录更新多久传播到缓存？
通常，缓存会超时并定期自动失效。但是在 CDC 的帮助下，缓存的条目可以以事件驱动的方式失效。
假设我们有一个 DynamoDb 表来捕获对候选人的投票。每当记录新投票时，它都会作为事件捕获并发布到 DynamoDb 流，由 Lambda 函数处理。该函数的逻辑聚合投票计数并将其写入 ElasticCache。因此，仪表板可以直接读取缓存的结果，而无需 DynamoDb 每次都运行聚合。
2.更新一个搜索索引，比如Elasticsearch
我们经常使用 OLTP 数据库作为我们的操作记录系统。但它们不适合执行诸如全文搜索之类的专门操作。虽然数据库可以配备相关的扩展，但人们经常将全文搜索操作卸载到像 Elasticsearch 这样的专门系统。
例如，我们可以在 Elasticsearch 中维护一个高度非规范化的聚合视图，以满足客户订单等查询。在关系数据库中，此查询将通过连接多个表来提供，如果要连接的行数很多且查询频繁，则它是不可扩展的。但 Elasticsearch 可以将这些信息捕获到单个文档中，并使消费者能够按产品名称搜索订单。
我们在这里面临的挑战是如何将源系统更改可靠地传播到 Elasticsearch 并始终保持两个系统一致。
在这一点上，像 Debezium 这样的 CDC 系统可以通过检测源数据库更改并以可扩展且可靠的方式将它们传播到 Elasticsearch 来帮助您。
Debezium 获取 MySQL 的行级更改并将其写入 Kafka 主题。然后，部署到 Kafka Connect 的 Elasticsearch sink 连接器读取更改并传播到 Elasticsearch 的相关索引。您可以从这里阅读更多相关信息。
3.实时数据加载到数据仓库
操作数据库不是运行繁重分析工作负载的好选择，因为它们会阻碍常规 OLTP 操作的性能。因此，必须将运营数据移动到专用系统（例如数据仓库）以运行支持 BI 和报告需求的分析查询。
有两种方法；ETL 是传统的方法，您可以批量操作数据并定期将它们加载到仓库。ETL 的缺点是延迟。但是使用 CDC，您可以在源系统更改发生时捕获它们并将它们实时传送到仓库。
今天，许多数据仓库允许以流方式加载数据。AWS Redshift、Google BigQuery、Apache Druid 和 Apache Pinot 就是几个例子。
您可以捕获 DynamoDb 表的更改并将它们写入 Kinesis 流。然后使用 Kinesis Firehose 将它们加载到 RedShift。同样，您可以使用 Debezium 将操作数据移动到 Kafka 主题中，Apache Pinot 可以以流式方式读取该主题。
4. 将本地数据同步到云端
有时，通常需要将在诸如本地系统（例如 POS 系统、COTS 应用程序）等边缘位置产生的操作数据移动到位于云中的中央数据库。主要目标是利用云供应商提供的可扩展和持久的存储选项。
例如，本地事务数据可以发送到云数据仓库，在那里可以执行丰富的分析操作，而无需在本地配置昂贵的基础设施。另一个用例是将本地数据迁移到云中提供的新应用程序。
您可以利用 CDC 有效地捕获本地数据库更改并将其传播到云。大多数情况下，它是作为位于本地和云的两个数据库之间的连续数据复制来完成的。
5. 微服务物化视图的事件驱动更新
微服务架构提倡每个服务都有一个数据库来保存服务私有的数据。尽管这提高了跨服务的自治性和可扩展性，但这可能会导致一些复杂情况。
例如，当一个服务尝试访问另一个服务拥有的数据时，唯一的方法是进行 API 调用。但是当涉及级联 API 调用时，此模型不可扩展。消费者必须执行低效的内存中连接才能保持来自多个服务的响应。
作为一种补救措施，微服务依靠命令查询职责分离（CQRS）模式将状态突变与查询分离。服务可以侦听来自下游系统的域事件并更新内部物化视图以在本地执行查询，而不是实时查询服务。这提高了读取性能、整体系统可用性和自主性。
6. 使用发件箱模式进行可靠的微服务数据交换
微服务的另一个常见问题是跨多个服务边界可靠地更新数据。例如，考虑一个管理采购订单的微服务。下新订单时，可能必须将有关该订单的信息转发给运输服务和客户服务。
Saga模式在一定程度上有助于解决这个问题。但是由于其同步性质，实现 Saga 通常很复杂和脆弱。
CDC 通过捕获对发件箱表所做的更改并以可靠且最终一致的方式将它们传播到下游微服务来进入画面。
Debezium 博客有一篇关于使用 Debezium 实现这一点的优秀文章。
7.实时信息发布
CDC 允许您将源数据库中的更改作为事件流捕获。然后可以使用Apache Flink等流处理引擎处理这些事件，以实时应用转换或运行聚合。清理后的事件比它们的原始版本更有意义。因此它们可以用于人类消费，如下所示。
更新实时仪表板
Microsoft Power BI 等仪表板可以通过从流数据集中读取来实时更新。
发布到异步 API
处理后的更改事件可以写入 WebSocket，以便订阅者可以采取适当的操作。
8. 建立审计日志
维护审计日志是业务应用程序的常见要求，即应用程序数据的所有更改的持久跟踪。
在其自然形式中，像 Debezium 这样的 CDC 系统根据更改应用于源系统的顺序来捕获、存储和传播更改。因此，接收此数据的目标系统可以建立已应用于源系统的更改的时间顺序并追溯到特定时间点。
可以使用来自外部系统的信息来丰富变化，以提供有助于对事件进行取证分析的整体视图。例如，通过从头开始重放审计日志，可以找到谁在哪个时间做了什么操作的答案。
Debezium 博客有一篇关于这个主题的深入文章。您可以阅读它以获取更多信息。
更多：变更数据捕获CDC文章