一种流数据合并处理方法及装置

技术领域

本发明涉及计算机技术领域，尤其涉及一种流数据合并处理方法及装置。

背景技术

目前信息数据处理领域中，流数据是较为常见的一种应用场景，一组顺序、大量、快速、连续到达的数据序列通常被定义为流数据。流数据是一种动态的实时数据，相对于静态批数据而言，每次处理的数据量少但是对于处理系统的稳定性、可靠性要求高，系统短时间内的故障就会导致数据的丢失或错误。对处理性能的时延要求高，基本在秒级、毫秒级之内；而批处理的性能要求可以在分钟或小时的数量级范围。

而对于流数据中多个数据流之间的合并处理，目前常见的一些方法包括将不同流的数据分别存入数据库后在通过批处理的方法将关联的数据进行合并，这种方法的效率较为低下，存在较高的时延，不能满足一些要求时效性较高的应用场景；传统的流数据处理方法是直接对于不同流的数据在接收到时就做对应处理，但是这种方法要求数据流到达的时间相近，如果时间相差较大，需要在消息队列中缓存较多的数据，且通过消息队列作为缓存处理性能较低，时间间隔越大、数据量越大就越为明显。

发明内容

本发明为解决现有的数据流合并处理效率低、时延高的问题，所采用的技术方案是：一方面，发明提供了一种流数据合并处理方法，包括如下步骤：

消息队列接收到流数据；

读取消息队列中查询数据流主题的数据，并提取公共身份识别，同时将查询事件主体作为一组键值对应存放在类数据库中；

接收消息队列中的主数据流；

基于主数据流中的待合并数据流事件，获取对应的主键信息及主键的状态；

将查询数据流与主数据流合并。

进一步改进为，所述主键的状态包括：阻塞、完成、未知、失败和正常；

如果获取到的主键的状态为阻塞状态，那么表示有其他的状态管理模块正在处理这条请求，直接跳过该请求处理下一条；

如果获取到的主键的状态为完成状态，那么表示该事件已经有其他模块处理完成，将完成的状态写回；

其他状态情况下，将该主键的状态修改为阻塞后写入状态存储，并继续后续流程；

对于返回错误的情况，将该事件推回到消息队列中的重试队列中，等待一定事件后再重新处理。

进一步改进为，所述将查询数据流与主数据流合并，包括：

对于正常的主键状态，数据流会进行合并处理，如果合并成功，得到已合并的数据流，将其写入到消息队列中的已合并的主题中，待对其进行存储，并把该消息的状态写为完成；

如果合并失败，将该消息也写入消息队列中的重试队列，消息的状态修改为失败，重试次数加一，重试次数超过一定数量之后就不再进行写回处理。

另一方面，本发明提供了一种流数据合并处理方法装置，包括：

消息队列模块，用于接收到流数据；

数据流读取模块，用于读取消息队列中查询数据流主题的数据，并提取公共身份识别，同时将查询事件主体作为一组键值对应存放在类数据库中；

状态管理模块，用于接收消息队列中的主数据流；

查询获取模块，用于基于主数据流中的待合并数据流事件，获取对应的主键信息及从状态存储模块中获取主键的状态；

数据流合并模块，将查询数据流与主数据流合并。

进一步改进为，所述主键的状态包括：阻塞、完成、未知、失败和正常；

如果查询获取模块获取到的主键的状态为阻塞状态，那么表示有其他的状态管理模块正在处理这条请求，直接跳过该请求处理下一条；

如果查询获取模块获取到的主键的状态为完成状态，那么表示该事件已经有其他模块处理完成，将完成的状态写回；

如果查询获取模块获取到的主键的状态为其他状态情况下，将该主键的状态修改为阻塞后写入状态存储模块，并继续后续流程；

对于查询获取模块查询时返回错误的情况，将该事件推回到消息队列模块中的重试队列中，等待一定事件后再重新处理。

进一步改进为，所述数据流合并模块，用于将查询获取模块获取的主键状态正常的数据流进行合并处理，如果合并成功，得到已合并的数据流，将其写入到消息队列中的已合并的主题中，待对其进行存储，并把该消息的状态写为完成；

