CN110659308B - 一种数据清算处理方法及装置 - Google Patents

Abstract

本公开是关于一种数据清算处理方法及装置。该方法包括：获取待清算数据；分析所述待清算数据的业务特征；根据所述待清算数据的业务特征分析结果，对所述待清算数据执行不同处理。本公开的方案，能扩展使用场景，更好进行海量数据清算处理，并能够处理按特定顺序或处理结果相互依赖制约的数据，以及在使用大数据技术的前提下，能够保证多笔数据处理结果的事务一致性。

Description

一种数据清算处理方法及装置

技术领域

本公开涉及数据清算处理技术领域，尤其涉及一种数据清算处理方法及装置。

背景技术

目前，随着社交网络、云计算等技术不断融入人们的生活，以及现有的计算能力、存储空间、网络带宽等高速发展，人类积累的数据在互联网、通信、金融、商业等诸多领域不断地增长和累积。相关技术中，需要对各种各样的数据例如积分数据进行处理，包括进行清算处理等，其中会涉及到使用存储技术、流式计算技术等。

其中，流式计算技术包括Spark Streaming、Flink或Storm等。Spark是一种专为大规模数据处理而设计的快速通用的计算引擎，Spark Streaming(Spark流)是Spark用于处理流式数据的模块，可以实现高吞吐量的具备容错机制的实时流数据的处理，支持从多种数据源获取数据，在从数据源获取数据之后，可以使用各种高级函数进行复杂算法的处理。Flink是由Apache软件基金会开发的开源流处理框架，具有分布式部署和分布式计算的能力，其以数据并行和流水线方式执行任意流数据程序，Flink的流水线运行时系统可以执行批处理和流处理程序。Storm是一个免费并开源的分布式实时计算系统，利用Storm可以很容易做到可靠地处理无限的数据流，可以实时处理数据。

相关技术中，流式计算为当前数据清算处理的主流模式，应用于当前各知名互联网公司，其数据清算处理的基本过程一般都是将业务系统的数据流做为数据来源，通过统一的数据收集模块如消息中间件等将数据流转至Spark Streaming、Flink或Storm等流式处理引擎进行处理，再将数据清算处理的处理结果存储于数据库或分布式文件系统中。其中，消息中间件例如可以是消息队列等。其中，流式处理引擎均是对一条或多条数据进行清算，每条数据清算过程之间一般无依赖关系，不用严格区分哪些数据先处理，且每条清算结果也不相互影响，也不需要保证某些条数据清算结果必须是同一个事务性，这样才能发挥分布式流计算的强大运算能力，实时清算海量数据。

但是，上述相关技术中，如果出现消息中的数据有特定处理顺序，数据清算逻辑相互依赖，上述的数据清算处理方法就满足不了数据清算要求。所以，相关技术中的数据清算处理方法在处理海量数据时，使用场景具有一定局限性。

发明内容

为克服相关技术中存在的问题，本公开提供一种数据清算处理方法及装置，能扩展使用场景，更好进行海量数据清算处理。

根据本公开实施例的第一方面，提供一种数据清算处理方法，包括：

获取待清算数据；

分析所述待清算数据的业务特征；

根据所述待清算数据的业务特征分析结果，对所述待清算数据执行不同处理。

优选的，所述根据所述待清算数据的业务特征分析结果，对所述待清算数据执行不同处理，包括：

将根据交易类型分析出的积分类数据，根据时间顺序进行清算处理；

在所述积分类数据清算处理完成后，将根据交易类型分析出的兑分类数据进行数据特性分析，根据分析出的依赖关系结果，采用不同方式进行清算处理。

优选的，所述将根据交易类型分析出的兑分类数据进行数据特性分析，根据分析出的依赖关系结果，采用不同方式进行清算处理，包括：

在所述兑分类数据为含依赖关系的情况下，根据串行原则进行清算处理；或，

在所述兑分类数据为无依赖关系的情况下，根据分组并行原则进行清算处理。

优选的，所述在所述兑分类数据为含依赖关系的情况下，根据串行原则进行清算处理，包括：

在所述兑分类数据为含依赖关系的情况下，将兑分类数据按会员分组且含依赖关系的会员分为同组，每组内根据先进先出的业务规则和由依赖关系所确定的清算顺序，串行进行清算处理，各组并行进行清算处理；

所述在所述兑分类数据为无依赖关系的情况下，根据分组并行原则进行清算处理，包括：

在所述兑分类数据为无依赖关系的情况下，将兑分类数据按会员分组，各组并行进行清算处理，每组内根据先进先出的业务规则，串行进行清算处理。

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

对于积分类数据，选择分布式计算引擎Impala并采用Impala SQL进行清算处理；或，

对于无依赖关系的兑分类数据，选择分布式计算引擎Impala并采用Impala SQL进行清算处理，对于含依赖关系的兑分类数据，选择分布式计算引擎Spark进行清算处理；或，在进行数据存储时，选择大数据存储引擎Kudu进行存储。

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

在进行清算处理的过程中，使用中间结果表存储清算结果，和/或，对清算结果执行镜像处理；

在清算处理完成后，将所述中间结果表合并到最终结果表中。

根据本公开实施例的第二方面，提供一种数据清算处理装置，包括：

获取模块，用于获取待清算数据；

分析模块，用于分析所述待清算数据的业务特征；

处理模块，用于根据所述分析模块分析出的所述待清算数据的业务特征分析结果，对所述待清算数据执行不同处理。

优选的，所述处理模块包括：

积分类数据子模块，用于将根据交易类型分析出的积分类数据，根据时间顺序进行清算处理；

兑分类数据子模块，用于在所述积分类数据子模块的积分类数据清算处理完成后，将根据交易类型分析出的兑分类数据进行数据特性分析，根据分析出的依赖关系结果，采用不同方式进行清算处理。

优选的，所述兑分类数据子模块包括：

第一兑分处理子模块，用于在所述兑分类数据为含依赖关系的情况下，根据串行原则进行清算处理；或，

