CN111414277B - 数据恢复方法、装置、电子设备和介质 - Google Patents

Abstract

本申请提供了数据恢复方法、装置、电子设备和介质，涉及数据传输领域。本申请提供的数据恢复方法，在实现时，下游文件***在接收到上游计算***所发出关于目标压缩文件的压缩数据后，将压缩数据保存在本地缓存中；在发生故障而重启后，获取上游计算***持久化在存储***中的关于目标压缩文件的数据格式信息和有效传输长度；而后，根据数据格式信息和有效传输长度对目标压缩文件进行恢复。本申请所提供的方法考虑到了压缩数据和文档数据的差异性，在恢复数据的时候利用了数据格式信息进行辅助，保证了数据恢复的准确性。

Description

数据恢复方法、装置、电子设备和介质

技术领域

本申请涉及数据传输领域，具体而言，涉及数据恢复方法、装置、电子设备和介质。

背景技术

随着电子信息技术的发展，每天需要处理的业务数据在不断的扩大。对于当前已经扩大到PB级的业务数据，传统的单机处理技术早已无法有效的进行处理，进而产生了分布式计算技术来应对这种PB级业务数据的处理需求。

分布式计算技术可以将一个需要处理的大型任务分解成多个小任务，并由不同的网络节点(如服务器)分别完成每个小任务，最后再将每个小任务的处理结果进行整合，进而得到大型任务的处理结果。

随着对数据时效性要求的提高，在传统分布式技术的基础上，又出现了分布式流式计算技术，其中，Apache Flink就是一种新兴的分布式流式计算框架。分布式流式计算技术可以很好地对大规模流动数据在不断变化的运动过程中实时地进行分析，捕捉到可能有用的信息，并把结果发送到下一计算节点。

发明内容

本申请的目的在于提供数据恢复方法、装置、电子设备和介质。

在一些实施例中，一种数据恢复方法，作用于下游文件***，该方法包括：

在接收到上游计算***所发出关于目标压缩文件的压缩数据后，将压缩数据保存在本地缓存中；

在发生故障而重启后，获取上游计算***持久化在存储***中的关于目标压缩文件的数据格式信息和有效传输长度；

根据数据格式信息和有效传输长度对目标压缩文件进行恢复。

在一些实施例中，根据数据格式信息和有效传输长度对目标压缩文件进行恢复，包括：

根据有效数据长度和记录的压缩数据的到达顺序对压缩数据进行截断处理，以生成有效压缩数据；

根据数据格式信息生成目标压缩文件的文件尾；

根据有效压缩数据和文件尾对目标压缩文件进行恢复。

在一些实施例中，根据数据格式信息生成目标压缩文件的文件尾，包括：

根据上游计算***持久化在存储***中的关于目标压缩文件的文件头确定目标压缩文件的文件类型；

根据文件类型确定文件尾拼接方式；

根据确定的文件尾拼接方式和数据格式信息生成目标压缩文件的文件尾。

在一些实施例中，若文件类型为PDF类型；则数据格式信息包括交叉引用表、根节点信息和文件解析节点信息；根据确定的文件尾拼接方式和数据格式信息生成目标压缩文件的文件尾，包括：

将持久化在存储***中的交叉引用表、根节点信息和文件解析节点信息按照预定顺序进行拼接，以形成目标压缩文件的文件尾。

在一些实施例中，若文件类型为Gzip类型；则数据格式信息包括校验码；根据确定的文件尾生成方式和数据格式信息生成目标压缩文件的文件尾，包括：

对有效传输长度进行取模运算，以确定压缩数据的标识符；

将校验码和标识符拼接成目标压缩文件的文件尾。

在一些实施例中，根据数据格式信息和有效传输长度对目标压缩文件进行恢复，包括：

将保存在本地缓存中的压缩数据进行分组，以得到多组子压缩数据；

针对每组子压缩数据，将该组子压缩数据发送给对应的分布式计算节点，以使分布式计算节点根据接收到的有效传输长度对该组子压缩数据进行截断，以得到有效子压缩数据，并根据数据格式信息生成该组子压缩数据的子文件尾，以及将根据有效子压缩数据和子文件尾恢复出子压缩文件；

根据分布式计算节点所返回的子压缩文件对目标压缩文件进行恢复。

在一些实施例中，针对每组子压缩数据，将该组子压缩数据发送给对应的分布式计算节点，包括：

获取每个分布式计算节点的当前负载程度；

根据当前负载程度，确定每组子压缩数据所对应的分布式计算节点；

针对每组子压缩数据，将该组子压缩数据发送给对应的分布式计算节点。

在一些实施例中，该方法还包括：

接收应用***所发出的关于目标压缩文件的数据读取请求；

判断是否发送过关于目标压缩文件的确认指令的第一告知消息；确认指令是上游计算***在将目标压缩文件传输完成后发送给下游文件***的；第一告知消息是下游文件***在接收到确认指令后生成，并发送给上游计算***的；

若发送过第一告知消息，则将目标压缩文件发送给应用***。

在一些实施例中，该方法还包括：

接收应用***所发出的关于目标压缩文件的数据读取请求；

