CN112527839A - 多源数据处理方法、系统、设备及存储介质 - Google Patents

Abstract

本说明书实施例提供了一种多源数据处理方法、系统、设备及存储介质，该多源数据处理方法，该方法包括：实时获取多个数据源的增量数据，并定期获取所述多个数据源的前一日日终数据；将所述增量数据进行流处理后进行本地存储，并将所述前一日日终数据进行批处理后进行本地存储；当接收到查询请求时，基于本地存储的流处理后或批处理后的数据处理所述查询请求。本说明书实施例可以提高处理多源数据查询请求的实时性。

Description

多源数据处理方法、系统、设备及存储介质

技术领域

本说明书涉及数据处理技术领域，尤其是涉及一种多源数据处理方法、系统、设备及存储介质。

背景技术

目前，不同种类的任务一般通过不同种类的业务子系统提供服务，每个业务子系统相当于一个数据源。当用户的查询请求为多源数据查询请求(即一个查询请求涉及多种不同种类的业务)时，需要从多个业务子系统获取数据并处理。由于这些业务子系统在物理上是往往分散的，在高并发场景下，这种方式数据处理量很大，实时性较差。

发明内容

本说明书实施例的目的在于提供一种多源数据处理方法、系统、设备及存储介质，以提高处理多源数据查询请求的实时性。

为达到上述目的，一方面，本说明书实施例提供了一种多源数据处理方法，包括：

实时获取多个数据源的增量数据，并定期获取所述多个数据源的前一日日终数据；

将所述增量数据进行流处理后进行本地存储，并将所述前一日日终数据进行批处理后进行本地存储；

当接收到查询请求时，基于本地存储的流处理后或批处理后的数据处理所述查询请求。

本说明书一实施例中，所述将所述增量数据进行流处理，包括：

将所述多个数据源的增量数据按照用户标识进行关联；

根据关联后的增量数据更新目标数据。

本说明书一实施例中，所述根据关联后的增量数据更新目标数据，包括：

根据关联后的增量数据计算各用户标识的一个或多个维度的指标值；

按照设定的排序算法对各用户标识的指定指标值进行排序，获得排序结果；

保存所述排序结果，以供外部系统调用。

本说明书一实施例中，所述将所述前一日日终数据进行批处理，包括：

将所述多个数据源的前一日日终数据按照用户标识进行关联；

根据关联后的前一日日终数据，对对应用户标识的前一日增量数据进行校正。

本说明书一实施例中，所述实时获取多个数据源的增量数据，包括：

实时监测所述多个数据源的二进制日志；

当监测到有数据源执行了表数据修改语句时，根据所述二进制日志实时获取对应的增量数据。

本说明书一实施例中，所述实时获取多个数据源的增量数据，包括：

接收所述多个数据源通过调用对应的应用程序接口实时推送的增量数据。

本说明书一实施例中，所述定期获取所述多个数据源的前一日日终数据，包括：

接收所述多个数据源定期推送的数据库日终镜像文件。

另一方面，本说明书实施例还提供了一种多源数据处理系统，包括：

流处理模块，用于实时获取多个数据源的增量数据，并将所述增量数据进行流处理后进行本地存储；

批处理模块，用于定期获取所述多个数据源的前一日日终数据，并将所述前一日日终数据进行批处理后进行本地存储；

查询处理模块，用于当接收到查询请求时，基于本地存储的流处理后或批处理后的数据处理所述查询请求。

另一方面，本说明书实施例还提供了一种计算机设备，包括存储器、处理器、以及存储在所述存储器上的计算机程序，所述计算机程序被所述处理器运行时，执行上述方法的指令。

另一方面，本说明书实施例还提供了一种计算机存储介质，其上存储有计算机程序，所述计算机程序被计算机设备的处理器运行时，执行上述方法的指令。

