CN106339274A

CN106339274A - 一种数据快照获取的方法及系统

Info

Publication number: CN106339274A
Application number: CN201510413154.8A
Authority: CN
Inventors: 邓小勇
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2015-07-14
Filing date: 2015-07-14
Publication date: 2017-01-18
Anticipated expiration: 2035-07-14
Also published as: WO2017008657A1; CN106339274B; US20180137134A1

Abstract

本申请实施例提供了一种数据快照获取的方法及系统，其中所述方法包括：基于源端中记录的始于指定位置的重做日志redolog文件，获取对应的变更数据记录；将所述变更数据记录加载到对应的目的端；在所述目的端中，当到达预设的指定时间时，依据所述变更数据记录获取所述指定时间对应的第一数据快照，本申请可以精确获得指定时间的数据快照。

Description

一种数据快照获取的方法及系统

技术领域

本申请涉及数据存储技术领域，特别是涉及一种数据快照获取的方法，以及一种数据快照获取的系统。

背景技术

随着企业信息化建设的发展，越来越多的企业建立了众多的信息系统，以帮助企业进行内外部业务的处理和管理工作。但是随着信息系统的增加，各自孤立工作的信息系统造成了大量的冗余数据和业务人员的重复劳动。企业应用集成(EAI，Enterprise Application Integration)应运而生，而ETL是实现数据集成的主要技术。

ETL，Extraction-Transformation-Loading的缩写，即数据抽取(Extract)、转换(Transform)、加载(Load)的过程，它是构建数据仓库的重要环节。ETL是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据。

现有技术中，常用的数据抽取手段是离线抽取，离线抽取主要是根据源端提供的数据接口遍历全部数据从而抽取出想要的数据，传统的源端抽取(比如select)就属于离线抽取。由于离线抽取是直接对源数据当时状态的遍历，故不需要数据计算就能直接得到数据快照。

然而，发明人在实践中发现离线抽取存在以下不足：

(1)无法指定快照时间点：离线抽取的执行时间是近似时间(或者是指定时间之后的时间)，无法拿到指定时间点上的快照；

(2)不是精准快照：在有分库分表等分布式场景下，由于分布式调度无法做到所有执行点同时调度，故快照中的数据状态时间点不一致；

(3)不够快速：由于离线抽取需要遍历整个源端数据集，特别是在获取总基数大而增量小的数据快照时，投入产出比相当低；

(4)影响在线生产：由于离线抽取通过源端接口抽取数据，而在线生产和离线抽取都在调用这个数据出入口，可能导致在线生产延迟响应甚至崩溃。

因此，目前需要本领域技术人员迫切解决的一个技术问题就是：如何提出一种数据快照获取方案，用以精确获得指定时间的数据快照。

发明内容

本申请实施例所要解决的技术问题是提供一种数据快照获取的方法，用以精确获得指定时间的数据快照。

相应的，本申请实施例还提供了一种数据快照获取的系统，用以保证上述方法的实现及应用。

为了解决上述问题，本申请实施例公开了一种数据快照获取的方法，所述的方法包括：

基于源端中记录的始于指定位置的重做日志redolog文件，获取对应的变更数据记录；

将所述变更数据记录加载到对应的目的端；

在所述目的端中，当到达预设的指定时间时，依据所述变更数据记录获取所述指定时间对应的第一数据快照。

优选地，所述方法还包括：

若所述指定位置具有对应的在先已获取的第二数据快照，则将所述第一数据快照与所述第二数据快照组织成所述指定时间的第三数据快照。

优选地，所述方法还包括：

在将所述变更数据记录加载到所述目的端时，按需为所述变更数据记录添加标签信息。

优选地，所述变更数据记录包括主键标识，所述在所述目的端中，当到达预设的指定时间时，依据所述变更数据记录获取所述指定时间对应的第一数据快照的步骤包括：

在目的端中检测所述标签信息，判断是否到达所述指定时间；

若到达所述指定时间，针对每个主键标识的变更数据记录进行倒排序；

获得各个主键标识排序在首位的数据记录，作为所述主键标识的第一数据快照。

优选地，所述变更数据记录还包括数据编号，所述若到达所述指定时间，针对每个主键标识的变更数据记录进行倒排序的步骤为：

若到达所述指定时间，针对每个主键标识的变更数据记录，按照所述数据编号进行倒排序。

优选地，所述将所述变更数据记录加载到目的端的步骤包括：

由预置的发布程序将所述变更数据记录发布至预置的订阅程序，其中，所述订阅程序为向所述发布程序订阅所述变更数据记录的程序；

由所述订阅程序将所述变更数据记录转换成所述目的端所需的数据格式；

由所述订阅程序将所述转换数据格式后的变更数据记录，加载到对应的目的端的数据表中。

优选地，所述变更数据记录包括源端变更时间戳，所述由所述订阅程序将所述转换数据格式后的变更数据记录加载到对应的目的端的数据表中的步骤包括：

由所述订阅程序按照每条变更数据记录的源端变更时间戳，确定所述变更数据记录所属的存储分区，所述存储分区包括存储分区标识；