第二兑分处理子模块，用于在所述兑分类数据为无依赖关系的情况下，根据分组并行原则进行清算处理。

优选的，所述装置还包括：选择模块和/或优化模块；

其中，选择模块，用于对于积分类数据，选择分布式计算引擎Impala并采用ImpalaSQL进行清算处理；或，对于无依赖关系的兑分类数据，选择分布式计算引擎Impala并采用Impala SQL进行清算处理，对于含依赖关系的兑分类数据，选择分布式计算引擎Spark进行清算处理；或，在进行数据存储时，选择大数据存储引擎Kudu进行存储；

优化模块，用于在进行清算处理的过程中，使用中间结果表存储清算结果，和/或，对清算结果执行镜像处理；在清算处理完成后，将所述中间结果表合并到最终结果表中。

本公开的实施例提供的技术方案可以包括以下有益效果：

本公开的方案在获取待清算数据后，分析所述待清算数据的业务特征；根据所述待清算数据的业务特征分析结果，对所述待清算数据执行不同处理。通过上述处理，无论数据是积分类数据还是兑分类数据，无论数据是否包含特定处理顺序，数据清算逻辑是否相互依赖，本公开的方案都能相应进行处理，因此实现了扩展使用场景，更好进行海量数据清算处理，更好满足了数据清算要求。

本公开的实施例，待清算数据可以根据交易类型分为积分类数据和兑分类数据，将根据交易类型分析出的积分类数据，根据时间顺序进行清算处理，在所述积分类数据清算处理完成后，将根据交易类型分析出的兑分类数据进行数据特性分析，根据分析出的依赖关系结果，再采用不同方式进行清算处理。

本公开的实施例，其中兑分类数据的依赖关系可以划分为含依赖关系或无依赖关系，在所述兑分类数据为含依赖关系的情况下，根据串行原则进行清算处理；或，在所述兑分类数据为无依赖关系的情况下，根据分组并行原则进行清算处理，从而实现根据不同数据依赖关系进行不同清算处理，扩展使用场景。

本公开的实施例，可以在所述兑分类数据为含依赖关系的情况下，将兑分类数据按会员分组且含依赖关系的会员分为同组，每组内根据先进先出的业务规则和由依赖关系所确定的清算顺序，串行进行清算处理，各组并行进行清算处理；还可以在所述兑分类数据为无依赖关系的情况下，将兑分类数据按会员分组，各组并行进行清算处理，每组内根据先进先出的业务规则，串行进行清算处理。通过上述处理，进一步提升了数据清算处理效率。

本公开的实施例，可以在进行清算处理的过程中，使用中间结果表存储清算结果，和/或，对清算结果执行镜像处理；在清算处理完成后，将所述中间结果表合并到最终结果表中。通过上述处理，隔离了中间清算过程与最终结果表数据，一旦中间计算过程中遇到错误，只需要舍弃清算结果重新清算，无需对最终结果表做任何改变，保障了历史清算成功的结果不受干扰，从而进一步优化了数据清算处理效果。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

通过结合附图对本公开示例性实施方式进行更详细的描述，本公开的上述以及其它目的、特征和优势将变得更加明显，其中，在本公开示例性实施方式中，相同的参考标号通常代表相同部件。

图1是本公开根据一示例性实施例示出的一种数据清算处理方法的流程图；

图2是本公开根据一示例性实施例示出的一种数据清算处理方法的另一流程图；

图3是本公开根据一示例性实施例示出的数据清算处理方法中积分类数据的清算处理过程示意图；

图4是本公开根据一示例性实施例示出的数据清算处理方法中兑分类数据清算处理过程示意图；

图5是本公开根据一示例性实施例示出的一种数据清算处理装置的示意图框图；

图6是本公开根据一示例性实施例示出的一种数据清算处理装置的另一示意图框图；

图7是本公开根据一示例性实施例示出的一种计算设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的优选实施方式。虽然附图中显示了本公开的优选实施方式，然而应该理解，可以以各种形式实现本公开而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

在本公开使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本公开。在本公开和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本公开可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

本公开提供了一种数据清算处理方法，能扩展使用场景，更好进行海量数据清算处理，并能够处理按特定顺序或处理结果相互依赖制约的数据，以及在使用大数据技术的前提下，能够保证多笔数据处理结果的事务一致性。

以下结合附图详细介绍本公开的技术方案。

图1是本公开根据一示例性实施例示出的一种数据清算处理方法的流程图。

如图1所示，该方法可以应用于数据清算处理装置中，包括以下步骤：

在步骤101中，获取待清算数据。

其中，所述待清算数据可以包括积分类数据和兑分类数据等。

在步骤102中，分析所述待清算数据的业务特征。

其中，可以根据交易类型分析出清算数据是积分类数据或兑分类数据。

在步骤103中，根据所述待清算数据的业务特征分析结果，对所述待清算数据执行不同处理。

该步骤中，可以将根据交易类型分析出的积分类数据，根据时间顺序例如根据先进先出的业务规则进行清算处理；在所述积分类数据清算处理完成后，将根据交易类型分析出的兑分类数据进行数据特性分析，根据分析出的依赖关系结果，采用不同方式进行清算处理。

由该实施例可见，本公开的方案在获取待清算数据后，分析所述待清算数据的业务特征；根据所述待清算数据的业务特征分析结果，对所述待清算数据执行不同处理。通过上述处理，无论数据是积分类数据还是兑分类数据，无论数据是否包含特定处理顺序，数据清算逻辑是否相互依赖，本公开的方案都能相应进行处理，因此实现了扩展使用场景，更好进行海量数据清算处理，更好满足了数据清算要求。

图2是本公开根据一示例性实施例示出的一种数据清算处理方法的另一流程图。图2相对于图1更详细描述了本公开的方案。

