从广泛意义上说,全球许多企业每天都需要通过频繁的数据批量处理与加载,来定期将数据从一个数据库迁移到另一个数据库(或数据仓库)。这类定期批量加载的工作,往往既耗费时间,又会消耗原始系统的大量处理能力。因此,管理员只能在业务运行的间歇期间运行数据的批量传输与复制作业,否则会产生严重的效率影响。而显然,这与24x7的不间断业务需求是背道而驰的。
近年来,变更数据捕获(Change Data Capture,CDC)已成为了在高速数据流通环境中,各种关系型数据库、云端数据库、以及数据仓库之间,进行低延迟、高可靠性且可扩展式数据复制的理想化解决方案。
什么是变更数据捕获?
CDC是指从源数据库捕获到数据和数据结构(也称为模式)的增量变更,近乎实时地将这些变更,传播到其他数据库或应用程序之处。通过这种方式,CDC能够向数据仓库提供高效、低延迟的数据传输,以便信息被及时转换并交付给专供分析的应用程序。
在数据不断变化,且无法中断与在线数据库连接的情况下,对于各种时间敏感(time-sensitive)类信息的复制,往往也是云端迁移的重要组成部分。与批量复制相比,变更数据的捕获通常具有如下三项基本优势:
CDC通过仅发送增量的变更,来降低通过网络传输数据的成本。CDC可以帮助用户根据最新的数据做出更快、更准确的决策。例如,CDC会将事务直接传输到专供分析的应用上。CDC最大限度地减少了对于生产环境网络流量的干扰。
变更数据捕获的方法
目前,业界有多种CDC方法,可用于跟踪和传输变更的数据,您可以根据应用程序的实际要求,及其对于性能下降的容忍度,从中进行选取。下面,我将向您介绍四种不同的CDC方法所涉及到的技术、工作原理、以及它们各自的优缺点。
时间戳或版本号跟踪(Delete 操作不友好)
数据库设计者可以在需要跟踪的数据表中,设定某一列来代表最后被修改的时间戳或版本号。例如,我们通常可以将这些列命名为:LAST_UPDATE、DATE_MODIFIED、以及VERSION_NUMBER等。那些在上一次数据捕获之后,增加了时间戳的任何行,都将被视为发生了修改。而在基于版本号的跟踪方法中,变更一旦发生,所有具有最新版本号的数据,都被视为发生了修改。
在实际应用中,您可以结合版本和时间戳两个维度,来跟踪数据库表中的数据。例如,您可以设定一条逻辑--“捕获自6月22日以来,相对于3.4版发生了变更的所有数据”。
优点:
简单易懂。数据库设计者可以自定义应用程序的逻辑构建。不需要任何外部的工具。缺点:
给数据库增加了额外的开销。需要额外的CPU资源,来扫描表中的数据变更,并需要预留资源,以确保 LAST_UPDATE列能够可靠地追踪所有资源表。被删除的行不会存在于LAST_UPDATE中。如果没有其他脚本来跟踪此类删除的话,DML语句(例如“DELETE”)将不会被传递到目标数据库处。容易出错,并可能导致数据出现一致性问题。表的差异与增量(大数据量不友好)
这种CDC方法使用诸如:表增量(table delta)之类的实用程序,或tablediff,去比较两个表中的数据,以发现不匹配的行。据此,您可以使用其他的脚本,将源表的差异同步到目标表上。
虽然该方法在管理已删除行的方面,比时间戳CDC的效果更好,但是它在发现差异时,所需要的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产品和DBConvert Studio都会使用基于触发器的数据库同步CDC方法。不过,对于集群数据库而言,基于触发器的方法可能会比使用MySQL的二进制日志、或PostgreSQL的事务日志,要相差许多。毕竟,MySQL在其官网上已声称:“在启用二进制日志的情况下,服务器的运行性能可能会被略微拖慢。但是,二进制日志在方便复制与恢复操作等方面的好处,通常超过性能上的微降。”(/doc/refman/8.0/en/binary-log.html)
小结
综上所述,CDC是现代数据架构的重要组成部分,可被用于将事务数据从源系统,传输到数据流中。我们需要它支持实时的事务数据,且不会对源系统造成重大的负载。它既不需要改变源应用程序,又要保证仅传输最少量的数据。因此,CDC更适合大体量的数据集。将来,我们会在那些强调数据分析和历史数据比较的企业级数据仓库中,看到CDC的广泛使用。
参考:
CDC是个啥,它是如何工作的?-