【技术实现步骤摘要】
本专利技术涉及流式计算的，尤其是指一种基于优化器的流式sql执行计划优化方法。
技术介绍
1、随着大数据时代的来临，数据量呈爆炸性增长，对于海量数据处理的实时性要求也逐渐增加。许多系统需要根据数据的实时变化做出及时的处理，这导致许多分布式流处理引擎的产生以及发展，例如storm、spark streaming以及flink等。但与传统的大数据引擎面临同样的问题，会使得开发人员以及数据分析人员的编程门槛大大提高，而sql是难度较低且常用的数据处理语言，因此出现了类sql语句即流式sql可以使得开发人员方便利用流式计算进行实时处理大数据问题。
2、由于流式sql根据查询语句能够生成多种对应的流式计算作业的执行计划，多种执行计划性能差异可能特别大。因此针对流式sql进行查询优化使其能够生成较优的执行计划，提升查询性能显得格外的重要。在基于先验知识的情况下，可以针对流式sql进行基于规则的优化，例如谓词下推等普遍能够带来计算资源的节省以及性能的提升。但是存在着一些优化是基于成本的，如果不基于统计信息以及成本模型进行计算，直接进行改变执行计划，可能反而导致需要进行更多的计算以及浪费更多的资源。然而传统批处理的统计信息收集方式以及成本模型均不适配流式计算的执行过程，因此针对流式sql的基于成本的优化是必要的。然而流式计算存在着运行时间长、数据量变化较大等特点，若需要在运行时进行统计信息收集，则会消耗较多的计算资源。而且由于在运行时切换到其他计划会面临着存储着历史计算信息的状态兼容的问题以及构建新计划所需状态的昂贵费用，如果历史输
技术实现思路
1、本专利技术的目的在于克服现有技术的缺点与不足，提出了一种基于优化器的流式sql执行计划优化方法，对于具有历史输入的数据源流，在其流式sql实际执行前基于成本进行优化，生成一个较优的执行计划，提升流式sql的执行性能，减少计算资源的使用。
2、为实现上述目的，本专利技术所提供的技术方案为：基于优化器的流式sql执行计划优化方法，包括以下步骤：
3、s1、针对具有历史输入的数据源流，收集所需的统计信息，并实现基于成本的规则，使优化器能够生成多种执行计划；
4、s2、构建符合流式计算的成本模型，并采用步骤s1收集的统计信息，对优化器基于成本的规则生成的多种执行计划进行成本的计算，并根据计算的成本对比选出成本最小的最终执行计划；
5、s3、得到最终执行计划，进行最终流式sql的执行。
6、进一步，在步骤s1，收集的统计信息包括元组数、每列的基数、最大值、最小值以及所占字符大小。
7、进一步，在步骤s1，在流式计算中，对于聚合算子aggregate，实现了在对聚合算子进行攒批操作的基础上，能够生成对aggregate开启或关闭两阶段的执行计划；开启两阶段aggregate能够将aggregate分为本地聚合local aggregate和全局聚合globalaggregate；local aggregate在本地对需要发往下游的数据提前进行预聚合后再发往global aggregate；对于连接算子join，在多流进行join的情况，实现了根据join条件对流的顺序进行推断出不同的join顺序从而生成多种不同的执行计划的规则。
8、进一步，在步骤s2，为了考虑流式计算的实际执行所需资源的消耗，以及流式计算对于性能的指标主要包括吞吐量和延迟，所述成本模型综合考虑cpu、i/o、内存和网络传输这四种资源进行成本开销的计算，最终计算成本为：
9、cost＝normalize(cpu,i/o,memory,net)
10、式中，cost代表最终计算成本，normalize代表将四种资源成本进行归一化，cpu代表所需消耗的cpu资源，i/o代表所需消耗的i/o资源，memory代表所需消耗的内存资源，net代表所需消耗的网络传输资源。
11、进一步，在步骤s2，所述成本模型包括对aggregate、local aggregate、globalaggregate和join算子的成本计算；
12、将aggregate的成本定义为：
13、cpu＝t(i)×(rfunction×nf+rstate×nk)+t(o)×rserialize_deserialize
14、
15、memory＝0
16、net＝tsz(o)×t(o)
17、式中，t(i)代表输入源的元组数，t(o)代表输出的元组数，rfunction代表执行一个计算函数所需的cpu的比率，rstate代表执行探测状态所需的cpu的比率，rserialize_deserialize代表执行序列化和反序列化所需的cpu的比率，nf代表查询语句中的聚合函数个数，nk代表聚合的键值的个数，tsz(o)代表输出的元组平均大小；
18、aggregate所需的cpu开销包括对输入数据进行nk个聚合函数的计算、对状态中数据按nk个键进行搜索的开销、执行在完成聚合过程读取以及存储状态所需的序列化和反序列的开销；
19、aggregate所需的i/o开销需要分为两种情况：第一种，在nk为0即聚合键为空的情况下，代表着无需按键分组，输入数据最终结果聚合为一条数据；第二种，在nk不为0的情况下，输入数据最终结果会聚合成按键分组的数据；
20、所述成本模型考虑将状态存储到磁盘当中，因此内存的开销忽略不计；
21、aggregate所需的网络传输开销包括将算子计算结果通过网络传输到下游的网络开销；
22、将local aggregate的成本定义为：
23、cpu＝t(i)×(rfunction×nf+rhash×nk)
24、i/o＝0
25、
26、net＝tsz(o)×t(o)
27、式中，rfunction代表执行哈希探查所需的cpu的比率；
28、由于local aggregate不涉及状态的管理问题，因此不涉及序列化及反序列化的开销，故local aggregate所需的cpu开销包括对输入数据进行nf个聚合函数的计算，对所存数据按nk个键进行搜索的开销；
29、由于local aggregate不涉及状态的管理问题，因此无需考虑状态读写到磁盘的开销，因此i/o开销忽略不计；
30、local aggregate所需的内存开销需要分为两种情况：第一种，在nk为0即聚合键本文档来自技高网...
【技术保护点】
1.基于优化器的流式SQL执行计划优化方法，其特征在于，包括以下步骤：
2.根据权利要求1所述的基于优化器的流式SQL执行计划优化方法，其特征在于：在步骤S1，收集的统计信息包括元组数、每列的基数、最大值、最小值以及所占字符大小。
3.根据权利要求2所述的基于优化器的流式SQL执行计划优化方法，其特征在于：在步骤S1，在流式计算中，对于聚合算子Aggregate，实现了在对聚合算子进行攒批操作的基础上，能够生成对Aggregate开启或关闭两阶段的执行计划；开启两阶段Aggregate能够将Aggregate分为本地聚合Local Aggregate和全局聚合Global Aggregate；LocalAggregate在本地对需要发往下游的数据提前进行预聚合后再发往Global Aggregate；对于连接算子Join，在多流进行Join的情况，实现了根据Join条件对流的顺序进行推断出不同的Join顺序从而生成多种不同的执行计划的规则。
4.根据权利要求3所述的基于优化器的流式SQL执行计划优化方法，其特征在于：在步骤S2，为了考虑流式计算
5.根据权利要求4所述的基于优化器的流式SQL执行计划优化方法，其特征在于：在步骤S2，所述成本模型包括对Aggregate、Local Aggregate、Global Aggregate和Join算子的成本计算；
...【技术特征摘要】
1.基于优化器的流式sql执行计划优化方法，其特征在于，包括以下步骤：
2.根据权利要求1所述的基于优化器的流式sql执行计划优化方法，其特征在于：在步骤s1，收集的统计信息包括元组数、每列的基数、最大值、最小值以及所占字符大小。
3.根据权利要求2所述的基于优化器的流式sql执行计划优化方法，其特征在于：在步骤s1，在流式计算中，对于聚合算子aggregate，实现了在对聚合算子进行攒批操作的基础上，能够生成对aggregate开启或关闭两阶段的执行计划；开启两阶段aggregate能够将aggregate分为本地聚合local aggregate和全局聚合global aggregate；localaggregate在本地对需要发往下游的数据提前进行预聚合后再发...
还没有人留言评论。发表了对其他浏览者有用的留言会获得科技券。