相关技术中，要想充分发挥流式处理引擎的海量数据计算能力，需充分利用分布式处理即多个处理节点同时清算来自消息中间件中的数据，而要想达到这一目标，需满足消息中间件中的数据在被多个流式处理引擎同时清算时，计算结果是相互不影响，计算逻辑是相互不依赖，且各处理节点清算的结果不要求与其它处理节点的清算结果保持在一个事务中。所以，一旦出现消息中的数据有特定处理顺序，数据清算逻辑相互依赖，结果相互影响，且可能存在多条数据清算处理结果需在同一个事务中，而目前相关技术中的数据清算处理方法满足不了数据清算要求。本公开的方案，可以解决上述问题，能更好进行海量数据清算处理，并能够处理按特定顺序或处理结果相互依赖制约的数据，以及在使用大数据技术的前提下，能够保证多笔数据处理结果的事务一致性。

本公开的方案，在相关传统的积分清算处理方法上进行改进，结合大数据平台技术，利用分布式计算引擎的大规模计算能力优势，按照积分事务发生时间的先后顺序，采用先进先出策略进行数据的清算处理。

本公开方案中，数据的清算主要可以分为两大过程：积分过程和兑分过程。其中，积分类似于用户存钱，兑分类似于用户消费，积分过程产生积分类数据，兑分过程产生兑分类数据。

本公开可以将积分数据按业务特征分为两类：积分类数据(用户积分)、兑分类数据(用户消费分)，其中业务特征都可以按交易类型进行区分。本公开方案，先处理完获取的积分类数据，生成最终结果后，再获取兑分类数据分析再处理。本公开方案的一次完整的清算周期可以为：先处理完积分类数据后，再处理完兑分类数据，其中清算难点在于兑分类数据，需要再次区分兑分类数据有无依赖关系，根据依赖关系结果决定数据分组情况，及确定并行或串行的基本原则。

本公开的清算处理逻辑包括：

1)按交易类型区分出业务特征是积分类数据并挑选出这部分数据，先统一清算完成(此时忽略兑分类数据清算处理)，并合并到最终结果。这种情况的数据没有依赖关系，按时间顺序清算即可，清算的过程为可以选择分布式计算引擎Impala并采用Impala SQL进行批量清算。

2)对于兑分类数据，获取兑分类数据后再一次进行分析，将兑分类数据再一次分析出是含依赖还是无依赖的的兑分，根据不同依赖关系进行不同清算。例如无依赖关系的情况下，主要根据分组并行原则进行清算处理，进一步的对于无依赖关系的情况，可以选择分布式计算引擎Impala并采用Impala SQL进行分组并行清算，其中组内还是可以根据先进先出的业务规则，串行进行清算处理；例如含依赖关系的情况下，主要根据串行原则进行清算处理，进一步的对于含依赖关系的情况，可以选择分布式计算引擎Spark进行清算处理，因为有依赖顺序，在组内根据先进先出的业务规则和由依赖关系所确定的清算顺序，串行进行清算处理，最终合并到最终结果表。

如图2所示，该方法可以应用于数据清算处理装置中，包括以下步骤：

在步骤201中，获取积分类数据。

本公开根据交易类型分析出待清算数据为积分类数据或兑分类数据后，获取积分类数据。

在步骤202中，对积分类数据进行清算。

该步骤对于积分类数据，根据时间顺序进行清算处理，例如根据先进先出的业务规则进行清算处理。

在步骤203中，获取兑分类数据。

本公开根据交易类型分析出待清算数据为积分类数据或兑分类数据后，可以获取兑分类数据。

在步骤204中，将兑分类数据进行数据特性分析，得到数据之间的依赖关系，根据依赖关系结果确定采用不同方式进行清算处理。

本公开方案中，数据依赖关系的分析依据是可以根据数据本身的特点进行分析，数据与数据之间是有逻辑关系，例如第一条数据有交易流水编号，第二条交易数据某个字段写明了关联第一条的交易流水编号，这就是一种逻辑上的依赖关系。该步骤进行数据特性分析，根据数据之间的逻辑关系，将兑分类数据的依赖关系划分为含依赖关系或无依赖关系。

该步骤将兑分类数据进行数据特性分析，得到数据之间的依赖关系为含依赖关系或无依赖关系。

在步骤205中，在兑分类数据为无依赖关系的情况下，根据分组并行原则进行清算处理。

在兑分类数据为无依赖关系也即属于简单兑分的情况下，主要根据分组并行原则进行清算处理，但各组内还是可以串行处理。

也就是说，在兑分类数据为无依赖关系的情况下，将兑分类数据按会员分组，各组并行进行清算处理，每组内根据先进先出的业务规则，串行进行清算处理。

如图2所示，对于简单兑分处理情况，例如可以按会员分组M1、M2、M3，组与组之间可以并行计算，每个组内例如M1、M2、M3组内是串行计算。

在步骤206中，在兑分类数据为含依赖关系的情况下，根据串行原则进行清算处理。

在兑分类数据为含依赖关系也即属于复杂兑分的情况下，主要根据串行原则进行清算处理，但是进一步的将含依赖关系的会员分为同组后，各组可以并行进行清算处理。

也就是说，在兑分类数据为含依赖关系的情况下，可以将兑分类数据按会员分组且含依赖关系的会员分为同组，每组内根据先进先出的业务规则和由依赖关系所确定的清算顺序，串行进行清算处理，各组并行进行清算处理。

如图2所示，对于复杂兑分处理情况，例如可以按会员分组，含依赖关系会员分为一组，例如分为(M7、M8)、(M9、M10)、(M20、M31)等，每个组内是串行计算，但可以并行计算各组，从而提高处理效率。

需说明的是，步骤205和206没有必然的顺序关系。

还需说明的是，对于积分类数据，本公开可以选择分布式计算引擎Impala并采用Impala SQL进行清算处理；对于无依赖关系的兑分类数据，可以选择分布式计算引擎Impala并采用Impala SQL进行清算处理，对于含依赖关系的兑分类数据，选择分布式计算引擎Spark进行清算处理；在进行数据存储时，选择大数据存储引擎Kudu进行存储。