如果合并失败，将该消息也写入消息队列中的重试队列，消息的状态修改为失败，重试次数加一，重试次数超过一定数量之后就不再进行写回处理。

再一方面，本发明还提供了一种流数据合并处理装置，包括：一个或多个处理器及存储器，所述存储器存储有程序，并且被配置成由所述一个或多个处理器执行以下步骤：

消息队列接收到流数据；

读取消息队列中查询数据流主题的数据，并提取公共身份识别，同时将查询事件主体作为一组键值对应存放在类数据库中；

接收消息队列中的主数据流；

基于主数据流中的待合并数据流事件，获取对应的主键信息及主键的状态；

将查询数据流与主数据流合并。

再一方面，本发明还提供了一种计算机可读存储介质，所述计算机可读存储介质包含计算机可执行的程序，所述程序可被处理器执行以完成以下步骤：

消息队列接收到流数据；

读取消息队列中查询数据流主题的数据，并提取公共身份识别，同时将查询事件主体作为一组键值对应存放在类数据库中；

接收消息队列中的主数据流；

基于主数据流中的待合并数据流事件，获取对应的主键信息及主键的状态；

将查询数据流与主数据流合并。

本发明的有益效果是：

本发明提供的流数据合并处理方法及装置，解决了数据落地后批处理的时效性差的问题，对于流数据的实时分析大大降低了延迟；也解决了传统流数据处理对于多个流合并的情况，较难解决的各个流之间时间关系不满足处理要求的问题；系统中多采用列式键值对的存储模型，通过主数据流和查询数据流的关联ID即可快速获取相关数据，也解决了部分数据在数据库存储时读取性能低的问题。

附图说明

下面结合附图和实施例对本发明进一步说明。

图1是本发明的流数据合并处理方法优选流程示意图；

图2是本发明的具体实施中的系统流程图；

图3是本发明的数据流合并流程图。

具体实施方式

为了使本申请所揭示的技术内容更加详尽与完备，可参照附图以及本申请的下述各种具体实施例，附图中相同的标记代表相同或相似的组件。然而，本领域的普通技术人员应当理解，下文中所提供的实施例并非用来限制本申请所涵盖的范围。此外，附图仅仅用于示意性地加以说明，并未依照其原尺寸进行绘制。

在本申请一个典型的配置中，终端、服务网络的设备和可信方均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的子单元或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁硬盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

如图1所示，一方面，发明提供了一种流数据合并处理方法，包括如下步骤：

S01，消息队列接收到流数据；

S02，读取消息队列中查询数据流主题的数据，并提取公共身份识别，同时将查询事件主体作为一组键值对应存放在类数据库中；

S03，接收消息队列中的主数据流；

S04，基于主数据流中的待合并数据流事件，获取对应的主键信息及主键的状态；

S05，将查询数据流与主数据流合并。

本发明提供的流数据合并处理方法及装置，解决了数据落地后批处理的时效性差的问题，对于流数据的实时分析大大降低了延迟；也解决了传统流数据处理对于多个流合并的情况，较难解决的各个流之间时间关系不满足处理要求的问题；系统中多采用列式键值对的存储模型，通过主数据流和查询数据流的关联ID即可快速获取相关数据，也解决了部分数据在数据库存储时读取性能低的问题。

进一步改进为，所述主键的状态包括：阻塞、完成、未知、失败和正常；

如果获取到的主键的状态为阻塞状态，那么表示有其他的状态管理模块正在处理这条请求，直接跳过该请求处理下一条；

如果获取到的主键的状态为完成状态，那么表示该事件已经有其他模块处理完成，将完成的状态写回；

其他状态情况下，将该主键的状态修改为阻塞后写入状态存储，并继续后续流程；

对于返回错误的情况，将该事件推回到消息队列中的重试队列中，等待一定事件后再重新处理。

进一步改进为，所述将查询数据流与主数据流合并，包括：

对于正常的主键状态，数据流会进行合并处理，如果合并成功，得到已合并的数据流，将其写入到消息队列中的已合并的主题中，待对其进行存储，并把该消息的状态写为完成；

如果合并失败，将该消息也写入消息队列中的重试队列，消息的状态修改为失败，重试次数加一，重试次数超过一定数量之后就不再进行写回处理。

另一方面，本发明提供了一种流数据合并处理方法装置，包括：

