采集文章系统(变更数据采集（CDC）是一个一流的最佳决策至关重要)

　　采集文章系统(变更数据采集（CDC）是一个一流的最佳决策至关重要)

　　没有人愿意查看仪表板或根据昨天的数据做出决策。我们生活在这样一个世界中，实时信息是我们用户的一流期望，对于在组织内做出最佳决策至关重要。

　　Change Data采集 (CDC) 是一种高效且可扩展的模型，可简化实时系统的实施。

　　

　　更改数据采集图表

　　Shopify、Capital One、Netflix、Airbnb 和 Zendesk 等行业领先公司已经发布了技术 文章，展示了他们如何在其数据架构中实施变更数据捕获 (CDC) 以：

　　在这个关于更改数据的多部分系列采集 中，我们将深入探讨。

　　开始吧。

　　什么是变更数据采集 (CDC)？

　　跟踪系统变化的想法并不新鲜。自从有了编程的想法，工程师就一直在编写脚本来批量查询和更新数据。变更数据采集 是决定如何跟踪变更的各种方法的形式化。

　　CDC 的核心是一个允许应用程序*敏*感*词*数据存储变化并对这些事件做出反应的过程。此过程涉及数据存储（数据库、数据仓库等）和捕获数据存储更改的系统。

　　例如，人们可以。

　　现实世界的例子

　　让我们看一个可以从 CDC 中受益的真实示例。在这里，我们有一个 PostgreSQL 中的表示例。

　　

　　用户数据实例

　　当用户表中的信息发生变化时，企业可能需要这个。

　　我们可以通过对数据更改事件采取行动来创建执行上述所有操作的服务，并在需要时独立创建和管理它们。

　　CDC 通过在事件发生时采取行动来提高效率，并通过利用“事件驱动”来实现可扩展性。

　　CDC事件的一个例子

　　CDC 系统通常会发出一个事件，其中收录有关所发生事件的详细信息。当使用像 Debezium 这样的 CDC 系统并创建新用户时，会生成以下事件。

　　

　　剖析 CDC 事件

　　此事件描述数据的架构、发生的操作 (op) 以及负载之前和之后的数据。

　　事件的形式、信息的保真度、传递的时间都取决于疾控中心系统的执行情况。

　　疾控中心的实施

　　跟踪 PostgreSQL 数据库中的更改可能看起来与跟踪 MongoDB 中的更改非常相似或非常不同。这完全取决于环境和选择的捕获方法。

　　可以定义选择的捕获方法

　　让我们看一下每种不同的方法，并讨论每种方法的一些优点和缺点。

　　轮询

　　在实现任何数据库连接器时，决定从“轮询或不轮询”开始。轮询是 CDC 概念上最简单的方法。为了实现轮询，您需要以一定的时间间隔查询数据存储。

　　例如，您可以在一个时间间隔内运行以下查询。

　　从用户中选择 *；

　　此类 SELECT * 查询被视为批处理（“给我一切”）轮询方法。虽然这对于捕获当前状态的快照非常有用，但下游消费者需要努力弄清楚每个时间间隔内发生了哪些数据变化。

　　但是，轮询可以变得更加细化。例如，我们只能轮询一个主键。

　　从用户中选择 MAX(id)；

　　系统可以跟踪主键 (id) 的最大值。当最大值增加时，表示发生了 INSERT 操作。

　　此外，如果数据库具有 updateAt 列，则查询可以查看时间戳更改以捕获 UPDATE 操作。

　　SELECT * from Users WHERE updated_at > 2021-02-08;

　　利弊

　　简单：轮询很棒，因为它易于实施和部署，而且非常有效。

　　自定义查询很有用。一个好处是可以自定义轮询时使用的查询以适应复杂的用例。查询可以直接在 SQL 中收录 JOINS 或转换。

　　捕捉删除很困难：使用轮询，捕捉删除更加困难。如果数据库中的一行完全没有了，你就不能真正查询它。一种解决方案是使用数据库触发器创建表来存储已删除的数据。然后删除操作变成了插入操作到可以轮询的新表中。

　　事件被拉出，而不是被推出。通过轮询，可以从上游系统中提取事件。例如，当使用轮询来摄取数据仓库时，摄取将在 CDC 系统决定进行轮询时发生。理论上，“实时”可以通过足够快的轮询来完成，但这可能会给数据库带来性能开销。

　　性能开销是一个问题。SELECT * 或任何复杂的查询在海量数据集上都不能很好地扩展。一种常见的解决方法是通过轮询备用实例来替换主数据库。

　　无法捕获查询时间之间的变化。另一个考虑因素是查询时间之间的数据变化。例如，如果系统每小时轮询一次，并且数据在同一小时内多次更改，则您只能看到查询时间的更改，而看不到任何中间更改。

　　数据库触发器

　　大多数流行的数据库都支持某种形式的触发器。例如。在 PostgreSQL 中，可以构建一个触发器，当一条记录被删除时，将它移动到一个新表中。

　　CREATE TRIGGER moveDeleted

　　在删除“用户”之前

　　对于每一行