由该实施例可见，本公开的实施例，待清算数据可以根据交易类型分为积分类数据和兑分类数据，将根据交易类型分析出的积分类数据，根据时间顺序进行清算处理，在所述积分类数据清算处理完成后，将根据交易类型分析出的兑分类数据进行数据特性分析，根据分析出的依赖关系结果，再采用不同方式进行清算处理。其中兑分类数据的依赖关系可以划分为含依赖关系或无依赖关系，在所述兑分类数据为含依赖关系的情况下，根据串行原则进行清算处理；或，在所述兑分类数据为无依赖关系的情况下，根据分组并行原则进行清算处理，从而实现根据不同数据依赖关系进行不同清算处理，扩展使用场景。

图3是本公开根据一示例性实施例示出的数据清算处理方法中积分类数据(用户积分)的清算处理过程示意图。该过程是通过挑选出积分类数据(积分类全部无依赖关系)来进行清算。

本公开方案中，积分过程是相关引擎按照时间顺序，记录每个会员的积分结果的过程。首先，将海量积分事务的积分数据存储到大数据分布式存储引擎中，采用大数据分布式计算引擎，按照积分事务发生的先后顺序，记录还没有被清算过的积分数据，并将积分过程的相关数据存储到大数据分布式存储引擎，作为后续兑分清算的基础来源余额。所说的基础来源余额，是指用户积了一笔积分，该笔积分还有多少余额分可兑分。本公开的积分过程主要保证积分记录能够及时并正确保存到大数据平台。

如图3所示的流程，包括以下步骤：

在步骤301中，检查上一次历史运行结果。

该步骤中，检测上一次积分类数据清算的历史运行结果。

在步骤302中，判断上一次历史运行结果是否满足运行条件，如果不满足，进入步骤309，如果满足，进入步骤303。

其中，运行条件是指数据不存在问题，数据是否存在问题可以根据数据本身的一些逻辑关系进行判断。如果不满足运行条件，也即指数据存在问题，则进入步骤309进行报警，如果满足运行条件，也即指数据不存在问题，进入步骤303。

在步骤303中，获取新的积分事务到临时表，进入步骤304。

该步骤中，对于用户获取新的积分，可以获取新的积分事务到临时表，通过临时表进行暂存。

在步骤304中，判断获取新的积分事务到临时表是否成功，如果不成功，进入步骤309，如果成功，进入步骤305。

其中，如果临时表显示了新的积分事务，表示获取新的积分事务到临时表是成功。

在步骤305中，为新的积分事务产生长整型UUID(Universally UniqueIdentifier，通用唯一识别码)，进入步骤306。

通过UUID，可以让分布式系统中的所有元素，都能具有唯一的辨识信息。

在步骤306中，判断为新的积分事务产生长整型UUID是否成功，如果不成功，进入步骤309，如果成功，进入步骤307。

其中，如果产生了新的UUID，表示为新的积分事务产生长整型UUID是成功。

在步骤307中，将新积分结果存入到积分历史变动表，进入步骤308。

本公开通过积分历史变动表，记录所有积分历史的变动，也方便查询过程记录。该步骤将新积分结果存入到积分历史变动表。

在步骤308中，将新积分记录插入到积分结果表，进入步骤310。

本公开通过积分结果表，记录所有积分记录结果，可以查询到所有的积分记录。该步骤将新积分记录插入到积分结果表。

在步骤309中，发送报警信息，进入步骤311。

在步骤310中，判断将新积分记录插入到积分结果表是否成功，如果不成功，进入步骤309，如果成功，进入步骤311。

其中，如果积分结果表显示了新积分记录，表示新积分记录插入到积分结果表是成功。

在步骤311中，结束流程。

由该实施例可见，本公开按照积分事务发生的先后顺序，记录每个会员的积分结果的过程，并将积分过程的相关数据存储到大数据分布式存储引擎，以供后续进行兑分结算。

图4是本公开根据一示例性实施例示出的数据清算处理方法中兑分类数据清算处理过程示意图。该过程也是基于基本的数据分析挑选出兑分类数据，对挑选出的兑分类数据再分析出有无依赖关系，按不同依赖关系进行不同处理。

本公开方案中，兑分过程与相关传统清算过程不同的是，本公开方案在分布式计算的过程中是优先保证兑分过程按照先进先出的业务规则进行。先进先出的业务规则是指同一个用户，越早积分的分数，在兑分的时候越早被兑换使用。先进先出的业务规则在本公开方案中是整个清算过程中的核心部分。本公开在数据清算处理过程中，根据同一个会员按时间顺序来处理，但也可能存在不同会员之前的分数转移，这就是对应分析数据所得到的复杂兑分部分(含依赖关系的数据)。另外，相关技术中传统的清算过程只对待清算数据本身进行清算，无论是财务类(金额类)还是积分类的数据清算，都不需依赖于历史的清算结果，而本公开方案的清算兑分过程，则利用了历史数据例如以前某一天或历史上某一天清算完的积分剩余余额的数据，再进行处理。

本公开的方案，通过提前分析设定时间段(例如1小时或半小时等)内要处理的兑分类数据，根据兑分类数据之间的逻辑关系分析数据之间的依赖关系，可以分析出哪部分数据相互依赖，从而得到特定的清算顺序。然后，将具有不同数据依赖关系的兑分类数据采用不同方式进行清算处理，即对于没有依赖的数据采用一种方式进行处理，对于有依赖关系的数据采用另外一种方式处理，并且处理过程中按照所得到的清算顺序进行处理。

本公开方案，通过提前分析兑分类数据，确定出兑分类数据之间的相互依赖关系，可以得到以下两部分数据：

A无依赖关系的兑分类数据：即每一条数据的清算过程相互不影响，清算时点没有特定要求，只需要保证一条交易数据清算生产的多个清算结果在同一个事务中即可。

B含依赖关系的兑分类数据：即交易数据在清算过程中有特定的清算顺序，数据之间相互依赖，清算结果相互影响，部分数据清算结果同样需在同一个事务中。