由以上本说明书实施例提供的技术方案可见，在本说明书的实施例中，多源数据处理系统可以实时获取多个数据源的增量数据，将增量数据进行流处理后进行本地存储，还可以定期获取多个数据源的前一日日终数据，并将前一日日终数据进行批处理后进行本地存储。如此，当接收到查询请求时，可以直接从本地存储的流处理后或批处理后的数据中，获取相关数据并进行处理以生成对应的查询响应。如此，这种直接从本地获取相关数据并处理的方式，与现有技术在收到查询请求时才从各个数据源远程获取数据并处理的方式相比，大大缩短了数据获取的时间，效率更高，从而提高了处理多源数据查询请求的实时性。

附图说明

为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1示出了本说明书一些实施例中多源数据处理方法的流程图；

图2示出了本说明书一些实施例中多源数据处理系统的示意图；

图3示出了本说明书一些实施例中多源数据处理系统的示意图；

图4示出了本说明书一实施例中多源数据处理过程的示意图；

图5示出了本说明书另一实施例中多源数据处理过程的示意图；

图6示出了本说明书一些实施例中多源数据处理系统的结构框图；

图7示出了本说明书一些实施例计算机设备的结构框图。

【附图标记说明】

61、流处理模块；

62、批处理模块；

63、查询处理模块；

702、计算机设备；

704、处理器；

706、存储器；

708、驱动机构；

710、输入/输出模块；

712、输入设备；

714、输出设备；

716、呈现设备；

718、图形用户接口；

720、网络接口；

722、通信链路；

724、通信总线。

具体实施方式

为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本说明书保护的范围。

本说明书实施例提供的多源数据处理方法可以用于多源数据处理系统中。其中，多源数据处理系统可以为用于多源数据处理的服务器或服务器集群。在本说明书一些实施例中，所述服务器可以为具有运算和网络交互功能的电子设备；在本说明书另一些实施例中，所述服务器也可以为运行于该电子设备中，为数据处理和网络交互提供业务逻辑的软体。在本说明书一实施例中，所述服务器可以与客户端进行数据交互。例如，所述服务器可以接收客户端发送的通信消息(如接收查询请求等)，并向客户端发送通信消息(如返回查询响应等)。

在本说明书一些实施例中，所述客户端可以为台式电脑、平板电脑、笔记本电脑、智能手机、数字助理、智能可穿戴设备等。其中，智能可穿戴设备可以包括智能手环、智能手表、智能眼镜、智能头盔等。当然，所述客户端并不限于上述具有一定实体的电子设备，其还可以为运行于上述电子设备中的软体。

参考图1所示，在本说明书一些实施例中，多源数据处理系统可以与多个业务子系统进行通信。因此，对于多源数据处理系统而言，一个业务子系统即为一个数据源，多个业务子系统可形成多个数据源。通过与多个业务子系统进行通信，多源数据处理系统可以实时获取多个业务子系统的增量数据，将增量数据进行流处理后进行本地存储；还可以定期获取多个业务子系统的前一日日终数据，并将前一日日终数据进行批处理后进行本地存储。因此，当用户通过客户端发起查询请求时，可以基于本地存储的流处理后或批处理后的数据处理查询请求。

上述每个数据源(或业务子系统)可以负责一类业务的服务。例如，在本说明书一实施例中，以金融领域的应用场景为例，数据源(或业务子系统)可以是基金系统、理财系统、信用卡系统、存款系统、贷款系统、生活缴费系统和外汇系统等中的任意一种等等。当然，这里仅是举例说明，在本说明书其他的实施例中，根据应用场景的不同，数据源(或业务子系统)也可以为其他任何系统。

结合图2所示，在本说明书另一些实施例中，多源数据处理系统还可以与除所述多个业务子系统之外的系统(以下称为外部系统)进行通信，该外部系统可以调用多源数据处理系统的处理结果，即外部系统可以调用本地存储的流处理后或批处理后的数据，以用于任何合适的用途。例如，在本说明书一实施例中，外部系统可通过订阅(Subscription)等方式获取多源数据处理系统的处理结果，并基于该处理结果触发外部系统的处理逻辑(在下文会具体说明有关于这部分内容的细节)。

参考图3所示，在本说明书一些实施例中，所述多源数据处理方法可以包括以下步骤：

S301、实时获取多个数据源的增量数据，并定期获取所述多个数据源的前一日日终数据。

