一种流数据滑动窗口聚集查询方法与流程

本发明涉及对流数据的处理，尤其涉及对流数据滑动窗口的聚集查询。

背景技术：

在计算机领域中，流数据指的是依照顺序连续传输的数据项。由于流数据连续地传输、并且没有边界，因而理论上无法读取全部流数据。对此，本领域提出“窗口”的概念，以对查询或运算在流数据上的作用范围进行限制。作为一种窗口类型，“滑动窗口”指的是采用固定大小窗口边界，在新的数据项到达时，将窗口的上界和下界均向前移动，使其包含新到达的数据项。其中，滑动窗口的窗口范围(range)指滑动窗口的大小；滑动窗口的更新间隔(slide)指窗口一次滑动的时间区间或数据项数目。

“流数据滑动窗口聚集查询”指的是依托于滑动窗口对流数据进行聚集查询，通过控制滑动窗口的窗口范围、更新间隔等来确定针对流数据中的哪些部分进行聚集查询。例如，在数据集上针对某一属性(下文称作聚集属性)执行诸如count、sum、avg等聚集操作时，在滑动窗口的范围内对进行操作的流数据进行查询。流数据滑动窗口聚集查询是一类常见的、也是重要的流数据查询，在各类应用系统中具有广泛的用途。以流数据滑动窗口聚集查询在智能交通系统中的一种应用为例，可以根据受测路网中采集到的车牌流数据，统计在选定时间段内监测点所采集到的车辆数目，即该监测点的车流量。举例说明，可以将流数据滑动窗口的范围设置为5分钟，更新间隔设置为1分钟。假设当前时刻为10：05分，则统计最近5分钟，即在10:00-10:05时间段内经过某监测点的车辆总数，由此在窗口范围为5分钟的窗口上进行一次聚集查询操作；在更新间隔1分钟后，即10：06分，统计在10:01-10:06时间段内经过该监测点的车辆总数，由此进行又一次聚集查询操作。

然而，传统的流数据滑动窗口聚集查询存在以下缺陷。

对于采用非服务形式的传统流数据滑动窗口聚集查询的技术而言，其无法提供可供第三方方便使用的接口。开发者为了获得聚集查询的结果，往往需要自行搭建相应的软件系统，例如在服务端和客户端分别搭建相应的软件来获取流数据、对数据进行预处理、以及编写查询模块代码等，致使增加了开发耗时和成本。

还有一种现有技术，采用了服务的形式来提供流数据滑动窗口聚集查询，然而其针对客户端的每次请求，服务端仅可以提供一次响应以反馈。为了对连续、不间断地到来的流数据进行聚集查询，需要客户端多次地向服务端提出请求，致使查询效率低、资源消耗高。

并且，发明人还发现，在现有技术中缺少针对聚集查询服务的计算模式选取的优化方案，致使计算开销大、聚集查询服务的服务响应延迟高。尽管，存在极个别的现有技术提出了针对聚集查询对多种计算模式进行优化选取，然而所述现有技术仍存在需要自行搭建相应软件系统的缺陷。

技术实现要素：

因此，本发明的目的在于克服上述现有技术的缺陷，提供一种流数据滑动窗口聚集查询方法，包括：

1)根据客户端的请求，在客户端与服务端之间建立http长连接；

2)在所述长连接的存续期间，由所述服务端根据所述请求向所述客户端推送滑动窗口中的数据。

优选地，根据所述方法，其中还包括：

3)当出现以下情况时，关闭所述http长连接，服务端释放为所述客户端分配的资源：

所述服务端收到来自所述客户端的要求关闭连接的信息；或者

所述服务端发送要求关闭连接的信息到达客户端；或者

所述服务端检测到所述客户端已关闭。

优选地，根据所述方法，其中步骤2)包括：

2-1)所述服务端根据用于采集流数据的监测点数目u、以及所述滑动窗口的数据量n，选择用于对流数据进行处理的计算模型。

优选地，根据所述方法，所述计算模型包括以下一种或多种：esper、hadoop、storm、spark。

优选地，根据所述方法，其中步骤2-1)包括：

2-11)所述服务端根据所述监测点数目u、所述滑动窗口的数据量n、以及预置的延迟查询表，选择服务响应的延迟最小的计算模型；

其中，所述延迟查询表所存储的表项被用于确定在相应的u、和n下服务响应的延迟最小的计算模型。