判断是否发送过第二告知消息；第二告知消息是下游文件***在将目标压缩文件成功恢复后生成，并发送给上游计算***的；

若发送过第二告知消息，则将目标压缩文件发送给应用***。

在一些实施例中，一种数据恢复装置，作用于下游文件***，该装置包括：

保存模块，用于在接收到上游计算***所发出关于目标压缩文件的压缩数据后，将压缩数据保存在本地缓存中；

获取模块，用于在发生故障而重启后，获取上游计算***持久化在存储***中的关于目标压缩文件的数据格式信息和有效传输长度；

恢复模块，用于根据数据格式信息和有效传输长度对目标压缩文件进行恢复。

在一些实施例中，一种电子设备，包括：处理器、存储器和总线，存储器存储有处理器可执行的机器可读指令，当电子设备运行时，处理器与存储器之间通过总线通信，机器可读指令被处理器执行时执行如数据恢复方法的步骤。

在一些实施例中，一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如数据恢复方法的步骤。

本申请实施例提供的数据恢复方法，在实现时，下游文件***在接收到上游计算***所发出关于目标压缩文件的压缩数据后，将压缩数据保存在本地缓存中；在发生故障而重启后，获取上游计算***持久化在存储***中的关于目标压缩文件的数据格式信息和有效传输长度；而后，根据数据格式信息和有效传输长度对目标压缩文件进行恢复。本申请所提供的方法考虑到了压缩数据和文档数据的差异性，在恢复数据的时候利用了数据格式信息进行辅助，保证了数据恢复的准确性。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请实施例所提供的数据恢复方法的基本流程图；

图2示出了本申请实施例所提供的数据恢复方法所应用的***的第一种***架构示意图；

图3示出了本申请实施例所提供的数据恢复方法所应用的***的第二种***架构示意图；

图4示出了本申请实施例所提供的电子设备的示意图。

具体实施方式

下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

分布式计算技术是目前应用比较广泛的一种数据处理技术，目前已经应用到了各行各业中，随着对数据时效性要求的提高，在传统分布式技术的基础上，又出现了分布式流式计算技术，其中，Apache Flink就是一种新兴的分布式流式计算框架。常见的分布式流式计算框架已经实现了至少三种语义，分别是：

1，至多一次(at most once)：保证计算结果在计算过程中遇到节点故障后，计算恢复前后结算结果至多发送到传输***一次。

2，至少一次(at least once)：保证计算结果在计算过程中遇到节点故障后，计算恢复前后结算结果至少发送到传输***一次。例如Strom。

3，受限的严格一次(exactly once)：依赖计算结果发布的存储支持update幂等功能，且update依据的key一般由业务方指定，实现计算结果直接记入存储，不再支持结果继续进行流式计算。例如Flink使用Cassandra作为存储。

目前，常见的流式计算或采集工具，如Flume,Spark Streaming,Logstash等，在流式(微批)处理将数据导入HDFS中均只能保证at-least-once。而Flink提供的HDFS连接器，目前只针对纯文本的写入的方式可以保证Exactly-once。因此，目前实现以压缩文件的方式写入HDFS并保证exactly-once的方式有以下两种：

第一种处理方式是由上游计算***先向下游文件***写入纯文本数据，在写入完成后，由下游文件***进行压缩；第二种处理方式是上游计算***以压缩流的方式向下游文件***写入数据，后期再由下游文件***进行去重。

上述两种处理方式相比，以纯文本的方式写入数据对存储的压力会远大于以压缩流写入数据的方式。而由于HDFS(Hadoop Distributed File System，分布式文件***)无法支持直接在分布式文件***上进行压缩，需要将文本文件下载到网络终端，并由网络终端压缩后再上传，对于巨大的数据量，这么做不仅对CPU和IO负载极高，而且效率也非常低，且可能出现二次错误。虽然以压缩流写入数据的方式在写入过程中压力较小，但是后期对写入数据进行去重却变得非常棘手，特别是对于巨量压缩文件，通常是需要先解压，再去重，而后再压缩的处理方式，可见，这种处理方式的效率也是较低的。

在数据传输的时候，***可能会发生故障而进行重启，采用上述第一种方式传输数据时，如果进行重启的话，通常会采用回滚的方式来恢复数据；而采用上述第二种方式传输数据时，如果进行重启的话，则只能直接将全部压缩数据直接放弃，从头重新传输，但即使采用这种方式，也无法保证数据的不重不丢。

针对上述第二种处理方式的弊端，如图1所示，本身请提供了一种数据恢复方法，作用于下游文件***，该方法包括如下步骤：

S101，在接收到上游计算***所发出关于目标压缩文件的压缩数据后，将压缩数据保存在本地缓存中；

S102，在发生故障而重启后，获取上游计算***持久化在存储***中的关于目标压缩文件的数据格式信息和有效传输长度；

S103，根据数据格式信息和有效传输长度对目标压缩文件进行恢复。

如图2所示，示出了本申请所提供的方法所适用的数据传输***，该数据传输***包括：上游计算***、存储***、下游文件***和应用***。其中，上游计算***分别与存储***和下游文件***通讯链接；下游分别***分别与上游计算***、存储***和应用***通讯连接。