S302、将所述增量数据进行流处理后进行本地存储，并将所述前一日日终数据进行批处理后进行本地存储。

S303、当接收到查询请求时，基于本地存储的流处理后或批处理后的数据处理所述查询请求。

在本说明书的实施例中，多源数据处理系统可以实时获取多个数据源的增量数据，将增量数据进行流处理后进行本地存储，还可以定期获取多个数据源的前一日日终数据，并将前一日日终数据进行批处理后进行本地存储。如此，当接收到查询请求时，可以直接从本地存储的流处理后或批处理后的数据中，获取相关数据并进行处理以生成对应的查询响应。如此，这种直接从本地获取相关数据并处理的方式，与现有技术在收到查询请求时才从各个数据源远程获取数据并处理的方式相比，大大缩短了数据获取的时间，效率更高，从而提高了处理多源数据查询请求的实时性。

在本说明书的实施例中，增量数据一般是指数据的实时增量。例如，若当前时刻的数据相对于前一时刻的数据发生了变化，即产生了实时增量。

在本说明一些实施例中，多源数据处理系统可以通过任何合适的方式实时获取多个数据源的增量数据。本说明书对此不作唯一限定，具体可以根据需要选择。

在本说明一实施例中，多源数据处理系统可以通过实时监控多个数据源的二进制日志(binlog)方式等，实时获取多个数据源的增量数据。因此，所述实时获取多个数据源的增量数据可以包括：实时监测所述多个数据源的二进制日志；当监测到有数据源执行了表数据修改语句时，根据所述二进制日志实时获取对应的增量数据。对于数据源为单库或简单应用场景(例如取单一数据)，采用实时监控数据源的二进制日志方式实时获取增量数据易于实现，从而有利于降低实现成本。

二进制日志一般包括二进制日志索引文件和二进制日志文件这两类文件。其中，二进制日志索引文件(例如文件名后缀为.index)用于记录所有的二进制日志文件；二进制日志文件(例如文件名后缀为.00000*)用于记录数据库所有的数据定义语言(DataDefinition Language，DDL)和数据操纵语言(Data Manipulation Language，DML)(除了数据查询语句)的语句事件。因此，通过实时监控每个数据源的二进制日志，可以实时发现每个数据源的数据变化情况，从而可以实时获取其增量数据。

比如，以采用MySQL数据库的数据源为例，MySQL的binlog是记录所有的数据库表结构变更(例如创建(CREATE)、修改(ALTER)数据表等)以及表数据修改(插入(INSERT)、更新(UPDATE)、删除(DELETE)等)的二进制日志。虽然，MySQL的binlog不会记录筛选(SELECT)和显示(SHOW)这类操作，因为这类操作对数据本身并没有修改，但可以通过查询通用的二进制日志来查看MySQL执行过的所有语句。

在本说明一实施例中，多源数据处理系统可以通过应用程序接口(ApplicationProgramming Interface，API)调用方式等，实时获取多个数据源的增量数据。在上文已经阐明，对于数据源为单库或简单应用场景，采用实时监控数据源的二进制日志方式实时获取增量数据易于实现。然而，当数据源为跨库(例如分库分表)或复杂应用场景(例如取多样复杂的数据等)时，通过二进制日志方式可能难以实现。在此情况下，可以考虑采用API调用的方式实现。应用程序接口又称为应用编程接口，是一组定义、程序及协议的集合，通过API接口实现多源数据处理系统与数据源之间的相互通信。API的一个主要功能是提供通用功能集。API同时也是一种中间件，为各种不同平台提供数据共享。良好的API接口设计可以降低系统各部分的相互依赖，提高组成单元的内聚性，降低组成单元间的耦合程度，从而提高系统的可维护性和可扩展性。

在一示例性实施例中，数据源在自身出现增量数据时，可以实时调用与多源数据处理系统之间的API接口，将增量数据主动推送给多源数据处理系统。因此，对于有所述多源数据处理系统而言，可以接收多个数据源通过调用对应的应用程序接口实时推送的增量数据，从而也可以实现实时获取多个数据源的增量数据。当然，在本说明书另一实施例中，数据源在自身出现增量数据时，也可以调用与多源数据处理系统之间的API接口，向多源数据处理系统发送一个数据更新事件通知，以便于多源数据处理系统在收到通知时，调用对应的API接口主动从数据源获取增量数据，如此也可以实现实时获取多个数据源的增量数据。