其中，依赖关系的分析依据是可以根据兑分类数据本身的特点进行分析，数据与数据之间是有逻辑关系，例如第一条数据有交易流水编号，第二条交易数据某个字段写明了关联第一条的交易流水编号，这就是一种逻辑上的依赖关系。

其中，关于清算过程中特定的清算顺序，可以有多种，常见的例如兑分换物品后又发生退货，那么退货的清算需要在兑分之后；又例如用户A发起将积分转给用户B，那么用户B接收的这笔积分的清算需在用户A转移积分之后。

如图4所示的流程，本公开的兑分过程包括以下步骤：

在步骤401中，获取所有未兑分事务，对其中的简单兑分事务进行兑分。

本公开的方案中，对于已经清算过的数据不会再重复清算。该步骤中，获取所有未兑分事务，先对其中的简单兑分事务进行兑分。

本公开的兑分处理可以分为简单兑分和复杂兑分。其中简单兑分就是指没有依赖关系、没有先后处理的顺序关系、清算结果不相互影响的那一部分数据，也即前面提到的提前分析数据所得到的无依赖关系的那一部分兑分类数据。其中复杂兑分是指数据需有一个先后关系，或需先清算完部分数据然后才再清算另外的数据，因为清算结果要依次传递，即相互依赖。

简单兑分对应无依赖关系，对于无依赖关系的兑分类数据的清算，本公开选择采用分布式计算引擎Impala，并利用结构化查询语言Impala SQL(Structured QueryLanguage，结构化查询语言)来分组并行清算实现，其中每组内还是可以按照先进先出的业务规则处理。本公开通过分布式计算引擎Impala结合分布式存储引擎HDFS(HadoopDistributed File System，Hadoop分布式文件系统)，充分利用大数据平台的超强计算能力，能够实现海量数据(十亿级以上)的处理。其中，Impala是一种新型查询系统，它提供SQL语义，能查询存储在Hadoop的HDFS和HBase(Hadoop Database，一个结构化数据的分布式存储系统)中的PB级大数据。Impala的最大特点是快速，另外也是一种支持并发处理的技术，HDFS是用来存储并发处理产生的结果，而HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库，HBase基于列的而不是基于行的模式。

因为该类型情况下是处理无依赖关系的数据，所以不需要关注依赖关系，能够允许并发处理，因此该类型的数据清算采用并发处理方式，分组并行清算，因此可以提高处理效率。但是，每组内还是可以按照先进先出的业务规则处理。

在步骤402中，判断兑分是否成功，如果不成功，进入步骤411，如果成功，进入步骤403。

兑分后，如果积分记录相应扣除兑换的分数，表示兑分成功。

在步骤403中，为新兑分过程记录表产生长整型UUID。

通过UUID，可以让分布式系统中的所有元素，都能具有唯一的辨识信息。该步骤中，根据兑分情况，为新兑分过程记录表产生长整型UUID。

在步骤404中，判断为新兑分过程记录表产生长整型UUID是否成功，如果不成功，进入步骤411，如果成功，进入步骤405。

其中，如果产生了新的UUID，表示为新兑分过程记录表产生长整型UUID是成功。

在步骤405中，对其中的复杂兑分事务进行兑分，进入步骤406。

复杂兑分对应含依赖关系，对于含依赖关系的兑分类数据的清算，因兑分类数据包含交易且具有特定的清算顺序数据，本公开的方案采用分布式计算引擎Spark，按照具体依赖关系对待清算数据进行分组，同一类依赖关系的数据清算时分在一组以保证清算结果在同一组事务中，然后按照业务规则，按特定的依赖顺序进行清算处理。也就是说，该步骤在兑分类数据为含依赖关系的情况下，在同一类依赖关系的数据分组内，根据先进先出的业务规则和由依赖关系所确定的清算顺序，对兑分类数据进行处理，但是各不同组还是可以并行进行清算处理以提高效率。需说明的是，分组数量可以在1～1000间进行动态调整，充分利Spark分布式计算的优点，保证特定清算顺序的前提下，还能大批量高并发清算积分数据。

本公开的方案中，可以将待处理的兑分类数据依据业务开展的交易类型进行分类，例如可以分成两类但不局限于此。

其中一类属于会员个人属性类别。该类别只涉及会员个人的处理，例如不管会员是积分还是兑分操作，均是自身独立完成，不影响其他会员。另外一类是属于非会员个人属性类别。该类别涉及会员可能存在个人的处理但该处理也涉及与其他会员的联系，例如将自已的积分转给别的会员，或是别的会员转了积分给本会员等情况。

针对第一类属于会员个人属性类别的数据，本公开的方案是可以按会员进行分组，同时可以分成很多组，而每组都同时处理数据，即并行处理各组的数据；但是，每组会员维度的清算也即每组内的结算则是串行处理，即依次按时间顺序处理。也就是说，从单个会员角度看是一条条串行处理，但是各个会员的数据则是分别同时并行处理。

针对第二类数据属于非会员个人属性类别的数据，所有的会员根据依赖关系均在一个组，数据是按交易时间的先后顺序处理。

需说明的是，本公开方案的业务规则包括先进先出、先积分先被兑的时间顺序但不局限于此，本公开在兑分方面的业务规则还可以包括商户优先规则或分数高规则等。

在步骤406中，判断兑分是否成功，如果不成功，进入步骤411，如果成功，进入步骤407。

兑分后，如果积分记录相应扣除兑换的分数，表示兑分成功。

在步骤407中，将简单兑分和复杂兑分结果合并到临时表，进入步骤408。

本公开在清算过程中，临时表是作为中间结果表，使用中间结果表存储清算结果，并不直接更新最终结果表。通过中间结果表设计，隔离了中间清算过程与最终结果表数据，一旦中间计算过程中遇到错误，只需要舍弃清算结果重新清算，无需对最终结果表做任何改变，保障了历史清算成功的结果不受干扰。

在步骤408中，判断合并是否成功，如果不成功，进入步骤411，如果成功，进入步骤409。

