CN117785952A - 一种数据查询方法、装置、服务器及介质 - Google Patents

Abstract

本申请实施例公开了一种数据查询方法、装置、服务器及介质，其中方法包括：获取客户端发送的查询请求，并调用元信息存储服务从中央信息库中获取元信息；根据查询请求和元信息确定与查询请求关联的参考数据表标识，并确定与参考数据表标识关联的目标分桶；目标分桶用于存储参考数据表标识对应的参考数据表中的数据；获取查询节点与分桶之间的映射关系，基于映射关系确定目标分桶对应的目标查询节点；调用目标查询节点对目标分桶的数据进行查询，得到查询请求对应的查询结果。可以提高数据查询效率。

Description

一种数据查询方法、装置、服务器及介质

技术领域

本申请涉及数据处理技术领域，尤其涉及一种数据查询方法、装置、服务器及介质。

背景技术

随着实时数仓的概念日益火热，越来越多的企业开始进行实时数仓建设的探索；其中应用较为广泛的是基于Kafka+Flink+OLAP(on-Line Analytic Processing，联机分析处理)的链路，这种链路较好的解决了实时数仓里面的两个主要问题：通过Flink进行实时数据集成和通过OLAP引擎进行实时数据分析。OLAP引擎通常是可以让用户提取所需的数据并查询数据。其中，ClickHouse是OLAP引擎中的一个代表引擎，目前，ClickHouse在数据查询场景得到了越来越多的应用，如在趋势分析、广告预测等方面的查询辅助，因此，如何基于ClickHouse来进行数据查询成为了当前的研究热点。

发明内容

本申请实施例提供了一种数据查询方法、装置、服务器及介质，可以提高数据查询效率。

本申请实施例第一方面公开了一种数据查询方法，所述方法包括：

获取客户端发送的查询请求，并调用元信息存储服务从中央信息库中获取元信息；

根据所述查询请求和所述元信息确定与所述查询请求关联的参考数据表标识，并确定与所述参考数据表标识关联的目标分桶；所述目标分桶用于存储所述参考数据表标识对应的参考数据表中的数据；

获取查询节点与分桶之间的映射关系，基于所述映射关系确定所述目标分桶对应的目标查询节点；

调用所述目标查询节点对目标分桶的数据进行查询，得到所述查询请求对应的查询结果。

本申请实施例第二方面公开了一种数据查询装置，所述装置包括：

获取单元，用于获取客户端发送的查询请求，并调用元信息存储服务从中央信息库中获取元信息；

第一确定单元，用于根据所述查询请求和所述元信息确定与所述查询请求关联的参考数据表标识，并确定与所述参考数据表标识关联的目标分桶；所述目标分桶用于存储所述参考数据表标识对应的参考数据表中的数据；

第二确定单元，用于获取查询节点与分桶之间的映射关系，基于所述映射关系确定所述目标分桶对应的目标查询节点；

查询单元，用于调用所述目标查询节点对目标分桶的数据进行查询，得到所述查询请求对应的查询结果。

本申请实施例第三方面公开了一种服务器，包括处理器和存储器，其中，所述存储器用于存储计算机程序，所述计算机程序包括程序指令，所述处理器被配置用于调用所述程序指令，执行上述第一方面的方法。

本申请实施例第四方面公开了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时使所述处理器执行上述第一方面的方法。

本申请实施例第五方面公开了一种计算机程序产品或计算机程序，所述计算机程序产品或计算机程序包括程序指令，所述程序指令被处理器执行时实现上述第一方面的方法。

在本申请实施例中，可以获取客户端发送的查询请求，并调用元信息存储服务从中央信息库中获取元信息；然后，可以根据查询请求和元信息确定与查询请求关联的参考数据表标识，并确定与参考数据表标识关联的目标分桶；该目标分桶可以用于存储参考数据表标识对应的参考数据表中的数据；进一步的，可以获取查询节点与分桶之间的映射关系，以基于该映射关系确定目标分桶对应的目标查询节点，并调用目标查询节点对目标分桶的数据进行查询，得到查询请求对应的查询结果。通过实施上述方式，可以利用分桶来实现数据的存储，实现动态扩缩容的能力，以提升计算资源的利用率，从而提高数据查询效率。

附图说明

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

图1a是本申请实施例提供的一种数据查询系统的架构示意图；

图1b是本申请实施例提供的一种元信息服务的架构示意图；

图1c是本申请实施例提供的另一种数据查询系统的架构示意图；

图2是本申请实施例提供的一种数据查询方法的流程示意图；

图3是本申请实施例提供的另一种数据查询方法的流程示意图；

图4是本申请实施例提供的一种数据查询装置的结构示意图；

图5是本申请实施例提供的一种服务器的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

本申请实施例提出了一种数据查询方法，服务器可以获取客户端发送的查询请求，并调用元信息存储服务从中央信息库中获取元信息；然后，可以根据查询请求和元信息确定与查询请求关联的参考数据表标识，并确定与参考数据表标识关联的目标分桶；该目标分桶可以用于存储参考数据表标识对应的参考数据表中的数据；进一步的，可以获取查询节点与分桶之间的映射关系，以基于该映射关系确定目标分桶对应的目标查询节点，并调用目标查询节点对目标分桶的数据进行查询，得到查询请求对应的查询结果。可以利用分桶来实现数据的存储，实现动态扩缩容的能力，以提升计算资源的利用率，从而提高数据查询效率。

需要说明的是，本申请实施例提供的数据查询的方法具体可应用于数据查询的系统中，请参阅图1a，图1a是本申请实施例提供的一种数据查询系统的架构示意图，该数据查询系统的架构可以理解为开源ClickHouse架构的改进版本。如图1a所示，可以将数据查询系统可分为元信息服务(MetaService)模块、查询处理(Query Processing)模块以及存储(Storage)模块。

