一种自定义报表的查询方法、计算节点及查询系统

摘要

本发明公开一种自定义报表的查询方法、计算节点及查询系统，所述查询方法包括：接收客户端发送的自定义报表查询请求，根据所述查询请求进行语法解析，生成逻辑计划；将所述逻辑计划转换为多个物理计划；从多个物理计划中选择最佳的物理计划；根据所述最佳的物理计划生成携带有存储插件名称的控制指令；根据存储插件名称的控制指令从存储插件系统表中读取对应存储插件的配置文件，使所述存储插件根据所述配置文件从数据源中查询数据并进行元数据解析；对存储插件的解析数据进行计算，得到对自定义报表的查询结果；对所述查询结果做全局聚合，并将聚合后的数据发送至客户端，从而实现对自定义报表的查询统计。

说明书

技术领域

本发明涉及大数据信息查询技术领域，特别是涉及一种自定义报表的查询方法、计算节点及查询系统。

背景技术

传统报表统计方法只能处理结构化数据，不能处理非结构化数据，然而在真实的应用场景中，数据通常存储在各种各样的位置，数据格式也多种多样，为了解决该问题，提出了处理多种多样的数据模型。

1)数据仓库(Data warehourse)

数据库已经在信息技术领域有了广泛的应用，我们社会生活的各个部门，几乎都有各种各样的数据库保存着与我们的生活息息相关的各种数据。作为数据库的一个分支，数据仓库概念的提出，相对于数据库从时间上就近得多。美国著名信息工程专家WilliamInm博士在90年代初提出了数据仓库概念的一个表述，认为：“一个数据仓库通常是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合，它用于对管理决策过程的支持。”

这里的主题，是指用户使用数据仓库进行决策时所关心的重点方面，如：收入、客户、销售渠道等；所谓面向主题，是指数据仓库内的信息是按主题进行组织的，而不是像业务支撑系统那样是按照业务功能进行组织的。

集成，是指数据仓库中的信息不是从各个业务系统中简单抽取出来的，而是经过一系列加工、整理和汇总的过程，因此数据仓库中的信息是关于整个企业的一致的全局信息。

随时间变化，是指数据仓库内的信息并不只是反映企业当前的状态，而是记录了从过去某一时点到当前各个阶段的信息。

2)大规模并行处理数据库(Massively parallel processing Database)

传统数据仓库通常是单机的，只能垂直扩展而不能水平扩展，导致其扩展成本非常高昂。所谓垂直扩展就是通过增加cpu或者内存来提高机器的性能，水平扩展是指通过增加新的机器来提高整体服务性能。

大规模并行处理(Massively parallel processing，MPP)有多个处理单元组成，每个处理单元有独立的操作系统，cpu，内存，和磁盘，处理单元之间通过网络互联，处理单元可以并行工作。大规模并行处理系统容易进行水平扩展，通常可以扩展到几十甚至上百个处理单元。

在大规模并行处理系统之上构建的数据库叫做大规模并行处理数据库，简称为MPP数据库。MPP数据库可以将数据存储在多个独立的服务器上，可以进行并行查询，具有较好的查询性能。MMP的缺点是，架构昂贵；不适合复杂查询；可扩展性较差，通常只能扩展到几十台，最多上百台。

3)Map(映射)Reduce(归约)

Map Reduce是一个用于处理海量数据的具有自动容错的集群编程模型。MapReduce通常由三个阶段组成，如图1所示：

Map阶段：首先是读数据，数据来源可能是文本文件，表格，MySQL数据库。这些数据通常是成千上万的文件，称为shards(碎片)，shards被当做一个逻辑输入源。然后Map阶段调用用户实现的函数，即Mapper(映射函数)，独立且并行的处理每个shard。对于每个shard，Mapper返回多个键值对，这是Map阶段的输出。

Shuffle阶段：把键值对进行归类，也就是把所有相同的键的键值对归为一类。这个步骤的输出是不同的键和该键的对应的值的数据流。