其中，在临时表如果都能显示简单兑分和复杂兑分的结果，对应关系也准确，表示合并成功。

在步骤409中，对兑分结果进行基本验证，进入步骤410。

清算过程中，本公开采用严格的清算规则验证机制，通过内部校验逻辑，保证清算结果的正确性。本公开可以采用相关技术中的清算规则验证机制进行基本验证，本公开对此并不加以限定。

关于兑分结果进行基本验证，也是基于数据的逻辑关系进行验证，例如，如果是兑分100分，不管来源于哪些商户，总和就需要是消耗用户100分，不能多也不能少。

在步骤410中，判断验证是否成功，如果不成功，进入步骤411，如果成功，进入步骤412。

其中，如果逻辑关系验证正确，表示验证成功。

在步骤411中，发送报警信息，进入步骤413。

在上述每个判断过程中，如果出现任何错误，都会发送报警信息，可以通知维护人员进行人工检查，确保数据无误才进行下一轮的清算。

在步骤412中，将更新的兑分过程记录插入到兑分过程历史表，更新积分余额和兑分过程历史表，进入步骤413。

本公开通过兑分过程历史表，记录所有兑分历史的变动，也方便查询过程记录。兑分后，相应也会更新积分结果表中的积分余额。

需说明的是，如果流程中出现任何错误，会终止任何更新操作，并发出报警通知维护人员进行人工检查，确保数据无误才进行下一轮的清算。

本公开方案中清算结果主要包含清算积分余额结果和清算兑分结果。

关于清算积分余额结果，需要在清算过程中不断更新，本公开的方案选择采用支持更新的大数据存储引擎Kudu。相关技术中是采用关系型数据库中的存储过程技术，有很强的事务性以及随时方便更新数据的特点。本公开方案采用的Kudu是运行在Hadoop平台上的列式存储系统，支持水平扩展，具有高可用性。

关于清算兑分结果，本公开的方案是保存到HDFS存储中，本公开方案中的存储格式选择了Parquet的列式存储结构。相关技术中采用的是关系型数据库，关系型数据库的存储结构是行式结构，关系型数据库更新数据方便，有统一的强事务性特点，可以满足多条数据清算处理结果在同一个事务中的要求；而本公开方案采用HDFS Parquet存储的优势包括：与Imapla集成深度优化，使用方便且性能好；扩容和数据高可用支持非常好。进一步的，本公开为了提供查询性能，清算兑分结果可以采用按天分区设计但不局限于此，每天产生的结果存储到当天分区中。

在步骤413中，结束流程。

需说明的是，本公开的方案还考虑了清算过程中的事务保证。在清算过程中有可能因为各种原因导致清算失败，可能是硬件原因、资源竞争原因或者其他不可预见的原因等，这就需要清算出错后能够支持数据回滚，保证只有正确数据才会存储到最终结果中，所以为了达到以上目的，本公开方案中主要采用了以下几种措施来保证数据的正确性：

1)清算过程中，使用中间结果表存储清算结果，并不直接更新最终结果表。通过中间结果表设计，隔离了中间清算过程与最终结果表数据，一旦中间计算过程中遇到错误，只需要舍弃清算结果重新清算，无需对最终结果表做任何改变，保障了历史清算成功的结果不受干扰。

2)清算过程中，对清算结果均执行镜像处理，为后续进行追溯回滚提供依据。

3)清算过程中，采用严格的清算规则验证机制，通过内部校验逻辑,保证清算结果的正确性。

4)清算完成后，中间结果表会合并到最终结果表中。如果清算过程中出现任何错误，会终止任何更新操作，并发出报警通知维护人员进行人工检查，确保数据无误才进行下一轮的清算。如果数据出现错误，则自动清理本次清算的所有数据，重新运行清算过程。

为便于理解，以下以一个应用实例举例说明：

本公开方案中，积分类似于用户存钱，兑分类似于用户消费。

用户A积分的场景可能如下：

用户id	积分商户(用户从哪个商家积分)	积分数量	积分时间
				A	1000012商户	+20	2019-07-10 10：00：00
A	1000013商户	+120	2019-07-10 11：20：00
				A	1000014商户	+80	2019-07-11 11：20：00
A	1000012商户	+1000	2019-07-12 11：00：00

其中，用户A总共可用分1220分，如果用户A在之后兑分花掉800分，则利用本公开的方案可以清算出这800分按积分的先后顺序，分别来源于以下的商户：

用户id	积分商户(用户从哪个商家积分)	兑换积分数量	积分余额
				A	1000012商户	-20	0
A	1000013商户	-120	0
				A	1000014商户	-80	0
A	1000012商户	-580	420

其中，最后一笔积分(1000分)，剩下只有420分可用，用户A未来兑分可以从该420分中用于兑换抵扣直到为0。也就是说，表格中的420分是剩下的积分，会在后期被用来兑分，而新增加的积分余额是积分1000分就有1000分，这1000分被在后期被同一个用户兑换消耗掉，可能是消耗部分，那就会剩下一部分积分，剩下的积分是基础来源分。

需说明的是，对于用户A而言，上述过程他是无感知的，用户A只关注总分数量多少或兑分数量，但是采用本公开的方案可以处理得到这积分来源于哪个商户及对应结算多少钱，进一步根据清算处理结果可以与商户进行结算。

从上述内容可以发现，本公开的技术方案包括以下有益效果：

1)可以实现海量数据的处理。因为底层选用的是大数据技术中的Spark技术结合Impala工具，可以分布式计算海量数据，并以分布式文件HDFS存储清算结果。

2)可以根据特定的业务规则和按特定的清算顺序清算数据。因为本公开方案可以提前分析待清算数据，确定待清算数据之间的依赖关系，并确定出待清算数据之间的顺序，所以可以实现按指定顺序或无序清算数据，克服相关技术中存在的缺陷，扩展了使用场景。

3)可以解决清算结果相互依赖的问题。