消息队列模块，用于接收到流数据；

数据流读取模块，用于读取消息队列中查询数据流主题的数据，并提取公共身份识别，同时将查询事件主体作为一组键值对应存放在类数据库中；

状态管理模块，用于接收消息队列中的主数据流；

查询获取模块，用于基于主数据流中的待合并数据流事件，获取对应的主键信息及从状态存储模块中获取主键的状态；

数据流合并模块，将查询数据流与主数据流合并。

进一步改进为，所述主键的状态包括：阻塞、完成、未知、失败和正常；

如果查询获取模块获取到的主键的状态为阻塞状态，那么表示有其他的状态管理模块正在处理这条请求，直接跳过该请求处理下一条；

如果查询获取模块获取到的主键的状态为完成状态，那么表示该事件已经有其他模块处理完成，将完成的状态写回；

如果查询获取模块获取到的主键的状态为其他状态情况下，将该主键的状态修改为阻塞后写入状态存储模块，并继续后续流程；

对于查询获取模块查询时返回错误的情况，将该事件推回到消息队列模块中的重试队列中，等待一定事件后再重新处理。

进一步改进为，所述数据流合并模块，用于将查询获取模块获取的主键状态正常的数据流进行合并处理，如果合并成功，得到已合并的数据流，将其写入到消息队列中的已合并的主题中，待对其进行存储，并把该消息的状态写为完成；

如果合并失败，将该消息也写入消息队列中的重试队列，消息的状态修改为失败，重试次数加一，重试次数超过一定数量之后就不再进行写回处理。

再一方面，本发明还提供了一种流数据合并处理装置，包括：一个或多个处理器及存储器，所述存储器存储有程序，并且被配置成由所述一个或多个处理器执行以下步骤：

消息队列接收到流数据；

读取消息队列中查询数据流主题的数据，并提取公共身份识别，同时将查询事件主体作为一组键值对应存放在类数据库中；

接收消息队列中的主数据流；

基于主数据流中的待合并数据流事件，获取对应的主键信息及主键的状态；

将查询数据流与主数据流合并。

再一方面，本发明还提供了一种计算机可读存储介质，所述计算机可读存储介质包含计算机可执行的程序，所述程序可被处理器执行以完成以下步骤：

消息队列接收到流数据；

读取消息队列中查询数据流主题的数据，并提取公共身份识别，同时将查询事件主体作为一组键值对应存放在类数据库中；

接收消息队列中的主数据流；

基于主数据流中的待合并数据流事件，获取对应的主键信息及主键的状态；

将查询数据流与主数据流合并。

本发明具体实施如下：

如图2和图3所示，本技术方案针对的场景为多数据流的合并处理，对于合并的数据流要求二者之间是有一定关联，通过某个字段可以进行对应的检索查询。对于基础用来查询的事件称之为查询数据流，此类事件作为整个流程的基础，需要关联的后续操作日志均基于该事件产生；后续操作的数据流称之为主数据流，当该数据流产生时，将该数据流的数据与查询数据流进行合并。总结，适用的场景需要满足两个基本要求：第一，合并的两数据流有一定的关联；第二，一个为查询数据流，作为主数据流的基础，任何一条主数据流理论上都有关联的查询数据流，且通常情况下查询数据流优先产生。

数据源接入与消息队列为公共的数据流入模块，采用较为通用的分布式消息队列模块可以满足系统的需求。

查询数据流的流程主要包括流读取模块，主要功能将消息队列中的查询数据流主题的数据读取，并提取公共身份识别(event ID)，即查询数据流与主数据流关联的内容，以及查询事件主体作为一组键值对应存放在列数据库中(目前采用HBase)。该数据库的特定可以支持海量数据，易于扩展，且通过键查询整条数据的性能高效，满足当前场景。数据流读取模块、完整事件存储以及ID存储三部分为查询数据流这条流程的主要部分。

主数据流的流程主要包括状态管理模块、状态存储、流数据合并模块、获取查询模块。其中，状态管理模块主要负责接收主数据流，数据流状态管理以及数据流转的工作。当状态管理接收到一个待合并的数据流事件后，根据系统配置信息获取主键信息，同时去状态存储模块获取对应主键的状态，状态的类型主要为以下几类，根据获取到不同的状态决定下一步流程，阻塞(PENDING)、完成(DONE)、未知(UNKOWN)、失败(FAILED)：