其中，元信息服务模块可以用于存储ClickHouse集群的元信息，该元信息可以包括：ClickHouse集群中存储的哪些数据表，每个数据表用于存储什么数据、每个数据表包括哪些分区、查询节点(或称为计算节点)与分桶的映射关系等等。在开源ClickHouse的设计中，元信息通常来源于磁盘的目录，通过读取目录列表可以构建对应的元信息，因此元信息通常分散在每个查询节点内部，每个查询节点均有独一无二的状态，当有查询节点发生宕机时，就可能导致整个集群不可用。为了能够提高可靠性，本申请实施例引入了中央元信息库和Metastore(元信息存储)角色，中央元信息库用于存储所有的元信息，其中，元信息可以采用DB存储或KV存储，如中央元信息库可以是Mysql，即可以通过Mysql来存储元信息。中央元信息库中的元信息可以通过Metastore服务提供给所有查询节点访问；例如，查询节点可以连接Metastore服务(如可称之为MetaService)，Metastore服务再去连接中央元信息库，以实现从中央元信息库中获取元信息。如图1b所示为元信息服务模块的具体实现框架，如图1b所示，ClickHouse节点可以调用负载均衡器(Load Balancer)来实现元信息的存储，以提高资源利用。

其中，查询处理模块可以用于执行针对查询请求的查询操作。查询处理模块中可以涉及N个虚拟仓库(Virtual Warehouse)，虚拟仓库可以是针对不同业务场景下的执行查询处理的载体单位。每一个虚拟仓库可以包括管控单元(Master)、服务单元(Server)以及查询单元(Worker)。其中，管控单元可以从元信息服务模块中拉取元信息，并将拉取的元信息发送给服务单元。服务单元可以用来实现对外服务，如可以接收客户端发送的查询请求；服务单元在接收到查询请求之后，可以调用管控单元从元信息服务模块中拉取元信息，以获取元信息；在服务单元获取到元信息之后，即可以基于该元信息和查询请求确定与查询请求相关联的数据表标识(如可称为参考数据表标识)，并进一步可以确定与参考数据表标识关联的目标分桶，在元信息中还可以获取到查询节点与分桶之间的映射关系，以基于映射关系确定目标分桶对应的目标查询节点。进一步的，服务单元可以将该查询请求下发到查询单元执行对应的查询操作，以得到查询请求对应的查询结果，如该查询单元可以调用目标查询节点对目标分桶的数据进行查询，以得到查询结果。

其中，存储模块可以用于数据的存储，可以利用分布式文件系统(FileSystem)或对象存储(ObjectStorage)进行数据的存储，如分布式文件系统可以包括HDFS(HadoopDistributed File System)、JuiceFS等，对象存储可以包括OBS(Object StorageService)、COS(Cloud Object Storag)等。在本申请实施例中，可以优先考虑使用对象存储实现数据存储。对象存储具有无限扩展、低成本、可靠性较高等特点，那么使用对象存储来进行数据存储，也可以很好地的解决各种业务场景日益增长的数据存储需求，在集群的扩展过程中也不需要有数据迁移操作。并且，利用对象存储的可靠性也可以避免使用副本机制，从而可以直接摆脱副本一致性、资源浪费、zookeeper(是一个分布式的，开放源码的分布式应用程序协调服务)稳定性等一系列问题，为Clickhouse集群中Clickhouse节点的无状态化提供了基础。在一种实现方式中，存储模块中的数据可以以桶(Bucket)的形式存储，此处的桶也就是上述提及的分桶，存储模块中的桶可以分布在各个查询节点中，分桶与查询节点之间的映射关系可以预先建立。通过利用分桶来存储数据，可以实现动态扩缩容(或称之为自动扩缩容、弹性扩缩容)，如在扩容的情况下，已有的查询节点上的分桶可以分配到新增的查询节点上，在缩容的情况下，即已有的查询节点部分不可用，则需要将其他可用的查询节点上的分桶进行重新分配。可以看出，在动态扩缩容的情况下，一般是存在分桶的重新分布，即触发数据的加载和卸载，不需要数据迁移，可以有效提高动态效率。

综上可以看出，本申请实施例中的ClickHouse采用了一种存算分离的架构，或者说提供了一种存算分离架构的OLAP引擎，即数据的存储和数据的计算(查询)是剥离开的，这样可以保证读写是分离的，如果存在大量的数据导入，不会影响数据的查询处理，也不会影响服务的可用性。应理解的是，在存算耦合的ClickHouse架构中，数据以及服务的高可用性是需要通过副本机制来保障，而副本机制需要对应的成本，在这种情况下，成本可能会进一步成倍增长；同时，在存算耦合的架构中，当想要保存更多的数据时，需要对存储进行扩容，但同步也就对进行计算资源进行扩容，这样极大的提高了成本；同时扩容也需要进行大量的数据迁移工作，极大的提升了运维、时间以及人力等成本)，同时也影响了服务的可用性。而本申请通过存算分离架构以及对象存储来进行数据存储，可以避免使用副本机制，也可以避免数据迁移操作，从而在一定程度上减少了运维、时间以及人力等成本。并且，通过利用对象存储可以保存无限历史数据以及保障数据可用性的同时，还可以配合容器(如桶)技术，实现动态扩缩容的能力，以提升资源利用率以及运维效率。