4)可以解决清算结果以分布式文件HDFS存储的强事务性。因为存在清算结果相互依赖，会出现一笔清算产生多笔清算结果的情况，本公开方案中的多笔清算结果都可以成功生成至HDFS文件中。本公开方案可以解决清算过程中结果相互依赖相互影响，清算结果以分布式文件HDFS存储的前提下，结果数据能满足事务最终一致性，要么均清算成功，要么均清算失败。

需说明的是，本公开的方案，可以实现T+0(当天)海量积分交易数据清算过程，按照用户积分的先进先出业务规则，在用户无感知跨商户兑分、先积分先使用的情况下，计算出积分平台与各商户产生的本场积兑、跨场积兑的结算金额，为用户多处积分各处兑分使用的业务模式提供统一的清算与结算。本公开的方案可以实现T+0处理，也表示本公开方案的清算效率高。

还需说明的是，本公开方案不但可以应用于T+0场景，也可以应用于T+1、T+2场景等，可根据需要进行选择。

与前述应用功能实现方法实施例相对应，本公开还提供了一种数据清算处理装置、计算设备及相应的实施例。

图5是本公开根据一示例性实施例示出的一种数据清算处理装置的示意图框图。

该装置可以是位于终端设备或计算机设备中。参照图5，在一种数据清算处理装置中可以包括：获取模块51、分析模块52、处理模块53。

获取模块51，用于获取待清算数据。

所述待清算数据可以包括积分类数据和兑分类数据等。

分析模块52，用于分析所述待清算数据的业务特征。

其中可以根据交易类型分析出清算数据是积分类数据或兑分类数据。

处理模块53，用于根据所述分析模块52分析出的所述待清算数据的业务特征分析结果，对所述待清算数据执行不同处理。

处理模块53可以将根据交易类型分析出的积分类数据，根据时间顺序例如根据先进先出的业务规则进行清算处理；在所述积分类数据清算处理完成后，将根据交易类型分析出的兑分类数据进行数据特性分析，根据分析出的依赖关系结果，采用不同方式进行清算处理。

由该实施例可见，本公开的方案在获取待清算数据后，分析所述待清算数据的业务特征；根据所述待清算数据的业务特征分析结果，对所述待清算数据执行不同处理。通过上述处理，无论数据是否包含特定处理顺序，数据清算逻辑是否相互依赖，本公开的方案都能相应进行处理，因此实现了扩展使用场景，更好进行海量数据清算处理，更好满足了数据清算要求。

图6是本公开根据一示例性实施例示出的一种数据清算处理装置的另一示意图框图。

该装置可以是位于终端设备或计算机设备中。参照图6，在一种数据清算处理装置中可以包括：获取模块51、分析模块52、处理模块53、选择模块54、优化模块55。

其中获取模块51、分析模块52、处理模块53的功能可以参见图5中的描述，此处不再赘述。

所述处理模块53包括：积分类数据子模块531、兑分类数据子模块532。

积分类数据子模块531，用于将根据交易类型分析出的积分类数据，根据时间顺序进行清算处理。

兑分类数据子模块532，用于在所述积分类数据子模块531的积分类数据清算处理完成后，将根据交易类型分析出的兑分类数据进行数据特性分析，根据分析出的依赖关系结果，采用不同方式进行清算处理。

其中依赖关系的分析依据是可以根据数据本身的特点进行分析，数据与数据之间是有逻辑关系，例如第一条数据有交易流水编号，第二条交易数据某个字段写明了关联第一条的交易流水编号，这就是一种逻辑上的依赖关系。该步骤根据积分数据之间的逻辑关系，将所述积分数据的依赖关系划分为含依赖关系或无依赖关系。

其中兑分类数据子模块532可以包括：第一兑分处理子模块5321、第二兑分处理子模块5322。

第一兑分处理子模块5321，用于在所述兑分类数据为含依赖关系的情况下，根据串行原则进行清算处理。

第二兑分处理子模块5322，用于在所述兑分类数据为无依赖关系的情况下，根据分组并行原则进行清算处理。

其中，所述第一兑分处理5321在所述兑分类数据为含依赖关系的情况下，根据串行原则进行清算处理，包括：在所述兑分类数据为含依赖关系的情况下，将兑分类数据按会员分组且含依赖关系的会员分为同组，每组内根据先进先出的业务规则和由依赖关系所确定的清算顺序，串行进行清算处理，各组并行进行清算处理。

其中，所述第二兑分处理子模块5322在所述兑分类数据为无依赖关系的情况下，根据分组并行原则进行清算处理，包括：在所述兑分类数据为无依赖关系的情况下，将兑分类数据按会员分组，各组并行进行清算处理，每组内根据先进先出的业务规则，串行进行清算处理。

选择模块54，用于对于积分类数据，选择分布式计算引擎Impala并采用ImpalaSQL进行清算处理；或，对于无依赖关系的兑分类数据，选择分布式计算引擎Impala并采用Impala SQL进行清算处理，对于含依赖关系的兑分类数据，选择分布式计算引擎Spark进行清算处理；或，在进行数据存储时，选择大数据存储引擎Kudu进行存储。

优化模块55，用于在进行清算处理的过程中，使用中间结果表存储清算结果，和/或，对清算结果执行镜像处理；在清算处理完成后，将所述中间结果表合并到最终结果表中。

图7是根据一示例性实施例示出的一种计算设备的结构示意图，该计算设备可用于实现上述数据清算处理方法。

参见图7，计算设备700包括存储器710和处理器720。

处理器720可以是一个多核的处理器，也可以包含多个处理器。在一些实施例中，处理器720可以包含一个通用的主处理器以及一个或多个特殊的协处理器，例如图形处理器(GPU)、数字信号处理器(DSP)等等。在一些实施例中，处理器720可以使用定制的电路实现，例如特定用途集成电路(ASIC，Application Specific Integrated Circuit)或者现场可编程逻辑门阵列(FPGA，Field Programmable Gate Arrays)。

