查询处理方法、查询处理系统、服务器和计算机可读介质与流程

本公开涉及物联网技术领域和云计算领域，特别涉及一种查询处理方法、查询处理系统、服务器和计算机可读介质。

背景技术：

在物联网领域，数据对于企业来说的重要性不可估量，通过挖掘数据背后的价值，可以分析过去，监控现在以及决策未来。这个过程中，一个重要的环节就是数据的查询。

物联网领域的数据类型多样化，数据量海量化，查询场景覆盖联机分析处理(On-Line Analysis Processing，简称OLAP)规模查询业务和联机事务处理(On-Line Transaction Processing，简称 OLTP)规模查询业务，而现有的数据查询引擎难以同时支持OLAP规模查询业务和OLTP规模查询业务，即现有的数据查询技术无法满足物联网领域的查询需求。

技术实现要素：

本公开旨在至少解决现有技术中存在的技术问题之一，提出了一种查询处理方法、查询处理系统、服务器和计算机可读介质。

第一方面，本公开实施例提供了一种查询处理方法，包括：

服务节点解析查询请求并生成相应的逻辑执行计划；

所述服务节点判断所述逻辑执行计划属于OLAP规模查询业务或 OLTP规模查询业务；

当判断出所述逻辑执行计划属于OLAP规模查询业务时，则所述服务节点将所述逻辑执行计划切分为多个逻辑执行子计划，并将完成切分的所述逻辑执行计划发送至协调节点；

所述协调节点生成所述逻辑执行计划对应的第一物理执行计划，并反馈至所述服务节点，所述第一物理执行计划中记载有各所述逻辑执行子计划对应的处理节点的节点信息；

所述服务节点根据所述第一物理执行计划，将各所述逻辑执行子计划分配至对应的处理节点；

所述处理节点处理相应的逻辑执行子计划，得到查询子结果，并将所述处理子结果进行逐层上报；

所述服务节点对接收到的处理子结果进行汇总，生成最终查询结果，并将所述最终查询结果反馈至用户。

在一些实施例中，当判断出所述逻辑执行计划属于OLTP规模查询业务时，则所述服务节点将所述逻辑执行计划发送至协调节点；

所述协调节点生成所述逻辑执行计划对应的第二物理执行计划，并反馈至所述服务节点，所述第二物理执行计划中记载有所述逻辑执行计划对应的处理节点的节点信息；

所述服务节点根据所述第二物理执行计划，将所述逻辑执行计划分配至对应的处理节点；

所述处理节点处理相应的所述逻辑执行计划，得到最终查询结果，并将所述最终查询结果上传至所述服务节点；

所述服务节点将接收到的所述最终查询结果反馈至用户。

在一些实施例中，服务节点判断所述逻辑执行计划属于OLAP规模查询业务或OLTP规模查询业务的步骤包括：

所述服务节点向存储节点询问与所述逻辑执行计划相关联的各数据源的数据量；

所述服务节点根据所述存储节点所反馈的与所述逻辑执行计划相关联的各数据源的数据量，评估出所述逻辑执行计划对应的数据查询总量；

所述服务节点比较所述数据查询总量与预定查询总量的大小；

若比较出所述数据查询总量大于所述预定查询总量，则所述服务节点判断出所述逻辑执行计划属于OLAP规模查询业务；若比较出所述数据查询总量小于或等于所述预定查询总量，则所述服务节点判断出所述逻辑执行计划属于OLTP规模查询业务。

在一些实施例中，所述处理节点处理相应的逻辑执行子计划的步骤具体包括：

所述处理节点检测自身所接收到的逻辑执行子计划属于查询计划或聚合计划；

当检测出其自身所接收到的逻辑执行子计划属于查询计划时，则所述处理节点将所述逻辑执行子计划转发至存储节点，以供所述存储节点构建针对所述逻辑执行子计划的数据库；

所述处理节点在所述存储节点所构建的针对所述逻辑执行子计划的数据库中执行相应的查询操作，得到相应的查询子结果；

其中，在所述存储节点接收到处理节点所发送的逻辑执行子计划时，还包括：所述存储节点构建针对所述逻辑执行子计划的数据库。

在一些实施例中，当检测出其自身所接收到的逻辑执行子计划属于聚合计划时，则所述处理节点接收下级处理节点所上报的查询子结果，并进行聚合处理。

在一些实施例中，所述存储节点构建针对所述逻辑执行子计划的数据库的步骤具体包括：

所述存储节点根据接收到的所述逻辑执行子计划，获取与所述逻辑执行子计划相关联的数据源提供的数据表；

所述存储节点判断与所述逻辑执行子计划相关联的数据源的数量是否大于1；

当判断出与所述逻辑执行子计划相关联的数据源的数量大于1 时，则所述存储服务节将与所述逻辑执行子计划相关联的各数据源所提供的数据表映射为关系型数据库；

当判断出与所述逻辑执行子计划相关联的数据源的数量等于1 时，则将与所述逻辑执行子计划相关联的1个数据源所提供的数据表作为数据库。

在一些实施例中，所述存储节点根据接收到的所述逻辑执行子计划，获取与所述逻辑执行子计划相关联的数据源提供的数据表的步骤包括：

所述存储节点确定出与所述逻辑执行子计划相关联的数据源；

所述存储节点从预先存储的对应关系表中确定出与所述逻辑执行子计划相关联的各数据源所对应的优选处理字段，所述对应关系表中记载有不同数据源及其对应的优选处理字段；

针对与所述逻辑执行子计划相关联的每一个数据源，所述存储节点判断该数据源所对应的优选处理字段是否为所述逻辑执行子计划所包含查询条件的查询字段；