Reduce阶段:输入当然是shuffle的输出。然后Reduce阶段调用用户实现的函数，即Reducer(归约函数)，对每个不同的键和该键的对应的值的数据流进行独立、并行的处理。每个reducer遍历键对应的值，然后对值进行“置换”。这些置换通常指的的是值的聚合或者什么也不处理，然后把键值对写入数据库、表格或者文件中。

4)Hadoop(分布式系统基础框架)/Spark

Hadoop/Spark是Map Reduce最流行的一个开源实现。很多企业使用Hadoop实现Web索引，数据挖掘，报表统计等功能。

其中，MPP数据库、Map Reduce和Sql-on-hadoop都能实现报表的统计查询，其中，MPP数据库在上世纪90年代被广泛使用，后来随着数据规模的扩大，其处理性能有待提高，03年以后便出现了以Map Reduce和hadoop数据仓库技术为核心的报表系统。尽管这些系统解决了大规模数据水平扩展的问题，但是在数据处理模型方面仍然具有如下缺点：不适合处理半结构化数据。

具体原因如下：传统查询引擎比如Impla，Presto，Hive在查询数据之前需要知道要查询的表的元数据，这些系统通常有一个中心化元数据仓库负责存储表的元数据，其查询引擎在解析逻辑计划时会查询元数据仓库进行元数据验证，比如，如果用户要查询的列不存在或者数据类型，查询就会失败。

发明内容

本发明的目的是提供一种自定义报表的查询方法、计算节点及查询系统，可实现对报表的查询统计。

为实现上述目的，本发明提供了如下方案：

一种自定义报表的查询方法，所述查询方法包括：

接收客户端发送的自定义报表查询请求，根据所述查询请求进行语法解析，生成逻辑计划；所述自定义报表查询请求中携带有用户指定数据源的存储插件名称；

将所述逻辑计划转换为多个物理计划；

从多个物理计划中选择最佳的物理计划；

根据所述最佳的物理计划生成携带有存储插件名称的控制指令；

根据存储插件名称的控制指令从存储插件系统表中读取对应存储插件的配置文件，使所述存储插件根据所述配置文件从数据源中查询数据并进行元数据解析；对存储插件的解析数据进行计算，得到对自定义报表的查询结果；

对所述查询结果做全局聚合，并将聚合后的数据发送至客户端。

可选的，所述存储插件系统表存储了存储插件名称与存储插件之间的映射关系，所述映射关系包括：存储插件接口、存储插件名称及存储插件对应的配置文件；

所述配置文件包括：存储插件读取的数据源的路径、位置及数据源格式。

可选的，所述将所述逻辑计划转换为多个物理计划，具体包括：

对所述逻辑计划进行初步优化；对初步优化后的逻辑计划进行转换，得到多个物理计划。

为实现上述目的，本发明还提供了如下方案：

一种查询自定义报表的计算节点，所述计算机节点包括：

查询解析器，用于接收客户端发送的自定义报表查询请求，根据所述查询请求进行语法解析，生成逻辑计划；所述自定义报表查询请求中携带有用户指定数据源的存储插件名称；

优化转换器，用于将将所述逻辑计划转换为多个物理计划；

优化选择器，用于从多个物理计划中选择最佳的物理计划；

指令生成器，用于根据所述最佳的物理计划生成携带有存储插件名称的控制指令；

执行器，用于根据存储插件名称的控制指令从存储插件系统表中读取对应存储插件的配置文件，使所述存储插件根据所述配置文件从数据源中查询数据并进行元数据解析；对存储插件的解析数据进行计算，得到对自定义报表的查询结果；

聚合器，用于对查询结果做全局聚合，并将聚合后的数据发送至客户端。

可选的，所述存储插件系统表存储了存储插件名称与存储插件之间的映射关系，所述映射关系包括：存储插件接口、存储插件名称及存储插件对应的配置文件；

所述配置文件包括：存储插件读取的数据源的路径、位置及数据源格式。

可选的，计算节点还包括：

任务调度器，用于将所述控制指令分配给数据距离任务最近的执行器中。

可选的，所述优化转换器将所述逻辑计划转换为多个物理计划，具体包括：

对所述逻辑计划进行初步优化；对初步优化后的逻辑计划进行转换，得到多个物理计划。

为实现上述目的，本发明还提供了如下方案：

