一种基于自适应不解压直接计算的流处理方法和系统

1.本发明涉及一种基于自适应不解压直接计算的流处理方法和系统，属于大数据处理技术领域。


背景技术：

2.随着大数据的发展，流处理技术在当前的大数据时代变得越来越普遍。例如，2021年，全球联网物联网设备数量增长9％，有123亿个活动端点。流处理可以对大量连续到达的数据流元组进行分析和查询，如传感器数据和金融交易，其主要特点是低延迟和实时性要求。然而，随着数据流规模的不断增加，流处理系统面临着数据量带来的压力。
3.对如此大规模的流数据进行处理面临空间和时间上的双重挑战，一方面，大量的流数据给传输带宽带来了巨大的压力，如果网络传输中存在明显的延迟，则无法保证流处理的实时性；另一方面，流处理系统通常会将数据临时存储在内存中，如果数据到达的速率很高，也会给服务器的内存使用带来巨大压力。特别的，数据压缩作为减少数据大小的常用方法，在大数据领域中被广泛用来节省时间和空间开销，然而由于流数据实时变化的特点，单一的压缩算法难以满足流处理的需求。
4.现在有大量关于流处理系统的文献，但很少有研究关注流处理中的综合压缩方法，尤其是基于结构化查询语言(sql)的压缩流处理。在流处理中支持sql有助于用户以用户友好的方式处理数据，在压缩数据上直接进行sql处理有助于进一步提高系统性能。在现有的流引擎中，tersecades通过优化硬件架构来确保压缩流处理的性能，但它只使用简单的整数压缩方法和浮点压缩方法，没有多样的压缩方法和自适应的性能模型提供自适应处理。saber和finestream在异构cpu-gpu架构上执行sql流处理，但没有考虑流压缩。
5.在传统的数据库处理中，有更为多样的压缩算法支持，如ns、nsv、dict和bitmap。在succinct中，可以直接对输入数据的压缩表示进行高效查询。但流数据处理的特点与传统数据库有很大的不同，传统的数据库处理方法是在扫描完所有数据后进行整体操作，根据数据的总体特征选择压缩算法。在流处理中，无界的数据流实时地到达。流数据的动态特性主要体现在以下三个方面。首先，流数据的属性可以随时改变，包括值范围、重复程度等。随着流数据属性的改变，不同的压缩算法所能达到的压缩比也不尽相同。其次，受到数据生成速度和网络延迟等因素的影响，流数据的传输速率随时可能发生变化，从而影响系统的等待时间。第三，不可能预测数据属性变化的频率。由于数据流的特性是不可预测的，因此不能预先确定一个固定的解决方案来有效地处理。需要由动态的压缩方法进行处理。


技术实现要素：