在一种实现方式中，图1c是本申请实施例提供的另一种数据查询系统的架构示意图，该数据查询系统可以理解为一个分布式引擎(Distribute Engine)，该数据查询系统可以包括客户端(Client)、服务器(Server)。客户端可以用于向服务器发送查询请求，在服务器接收到该查询请求之后，则可以响应该查询请求，并得到对应的查询结果；其中，该服务器可以利用服务合并树(ServerMergeTree)的机制来实现查询操作。具体实现中，该服务器可以调用多个查询节点来实现针对该查询请求的查询操作，并得到对应的查询结果。如图1a中所示的查询节点1(Worker1)、查询节点2(Worker2)、...、查询节点N(WorkerN)，其中，各个查询节点可以在调用查询合并树(WorkerMergeTree)的机制来实现具体的查询操作。在利用查询节点来进行查询操作时，可以实现自动扩缩容/弹性扩缩容(Auto Scale)，如若存在不可用的查询节点，则可以将不可用的查询节点对应的分桶映射到其他可用的查询节点上；又如若存在新增的查询节点，则可以将已有的查询节点上的分桶映射到这个新增的查询节点上；那么，在重新映射的过程中，即可以实现各个查询节点上计算资源的弹性扩缩容。可选的，可以优先在本地缓存(Local Cache)中查找查询请求所需要的查询结果，以提高查询速度。

其中，该客户端可以是运行在终端上的具有查询功能的客户端，如浏览器客户端、信息流客户端，等等。其中，此处所提及的终端可包括但不限于：智能手机、平板电脑、笔记本电脑、台式计算机、智能电视等。服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、大数据以及人工智能平台等基础云计算服务的云服务器，等等。其中，客户端与服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

需说明的是，本申请实施例中涉及到用户信息相关的数据均为用户授权后的数据。

请参阅图2，图2是本申请实施例提供的一种数据查询方法的流程示意图，本实施例所描述的数据查询方法可应用于上述的服务器，如图2所示，该方法可包括：

S201，获取客户端发送的查询请求，并调用元信息存储服务从中央信息库中获取元信息。

在一种实现方式中，当用户存在查询需求时，可以通过客户端发起针对该查询需求的查询请求。例如，用户可以向客户端发送一个查询请求，以使该客户端接收到该查询请求，而在客户端接收到该查询请求之后，可以将该查询请求发送给服务器，从而使得服务器可以获取到该查询请求。如用户可以通过在客户端所输出的用户操作界面执行相关操作，以向客户端发送一个查询请求。例如，用户所使用的客户端可在客户端屏幕中显示一个用户操作界面，该用户操作界面可以至少包括一个查询区域。若用户想要查询某一信息(如学生的基本信息)，则该用户可在该查询区域中输入相关信息(如学生的姓名)，从而触发用户所使用的客户端可以根据在查询区域中的相关信息生成查询请求，并将该查询请求发送给服务器。

在一种实现方式中，服务器在接收到该查询请求之后，可以进一步获取关于数据库的相关元信息(如上述提及的ClickHouse集群的元信息)，例如，该元信息可以包括数据库中包含的数据表的相关信息(如数据表的数量、每个数据表是具体存储的哪种数据、等等)，查询节点与分桶之间的映射关系，等等。在一种实现方式中，元信息可以存储在一个中央信息库中，当存在查询请求时，可以从该中央信息库中获取对应的元信息，如可以调用元信息存储服务从中央信息库中获取元信息。

S202，根据查询请求和元信息确定与查询请求关联的参考数据表标识，并确定与参考数据表标识关联的目标分桶。

其中，目标分桶可以用于存储参考数据表标识对应的参考数据表中的数据。

在一种实现方式中，查询请求中可以指定从哪些数据表中进行查询，那么，基于查询请求以及元信息可以确定该查询请求关联的数据表对应的数据表标识，如此处的数据表可成为参考数据表，数据表标识可称为参考数据表标识。在一个实施例中，参考数据表中的数据是以分桶的形式进行存储的，则在后续执行查询操作时，需要在分桶中执行查询操作，则需要进一步确定参考数据表标识关联的目标分桶。其中，对象存储中数据表与分桶之间的映射关系可以预先记录在元信息中，则在获取到元信息以及确定参考数据表标识之后，可以基于元信息中的数据表与分桶之间的映射关系确定参考数据表标识所关联的目标分桶。

在一种实现方式中，为给弹性(动态)扩缩容提供基础，即保证能够对查询节点的计算资源进行扩缩容，可以将对象存储中数据以桶(bucket)的形式进行存储，如上述的目标分桶的数据存储在对象存储中。例如，可以将数据表或分区中指定列的值为关键钥匙(key)进行哈希(hash)，并hash到指定的桶中。通常，对象存储中可以包括多个数据表，即可以包括针对多个数据表的存储，下述以一个数据表为例对分桶的构建进行说明。具体实现中，针对任一数据表，可以对任一数据表中指定类型对应的所有指定数据进行哈希计算，得到任一数据表各个指定数据的哈希值；然后，可以构建多个分桶，并将各个指定数据的哈希值分配到多个分桶中，一个分桶对应一个或多个哈希值；针对任一分桶，可以将任一分桶所分配的哈希值对应的目标数据存储在任一分桶中；其中，哈希值对应的目标数据是指哈希值对应的指定数据在任一数据表中所在行对应的所有数据。其中，哈希值可以用于确定针对查询请求的目标分桶。

举例来说，以表1所示的数据表为例对分桶操作进行相关阐述。

表1：

用户ID	姓名	年龄	性别
				111	张三	xx	xx
222	李四	xx	xx
				333	王五	xx	xx
444	赵六	xx	xx
				…	…	…	…