一种自定义报表的查询系统，所述查询系统包括：

多个上述查询自定义报表的计算节点；以及

客户端，用于轮询或者随机的选择一个计算节点，作为计算主节点，将自定义报表查询请求发送至所述计算主节点；以及接收所述计算主节点发送的对自定义报表的查询结果。

可选的，各计算节点运行在hadoop分布式系统基础框架集群上。

可选的，所述自定义报表的查询系统还包括：

协调服务组件，用于在动态修改一个计算节点的存储插件系统表后，将变化同步到其他计算节点中。

根据本发明提供的具体实施例，本发明公开了以下技术效果：

本发明通过对查询请求进行语法解析依次生成逻辑计划、物理计划、控制指令，根据控制指定从存储插件系统表中读取对应存储插件的配置文件，使所述存储插件根据所述配置文件从数据源中查询数据并进行元数据解析；进而对存储插件的解析数据进行计算、全局聚合，从而实现对自定义报表的查询统计；通过将元数据解析从逻辑计划阶段移动到存储插件中，不再需要一个中心化的元数据仓库来存储系统元数据，从而可以实现无模式数据模型架构，可以处理结构化，半结构化数据类型等多种数据源。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例自定义报表的查询方法的流程图；

图2为本发明实施例查询自定义报表的计算节点。

符号说明：

查询解析器—1，优化转换器—2，优化选择器—3，指令生成器—4，执行器—5，聚合器—6，任务调度器—7。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明的目的是提供一种自定义报表的查询方法，通过对查询请求进行语法解析依次生成逻辑计划、物理计划、控制指令，根据控制指定从存储插件系统表中读取对应存储插件的配置文件，使所述存储插件根据所述配置文件从数据源中查询数据并进行元数据解析；进而对存储插件的解析数据进行计算、全局聚合，从而实现对自定义报表的查询统计；通过将元数据解析从逻辑计划阶段移动到存储插件中，不再需要一个中心化的元数据仓库来存储系统元数据，从而可以实现无模式数据模型架构，可以处理结构化，半结构化数据类型等多种数据源。

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

如图1所示，本发明自定义报表的查询方法包括：

步骤100：接收客户端发送的自定义报表查询请求，根据所述查询请求进行语法解析，生成逻辑计划。

步骤200：将所述逻辑计划转换为多个物理计划。

步骤300：从多个物理计划中选择最佳的物理计划。

步骤400：根据所述最佳的物理计划生成携带有存储插件名称的控制指令。

步骤500：根据存储插件名称的控制指令从存储插件系统表中读取对应存储插件的配置文件，使所述存储插件根据所述配置文件从数据源中查询数据并进行元数据解析；对存储插件的解析数据进行计算，得到对自定义报表的查询结果；

步骤600：对所述查询结果做全局聚合，并将聚合后的数据发送至客户端。

其中，所述自定义报表查询请求中携带有用户指定数据源的存储插件名称。在步骤100中，将查询请求解析为逻辑计划(Logical Plan)，该阶段只进行语法解析，不进行元数据解析。

与之相比，在现有的MPP数据库或者Hadoop数据仓库的查询引擎在生产逻辑计划阶段，会查询一个中心化的元数据仓库进行数据源的有效性验证，比如用查询的表和列是否存在，类型是否匹配，如果不匹配，则无法进行后续操作，从而不利于报表的统计查询。

在步骤200中，所述将所述逻辑计划转换为多个物理计划，具体包括：

对所述逻辑计划进行初步优化；对初步优化后的逻辑计划进行转换，得到多个物理计划。

在步骤500中，所述存储插件系统表存储了存储插件名称与存储插件之间的映射关系，所述映射关系包括：存储插件接口、存储插件名称及存储插件对应的配置文件；所述配置文件包括：存储插件读取的数据源的路径、位置及数据源格式。

其中，所述对存储插件的解析数据进行计算，具体包括：根据配置选择使用AQPEngine(引擎)进行近似计算或者使用MPP Executor(大规模并行处理执行器)执行精确计算。

如图2所示，本发明还提供一种查询自定义报表的计算节点(MPP Worker)，本发明查询自定义报表的计算节点包括查询解析器1、优化转换器2、优化选择器3、指令生成器4、执行器5及聚合器6。