优选地，根据所述方法，其中所述延迟查询表所存储的表项为通过对在相应的u、和n下各个计算模型的真实延迟进行检测而确定。

优选地，根据所述方法，其中步骤2-1)包括：

2-12)所述服务端根据所述监测点数目u、所述滑动窗口的数据量n，利用延迟l与u和n的关系，计算出计算模型所对应的服务响应的延迟大小；

2-13)根据计算获得的结果，选择用于对流数据进行处理的计算模型。

优选地，根据所述方法，所述延迟l与u和n的关系为：l＝a×n+b×u+c，其中a、b、c为待确定的参数，a是n与l之间的斜率，b是u与l之间的斜率，c是直线的截距。

优选地，根据所述方法，其中所述参数a、b、c通过最小二乘法的方式以以下步骤计算获得：

2-12a)对中的参数a、b、c分别求导，并求导的结果等于0；

2-12b)对下述方程组进行求解，计算参数a、b、c，

2-12c)利用所获得的参数a、b、c以及l＝a×n+b×u+c，确定所述计算模型的延迟；

其中，i表示针对计算模型的第i组测量的标号，ui表示针对计算模型的第i组测量时所采用的监测点数目，ni表示针对计算模型的第i组测量时所采用的滑动窗口的数据量，li表示针对计算模型的第i组测量时实际发生的延迟。

以及，一种计算机可读存储介质，其中存储有计算机程序，所述计算机程序在被执行时用于实现如上述任意一项所述的方法。

与现有技术相比，本发明的优点在于：

通过本发明所提供的流数据滑动窗口聚集查询方法，对计算模式进行了优化选取，其相较于一般的服务在响应时间上得到优化，并且支持一次请求、连续响应的“流数据”服务。

并且，在本发明中还可以将流数据滑动聚集查询以web服务的方式提供至第三方，由第三方获取聚集查询的结果，从而简化聚集查询中对软件的开发过程，缩短开发周期。在结合web服务技术的基础上，针对聚集查询服务的计算模式选取的效率高的计算模式，从而达到提高查询效率、降低服务响应延迟的目的。

附图说明

以下参照附图对本发明实施例作进一步说明，其中：

图1是现有的基于服务方式的流数据滑动窗口聚集查询的技术方案进行信令交互的示意图；

图2是根据本发明的一个实施例对流数据滑动窗口聚集查询的信令交互的示意图；

图3是根据本发明的一个实施例在客户端与服务端实现流数据滑动窗口聚集查询的流程示意图；

图4是在不同的流数据到达速度下对esper、hadoop、storm、spark的计算模型的实际延迟的测试结果图；

图5是针对不同的统计任务以及不同的计算模型的实际延迟与采用本发明的方式所获得的预测延迟的对比图。

具体实施方式

下面结合附图和具体实施方式对本发明作详细说明。

如背景技术中所介绍地，现有技术中存在各种有待改进之处。以其中用服务的形式来提供流数据滑动窗口聚集查询的现有技术为例，图1示出了现有的用于流数据滑动窗口聚集查询的restful服务的客户端与restful服务的服务端的交互模式。参考图1，首先由客户端向服务端发送httpget请求以要求服务端为其推送数据，服务端根据接收到的get请求向客户端返回xml/json的响应结果以推送数据。至此，完成了一次对流数据滑动窗口聚集查询。

可以看到，在上述现有方法中，通过一次请求仅能获得一次针对数据查询的响应，无法通过单次的请求多次地获得对数据查询的响应。然而，对于流数据而言，数据连续不断地到来、连续不断地发生变化，这使得上述“请求-应答”一一对应的方式，需要由客户端不断地发出请求。这样的方式显然是低效的，难以满足对流数据进行查询的需求。

对此，发明人提出可以通过web的形式来提供对流数据滑动窗口聚集查询的服务，从而利用web服务的特性，使得客户端通过发送请求与服务端之间建立http长连接(long-livedconnection)，在所述http长连接维持期间，服务端可以持续地通过所述http长连接向客户端不断地返回推送数据的响应，直到服务端需要主动停止推送数据或者服务端收到来自客户端的停止请求，断开所述http长连接。

图2示出了根据本发明的一个实施例的流数据滑动窗口聚集查询的信令交互流程示意图。

假设，客户端期望获得s[p]→o的服务，其中s为希望获得的流数据滑动窗口聚集查询服务，p为输入的参数，o为输出的流数据内容。