如参考表1所示可以将表1中的用户ID这一列指定为bucket划分的key，即可以将表1中所有的用户ID进行哈希计算，得到各个用户ID的哈希值，在得到各个用户ID的哈希值之后，可以将这些哈希值分配到预先构建的多个分桶中。其中，每个分桶对应的哈希值可以任意分配；也可以尽量保证均匀分配；也可以按照预设分配规则进行分配，如若各个分桶的数据可存储量存在区别，则可以按照存储在分桶中的数据的数据量不超过该分桶的数据可存储量存储规则来进行分配。示例性的，假设哈希值包括hash1(用户ID为111对应的哈希值)、hash2(用户ID为222对应的哈希值)、hash3(用户ID为333对应的哈希值)、hash4(用户ID为444对应的哈希值)，分桶包括桶1、桶2，则桶1可分配有hash1、hash3，桶2可分配有hash2、hash4，即表1中用户ID为111以及333这两行对应的所有数据以及可存储在桶1中，表1中用户ID为222以及444这两行对应的所有数据以及可存储在桶2中。

在一种实现方式中，上述指定类型可以预先任意设定；也可以按照预设规则来确定，如可以基于数据类型的查询(访问)频率确定指定类型。其中查询频率可以是指在某一时间段内被查询的次数，可选的，可以将查询频率较高的数据类型作为指定类型。其中，数据类型可以是指数据表的表头，如针对一个用户信息表(如上述表1)，该表1的表头包括用户ID、姓名、年龄以及性别，则针对该表1的数据类型可以是：用户ID、姓名、年龄以及性别。在具体实现中，可以统计历史时间段内，数据表中针对各种数据类型的查询次数，其中，此处的历史时间段可以是指位于目标时间之前，且与目标时间间隔预设时长(例如15天、20天等)的时间段，此处的目标时间可以是指需要利用分桶来进行数据存储的时刻。在统计到各种数据类型的查询次数之后，可以将最大查询次数对应的数据类型作为指定类型。如针对表1而言，假设通过统计确定用户ID的查询次数最大，则可以将用户ID作为key来进行哈希计算。

在一种实现方式中，在将对象存储中的数据以分桶形式进行存储时，可以将对象存储中的所有数据利用分桶来进行存储；也可以从该对象存储中筛选部分数据来利用分桶进行存储，例如，可以将对象存储中查询次数较高的数据表中的数据利用分桶进行存储。具体实现中，可以统计各个数据表在历史时间段内的查询次数，其中，此处的历史时间段可以为前述理解；然后，可以基于各个数据表的查询次数从多个数据表中选择出目标数据表，该目标数据表中的数据即是需要利用分桶进行存储的数据。例如，可以依照查询次数从大到小的顺序依次对各个数据表进行排序，并得到对应的排序结果，在得到该排序结果之后，可以将该排序结果中处于前K位的数据表作为目标数据表。其中，K可以预先设置，具体数值对此不做限定。

在一种实现方式中，如果查询请求中存在指定类型的查询条件，则可以将查询条件进行哈希计算，以得到查询条件的哈希值；在得到该查询条件的哈希值之后，可以将该查询条件的哈希值与多个分桶对应的哈希值进行匹配，并可以将匹配到的分桶作为目标分桶。另一种实现方式中，若各个分桶对应有分桶编号，在得到查询条件的哈希值之后，还可以对该哈希值进行取模(取余)运算，得到该查询请求对应的分桶编号，所得到的分桶编号对应的分桶即目标分桶。如可通过计算公式H＝hash(a)％n来确定分桶编号，其中，H表示分桶编号(如以1、2、3依次对分桶进行编号)，a表示查询条件(如查询条件可以是某一用户ID)，n表示分桶的总数量(如可以是4、6等)。示例性的，假设在某一情况下通过hash(a)％n计算得到1，则可以确定目标分桶是编号为1的分桶。

综上可以看出，当查询请求中存在指定类型的查询条件时，可以通过分桶键(如上述提及的分桶对应分桶编号或分桶对应哈希值)直接定位到查询请求对应的分桶，从而可以实现分桶的快速过滤，起到了高速检索的作为，同时也可以减少数据的读取量，以提高数据查询速度。

在一种实现方式中，本申请实施例可以优先使用查询QPS(Queries Per Second，每秒响应的查询次数)较高的存储方式来存储对象存储中数据的目录元数据，这种目标元数据的存储方式可以解决分布式文件系统的查询QPS限制。对象存储作为Key-value(KV)结构，为了模拟文件系统，一般是通过POSIX文件系统来存储对应的元数据；在实际应用场景中，考虑在使用分布式文件系统(如CFS(Cloud File Storage，云文件存储))的过程中发现并不适用于小文件高频访问的场景，因为查询QPS过高时会导致CFS宕机，影响ClickHouse集群的正常运作。基于此可知，为了解决如小文件高频访问的场景的访问限制，可以引入查询QPS较高的存储方式或者说高速的Key-value查询系统来存储目录元数据，以提高数据查询的稳定性和可靠性。

S203，获取查询节点与分桶之间的映射关系，基于映射关系确定目标分桶对应的目标查询节点。

在一种实现方式中，查询节点与分桶之间的映射关系可以预先设定，如可以以随机分配、一致性哈希等方式将分桶分配到查询节点上。示例性的，以随机分配方式来说，假设查询节点包括节点1和节点2，分桶包括桶1、桶2、桶3、桶4；查询节点与分桶之间的映射关系可以是节点1对应桶1和桶2，节点2对应桶3和桶4，也可以是节点1对应桶1，节点2对应桶2、桶3以及桶4。在查询节点的数量与分桶的数量足够多的情况下，可以尽量使得分桶可以均匀的分配到各个查询节点上，即每一个查询节点可以对应有相同数量的分桶。其中，每一个查询节点所对应的具体分桶可以不做限制。如一个查询节点可以对应有桶1和桶2，也可以是对应有桶3和桶4。