若判断出该数据源所对应的优选处理字段为所述逻辑执行子计划所包含查询条件的查询字段时，则所述存储节点将所述逻辑执行子计划内该数据源所对应的优选处理字段的查询条件发送至该数据源，以供该数据源根据接收到的查询条件对自身所存储的数据表进行筛选，然后再将完成筛选的数据表反馈至所述存储节点；

若判断出该数据源所对应的不为所述逻辑执行子计划所包含查询条件的查询字段时，则所述存储节点向该数据源发送数据获取请求，以供该数据源反馈自身的数据表。

在一些实施例中，在所述服务节点解析查询请求并生成相应的逻辑执行计划的步骤之前，还包括：

元信息管理节点对用户身份信息进行有效性验证；

当用户身份信息通过有效性验证时，则所述服务节点执行解析查询请求并生成相应的逻辑执行计划的步骤；

当用户身份信息未通过有效性验证时，则所述元信息管理节点向用户反馈身份信息验证失败信息。

第二方面，本公开实施例提供了一种查询处理系统，包括：服务节点、协调节点和多个处理节点；

所述服务节点包括：解析模块、第一判断模块、切分模块、第一分配模块、汇总模块和第一反馈模块；

所述协调节点包括：第一生成模块；

所述处理节点包括：第一处理模块；

所述解析模块用于解析查询请求并生成相应的逻辑执行计划；

所述第一判断模块用于判断所述逻辑执行计划属于OLAP规模查询业务或OLTP规模查询业务；

所述切分模块用于当所述第一判断模块判断出所述逻辑执行计划属于OLAP规模查询业务时，将所述逻辑执行计划切分为多个逻辑执行子计划，并将完成切分的所述逻辑执行计划发送至协调节点；

所述第一生成模块用于生成从所述切分模块处接收到的所述逻辑执行计划对应的第一物理执行计划，并反馈至所述服务节点，所述第一物理执行计划中记载有各所述逻辑执行子计划对应的处理节点的节点信息；

所述第一分配模块用于根据所述第一物理执行计划，将各所述逻辑执行子计划分配至对应的处理节点；

所述第一处理模块用于处理相应的逻辑执行子计划，得到查询子结果，并将所述处理子结果进行逐层上报；

所述汇总模块用于对接收到的处理子结果进行汇总，生成最终查询结果；

所述第一反馈模块用于将所述最终查询结果反馈至用户。

在一些实施例中，所述服务节点还包括：发送模块、第二分配模块和第二反馈模块；

所述协调节点还包括：第二生成模块；

所述处理节点还包括：第二处理模块；

所述发送模块用于当所述第一判断模块判断出所述逻辑执行计划属于OLTP规模查询业务时，将所述逻辑执行计划发送至协调节点；

所述第二生成模块用于生成从所述发送模块处接收到的所述逻辑执行计划对应的第二物理执行计划，并反馈至所述服务节点，所述第二物理执行计划中记载有所述逻辑执行计划对应的处理节点的节点信息；

所述第二分配模块用于根据所述第二物理执行计划，将所述逻辑执行计划分配至对应的处理节点；

所述第二处理模块用于处理相应的所述逻辑执行计划，得到最终查询结果，并将所述最终查询结果上传至所述服务节点；

所述第二反馈模块用于将接收到的所述最终查询结果反馈至用户。

在一些实施例中，所述查询处理系统还包括：存储节点，所述存储节点包括：存储模块，所述存储模块中预先存储有各数据源的数据量信息；

所述第一判断模块包括：询问单元、评估单元和比较单元；

所述询问单元用于向存储节点询问与所述逻辑执行计划相关联的各数据源的数据量；

所述评估单元用于根据所述存储节点所反馈的与所述逻辑执行计划相关联的各数据源的数据量，评估出所述逻辑执行计划对应的数据查询总量；

所述比较单元用于比较所述数据查询总量与预定查询总量的大小；

若所述比较单元比较出所述数据查询总量大于所述预定查询总量，则所述第一判断模块判断出所述逻辑执行计划属于OLAP规模查询业务；若所述比较单元比较出所述数据查询总量小于或等于所述预定查询总量，则所述第一判断模块判断出所述逻辑执行计划属于 OLTP规模查询业务。

在一些实施例中，所述第一处理模块包括：第一检测单元、转发单元和查询单元；

所述查询处理系统还包括：存储节点，所述存储节点包括：构建模块；

所述第一检测单元用于检测所述处理节点自身所接收到的逻辑执行子计划属于查询计划或聚合计划；

所述转发单元用于当所述第一检测单元检测出所述处理节点自身所接收到的逻辑执行子计划属于查询计划时，将所述逻辑执行子计划转发至存储节点，以供所述存储节点构建针对所述逻辑执行子计划的数据库；

所述查询单元用于在所述存储节点所构建的针对所述逻辑执行子计划的数据库中执行相应的查询操作，得到相应的查询子结果；

所述构建模块用于在所述存储节点接收到处理节点所发送的逻辑执行子计划时，构建针对所述逻辑执行子计划的数据库。

在一些实施例中，所述第一处理模块还包括：聚合单元；

所述聚合单元用于当所述第一检测单元检测出所述处理节点自身所接收到的逻辑执行子计划属于聚合计划时，接收下级处理节点所上报的查询子结果，并进行聚合处理。

在一些实施例中，所述构建模块包括：获取单元、判断单元和处理单元；

所述获取单元用于根据接收到的所述逻辑执行子计划，获取与所述逻辑执行子计划相关联的数据源提供的数据表；

所述判断单元用于判断与所述逻辑执行子计划相关联的数据源的数量是否大于1；

所述处理单元用于当所述判断单元判断出与所述逻辑执行子计划相关联的数据源的数量大于1时，将与所述逻辑执行子计划相关联的各数据源所提供的数据表映射为关系型数据库；以及，用于当所述判断单元判断出与所述逻辑执行子计划相关联的数据源的数量等于 1时，将与所述逻辑执行子计划相关联的1个数据源所提供的数据表作为数据库。