将所述变更数据记录写入对应的存储分区中，并将所述存储分区对应的标识写入所述数据表中与所述变更数据记录对应的位置。

优选地，所述方法还包括：

存储预设时间段内的变更数据记录。

优选地，所述源端为多个，所述根据源端中记录的重做日志redolog文件，获取变更数据记录的步骤包括：

分别将多个源端中记录的，始于指定位置的redolog文件集中采集到所述发布程序中，由所述发布程序解析所述redolog文件，获得对应的变更数据记录。

优选地，所述第一数据快照包括第一主键标识、变更类型以及第一数值信息，所述第二数据快照包括第二主键标识及第二数值信息，所述将所述第一数据快照与所述第二数据快照组织成所述指定时间的第三数据快照的步骤包括：

按照所述第一主键标识和/或所述第二主键标识，合并所述第一数据快照以及所述第二数据快照；

若所述第一主键标识为空，则将所述第二主键标识及所述第二数值信息组织成第三数据快照；

若所述第一主键标识不为空，则将所述第一主键标识及所述第一数值信息组织成第三数据快照。

本申请实施例还公开了一种数据快照获取的系统，所述的系统包括：

数据记录获取模块，用于基于源端中记录的始于指定位置的重做日志redolog文件，获取对应的变更数据记录；

数据加载模块，用于将所述变更数据记录加载到对应的目的端；

快照获取模块，用于在所述目的端中，当到达预设的指定时间时，依据所述变更数据记录获取所述指定时间对应的第一数据快照。

优选地，所述系统还包括：

合并模块，用于在所述指定位置具有对应的在先已获取的第二数据快照时，将所述第一数据快照与所述第二数据快照组织成所述指定时间的第三数据快照。

优选地，所述系统还包括：

标签添加模块，用于在将所述变更数据记录加载到所述目的端时，按需为所述变更数据记录添加标签信息。

优选地，所述变更数据记录包括主键标识，所述快照获取模块包括：

判断子模块，用于在目的端中检测所述标签信息，判断是否到达所述指定时间；

排序子模块，用于在到达所述指定时间时，针对每个主键标识的变更数据记录进行倒排序；

快照获得子模块，用于获得各个主键标识排序在首位的数据记录，作为所述主键标识的第一数据快照。

优选地，所述变更数据记录还包括数据编号，所述排序子模块还用于：

优选地，所述数据加载模块包括：

发布子模块，用于由预置的发布程序将所述变更数据记录发布至预置的订阅程序，其中，所述订阅程序为向所述发布程序订阅所述变更数据记录的程序；

格式转换子模块，用于由所述订阅程序将所述变更数据记录转换成所述目的端所需的数据格式；

加载子模块，用于由所述订阅程序将所述转换数据格式后的变更数据记录，加载到对应的目的端的数据表中。

优选地，所述变更数据记录包括源端变更时间戳，所述格式转换子模块包括：

分区确定单元，用于由所述订阅程序按照每条变更数据记录的源端变更时间戳，确定所述变更数据记录所属的存储分区，所述存储分区包括存储分区标识；

写入单元，用于将所述变更数据记录写入对应的存储分区中，并将所述存储分区对应的标识写入所述数据表中与所述变更数据记录对应的位置。

优选地，所述系统还包括：

存储模块，用于存储预设时间段内的变更数据记录。

优选地，所述源端为多个，所述数据记录获取模块包括：

采集子模块，用于分别将多个源端中记录的，始于指定位置的redolog文件集中采集到所述发布程序中由所述发布程序解析所述redolog文件，获得对应的变更数据记录。

优选地，所述第一数据快照包括第一主键标识、变更类型以及第一数值信息，所述第二数据快照包括第二主键标识及第二数值信息，所述合并模块包括：

合并子模块，用于按照所述第一主键标识和/或所述第二主键标识，合并所述第一数据快照以及所述第二数据快照；

第一组织子模块，用于在所述第一主键标识为空时，将所述第二主键标识及所述第二数值信息组织成第三数据快照；

第二组织子模块，用于在所述第一主键标识不为空时，将所述第一主键标识及所述第一数值信息组织成第三数据快照。

与背景技术相比，本申请实施例包括以下优点：

a.指定任意快照时间点：本申请实施例通过redolog文件拿到的变更流水，能够做到同key数据按时间倒排序，经过计算，就能得到任意时间点上的数据快照；

b.精准快照：即使在分布式情况下(忽略分布式各主机的时钟差异)，只要从redolog中获取了变更数据时间点，就能得到时间点一致的数据快照；

c.快速获取：本申请实施例通过redolog文件获得变更数据记录，不用遍历整个数据集，故ETL速度很快；

d.隔离生产：本申请实施例通过读取redolog文件，不是走源端数据出入接口，故对在线生产影响小甚至没有影响；

e.通用：本申请实施例对于有redolog文件的存储系统可以通用，只要能从redolog中获取变更流水，就能达到以上所有技术效果。

附图说明