参考图2，为了获得上述服务，则需要首先由客户端采用http标准协议的方式向服务端发送针对服务s的get请求以将参数p发往服务端。参考表1所示出的根据本发明的一个实施例的流数据聚集查询服务参数，所述get请求的url为“/servicename？id＝{id}”，其中，“servicename”是流数据聚集查询get请求的url路径，在“？”之后的“id＝{id}”是用于标明查询作业的id的查询字符串，以使得服务端可以根据接收到的id来向客户端反馈聚集查询的结果。这里应当理解，上述查询字符串仅是本发明所提供的一种形式，在本发明中还可以采用其他形式的查询字符串。

参考图2，收到所述get请求的服务端与所述客户端建立http长连接，并在所述长连接保持连接状态的期间向发出所述get请求的客户端推送流数据，例如每次推送与窗口范围相对应的数据。参考表1，响应于所述get请求，推送的内容是与所述查询作业id相对应的最新的聚集查询结果。在所述响应中，服务选项的内容为“output＝xml/json&range＝r&slide＝s”；其中，“output＝xml/json”表示服务的调用结果(这里即为聚集查询的结果)所采用的输出格式为xml格式、json格式；“range＝r”表示滑动窗口的范围为r，这里的r可以是一个字符串，例如“5m”，以表示滑动窗口的范围为5分钟；“slide＝s”表示滑动窗口的更新间隔为s，这里的s可以是一个字符串，例如“2m”，以表示滑动窗口的更新间隔为2分钟。通过上述服务选项，可以使得收到所述响应的客户端获知聚集查询的结果采用何种输出格式、以及滑动窗口的范围和更新间隔。这里应当理解，在本发明中还可以在所述响应中采用其他形式的服务选项。

表1

为了避免浪费资源，可以针对以下情况断开在客户端和服务端之间建立的http长连接：

i)客户端发出的关闭连接的信号到达服务端；如果客户端已经意外关闭，那么服务端在发送数据给客户端时，服务端往通道写数据会出现异常，服务端就会及时释放为这个客户端分配的资源；

ii)服务端主动发送的提示出错和关闭连接的信息到达客户端，同时释放资源、关闭连接；

iii)服务端定时地向客户端发送心跳信息，如果客户端已经关闭，服务端往通道写数据会出现异常，服务端也会及时释放资源、关闭连接。

从上述实施例可以看出，通过在服务端与所述客户端建立http长连接的方式可以支持一次请求、连续响应的“流数据”服务，从而满足对流数据的查询需求。

图3示出了根据本发明的一个实施例在客户端与服务端实现流数据滑动窗口聚集查询的流程示意图。参考图3，流数据不间断地被采集和获取，当客户端将服务请求发送至服务端时，收到该请求的服务端指示预测选择模块确定一种计算模型来对不间断地输入的流数据进行处理，完成所述处理过程的数据处理模块将聚集查询的结果(即处理后的数据)输入到与滑动窗口范围(例如窗口大小为n)相符合的中间存储模块中，在如图2所示出的每一次数据推送中，服务端均将存储在中间存储模块中的大小为n的数据作为一个整体提供至客户端。

这里的中间存储模块可以采用hbase作为存储介质，通过对hbase表结构中的rowkey(行键)的设计与选择，以应对不同类型的数据的业务。例如，可以将用于采集数据的监测点的id和时间戳组合起来以作为rowkey以提高查询效率。将查询常用的时间维度和id加入rowkey的原因在于，随着时间的推进，在一个监测点上会产生大量的数据，由于行键排序的特点，在物理上同一个监测点的数据存储位置会相对集中，将查询常用的时间维度和id加入rowkey，可以提供查询的效率。通过搭建hbase集群的方式可以支持高并发写入，为进一步提高写入性能并保证系统稳定，采用线程池技术对多线程进行管理和调度，并使用多线程对数据进行并发写入。

如图3所示出的，在进行滑动窗口聚集查询流数据时，还需要通过例如数据处理模块来对输入的流数据进行一定的处理操作，这样的处理操作可以采用一些常用的计算模型，例如以esper、hadoop、storm、spark等为代表的用于事件驱动处理、批处理、实时流处理、近实时小批处理的计算模型。然而，这样的处理操作需要时间来完成相应的计算，而这往往会为服务的响应带来一定的延迟。为了进一步提高上述采用http长连接的方案的效果，在本发明中还可以通过选择恰当的计算模型来缩短服务端的服务响应的延迟。这样做的目的在于，针对持续获取新查询结果的服务，服务消费者发起一个http请求调用流数据聚集查询服务，开始持久接收数据，这样的行为对处理及时性的要求更加迫切，若后台计算模型无法及时计算出最新结果，将影响服务消费者的应用效果或用户体验，因此有必要对后台多种计算模型进行优化选取。