在一种实现方式，还可以基于查询节点的计算资源和分桶中数据的数据量来确定查询节点与分桶之间的映射关系。具体实现中，可以获取各个查询节点的计算资源，并获取各个分桶中数据的数据量，依照查询节点的计算资源以及分桶对应的数据量来确定查询节点与分桶之间的映射关系。例如，可以将计算资源较大的查询节点匹配数据量较大的分桶，将计算资源较小的查询节点匹配数据量较小的分桶，以保证查询节点有足够的计算资源来处理分桶中的数据，以保证数据的查询速度。

综上可以看出，通过将数据按bucket划分，可以在调度过程中以bucket为单位，灵活调度查询节点和bucket的映射关系，从而为弹性扩缩容提供基础。例如，在某一个或多个查询节点不可用时(如出现网络故障等情况)，或者新增一个或多个查询节点时，可以将各个查询节点上分桶重新进行分配，即一个查询节点上的分桶可以发生变化，在分桶发生变化时，各个查询节点的计算资源也在变化，即计算资源在扩缩容。通常，OLAP引擎的使用有明显的波峰浪谷特性，如白天使用量多，夜间使用量少，如果利用原有的ClickHouse架构，可能会导致夜间的计算资源浪费，而通过本申请中的在ClickHouse框架中引入了分桶机制，且调度查询节点和bucket的映射关系的灵活性，可以将多余的计算资源调度给其他数据处理，以避免资源的浪费。

在查询节点分配调度的过程，如果数据过于分散，在做聚合、多表join(联合)的过程查询性能会非常低，并经常会伴随机器OOM(out of memory，内存不足)、计算倾斜等问题。而在ClickHouse框架中引入了分桶机制，除了在单点查询时通过分桶键进行快速过滤，起到高速索引的作用，并减少数据读取量的同时，通过分桶机制也可以优化聚合、多表join查询性能，避免数据shuffle，如在需要利用对多个数据表执行查询操作时，不需要对多个数据表进行联合并进行全局查询，只需要对与查询请求关联的分桶中的数据进行联合并查询，可以有效的减小数据读取量，从而提高数据查询速度。示例性的，针对一查询请求，假设该查询请求需要从表1和表2中查找用户ID为111的用户信息。其中，表1可以为上述所示，表2可参见下表：

表2：

用户ID	姓名	班级	成绩
				111	张三	xx	xx
222	李四	xx	xx
				333	王五	xx	xx
444	赵六	xx	xx
				…	…	…	…

假设表1中用户ID为111的用户信息存储在桶1中，表2中用户ID为111的用户信息存储在桶2中，则在进行数据查询时，只需要对桶1和桶2中的数据进行联合，以查询用户ID为111的所有用户信息，而不需要直接对表1和表2进行联合，来查询用户ID为111的所有用户信息。可以看出，相比于针对多表联合而言，利用分桶可以有效减少数据读取量，从而提高数据查询速度。

S204，调用目标查询节点对目标分桶的数据进行查询，得到查询请求对应的查询结果。

在一种实现方式中，服务器可以调用目标查询节点对目标分桶的数据执行具体的查询，并将查询所得到的查询结果返回给客户端。

在本申请实施例中，服务器可以获取客户端发送的查询请求，并调用元信息存储服务从中央信息库中获取元信息；根据查询请求和元信息确定与查询请求关联的参考数据表标识，并确定与参考数据表标识关联的目标分桶；目标分桶用于存储参考数据表标识对应的参考数据表中的数据；获取查询节点与分桶之间的映射关系，基于映射关系确定目标分桶对应的目标查询节点；调用目标查询节点对目标分桶的数据进行查询，得到查询请求对应的查询结果。通过实施上述方法，可以利用对象存储保存无限历史数据以及保障数据可用性，还可以通过引入桶(bucket)的设计概念，即利用分桶来实现对象存储中数据的存储，以实现动态扩缩容的能力，以提升资源利用率以及运维效率。

请参阅图3，图3是本申请实施例提供的另一种数据查询方法的流程示意图，本实施例所描述的数据查询方法可应用于上述的服务器，如图3所示，该方法可包括：

S301，获取客户端发送的查询请求，并调用元信息存储服务从中央信息库中获取元信息。

S302，根据查询请求和元信息确定与查询请求关联的参考数据表标识，并确定与参考数据表标识关联的目标分桶。

S303，获取查询节点与分桶之间的映射关系，基于映射关系确定目标分桶对应的目标查询节点。

其中，步骤S301-S303的具体实施方式可以参见上述步骤S201-S203的具体实施方式，在此处不再赘述。

S304，在缓存中调用目标查询节点对目标分桶的数据进行查询。

在一种实现方式中，可以将对象存储中的部分数据存储在缓存中，以便于可以从缓存中查找查询请求对应的数据，从而可以提高数据查询速度。例如，可以将本地磁盘作为对象存储的缓存(或者称为缓存盘)。在ClickHouse集群启动后，可以先将部分数据从对象存储缓存到本地磁盘，那么，在执行用户的查询操作(也就是获取到查询请求)时，可以先直接从本地磁盘读取数据以查询所需要的数据，如果可以在本地磁盘中查询到对应的数据，则这种方式下的查询性能与直接将数据存储在本地磁盘是相同的，因为均是从本地磁盘直接进行查询的。相比于直接从对象存储中查找数据，从缓存中查询数据可以提高查询速度，从而可以提高查询效率。