在一些实施例中，所述获取单元包括：第一确定子单元、第二确定子单元、判断子单元、第一发送子单元和第二发送子单元；

所述第一确定子单元用于确定出与所述逻辑执行子计划相关联的数据源；

所述第二确定子单元用于从预先存储的对应关系表中确定出与所述逻辑执行子计划相关联的各数据源所对应的优选处理字段，所述对应关系表中记载有不同数据源及其对应的优选处理字段；

所述判断子单元用于针对与所述逻辑执行子计划相关联的每一个数据源，判断该数据源所对应的优选处理字段是否为所述逻辑执行子计划所包含查询条件的查询字段；

所述第一发送子单元用于当所述判断子单元判断出该数据源所对应的优选处理字段为所述逻辑执行子计划所包含查询条件的查询字段时，将所述逻辑执行子计划内该数据源所对应的优选处理字段的查询条件发送至该数据源，以供该数据源根据接收到的查询条件对自身所存储的数据表进行筛选，然后再将完成筛选的数据表反馈至所述存储节点；

所述第二发送子单元用于当所述判断子单元判断出该数据源所对应的不为所述逻辑执行子计划所包含查询条件的查询字段时，向该数据源发送数据获取请求，以供该数据源反馈自身的数据表。

在一些实施例中，所述查询处理系统还包括：元信息管理节点，所述元信息管理节点包括：验证模块和第三反馈模块；

所述验证模块用于对用户身份信息进行有效性验证；

所述第三反馈模块用于当用户身份信息未通过有效性验证时，所述元信息管理节点向用户反馈身份信息验证失败信息；

所述解析模块具体用于当用户身份信息通过有效性验证时，解析查询请求并生成相应的逻辑执行计划。

第三方面，本公开实施例提供了一种服务器，包括：一个或多个处理器；存储装置，其上存储有一个或多个程序，当上述一个或多个程序被上述一个或多个处理器执行时，使得上述一个或多个处理器实现如第一方面中任一实现方式描述的方法。

第四方面，本公开实施例提供了一种计算机可读存储介质，其上存储有计算机程序，其中，该计算机程序被一个或多个处理器执行时实现如第一方面中任一实现方式描述的方法

本公开具有以下有益效果：

本公开实施例提供了一种查询处理方法，该查询处理方法可基于查询请求所对应的数据规模来选择不同的处理流程，该查询处理方法能够同时支持OLAP规模查询业务和OLTP规模查询业务，满足物联网领域的查询需求；

另外，针对跨多个数据源的联合查询，本公开中通过设置存储节点，该存储节点可将不同数据源提供的不同数据表映射为关系型数据库的形式，使得跨服务的联合查询变为可能。

此外，而对于用户而言，只要利用SQL语言，就能在多个数据源之上进行一站式的数据查询，便于用户操作。

附图说明

图1为本公开实施例提供的一种查询处理方法的流程图；

图2为本公开中步骤S2的一种具体实现流程图；

图3为本公开中步骤S6的一种具体实现流程图；

图4为本公开中步骤S602a的一种具体实现流程图；

图5为本公开中步骤S6021的一种具体实现流程图；

图6为本公开实施例提供的另一种查询处理方法的流程图；

图7a为本公开实施例提供的一种查询处理系统的结构框图；

图7b～图7f分别为本公开中服务节点、协调节点、处理节点、存储节点和元信息管理节点的结构框图；

图8为本公开中第一判断模块的一种结构框图；

图9为本公开中第一处理模块的一种结构框图；

图10为本公开中构建模块的一种结构框图；

图11为本公开中获取单元的一种结构框图。

具体实施方式

为使本领域的技术人员更好地理解本公开的技术方案，下面结合附图对本公开提供的一种查询处理方法、查询处理系统、服务器和计算机可读介质进行详细描述。

在下文中将参考附图更充分地描述示例实施例，但是所述示例实施例可以以不同形式来体现且不应当被解释为限于本文阐述的实施例。反之，提供这些实施例的目的在于使本公开透彻和完整，并将使本领域技术人员充分理解本公开的范围。

本文所使用的术语仅用于描述特定实施例，且不意欲限制本公开。如本文所使用的，单数形式“一个”和“该”也意欲包括复数形式，除非上下文另外清楚指出。还将理解的是，当本说明书中使用术语“包括”和/或“由……制成”时，指定存在所述特征、整体、步骤、操作、元件和/或组件，但不排除存在或添加一个或多个其他特征、整体、步骤、操作、元件、组件和/或其群组。

将理解的是，虽然本文可以使用术语第一、第二等来描述各种元件，但这些元件不应当受限于这些术语。这些术语仅用于区分一个元件和另一元件。因此，在不背离本公开的指教的情况下，下文讨论的第一元件、第一组件或第一部件可称为第二元件、第二组件或第二部件。

除非另外限定，否则本文所用的所有术语(包括技术和科学术语) 的含义与本领域普通技术人员通常理解的含义相同。还将理解，诸如那些在常用字典中限定的那些术语应当被解释为具有与其在相关技术以及本公开的背景下的含义一致的含义，且将不解释为具有理想化或过度形式上的含义，除非本文明确如此限定。

在本领域中，根据查询过程中所涉及数据查询总量的多少，将查询业务划分如下两类：OLAP规模查询业务和OLTP规模查询业务；其中，OLAP规模查询业务是指查询过程中所涉及数据查询总量大于预定阈值的查询业务，OLTP规模查询业务是指查询过程中所涉及数据查询总量小于或等于预定阈值的查询业务，该预定阈值的取值可根据实际情况进行设定和调整。OLAP规模查询业务表征查询过程中涉及大规模(一般而言，数量级达到“万”级别)的数据，OLTP规模查询业务表征查询过程中涉及小规模的数据。