本领域技术人员可以理解，以上实时获取多个数据源的增量数据的方式仅为示例性说明。在本说明书其他的实施例中，根据需要还可以选择其他任何合适的方式。例如，除了监控二进制日志外，还可以通过触发器、时间戳和全表对比等方式取数据源的实时增量数据。其中，

触发器方式：在要抽取的表上建立需要的触发器，一般可以建立插入、修改、删除三个触发器，每当源表中的数据发生变化，就被相应的触发器将变化的数据写入一个临时表，抽取线程从临时表中抽取数据，临时表中抽取过的数据被标记或删除。触发器方式的优点是数据抽取的性能较高，缺点是要求业务表建立触发器，对业务子系统有一定的影响。

时间戳方式：它是一种基于快照比较的变化数据捕获方式，在源表上增加一个时间戳字段，系统中更新修改表数据的时候，同时修改时间戳字段的值。当进行数据抽取时，通过比较系统时间与时间戳字段的值来决定抽取哪些数据。有的数据库的时间戳支持自动更新，即表的其它字段的数据发生改变时，自动更新时间戳字段的值。有的数据库不支持时间戳的自动更新，这就要求业务子系统在更新业务数据时，手工更新时间戳字段。同触发器方式一样，时间戳方式的性能也比较好，数据抽取相对清楚简单，但对业务子系统也有一定的侵入性(加入额外的时间戳字段)，特别是对不支持时间戳的自动更新的数据库，还要求业务子系统进行额外的更新时间戳操作。另外，无法捕获对时间戳以前数据的删除和更新操作，在数据准确性上受到了一定的限制。

全表比对方式：典型的全表比对的方式是采用MD5校验码。ETL(Extract-Transform-Load)工具事先为要抽取的表建立一个结构类似的MD5临时表，该临时表记录源表主键以及根据所有字段的数据计算出来的MD5校验码。每次进行数据抽取时，对源表和MD5临时表进行MD5校验码的比对，从而决定源表中的数据是新增、修改还是删除，同时更新MD5校验码。MD5方式的优点是对源系统的侵入性较小(仅需要建立一个MD5临时表)，但缺点也是显而易见的，与触发器和时间戳方式中的主动通知不同，MD5方式是被动的进行全表数据的比对，性能较差。

数据源的实时增量数据仅反映了数据源当前时刻相对于前一时刻的数据变化情况。而用户的查询请求不仅可以是针对实时情况的查询，还可能是针对历史情况的查询。因此，为了有利于全面提高查询处理效率，还可以获取多个数据源的历史数据。在本说明书的实施例中，当每日日终后，数据源会统计并核算截止到该日日终时各用户标识对应的业务历史数据。因此，可以通过定期获取多个数据源的前一日日终数据的方式获取历史数据。

为了保证数据源的数据安全性，数据源可以对每日日终数据进行镜像(Mirroring)，即可以生成每日日终数据的镜像文件。其中，镜像是一种文件存储形式，是冗余的一种类型，一个磁盘等存储资源上的数据在另一个磁盘等存储资源上存在一个完全相同的副本即为镜像。在本说明书的实施例中，可以将多源数据处理系统作为多个数据源的镜像服务器，即多个数据源可以将镜像文件定期同步至多源数据处理系统进行备份。因此，在本说明书一实施例中，所述定期获取多个数据源的前一日日终数据可以为：接收多个数据源定期推送的数据库日终镜像文件。在单库场景下，可以把日终数据做成一个镜像文件。在多库场景下，可以把日终数据做成多个镜像文件。

应当指出的是，类似于获取多个数据源的实时增量数据，本说明书对于定期获取多个数据源的前一日日终数据的方式，也不作唯一限定。在本说明书其他的实施例中，根据需要可以选择其他任何合适的方式获取。例如，数据源获得每日日终数据后，可以向多源数据处理系统发送一个通知，多源数据处理系统收到通知后可以从数据源批量捞取对应的日终数据。