图1是本申请的一种数据快照获取的方法实施例一的步骤流程图；

图2是本申请的一种数据快照获取的方法实施例一中的增量合并代码示意图；

图3是本申请的一种数据快照获取的方法实施例二的步骤流程图；

图4是本申请的一种数据快照获取的方法实施例二中的全量合并代码示意图；

图5是本申请一种数据快照获取的系统实施例的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

参照图1，示出了本申请的一种数据快照获取的方法实施例一的步骤流程图，可以包括如下步骤：

步骤101，基于源端中记录的始于指定位置的重做日志redolog文件，获取对应的变更数据记录；

本申请实施例可以应用于ETL系统中，在数据抽取阶段，本申请可以基于源端中记录的重做日志redolog文件来获得变更数据记录。

在具体实现中，源端的存储系统(比如mysql、oralce、hbase等)中存储着结构化数据(即行数据)，该结构化数据为存储系统中用二维表逻辑结构表达的数据，这些数据在存储系统中一般具有redolog文件。其中，redolog文件是指结构化存储将自身数据的变更过程记录到日志中，具体来说，数据库系统每执行一个更新操作时，都会引起数据库的变化，因此都会生成一定数量的重做日志，它们将被记录到重做日志文件redolog文件中，以便在数据库出现例程失败或介质故障时，可以利用重做日志文件来恢复数据库，本申请实施例中采用redolog文件来获取源端中的数据变更流水。

本申请实施例可以应用于分布式环境中，则源端可以有多个，在本申请实施例的一种优选实施例中，步骤101具体可以为：

子步骤S11，分别将多个源端中记录的，始于指定位置的redolog文件集中采集到预设的发布程序中，由所述发布程序解析所述redolog文件，获得对应的变更数据记录。

在一种实施方式中，多个源端中的redolog文件可以集中采集到预置的发布程序中，由该发布程序进行redolog文件的解析，而无需在redolog文件所在的源端中进行数据解析，从而与该源端形成良好的隔离，节省了源端的资源消耗。

在具体实现中，在进行集中采集时，对于不同的源端，可以采用不同的采集方式，例如，对于mysql可以通过主从复制二进制日志binlog进行采集；没有现成redolog复制方案的源端可以直接通过拷贝文件的方式实现，比如rsync(类unix系统下的数据镜像备份工具)等等。

为了避免redolog文件的重复采集，在前一次的redolog文件采集完毕以后，可以对采集截止的位置进行标记，该标记位置或标记位置之后的一个单位数据的位置可以作为指定位置，则下一次采集时，从指定位置开始进行采集。在具体实现中，可以基于时间参数进行标记，例如，前一次采集到2015年4月20日8时的redolog文件，则在2015年4月20日8时处进行标记，则指定位置可以为2015年4月20日8时；或者，也可以基于文件编号参数进行标记，例如，前一次采集到的redolog文件编号为4，则在编号为“4”处进行标记，则指定位置可以为编号为“4”的位置的下一位置，例如，编号为“5”的位置。当然，还可以以其他方式确定指定位置，本申请实施例对此无需加以限制。

采集redolog文件以后，发布程序进一步将该redolog文件解析成可识别的数据格式，得到对应的变更数据记录record。在实际中，一个数据库的变更可以不断追加到redolog文件中，也即redolog记录了数据变更流水，redolog经过解析后，就能得到相应的变更流水record。

其中，可识别的格式可以为excel的行列格式(一行记录是一条record，不同列有不同含义)，也可以是json格式(一个json是一条record，内部不同key有不同含义)，也可以是一个程序对象，对象里面包含了record，还可以是protobuf、avro等等其他序列化格式。

在具体实现中，对于不同的源端的redolog文件，本申请也可以采用不同的解析方式，比如oracle的logminer，mysql的mysqlbinlog等。

在本申请实施例中，解析后得到的变更数据记录record和源端的redolog文件中记录的数据并不完全相同，源端中的数据仅是各具体的数据字段，而record可以包含元信息和数值信息两部分。元信息可以包括主键标识、变更类型(例如，插入INSERT、更新UPDATE、删除DELETE等，对于DELETE的变更，至少要给出变更的主键标识)、源端库名、源端表名、源端变更时间戳等等；数值信息可以记录在List<Field>中，每个Field对象也有自己的元信息，比如：数据类型(INT、FLOAT、DOUBLE、STRING、DATE、BLOB等)、Field名、Field编码、具体Field值，等等。

需要说明的是，本申请实施例并不限于上述的集中式采集方式，本领域技术人员也可以按分库分表位置对redolog文件进行单独处理，即在源端本地进行redolog文件的解析，这样做的好处是节省了redolog文件的在线传输(无需将redolog文件传送至发布程序中)，但这种方式会消耗各个源端的各种资源(比如CPU、内存、网络等资源)，从而会影响在线服务。