在本公开中，以结构化查询语言(Structured Query Language，简称SQL)作为统一的查询语言，SQL是用于访问和处理数据库的标准的计算机语言，功能强大，而且简单易学。当用户需要进行数据查询时，用户以SQL语言向客户端程序(Client SDK)输入查询请求，客户端程序将该查询请求发送至服务节点。在下述各实施例中，涉及到的“用户”均是指通过Client SDK输入查询请求的用户。

本公开提供的查询处理方法基于相应的查询处理系统，该查询处理系统至少包括：服务节点(Server Node)、协调节点(Coodinator Node)和处理节点(Worker Node)。

其中，服务节点为接收查询请求的入口，负责解析查询请求相应的逻辑执行计划，以及一定情况下将逻辑执行计划切分为多个逻辑执行子计划；此外，复位节点还可以根据协调节点生成的物理执行计划来将逻辑执行计划下发至相应的处理节点。

协调节点管理系统内的服务节点和所有处理节点，拥有各处理节点的状态信息(例如：处理节点的当前负载、剩余资源、处理速度等)，可以根据逻辑执行计划，并结合各处理节点的当前负载、剩余资源等因素来生成实际的物理执行计划。

处理节点负责执行服务节点下发的逻辑执行计划/子计划，其中一个处理节点可以处理一个或多个逻辑执行计划/子计划。其中，处理节点接收到的逻辑执行子计划既可能为查询计划，也可能为聚合计划；其中，当处理节点接收到的逻辑执行子计划为查询计划时，处理节点将执行相应的查询操作；当处理节点接收到的逻辑执行子计划为聚合计划时，则该处理节点需要待其下属处理节点(该处理节点的子节点)均完成查询/聚合操作且上报相应数据后，该处理节点再对接收到的数据进行聚合处理。

为便于本领域技术人员更好的理解本公开的技术方案，下面将结合具体示例来进行详细描述。

图1为本公开实施例提供的一种查询处理方法的流程图，如图1 所示，该查询处理方法包括：

步骤S1、服务节点解析查询请求并生成相应的逻辑执行计划。

查询请求为以SQL语言表达的SQL查询语句；在步骤S1中，服务节点利用自身预先存储的命令解析器(Command Parser)检查SQL 查询语句的语法正确性，并检测出SQL查询语句正确时对SQL查询语句进行解析，以转化为系统可以进行操作的内部格式，即得到逻辑执行计划(Logical Plan)；逻辑执行计划用树状结构表示，亦可称为查询树(Query Tree)，逻辑执行计划表征在执行该查询请求时的处理逻辑步骤。

逻辑执行计划中记载与查询请求相关联的各数据源的数据表名以及用于对数据表进行查询的查询条件(亦可称为筛选条件)。

步骤S2、服务节点判断逻辑执行计划属于OLAP规模查询业务或 OLTP规模查询业务。

图2为本公开中步骤S2的一种具体实现流程图，如图2所示，在本公开中该查询处理系统还包括存储节点(Storage Node)，存储节点负责对接所有物联网服务提供方，物联网服务提供方作为数据源能够根据存储节点的请求向存储节点提供相应的数据表，存储节点实时监测各数据源的数据表内数据量。

需要说明的是，本公开中“数据量”是指数据表内所包含数据记录(一般而言，数据表内1行数据表示1条数据记录)的条数。

处理节点可通过存储节点来访问数据源所提供的数据表，其中当处理节点需要同时对不同数据源所提供的异构数据表进行查询时，存储节点可将不同数据源提供的异构数据表映射为关系型数据库，以屏蔽不同数据源的数据结构差异。

步骤S2具体包括：

步骤S201、服务节点向存储节点询问与逻辑执行计划相关联的各数据源的数据量。

在步骤S201中，假定与与逻辑执行计划相关联的数据源的数据表数量为n，其中第i个数据源的数据表中数据记录为Ki条，其中n 为大于1的整数，k为小于等于n的正整数。

步骤S202、服务节点根据存储节点所反馈的与逻辑执行计划相关联的各数据源的数据量，评估出逻辑执行计划对应的数据查询总量。

在步骤S202中，基于与逻辑执行计划相关联的各数据源的数据量，可对与逻辑执行计划对应的数据查询总量进行评估。

作为一种可选方案，可采用如下式子来评估出数据查询总量S：

需要说明的是，上述示例出的评估与逻辑执行计划对应的数据查询总量进行评估的算法，仅为本公开中的一种可选方案，其不会对本公开的技术方案产生限制。本领域技术人员应该知晓的是，但凡是基于与逻辑执行计划相关联的各数据源的数据量，来评估出逻辑执行计划对应的数据查询总量所使用的任意算法，均应属于本公开的保护范围，具体算法此处不再一一举例。

步骤S203、服务节点比较数据查询总量与预定查询总量的大小。

该预定查询总量(即前述的“预定阈值”)可根据实际需要进行设定和调整。

在步骤S203中，若比较出数据查询总量大于预定查询总量(大规模的数据)，则服务节点判断出逻辑执行计划属于OLAP规模查询业务；若比较出数据查询总量小于或等于预定查询总量(小规模的数据)，则服务节点判断出逻辑执行计划属于OLTP规模查询业务。

在步骤S2中，当判断出逻辑执行计划属于OLAP规模查询业务时，则执行步骤S3；当步骤S3判断出逻辑执行计划属于OLTP规模查询业务时，则执行步骤S9。

步骤S3、服务节点将逻辑执行计划切分为多个逻辑执行子计划，并将完成切分的逻辑执行计划发送至协调节点。

当服务节点判断出逻辑执行计划属于OLAP规模查询业务时，为提升后续的查询速度，将会采用大规模并行处理(Massively Parallel Processing，简称MPP)技术来进行后续查询处理。