如果获取到的状态为阻塞状态(PENDING)，那么表示有其他的状态管理模块正在处理这条请求，直接跳过该请求处理下一条；

如果获取到的状态为完成状态(DONE)，那么表示该事件已经有其他模块处理完成，将完成的状态写回；

其他状态情况下，将该主键的状态修改为阻塞后写入状态存储，并继续下面的流程；

对于返回错误的情况，例如与状态存储模块连接异常时，无法获取状态，将该事件推回到消息队列中的重试队列中，等待一定事件后再重新处理

对于正常的状态，数据会流转到数据流合并模块进行处理，如果获取正确的处理结果，就会得到已合并的数据流，将其写入到消息队列中的已合并(joined)的主题中，待对其进行存储，并把该消息的状态写为完成(DONE)；如果合并失败，例如查询数据流不存在，网络连接失败等问题，将该消息也写入消息队列中的重试队列，消息的状态修改为失败(FAILED)，重试次数加一，重试次数超过一定数量之后就不再进行写回处理。

由于有状态管理模块的存在，数据流合并模块的原理相对简单明确，是一个无状态的模块，所有的合并模块均为一样的逻辑。主要功能就是接收由状态管理模块发送来的主数据，调用数据查询模块获取另外一半需要合并的数据，将二者合并后返回给状态管理模块。合并过程中，针对每一条事件有较大的延迟或者合并错误，均返回给状态管理模块一条错误的提示。

查询获取模块是用来通过ID转化到对应存储模块的偏移量快速获取事件内容，由于该模块的功能仅依赖于查询列数据库，可以通过缓存进一步提高该模块的性能。查询获取模块同样可以为系统中提供事件查询的微服务功能。

具体应用场景举例：

对于搜索引擎的应用场景，用户会产生大量的搜索操作，在一次搜索后会伴随着很多广告点击的操作。用户搜索的操作就可以看做场景中的查询数据流，而广告点击操作为主数据流，因为点击的操作总是出现在搜索操作之后，而且每一条点击的操作总是能够关联到一次搜索记录。对于该场景下，每次的点击操作想要关联到对应的搜索操作就可以使用上文中设计的系统，对于点击记录在存储之前就可以高效的做到实时关联搜索操作。通过实时对流数据合并处理后，可以更高效的对点击记录进行更多维度的分析。比如分析用户对某个广告感兴趣是在搜索哪些内容的时的比例更高，可以更为精准的推送广告内容。

该本技术方案同样可以支持多级数据流的合并，比如同样是搜索引擎的例子中，甚至可以对用户前后多次的搜索后再进行的点击进行逐级合并，通过最底层的一次操作触发前面的几次的搜索一并合并在一起。

对比现有的对不同数据流先做本地存储，再通过定时任务将两数据分别读出后进行合并关联的处理方法，本技术方案的方法与该方法相比较，最大的优势就是体现在实时性上，主数据在写入到数据库时就已经是处理完成的结果，而这个处理的过程也是要比在本地重新读出后再处理也是快的。

另外，对于一些流式数据处理的方法，本技术方案的方法优势在于有更高的稳定性和可靠性，对于一些数据前后时间交错的问题，现有的方法会无法处理，并且重试会导致系统性能降低，而本技术方案的方法解决了数据流异常的问题，可以在不影响系统性能的情况下，应对无法查找到查询数据流的问题。

本技术方案的方法解决了数据落地后批处理的时效性差的问题，对于流数据的实时分析大大降低了延迟；也解决了传统流数据处理对于多个流合并的情况，较难解决的各个流之间时间关系不满足处理要求的问题。系统中多采用列式键值对的存储模型，通过主数据流和查询数据流的关联ID即可快速获取相关数据，也解决了部分数据在数据库存储时读取性能低的问题。

以上述依据本发明的理想实施例为启示，通过上述的说明内容，相关工作人员完全可以在不偏离本项发明技术思想的范围内，进行多样的变更以及修改。本项发明的技术性范围并不局限于说明书上的内容，必须要根据权利要求范围来确定其技术性范围。