在不断发展的数据世界中，有一个问题经常出现。如何才能无缝地复制呈指数级增长且来源越来越多的数据？本文解释了一些基础的开源技术，这些技术可能有助于将数据库复制任务商品化到数据仓库、湖泊或其他数据库。
一种流行的复制技术是变化数据捕获（CDC），这种模式允许快速识别、捕获源数据库的行级数据变化，并实时传递到目标数据仓库、湖或其他数据库。通过CDC，只有自上次复制以来发生变化的数据--按插入、更新和删除操作分类--才在范围内。这种增量设计方法使 CDC 比其他数据库复制模式（如全数据库复制）更有效率。在全数据库复制中，整个源数据库表（可能有数百万行）被扫描并复制到目的地。
开源的CDC
Debezium是一个开源的分布式CDC平台，利用Apache Kafka来传输数据变化。它持续监控数据库，确保每一个行级变化都以完全相同的顺序被发送到目的地。然而，在一个自己动手的复制项目中使用Debezium可能是一个重头戏。它需要深入了解与源系统和目的系统、Kafka和Debezium内部相关的概念。例如，只要看看Debezium MySQL连接器所需的所有细节就知道了。
Airbyte是一个开源的数据整合引擎，它允许你整合你的数据仓库、湖泊和数据库中的数据。Airbyte利用Debezium并完成所有繁重的工作。事实上，在Airbyte中，Debezium是作为一个嵌入式库运行的。这种工程设计允许使用Debezium，而不需要使用Apache Kafka或其他语言运行时间。这个视频显示了你如何使用CDC在几分钟内用Airbyte复制一个PostgreSQL数据库。开源代码可用于Postgres、MySQL和MSSQL，并将很快用于所有其他启用它的主要数据库。
数据库的一些典型CDC用例是什么？
数据库是当今数据基础设施的核心，有几种不同的使用情况。
1.削减您的交易数据库和网络的开销
有了 CDC，就有可能将数据变化作为一个连续的流来交付，而不会给源数据库系统带来不必要的开销。这意味着数据库可以专注于完成其设计的更有价值的任务，从而为应用程序带来更高的吞吐量和更低的延迟。有了CDC，只有增量数据变化在网络上传输，降低了数据传输成本，最大限度地减少了网络饱和度，并消除了微调系统以处理峰值批处理流量的需要。
2.保持交易型数据库和分析型数据库的同步
随着数据以令人眼花缭乱的速度产生，从数据中提取洞察力是一个组织成功的关键。CDC从交易型数据库捕捉实时数据变化，并定期将这些数据传送到分析型数据库或仓库，在那里可以对它们进行分析以提取更深入的见解。例如，想象你是一家在线旅游公司。你可以在数据库层捕获实时的在线预订活动（比方说使用PostgreSQL），并将这些交易发送到你的分析数据库，以了解更多关于你的客户的购买模式和偏好。
3.将数据从遗留系统迁移到下一代数据平台
随着向基于云的数据库实例现代化的转变，将数据转移到这些较新的平台变得比以往更加关键。有了CDC，数据会定期同步，使你能够按照自己的节奏实现数据平台的现代化，同时在这期间保持你的传统和下一代数据平台。这种设置确保了灵活性，并能保持业务运作而不遗漏任何心跳。
4.为应用程序预热一个动态数据缓存
缓存是提高应用程序性能的标准技术，但数据缓存必须经过预热（或加载数据），才能发挥其作用。有了暖和的数据缓存，应用程序可以绕过核心数据库快速访问数据。例如，这种模式对于一个做很多数据查询的应用来说是非常有利的，因为在缓存中加载这些查询数据可以从核心数据库中卸载读取的工作量。使用CDC，数据缓存可以一直动态地更新。例如，在最初的预热周期中，数据库中的选择性查询表可以被加载到缓存中。今后查询表数据的任何修改都会被增量传播，以更新缓冲区。
有哪些CDC的实现，你应该选择什么数据库？
CDC已经存在了相当长的一段时间，多年来，在其他产品中出现了几种不同的广泛使用的实现。然而，并不是所有的CDC实现都是一样的，你需要挑选合适的实现来清楚地了解数据的变化。我在下面的列表中总结了其中的一些实现方式以及使用每一种实现方式的挑战。
修改日期
这种方法跟踪表中每一行的元数据，包括谁创建了该行，谁最近修改了该行，以及该行是何时创建和修改的。
面临的挑战。
- 不容易跟踪数据的删除，因为对于被删除的行，date_modified字段已经不存在了。
- 需要额外的计算资源来处理date_modified字段。如果在日期修改字段上使用索引，索引将需要额外的计算和存储资源。
二进制差异
这个实现计算了当前数据和之前数据之间的状态差异。
面临的挑战。
- 计算状态差异可能很复杂，当数据量很大时，不能很好地扩展。
- 需要额外的计算资源，不能实时完成。
数据库触发器
这种方法需要创建数据库触发器，用逻辑来管理同一表中的元数据，或在一个单独的记账表中。
面临的挑战。
- 触发器必须为每一个事务开火，这可能会减慢事务性的工作负荷。
- 数据工程师必须编写额外的复杂的回滚逻辑来处理交易失败的情况。
- 如果表的模式被修改，触发器必须根据最新的模式变化手动更新。
- 不同数据库系统之间的SQL语言差异意味着触发器不容易移植，可能需要重新编写。
基于日志的
这种实现方式直接从数据库的日志和日记文件中读取数据，以尽量减少捕获过程的影响。由于数据库日志和日志文件存在于每一个事务性数据库产品中，所以这种体验是透明的。这意味着它不需要在数据库对象或运行在数据库之上的应用程序方面进行任何逻辑上的改变。
挑战。
- 如果目标数据库系统发生故障，源数据库系统的日志将需要保持完整，直到同步发生。
- 绕过日志文件的数据库操作将不会被捕获。这是大多数关系型数据库使用案例的一个角落，因为需要日志来保证ACID行为。
- 例如，TRUNCATE表语句可能不会记录数据，在这种情况下，可能需要通过查询提示或配置强制记录。
当涉及到生产数据库时，选择是明确的：基于日志的CDC是前进的方向，因为它的可靠性，在大量数据下的扩展能力，以及易于使用而不需要任何数据库或应用程序的变化。
总结
我希望这篇文章对解释为什么基于日志的数据库CDC复制很重要，以及为你提供的新的开源选项很有用。这些选项提供了无尽的复制可能性，就像Airbyte让基于日志的CDC复制变得更加容易一样。