其中，所述查询解析器1用于接收客户端发送的自定义报表查询请求，根据所述查询请求进行语法解析，生成逻辑计划；所述自定义报表查询请求中携带有用户指定数据源的存储插件名称。所述优化转换器2用于将将所述逻辑计划转换为多个物理计划；所述优化选择器3用于从多个物理计划中选择最佳的物理计划；所述指令生成器4用于根据所述最佳的物理计划生成携带有存储插件名称的控制指令；所述执行器5用于根据存储插件名称的控制指令从存储插件系统表中读取对应存储插件的配置文件，使所述存储插件根据所述配置文件从数据源中查询数据并进行元数据解析；对存储插件的解析数据进行计算，得到对自定义报表的查询结果；所述聚合器6用于对所述查询结果做全局聚合，并将聚合后的数据发送至客户端。

其中，所述存储插件系统表存储了存储插件名称与存储插件之间的映射关系，所述映射关系包括：存储插件接口、存储插件名称及存储插件对应的配置文件；所述配置文件包括：存储插件读取的数据源的路径、位置及数据源格式。

所述优化转换器2将所述逻辑计划转换为多个物理计划，具体包括：

对所述逻辑计划进行初步优化；对初步优化后的逻辑计划进行转换，得到多个物理计划。

所述优化选择器3为基于规则(rule based)和基于开销(cost baed)的优化器，通过所述基于规则基于开销的优化器可从多个物理计划中选择最佳的物理计划。

所述指令生成器4对最佳的物理计划生成充分利用现代处理器结构的指令。

此外，本发明查询自定义报表的计算节点还包括任务调度器7，所述任务调度器7用于将所述控制指令分配给数据距离任务最近的执行器中，从而避免数据的移动。

本发明还提供一种自定义报表的查询系统。具体的，本发明自定义报表的查询系统包括多个上述查询自定义报表的计算节点；以及客户端，所述客户端8用于轮询或者随机的选择一个计算节点，作为计算主节点，将自定义报表查询请求发送至所述计算主节点(Mpp Main Worker)；以及接收所述计算主节点发送的聚合后的数据。

其中，各计算节点运行在hadoop分布式系统基础框架集群上。

优选地，本发明自定义报表的查询系统还包括：协调服务组件(Zookeeper)，用于在动态修改一个计算节点的存储插件系统表后，将变化同步到其他计算节点中。

每一个计算节点都有一个存储插件系统表，存储插件系统表存储了存储插件名称和存储插件之间的映射关系，所述映射关系包括存储插件接口、存储插件名称及存储插件对应的配置文件，存储插件系统表提供插入/移除/查询插件接口。用户可以不用重启计算节点动态的添加存储插件到任意一个计算节点的存储插件系统表，当一个计算节点的存储插件系统表变更后Zookeepr会得到通知，Zookeeper会将变化同步到其他计算节点。

存储插件根据配置文件从数据源中查询数据，并解析数据的元数据以供MPPComputor使用。当用户需要添加一个新的数据源时，只需要实现一个新的存储插件并注册到存储插件系统表即可。

本发明中的计算节点基于MPP架构：由于MPP架构中的计算节点机构相同，所以基于该架构的报表计算方法易于理解和实现。其次，在多用户下MPP架构具有很好的性能，这是因为MPP Client可以将用户提交的查询请求提交给任意一个MPP Worker来执行，同时Query Compiler将用户统计逻辑编译成分布式查询计划。

数据处理模型是Map Reduce：为了提供更好的容错，数据模型采用Map Reduce。因为Map执行的是确定性动作，并且其输入稳定存储，因此，当map出现故障后，可以重新提交这个map到一个新的MPP Worker上来执行，从而实现自动容错。

依赖ZooKeeper协调各个计算节点：Zookeeper用于协调MPP Worker，并自动进行容错管理。Zookeeper负责监控集群所有计算节点，当某一台计算节点出现故障后，Zookeeper会得到通知并通知集群中所有其他计算节点，以避免将计算任务调教给一个出现故障的计算节点。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。

本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本发明的限制。