本说明书的实施例中，流处理是指一种大数据处理手段，其主要特点是待处理的数据(即增量数据)是源源不断且实时到来的。在本说明书一实施例中，根据实际需要流处理可以是普通的流处理，也可以是分布式流处理。其中，分布式流处理是一种面向动态数据的细粒度处理模式，基于分布式内存，对不断产生的动态数据进行处理。流处理具有快速、高效、低延迟等特性，在大数据处理中发挥越来越重要的作用。

本说明书一些实施例中，对所述增量数据进行流处理的处理逻辑，可以根据实际应用场景自定义。并且根据需要，流处理的处理逻辑可以是一种算子或多种算子的组合。例如，在一示例性实施例中，所述将所述增量数据进行流处理可以包括以下步骤：

(一)、将所述多个数据源的增量数据按照用户标识进行关联(join)。

本说明书实施例中的用户标识用于唯一识别一个用户。在本说明书一实施例中，所述用户标识例如可以为用户的用户名标识、账户标识等。

每种数据源一般是提供一种类型的业务，从而只能得到一种业务数据。当一个用户标识涉及多种类型的业务时，就可以将多个数据源的增量数据按照用户标识进行关联(join)。若每个数据源的增量数据是一个数据表，则关联可以是指将两张或两张以上的数据表进行连接操作(即将两张或两张以上的数据表整合为一张数据表)。例如，在一示例性实施例中，数据源1和数据源2分别提供了基金业务和理财业务，对应的增量数据分别为下表1和表2。而数据源1和数据源2的增量数据按照用户标识进行关联后，可以则得到下表3。

表1

序号	用户标识	基金金额(元)
			1	小明	5000
2	小花	1000
			3	小强	8000
…	…	…

表2

序号	用户标识	理财金额(元)
			1	小明	7000
2	小花	11000
			3	小强	3000
…	…	…

表3

(二)、根据关联后的增量数据更新目标数据。

在获得关联后的增量数据后，利用关联后的增量数据可以进行任何逻辑计算(或处理)，具体可以根据实际应用场景自定义。例如，在一示例性实施例中，所述根据关联后的增量数据更新目标数据，可以包括：

1)、根据关联后的增量数据计算各用户标识的一个或多个维度的指标值。例如，以图4所示的应用场景为例，两个数据源为理财系统和基金系统，计算指标值为总资产。则根据关联后的理财增量数据和基金增量数据可以计算出每个用户标识的总资产。例如，T日当前时刻获得了用户A的新的理财增量数据(用户A刚刚赎回了2000元的理财)和新的基金增量数据(用户A刚刚购买15000元的基金)，在此之前，用户A的理财金额为5000元，基金金额为3000元，则据此可以计算得到用户A当前的总资产＝5000元-2000元+3000元+15000元＝21000元。其他用户的可以通过类似方式计算得到。

2)、按照设定的排序算法对各用户标识的指定指标值进行排序，获得排序结果。

例如，以图4所示的应用场景为例，两个数据源为理财系统和基金系统，计算指标值为总资产。则可以得到当前时刻各用户标识的总资产排序(例如从高至低排序)。

3)、保存所述排序结果，以供外部系统调用。

在本说明书实施例中，每个排序结果可以带有对应的时间戳，以便于当外部系统调用时，可以获取到最新的排序结果。以图5所示的应用场景为例，两个数据源为理财系统和基金系统，计算指标值为总资产，外部系统为奖励券推送系统。当奖励券推送系统获取到最新的总资产排序后，可以对总资产排序中的一部分用户标识进行奖励券奖励。例如，可以对总资产排序前100名用户各奖励一张电子券，或者可以其中总资产额度达到设定额度的用户各奖励一张电子券等等。当奖励券推送系统确定奖励对象后，可以直接或通过短信平台(也可以是其他平台)将电子券主动推送至用户终端(例如用户的移动终端等)。

