CDC数据复制：技术、权衡、见解
CDC数据复制：技术、权衡、见解' can be condensed to 'CDC数据复制
许多不同行业的组织都在操作生产数据库，其中大部分数据变化并不频繁；也就是说，每天的变化和更新只占存储在其中的数据总量的一小部分。正是这些组织可以从变更数据捕获（CDC）数据复制中获益最多。
本文中，我将定义CDC数据复制，简要讨论最常见的使用案例，然后讨论常见的技术和各种权衡。最后，我将提供一些我作为数据集成公司Dataddo的首席执行官和创始人所学到的一些实现见解。
什么是变更数据捕获（CDC）数据复制？
CDC数据复制是一种在两个数据库之间实时或准实时地复制数据的方法，只复制新增或修改的数据。
这是替代快照复制的一种方法，快照复制涉及将一个数据库的整个快照多次移动到另一个数据库。快照复制适用于需要随时间保存各个快照的组织，但它需要很多处理资源，并且占用大量财务资源。对于不需要这样做的组织来说，CDC可以节省大量的付费处理时间。
数据的更改可以实时捕获并传递到其新目标，也可以批量传递（例如每小时传递一次）。
值得一提的是，CDC并不是一个新的过程。然而，直到最近，只有大型组织才有工程资源来实施它。新的是越来越多的托管工具可以以较低的成本实现CDC，因此它才变得越来越受欢迎。
最常见的CDC使用案例
本文空间有限，无法涵盖CDC数据复制的所有使用案例，但以下是最常见的三种。
用于商业智能和分析的数据仓库
任何运行专有数据收集系统的组织都可能拥有一个存储来自该系统的关键信息的生产数据库。
由于生产数据库设计用于写操作，它们并不会将数据用于盈利。因此，许多组织希望将数据复制到数据仓库中，以便进行复杂的读取操作，用于分析和商业智能。
如果您的分析团队需要准实时数据，CDC是将数据迅速传递给他们的一种好方法，因为它会在更改时快速将更改传递到分析仓库中。
数据库迁移
在从一种数据库技术迁移到另一种数据库技术时，如果您需要在停机时间发生时保持所有数据可用，CDC也非常有用。一个经典的例子是从本地数据库迁移到云数据库。
灾难恢复
与迁移情况类似，CDC是一种高效且潜在具有成本效益的方式，可确保您的所有数据始终在多个物理位置可用，以防其中一个位置发生停机。
常见的CDC技术及其各自的权衡
有三种主要的CDC技术，每种技术都有其自身的优势和劣势。
基于查询的CDC
基于查询的CDC非常简单。您只需使用这种技术编写一个简单的选择查询来选择特定表中的数据，然后加上一些条件，例如“仅选择昨天更新或添加的数据”。假设您已经配置了次要表的架构，那么这些查询将获取这些更改的数据，并生成一个新的二维表格，该表格可以插入到新位置。
优势
- 高度灵活。允许您定义要捕获的更改以及如何捕获它们。这使得可以以非常精细的方式自定义复制过程。
- 降低开销。仅捕获满足特定条件的更改，因此比捕获数据库中的所有更改的CDC要便宜得多。
- 更容易进行故障排除。可以轻松检查和纠正各个查询中的问题。
劣势
- 复杂的维护。每个查询都必须进行维护。例如，如果数据库中有几百张表，那么您可能需要相同数量的查询，并且维护它们将是一场噩梦。这是主要的劣势。
- 较高的延迟。依赖轮询更改，这可能会导致复制过程中的延迟。这意味着无法使用选择查询实现实时复制，并且需要安排某种批处理。如果需要使用长时间序列（如客户行为）分析某些内容，这可能不是一个大问题。
基于日志的CDC
我们今天使用的大多数数据库技术都支持集群化，意味着可以在多个副本中运行它们以实现高可用性。这类技术必须具备某种二进制日志，用于捕获数据库的所有更改。在基于日志的CDC中，更改是从日志而不是数据库本身中读取的，然后复制到目标系统。
优势
- 低延迟。数据更改可以非常快速地复制到下游系统。
- 高度准确。日志捕获数据库的所有更改，包括数据定义语言（DDL）和数据操作语言（DML）更改。这使得可以跟踪删除的行（在基于查询的CDC中不可能）。
劣势
- 较高的安全风险。需要直接访问数据库事务日志。这可能会引起安全问题，因为它将需要广泛的访问级别。
- 灵活性有限。捕获数据库的所有更改，这限制了定义更改和自定义复制过程的灵活性。在需要高度自定义的情况下，日志将需要进行大量的后处理。
总的来说，基于日志的CDC很难实现。有关更多信息，请参见下面的“洞察”部分。
基于触发器的CDC
基于触发器的CDC是第一种和第二种技术之间的一种混合形式。它涉及为捕获表中的某些更改定义触发器，然后将这些更改插入和跟踪到一个新表中。从这个新表中，更改被复制到目标系统。
优势
- 灵活性。允许您定义要捕获的更改以及如何捕获它们（与基于查询的CDC中一样），包括删除的行（与基于日志的CDC中一样）。
- 低延迟。每次触发器触发时，它都被视为一个事件，事件可以实时或准实时处理。
劣势
- 极其复杂的维护。与基于查询的CDC中的查询一样，所有触发器都需要进行个别维护。因此，如果您有一个包含200张表的数据库，并且需要捕获所有表的更改，那么您的整体维护成本将非常高。
实施见解
作为一家数据集成公司的首席执行官，我在大规模和小规模上实施CDC方面有很多经验。以下是我在这个过程中学到的一些经验。
不同日志的不同实现
基于日志的CDC特别复杂。这是因为所有的日志（例如，MySQL的BinLog，Postgres的WAL，Oracle的Redo Log，Mongo DB的Oplog）虽然在概念上是相同的，但实现方式不同。因此，您需要深入研究您选择的数据库的底层参数，以使其正常工作。
将数据更改写入目标位置
您需要确定如何在目标位置插入、更新和删除数据。
一般来说，插入很容易，但数据量对决定使用哪种方法起着重要作用。无论您使用批量插入、数据流式传输，还是决定使用文件加载更改，您总是会面临技术权衡。
为了确保正确更新并避免不必要的重复，您需要在表上定义一个虚拟键，告诉系统应该插入什么和应该更新什么。
为了确保正确删除，您需要有一些容错机制，以确保糟糕的实现不会导致目标表中的所有数据被删除。
维护长时间运行的作业
如果您只传输几行数据，那么事情会变得很容易，但如果是这种情况，那么您可能不需要CDC。因此，通常情况下，我们可以预计CDC作业将需要几分钟甚至几小时，并且这将需要可靠的监控和维护机制。
错误处理
这可能是另一篇独立文章的主题。但简而言之，我可以说每种技术都有不同的方式来引发异常和显示错误。因此，您应该为连接失败时该怎么办制定策略。您应该重试吗？您应该将所有内容封装在事务中吗？
在内部实施CDC数据复制非常复杂且非常特定于情况。这就是为什么它在传统上不是一个流行的复制解决方案，也是为什么很难给出关于如何实施它的一般建议。近年来，像Dataddo、Informatica、SAP Replication Server等托管工具显著降低了可访问性门槛。
并非适用于所有情况，但对某些情况非常好
正如我在本文开头提到的，CDC有潜力为公司节省大量财务资源：
- 其主要数据库主要由不经常更改的数据组成（即每天只有相对较小部分的数据发生更改）的公司
- 其分析团队需要几乎实时的数据的公司
- 不需要随时间保留其主要数据库的完整快照的公司
然而，没有完美的技术解决方案，只有权衡。CDC数据复制也是如此。选择实施CDC的人将不得不不均衡地优先考虑灵活性、准确性、延迟、维护和安全性。Petr Nemeth是Dataddo的创始人兼首席执行官，Dataddo是一个完全托管的、无代码的数据集成平台，连接云服务、仪表板应用程序、数据仓库和数据湖。该平台提供ETL、ELT、反向ETL和数据库复制功能（包括CDC），以及200多个连接器的广泛组合，使任何技术水平的业务专业人士能够将数据从几乎任何来源发送到任何目标位置。在创立Dataddo之前，Petr曾在电信、IT和媒体公司担任开发人员、分析师和系统架构师，参与大规模的物联网、大数据和商业智能项目。