在步骤S3中，服务节点根据预定的切分算法来将逻辑执行计划切分为多个逻辑执行子计划。需要说明的是，本公开中所使用的切分算法可以为现有MPP构架中常规使用的切分算法；一般而言，MPP的切分出的各逻辑执行子计划所对应的查询总量是平均的。

为便于本领域技术人员进行理解，下面将结合一个具体示例进行详细描述。

查询场景如下：客户需要查询2019-01-01这一天内所有服务器设备的心跳数据；其中，服务器设备的设备信息(设备id)存储于设备管理服务提供方(记为hub)的device表中，device表的数据量的数据级大概在“万”级别；各服务器设备的心跳数据存储在时序数据库服务提供方(记为tsdb)的heartbeat表中，heartbeat表的数据量的数据级大概在“十万”级别，device表和heartbeat表通过设备id进行关联。

用户在进行查询时，可通过Client SDK输入如下SQL语句：

SELECT d.id,count(*)from hub.device d join tsdb.heartbeat h on d.id＝h.deviceId

where h.timestamp between‘2019-01-01’and‘2019-01-02’

group by d.id

其中，hub.device表示设备管理服务提供方中的device表(也用d表示)，d.id表示device表中用于表征设备id的字段为“id”， h.timestamp表示heartbeat表中表征时间戳(一般精确到秒)的字段为“timestamp”，h.deviceId表示heartbeat表中表征设备id 的字段为“deviceId”，d.id＝h.deviceId表征device表中的字段“id”与heartbeat表中的字段“deviceId”建立关联。

h.timestamp between‘2019-01-01’and‘2019-01-02’表征查询条件为时间戳在2019年1月1号0时0分0秒至2019年1 月2号0时0分0秒。

由上述内容可见，查询请求中直接记载有与本次查询相关联的数据源(及对应的数据表)和查询条件。

在上述示例中，考虑到device表的数据量的数据级大概在“万”级别，heartbeat表的数据量的数据级大概在“十万”级别，通过步骤S2可以评估出本次查询涉及到的数据查询总量在“亿”级别，属于OLAP规模查询业务。

因此，在步骤S3中，会将逻辑执行计划切分为多个逻辑执行子计划(每一个逻辑执行子计划其本质也是一棵查询树)。作为一种可选切分方案，将以设备id来对逻辑执行计划机械能切分；具体地，将逻辑执行计划切分为100个逻辑执行子计划，其中第N个逻辑执行子计划为：获取设备id与100进行除法运算并求余且余数等于N的各服务器设备(即hub.device.id％100＝N的服务器设备)在 2019-01-01这一天的心跳数据，其中N为小于或等于100的正整数。需要说明的是，上述100个逻辑执行子计划均为查询计划的情况，仅起到示例性作用，其不会对本公开的技术方案产生限制。

需要说明的是，在将逻辑执行计划切分为多个逻辑执行子计划的过程中，所切分出的逻辑执行子计划不仅可以为查询计划，也可以为聚合计划，具体内容可参见后续描述。

在步骤S3中，在逻辑执行计划完成切分后，服务节点将所有逻辑执行子计划一起打包作为一个完整的逻辑执行计划，发送至协调节点。

步骤S4、协调节点生成逻辑执行计划对应的第一物理执行计划，并反馈至服务节点，第一物理执行计划中记载有各逻辑执行子计划对应的处理节点的节点信息。

由于协调节点接收到的逻辑执行计划包含多个逻辑执行子计划，因此协调节点也可识别出本次查询为OLAP规模查询业务。

在步骤S4中，协调节点根据监控到的各处理节点的当前负载、剩余资源、处理速度等信息，基于最小代价算法来为每个逻辑执行子计划配置对应的处理节点。需要说明的是，依据最小代价算法来分配逻辑执行子计划对应的处理节点的具体过程，其属于本领域的常规技术，此处不进行详细描述。

协调节点建立各逻辑执行子计划及对应处理节点的节点IP地址，以生成第一物理执行计划，并将第一物理执行计划反馈至服务节点。

需要说明的是，在为逻辑执行子计划分配处理节点的过程中，不同逻辑执行子计划可能分配至不同处理节点，也可能分配至相同处理节点。

步骤S5、服务节点根据第一物理执行计划，将各逻辑执行子计划分配至对应的处理节点。

步骤S6、处理节点处理相应的逻辑执行子计划，得到查询子结果，并将处理子结果进行逐层上报。

图3为本公开中步骤S6的一种具体实现流程图，如图3所示，步骤S6包括：

步骤S601、处理节点检测自身所接收到的逻辑执行子计划属于查询计划或聚合计划。

在步骤S601中，当检测出其自身所接收到的逻辑执行子计划属于查询计划时，则执行步骤S602；当检测出其自身所接收到的逻辑执行子计划属于聚合计划时，则执行步骤S604。

步骤S602、处理节点将逻辑执行子计划转发至存储节点，以供存储节点构建针对逻辑执行子计划的数据库。

在步骤S602中，处理节点将逻辑执行子计划转发至存储节点，存储节点基于接收到的逻辑执行子计划，并从相应数据源处获取数据表，以形成针对逻辑执行子计划的数据库。

步骤S603、处理节点在存储节点所构建的针对逻辑执行子计划的数据库中执行相应的查询操作，得到相应的查询子结果。

步骤S604、处理节点接收下级处理节点所上报的查询子结果，并进行聚合处理。

需要说明的是，当处理节点接收到的逻辑执行子计划属于聚合计划时，则该处理节点必然有下级处理节点(也称为该处理节点的子节点)。

在步骤S604中，当执行聚合计划的处理节点的所有下级处理节点均执行完相应的逻辑执行子计划并完成数据上报后，执行聚合计划的处理节点对接收到的所有数据进行聚合处理，并将聚合处理得到的数据继续进行上报。

