用于预计算系统中查询引擎的动态路由方法及装置与流程

本申请涉及计算机、数据分析领域，具体而言，涉及一种用于预计算系统中查询引擎的动态路由方法及装置。
背景技术：
：预计算查询系统，能够利用空余的计算、存储资源提前完成部分的计算，并且将这些计算结果保存在可持久化的存储介质中，当用户查询到来的时候，只需要进行少量的数据再加工便可以回答用户的查询。发明人发现，在分布式计算环境中，预计算查询系统的查询响应速度仍然不理想。进一步，对预计算结果的利用也较差。针对相关技术中预计算查询系统的查询响应速度并不理想的问题，目前尚未提出有效的解决方案。技术实现要素：本申请的主要目的在于提供一种用于预计算系统中查询引擎的动态路由方法及装置，以解决预计算查询系统的查询响应速度并不理想的问题。为了实现上述目的，根据本申请的一个方面，提供了一种用于预计算系统中查询引擎的动态路由方法。根据本申请的用于预计算系统中查询引擎的动态路由方法包括：预先获取预计算系统中预设维度组合下的立方体数据；在接收查询请求后，判断按照预期选中的所述预设维度组合下的立方体数据的聚合程度；在所述预设维度组合下的立方体数据的聚合程度为高时，在第一分布式查询引擎对所述查询请求执行查询处理；以及在所述预设维度组合下的立方体数据的聚合程度为低时，切换至第二分布式查询引擎对所述查询请求执行查询处理。进一步地，在接收查询请求后，判断按照预期选中的所述预设维度组合下的立方体数据的聚合程度时还包括：评估执行所述查询请求的代价结果；当按照预期选中的所述预设维度组合下的立方体数据相同和/或重叠时，根据所述代价结果调整选用所述第一分布式查询引擎或所述第二分布式查询引擎。进一步地，在所述预设维度组合下的立方体数据的聚合程度为高时，在第一分布式查询引擎对所述查询请求执行查询处理包括：在所述预设维度组合下的立方体数据的聚合程度为高时，在scatter-and-gather第一分布式查询引擎对所述查询请求执行查询处理。进一步地，在所述预设维度组合下的立方体数据的聚合程度为低时，切换至第二分布式查询引擎对所述查询请求执行查询处理包括：在所述预设维度组合下的立方体数据的聚合程度为低时，切换至total-exchange第二分布式查询引擎对所述查询请求执行查询处理。进一步地，在所述预设维度组合下的立方体数据的聚合程度为低时，切换至第二分布式查询引擎对所述查询请求执行查询处理之后还包括：在再次接收到查询请求后，判断按照预期选中的所述预设维度组合下的立方体数据的聚合程度；在所述预设维度组合下的立方体数据的聚合程度由低变为高时，切换至第一分布式查询引擎对所述查询请求执行查询处理。为了实现上述目的，根据本申请的另一方面，提供了一种用于预计算系统中查询引擎的动态路由装置。根据本申请的用于预计算系统中查询引擎的动态路由装置包括：预存模块，用于预先获取预计算系统中预设维度组合下的立方体数据；判断模块，用于在接收查询请求后，判断按照预期选中的所述预设维度组合下的立方体数据的聚合程度；第一执行模块，用于在所述预设维度组合下的立方体数据的聚合程度为高时，在第一分布式查询引擎对所述查询请求执行查询处理；以及第二执行模块，用于在所述预设维度组合下的立方体数据的聚合程度为低时，切换至第二分布式查询引擎对所述查询请求执行查询处理。进一步地，装置还包括：代价规则模块，所述代价规则模块包括：评估单元，用于评估执行所述查询请求的代价结果；调整单元，用于当按照预期选中的所述预设维度组合下的立方体数据相同和/或重叠时，根据所述代价结果调整选用所述第一分布式查询引擎或所述第二分布式查询引擎。进一步地，所述第一执行模块包括：第一引擎单元，所述第一引擎单元，用于在所述预设维度组合下的立方体数据的聚合程度为高时，在scatter-and-gather第一分布式查询引擎对所述查询请求执行查询处理。进一步地，所述第二执行模块包括：第二引擎单元，所述第二引擎单元，用于在所述预设维度组合下的立方体数据的聚合程度为低时，切换至total-exchange第二分布式查询引擎对所述查询请求执行查询处理。进一步地，装置还包括：动态调节模块，所述动态调节模块包括：再判断单元，在再次接收到查询请求后，判断按照预期选中的所述预设维度组合下的立方体数据的聚合程度；调整执行单元，用于在所述预设维度组合下的立方体数据的聚合程度由低变为高时，切换至第一分布式查询引擎对所述查询请求执行查询处理。在本申请实施例中的用于预计算系统中查询引擎的动态路由方法及装置，采用预先获取预计算系统中预设维度组合下的立方体数据的方式，通过在接收查询请求后，判断按照预期选中的所述预设维度组合下的立方体数据的聚合程度，达到了在所述预设维度组合下的立方体数据的聚合程度为高时，在第一分布式查询引擎对所述查询请求执行查询处理和在所述预设维度组合下的立方体数据的聚合程度为低时，切换至第二分布式查询引擎对所述查询请求执行查询处理的目的，从而实现了稳定利用预计算结果并快速响应客户查询请求的技术效果，进而解决了预计算查询系统的查询响应速度并不理想的技术问题。附图说明构成本申请的一部分的附图用来提供对本申请的进一步理解，使得本申请的其它特征、目的和优点变得更明显。本申请的示意性实施例附图及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：图1是根据本申请第一实施例的用于预计算系统中查询引擎的动态路由方法流程示意图；图2是根据本申请第二实施例的用于预计算系统中查询引擎的动态路由方法流程示意图；图3是根据本申请第三实施例的用于预计算系统中查询引擎的动态路由方法流程示意图；图4是根据本申请第四实施例的用于预计算系统中查询引擎的动态路由方法流程示意图；图5是根据本申请第五实施例的用于预计算系统中查询引擎的动态路由方法流程示意图；图6是根据本申请第一实施例的用于预计算系统中查询引擎的动态路由装置结构示意图；图7是根据本申请第二实施例的用于预计算系统中查询引擎的动态路由装置结构示意图；图8是根据本申请第三实施例的用于预计算系统中查询引擎的动态路由装置结构示意图；图9是根据本申请第四实施例的用于预计算系统中查询引擎的动态路由装置结构示意图；图10是根据本申请第五实施例的用于预计算系统中查询引擎的动态路由装置结构示意图；图11是本申请中的实现原理示意图；图12是scatter-and-gather模型原理示意图；图13是根据total-exchange模型原理示意图。具体实施方式为了使本
技术领域：
的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。本申请用于预计算系统中查询引擎的动态路由方法，提出了基于代价规则库和预计算元信息的预计算查询引擎的智能路由机制，可以让预计算查询系统能够以降低查询响应时间，同时保障系统稳定性为目标。并且可以在不同引擎之间实现自动切换。实现了动态以及智能的查询引擎路由机制，从而可以提高预计算系统的性能和效率以及稳定性。如图1所示，该方法包括如下的步骤s102至步骤s108：步骤s102，预先获取预计算系统中预设维度组合下的立方体数据；由于采用预计算系统具有如下特性：预计算系统可以提前使用离线作业，预计算好按照维度聚合度量的结果，作为立方体数据即cube数据。而由于cube数据是经过聚合的，并且经过了维度筛选和度量。因此，cube数据的数据量通常比原始数据要小得多。进一步，cube数据是预计算结果的集合，在所述集合中的每个元素为按照某种特定维度组合下的度量结果，则作为预设维度组合下的立方体数据即cuboid。可以理解，对于不同的查询，在预计算查询系统中预期选中的立方体数据或者预设维度组合下的立方体数据是不同的。而根据上述预计算系统中的特性，可以在接收到用户的查询请求之前就可以获知并缓存预计算的每一个cuboid的行数，大小，基数等特性在系统内存中。具体地，预先获取预计算系统中预设维度组合下的立方体数据是指在预计算系统中的查询引擎面对的不是原始数据，而是已经完成好聚合的cube数据或cuboid。步骤s104，在接收查询请求后，判断按照预期选中的所述预设维度组合下的立方体数据的聚合程度；在接收到查询请求后，需要判断按照预期选中的所述预设维度组合下的立方体数据即cuboid的聚合程度。比如，当一个查询选中的是一个被聚合程度很高的cuboid时，如果一个是具体按照年龄维度聚合的cuboid，则完成所述查询所需访问的cuboid数据量是很小的；而如果查询选中的是一个按照承保人+日期维度聚合的低聚合程度的cuboid，那么需要访问的cuboid数据量仍然是很大的。通过判断cuboid聚合程度，可以明确地了解完成所述查询所需要访问的cuboid的数据量，从而决定了查询的返回效率。步骤s106，在所述预设维度组合下的立方体数据的聚合程度为高时，在第一分布式查询引擎对所述查询请求执行查询处理；在所述预设维度组合下的立方体数据的聚合程度为高时，需要在第一分布式查询引擎中对所述查询请求执行查询处理。根据判断结果，所述第一分布式查询引擎需要是可以执行所述预设维度组合下的立方体数据的聚合程度较高时的查询引擎。需要注意的是，第一分布式查询引擎需要满足性能优势即可，在本申请实施例中并不进行具体限定，只要满足性能优势条件即可。步骤s108，在所述预设维度组合下的立方体数据的聚合程度为低时，切换至第二分布式查询引擎对所述查询请求执行查询处理。在所述预设维度组合下的立方体数据的聚合程度为低时，需要在第二分布式查询引擎中对所述查询请求执行查询处理。根据判断结果，所述第二分布式查询引擎需要是可以执行所述预设维度组合下的立方体数据的聚合程度较低时的查询引擎。需要注意的是，第二分布式查询引擎需要满足稳定性可靠性优势即可，在本申请实施例中并不进行具体限定，只要满足可靠性条件即可。通过路由切换，既能获得第一分布式查询引擎的性能优势，又能获得第二分布式查询引擎的稳定性可靠性优势。从以上的描述中，可以看出，本申请实现了如下技术效果：在本申请实施例中，采用预先获取预计算系统中预设维度组合下的立方体数据的方式，通过在接收查询请求后，判断按照预期选中的所述预设维度组合下的立方体数据的聚合程度，达到了在所述预设维度组合下的立方体数据的聚合程度为高时，在第一分布式查询引擎对所述查询请求执行查询处理和在所述预设维度组合下的立方体数据的聚合程度为低时，切换至第二分布式查询引擎对所述查询请求执行查询处理的目的，从而实现了稳定利用预计算结果并快速响应客户查询请求的技术效果，进而解决了预计算查询系统的查询响应速度并不理想的技术问题。根据本申请实施例，作为本实施例中的优选，如图2所示，在接收查询请求后，判断按照预期选中的所述预设维度组合下的立方体数据的聚合程度时还包括：步骤s202，评估执行所述查询请求的代价结果；在判断按照预期选中的所述预设维度组合下的立方体数据的聚合程度时，还需要考虑查询代价。可以通过建立预设的代价规则库进行判断结果的修正或补充。步骤s204，当按照预期选中的所述预设维度组合下的立方体数据相同和/或重叠时，根据所述代价结果调整选用所述第一分布式查询引擎或所述第二分布式查询引擎。当按照预期选中的所述预设维度组合下的立方体数据相同时是指，当查询请求选中了相同的cuboid。当按照预期选中的所述预设维度组合下的立方体数据重叠时是指，当查询请求选中了相互覆盖或重叠的cuboid。比如，即使在接收的两条不同维度的查询请求选中了相同cuboid，但是对于cuboid的使用方式也可能是区别较大的。需要注意的是，不同维度的查询请求会影响cuboid的使用方式，仅作为本实施例中的优选实施方案，并不代表对本申请中实施方式的限定。具体地，当两条查询都会击中cuboid时，一类查询请求会涉及大量的数据扫描，而另一类查询请求可以很精准地只获取部分的数据就足以完成查询。通过预设代价规则库的代价结算结果，识别一类查询请求中的查询的代价需要扫描cuboid的大部分数据，并且在进行汇总的时候存在潜在的单点风险。而另一类查询请求中的查询仅需要扫描少量的cuboid数据，单点风险较小。所以，两类查询请求的特点存在明显差异，造成了一类查询请求适合选用第二分布式查询引擎，而另一类查询请求适合选用第一分布式查询引擎的情况。根据本申请实施例，作为本实施例中的优选，如图3所示，在所述预设维度组合下的立方体数据的聚合程度为高时，在第一分布式查询引擎对所述查询请求执行查询处理包括：步骤s107，在所述预设维度组合下的立方体数据的聚合程度为高时，在scatter-and-gather第一分布式查询引擎对所述查询请求执行查询处理。第一分布式查询引擎scatter-and-gather是一种分布式计算模型。在分布式计算模型scatter-and-gather中，数据存放在每个slave所在的节点上，数据请求者向每个slave单独发送数据请求，并在请求者自己的内存中完成数据的汇总。其中，所述汇总通常指着预聚合数据的再加工处理。scatter-and-gather分布式模型的优点在于实现简单，性能高效，尤其是数据请求者仅需从每个slave获取少量的数据，且最后汇总的数据总量并不是很大的查询请求的场景下使用。根据本申请实施例，作为本实施例中的优选，如图4所示，在所述预设维度组合下的立方体数据的聚合程度为低时，切换至第二分布式查询引擎对所述查询请求执行查询处理包括：步骤s109，在所述预设维度组合下的立方体数据的聚合程度为低时，切换至total-exchange第二分布式查询引擎对所述查询请求执行查询处理。第二分布式查询引擎total-exchange也是一种分布式计算模型。在total-exchange模型中数据存放在每个slave所在的节点上，数据请求者向每个slave单独发送数据请求，slave之间通过相互通信完成数据的汇总，并最终直接返还给数据请求者已经汇总完毕的结果。数据请求者不需要进行任何的数据汇总工作。scatter-and-gather分布式模型的优点在于在需要汇总的数据量很大的情况下，可以有效地避免单点瓶颈问题。根据本申请实施例，作为本实施例中的优选，如图5所示，在所述预设维度组合下的立方体数据的聚合程度为低时，切换至第二分布式查询引擎对所述查询请求执行查询处理之后还包括：步骤s110，在再次接收到查询请求后，判断按照预期选中的所述预设维度组合下的立方体数据的聚合程度；由于需要进行动态路由调节，所以在再次接收到查询请求后，需要重新判断按照预期选中的所述预设维度组合下的立方体数据的聚合程度，并且继续下述操作。即在每次接收到查询请求时，都需要进行按照预期选中的所述预设维度组合下的立方体数据的聚合程度的判断。步骤s112，在所述预设维度组合下的立方体数据的聚合程度由低变为高时，切换至第一分布式查询引擎对所述查询请求执行查询处理。在所述预设维度组合下的立方体数据的聚合程度由低变为高时，则路由动态切换至第一分布式查询引擎对所述查询请求执行查询处理。即根据聚合程度的变化情况比如由低至高，进行采用第一分布式查询引擎对所述查询请求执行查询处理的切换。此外，在执行上述判断按照预期选中的所述预设维度组合下的立方体数据的聚合程度的操作时，还需要评估执行所述查询请求的代价结果；当按照预期选中的所述预设维度组合下的立方体数据相同和/或重叠时，根据所述代价结果调整选用所述第一分布式查询引擎或所述第二分布式查询引擎。即需要根据预设基于代价的规则库计算出查询代价并判断是否对分布式查询引擎的选择进行调整。通过上述操作，实现了动态以及智能的查询引擎路由机制，从而可以提高预计算系统的性能和效率以及稳定性。根据预计算结果中的元信息和查询本身的特性，可动态智能地选择最优的分布式计算模型。需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。根据本申请实施例，还提供了一种用于实施上述用于预计算系统中查询引擎的动态路由方法的装置，如图6所示，该装置包括：预存模块10，用于预先获取预计算系统中预设维度组合下的立方体数据；判断模块20，用于在接收查询请求后，判断按照预期选中的所述预设维度组合下的立方体数据的聚合程度；第一执行模块30，用于在所述预设维度组合下的立方体数据的聚合程度为高时，在第一分布式查询引擎对所述查询请求执行查询处理；以及第二执行模块40，用于在所述预设维度组合下的立方体数据的聚合程度为低时，切换至第二分布式查询引擎对所述查询请求执行查询处理。本申请实施例的预存模块10中由于采用预计算系统具有如下特性：预计算系统可以提前使用离线作业，预计算好按照维度聚合度量的结果，作为立方体数据即cube数据。而由于cube数据是经过聚合的，并且经过了维度筛选和度量。因此，cube数据的数据量通常比原始数据要小得多。进一步，cube数据是预计算结果的集合，在所述集合中的每个元素为按照某种特定维度组合下的度量结果，则作为预设维度组合下的立方体数据即cuboid。可以理解，对于不同的查询，在预计算查询系统中预期选中的立方体数据或者预设维度组合下的立方体数据是不同的。而根据上述预计算系统中的特性，可以在接收到用户的查询请求之前就可以获知并缓存预计算的每一个cuboid的行数，大小，基数等特性在系统内存中。具体地，预先获取预计算系统中预设维度组合下的立方体数据是指在预计算系统中的查询引擎面对的不是原始数据，而是已经完成好聚合的cube数据或cuboid。本申请实施例的判断模块20中在接收到查询请求后，需要判断按照预期选中的所述预设维度组合下的立方体数据即cuboid的聚合程度。比如，当一个查询选中的是一个被聚合程度很高的cuboid时，如果一个是具体按照年龄维度聚合的cuboid，则完成所述查询所需访问的cuboid数据量是很小的；而如果查询选中的是一个按照承保人+日期维度聚合的低聚合程度的cuboid，那么需要访问的cuboid数据量仍然是很大的。通过判断cuboid聚合程度，可以明确地了解完成所述查询所需要访问的cuboid的数据量，从而决定了查询的返回效率。本申请实施例的第一执行模块30中在所述预设维度组合下的立方体数据的聚合程度为高时，需要在第一分布式查询引擎中对所述查询请求执行查询处理。根据判断结果，所述第一分布式查询引擎需要是可以执行所述预设维度组合下的立方体数据的聚合程度较高时的查询引擎。需要注意的是，第一分布式查询引擎需要满足性能优势即可，在本申请实施例中并不进行具体限定，只要满足性能优势条件即可。本申请实施例的第二执行模块40中在所述预设维度组合下的立方体数据的聚合程度为低时，需要在第二分布式查询引擎中对所述查询请求执行查询处理。根据判断结果，所述第二分布式查询引擎需要是可以执行所述预设维度组合下的立方体数据的聚合程度较低时的查询引擎。需要注意的是，第二分布式查询引擎需要满足稳定性可靠性优势即可，在本申请实施例中并不进行具体限定，只要满足可靠性条件即可。通过路由切换，既能获得第一分布式查询引擎的性能优势，又能获得第二分布式查询引擎的稳定性可靠性优势。根据本申请实施例，作为本实施例中的优选，如图7所示，还包括：代价规则模块50，所述代价规则模块50包括：评估单元501，用于评估执行所述查询请求的代价结果；调整单元502，用于当按照预期选中的所述预设维度组合下的立方体数据相同和/或重叠时，根据所述代价结果调整选用所述第一分布式查询引擎或所述第二分布式查询引擎。本申请实施例的评估单元501中在判断按照预期选中的所述预设维度组合下的立方体数据的聚合程度时，还需要考虑查询代价。可以通过建立预设的代价规则库进行判断结果的修正或补充。本申请实施例的调整单元502中当按照预期选中的所述预设维度组合下的立方体数据相同时是指，当查询请求选中了相同的cuboid。当按照预期选中的所述预设维度组合下的立方体数据重叠时是指，当查询请求选中了相互覆盖或重叠的cuboid。比如，即使在接收的两条不同维度的查询请求选中了相同cuboid，但是对于cuboid的使用方式也可能是区别较大的。需要注意的是，不同维度的查询请求会影响cuboid的使用方式，仅作为本实施例中的优选实施方案，并不代表对本申请中实施方式的限定。具体地，当两条查询都会击中cuboid时，一类查询请求会涉及大量的数据扫描，而另一类查询请求可以很精准地只获取部分的数据就足以完成查询。通过预设代价规则库的代价结算结果，识别一类查询请求中的查询的代价需要扫描cuboid的大部分数据，并且在进行汇总的时候存在潜在的单点风险。而另一类查询请求中的查询仅需要扫描少量的cuboid数据，单点风险较小。所以，两类查询请求的特点存在明显差异，造成了一类查询请求适合选用第二分布式查询引擎，而另一类查询请求适合选用第一分布式查询引擎的情况。根据本申请实施例，作为本实施例中的优选，如图8所示，所述第一执行模块包括：第一引擎单元301，所述第一引擎单元301，用于在所述预设维度组合下的立方体数据的聚合程度为高时，在scatter-and-gather第一分布式查询引擎对所述查询请求执行查询处理。本申请实施例的第一引擎单元301中第一分布式查询引擎scatter-and-gather是一种分布式计算模型。在分布式计算模型scatter-and-gather中，数据存放在每个slave所在的节点上，数据请求者向每个slave单独发送数据请求，并在请求者自己的内存中完成数据的汇总。其中，所述汇总通常指着预聚合数据的再加工处理。scatter-and-gather分布式模型的优点在于实现简单，性能高效，尤其是数据请求者仅需从每个slave获取少量的数据，且最后汇总的数据总量并不是很大的查询请求的场景下使用。根据本申请实施例，作为本实施例中的优选，如图9所示，所述第二执行模块包括：第二引擎单元401，所述第二引擎单元401，用于在所述预设维度组合下的立方体数据的聚合程度为低时，切换至total-exchange第二分布式查询引擎对所述查询请求执行查询处理。本申请实施例的第二引擎单元401中第二分布式查询引擎total-exchange也是一种分布式计算模型。在total-exchange模型中数据存放在每个slave所在的节点上，数据请求者向每个slave单独发送数据请求，slave之间通过相互通信完成数据的汇总，并最终直接返还给数据请求者已经汇总完毕的结果。数据请求者不需要进行任何的数据汇总工作。scatter-and-gather分布式模型的优点在于在需要汇总的数据量很大的情况下，可以有效地避免单点瓶颈问题。根据本申请实施例，作为本实施例中的优选，如图10所示，还包括：动态调节模块，所述动态调节模块60包括：再判断单元601，在再次接收到查询请求后，判断按照预期选中的所述预设维度组合下的立方体数据的聚合程度；调整执行单元602，用于在所述预设维度组合下的立方体数据的聚合程度由低变为高时，切换至第一分布式查询引擎对所述查询请求执行查询处理。本申请实施例的再判断单元601中由于需要进行动态路由调节，所以在再次接收到查询请求后，需要重新判断按照预期选中的所述预设维度组合下的立方体数据的聚合程度，并且继续下述操作。即在每次接收到查询请求时，都需要进行按照预期选中的所述预设维度组合下的立方体数据的聚合程度的判断。本申请实施例的调整执行单元602中在所述预设维度组合下的立方体数据的聚合程度由低变为高时，则路由动态切换至第一分布式查询引擎对所述查询请求执行查询处理。即根据聚合程度的变化情况比如由低至高，进行采用第一分布式查询引擎对所述查询请求执行查询处理的切换。此外，在执行上述判断按照预期选中的所述预设维度组合下的立方体数据的聚合程度的操作时，还需要评估执行所述查询请求的代价结果；当按照预期选中的所述预设维度组合下的立方体数据相同和/或重叠时，根据所述代价结果调整选用所述第一分布式查询引擎或所述第二分布式查询引擎。即需要根据预设基于代价的规则库计算出查询代价并判断是否对分布式查询引擎的选择进行调整。通过上述操作，实现了动态以及智能的查询引擎路由机制，从而可以提高预计算系统的性能和效率以及稳定性。根据预计算结果中的元信息和查询本身的特性，可动态智能地选择最优的分布式计算模型。显然，本领域的技术人员应该明白，上述的本申请的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请不限制于任何特定的硬件和软件结合。本申请的实现原理如下：传统的通用查询系统会对该sql查询进行词法分析、语法分析、逻辑分析、物理分析等，最后得到的执行计划被会用到物理环境中对全表数据进行处理。以“selectsum(amount),cityfromtransactionsgroupbycity”sql查询语句为例，对于预计算查询系统来说，在预计算查询系统中可以提前将对原始数据进行离线处理，预先让用户定义好关键的维度(如上述“city”)和度量(如上述“sum(amount)”)，从而系统可以提前使用离线作业，预计算好按照维度聚合度量的结果，上述的结果的集合在olap系统中通常被称作cube。由于cube数据是经过聚合的，而且筛选了维度和度量，因此cube数据的数据量通常比原始数据要小得多。当查询真正到来的时候，直接用cube中的数据回答查询而非使用原始数据回答，所需要处理的数据量就小的多，有时这种数据量的差别是o(n)和o(1)的关系，其中n是原始数据的行数。区别于通用的查询引擎，预计算olap系统中的查询引擎面对的不是原始数据，而是已经完成好聚合的cube。cube是预计算结果的集合，集合中的每个元素为按照某种特定维度组合下的度量结果，可称为一个cuboid。比如，保险公司的交易表中可能产生一个cube，其中包括cuboid1是按照城市聚合的总交易量，cuboid2可能是按照保险销售员聚合的最大成交笔数。不同的cuboid源自相同的原始数据，但是其本身的行数，列数，以及大小可能都是不同的。对于不同的查询，预计算查询系统预期选中的cube/或者cuboid是不同的。这就给分布式物理执行模型提供了很大选择余地：当某个查询选中的是一个被聚合程度很高的cuboid即数据行数很少的cuboid的情况，如一个按照年龄维度聚合的cuboid，则完成这个查询所需访问的cuboid数据量是很小的，而如果查询选中的是一个按照承保人+日期维度聚合的低聚合程度的cuboid即数据行数很多的cuboid，则需要访问的cuboid数据量仍然是很大的。本申请中的用于预计算系统中查询引擎的动态路由方法，基于规则库和预计算元信息在预计算系统的查询引擎中实现了智能路由机制，让预计算查询系统能够以降低查询响应时间，同时保障系统稳定性为目标，在scatter-and-gather引擎和total-exchange引擎之间自动切换。如图11所示，由于预计算的特性，可以在查询到来之前就可以获知并缓存预计算的每一个cuboid的行数、大小以及基数等特性在内存中，让动态路由模块可以以低廉的代价访问到该些元信息。如图11所示，动态路由模块可以使用一个基础原则：即选用scatter-and-gather模型服务高聚合程度的cuboid，而total-exchange模型服务低聚合程度的cuboid。这样既能获得scatter-and-gather引擎的性能优势，又能获得total-exchange的稳定性可靠性优势。同时，智能路由模块也依靠一定的规则库对这种简单的原则进行补充。即使两条查询选中了相同的cuboid，对于cuboid的使用方式也可能是很不相同的。具体而言，如果有一个cuboid的维度是保险销售员(seller_id)和日期(date)，度量是保单金额总和：sum(amount)，由于销售员的数量可能很多，cuboid的聚合度可能不是很高。所述cuboid对应的数据内容可能如下表所示，是按照每位销售员在每天的销售记录的交易额进行汇总的结果：表1(假设总共有10万个销售员，省略剩下的10w行预计算结果)seller_iddatesum(amount)100011.1100100011.2200100021.1150100031.280100031.330具体地，对于两条查询语句sql1和sql2，比如，sql1查询语句是分析工号大于10002的新销售员的每日成交总额：selectsum(amount),datefromtransactionswhereseller_id>10002groupbydateorderbydatesql2查询语句是分析编号为10003的销售员在1月1日的成交总额：selectsum(amount)fromtransactionswheredate＝’1.1’andseller_id＝‘10003’上述两条sql查询都会击中上表1中的cuboid，但是sql1会涉及大量的数据扫描，所述sql2可以很精准地只获取部分的数据就足以完成查询。通过规则库的影响，识别所述sql1中的查询的代价需要扫描cuboid的大部分数据，在进一步进行汇总的时候存在潜在的单点风险。所述sql2中的查询仅需要扫描少量的cuboid数据，单点风险较小。由上分析可知，两个查询语句的特点存在明显差异，造成了sql1适合选用total-exchange模型，所述sql2适合选用scatter-and-gather模型的情况。如图12所示，是scatter-and-gather模型原理示意图。在所述scatter-and-gather模型中数据存放在每个slave所在的节点上，数据请求者向每个slave单独发送数据请求，并在请求者自己的内存中完成数据的汇总，其中，汇总通常指着预聚合数据的再加工处理。scatter-and-gather模型的优点是实现简单，性能高效，尤其是数据请求者仅需从每个slave获取少量的数据，且最后汇总的数据总量并不是很大的情况下。但是如果最终需要汇总的数据量达到了一定的规模，则大量的数据在数据请求端形成堆积，轻微的情况下会影响性能，严重时甚至导致数据请求者进程崩溃。如图13所示，是total-exchange模型原理示意图。在所述total-exchange模型中数据存放在每个slave所在的节点上，数据请求者向每个slave单独发送数据请求，slave之间通过相互通信完成数据的汇总，并最终直接返还给数据请求者已经汇总完毕的结果。数据请求者不需要进行任何的数据汇总工作在需要汇总的数据量很大的情况下，可以有效地避免单点瓶颈问题。所以是一种更可靠更稳定的设计方案。以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。当前第1页12