此处，上游计算***通常是各大分布式计算引擎(如Spark、Hadoop、Flume和Flink等，本申请所提供的方案尤其适用于Flink)，该分布式计算引擎目前使用最多的功能是做日志数据的清洗解析和过滤，也是最为广泛使用的。在本方案中，上游计算***的主要功能是：获取文档形式(非压缩文件形式)的数据(如日志数据)，并形成对这些日志数据进行清洗(对日志数据按照既定规则进行过滤、格式化等处理)压缩，以形成二进制的压缩文件，而后，这些压缩文件会由上游计算***通过压缩流的形式发送给下游文件***，在将压缩文件发送给下游文件***的过程中，上游计算***还会实时的将所发送的文件所对应的描述信息(数据格式信息、有效传输长度和文件头)写入到存储***中，以便于在数据恢复的时候，下游文件***可以从存储***中调取这两个数据。一般情况下，上游计算***内是由多个层级的计算节点构成的，具体来说，上游计算***中通常是由大量的上游计算节点和下游计算节点相配合来完成计算功能的。

下游文件***如cephFs、fastdFs和Hdfs等，其中，本方案主要适用的是Hdfs。该下有文件***的主要功能是做数据的存储和数据仓库的构建。在本方案中，下游文件***的主要功能是：接收上游计算***所发出的压缩文件，并对压缩文件进行存储和管理；以及，在接收压缩文件出现意外(如***重启)的时候对接收到的异常数据进行恢复。同时，下游文件***会响应应用***的请求，将其接收到的压缩文件发送给应用***。此处，需要说明的是，实际工作中，下游文件***不仅可以处理压缩文件，也可以处理非压缩文件，非压缩文件的处理方式按照传统方式执行即可。

存储***(主要是分布式存储***)如Hdfs、Hbase和Redis等，本方案所提供的方法中，优选使用Hdfs来作为存储***。在本方案中，下游文件***的主要功能是：接收上游计算***所发出的关于压缩文件的描述信息，此处的描述信息如数据格式信息和有效传输长度，这些描述信息用来在数据恢复的时候提供给下游文件***进行使用。

应用***通常是面向用户侧的具有特定功能的软件产品，这些应用***需要从下游文件***中获取数据，以完成其特定的需要实现的功能。

上述步骤S101反映了一般的数据传输过程。上游计算***内部的节点大致可以分为两种，分别是计算节点和检查节点(checkpoint)，其中，计算节点的主要功能是从数据源(如提供基础日志信息的网络端)获取到基础数据后，对这些基础数据进行压缩，并将压缩后的数据传输给下游文件***；检查节点的主要作用是记录发出的压缩数据的描述信息(数据格式信息和有效传输长度)，并将这些描述信息写入到存储***中。检查节点还会定期的向下游文件***发送确认指令(commit指令)，以表示确认这一阶段的数据传输是正常的。下游文件***在接收到压缩数据之后，会将压缩数据保存在本地缓存中，同时，如果下游文件***接收到了确认指令后，会向上游计算***返回关于确认指令的告知消息，以告知上游文件***数据传输是正常的。通常情况下，在应用***向下游文件***请求数据的时候，下游文件***会验证其请求的数据是否接收到了对应的commit指令，只有在接收到commit指令(表示这部分数据已经完成传输)后，才会向下游文件***返回其请求的数据，否则不会返回其请求的数据。

上述步骤S101反映的是下游文件***在接收到上游计算***所发出的目标压缩文件后的正常工作状态，即上游计算***在对接收到基础数据之后，会对基础数据进行压缩，以形成目标压缩文件，而后，上游计算***会将该目标压缩文件发送给下游文件***。发送目标压缩文件的时候，目标压缩文件整体可以分成三个部分，分别是文件头(用于标识文件类别，如文件名等说明文件整体情况的信息)、多个压缩数据(记录有具体业务信息的部分，或者说是应用***进行业务操作时所需要的部分，即步骤S101中的压缩数据)和数据格式信息(用于解读/解压缩压缩数据的用于表征数据格式的信息，该信息通常是用来构成文件尾的，对于压缩文件，由于写入的数据是在实时增加，因此数据格式信息也是实时变化的)。具体传输的时候，文件头通常会先行传输，而后会按照既定的顺序传输多个压缩数据，在传输多个压缩数据的同时，也会传输数据格式信息给下游文件***，此处，由于压缩数据是逐步传输给下游文件***的，因此，用于描述压缩数据的数据格式信息也是逐步生成，并发送给下游文件***的(传输的数据格式信息与传输的压缩数据是相适配的)。上游计算***在将数据格式信息发送给下游文件***的同时，还会将数据格式信息、文件头有效传输长度等信息持久化在存储***中，以便于数据恢复的时候由下游文件***调取。

下游文件***在接收到文件头、数据格式信息和压缩数据后，会将按照压缩数据的接收顺序和文件头，将压缩数据进行拼接，并根据数据格式信息计算出文件尾，在拼接后的压缩数据的基础上加上文件尾，就可以形成完成的目标压缩文件了。