在一个实施例中，对象存储中进行缓存的数据可以是基于用户预先设定的规则所确定的；如该规则可以涉及到两种缓存方式：主动缓存方式和被动缓存方式。其中，主动缓存方式可以适用于可预知会被频繁访问的数据，即可以预先将这些数据从对象存储中转移到缓存中存储，在这种缓存方式下，可以基于数据的数据特征从对象存储中筛选出需进行缓存的数据，为方便描述，可以将需进行缓存的数据称之为待缓存数据；被动缓存方式可以适用于不可预知的数据，在这种缓存方式下，可以在接收到客户端发送的查询请求之后，将查询请求相关联的数据作为待缓存数据，以进行临时缓存。下述对主动缓存方式和被动缓存方式进行具体说明。

(1)针对主动缓存方式，前述可知，可以是将频繁访问的数据预先进行缓存。在具体实现中，可以先确定对象存储中所包括的各个数据的数据特征；该数据特征可以包括访问频率、存储时长中的一种或多种，数据特征还可以包括其他数据特征，本申请实施例主要以访问频率和存储时长进行相关说明；在确定数据的数据特征之后，进一步可以基于各个数据的数据特征确定对象存储中的待缓存数据，并将该待缓存数据从对象存储中转移到缓存中进行缓存。其中，访问频率可以是指在历史时间段内被访问的次数，所谓的历史时间段是指位于当前时间之前，且与当前时间间隔预设时长(例如3天、7天等)的时间段，此处的当前时间可以是指获取到查询请求的时刻。存储时长可以是指当前时间与最近的一次被查询对应的时间之间的时长。

其中，由于数据的数据特征的不同，从对象存储中确定待缓存数据的实现方式也存在区别，下述以数据特征包括访问频率、存储时长中的一种或多种为例对确定待缓存数据的实现方式进行相关说明。

可选的，在数据特征为访问频率的情况下，可以先确定对象存储中各个数据的访问频率，以根据访问频率来筛选出待缓存数据。在一个实施例中，可以将各个数据的访问频率与预设访问频率进行比较，如果某一数据的访问频率超过该预设访问频率，则可以将该数据作为待缓存数据，如果某一数据的访问频率未超过该预设访问频率，则可以不将该数据作为待缓存数据。在另一个实施例中，可以依照访问频率从大到小的顺序对各个数据排序，得到针对数据的排序结果；然后，将该排序结果中处于前N位的数据作为待缓存数据。

可选的，在数据特征为存储时长的情况下，可以先确定对象存储中各个数据的存储时长，以根据存储时长来筛选出待缓存数据。在一个实施例中，可以将各个数据的存储时长与预设存储时长进行比较，如果某一数据的存储时长未超过该预设存储时长，则可以将该数据作为待缓存数据，如果某一数据的存储时长超过该预设存储时长，则可以不将该数据作为待缓存数据。在另一个实施例中，可以依照存储时长从小到大的顺序对各个数据排序，得到针对数据的排序结果；然后，将该排序结果中处于前N位的数据作为待缓存数据。

可选的，在数据特征为访问频率和存储时长的情况下，可以先确定对象存储中各个数据的访问频率和存储时长，以根据访问频率和存储时长来筛选出待缓存数据。在一个实施例中，可以先将各个数据的访问频率与预设访问频率进行比较，并将访问频率超过该预设访问频率的数据作为初始数据；然后，可以将初始数据的存储时长与预设存储时长进行比较，并将存储时长不超过该预设存储时长的数据作为待缓存数据。在另一个实施例中，可以先依照访问频率从大到小的顺序对各个数据排序，得到针对数据的排序结果；然后，将该排序结果中处于前M位的数据作为初始数据；接着，依照存储时长从小到大的顺序对各个初始数据排序，得到针对初始数据的排序结果；最后，将该排序结果中处于前N位的初始数据作为待缓存数据。需说明的是，除了上述描述的按照访问频率、存储时长的顺序来从数据中筛选出待缓存数据，也可以按照存储时长、访问频率的顺序来从数据中筛选出待缓存数据，具体实现与上述方式类似，此处不再赘述。

其中，上述的预设访问频率、预设存储时长、M值、N值可以预先设置，具体的数值对此不做限定。

(2)针对被动缓存方式，前述可知，是将查询请求相关联的数据进行临时缓存。具体实现中，可以将与参考数据表关联的目标分桶对应的数据从对象存储中转移到缓存中进行缓存，即可以将目标分桶对应的数据作为待缓存数据。在这种情况下，步骤S304的具体实现可以是调用目标查询节点对缓存中的目标分桶的数据进行查询，考虑到是直接将查询请求相关的数据进行缓存，则在缓存中可以直接得到查询请求对应的查询结果。

S305，若未得到查询请求对应的查询结果，则在对象存储中调用目标查询节点对目标分桶的数据进行查询，得到查询请求对应的查询结果。

综上可知，在获取到查询请求之后，可以优先从缓存中进行查询操作，在缓存中查询不到查询请求的数据的情况下，再进一步从对象存储中进行查询操作，通过上述查询操作，可以看出，可以解决数据从对象存储中拉取的性能限制问题，可以为部分高频数据的查询需求提供高性能保障，也就是可以提高查询速度。

在本申请实施例中，服务器可以获取客户端发送的查询请求，并调用元信息存储服务从中央信息库中获取元信息；然后，可以根据查询请求和元信息确定与查询请求关联的参考数据表标识，并确定与参考数据表标识关联的目标分桶；该目标分桶可以用于存储参考数据表标识对应的参考数据表中的数据；然后，可以获取查询节点与分桶之间的映射关系，以基于该映射关系确定目标分桶对应的目标查询节点，进一步，可以在缓存中调用目标查询节点对目标分桶的数据进行查询；若未得到查询请求对应的查询结果，则在对象存储中调用目标查询节点对目标分桶的数据进行查询，得到查询请求对应的查询结果。通过实施上述方法，可以通过引入桶(bucket)的设计概念，即利用分桶来实现对象存储中数据的存储，可以实现动态扩缩容的能力，以提升资源利用率以及运维效率；并且，基于缓存机制，可以解决数据从对象存储拉取的性能限制问题，为部分高频查询需求提供了较高的性能保障，即可以提高数据查询速度。