6.针对上述问题，本发明的目的是提供一种基于自适应不解压直接计算的流处理方法和系统，能够根据性能模型，自适应地压缩流数据，并进行压缩状态下的直接处理，提高流处理系统的性能。
7.为实现上述目的，本发明采取以下技术方案：
8.第一方面，本发明提供一种基于自适应不解压直接计算的流处理方法，包括以下步骤：
9.确定待处理的流数据以及基于该待处理流数据的待执行应用；
10.实时选择对待处理的流数据性能最优的压缩算法，并在客户端对待处理流数据进行自适应压缩，得到压缩后数据；
11.基于客户端上所维护的可用的服务器资源队列，选择对待执行应用最合适的服务器，并将压缩后数据以及待执行的应用传输给相应服务器；
12.相应服务器根据采用的压缩算法，在压缩后数据上进行待执行应用的运行处理，得到流处理结果。
13.进一步，所述实时选择对待处理的流数据性能最优的压缩算法，并在客户端对待处理流数据进行自适应压缩，得到压缩后数据的方法，包括：
14.每隔一段处理批，预读入预设数量处理批的流数据元组，并统计其数据特性；
15.依据统计得到的数据特性，计算采用各种预设压缩算法所带来的总处理时间，选择总处理时间最少的压缩算法，作为本段处理批流数据的最优压缩算法；
16.基于确定的最优压缩算法，对本段处理批的流数据进行自适应压缩，同时记录本段处理批的流数据所采用的压缩方法和占用的字节数，作为最终的压缩后数据。
17.进一步，所述依据统计得到的数据特性，计算采用各种预设压缩算法所带来的总处理时间，选择总处理时间最少的压缩算法，作为本段处理批流数据的最优压缩算法，包括：
18.确定能够对流数据进行压缩处理的各种压缩算法，包括eg编码、ed编码、ns编码、nsv编码、bd编码、rle编码、字典编码和位图；
19.依据统计得到的数据特性，计算采用各种压缩算法所带来的总处理时间；
20.基于不同压缩算法的总处理时间，选择总处理时间最少的压缩算法，作为本段处理批流数据的最优压缩方法。
21.进一步，所述总处理时间的计算公式为：
22.t＝t
compress
+t
trans
+t
query
23.其中，t
compress
表示压缩用时，t
trans
表示传输用时，t
query
表示查询计算用时；
24.所述压缩用时t
compress
的计算公式为：
[0025][0026]
其中，a表示压缩算法是贪婪的还是懒惰的；t
wait
表示等待读入整个数据批所消耗的时间；表示压缩过程中用于访存的指令数；表示压缩过程中用于计算的指令数；n
client
表示客户端的处理性能；
[0027]
所述传输用时t
trans
的计算公式为：
[0028][0029]
其中，size
t
表示每个元组所占用的字节数；r表示所选择的压缩算法τ的压缩比；sizeb表示每个批的元组数量；latency表示网络的传输延迟；
[0030]
所述查询计算用时t
query
的计算公式为：
[0031][0032]
其中，表示在查询过程中用于计算的指令所消耗的时间；表示在该过程中用于内存读写的指令消耗的时间。
[0033]
进一步，所述基于客户端上所维护的可用的服务器资源队列，选择对待执行应用最合适的服务器，并将压缩后数据以及待执行的应用传输给相应服务器，包括：
[0034]
基于客户端上所维护的可用的服务器资源队列s，选择第一个剩余可用资源足够执行当前任务的服务器来负责当前任务；
[0035]
当服务器接收当前任务后，向所有客户端发送当前的可用资源信息，更新客户端上的服务器资源队列s，以供新任务的资源分配，并在完成任务后，向客户端返回结果时，同时发送更新的可用资源信息。
[0036]
进一步，所述第一个剩余可用资源足够执行当前任务的服务器，满足条件：
[0037]
①
memi≥memk,ci≥ck,gi≥gk；
[0038]
②
满足memj≥memk,cj≥ck,gj≥gk；
[0039]
其中，memi、memj和memk分别表示服务器si对应的空闲内存、服务器sj对应的空闲内存和当前任务所需要的内存；ci、cj和ck分别表示服务器si对应的cpu空闲率、服务器sj对应的cpu空闲率和当前任务所需要的空闲率；gi、gj和gk分别表示服务器si对应的cpu空闲率、服务器sj对应的cpu空闲率和当前任务所需要的空闲率。
[0040]
进一步，所述相应服务器根据采用的压缩算法，在压缩后数据上进行待执行应用的运行处理，得到流处理结果，包括：
[0041]
对于一个给定的输入数据流，假设其共有n个数据属性《col1,col2,
…
,coln》和m个待处理的运算操作序列《op1,op2,
…
,opm》；
[0042]
遍历运算操作序列，对于每个运算符opi，如果该运算在gpu上的性能更好，就将该运算分配给gpu，反之则分配给cpu；
[0043]
相应服务器基于客户端发送的与n个数据属性一一对应的所采用的压缩算法的集合《τ1,τ2,
…
,τn》以及压缩后数据所占用的字节数《bytes1,bytes2,
…
,bytesn》，对计算函数进行更新，并基于更新后的计算函数对相应运算符进行处理。
[0044]
第二方面，本发明提供一种基于自适应不解压直接计算的流处理系统，包括：
[0045]
输入模块，用于确定待处理的流数据以及基于该待处理流数据的待执行应用；
[0046]
自适应压缩模块，用于实时选择对待处理的流数据性能最优的压缩算法，在客户端对待处理流数据进行自适应压缩，得到压缩后数据；
[0047]
负载均衡模块，用于基于客户端上所维护的可用的服务器资源队列，选择对待执行应用最合适的服务器，并将压缩后数据以及待执行的应用传输给相应服务器；
[0048]
运算模块，用于相应服务器根据采用的压缩算法，在压缩后数据上进行待执行应用的运行处理，得到流处理结果。
[0049]
第三方面，本发明提供一种处理设备，所述处理设备至少包括处理器和存储器，所述存储器上存储有计算机程序，所述处理器运行所述计算机程序时执行以实现所述基于自适应不解压直接计算的流处理方法的步骤。
[0050]
第四方面，本发明提供一种计算机存储介质，其上存储有计算机可读指令，所述计
算机可读指令可被处理器执行以实现所述基于自适应不解压直接计算的流处理方法的步骤。
[0051]
本发明由于采取以上技术方案，其具有以下优点：
[0052]
1、本发明提出了包括压缩、传输、查询计算在内的多步性能模型，考虑了机器性能、网络条件等因素在内，用来估计流处理系统的性能。
[0053]
2、本发明在系统内集成了多种压缩算法，用于对不同特性数据的高性能处理。
[0054]
3、本发明结合性能模型，对流数据进行自适应压缩，自动切换压缩算法，适应流数据的特点，提高流处理性能。
[0055]
4、本发明通过负载均衡模块，在服务器之间进行负载均衡，提高了服务器的利用率。
[0056]
5、本发明可以在压缩数据上直接计算，避免了解压缩的延迟。
[0057]
因此，本发明可以广泛应用于大数据处理技术领域。
附图说明
[0058]
通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。在整个附图中，用相同的附图标记表示相同的部件。在附图中：
[0059]
图1是本发明实施例提供的基于细粒度自适应压缩的流处理方法流程图；
[0060]
图2是本发明实施例提供的压缩模块处理流程。
具体实施方式
[0061]
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例的附图，对本发明实施例的技术方案进行清楚、完整地描述。显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。基于所描述的本发明的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本发明保护的范围。
[0062]
需要注意的是，这里所使用的术语仅是为了描述具体实施方式，而非意图限制根据本技术的示例性实施方式。如在这里所使用的，除非上下文另外明确指出，否则单数形式也意图包括复数形式，此外，还应当理解的是，当在本说明书中使用术语“包含”和/或“包括”时，其指明存在特征、步骤、操作、器件、组件和/或它们的组合。
[0063]
本发明的一些实施例中，提供一种基于自适应不解压直接计算的流处理方法，首先通过基于性能模型的压缩算法选择器，为待处理的流数据实时选择性能最好的压缩算法进行压缩；然后将压缩后数据以及待执行的应用传输给最合适的服务器进行应用处理，得到流处理结果。本发明能够根据性能模型，自适应地压缩流数据，并进行压缩状态下的直接处理，提高流处理系统的性能。
[0064]
与之相对应地，本发明的另一些实施例中，提供一种基于自适应不解压直接计算的流处理系统、设备和介质。
[0065]
实施例1
[0066]
如图1所示，本实施例提供一种基于自适应不解压直接计算的流处理方法，其包括以下步骤：
[0067]
1)确定待处理的流数据以及基于该待处理流数据的待执行应用，也即sql语句；
[0068]
2)实时选择对待处理的流数据性能最优的压缩算法，并在客户端对待处理流数据进行自适应压缩，得到压缩后数据；
[0069]
3)基于客户端上所维护的可用的服务器资源队列，选择对待执行应用最合适的服务器，并将压缩后数据以及待执行的应用传输给相应服务器；
[0070]
4)相应服务器根据采用的压缩算法，在压缩后数据上进行待执行应用的运行处理，得到流处理结果。
[0071]
优选地，上述步骤2)中，在大数据流场景中，数据以流的方式传输，不能事先知道所有要处理的信息。随着输入数据流的动态变化，其实时处理方法需要自适应地改变。本发明中设计了一个针对压缩流处理系统的性能模型，根据该性能模型进行压缩算法的自适应选择。通过对输入流数据的指定特性的统计，可以估计采用各种压缩算法所带来的压缩比、需要执行的指令数、内存和时间的开销，进而计算采用对应压缩算法进行处理所需要的系统时间，最后选择耗时最少的压缩方法进行压缩。
[0072]
具体地，如图2所示，包括以下步骤：
[0073]
2.1)每隔一段处理批，预读入预设数量处理批的流数据元组，并统计其数据特性。
[0074]
其中，处理批的大小根据实际需要由用户设定的，本实施例将处理批的大小设定为100，预设数量批可以选择为5个处理批。
[0075]
本实施例对流数据元组的数据特性进行统计时，包括数据平均重复度，最大值和最小值，变化范围，前导零所占用的字节数等。本实施例以这5个处理批的流数据的数据特性统计结果，作为对接下来100个处理批的流数据特性的预测。
[0076]
2.2)依据统计得到的数据特性，计算采用各种预设压缩算法所带来的总处理时间，选择总处理时间最少的压缩算法，作为本段处理批流数据的最优压缩算法。
[0077]
2.3)基于步骤2.2)确定的最优压缩算法，对本段处理批的流数据进行自适应压缩，同时记录本段处理批的流数据所采用的压缩方法和占用的字节数，作为最终的压缩后数据。
[0078]
优选地，上述步骤2.2)，包括以下步骤：
[0079]
2.2.1)确定能够对流数据进行压缩处理的各种压缩算法。
[0080]
具体地，在本发明的压缩模块中，集成了八种轻量级的压缩算法，各自具有不同的特性，用于自适应的流压缩处理。这八种轻量级压缩算法的描述如下：
[0081]
①
elias gamma encoding(eg)
[0082]
eg编码使用前导零的个数来表示数据的二进制有效位。给定一个正整数x，令即用l表示x的二进制表示的位数。x的eg编码形式就是l个前导零再加上它的二进制表示，共计用2*l+1位来表示。
[0083]
②
elias delta encoding(ed)
[0084]
ed编码是eg编码的变体，对eg编码中得到的l再进行一次编码。给定一个正整数x，令x的ed编码形式为n个前导零，加上l+1的二进制表示，再加上x的二进制表示的最后l位，共计2*n+l+1位。相比之下，eg编码更适合压缩小整数，而ed编码更适合压缩大整数。
[0085]
③
null suppression with fixed length(ns)
[0086]
ns编码通过删除元素的二进制表示的前导零来完成压缩。因为数据在程序中的表示经常是用对齐的数据类型表示的，有很多冗余的前导零，因此可以删除前导零来节约空间。这种方法的编码结果长度固定，因此对于一组待压缩的数据，都统一按照删除前导零后的最长位数来对齐。
[0087]
④
null suppression with variable length(nsv)
[0088]
nsv编码与ns编码相似，也是通过删除前导零来完成压缩。区别是ns的压缩结果的位数相同，为了对齐还会有冗余的前导零存在，而nsv则完全删除了前导零，但需要用额外的标志位来记录压缩后数据的位数。相比之下，ns编码更适合压缩一组二进制表示的长度比较接近的数据，而nsv编码对二进制编码长度不确定的数据压缩效果会显著好于ns。
[0089]
⑤
base-delta encoding(bd)
[0090]
bd编码在一组待压缩的数据中，选定一个基值并记录，然后对于所有元素，都用该元素与基值的差值来表示。因此，如果元素之间的变化值远小于元素本身，就可以占用更少的位数。
[0091]
⑥
run length encoding(rle)
[0092]
rle编码是一种传统的编码方式，用key-value的键值对来表示元素以及它连续出现的长度。例如，字符串“aaaabbbbbccc”可以被编码为[a,4][b,5][c,3]，因此对于频繁重复出现的数据有很好的压缩效果。
[0093]
⑦
dictionary(dict)
[0094]
字典编码将一个大范围的数据一一映射到一个小范围的字典中，例如字符串“ababc”，可以将“a”编码为“00”，“b”编码为“01”，“c”编码为“10”。字典编码对于变化范围较大，但是取值较少的数据有很好的效果。
[0095]
⑧
bitmap(bitmap)
[0096]
位图使用一个二进制串来完成对数据的映射，二进制串中的每一位都对应一个原始数据。例如对于字符串“aabccd”，里面的每个元素都可以映射为一个4位的二进制串，“a”对应“0001”，“b”对应“0010”，“c”对应“0100”，“d”对应“1000”，即a对应二进制串中的最低位，d对应最高位。因为数据的取值越多，就会导致二进制串越长，因此位图只适合取值很少的数据。
[0097]
每种压缩算法都有各自的优缺点，它们适用于具有不同特性的数据流。例如，elias gamma编码和elias delta编码分别适用于小数值和大数值，游程编码适用于重复次数较多的数据，ns和nsv的压缩效果取决于元素中的冗余前导零。本发明将这八种轻量级压缩算法分为两类：贪婪的(eager)和懒惰的(lazy)。其中elias gamma编码，elias delta编码，ns编码和nsv编码属于贪婪的压缩算法，另外四种属于懒惰的压缩算法。贪婪的压缩算法在输入的部分元组到达时立即进行压缩，与之相比，懒惰压缩算法等待整个要处理的数据批进入后再进行压缩。贪婪压缩算法的优点在于可以在不等待的情况下即时处理每个元组，而懒惰算法的优点在于可以更好地利用大量相似的冗余数据来获得更高的压缩比。
[0098]
本实施例以一个来自智能电网的数据集作为分析案例，其中包含了超过40.55亿个能源消耗测量数据，来自于在一个月内测量分布在40个住宅中的2125个插头。数据集中包含七个属性，包括时间戳、能耗值、插头和房子的id等。对于实时生成的电能消耗数据，流数据的特性是不断变化的。电力消费的高峰和低谷，以及不同家庭的不同用电习惯，都会导
致数据流的不断变化。由于不能预测数据的变化趋势，因此在流处理中，所采用的处理方法需要具有实时性、动态性，能够自动适应数据流的特性变化。
[0099]
例如，当一个家庭在很短的时间内生成大量的电力消耗数据时，在数据流中会表现为连续重复的房屋id和不断变化的插头id及能耗值，此时对于短时间内的小范围时间戳变化，可能采用base-delta编码，对于连续重复的房屋id，可能采用游程编码(rle)，而对于变化的插头id，则可能采用字典编码(dict)，或者去除冗余的前导零(ns)等压缩方法。当许多家庭在同一时间产生用电数据时，房子的id可能会经常变化，而时间戳保持不变，此时可能对时间戳采用游程编码压缩，对房屋id采用字典编码压缩等。这样，可能对第一段数据采用“base-delta，rle，dict”的压缩组合，对第二段数据采用“rle，dict，ns”的压缩组合。随着流数据特性的变化，本发明中对数据流的压缩方法在不断变化，为数据流中的每一列属性都独立选择性能最优的处理方法。
[0100]
2.2.2)依据统计得到的数据特性，计算采用各种压缩算法所带来的总处理时间。
[0101]
为了指导系统在运行时自动选择合适的压缩算法，本实施例提出了一个性能模型。提出压缩流处理成本模型的难点主要在于处理过程和场景的复杂性。在本发明的处理场景中，本发明考虑了机器性能、网络条件和其他广泛的因素，并通过一个多步模型来解决上述困难。考虑到本发明的处理主要包括三个阶段：压缩、传输和查询计算，本发明建立了压缩流处理在这三个阶段下的系统性能模型，将压缩流处理系统的总处理时间t表示为：
[0102]
t＝t
compress
+t
trans
+t
query
ꢀꢀꢀ
(1)
[0103]
其中，t
compress
表示压缩用时，t
trans
表示传输用时，t
query
表示查询计算用时。
[0104]
之后，对这三个阶段的处理时间分别进行计算。
[0105]
①
压缩用时t
compress
[0106]
对于一个选定的压缩算法τ，本发明使用来表示在压缩算法的处理过程中，用于内存访问的指令数目，用表示用于计算操作的指令数目。由于压缩在客户端进行，因此需要将客户端的处理性能考虑在内，用n
client
表示。对于计算密集型程序，客户端处理性能用cpu频率来表示；对于访存密集型程序，客户端处理性能则用内存读写速度来表示。同时，不同压缩算法需要进行操作的总指令数可以预先计算，这样就可以将压缩算法的性能与客户端机器性能结合起来，得到压缩阶段的时间开销。同时，对于贪婪的压缩算法，会随着数据的到来立刻进行压缩，而懒惰的压缩算法需要等待一整个待处理的数据批，因此本发明使用α
·
t
wait
表示压缩算法τ的等待时间，其中α定义为：
[0107][0108]
综上，压缩用时t
compress
的计算公式为：
[0109][0110]
其中，α表示压缩算法是贪婪的还是懒惰的；t
wait
表示等待读入整个数据批所消耗的时间；表示压缩过程中用于访存的指令数；表示压缩过程中用于计算的指令数；n
client
表示客户端的处理性能。
[0111]
②
传输用时t
trans
[0112][0113]
其中，size
t
表示每个元组所占用的字节数，这是由输入数据的格式所确定的；r表示所选择的压缩算法τ的压缩比(压缩前字节数/压缩后字节数)，也即压缩后的元组大小就是size
t
/r；sizeb表示每个批的元组数量，这样，对于一个压缩后的批，需要传输的字节数就是size
t
·
sizeb/r，即需要传输的数据量取决于所采用的压缩算法的压缩比，压缩比越高的算法，在传输性能上越有优势；latency表示网络的传输延迟。
[0114]
在传输过程中，需要将网络状况考虑在内，当网络带宽充足，即每秒传输的字节数小于该网络每秒所能传输的最大字节数，不需要考虑数据排队的延迟时，t
trans
采用式(4)计算；如果网络带宽被完全占用，即每秒传输的字节数大于该网络每秒所能传输的最大字节数，大量数据需要排队等待时，t
trans
的计算则由下式(5)计算：
[0115][0116]
③
查询计算用时
[0117]
查询计算在服务器端通过计算函数来进行。压缩过程主要影响计算函数在内存读写上的效率，对计算指令的效率没有影响。本发明的读写处理都以字节为最小单位，因此内存读写的耗时与数据在内存中占用的字节数成正比。本发明使用表示在查询过程中用于计算的指令所消耗的时间，表示在该过程中用于内存读写的指令消耗的时间。由于可以进行不解压缩的直接计算，在计算时的读写速度和计算速度都会变快，因此数据规模的减小，可以加快计算过程。不同压缩算法的压缩比不同，会在计算过程中体现出不同的效率。具体地，查询计算用时的计算公式为：
[0118][0119]
其中，表示在查询过程中用于计算的指令所消耗的时间；表示在该过程中用于内存读写的指令消耗的时间；r表示所选择的压缩算法τ的压缩比(压缩前字节数/压缩后字节数)。
[0120]
2.2.3)基于不同压缩算法的总处理时间，选择总处理时间最少的压缩算法，作为本段处理批流数据的最优压缩方法。
[0121]
优选地，上述步骤3)中，基于客户端上所维护的可用的服务器资源队列，选择对待执行应用最合适的服务器的方法，包括：
[0122]
3.1)基于客户端上所维护的可用的服务器资源队列s，选择第一个剩余可用资源足够执行当前任务的服务器来负责当前任务。
[0123]
在每台客户端上，都会维护一个可用的服务器资源队列s，该队列中包含n个服务器《s1,s2,
…
,sn》，每个服务器si都有对应的空闲内存memi，cpu空闲率ci以及gpu空闲率gi。服务器资源队列s是一个有序队列，按照资源可用程度升序排列，排序的规则为：
[0124]
对于两个服务器si，sj，若memi《memj，则si《sj，若memi》memj，则si》sj；否则，若ci《cj，则si《sj，若ci》cj，则si》sj；否则，若gi≤gj，则si《sj，则si》sj。
[0125]
当客户端执行负载均衡模块时，会查找服务器资源队列s，选择第一个剩余可用资源足够执行当前任务的服务器来负责当前任务，假设执行当前任务需要的资源为memk,ck,gk，即找到服务器si，满足：
[0126]
①
memi≥memk,ci≥ck,gi≥gk。
[0127]
②
满足memj≥memk,cj≥ck,gj≥gk。
[0128]
这样做的目的是每次都选择最小可用的服务器，最大程度上充分利用服务器资源。
[0129]
3.2)当服务器接收当前任务后，向所有客户端发送当前的可用资源信息，更新客户端上的服务器资源队列s，以供新任务的资源分配，同时服务器在完成任务后，向客户端返回结果时，也会同样发送更新的可用资源信息。
[0130]
优选地，上述步骤4)中，相应服务器对待执行的sql语句进行处理时，首先将sql语句进一步细分为不同的操作符，这是最小的数据处理单元，具体地，本实施例中包括的操作符支持常见的关系运算符，包括投影、选择、聚合、分组、联接等。在流处理的上下文中，数据流由一个元组序列组成，元组是一个表示包括诸如时间戳、数量和测量值等元素的事件的记录。元组构成批。批处理表示包含一定数量元组的处理块。在批处理中，本发明使用列表示同一字段中不同元组的元素。最后，本发明用一个滑动窗口来处理数据，窗口是元组的有限序列组成的，窗口的大小由用户设定，表示要处理的数据单元的大小。
[0131]
在计算模块中，流处理通过由这些运算符组成的查询语句执行，该运算符具有给定的滑动窗口大小。在一定的时间间隔之后，压缩模块会使用系统性能模型预测处理延迟并更新所使用的压缩算法，计算模块也会随之更新，根据选择的新压缩算法切换对应的计算函数。使用这些优化的查询函数，可以直接比较和计算压缩值，允许本发明直接在压缩数据上执行计算。
[0132]
此外，由于不同的运算符会有不同的设备偏好，比如投影、分组、选择等操作在gpu上的性能更好，而聚合和连接在cpu上的性能表现更好，因此在计算模块中，会事先根据待执行的sql语句，将待执行的任务分配给cpu或gpu，以取得更高的系统性能。
[0133]
基于上述分析，处理器的处理流程包括以下步骤：
[0134]
4.1)对于一个给定的输入数据流，假设其共有n个数据属性《col1,col2,
…
,coln》和m个待处理的运算操作序列《op1,op2,
…
,opm》；
[0135]
4.2)遍历运算操作序列，对于每个运算符opi，如果该运算在gpu上的性能更好，就将该运算分配给gpu，反之则分配给cpu。
[0136]
4.3)相应服务器基于客户端发送的与n个数据属性一一对应的所采用的压缩算法的集合《τ1,τ2,
…
,τn》以及压缩后数据所占用的字节数《bytes1,bytes2,
…
,bytesn》，对计算函数进行更新，并基于更新后的计算函数对相应运算符进行处理。
[0137]
计算模块中内置的计算函数默认用于处理未经压缩的数据流，而对于压缩数据流的处理，则需要进行对应的计算函数更新。由于本发明针对流数据的特性，采用了动态更新的处理方式，因此每次更新，所使用的计算函数也会随之更新。每次动态更新处理方式时，客户端会给服务器发送与n个数据属性一一对应的所采用的压缩算法的集合《τ1,τ2,
…
,τn》以及压缩后数据所占用的字节数《bytes1,bytes2,
…
,bytesn》。对于一个运算符opi，其默认计算函数对每列数据属性的处理用《q1,q2,
…
,qn》来表示，更新后的计算函数则表示为《(q1,τ1,bytes1),(q2,τ2,bytes2),
…
,(qn,τn,bytesn)》。其中，处理函数qi的更新方式由对应的压缩算法τi决定，再结合压缩后的字节数bytesi来确定数据的读写和计算时所需要的内存空间。
[0138]
对于按字节对齐的压缩算法，如base-delta编码，ns编码等，处理函数qi的更新方式较为简单，例如原查询为在数据属性coli上进行的运算操作，对应的(qi,τi,bytesi)只需要将访存和运算的数据单位变为bytesi即可。而对于其他非对齐的压缩算法，处理函数qi的更新则需要依据压缩算法τi的原理和处理函数的具体操作进行更新，例如qi为分组操作，τi为rle编码时，因为编码后的结果为原始数据中符号值和符号重复出现次数，对应的(qi,τi,bytesi)将编码后的数据合并汇总即可。
[0139]
实施例2
[0140]
本实施例在几个通用的数据集上做了测试，smart grids是一个智能电网的能耗测量，cluster monitoring是来自谷歌计算集群的监测数据，linear road benchmark是对车辆位置的监控和轨迹预测。在这三个数据集上，本发明可以分别取得4.80倍，2.38倍和2.55倍的吞吐量提升，以及66.0％，58.0％和60.8％的延迟降低。
[0141]
本实施例在这些数据集上使用动态的工作负载，与已有的性能最好的处理方法进行了性能对比。以smart grid数据集为例，在10mbps的网络带宽下，与性能最好的静态处理方法相比，可以取得1.70倍的加速比，在100mbps的网络带宽下，可以取得1.21倍的加速比。
[0142]
实施例3
[0143]
上述实施例1提供了一种基于自适应不解压直接计算的流处理方法，与之相对应地，本实施例提供一种基于自适应不解压直接计算的流处理系统。本实施例提供的系统可以实施实施例1的基于自适应不解压直接计算的流处理方法，该系统可以通过软件、硬件或软硬结合的方式来实现。例如，该系统可以包括集成的或分开的功能模块或功能单元来执行实施例1各方法中的对应步骤。由于本实施例的系统基本相似于方法实施例，所以本实施例描述过程比较简单，相关之处可以参见实施例1的部分说明即可，本实施例提供的系统的实施例仅仅是示意性的。
[0144]
本实施例提供的基于自适应不解压直接计算的流处理系统，包括：
[0145]
输入模块，用于确定待处理的流数据以及基于该待处理流数据的待执行应用，也即sql语句；
[0146]
自适应压缩模块，用于实时选择对待处理的流数据性能最优的压缩算法，在客户端对待处理流数据进行自适应压缩，得到压缩后数据；
[0147]
负载均衡模块，用于基于客户端上所维护的可用的服务器资源队列，选择对待执行应用最合适的服务器，并将压缩后数据以及待执行的应用传输给相应服务器；
[0148]
运算模块，用于相应服务器根据采用的压缩算法，在压缩后数据上进行待执行应用的运行处理，得到流处理结果。
[0149]
优选地，自适应压缩模块包括压缩算法选择器和压缩模块，其中，压缩算法选择器用于基于性能模型，实时选择对待处理的流数据性能最优的压缩算法；压缩模块用于采用最优压缩算法对待处理流数据进行压缩，得到压缩后数据。
[0150]
实施例4
[0151]
本实施例提供一种与本实施例1所提供的基于自适应不解压直接计算的流处理方法对应的处理设备，处理设备可以是用于客户端的处理设备，例如手机、笔记本电脑、平板电脑、台式机电脑等，以执行实施例1的方法。
[0152]
所述处理设备包括处理器、存储器、通信接口和总线，处理器、存储器和通信接口
通过总线连接，以完成相互间的通信。存储器中存储有可在所述处理器上运行的计算机程序，所述处理器运行所述计算机程序时执行本实施例1所提供的基于自适应不解压直接计算的流处理方法。
[0153]
在一些实施例中，存储器可以是高速随机存取存储器(ram：random access memory)，也可能还包括非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。
[0154]
在另一些实施例中，处理器可以为中央处理器(cpu)、数字信号处理器(dsp)等各种类型通用处理器，在此不做限定。
[0155]
实施例5
[0156]
本实施例1的基于自适应不解压直接计算的流处理方法可被具体实现为一种计算机程序产品，计算机程序产品可以包括计算机可读存储介质，其上载有用于执行本实施例1所述的基于细粒度自适应压缩的流处理方法的计算机可读程序指令。
[0157]
计算机可读存储介质可以是保持和存储由指令执行设备使用的指令的有形设备。计算机可读存储介质例如可以是但不限于电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意组合。
[0158]
最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。