当***发生故障而重启之后，下游文件***中的数据格式信息无法直接使用，而是需要从存储***中调取、有效数据长度、数据格式信息和文件头，并依据缓存在本地的压缩数据来进行数据恢复。

步骤S102中，数据格式信息和有效传输长度都是上游计算***在成功传输压缩数据后，将对应的数据数据格式信息和有效传输长度持久化到存储***中的，也就是存储***中所记录的数据数据格式信息和有效传输长度至少反映了***重启前最后一批正常传输的压缩数据的情况。

最后，步骤S103中，可以直接根据数据格式信息和有效传输长度对目标压缩文件进行恢复了。恢复的时候，一般是先判断文件头是否完整，如果文件头不完整，则直接放弃，并且向上游计算***发送告知消息，以要求上游计算***直接重传文件；如果文件头完整，则按照有效传输长度对压缩数据进行截取，而后将文件头和压缩数据按照文件的组成顺序进行拼接，再后，将根据数据格式信息生成文件尾加在尾部即可完成数据的恢复。当然，如果数据没有传输完全传输完，则可以告知上游计算***继续传输数据，并在数据传输完成之后，再进行数据的拼接和增加文件尾的行为。

实际恢复数据时，新版的下游文件***中已经融合了很多功能，其可以自行完成数据的截取、拼接，根据数据格式信息生成文件尾的行为，但对于老版本的下游文件***，则无法自己完成这些任务。进而，步骤S103在具体实现时可以分为两种情况，分别是：第一种，下游文件***自身有独立恢复能力的情况；第二种，下游文件***自身没有独立恢复能力的情况。

针对上述第一种情况，步骤S103可以按照如下方式实现：

步骤1031，根据有效数据长度和记录的压缩数据的到达顺序对压缩数据进行截断处理，以生成有效压缩数据；

步骤1032，根据数据格式信息生成目标压缩文件的文件尾；

步骤1033，根据有效压缩数据和文件尾对目标压缩文件进行恢复。

步骤1031中，是根据有效传输长度和压缩数据的到达顺序对下游文件***所接收到的压缩数据进行截断，只保留传输正确的压缩数据，即有效压缩数据。步骤1032中，需要根据数据格式信息生成目标压缩文件的文件尾。步骤1033中，直接将有效压缩数据和文件尾进行拼接即可。当然，如果有效压缩数据只是目标压缩文件中的一部分，那么则需要下游文件***告知上游计算***继续进行目标压缩文件的传输，而后，再根据最终的数据格式信息生成目标压缩文件的完整文件尾，并将全部的压缩数据和完整文件尾进行拼接，以形成目标压缩数据。

其中，步骤1032可以按照如下方式来实现：

步骤10321，根据上游计算***持久化在存储***中的关于目标压缩文件的文件头确定目标压缩文件的文件类型；

步骤10322，根据文件类型确定文件尾生成方式；

步骤10323，根据确定的文件尾生成方式和数据格式信息生成目标压缩文件的文件尾。

步骤10321中，目标压缩文件的文件头是上游计算***在生成/发出目标压缩文件的时候，持久化到存储***中的。文件头中会标识出目标压缩文件的类型，具体来说，类型通常有两种，分别是PDF和Gzip。每种类型的压缩文件的格式有一定差别，因此，在进行文件恢复的时候，每种类型有着对应的恢复策略，不同的恢复策略主要是体现在文件尾的生成方式是有差异的。因此，在步骤10322中，需要根据文件头确定出文件尾的生成方式，而后，在步骤10323中就可以根据确定的文件尾生成方式来生成目标压缩文件的文件尾了。

具体的，对于Gzip类型的压缩文件，其文件整体分为文件头(含大量标志位)、压缩数据块(步骤S101中的压缩数据)和文件尾；每个压缩数据块前有一个CRC16校验码，文件尾包含一个持续增量更新的CRC32校验码和一个4比特的ISIZE位标识，该标识是整个压缩文件的长度对2的32次方取模结果。因此，在恢复文件的时候，在将文件截断为有效长度后，需要将存储***中记录的CRC32校验码添加到文件尾部，最后根据记录的压缩数据块有效长度对2的32次取模得到ISIZE标识，该ISIZE标识也要放置到文件尾部，这样就完成了GZIP压缩文件的恢复。也就是，在对Gzip类型的压缩文件进行恢复的时候，CRC32校验码就属于数据格式信息。

进而，若文件类型为Gzip类型，则数据格式信息包括校验码(CRC32校验码)；

步骤10323可以按照如下方式实现：

对有效传输长度进行取模运算，以确定压缩数据的标识符(ISIZE标识)；

将校验码和标识符拼接成目标压缩文件的文件尾。

具体的，对于PDF类型的压缩文件，其文件整体包括文件头，文件体(由一系列PDF对象组成，即步骤S101中的压缩数据)，交叉引用表(包含所有指向PDF对象文件位置索引的列表)以及最后的根节点信息和文件解析节点信息，同样检查点中需要记录这些信息，在恢复PDF类型的压缩文件的时候，首先将文件截断为有效长度后，随后将持久化在存储***中的交叉引用表、根节点信息和文件解析节点信息拼接成文件尾，并将文件头、文件提和文件尾依次顺序排列，即可完成对PDF类型的压缩文件的恢复。