请参阅图4，是本申请实施例提供的一种数据查询装置的结构示意图。本实施例中所描述的数据查询装置，包括：

获取单元401，用于获取客户端发送的查询请求，并调用元信息存储服务从中央信息库中获取元信息；

第一确定单元402，用于根据所述查询请求和所述元信息确定与所述查询请求关联的参考数据表标识，并确定与所述参考数据表标识关联的目标分桶；所述目标分桶用于存储所述参考数据表标识对应的参考数据表中的数据；

第二确定单元403，用于获取查询节点与分桶之间的映射关系，基于所述映射关系确定所述目标分桶对应的目标查询节点；

查询单元404，用于调用所述目标查询节点对目标分桶的数据进行查询，得到所述查询请求对应的查询结果。

在一种实现方式中，所述目标分桶的数据存储在对象存储中，所述对象存储中包括多个数据表；所述装置还包括存储单元405，所述存储单元405，具体用于：

针对任一数据表，对所述任一数据表中指定类型对应的所有指定数据进行哈希计算，得到所述任一数据表各个指定数据的哈希值；

构建多个分桶，将各个指定数据的哈希值分配到所述多个分桶中，一个分桶对应一个或多个哈希值；

针对任一分桶，将所述任一分桶所分配的哈希值对应的目标数据存储在所述任一分桶中；所述哈希值对应的目标数据是指所述哈希值对应的指定数据在所述任一数据表中所在行对应的所有数据，所述哈希值用于确定目标分桶。

在一种实现方式中，所述第一确定单元402，具体用于：

若所述查询请求中存在所述指定类型的查询条件，则将所述查询条件进行哈希计算，得到所述查询条件的哈希值；

将所述查询条件的哈希值与所述多个分桶对应的哈希值进行匹配，将匹配到的分桶作为目标分桶。

在一种实现方式中，所述查询单元404，具体用于：

在缓存中调用所述目标查询节点对目标分桶的数据进行查询；

若未得到所述查询请求对应的查询结果，则在对象存储中调用所述目标查询节点对目标分桶的数据进行查询，得到所述查询请求对应的查询结果。

在一种实现方式中，所述存储单元405，还用于：

将与所述参考数据表标识关联的目标分桶对应的数据从所述对象存储中转移到缓存中进行缓存；

其中，所述查询单元404，具体用于：

调用所述目标查询节点对所述缓存中的目标分桶的数据进行查询，得到所述查询请求对应的查询结果。

在一种实现方式中，所述存储单元405，还用于：

确定所述对象存储中所包括的各个数据的数据特征；所述数据特征包括访问频率、存储时长中的一种或多种；

基于所述各个数据的数据特征确定所述对象存储中的待缓存数据，并将所述待缓存数据从所述对象存储中转移到缓存中进行缓存。

在一种实现方式中，所述数据特征包括访问频率和所述存储时长；所述存储单元405，具体用于：

将所述各个数据的访问频率与预设访问频率进行比较，并将访问频率超过所述预设访问频率对应的数据作为初始数据；

将所述初始数据的存储时长与预设存储时长进行比较，并将存储时长未超过所述预设存储时长的初始数据作为待缓存数据。

可以理解，本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。本申请实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

请参阅图5，图5是本申请实施例提供的一种服务器的结构示意图。服务器包括：处理器501、存储器502。可选的，该服务器还可包括网络接口503。上述处理器501、存储器502以及网络接口503之间可以交互数据。

上述处理器501可以是中央处理单元(Central Processing Unit，CPU)，该处理器还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

上述存储器502可以包括只读存储器和随机存取存储器，并向处理器501提供程序指令和数据。存储器502的一部分还可以包括非易失性随机存取存储器。其中，所述处理器501调用所述程序指令时用于执行：

在一种实现方式中，所述目标分桶的数据存储在对象存储中，所述对象存储中包括多个数据表；所述处理器501，还用于：

针对任一数据表，对所述任一数据表中指定类型对应的所有指定数据进行哈希计算，得到所述任一数据表各个指定数据的哈希值；

构建多个分桶，将各个指定数据的哈希值分配到所述多个分桶中，一个分桶对应一个或多个哈希值；

针对任一分桶，将所述任一分桶所分配的哈希值对应的待缓存数据存储在所述任一分桶中；所述哈希值对应的待缓存数据是指所述哈希值对应的指定数据在所述任一数据表中所在行对应的所有数据，所述哈希值用于确定目标分桶。

在一种实现方式中，所述处理器501，具体用于：

若所述查询请求中存在所述指定类型的查询条件，则将所述查询条件进行哈希计算，得到所述查询条件的哈希值；

将所述查询条件的哈希值与所述多个分桶对应的哈希值进行匹配，将匹配到的分桶作为目标分桶。

在一种实现方式中，所述处理器501，具体用于：

在缓存中调用所述目标查询节点对目标分桶的数据进行查询；

若未得到所述查询请求对应的查询结果，则在对象存储中调用所述目标查询节点对目标分桶的数据进行查询，得到所述查询请求对应的查询结果。

在一种实现方式中，所述处理器501，还用于：

将与所述参考数据表标识关联的目标分桶对应的数据从所述对象存储中转移到缓存中进行缓存；

其中，所述处理器501，具体用于：

调用所述目标查询节点对所述缓存中的目标分桶的数据进行查询，得到所述查询请求对应的查询结果。

在一种实现方式中，所述处理器501，还用于：