以上图4和图5均为示例性举例说明，不应理解为对本说明书的限制。在本说明书其他的实施例中，外部系统的处理逻辑可以根据应用场景自定义。

例如，在本说明书另一实施例中，外部系统可以为风险分析监控系统，通过获取并分析关联后的数据，还可以识别用户是否存在损失风险或欺诈风险等，便于在识别出损失风险或欺诈风险时，及时作出响应(例如及时向用户发出提醒或及时终止相关交易等)，从而有利于避免或减少损失。

例如，在本说明书另一实施例中，外部系统还可以为实现主动将流处理或批处理的处理结果推送给用户，以方便订阅该服务的用户可以获取相关信息。

例如，在本说明书另一实施例中，流处理或批处理的处理结果还可以作为外部系统分析用户行为偏好的依据，以便于根据分析结果向用户进行信息推荐(例如向用户推荐其可能感兴趣的金融产品)。

在本说明书一些实施例中，所述将所述前一日日终数据进行批处理可以包括：

1)、将所述多个数据源的前一日日终数据按照用户标识进行关联。

这里的关联与上述增量数据的关联类似，具体可以参见上文中有关于增量数据的关联部分的内容，在此不再赘述。

2)、根据关联后的前一日日终数据，对对应用户标识的前一日增量数据进行校正。

由于网络链路、系统稳定性等不可预知的原因，实时增量数据无法保证其正确性，而每日日终数据具有极高的准确性。因此，可以利用关联后的前一日日终数据对对应用户标识的前一日增量数据进行校正，并可以根据校正后的增量数据触发对应目标数据的校正；其中，目标数据可以是以前一日增量数据为输入(或输入之一)，通过指定的数据处理逻辑处理后得到的数据。例如，在本说明书一实施例中，可以根据校正后的增量数据触发对应排序的校正；其中，排序是以前一日增量数据为输入(或输入之一)，通过指定的排序算法处理后得到的数据。

例如，如图4或图5所示，当前日为T日，可以利用T-1日的日终数据，对T-1最后一个实时增量数据进行校正。比如，在一示例性应用场景下，T-1最后一个实时增量数据显示：用户B的资产为理财5345元，基金13303元。而根据T-1的日终数据，用户B的资产为：理财5344元，基金为13303元。据此可以将T-1最后一个实时增量数据中，用户B的资产更正为：理财5344元，基金13303元。在本说明书另一实施例中，这种校正还可以触发对应处理逻辑的重新计算。例如，可以基于校正后的数据触发对T-1最后的总资产排名的更正。因此，这种校正这对于后续查询各日的指标值具有重要意义。

需要指出的是，上述实时获取多个数据源的增量数据，并将所述增量数据进行流处理后进行本地存储，以及上述定期获取所述多个数据源的前一日日终数据，并将所述前一日日终数据进行批处理后进行本地存储，均与是否接收到用户的查询请求无关。即无论是否有用户发起查询请求，上述的处理均照常进行。

在本说明一些实施例中，多源数据处理系统可提供统一的查询接口层(类似于一个统一的查询服务前端)，不论用户通过何种方式进行何种查询，均可以通过统一的查询接口层进行处理。例如，当用户的查询为针对实时情况的查询请求时，可以根据流处理后的数据生成对应的查询响应；当用户的查询为针对历史情况的查询请求时，可以根据批处理后的数据生成对应的查询响应；当用户的查询为既包括实时情况也包括指定范围(例如最近一个月)内历史情况的查询请求时，可以根据流处理后的数据以及批处理后的数据生成对应的查询响应。

在本说明一些实施例中，在分布式环境下，上述的流处理和批处理也可以通过任何合适数据处理平台实现。例如，在本说明一实施例中，流处理可以基于Apache Flink等开源分布式流处理计算引擎实现。批处理可以基于Apache Hive等开源数据仓库工具实现。