进而，若文件类型为PDF类型，则数据格式信息包括交叉引用表、根节点信息和文件解析节点信息；

步骤10323可以按照如下方式实现：

将持久化在存储***中的交叉引用表、根节点信息和文件解析节点信息按照预定顺序进行拼接，以形成目标压缩文件的文件尾。

针对上述第二种情况，步骤S103可以按照如下方式实现：

步骤1034，将保存在本地缓存中的压缩数据进行分组，以得到多组子压缩数据；

步骤1035，针对每组子压缩数据，将该组子压缩数据发送给对应的分布式计算节点，以使分布式计算节点根据接收到的有效传输长度对该组子压缩数据进行截断，以得到有效子压缩数据，并根据数据格式信息生成该组子压缩数据的子文件尾，以及将根据有效子压缩数据和子文件尾恢复出子压缩文件；

步骤1036，根据分布式计算节点所返回的子压缩文件对目标压缩文件进行恢复。

如图3所示，示出了第二种情况所对应的***架构图，可以看出，图3在图2的基础上增加了分布式计算***，这主要是因为低版本的下游文件***无法独立实现复杂计算功能，需要将复杂计算的任务交给分布式计算***来完成。步骤1035中的分布式计算节点就属于分布式计算***。

步骤1034中，分组的目的是将恢复数据的任务分配到分布式计算节点中完成，在进行分组的时候，可以将压缩数据平均分为多组子压缩数据，也就是每组子压缩数据的数据量是基本相同的。步骤1035中，需要将每组子压缩数据分别发送给对应的分布式计算节点，以由分布式计算节点来完成对子压缩数据的恢复。具体给分布式计算节点分配子压缩数据的时候，并不必然要求平均分配，而是可以根据各个分布式计算节点的当前负载情况，按照负载均衡策略进行分配。

在分布式计算节点获取到子压缩数据和子压缩数据所对应的数据格式信息后，就可以由分布式计算节点来完成依据有效传输长度对该组子压缩数据进行截断，以及生成该组子压缩数据的文件尾，并最后恢复出子压缩文件。在分布式计算节点恢复出了子压缩文件之后，就可以将子压缩文件返回给下游文件***，以由下游文件***依据返回的子压缩文件来恢复出目标压缩文件。

如上一段所说，在进行子压缩数据的恢复的时候，可以按照负载均衡的方式来进行子压缩数据的分配，此种情况下，步骤1035可以按照如下方式实现：

步骤10351，获取每个分布式计算节点的当前负载程度；

步骤10352，根据当前负载程度，确定每组子压缩数据所对应的分布式计算节点；

步骤10353，针对每组子压缩数据，将该组子压缩数据发送给对应的分布式计算节点。

步骤10352中，在确定每组子压缩数据所对应的分布式计算节点时，除了考虑分布式计算节点的当前负载程度，还可以进一步考虑分布式计算节点的硬件性能，进而综合根据当前负载程度和硬件性能来确定每个分布式计算节点分配多少子压缩数据的处理任务，最后，在步骤10353中按照确定好的子压缩数据和分布式计算节点的对应关系来分配子压缩数据即可。在将子压缩数据分配到对应的分布式计算节点后，分布式计算节点按照如前文中所说的处理方式进行子压缩文件的恢复，并回传给下游文件***即可。

对于针对上述第二种情况，由于下游文件***的功能并不健全，因此在具体实现时，下游文件***可以采用如下的作业机制：

下游文件***在重启时，将检查点(上游计算***)持久化在存储***中的数据格式信息重写入一个与当前传输的压缩文件同名，但不同后缀的隐藏文件到下游文件***中，该隐藏文件称为状态信息文件。而后，下游文件***可以启动一个定时任务节点，该定时任务节点会定时扫描下游文件***，如果定时任务节点扫描到状态信息文件，则将对应的需要处理的问题文件的文件名放入消息队列，而后下游文件***可以通过分布式框架读取该文件的状态信息文件，而后，下游文件***就可以按照步骤1034-1036的处理方式将这些问题文件进行恢复了。

如前文中所说，上游计算***在向下游文件***发送压缩文件的时候，在发送完成之后(可以是全部文件均发送完成，也可以是某一个阶段的数据传输完成)会向下游文件***发送确认指令(commit指令)，下游文件***在接收到该指令之后，就会向上游计算***返回关于确认指令的告知消息，以告知上游文件***数据传输是正常的。通常情况下，在应用***向下游文件***请求数据的时候，下游文件***会验证其请求的数据是否接收到了对应的commit指令，只有在接收到commit指令(表示这部分数据已经完成传输)后，才会向下游文件***返回其请求的数据，否则不会返回其请求的数据。进而，本申请所提供的方法还包括如下步骤：

步骤201，接收应用***所发出的关于目标压缩文件的数据读取请求；

