【.com速递翻译】从广义上讲，全球很多企业都需要通过每天频繁的数据批处理和加载，定期将数据从一个数据库迁移到另一个数据库（或数据仓库）。这种类型的周期性批量加载通常很耗时，并且会消耗原始系统的大量处理能力。因此，管理员只能在业务运行的间歇期进行数据的批量传输和复制作业，否则会严重影响效率。显然，这与24x7不间断业务要求背道而驰。近年来，变更数据捕获（CDC）已成为高速数据流通环境下各种关系数据库、云数据库和数据仓库之间低延迟、高可靠、可扩展的数据交换。复制的理想解决方案。什么是变更数据捕获？CDC是从源数据库捕获数据和数据结构（也称为模式）的增量更改并近乎实时地传播到其他数据库或应用程序的地方。通过这种方式，CDC能够向数据仓库提供高效、低延迟的数据传输，以便及时将信息转换并交付给专为分析而设计的应用程序。当数据不断变化，无法中断与在线数据库的连接时，各种时效性信息的复制往往是云迁移的重要环节。与批量复制相比，更改数据捕获通常具有三个基本优势：CDC通过仅发送增量更改来降低通过网络传输数据的成本。CDC可以帮助用户根据最新的数据做出更快、更准确的决策。例如，CDC会将交易直接流式传输到专用于分析的应用程序。CDC最大限度地减少了对生产网络流量的中断。变化数据捕获方法目前业界有很多CDC方法可以用来跟踪和传输变化数据。您可以根据应用程序的实际要求及其对性能下降的容忍度从中进行选择。下面，我将为大家介绍四种不同的CDC方式所涉及的技术、工作原理以及各自的优缺点。时间戳或版本号跟踪数据库设计者可以在需要跟踪的数据表中设置一列来表示最后修改的时间戳或版本号。例如，我们通常可以将这些列命名为：LAST_UPDATE、DATE_MODIFIED和VERSION_NUMBER等。自上次数据捕获以来时间戳已递增的任何行都将被视为已修改。在基于版本号的跟踪方法中，一旦发生变化，所有具有最新版本号的数据都被认为已经被修改。在实际应用中，可以结合版本和时间戳这两个维度来跟踪数据库表中的数据。例如，您可以设置一个逻辑——“捕获自2021年6月22日以来发生变化的所有数据，相对于版本3.4”。优点：简单易懂。数据库设计者可以自定义应用程序的逻辑结构。不需要外部工具。缺点：增加了数据库的额外开销。需要额外的CPU资源来扫描表中的数据更改，并且需要预留资源以确保LAST_UPDATE列能够可靠地跟踪所有资源表。LAST_UPDATE中将不存在已删除的行。如果没有其他脚本来跟踪此类删除，DML语句（例如“DELETE”）将不会传递到目标数据库。容易出错，并可能导致数据一致性问题。表差异和增量这种CDC方法使用诸如表增量或tablediff之类的实用程序来比较两个表中的数据以查找不匹配的行。基于此，您可以使用其他脚本将源表的差异同步到目标表。虽然此方法比TimestampCDC更适合管理已删除的行，但它需要更多的CPU资源来查找差异。并且这种开销随着数据量的增加而线性增加。此外，针对源数据库或生产环境的分析查询也可能会降低应用程序本身的性能。为此，您可以定期将数据库导出到暂存环境以进行比较。然而，随着数据量的增加，这种传输的成本呈指数级增长。表差异的另一个问题是它无法捕获数据的临时更改。例如，假设有人更新了一个字段，但随后又将其改回其原始值。好吧，如果你只是运行一个简单的比较，你将无法捕捉到这个变化事件。并且由于diff方法本身有延迟，无法实时执行。优点：可以使用各种本机SQL脚本来准确查看已更改的数据。缺点：由于这种方式使用了数据源的三份副本：原始数据、之前的快照和当前快照，因此整体存储需求增加。在具有繁重事务负载的应用程序中，它不能很好地扩展。注意：无论是表差还是时间戳CDC方式都不适用于真实的生产环境。所以对于大数据集，我推荐大家使用下面两种CDC方式。实际上，基于触发器和事务日志的变更数据跟踪方式只是出于同一目的的两种不同的服务方式。基于触发器的CDC我们需要为每个参与数据复制的表创建三个触发器。当数据记录中发生以下特定事件时，将触发相应的操作：当一条新记录插入到数据表中时，触发器为INSERT触发器。当数据记录更改时，将触发UPDATE触发器。删除数据记录时，会触发DELETE触发器。“事件历史”的影子表存储在数据库本身中，由一系列不同的状态变化事件组成。每当对象的状态发生变化时，新事件就会附加到序列中。相应地，关于变更记录的信息也被转移到“事件历史”的影子表中。最后，根据历史表中的个别事??件，将更改传输到目标数据库。一个简单的历史表如下所示：由于源数据库中的每个表都需要一个触发器，因此在操作表上运行触发器的开销随着变化的发生而增加。但是，由于基于触发器的CDC工作在SQL级别，因此许多用户会倾向于使用这种方法。优点：非常可靠和详细。影子表可以提供所有事务的不可变详细日志。缺点：每次插入、更新或删除一行时，都需要多次写入数据库，从而降低数据库的性能。DBA和数据工程师应该继续监视和测试添加到生产环境中的各种触发器的性能，以确定是否可以容忍这种额外的开销。事务日志CDC众所周知，数据库使用事务日志主要用于备份和恢复目的，但它们也可用于将更改复制到目标数据库或数据湖。在基于事务日志的CDC系统中，数据流不是持久存储的。他们使用Kafka来捕获变化并将它们推送到目标数据库。可以看出，基于事务日志的CDC和基于触发器的CDC的主要区别在于，每次更改都会进入数据库引擎生成的事务日志。也就是说，数据库引擎使用本机事务日志（也称为重做日志）来存储所有数据库事件，以便在发生故障时可以恢复数据库。他们不需要执行任何应用程序级别的更改或扫描影子表。因此，从事务日志中恢复数据虽然更复杂，但比基于触发器的CDC更可行。优点：它对生产环境中的数据库系统的影响最小，因为每个事务都不需要额外的查询。无需在生产环境中更改数据库系统的架构或添加额外的数据表。缺点：由于大多数数据库没有记录它们的事务日志格式，也没有在新版本中宣布更改，因此DBA很难解析数据库的内部日志格式。DBA有时需要在每个新版本的数据库中解析更改数据库的日志记录逻辑。由于日志文件通常由数据库引擎归档，因此CDC软件必须在此之前读取日志，或者能够读取归档日志。创建可扫描事务日志所需的额外日志级别可能会增加少量性能开销。当CDC应用程序发送数据时，目标数据库可能会意外变得无法访问。他们必须缓冲未发送的数据，直到目标数据库重新联机。当然，未能完成此步骤可能会导致数据丢失或重复。同样，如果源和目标之间的传输连接中断，系统可能会出现故障，导致数据丢失、记录重复，需要从原始数据重新加载。基于触发器和事务日志的比较一般来说，基于触发器的CDC和事务日志CDC是数据库设计模型，可以用来构建反应式分布式系统。其中，基于触发器的CDC以自身的事件日志作为真正的数据源，而事务日志CDC则依赖于底层数据库的事务日志作为真正的数据源。触发器可以用作每个数据库事务的一部分，以捕获实时发生的事件。对于每次插入、更新或删除，都会使用触发器来触发记录的更改。另一方面，事务日志CDC可以独立于事务运行。它使用重做日志文件来记录更改。因为CDC操作在发生时并不直接与数据库中的每个事务相关联，所以它们的性能得到了提高。在实际应用中，各种常见的DBSync产品和DBConvertStudio都会采用基于触发器的数据库同步CDC方式。然而，对于集群数据库，基于触发器的方法可能与使用MySQL的二进制日志或PostgreSQL的事务日志有很大不同。毕竟，MySQL在其官网声称：“启用二进制日志后，服务器的性能可能会略有下降。但是，二进制日志在方便复制和恢复操作方面的好处通常超过性能.略有下降。”(https://dev.mysql.com/doc/refman/8.0/en/binary-log.html)总结综上所述，CDC是现代数据架构的重要组成部分，可用于从源系统传输事务数据成数据流。我们需要它来支持实时交易数据，而不会对源系统造成重大负担。它不需要对源应用程序进行任何更改，并保证只传输最少量的数据。因此CDC更适合大规模数据集。未来，我们将看到CDC在强调数据分析和历史数据对比的企业数据仓库中的广泛应用。原标题：变更数据捕获（CDC）：它是什么以及它是如何工作的？作者：DmitryNarizhnykh