Apache Flink作为一种开源分布式流处理计算引擎，其针对数据流的分布式计算提供了数据分布、数据通信以及容错机制等功能。可以用来做批处理，即处理静态的数据集、历史的数据集。也可以用来做流处理，即实时地处理一些实时数据流，实时地产生数据的结果。总而言之，Apache Flink是数据流(Streams)上的有状态(Stateful)计算。ApacheFlink认为有界数据集是无界数据流的一种特例，所以说有界数据集也是一种数据流，事件流也是一种数据流。因此，Apache Flink可以用来处理任何的数据，可以支持批处理、流处理、甚至是人工智能等。有状态计算是指在程序计算过程中，在Apache Flink程序内部存储计算产生的中间结果，并提供给后续函数或算子计算结果使用。状态数据可以维系在本地存储中，这里的存储可以是Apache Flink的堆内存或者堆外内存，也可以借助第三方的存储介质。当然，用户也可以自己实现相应的缓存系统去存储状态信息，以完成更加复杂的计算逻辑。

Apache Hive是基于Hadoop(Hadoop是由Apache基金会所开发的分布式系统基础架构)的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供类SQL查询功能。Apache Hive本质是将SQL转换为MapReduce(一种应用于大规模数据集的并行运算编程模型)程序。因此，可以将Apache Hive理解为Hadoop的一个客户端，Apache Hive提交MapReduce程序到hadoop中的资源管理主节点，hadoop中的资源管理主节点去连接Hadoop分布式文件系统。Apache Hive主要用来做离线数据分析，比直接用MapReduce开发效率更高。

虽然上文描述的过程流程包括以特定顺序出现的多个操作，但是，应当清楚了解，这些过程可以包括更多或更少的操作，这些操作可以顺序执行或并行执行(例如使用并行处理器或多线程环境)。

与上述的多源数据处理方法对应，本说明书实施例还提供了一种多源数据处理系统。参考图6所示，在本说明书一些实施例中，所述多源数据处理系统可以包括：

流处理模块61，可以用于实时获取多个数据源的增量数据，并将所述增量数据进行流处理后进行本地存储；

批处理模块62，可以用于定期获取所述多个数据源的前一日日终数据，并将所述前一日日终数据进行批处理后进行本地存储；

查询处理模块63，可以用于当接收到查询请求时，基于本地存储的流处理后或批处理后的数据处理所述查询请求。

本说明书一些实施例中，所述将所述增量数据进行流处理，可以包括：

将所述多个数据源的增量数据按照用户标识进行关联；

根据关联后的增量数据更新目标数据。

本说明书一些实施例中，所述根据关联后的增量数据更新目标数据，可以包括：

根据关联后的增量数据计算各用户标识的一个或多个维度的指标值；

按照设定的排序算法对各用户标识的指定指标值进行排序，获得排序结果；

保存所述排序结果，以供外部系统调用。

本说明书一些实施例中，所述将所述前一日日终数据进行批处理，可以包括：

将所述多个数据源的前一日日终数据按照用户标识进行关联；

根据关联后的前一日日终数据，对对应用户标识的前一日增量数据进行校正。

本说明书一些实施例中，所述实时获取多个数据源的增量数据，可以包括：

实时监测所述多个数据源的二进制日志；

当监测到有数据源执行了表数据修改语句时，根据所述二进制日志实时获取对应的增量数据。

本说明书一些实施例中，所述实时获取多个数据源的增量数据，可以包括：

接收所述多个数据源通过调用对应的应用程序接口实时推送的增量数据。

本说明书一些实施例中，所述定期获取所述多个数据源的前一日日终数据，可以包括：

接收所述多个数据源定期推送的数据库日终镜像文件。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本说明书时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本说明书的实施例还提供了一种计算机设备。如图7所示，在本说明书一些实施例中，所述计算机设备702可以包括一个或多个处理器704，诸如一个或多个中央处理单元(CPU)或图形处理器(GPU)，每个处理单元可以实现一个或多个硬件线程。计算机设备702还可以包括任何存储器706，其用于存储诸如代码、设置、数据等之类的任何种类的信息，一具体实施方式中，存储器706上并可在处理器704上运行的计算机程序，所述计算机程序被所述处理器704运行时，可以执行根据上述方法的指令。非限制性的，比如，存储器706可以包括以下任一项或多种组合：任何类型的RAM，任何类型的ROM，闪存设备，硬盘，光盘等。更一般地，任何存储器都可以使用任何技术来存储信息。进一步地，任何存储器可以提供信息的易失性或非易失性保留。进一步地，任何存储器可以表示计算机设备702的固定或可移除部件。在一种情况下，当处理器704执行被存储在任何存储器或存储器的组合中的相关联的指令时，计算机设备702可以执行相关联指令的任一操作。计算机设备702还包括用于与任何存储器交互的一个或多个驱动机构708，诸如硬盘驱动机构、光盘驱动机构等。