步骤202，判断是否发送过关于目标压缩文件的确认指令的第一告知消息；确认指令是上游计算***在将目标压缩文件传输完成后发送给下游文件***的；第一告知消息是下游文件***在接收到确认指令后生成，并发送给上游计算***的；

步骤203，若发送过第一告知消息，则将目标压缩文件发送给应用***；

步骤204，若未发送过第一告知消息，则终止当前流程，或向应用***返回表示请求失败的消息；请求失败的消息用于告知应用***目标压缩文件没有存在于下游文件***中。

步骤201中，数据读取请求中通常携带有数据标识，只有数据标识是目标压缩文件的数据标识时，才会执行步骤202。步骤202中的确认指令通常是上游计算***中的检查点(checkpoint)在对发送的数据检查无误后发出的，用以告知下游文件***其检查的这部分数据发送正常。下游文件***在接收到确认指令之后，还需要向上游计算***返回关于确认指令的第一告知消息，至此，上游计算***和下游文件***之间的数据传输就完成了。

在应用***向下游文件***请求数据的时候，如果被请求的数据有对应的第一告知消息，则说明被请求的数据是正常已经传输完的数据了，此时应当在步骤203中将目标压缩文件发送给应用***，以由应用***进行后续的应用层面的操作。对应的，如果被请求的数据没有对应的第一告知消息，则说明被请求的数据是没有正确传输的数据(上游计算***正在传输这部分数据)，此时应当终止当前流程(不向应用***进行任何反馈)，也可以向应用***返回表示请求失败的消息。当然，实际操作时，在某些情况下，也可以是下游文件***记录这些返回表示请求失败的消息，当表示请求失败的消息所对应的文件传输完成之后，再向应用***发送该表示请求失败的消息所对应的文件。

上述步骤201-204说明的是正常传输文件的流程，对应的，如果按照步骤S102-S103将目标压缩文件进行恢复后，下游文件***也可以直接生成告知消息，即本申请所提供的方法还包括如下步骤：

步骤301，接收应用***所发出的关于目标压缩文件的数据读取请求；

步骤302，判断是否发送过第二告知消息；第二告知消息是下游文件***在将目标压缩文件成功恢复后生成，并发送给上游计算***的；

步骤303，若发送过第二告知消息，则将目标压缩文件发送给应用***；

步骤304，若未发送过第二告知消息，则终止当前流程，或向应用***返回表示请求失败的消息；请求失败的消息用于告知应用***目标压缩文件没有存在于下游文件***中。

步骤301中，数据读取请求中通常携带有数据标识，只有数据标识是目标压缩文件的数据标识时，才会执行步骤302。步骤302中的第二告知消息是下游文件***在将目标压缩文件成功恢复后生成，并发送给上游计算***的，至此，上游计算***和下游文件***之间的数据传输就完成了。

在应用***向下游文件***请求数据的时候，如果被请求的数据有对应的第二告知消息，则说明被请求的数据是正常已经传输完的数据了，此时应当在步骤303中将目标压缩文件发送给应用***，以由应用***进行后续的应用层面的操作。对应的，如果被请求的数据没有对应的第二告知消息，则说明被请求的数据是没有正确传输的数据(重启后待恢复的时候)，此时应当终止当前流程(不向应用***进行任何反馈)，也可以向应用***返回表示请求失败的消息。当然，实际操作时，在某些情况下，也可以是下游文件***记录这些返回表示请求失败的消息，当表示请求失败的消息所对应的文件成功恢复之后，再向应用***发送该表示请求失败的消息所对应的文件。

下面以2个具体的实例来说明本申请所提供的数据传输方法在实际工作时的完整工作流程，即数据传输方法的恢复流程和正常传输流程。

实例1，数据传输方法的恢复流程。

该方法作用于如图2所示的数据传输***，该数据传输***包括：上游计算***、存储***、下游文件***和应用***。其中，上游计算***分别与存储***和下游文件***通讯链接；下游分别***分别与上游计算***、存储***和应用***通讯连接。

步骤1，上游计算***接收目标数据流；

步骤2，上游计算***对目标数据流进行格式化；

步骤3，上游计算***对格式化后的目标数据流进行压缩，以生成目标压缩文件；

步骤4，上游计算***将生成的目标压缩文件的压缩数据以压缩流的方式实时发送给下游文件***，并同时定期将目标压缩文件的数据格式信息、有效传输长度和文件头对应的持久化在存储***；

步骤5，当***故障而重启后，下游文件***从存储***中读取数据格式信息、有效传输长度和文件头；

步骤6，下游文件***根据有效传输长度对步骤4中接收到的压缩数据进行截断；

步骤7，下游文件***根据数据格式信息生成文件尾；

步骤8，下游文件***将文件头、步骤6中截断后得到的压缩数据和文件尾拼接成目标压缩文件，并保存在本地。

实例2，数据传输方法的正常传输流程。

该方法作用于如图2所示的数据传输***，该数据传输***包括：上游计算***、存储***、下游文件***和应用***。其中，上游计算***分别与存储***和下游文件***通讯链接；下游分别***分别与上游计算***、存储***和应用***通讯连接。