存储器710可以包括各种类型的存储单元，例如系统内存、只读存储器(ROM)，和永久存储装置。其中，ROM可以存储处理器720或者计算机的其他模块需要的静态数据或者指令。永久存储装置可以是可读写的存储装置。永久存储装置可以是即使计算机断电后也不会失去存储的指令和数据的非易失性存储设备。在一些实施方式中，永久性存储装置采用大容量存储装置(例如磁或光盘、闪存)作为永久存储装置。另外一些实施方式中，永久性存储装置可以是可移除的存储设备(例如软盘、光驱)。系统内存可以是可读写存储设备或者易失性可读写存储设备，例如动态随机访问内存。系统内存可以存储一些或者所有处理器在运行时需要的指令和数据。此外，存储器710可以包括任意计算机可读存储媒介的组合，包括各种类型的半导体存储芯片(DRAM，SRAM，SDRAM，闪存，可编程只读存储器)，磁盘和/或光盘也可以采用。在一些实施方式中，存储器710可以包括可读和/或写的可移除的存储设备，例如激光唱片(CD)、只读数字多功能光盘(例如DVD-ROM，双层DVD-ROM)、只读蓝光光盘、超密度光盘、闪存卡(例如SD卡、min SD卡、Micro-SD卡等等)、磁性软盘等等。计算机可读存储媒介不包含载波和通过无线或有线传输的瞬间电子信号。

存储器710上存储有可执行代码，当可执行代码被处理器720处理时，可以使处理器720执行上文述及的上述数据清算处理方法。

上文中已经参考附图详细描述了根据本公开的上述方法。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

此外，根据本公开的方法还可以实现为一种计算机程序或计算机程序产品，该计算机程序或计算机程序产品包括用于执行本发明的上述方法中限定的上述各步骤的计算机程序代码指令。

或者，本公开还可以实施为一种非暂时性机器可读存储介质(或计算机可读存储介质、或机器可读存储介质)，其上存储有可执行代码(或计算机程序、或计算机指令代码)，当所述可执行代码(或计算机程序、或计算机指令代码)被电子设备(或计算设备、服务器等)的处理器执行时，使所述处理器执行根据本发明的上述方法的各个步骤。

本领域技术人员还将明白的是，结合这里的公开所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。

附图中的流程图和框图显示了根据本公开的多个实施例的系统和方法的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标记的功能也可以以不同于附图中所标记的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上已经描述了本公开的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims (6)

1.一种数据清算处理方法，其特征在于，包括：

获取待清算数据；

分析所述待清算数据的业务特征；

根据所述待清算数据的业务特征分析结果，对所述待清算数据执行不同处理；

其中，所述根据所述待清算数据的业务特征分析结果，对所述待清算数据执行不同处理，包括：

将根据交易类型分析出的积分类数据，根据时间顺序进行清算处理；

在所述积分类数据清算处理完成后，将根据交易类型分析出的兑分类数据进行数据特性分析，根据分析出的依赖关系结果，采用不同方式进行清算处理，其中包括：

在所述兑分类数据为含依赖关系的情况下，根据串行原则进行清算处理；或，

在所述兑分类数据为无依赖关系的情况下，根据分组并行原则进行清算处理。

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

所述在所述兑分类数据为含依赖关系的情况下，根据串行原则进行清算处理，包括：

在所述兑分类数据为含依赖关系的情况下，将兑分类数据按会员分组且含依赖关系的会员分为同组，每组内根据先进先出的业务规则和由依赖关系所确定的清算顺序，串行进行清算处理，各组并行进行清算处理；

所述在所述兑分类数据为无依赖关系的情况下，根据分组并行原则进行清算处理，包括：

在所述兑分类数据为无依赖关系的情况下，将兑分类数据按会员分组，各组并行进行清算处理，每组内根据先进先出的业务规则，串行进行清算处理。

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

对于积分类数据，选择分布式计算引擎Impala并采用Impala SQL进行清算处理；或，

对于无依赖关系的兑分类数据，选择分布式计算引擎Impala并采用Impala SQL进行清算处理，对于含依赖关系的兑分类数据，选择分布式计算引擎Spark进行清算处理；或，

在进行数据存储时，选择大数据存储引擎Kudu进行存储。

4.根据权利要求1至3任一项所述的方法，其特征在于，所述方法还包括：

在进行清算处理的过程中，使用中间结果表存储清算结果，和/或，对清算结果执行镜像处理；

在清算处理完成后，将所述中间结果表合并到最终结果表中。

5.一种数据清算处理装置，其特征在于，包括：

获取模块，用于获取待清算数据；

分析模块，用于分析所述待清算数据的业务特征；

处理模块，用于根据所述分析模块分析出的所述待清算数据的业务特征分析结果，对所述待清算数据执行不同处理；

其中所述处理模块包括：

积分类数据子模块，用于将根据交易类型分析出的积分类数据，根据时间顺序进行清算处理；

兑分类数据子模块，用于在所述积分类数据子模块的积分类数据清算处理完成后，将根据交易类型分析出的兑分类数据进行数据特性分析，根据分析出的依赖关系结果，采用不同方式进行清算处理；

其中所述兑分类数据子模块包括：

第一兑分处理子模块，用于在所述兑分类数据为含依赖关系的情况下，根据串行原则进行清算处理；或，

第二兑分处理子模块，用于在所述兑分类数据为无依赖关系的情况下，根据分组并行原则进行清算处理。

6.根据权利要求5所述的装置，其特征在于，所述装置还包括：选择模块和/或优化模块；其中，

选择模块，用于对于积分类数据，选择分布式计算引擎Impala并采用Impala SQL进行清算处理；或，对于无依赖关系的兑分类数据，选择分布式计算引擎Impala并采用ImpalaSQL进行清算处理，对于含依赖关系的兑分类数据，选择分布式计算引擎Spark进行清算处理；或，在进行数据存储时，选择大数据存储引擎Kudu进行存储；

优化模块，用于在进行清算处理的过程中，使用中间结果表存储清算结果，和/或，对清算结果执行镜像处理；在清算处理完成后，将所述中间结果表合并到最终结果表中。

Images