计算机设备702还可以包括输入/输出模块710(I/O)，其用于接收各种输入(经由输入设备712)和用于提供各种输出(经由输出设备714)。一个具体输出机构可以包括呈现设备716和相关联的图形用户接口718(GUI)。在其他实施例中，还可以不包括输入/输出模块710(I/O)、输入设备712以及输出设备714，仅作为网络中的一台计算机设备。计算机设备702还可以包括一个或多个网络接口720，其用于经由一个或多个通信链路722与其他设备交换数据。一个或多个通信总线724将上文所描述的部件耦合在一起。

通信链路722可以以任何方式实现，例如，通过局域网、广域网(例如，因特网)、点对点连接等、或其任何组合。通信链路722可以包括由任何协议或协议组合支配的硬连线链路、无线链路、路由器、网关功能、名称服务器等的任何组合。

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

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

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

在一个典型的配置中，计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算机设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

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

本说明书实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理器来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各实施例均采用递进的方式描述，各实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书实施例的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (10)

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

实时获取多个数据源的增量数据，并定期获取所述多个数据源的前一日日终数据；

将所述增量数据进行流处理后进行本地存储，并将所述前一日日终数据进行批处理后进行本地存储；

当接收到查询请求时，基于本地存储的流处理后或批处理后的数据处理所述查询请求。

2.如权利要求1所述的多源数据处理方法，其特征在于，所述将所述增量数据进行流处理，包括：

将所述多个数据源的增量数据按照用户标识进行关联；

根据关联后的增量数据更新目标数据。

3.如权利要求2所述的多源数据处理方法，其特征在于，所述根据关联后的增量数据更新目标数据，包括：

根据关联后的增量数据计算各用户标识的一个或多个维度的指标值；

按照设定的排序算法对各用户标识的指定指标值进行排序，获得排序结果；

保存所述排序结果，以供外部系统调用。

4.如权利要求1所述的多源数据处理方法，其特征在于，所述将所述前一日日终数据进行批处理，包括：

将所述多个数据源的前一日日终数据按照用户标识进行关联；

根据关联后的前一日日终数据，对对应用户标识的前一日增量数据进行校正。

5.如权利要求1所述的多源数据处理方法，其特征在于，所述实时获取多个数据源的增量数据，包括：

实时监测所述多个数据源的二进制日志；

当监测到有数据源执行了表数据修改语句时，根据所述二进制日志实时获取对应的增量数据。

6.如权利要求1所述的多源数据处理方法，其特征在于，所述实时获取多个数据源的增量数据，包括：

接收所述多个数据源通过调用对应的应用程序接口实时推送的增量数据。

7.如权利要求1所述的多源数据处理方法，其特征在于，所述定期获取所述多个数据源的前一日日终数据，包括：

接收所述多个数据源定期推送的数据库日终镜像文件。

8.一种多源数据处理系统，其特征在于，包括：

流处理模块，用于实时获取多个数据源的增量数据，并将所述增量数据进行流处理后进行本地存储；

批处理模块，用于定期获取所述多个数据源的前一日日终数据，并将所述前一日日终数据进行批处理后进行本地存储；

查询处理模块，用于当接收到查询请求时，基于本地存储的流处理后或批处理后的数据处理所述查询请求。

9.一种计算机设备，包括存储器、处理器、以及存储在所述存储器上的计算机程序，其特征在于，所述计算机程序被所述处理器运行时，执行根据权利要求1-7任意一项所述方法的指令。

10.一种计算机存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被计算机设备的处理器运行时，执行根据权利要求1-7任意一项所述方法的指令。

Images