应用于本申请实施例，在获得变更数据记录以后，本申请实施例还可以存储预设时间段内的变更数据记录。具体来说，在本实施例的系统运行过程中，可能出现用户逻辑出错或丢失数据或系统宕机等异常情况，而实时数据流又是不断向前推移的，则异常情况出现以后需要在异常恢复之后把整个流水位点回退到一个安全时间点(预设时间段)上，重新拉取流水数据(可认为是一个补数据的过程)。如果在解析后缓存了该预设时间段内的流水数据(即变更数据记录)，那么就可以直接从这部分缓存流水数据中拖取变更数据记录(当然能够回退的时间位点需要在缓存的时间范围内)，而不用从源端再重复拖取redolog文件后解析。

需要说明的是，由于本申请实施例是对redolog文件的解析，所以解析出来的同主键key的变更数据记录是按实际变更顺序排列的，即同key数据是保序的。对于异key数据或分库分表数据，本申请仅是对其两者之间(两个key之间或两个表之间或两个库之间)时间差不要过大作要求，故对于一些需要数据事务性等场景(数据事务性的场景可以指一批数据操作要么都成功，要么都失败。比如银行需要将某一批账号(比如10个账号)都增加100元，那么数据事务性场景是这次操作需要保证10个账号全部都增加100元；否则全部都没增加，而不能一部分增加了，一部分没增加，否则很难查出谁增加成功了，谁失败了，给接下来的操作带来不便。)均不要求。

本申请实施例在数据抽取阶段，通过抽取redolog文件来获取变更数据记录，能够做到同key数据按时间排序，不用遍历整个数据集，大大提升了ETL速度，并且，能够获取任意指定时间的数据快照(对于任意指定时间，下文将对其进行说明)。

步骤102，将所述变更数据记录加载到对应的目的端；

由于本申请实施例应用于分布式环境中，则目的端也可以有多个，在获取变更数据记录以后，可以将该变更数据记录加载(load)到对应的目的端中。

在本申请实施例的一种优选实施例中，步骤102可以包括如下子步骤：

子步骤S21，由预置的发布程序将所述变更数据记录发布至预置的订阅程序，其中，所述订阅程序为向所述发布程序订阅所述变更数据记录的程序；

为了系统间的轻耦合，本申请实施例除了设置有发布程序，还设置有订阅程序，其中，发布程序专注于把redolog文件进行解析和发布，并不关注发布后的数据的流向和用途；而订阅程序用于把发布程序发布的数据订阅出来，加载到目的端；本申请实施例通过两个不同的程序完成解析及加载的操作，实现了系统间的轻耦合，由于分布式环境下的数据量太大，考虑到订阅程序的性能，可以由多个订阅程序处理发布程序发布的变更数据记录，例如，10个订阅程序订阅消费同一批数据，则每个订阅程序可以负责1/10的数据量。

在具体实现中，如果某个源端长时间确实没有发生变更操作，那么订阅程序就难以判断究竟是没有新的数据到达还是解析及发布过程出了问题，此时，发布程序可以不断向订阅程序发出心跳(比如1次/秒)来确保数据时间的前移。

子步骤S22，由所述订阅程序将所述变更数据记录转换成所述目的端所需的数据格式；

订阅程序获得变更数据记录以后，可以将该变更数据记录转换成目的端所需的数据格式，该格式数据是从源端获取并写入目的端的用于计算的纽带，具体可以包括元信息的格式转换以及数值信息的格式转换。

在一种实施方式中，可以将变更数据记录转换成下表1的格式形式：

表1

在上表1中：

多位循环同步序号：即该条变更数据记录的数据编号，该字段数据长度是等长的，同步序号循环分配(同步序号的位数取决于源端变更时间戳的粒度和该粒度内源端单表变更数目的最大值，例如，源端变更时间戳的粒度是1秒，那么假设一张表在1秒的变更数目的最大值是5w次，即最多变更5w次，那么同步序号的位数可以是5位及以上，例如00001，就是说用5位及以上位数能够表示的下1秒内的变更，由于下1秒的源端变更时间戳已经和上1秒的数据不同了，这时又可以循环使用这多位同步序号)，该字段是目的端同key数据的排序字段；

源端变更时间戳：源端数据变更的真实时间，其作用是决定该条变更数据记录写入目的端所属的存储区间，排序字段采用上述多位循环同步序号，而不采用该字段的原因是，解析出来的这个变更时间的精度可能较大，比如即使到了微秒，源端同key数据在一微秒内也可能有多条变更而无法区别先后顺序；

源端库名、源端表名：标注源端数据的真实来源，便于数据分析和问题定位；

变更类型：主要包括从前述解析出的INSERT、UPDATE和DELETE；

Field数值：解析得到的具体的数值信息，此处可能进行了编码转换或者类型转换，但要保证数值的高保真或不失真。

在实际中，变更数据记录写入上表1时，可以按行列的方式写入；也可以是一整行但内建行列分隔(行列分隔符需设置特殊字符，当数据中出现的行列分隔符时需要进行行/列替换)；也可以是json、protobuffer等其他序列化格式，但基本元信息如上表1所述。

子步骤S23，由所述订阅程序将所述转换数据格式后的变更数据记录，加载到对应的目的端的数据表中。