确定所述对象存储中所包括的各个数据的数据特征；所述数据特征包括访问频率、存储时长中的一种或多种；

基于所述各个数据的数据特征确定所述对象存储中的待缓存数据，并将所述待缓存数据从所述对象存储中转移到缓存中进行缓存。

在一种实现方式中，所述数据特征包括访问频率和所述存储时长；所述处理器501，具体用于：

将所述各个数据的访问频率与预设访问频率进行比较，并将访问频率超过所述预设访问频率对应的数据作为初始数据；

将所述初始数据的存储时长与预设存储时长进行比较，并将存储时长未超过所述预设存储时长的初始数据作为待缓存数据。

本申请实施例还提供了一种计算机存储介质，该计算机存储介质中存储有程序指令，所述程序执行时可包括如图2或者图3对应实施例中的数据查询方法的部分或全部步骤。

需要说明的是，对于前述的各个方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某一些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器(Read-Only Memory，ROM)、随机存取器(Random AccessMemory，RAM)、磁盘或光盘等。

本申请实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括程序指令，程序指令被处理器执行时可实现上述方法中的部分或全部步骤。例如，该程序指令存储在计算机可读存储介质中。服务器的处理器从计算机可读存储介质读取该程序指令，处理器执行该程序指令，使得该服务器执行上述各方法的实施例中所执行的步骤。

以上对本申请实施例所提供的一种数据查询方法、装置、服务器及介质进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种数据查询方法，其特征在于，所述方法包括：

获取客户端发送的查询请求，并调用元信息存储服务从中央信息库中获取元信息；

根据所述查询请求和所述元信息确定与所述查询请求关联的参考数据表标识，并确定与所述参考数据表标识关联的目标分桶；所述目标分桶用于存储所述参考数据表标识对应的参考数据表中的数据；

获取查询节点与分桶之间的映射关系，基于所述映射关系确定所述目标分桶对应的目标查询节点；

调用所述目标查询节点对目标分桶的数据进行查询，得到所述查询请求对应的查询结果。

2.根据权利要求1所述的方法，其特征在于，所述目标分桶的数据存储在对象存储中，所述对象存储中包括多个数据表；还包括：

针对任一数据表，对所述任一数据表中指定类型对应的所有指定数据进行哈希计算，得到所述任一数据表各个指定数据的哈希值；

构建多个分桶，将各个指定数据的哈希值分配到所述多个分桶中，一个分桶对应一个或多个哈希值；

针对任一分桶，将所述任一分桶所分配的哈希值对应的目标数据存储在所述任一分桶中；所述哈希值对应的目标数据是指所述哈希值对应的指定数据在所述任一数据表中所在行对应的所有数据，所述哈希值用于确定目标分桶。

3.根据权利要求2所述的方法，其特征在于，所述确定所述参考数据表标识所关联的目标分桶，包括：

若所述查询请求中存在所述指定类型的查询条件，则将所述查询条件进行哈希计算，得到所述查询条件的哈希值；

将所述查询条件的哈希值与所述多个分桶对应的哈希值进行匹配，将匹配到的分桶作为目标分桶。

4.根据权利要求1所述的方法，其特征在于，所述调用所述目标查询节点对目标分桶的数据进行查询，得到所述查询请求对应的查询结果，包括：

在缓存中调用所述目标查询节点对目标分桶的数据进行查询；

若未得到所述查询请求对应的查询结果，则在对象存储中调用所述目标查询节点对目标分桶的数据进行查询，得到所述查询请求对应的查询结果。

5.根据权利要求4所述的方法，其特征在于，还包括：

将与所述参考数据表标识关联的目标分桶对应的数据从所述对象存储中转移到缓存中进行缓存；

其中，所述调用所述目标查询节点对目标分桶的数据进行查询，得到所述查询请求对应的查询结果，包括：

调用所述目标查询节点对所述缓存中的目标分桶的数据进行查询，得到所述查询请求对应的查询结果。

6.根据权利要求4所述的方法，其特征在于，还包括：

确定所述对象存储中所包括的各个数据的数据特征；所述数据特征包括访问频率、存储时长中的一种或多种；

基于所述各个数据的数据特征确定所述对象存储中的待缓存数据，并将所述待缓存数据从所述对象存储中转移到缓存中进行缓存。

7.根据权利要求6所述的方法，其特征在于，所述数据特征包括访问频率和所述存储时长；所述基于所述各个数据的数据特征确定所述对象存储中的待缓存数据，包括：

将所述各个数据的访问频率与预设访问频率进行比较，并将访问频率超过所述预设访问频率对应的数据作为初始数据；

将所述初始数据的存储时长与预设存储时长进行比较，并将存储时长未超过所述预设存储时长的初始数据作为待缓存数据。

8.一种数据查询装置，其特征在于，包括：

获取单元，用于获取客户端发送的查询请求，并调用元信息存储服务从中央信息库中获取元信息；

第一确定单元，用于根据所述查询请求和所述元信息确定与所述查询请求关联的参考数据表标识，并确定与所述参考数据表标识关联的目标分桶；所述目标分桶用于存储所述参考数据表标识对应的参考数据表中的数据；

第二确定单元，用于获取查询节点与分桶之间的映射关系，基于所述映射关系确定所述目标分桶对应的目标查询节点；

查询单元，用于调用所述目标查询节点对目标分桶的数据进行查询，得到所述查询请求对应的查询结果。

9.一种服务器，其特征在于，包括处理器和存储器，其中，所述存储器用于存储计算机程序，所述计算机程序包括程序指令，所述处理器被配置用于调用所述程序指令，执行如权利要求1-7任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时使所述处理器执行如权利要求1-7任一项所述的方法。