基于上述思路，发明人针对不同的计算模型进行了试验。试验采用的是由3台(注：也可以多台)服务器搭建构成的esper、hadoop、storm、spark集群环境进行测试。其中，以esper为例，其以集中式的方式部署在主节点上，并且所述主节点服务器的配置为2核cpu、2.8g内存、40g外存，同时master节点也被用作计算节点；两台slave节点服务器配置为2核cpu、2.8g内存、10g外存。实验中采用的是模拟车牌流数据，其中将请求查询的元组定义为<t,k,v>，t表示时间戳，k表示监测点，v表示车牌。其中k符合齐夫分布，并且同一时间内k不能重复。

在进行试验时，首先通过数据发送程序(本实验实施例中采用了一种数据采集工具flumeclient)将文本文件中的实验数据发送到各个节点。随后，在hadoop、storm、spark集群中分别对模拟车牌流数据进行相同的对车流量进行统计的计算任务，记录计算的开始时间和结束时间，以作为测试所获得的计算延迟，并且针对每种框架进行15次测试。

表2示出了通过测试而获得的采用esper、hadoop、storm、spark的计算模型的实际延迟的结果。

表2

参考表2，测试所采用的窗口的窗口范围r、以及更新间隔均为500

秒，测试所采用的流数据服从齐夫分布(倾斜因子选自0～0.5的范围)，采集数据的监测点数目u为100000个，数据的到达速度以a表示(单位为元组/秒)，待处理窗口中的数据量n等于数据的到达速度a与窗口范围r的乘积，测试的结果包含在不同到达速度a时上述四种计算模型的延迟l(单位为秒)。

利用表2中的结果可以绘制出如图4中的示意图。参考图4，可以看出随着数据的到达速度a的增加，四种计算模型的延迟呈现为线性地递增。由此，可以推测出延迟l的大小随着n的增加而增加，并且这种递增趋势为线性地。

类似地，若控制变量使得数据的到达速度a保持不变，测试对于采用不同大小的u时上述四种计算模型的延迟，会发现类似的结果，即延迟l的大小随着u的增加而增加，并且这种递增趋势为线性地。

通过上述分析，发明人发现，对于上述四种计算模型而言，其计算所带来的延迟l的分布与流数据的待处理窗口的数据量n、监测点数目u之间存在近似于线性的关系：延迟l的大小随着n、以及u的增加而增加，并且所述分别近似于一条直线。

换句话说，对于n和u的大小不变的状况，所述计算模型的延迟l是确定的。并且，考虑到实际使用滑动窗口聚集查询服务的场景，通常情况下用于采集数据以产生流数据的监测点的数目u在设置后较长的时间内不会发生变化。因此，可以假设在监测点的数目u不会发生改变的情况下，预先针对不同的滑动窗口的窗口范围(所述窗口范围决定了待处理窗口的数据量n)，对各种计算模型的实际延迟进行测试、统计，例如多次测试在该计算模型下的实际延迟并求取平均值，将所述平均值记录作为所述模型在所述u、和所述n下的时延l。

例如，如表3中所示，在u取值不变的情况下，针对在不同的窗口范围分别测试esper、hadoop、storm、spark的计算模型的平均实际延迟。例如，测试出在待处理窗口的数据量为n1时，esper的延迟为l11，hadoop的延迟为l12，storm的延迟为l13，spark的延迟为l14。

表3

根据本发明的一个实施例，可以以延迟查询表的方式存储所述表2中的内容，在服务端收到需要提供流数据滑动窗口聚集查询服务的请求后，通过所述延迟查询表，从所支持的计算模式中选择使得延迟最小的计算模型对数据进行处理，以降低服务响应的延迟。

应当理解，所述延迟查询表还可以以其他形式进行存储。例如，可以在计算获得了如表3中的内容后，通过比较确定在相同u和n下延迟l最小的计算方式，并且仅存储在所述n下延迟最小的计算模型的标识即可，例如以字符串的形式存储计算模型的名称、或采用预先设定的标号来区分不同的计算模型以进行存储。例如，参考表3，针对u、n1，假设在四种计算模型中l12的取值最小，则在延迟查询表中将{u、n1、hadoop}作为一条表项进行存储；若针对u、n2，发现l23的取值最小，则在延迟查询表中将{u、n2、storm}作为一条表项进行存储，以此类推。这样的方式不必存储完整的表2的内容，可以节省延迟查询表所使用的存储空间，并且减少使用过程中对不同模式的延迟时间进行比较的计算量从而进一步地减少响应的时间。