订阅程序转换了变更数据记录的数据格式以后，可以将该转换格式后的变更数据记录加载到对应的目的端的数据表中。

在本申请实施例的一种优选实施例中，子步骤S23可以进一步包括如下子步骤：

子步骤S231，由所述订阅程序按照每条变更数据记录的源端变更时间戳，确定所述变更数据记录所属的存储分区；

由于在分布式环境中，需要处理的数据量都是庞大的，为了降低目的端的存储压力以及数据处理压力，本申请实施例划分出多个存储分区进行数据存储，每个存储分区可以存储一定时间范围的数据，例如，若每个存储分区可以存储1小时的数据，则可以将一天24小时划分成24个存储分区，第一个存储分区存储第00:00-01:00的数据，第二个存储分区存储第01:01-02:00的数据，第三个存储分区存储第02:01-03:00的数据，如此类推。

在确定每个存储分区所存储的时间段的数据以后，则可以根据每条变更数据记录的源端变更时间戳，确定该变更数据记录所属的存储分区，例如，当前变更数据记录的源端变更时间戳为01：30，则所属的存储分区为第二存储分区。

子步骤S232，将所述变更数据记录写入对应的存储分区中，并将所述存储分区对应的标识写入所述数据表中与所述变更数据记录对应的位置。

在确定变更数据记录所属的存储分区以后，订阅程序将该变更数据记录写入该存储分区中，例如，将源端变更时间戳为01：30的变更数据记录写入第二存储分区，并将该第二存储分区的标识写入目的端的数据表中。其中，存储分区的标识可以用数据编号标识，例如编号“1”、“2”等，也可以用该存储分区对应的时间段范围，即范围时间戳标识，如下表2所示，该范围时间戳可以使用诸如2014042009(存储2014年4月20日9时-10时的存储分区的标识)等表示。

表2

本申请实施例将存储分区的标识写入数据表中的目的是可以快速定位到数据所处的位置。

需要说明的是，存储分区的标识对于SQL类存储可以使用一个单独的标注范围字段表达，如表2所示的范围时间戳；对于NoSQL类存储可以使用分区来表达，例如，可以用类似于一个单独列来表达，但是在NoSQL中这个单独的列的字段属于元信息，而不是具体数值。

应用于本申请实施例，为了保证数据的完整性，在数据加载过程中，还可以包括如下步骤：

具体来说，在变更数据记录写入目的端的过程中，可以根据业务需求按时为变更数据记录添加标签信息(即对其打点)，比如每写入一小时的数据打一个点，或者在到达指定时间时进行打点，或根据存储分区的时间进行打点，则目的端可以根据打点情况来判断数据是否完整，以及是否到达指定时间。

需要说明的是，对于不同key的数据，从发布程序的处理到订阅程序的处理需要在一个时间范围(比如5分钟)内完成，以保证不同key的数据处理时间差异在合理范围内，避免后续计算时间延迟或数据不完整而导致数据丢失，例如，一条数据已经是凌晨0点了，但还有数据在晚上20：00，如果没有限定时间范围，那么凌晨0点就不能从全局上获取当前的变更情况了。

步骤103，在所述目的端中，当到达预设的指定时间时，依据所述变更数据记录获取所述指定时间对应的第一数据快照。

将变更数据记录加载到目的端以后，在目的端中，可以获取用户(例如，开发人员、数据分析人员等)指定时间对应的第一数据快照，其中，数据快照是指源端的存储系统中的数据在另一种或另一处存储系统(即目的端)中某一时刻的数据拷贝。

在本申请实施例的一种优选实施例中，步骤103可以包括如下子步骤：

子步骤S31，在目的端中检测所述标签信息，判断是否到达所述指定时间；

若打点是按照指定时间进行的打点，则在检测到打点时，说明该指定时间到达，在打点处的变更数据记录加载完整。

若打点是按照时间间隔进行的打点，例如一小时打一个点，若指定时间为04:00，从00:00开始，读到第四个打点说明指定时间到达，在第四个打点处的变更数据记录加载完整。

子步骤S32，若到达所述指定时间，针对每个主键标识的变更数据记录进行倒排序；

子步骤S33，获得各个主键标识排序在首位的数据记录，作为所述主键标识的第一数据快照。

在一种实施方式中，由于目的端同key数据的排序字段是多位循环同步序号，因此在到达指定时间时，针对每个主键标识的变更数据记录，可以按照多位循环同步序号，即数据编号进行排序。为了节约数据遍历时间，提高数据查找效率，本申请实施例优选的排序方式为倒排序，则排序在首位的数据记录为该主键标识最终状态的数据记录。在本申请实施例中，子步骤S32及子步骤S33的过程为增量合并的过程，则第一数据快照为对变更数据记录执行增量合并后得到的增量快照，其中，增量合并为指定变更流水的起止点T0(即本申请实施例中的指定位置)，按照变更的先后川页序联合相同key的数据(即对同key数据进行倒排序)，从而获取所有数据在截止时间点T1(即本申请实施例中的指定时间)的最终状态，把处于这个最终状态的数据叫做增量快照。