步骤1，上游计算***接收目标数据流；

步骤2，上游计算***对目标数据流进行格式化；

步骤3，上游计算***对格式化后的目标数据流进行压缩，以生成目标压缩文件；

步骤4，上游计算***将生成的目标压缩文件的压缩数据以压缩流的方式实时发送给下游文件***，并同时定期将目标压缩文件的数据格式信息和文件头对应的持久化在存储***；

步骤5，上游计算***定期检查目标压缩文件是否传输正常，如果传输正常，则向下游文件***发送确认指令(commit)；

步骤6，下游文件***在接收到确认指令后，向上游计算***回复告知消息，以说明下游文件***正常接收到了这部分数据，使上游计算***继续进行数据传输；

步骤7，下游文件***在目标数据传输完成后，将目标压缩文件按照文件头、压缩数据和文件尾的顺序进行拼接，以生成目标压缩数据，并保存在本地；

步骤8，下游文件***在接收到应用***关于目标压缩文件的数据读取请求后，确认发送过关于目标压缩文件的告知消息，则将目标压缩数据发送给应用***。

与上述数据恢复方法相对应的，本申请还提供了一种数据恢复装置，作用于下游文件***，该装置包括：

保存模块，用于在接收到上游计算***所发出关于目标压缩文件的压缩数据后，将压缩数据保存在本地缓存中；

获取模块，用于在发生故障而重启后，获取上游计算***持久化在存储***中的关于目标压缩文件的数据格式信息和有效传输长度；

恢复模块，用于根据数据格式信息和有效传输长度对目标压缩文件进行恢复。

在一些实施例中，恢复模块，包括：

截断单元，用于根据有效数据长度和记录的压缩数据的到达顺序对压缩数据进行截断处理，以生成有效压缩数据；

第一生成单元，用于根据数据格式信息生成目标压缩文件的文件尾；

第一恢复单元，用于根据有效压缩数据和文件尾对目标压缩文件进行恢复。

在一些实施例中，第一生成单元，包括：

第一确定子单元，用于根据上游计算***持久化在存储***中的关于目标压缩文件的文件头确定目标压缩文件的文件类型；

第二确定子单元，用于根据文件类型确定文件尾拼接方式；

第一生成子单元，用于根据确定的文件尾拼接方式和数据格式信息生成目标压缩文件的文件尾。

在一些实施例中，若文件类型为PDF类型；则数据格式信息包括交叉引用表、根节点信息和文件解析节点信息；

第一生成子单元，包括：

第一拼接子单元，用于将持久化在存储***中的交叉引用表、根节点信息和文件解析节点信息按照预定顺序进行拼接，以形成目标压缩文件的文件尾。

在一些实施例中，若文件类型为Gzip类型；则数据格式信息包括校验码；

第一生成子单元，包括：

第三确定子单元，用于对有效传输长度进行取模运算，以确定压缩数据的标识符；

第二拼接子单元，用于将校验码和标识符拼接成目标压缩文件的文件尾。

在一些实施例中，恢复模块，包括：

分组单元，用于将保存在本地缓存中的压缩数据进行分组，以得到多组子压缩数据；

第一发送单元，用于针对每组子压缩数据，将该组子压缩数据发送给对应的分布式计算节点，以使分布式计算节点根据接收到的有效传输长度对该组子压缩数据进行截断，以得到有效子压缩数据，并根据数据格式信息生成该组子压缩数据的子文件尾，以及将根据有效子压缩数据和子文件尾恢复出子压缩文件；

第二恢复单元，用于根据分布式计算节点所返回的子压缩文件对目标压缩文件进行恢复。

在一些实施例中，第一发送单元，包括：

第一获取子单元，用于获取每个分布式计算节点的当前负载程度；

第四确定子单元，用于根据当前负载程度，确定每组子压缩数据所对应的分布式计算节点；

第一发送子单元，用于针对每组子压缩数据，将该组子压缩数据发送给对应的分布式计算节点。

在一些实施例中，该装置还包括：

第一接收模块，用于接收应用***所发出的关于目标压缩文件的数据读取请求；

第一判断模块，用于判断是否发送过关于目标压缩文件的确认指令的第一告知消息；确认指令是上游计算***在将目标压缩文件传输完成后发送给下游文件***的；第一告知消息是下游文件***在接收到确认指令后生成，并发送给上游计算***的；

第一发送模块，若发送过第一告知消息，则用于将目标压缩文件发送给应用***。

在一些实施例中，该装置还包括：

第二接收模块，用于接收应用***所发出的关于目标压缩文件的数据读取请求；

第二判断模块，用于判断是否发送过第二告知消息；第二告知消息是下游文件***在将目标压缩文件成功恢复后生成，并发送给上游计算***的；

第二发送模块，若发送过第二告知消息，则用于将目标压缩文件发送给应用***。

与上述方法相对应的，本申请还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如数据恢复方法的步骤。

如图4所示，为本申请实施例所提供的电子设备示意图，该电子设备1000包括：处理器1001、存储器1002和总线1003，存储器1002存储有执行指令，当电子设备运行时，处理器1001与存储器1002之间通过总线1003通信，处理器1001执行存储器1002中存储的数据恢复方法的步骤。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的***、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的***、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