在步骤S602和步骤603之间，还包括：

步骤S602a、存储节点构建针对逻辑执行子计划的数据库。

图4为本公开中步骤S602a的一种具体实现流程图，如图4所示，作为实现步骤S602a的一种可选实施方案，步骤S602a包括：

S6021、存储节点根据接收到的逻辑执行子计划，获取与逻辑执行子计划相关联的数据源提供的数据表。

图5为本公开中步骤S6021的一种具体实现流程图，如图5所示，作为实现步骤S6021的一种优选实施方案，步骤S6021包括：

步骤S60211、存储节点确定出与逻辑执行子计划相关联的数据源。

步骤S60212、存储节点从预先存储的对应关系表中确定出与逻辑执行子计划相关联的各数据源所对应的优选处理字段，对应关系表中记载有不同数据源及其对应的优选处理字段。

在实际应用中，考虑到不同数据源(物联网服务提供方)自身对于不同的查询字段会表现出不同的查询性能(这是由各服务提供方自身特殊的业务场景决定)，即针对某一具体数据源，该数据源会对某一个或几个查询字段表现出较佳的查询性能，因此可将该数据源能够表现出较佳的查询性能的查询字段配置为该数据源所对应的优选处理字段。例如，考虑到时序数据库服务提供方自身对于查询字段为“timestamp”的查询条件具有较佳的查询性能，因此可将数据源为时序数据库服务提供方的优选处理字段设置为“timestamp”。为数据源配置对应的优选处理字段可由人工预先完成，并将各数据源对应的优选处理字段记载于对应关系表中，该对应关系表预先存储于存储节点内。

为便于本领域技术人员更好的理解本公开的技术方案，下面将继续以前述客户需要查询2019-01-01这一天内所有服务器设备的心跳数据的场景为例，进行示例性描述。其中，假定设备管理服务提供方不存在对应的优选处理字段，时序数据库服务提供方对应的优选处理字段为“timestamp”。

第N个逻辑执行子计划被分配至第N个处理节点，第N个处理节点需要执行获取设备id满足hub.device.id％100＝N的各服务器设备在2019-01-01这一天的心跳数据。

此时，该第N个逻辑执行子计划所关联的数据源有两个：1)设备管理服务提供方；2)时序数据库服务提供方；第N个逻辑执行子计划所对应的查询条件有两个：1)hub.device.id％100＝N；2) h.timestamp between‘2019-01-01’and‘2019-01-02’。

在步骤60212中，可以确定出与第N个逻辑执行子计划所关联的设备管理服务提供方对应的优选处理字段为空，与第N个逻辑执行子计划所关联的时序数据库服务提供方对应的优选处理字段为“timestamp”。

针对与逻辑执行子计划相关联的每一个数据源，均执行下述步骤S60213。

步骤S60213、存储节点判断该数据源所对应的优选处理字段是否为逻辑执行子计划所包含查询条件的查询字段；

在步骤S60213中，若判断出该数据源所对应的优选处理字段为逻辑执行子计划所包含查询条件的查询字段时，则执行步骤S60214；若判断出该数据源所对应的不为逻辑执行子计划所包含查询条件的查询字段时，则执行步骤S60215。

步骤S60214、存储节点将逻辑执行子计划内该数据源所对应的优选处理字段的查询条件发送至该数据源，以供该数据源根据接收到的查询条件对自身所存储的数据表进行筛选，然后再将完成筛选的数据表反馈至存储节点。

步骤S60215、存储节点向该数据源发送数据获取请求，以供该数据源反馈自身的数据表。

针对上述步骤S60213～步骤S60215，仍以处理第N个逻辑执行子计划的过程为例，进行示例性描述。

针对数据源为设备管理服务提供方，由于其对应的优选处理字段为空，因此在步骤S60213中会判断出设备管理服务提供方所对应的优选处理字段不为第N个逻辑执行子计划所包含查询条件的查询字段，所以在步骤S60213结束后会执行步骤S60215，即存储节点向设备管理服务提供方发送数据获取请求，设备管理服务提供方会将 device表全部数据都发送给device表。

针对数据源为时序数据库服务提供方，由于其对应的优选处理字段为timestamp，且第N个逻辑执行子计划所包含的查询条件中存在查询字段timestamp，因此在步骤S60213中会判断出设备管理服务提供方所对应的优选处理字段为第N个逻辑执行子计划所包含查询条件的查询字段，所以在步骤S60213结束后会执行步骤S60214，即存储节点将查询条件h.timestamp between‘2019-01-01’and ‘2019-01-02’发送至时序数据库服务提供方，时序数据库服务提供方基于该查询条件对heartbeat表进行筛选，以筛选出满足 timestamp取值在2019年1月1号0时0分0秒至2019年1月2号 0时0分0秒的记录，并将筛选出的记录反馈至存储节点。

S6022、存储节点判断与逻辑执行子计划相关联的数据源的数量是否大于1。

在步骤S6022中，当判断出与逻辑执行子计划相关联的数据源的数量大于1时，则执行步骤S6023；当判断出与逻辑执行子计划相关联的数据源的数量等于1时，则执行步骤S6024。

步骤S6023、存储节点将与逻辑执行子计划相关联的各数据源所提供的数据表映射为关系型数据库。

通过步骤S6023，可以屏蔽不同数据源的数据结构差异。

针对上述步骤S6022和步骤S6023，仍以处理第N个逻辑执行子计划的过程为例。

由于与第N个逻辑执行子计划相关联的数据源的数量为2个，因此在步骤S6022中会判断出与第N个逻辑执行子计划相关联的数据源的数量大于1，此后会执行步骤S6023。在步骤S6023中，存储节点将未进行数据筛选的device表和进行过数据筛选的heartbeat表映射为一个关系型数据库，以供第N个处理节点基于该关系型数据库执行相应的查询计划。