在具体实现中，第一数据快照的获取过程的伪SQL代码如图2的增量合并代码示意图所示，其中，第9行的含义是在数据范围(分区字段)选择所有数据，并将同主键的数据分发到一起后，按主键、源端变更时间戳、同步序号(即多位循环同步序号)进行倒排，得到临时表a，第11行的where条件表示选择第一条变更数据，最终插入到增量表的对应数据范围内，从而得到所有主键标识的在指定时间最晚值时刻的第一数据快照。

为了使本领域技术人员更好的理解本申请实施例，以下以临时表的形式对第一数据快照的获取过程进行示例性说明，但需要说明的是，下述表3及表4为临时表，在实际实现中不一定对其进行存储，本示例仅是一种过程解析示例，图2中的伪SQL代码就是直接处理了这些逻辑后而生成最终的第一数据快照：

第一步：根据业务要求选择指定位置至指定时间的时间范围的redolog文件，本示例选择的指定位置为2015-04-20 00：00：00，指定时间为2015-04-21 00：00：00，即选择时间范围为[2015-04-20 00：00：00，2015-04-21 00：00：00)的redolog文件，对其进行解析后，加载到目的端的变更数据记录如下表3所示；

变更序号	源端变更时间戳	源端库名	源端表名	变更类型	id(账号)	value(余额)	时间范围(按小时)
								00552	2015-04-20 09：30：00	cash_00	account_00	UPDATE	1111	10000	2015042009
00034	2015-04-20 09：40：00	cash_01	account_04	UPDATE	2222	5000	2015042009
								22222	2015-04-20 l4：30：00	cash_03	account_10	INSERT	3333	5000	2015042014
45678	2015-04-20 15：00：00	cash_00	account_00	UPDATE	1111	11000	2015042015
								02222	2015-04-20 15：10：00	cash_00	account_00	UPDATE	1111	12000	2015042015
02223	2015-07-20 15：10：00	cash_00	account_00	UPDATE	1111	11000	2015042015
								38762	2015-04-20 15：20：00	cash_01	account_04	DELETE	2222	删除	2015042015
00001	2015-04-20 16：10：00	cash_00	account_00	UPDATE	1111	7000	2015042016

表3

第二步：根据主键key标识对上述表3中的变更数据记录进行分组，针对每组同key的数据，按变更序号(即多位循环同步序号)进行倒排序，得到结果如下表4：

表4

第三步：获得每个主键标识中排序在首位的数据记录，即可得到2015-04-21 00：00：00时刻前的最终状态，即2015-04-21 00：00：00的第一数据快照，如下表5所示：

变更类型	id(账号)	value(余额)	时间范围(按小时)
				UPDATE	1111	7000	2015042016
DELETE	2222	删除	2015042015
				INSERT	3333	5000	2015042014

表5

需要说明的是，以上示例的时间范围仅是一天，即仅仅是取一天的数据快照，实际上该时间范围可以为更细粒度，比如小时级的精准快照，甚至可以获得分钟级别的精准快照。

采用本申请实施例，可以达到如下有益效果：

b.精准快照：即使在分布式情况下(忽略分布式各主机的时钟差异)，只要从redolog中获取了变更数据时间点，就能得到时间点一致的数据快照：

参照图3，示出了本申请的一种数据快照获取的方法实施例二的步骤流程图，可以包括如下步骤：

步骤301，基于源端中记录的始于指定位置的重做日志redolog文件，获取对应的变更数据记录；

在本申请实施例的一种优选实施例中，步骤301可以包括如下子步骤：

子步骤S41，分别将多个源端中记录的，始于指定位置的redolog文件集中采集到预设的发布程序中，由所述发布程序解析所述redolog文件，获得对应的变更数据记录。

在本申请实施例中，解析后得到的变更数据记录record和源端的redolog文件中记录的数据并不完全相同，源端中的数据仅是各具体的数据字段，而record可以包含元信息和数值信息两部分，元信息可以包括主键标识、变更类型、源端库名，源端表名、源端变更时间戳等等；数值信息可以记录在List<Field>中，每个Field对象也有自己的元信息，比如：数据类型(INT、FLOAT、DOUBLE、STRING、DATE、BLOB等)、Field名、Field编码、具体Field值，等等。

步骤302，将所述变更数据记录加载到对应的目的端；

由于本申请实施例应用于分布式环境中，则目的端也可以有多个，在获取变更数据记录以后，可以将该变更数据记录加载load到对应的目的端中。

在本申请实施例的一种优选实施例中，步骤302可以包括如下子步骤：

子步骤S51，由预置的发布程序将所述变更数据记录发布至预置的订阅程序，其中，所述订阅程序为向所述发布程序订阅所述变更数据记录的程序；

子步骤S52，由所述订阅程序将所述变更数据记录转换成所述目的端所需的数据格式；

子步骤S53，由所述订阅程序将所述转换数据格式后的变更数据记录，加载到对应的目的端的数据表中。