Claims (12)

1.一种数据恢复方法，其特征在于，作用于下游文件***，该方法包括：

在接收到上游计算***以压缩流方式所发出关于目标压缩文件的压缩数据后，将压缩数据保存在本地缓存中；

在发生故障而重启后，获取上游计算***在成功传输压缩数据后持久化在存储***中的关于目标压缩文件的数据格式信息和有效传输长度；

根据数据格式信息和有效传输长度对目标压缩文件进行恢复，其中，所述数据格式信息用于生成在对所述目标压缩文件进行恢复的过程中所使用的文件尾，所述有效传输长度用于对所述压缩数据进行截断处理生成在对所述目标压缩文件进行恢复的过程中所使用的截断处理结果。

2.根据权利要求1所述的方法，其特征在于，根据数据格式信息和有效传输长度对目标压缩文件进行恢复，包括：

根据有效数据长度和记录的所述压缩数据的到达顺序对所述压缩数据进行截断处理，以生成有效压缩数据；

根据数据格式信息生成目标压缩文件的文件尾；

根据所述有效压缩数据和所述文件尾对所述目标压缩文件进行恢复。

3.根据权利要求2所述的方法，其特征在于，根据数据格式信息生成目标压缩文件的文件尾，包括：

根据上游计算***持久化在存储***中的关于目标压缩文件的文件头确定目标压缩文件的文件类型；

根据所述文件类型确定文件尾拼接方式；

根据确定的文件尾拼接方式和数据格式信息生成目标压缩文件的文件尾。

4.根据权利要求3所述的方法，其特征在于，若文件类型为PDF类型；则数据格式信息包括交叉引用表、根节点信息和文件解析节点信息；根据确定的文件尾拼接方式和数据格式信息生成目标压缩文件的文件尾，包括：

将持久化在存储***中的交叉引用表、根节点信息和文件解析节点信息按照预定顺序进行拼接，以形成所述目标压缩文件的文件尾。

5.根据权利要求3所述的方法，其特征在于，若文件类型为Gzip类型；则数据格式信息包括校验码；根据确定的文件尾生成方式和数据格式信息生成目标压缩文件的文件尾，包括：

对有效传输长度进行取模运算，以确定压缩数据的标识符；

将所述校验码和所述标识符拼接成所述目标压缩文件的文件尾。

6.根据权利要求1所述的方法，其特征在于，根据数据格式信息和有效传输长度对目标压缩文件进行恢复，包括：

将保存在本地缓存中的压缩数据进行分组，以得到多组子压缩数据；

针对每组子压缩数据，将该组子压缩数据发送给对应的分布式计算节点，以使分布式计算节点根据接收到的有效传输长度对该组子压缩数据进行截断，以得到有效子压缩数据，并根据数据格式信息生成该组子压缩数据的子文件尾，以及将根据所述有效子压缩数据和所述子文件尾恢复出子压缩文件；

根据分布式计算节点所返回的子压缩文件对所述目标压缩文件进行恢复。

7.根据权利要求6所述的方法，其特征在于，针对每组子压缩数据，将该组子压缩数据发送给对应的分布式计算节点，包括：

获取每个分布式计算节点的当前负载程度；

根据所述当前负载程度，确定每组子压缩数据所对应的分布式计算节点；

针对每组子压缩数据，将该组子压缩数据发送给对应的分布式计算节点。

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

接收应用***所发出的关于目标压缩文件的数据读取请求；

判断是否发送过关于目标压缩文件的确认指令的第一告知消息；所述确认指令是上游计算***在将目标压缩文件传输完成后发送给下游文件***的；所述第一告知消息是下游文件***在接收到确认指令后生成，并发送给上游计算***的；

若发送过所述第一告知消息，则将目标压缩文件发送给应用***。

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

接收应用***所发出的关于目标压缩文件的数据读取请求；

判断是否发送过第二告知消息；所述第二告知消息是下游文件***在将目标压缩文件成功恢复后生成，并发送给上游计算***的；

若发送过所述第二告知消息，则将目标压缩文件发送给应用***。

10.一种数据恢复装置，其特征在于，作用于下游文件***，该装置包括：

保存模块，用于在接收到上游计算***以压缩流方式所发出关于目标压缩文件的压缩数据后，将压缩数据保存在本地缓存中；

获取模块，用于在发生故障而重启后，获取上游计算***在成功传输压缩数据后持久化在存储***中的关于目标压缩文件的数据格式信息和有效传输长度；

恢复模块，用于根据数据格式信息和有效传输长度对目标压缩文件进行恢复，其中，所述数据格式信息用于生成在对所述目标压缩文件进行恢复的过程中所使用的文件尾，所述有效传输长度用于对所述压缩数据进行截断处理生成在对所述目标压缩文件进行恢复的过程中所使用的截断处理结果。

11.一种电子设备，其特征在于，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行如权利要求1至9任意一项所述的数据恢复方法的步骤。

12.一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如权利要求1至9任意一项所述的数据恢复方法的步骤。