还应当理解，对于监测点的数目u可能会发生改变的应用场景，也可以在延迟查询表中针对不同的u值分别存储在不同的n值下所选择的计算模型，例如以{u1、n1、hadoop}，{u1、n2、storm}…{u3、n1、spark}…的形式来存储各条表项。

如前文中所述，计算模型的延迟l由n和u的大小所确定，通常情况下对于多数使用场景，其所使用的窗口范围是固定的，因此也可以在延迟查询表中仅针对不同的u值来存储几个常用n值下所选择的计算模型。

可以看出，上述采用延迟查询表来存储在不同n和u的大小下应当选取哪一种计算模型的方式可以快速地确定用于对数据进行处理操作的计算模型。然而，延迟查询表所能存储的内容量是有限的，其无法遍历任意n和u的组合下所应当选择的计算模型。参考图4所示出的实验结果，为了可以更加准确地预测各个模型在不同的u和n下，在必要时还可以通过计算来预测不同模型的延迟大小。

根据本发明的一个实施例，通过计算来预测不同模型的延迟大小。如前文所述，对于计算模型esper、hadoop、storm、spark而言，其延迟l的大小与u和n之间存在线性关系，因此可以假设对于这些计算模型而言l与u和n之间的关系可以被表示为：l＝a×n+b×u+c，其中a、b、c为待确定的参数，a是n与l之间的斜率，b是u与l之间的斜率，c是直线的截距。

在该实施例中，可以针对每个模型，预先测量多组不同ui和ni的组合下实际发生的延迟li，i表示第i组测量的标号。在获得了所测量的结果后，通过以下方式计算参数a、b、c。

对s中的系数a、b、c求导，并令求导的结果等于0，则有

对上述方程组进行求解便可计算获得参数a、b、c的大小。

这里采用了最小二乘法的方式来计算参数a、b、c，然而应当理解本发明还可以采用其他方式来对所述参数进行计算。

通过上述延迟l的大小与u和n之间存在线性关系的假设，可以利用针对某一模型的多组不同u和n下计算模型的实际延迟l来预测所述模型在任意u和n下的延迟。

为了验证上述计算方式的准确性，发明人利用统计拟合的方式对通过上述方法计算获得的l＝a×n+b×u+c与真实测试出的延迟的拟合程度进行了评估，采用决定系数r²＝1-sse/sst来度量(williammendenhall,terrysincich《统计学》,机械工业出版社，2009年10月)，其中sse为误差平方和，sst为回归平方和。表4示出了计算出的决定系数r²的结果。

表4

根据拟合程度的原理，所获得的r²越接近于1，则拟合程度越高。可以看出，上述将延迟l的大小与u和n之间的关系表示为l＝a×n+b×u+c的方式可以很好地描述以及预测延迟的大小。

并且，发明人还针对四种不同的统计任务t1、t2、t3、t4对不同的计算模型进行了测试。表5示出了进行测试时所使用的统计任务t1、t2、t3、t4的参数。图5示出了采用表5中的数据进行测试的结果，其中横坐标为实际测试到的延迟大小，纵坐标为预测的延迟大小。可以看到，对于统计任务t1、t2、t3、t4而言，实际测试到的延迟与预测的延迟之间存在较高的回归线、基本符合一比一的关系，即预测准确度得到了保证。

为了综合上述两个实施例的优点，在本发明的另一个实施例中，还可以将上述延迟查询表的方式与上述预测计算模型的延迟的方式结合在一起。在使用时，优先判断在延迟查询表中是否存在与当前所使用的u和n对应的记录项，对于不存在所述记录项的情况则通过计算预测各个计算模型的延迟，以选择所使用的计算模型。

通过上述实施例可以看出，本发明可以支持一次请求、连续响应的“流数据”服务，并且具有较低的服务响应延迟。

最后所应说明的是，以上实施例仅用以说明本发明的技术方案而非限制。尽管上文参照实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，对本发明的技术方案进行修改或者等同替换，都不脱离本发明技术方案的精神和范围，其均应涵盖在本发明的权利要求范围当中。