在本申请实施例的一种优选实施例中，子步骤S53可以进一步包括如下子步骤：

子步骤S531，由所述订阅程序按照每条变更数据记录的源端变更时间戳，确定所述变更数据记录所属的存储分区；

子步骤S532，将所述变更数据记录写入对应的存储分区中，并将所述存储分区对应的标识写入所述数据表中与所述变更数据记录对应的位置。

步骤303，在所述目的端中，当到达预设的指定时间时，依据所述变更数据记录获取所述指定时间对应的第一数据快照；

在本申请实施例的一种优选实施例中，步骤303可以包括如下子步骤：

子步骤S61，在目的端中检测所述标签信息，判断是否到达所述指定时间；

子步骤S62，若到达所述指定时间，针对每个主键标识的变更数据记录进行倒排序；

在本申请实施例的一种优选实施例中，子步骤S62具体可以为：若到达所述指定时间，针对每个主键标识的变更数据记录，按照所述数据编号进行倒排序。

子步骤S63，获得各个主键标识排序在首位的数据记录，作为所述主键标识的第一数据快照。

步骤304，若所述指定位置具有对应的在先已获取的第二数据快照，则将所述第一数据快照与所述第二数据快照组织成所述指定时间的第三数据快照。

在本申请实施例的一种优选实施例中，所述第一数据快照包括第一主键标识、变更类型及第一数值信息，所述第二数据快照包括第二主键标识及第二数值信息，步骤304可以包括如下子步骤：

子步骤S71，若所述指定位置具有对应的在先已获取的第二数据快照，则按照所述第一主键标识和/或所述第二主键标识，合并所述第一数据快照以及所述第二数据快照；

应用于本申请实施例，第二数据快照为该指定位置的全量快照，全量快照是对指定位置的数据进行全量合并的结果，全量合并是指将T0到T1时间段范围内的数据做增量合并后，再合并到T0时刻的全量快照上，从而得到T1时刻的全量快照，不断重复使用该方法，可以得到顺延各时间点的全量快照。因此，若指定位置为初始位置，则该指定位置不存在第二数据快照，否则，若指定位置不为初始位置，该指定位置存在第二数据快照。

参考图4所示的全量合并代码示意图，10-13行增量合并得到临时增量表incre，即得到指定时间的增量快照；第8行是获取上一业务点的全量值表total，即获得指定位置的第二数据快照；两者做拼接full outer join，join的条件是主键相等(第14行)，从而得到全增量的宽表(分别以total和incre打头，对于没有变更的数据其incre部分全部为null)。

子步骤S72，若所述第一主键标识为空，则将所述第二主键标识及所述第二数值信息组织成第三数据快照；

子步骤S73，若所述第一主键标识不为空，则将所述第一主键标识及所述第一数值信息组织成第三数据快照。

在数据过滤以后，单条数据是选择全量的数值信息还是增量的数值信息由图4的3-6行的if条件决定，如果增量的数值信息不存在则选择全量的数值信息字段值，否则选择增量的数值信息字段值，从而得到指定时间最晚值时刻所有数据的全量快照。

需要说明的是，第三数据快照的获取与第一数据快照的获取可以由同一个计算程序实现，即直接一步到位，用一个计算程序完成整个增全量的合并，但不会存储增量快照，图4中的伪代码即为该方式；也可以由两个不同的计算程序实现，即在得到第一数据快照之后再启动一个计算程序计算第三数据快照。

为了使本领域技术人员更好的理解本申请实施例，以下以临时表的形式对第三数据快照的获取过程进行示例性说明，但需要说明的是，下述表8及表9为临时表，在实际实现中不一定对其进行存储，本示例仅是一种过程解析示例，图4中的伪伪SQL代码就是直接处理了这些逻辑后而最终的第三数据快照：

第一步：根据增量合并拿到业务时间点(2015-04-20)的增量最终状态表(即第一数据快照)，如表6所示；

变更类型	id(帐号)	value(余额)	时间范围(按小时)
				UPDATE	1111	7000	2015042016
DELETE	2222	删除	2015042015
				INSERT	3333	5000	2015042014

表6

第二步：拿到前一天，即指定位置(2015-04-19)全量表，如表7所示；

id(账号)	value(余额)	时间范围
			1111	5000	20150419
2222	3000	20150419
			4444	6000	20150419

表7

第三步：将表6及表7做full outer join，join条件是根据key(主键)联合，如表8所示；

增量变更类型	增量id(账号)	增量value(余额)	全量id(账号)	全量value(余额)
					UPDATE	1111	7000	1111	5000
DELETE	2222	删除	2222	3000
					INSERT	3333	5000
			4444	6000

表8

第四步：根据判断逻辑进行数据过滤，判断逻辑是：保留增量主键为空或增量变更类型不为DELETE的数据，如表9所示：

增量变更类型	增量id(账号)	增量value(余额)	全量id(账号)	全量value(余额)
					UPDATE	1111	7000	1111	5000
INSERT	3333	5000
								4444	60000

表9