步骤S6024、将与逻辑执行子计划相关联的1个数据源所提供的数据表作为数据库。

当与逻辑执行子计划相关联的数据源数量为1个时，直接将该数据源所提供的数据表作为数据库，以供处理节点执行相应的查询计划。

步骤S7、服务节点对接收到的处理子结果进行汇总，生成最终查询结果。

服务节点对处理节点(可能为1个或多个，由逻辑执行计划对应的树结构所决定)所上报的处理子结果进行汇总，生成最终查询结果。

步骤S8、服务节点将汇总得到的最终查询结果反馈至相应用户。

步骤S9、服务节点将逻辑执行计划发送至协调节点。

当服务节点判断出逻辑执行计划属于OLTP规模查询业务时，则表明数据查询总量相对较小，后续可按照一般的查询流程来进行。

步骤S10、协调节点生成逻辑执行计划对应的第二物理执行计划，并反馈至服务节点，第二物理执行计划中记载有逻辑执行计划对应的处理节点的节点信息。

生成物理执行计划的过程可参见前述描述，此处不再赘述。在步骤S10中，由于逻辑执行计划作为一个整体任务未被切分，第二物理执行计划仅记载有执行该逻辑执行计划的一个处理节点的节点信息。

步骤S11、服务节点根据第二物理执行计划，将逻辑执行计划分配至对应的处理节点。

步骤S12、处理节点处理相应的逻辑执行计划，得到最终查询结果，并将最终查询结果上传至服务节点；

在步骤S12中，处理节点处理的逻辑执行计划一定为查询计划，该处理节点得到的结果即为最终查询结果，后续无需服务节点进行汇总。

需要说明的是，当协调节点生成逻辑执行计划对应的第二物理执行计划时，由于数据查询总量相对较小，因此在服务节点有剩余资源的情况下，也可将服务节点来作为处理节点，以执行逻辑执行计划。

步骤S13、服务节点将接收到的最终查询结果反馈至相应用户。

本公开实施例提供了一种查询处理方法，该查询处理方法可基于查询请求所对应的数据规模来选择不同的处理流程，该查询处理方法能够同时支持OLAP规模查询业务和OLTP规模查询业务，满足物联网领域的查询需求；

另外，针对跨多个数据源的联合查询，本公开中通过设置存储节点，该存储节点可将不同数据源提供的不同数据表映射为关系型数据库的形式，使得跨服务的联合查询变为可能。

此外，而对于用户而言，只要利用SQL语言，就能像往常访问关系型数据库一样，在多个数据源之上进行一站式的数据查询。

图6为本公开实施例提供的另一种查询处理方法的流程图，如图6所示，与图1中所示实施例不同的是，本实施例不但包括上述实施例中的步骤S1～步骤S13,还包括：步骤S01和步骤S02，对于步骤S1～步骤S13的描述，可参见前述内容；下面仅对步骤S01和步骤S02进行详细描述。

步骤S01、元信息管理节点对用户身份信息进行有效性验证。

在步骤S01中，当用户身份信息通过有效性验证时，则执行步骤S1；当用户身份信息未通过有效性验证时，则执行步骤S02；

步骤S02、元信息管理节点向用户反馈身份信息验证失败信息。

在本实施例中，元信息管理节点可实现对用户身份进行有效性验证。

图7a为本公开实施例提供的一种查询处理系统的结构框图，图 7b～图7f分别为本公开中服务节点、协调节点、处理节点、存储节点和元信息管理节点的结构框图，如图7a～图7f所示，该查询处理系统可用于实现前述实施例中的查询处理方法，该查询处理系统包括：服务节点1、协调节点2和多个处理节点3；其中，服务节点1 包括：解析模块101、第一判断模块102、切分模块103、第一分配模块104、汇总模块105和第一反馈模块106；协调节点2包括：第一生成模块201；处理节点3包括：第一处理模块301。

解析模块101用于解析查询请求并生成相应的逻辑执行计划。

第一判断模块102用于判断逻辑执行计划属于OLAP规模查询业务或OLTP规模查询业务。

切分模块103用于当第一判断模块102判断出逻辑执行计划属于OLAP规模查询业务时，将逻辑执行计划切分为多个逻辑执行子计划，并将完成切分的逻辑执行计划发送至协调节点2。

第一生成模块201用于生成从切分模块103处接收到的逻辑执行计划对应的第一物理执行计划，并反馈至服务节点1，第一物理执行计划中记载有各逻辑执行子计划对应的处理节点3的节点信息。

第一分配模块104用于根据第一物理执行计划，将各逻辑执行子计划分配至对应的处理节点3。

第一处理模块301用于处理相应的逻辑执行子计划，得到查询子结果，并将处理子结果进行逐层上报。

汇总模块105用于对接收到的处理子结果进行汇总，生成最终查询结果。

第一反馈模块106用于将最终查询结果反馈至相应用户。

在一些实施例中，服务节点1还包括：发送模块107、第二分配模块108和第二反馈模块109；协调节点2还包括：第二生成模块202；处理节点3还包括：第二处理模块302。

发送模块107用于当第一判断模块102判断出逻辑执行计划属于OLTP规模查询业务时，将逻辑执行计划发送至协调节点2。

第二生成模块202用于生成从发送模块107处接收到的逻辑执行计划对应的第二物理执行计划，并反馈至服务节点1，第二物理执行计划中记载有逻辑执行计划对应的处理节点3的节点信息。

第二分配模块108用于根据第二物理执行计划，将逻辑执行计划分配至对应的处理节点3。

第二处理模块302用于处理相应的逻辑执行计划，得到最终查询结果，并将最终查询结果上传至服务节点1。