　　执行过程 moveDeleted()。

　　因为触发器可以有效地侦听操作并执行操作，所以数据库触发器可以充当 CDC 系统。

　　在某些情况下，这些触发器可以是非常复杂和完整的功能。例如。在 MongoDB 中，触发器是用 Javascript 编写的。

　　exports = async function (changeEvent) {

//从变化流事件对象中解构出字段

const { updateDescription, fullDocument }= changeEvent;

// 检查shippingLocation字段是否被更新。

const updatedFields = Object.keys(updateDescription.upedFields)。

const isNewLocation = updatedFields.some(field =>)

field.match(/shippingLocation/)

);

// 如果位置改变了，就给客户发短信说明更新的位置。

if（isNewLocation）{

// 做点什么

}

};

　　利弊

　　易于部署。触发器很棒，因为它们对大多数数据库都有开箱即用的支持，并且易于实现。

　　数据一致性。任何当前和新的下游消费者都不必担心执行此逻辑，因为此逻辑收录在数据库中，而不是应用程序中 - 在微服务架构的情况下。

　　数据库中的应用程序逻辑可以被破坏：但是，数据库不应该收录太多的应用程序逻辑。这可能导致行为与数据库的耦合过于紧密，一个错误的触发器可能会影响整个数据基础架构。触发器应该简洁明了。

　　每个动作都被捕获。您可以为每个数据库操作创建一个触发器。

　　性能开销是一个问题。由于与轮询方法相同的原因，编写不当的触发器也会影响数据库性能。收录复杂查询的触发器在大型数据集上无法很好地扩展。

　　流式复制日志

　　最好至少运行一个数据库的辅助实例，以确保正确的故障转移和灾难恢复。

　　在这种模式下，数据库的备用实例需要在不丢失信息的情况下与主实例保持同步。现在最好的方法是让数据库写入日志中发生的所有更改。然后，任何备用实例都可以从此日志中流式传输更改并在本地应用这些操作。实时做同样的事情是允许备用实例“镜像”主实例。

　　以下是一些关于一些最流行的数据库如何工作的参考资料。

　　CDC 可以使用相同的机制来*敏*感*词*变化。就像备用数据库一样，附加系统也可以在更新流式日志时处理它们。

　　

　　在上面的 PostgreSQL 示例图中，CDC 系统可以充当额外的 WAL *敏*感*词*，处理事件并将它们发送到消息传输（HTTP API、Kafka 等）。

　　下面是使用提供的 SQL 函数从 PostgreSQL 的 WAL 查询更改的示例。

　　test_decoding plugin:

postgres=# SELECT * FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL);

lsn | xid | data

-----------+-------+---------------------------------------------------------

0/ba5a688 | 10298 | start 10298

0/BA5A6F0 | 10298 | table public.data:INSERT: id[integer]:1 data[text]:'1' 。

0/BA5A7F8 | 10298 | table public.data:INSERT: id[integer]:2 data[text]:'2' 。

0/ba5a8a8 | 10298 | commit 10298

(4 rows)

　　在上面的查询响应中，它描述了以下内容。

　　这些更改事件的格式将基于逻辑解码输出插件。例如 wal2json 输出插件允许您以 JSON 格式输出更改，这比 test_decoding 插件的输出更容易解析。

　　PostgreSQL 还提供了一种机制来在这些更改发生时对其进行流式传输。正如您在前面的事件示例中看到的，Debezium 还实时解析流式日志并生成 JSON 事件。

　　利弊

　　事件被推送。流式日志的一个巨大好处是事件在发生变化时被推送到 CDC 系统（而不是轮询）。这种推送模式支持实时架构。以用户表为例，数据仓库的摄取将在流式日志CDC系统中实时发生。

　　高效且低延迟。备用实例使用流式日志进行灾难恢复，效率和低延迟是重中之重。流式复制日志是捕获更改的最有效方法，并且对数据库的开销最小。这个过程在不同的数据库中会有不同的表现，但这些概念仍然适用。

　　每个动作都被捕获。数据存储中发生的每个事务都将写入日志。

　　很难获得数据的完整快照。通常，在一定时间（或大小）之后，流式日志会被清除，因为它们占用空间。因此，日志可能不收录已发生的所有更改，仅收录最近的更改。

　　需要进行配置。启用复制日志可能需要额外的配置、插件，甚至是数据库重启。在最小的城市地区实施这些变化可能很麻烦，需要规划。

　　下一步是什么？

　　捕捉数据变化就像是任何应用程序架构的瑞士*敏*感*词*；它对许多不同类型的问题很有用。侦听、存储和处理任何系统（尤其是数据库）中的变化，让您可以在两个数据存储之间实时复制数据，将单一应用程序分解为可扩展的、事件驱动的微服务，甚至可以为实时 UI 提供支持.

　　流式复制日志、轮询和数据库触发器为构建 CDC 系统提供了一种机制。对于您的应用程序架构和所需的功能，每种方法都有其自身的优点和缺点。

　　在下一篇文章中，我们将深入挖掘。

　　我迫不及待地想看看你建造了什么。