第五步：取值，当增量主键为空，则字段全部取全量值，否则全部取增量值，即可得到2015-04-20最终的全量快照，如表10所示。

id(账号)	value(余额)
		1111	7000
3333	5000
		4444	6000

表10

需要说明的是，的时间范围仅是一天，即仅仅是取一天的数据快照，实际上该时间范围可以为更细粒度，比如小时级的精准快照。

对于图3实施例而言，由于其与图1的方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作川页序的限制，因为依据本申请实施例，某些步骤可以采用其他川页序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。

参照图5，示出了本申请一种数据快照获取的系统实施例的结构框图，具体可以包括如下模块：

数据记录获取模块501，用于基于源端中记录的始于指定位置的重做日志redolog文件，获取对应的变更数据记录；

数据加载模块502，用于将所述变更数据记录加载到对应的目的端；

快照获取模块503，用于在所述目的端中，当到达预设的指定时间时，依据所述变更数据记录获取所述指定时间对应的第一数据快照。

在本申请实施例的一种优选实施例中，所述系统还可以包括：

在本申请实施例的一种优选实施例中，所述变更数据记录包括主键标识，所述快照获取模块503可以包括如下子模块：

在本申请实施例的一种优选实施例中，所述变更数据记录还包括数据编号，所述排序子模块还可以用于：

在本申请实施例的一种优选实施例中，所述数据加载模块502可以包括如下子模块：

在本申请实施例的一种优选实施例中，所述变更数据记录包括源端变更时间戳，所述格式转换子模块可以包括如下单元：

存储模块，用于存储预设时间段内的变更数据记录。

在本申请实施例的一种优选实施例中，所述源端为多个，所述数据记录获取模块501可以包括如下子模块：

采集子模块，用于分别将多个源端中记录的，始于指定位置的redolog文件集中采集到所述发布程序中，由所述发布程序解析所述redolog文件，获得对应的变更数据记录。

在本申请实施例的一种优选实施例中，所述第一数据快照包括第一主键标识、变更类型以及第一数值信息，所述第二数据快照包括第二主键标识及第二数值信息，所述合并模块可以包括如下子模块：

对于系统实施例而言，由于其与上述方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序操作指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序操作指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的操作指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序操作指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的操作指令产生包括操作指令装置的制造品，该操作指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序操作指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的操作指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种数据快照获取的方法及系统进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims

1.一种数据快照获取的方法，其特征在于，所述的方法包括：

将所述变更数据记录加载到对应的目的端；

2.根据权利要求1所述的方法，其特征在于，还包括：

3.根据权利要求1或2所述的方法，其特征在于，还包括：

4.根据权利要求3所述的方法，其特征在于，所述变更数据记录包括主键标识，所述在所述目的端中，当到达预设的指定时间时，依据所述变更数据记录获取所述指定时间对应的第一数据快照的步骤包括：

5.根据权利要求4所述的方法，其特征在于，所述变更数据记录还包括数据编号，所述若到达所述指定时间，针对每个主键标识的变更数据记录进行倒排序的步骤为：

6.根据权利要求1所述的方法，其特征在于，所述将所述变更数据记录加载到目的端的步骤包括：

7.根据权利要求6所述的方法，其特征在于，所述变更数据记录包括源端变更时间戳，所述由所述订阅程序将所述转换数据格式后的变更数据记录加载到对应的目的端的数据表中的步骤包括：

8.根据权利要求1所述的方法，其特征在于，还包括：

存储预设时间段内的变更数据记录。

9.根据权利要求6所述的方法，其特征在于，所述源端为多个，所述根据源端中记录的重做日志redolog文件，获取变更数据记录的步骤包括：

10.根据权利要求2所述的方法，其特征在于，所述第一数据快照包括第一主键标识、变更类型以及第一数值信息，所述第二数据快照包括第二主键标识及第二数值信息，所述将所述第一数据快照与所述第二数据快照组织成所述指定时间的第三数据快照的步骤包括：

11.一种数据快照获取的系统，其特征在于，所述的系统包括：

12.根据权利要求11所述的系统，其特征在于，还包括：

13.根据权利要求11或12所述的系统，其特征在于，还包括：

14.根据权利要求13所述的系统，其特征在于，所述变更数据记录包括主键标识，所述快照获取模块包括：

15.根据权利要求14所述的系统，其特征在于，所述变更数据记录还包括数据编号，所述排序子模块还用于：

16.根据权利要求11所述的系统，其特征在于，所述数据加载模块包括：

17.根据权利要求16所述的系统，其特征在于，所述变更数据记录包括源端变更时间戳，所述格式转换子模块包括：

18.根据权利要求11所述的系统，其特征在于，还包括：

存储模块，用于存储预设时间段内的变更数据记录。

19.根据权利要求16所述的系统，其特征在于，所述源端为多个，所述数据记录获取模块包括：

20.根据权利要求12所述的系统，其特征在于，所述第一数据快照包括第一主键标识、变更类型以及第一数值信息，所述第二数据快照包括第二主键标识及第二数值信息，所述合并模块包括：