第二反馈模块109用于将接收到的最终查询结果反馈至相应用户。

在一些实施例中，查询处理系统还包括：存储节点4，存储节点 4包括：存储模块401，存储模块401中预先存储有各数据源的数据量信息。

图8为本公开中第一判断模块102的一种结构框图，如图8所示，第一判断模块102包括：询问单元1021、评估单元1022和比较单元1023。

其中，询问单元1021用于向存储节点4询问与逻辑执行计划相关联的各数据源的数据量。

评估单元1022用于根据存储节点4所反馈的与逻辑执行计划相关联的各数据源的数据量，评估出逻辑执行计划对应的数据查询总量。

比较单元1023用于比较数据查询总量与预定查询总量的大小。

若比较单元1023比较出数据查询总量大于预定查询总量，则第一判断模块102判断出逻辑执行计划属于OLAP规模查询业务；若比较单元1023比较出数据查询总量小于或等于预定查询总量，则第一判断模块102判断出逻辑执行计划属于OLTP规模查询业务。

图9为本公开中第一处理模块的一种结构框图，如图9所示，在一些实施例中，第一处理模块301包括：第一检测单元3011、转发单元3012和查询单元3013；查询处理系统还包括：存储节点4，存储节点4包括：构建模块402。

其中，第一检测单元3011用于检测处理节点3自身所接收到的逻辑执行子计划属于查询计划或聚合计划。

转发单元3012用于当第一检测单元3011检测出处理节点3自身所接收到的逻辑执行子计划属于查询计划时，将逻辑执行子计划转发至存储节点4，以供存储节点4构建针对逻辑执行子计划的数据库。

查询单元3013用于在存储节点4所构建的针对逻辑执行子计划的数据库中执行相应的查询操作，得到相应的查询子结果。

构建模块402用于在存储节点4接收到处理节点3所发送的逻辑执行子计划时，构建针对逻辑执行子计划的数据库。

继续参见图9所示，在一些实施例中，第一处理模块301还包括：聚合单元3014，聚合单元3014用于当第一检测单元3011检测出处理节点3自身所接收到的逻辑执行子计划属于聚合计划时，接收下属处理节点3所上报的查询子结果，并进行聚合处理。

图10为本公开中构建模块的一种结构框图，如图10所示，构建模块402包括：获取单元4021、判断单元4022和处理单元4023。

其中，获取单元4021用于根据接收到的逻辑执行子计划，获取与逻辑执行子计划相关联的数据源提供的数据表。

判断单元4022用于判断与逻辑执行子计划相关联的数据源的数量是否大于1。

处理单元4023用于当判断单元4022判断出与逻辑执行子计划相关联的数据源的数量大于1时，将与逻辑执行子计划相关联的各数据源所提供的数据表映射为关系型数据库；以及，用于当判断单元 4022判断出与逻辑执行子计划相关联的数据源的数量等于1时，将与逻辑执行子计划相关联的1个数据源所提供的数据表作为数据库。

图11为本公开中获取单元的一种结构框图，如图11所示，在一些实施例中，获取单元4021包括：第一确定子单元40211、第二确定子单元40212、判断子单元40213、第一发送子单元40214和第二发送子单元40215。

第一确定子单元40211用于确定出与逻辑执行子计划相关联的数据源。

第二确定子单元40212用于从预先存储的对应关系表中确定出与逻辑执行子计划相关联的各数据源所对应的优选处理字段，对应关系表中记载有不同数据源及其对应的优选处理字段。

判断子单元40213用于针对与逻辑执行子计划相关联的每一个数据源，判断该数据源所对应的优选处理字段是否为逻辑执行子计划所包含查询条件的查询字段。

第一发送子单元40214用于当判断子单元40213判断出该数据源所对应的优选处理字段为逻辑执行子计划所包含查询条件的查询字段时，将逻辑执行子计划内该数据源所对应的优选处理字段的查询条件发送至该数据源，以供该数据源根据接收到的查询条件对自身所存储的数据表进行筛选，然后再将完成筛选的数据表反馈至存储节点 4。

第二发送子单元40215用于当判断子单元40213判断出该数据源所对应的不为逻辑执行子计划所包含查询条件的查询字段时，向该数据源发送数据获取请求，以供该数据源反馈自身的数据表。

参见图7f，在一些实施例中，查询处理系统还包括：元信息管理节点5，元信息管理节点5包括：验证模块501和第三反馈模块502。其中，验证模块501用于对用户身份信息进行有效性验证；第三反馈模块502用于当用户身份信息未通过有效性验证时，元信息管理节点 5向用户反馈身份信息验证失败信息。

此时，解析模块101具体用于当用户身份信息通过有效性验证时，解析查询请求并生成相应的逻辑执行计划。

对于上述各模块、单元、子单元的描述，可参见前述关于查询处理方法内对各步骤的描述，此处不在赘述。

本公开实施例还提供了一种服务器，该服务器包括：一个或多个处理器以及存储装置；其中，存储装置上存储有一个或多个程序，当上述一个或多个程序被上述一个或多个处理器执行时，使得上述一个或多个处理器实现如前述实施例所提供的查询处理方法。

本公开实施例还提供了一计算机可读存储介质，其上存储有计算机程序，其中，该计算机程序被执行时实现如前述实施例所提供的查询处理方法。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块 /单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

本文已经公开了示例实施例，并且虽然采用了具体术语，但它们仅用于并仅应当被解释为一般说明性含义，并且不用于限制的目的。在一些实例中，对本领域技术人员显而易见的是，除非另外明确指出，否则可单独使用与特定实施例相结合描述的特征、特性和/或元素，或可与其他实施例相结合描述的特征、特性和/或元件组合使用。因此，本领域技术人员将理解，在不脱离由所附的权利要求阐明的本公开的范围的情况下，可进行各种形式和细节上的改变。