CN113032430B - 一种数据处理方法、装置、介质和计算设备 - Google Patents

一种数据处理方法、装置、介质和计算设备 Download PDF

Info

Publication number
CN113032430B
CN113032430B CN202110321215.3A CN202110321215A CN113032430B CN 113032430 B CN113032430 B CN 113032430B CN 202110321215 A CN202110321215 A CN 202110321215A CN 113032430 B CN113032430 B CN 113032430B
Authority
CN
China
Prior art keywords
query
target
historical
request
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202110321215.3A
Other languages
English (en)
Other versions
CN113032430A (zh
Inventor
余利华
汪源
蒋鸿翔
温正湖
汪胜
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hangzhou Netease Shuzhifan Technology Co ltd
Original Assignee
Hangzhou Netease Shuzhifan Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hangzhou Netease Shuzhifan Technology Co ltd filed Critical Hangzhou Netease Shuzhifan Technology Co ltd
Priority to CN202110321215.3A priority Critical patent/CN113032430B/zh
Publication of CN113032430A publication Critical patent/CN113032430A/zh
Application granted granted Critical
Publication of CN113032430B publication Critical patent/CN113032430B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2453—Query optimisation
    • G06F16/24534—Query rewriting; Transformation
    • G06F16/24539—Query rewriting; Transformation using cached or materialised query results
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/242—Query formulation
    • G06F16/2433—Query languages
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24552—Database cache management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24553—Query execution of query operations
    • G06F16/24554—Unary operations; Data partitioning operations
    • G06F16/24556—Aggregation; Duplicate elimination
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G06F16/2462—Approximate or statistical queries
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Computational Linguistics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Mathematical Physics (AREA)
  • Fuzzy Systems (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本公开提供一种数据处理方法、装置、介质和计算设备，该方法包括：根据历史查询数据确定K个目标查询对象，K为正整数；预先确定所述K个目标查询对象中每个目标查询对象对应的查询结果，并基于所述K个目标查询对象中每个目标查询对象对应的查询结果构建M个缓存表，M为大于等于1且小于等于K的整数；在接收到针对所述K个目标查询对象中的目标查询对象的查询请求时，更改所述查询请求的查询路径；其中，更改后的所述查询路径指向所述目标查询对象对应的缓存表；基于更改后的所述查询路径获取所述目标查询对象的查询结果。

Description

一种数据处理方法、装置、介质和计算设备
技术领域
本公开涉及数据处理领域，更具体地，本公开涉及一种数据处理方法、装置、介质和计算设备。
背景技术
本部分旨在为权利要求书中陈述的本公开的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。
当前社会已经进入信息化、数字化时代，其明显的特征是单位时间产生的数据量越来越多，数据规模越来越大。线上集群一般包括多个节点，用户终端可以通过用于访问数据库的应用程序接口连接到某个节点，该节点根据用户终端提交的结构化查询语言(Structured Query Language，SQL)语句执行查询操作，在查询完成之后该节点会返回查询结果。如果线上集群同时存在大量的SQL语句，将导致线上集群负载很高，进而影响查询性能，降低用户使用体验。
发明内容
本公开提供了一种数据处理方法、装置、介质和计算设备，至少能提高查询性能。
本公开实施例的第一方面提供一种数据处理方法，包括：根据历史查询数据确定K个目标查询对象，K为正整数；预先确定所述K个目标查询对象中每个目标查询对象对应的查询结果，并基于所述K个目标查询对象中每个目标查询对象对应的查询结果构建M个缓存表，M为大于等于1且小于等于K的整数；在接收到针对所述K个目标查询对象中的目标查询对象的查询请求时，更改所述查询请求的查询路径；其中，更改后的所述查询路径指向所述目标查询对象对应的缓存表；基于更改后的所述查询路径获取所述目标查询对象的查询结果。
在本公开的一个实施例中，所述方法还包括：将所述M个缓存表集中式存储至第一预设数据库中，所述第一预设数据库是具有持久化存储功能的数据库。
在本公开的一个实施例中，所述根据历史查询数据确定K个目标查询对象，包括：根据所述历史查询数据统计第一预设时间范围内各个第一类查询对象的查询频率或查询次数；从所述第一预设时间范围内所述查询频率大于第一阈值或所述查询次数大于第二阈值的所述第一类查询对象中确定K个目标查询对象。
在本公开的一个实施例中，所述根据历史查询数据确定K个目标查询对象，包括：根据所述历史查询数据统计第二预设时间范围内各个第二类查询对象的使用频率或使用次数；从所述第二预设时间范围内所述使用频率大于第三阈值或所述使用次数大于第四阈值的所述第二类查询对象中确定K个目标查询对象。
在本公开的一个实施例中，所述预先确定所述K个目标查询对象中每个目标查询对象对应的查询结果，并基于所述K个目标查询对象中每个目标查询对象对应的查询结果构建M个缓存表，包括：获取所述K个目标查询对象中每个目标查询对象的查询数据源；基于所述K个目标查询对象中每个目标查询对象的查询数据源，预先确定所述K个目标查询对象中每个目标查询对象对应的查询结果；以缓存表的形式存储每个所述目标查询对象与其对应的查询结果之间的对应关系。
在本公开的一个实施例中，所述更改所述查询请求的查询路径，包括：基于所述查询请求确定所述查询路径指向的初始表；在确定存在与所述初始表对应的所述缓存表，且所述查询请求的查询类型为预设查询类型的情况下，更改所述查询请求的查询路径。
在本公开的一个实施例中，所述预设查询类型至少包括：聚合函数场景下的查询类型；去重函数场景下的查询类型。
在本公开的一个实施例中，所述方法还包括：在接收到针对非目标查询对象的查询请求时，根据所述非目标查询对象的查询请求所指示的查询路径，确定所述非目标查询对象的查询结果。
在本公开的一个实施例中，所述方法还包括：获取集群中N个节点上的查询记录，N为大于1的整数；基于所述N个节点中每个节点上的查询记录，得到历史查询数据；将所述历史查询数据存储到第二预设数据库。
在本公开的一个实施例中，所述方法还包括：接收所述历史查询数据的获取请求；基于所述获取请求输出所述历史查询数据；其中，所述历史查询数据包括下述数据中的一种或几种：每个历史查询请求的查询节点标识，每个历史查询请求的查询提交时间，每个历史查询请求的查询执行时间，每个历史查询请求的用户信息。
在本公开的一个实施例中，所述方法还包括：根据第三预设时间范围内的历史查询数据，统计所述第三预设时间范围内的各个历史查询请求的执行情况；利用可视化工具表示所述第三预设时间范围内的各个历史查询请求的执行情况。
在本公开的一个实施例中，所述方法应用于Impala集群。
本公开实施例的第二方面提供一种数据处理装置，包括：确定单元，用于根据历史查询数据确定K个目标查询对象，K为正整数；构建单元，用于预先确定所述K个目标查询对象中每个目标查询对象对应的查询结果，并基于所述K个目标查询对象中每个目标查询对象对应的查询结果构建M个缓存表，M为大于等于1且小于等于K的整数；更改单元，用于在接收到针对所述K个目标查询对象中的目标查询对象的查询请求时，更改所述查询请求的查询路径；其中，更改后的所述查询路径指向所述目标查询对象对应的缓存表；获取单元，用于基于更改后的所述查询路径获取所述目标查询对象的查询结果。
在本公开的一个实施例中，所述装置还包括：存储单元，用于将M个缓存表集中式存储至第一预设数据库中，所述第一预设数据库是具有持久化存储功能的数据库。
在本公开的一个实施例中，所述确定单元，用于：根据所述历史查询数据统计第一预设时间范围内各个第一类查询对象的查询频率或查询次数；从所述第一预设时间范围内所述查询频率大于第一阈值或所述查询次数大于第二阈值的所述第一类查询对象确定K个目标查询对象。
在本公开的一个实施例中，所述确定单元，用于：根据所述历史查询数据统计第二预设时间范围内各个第二类查询对象的使用频率或使用次数；从所述第二预设时间范围内所述使用频率大于第三阈值或所述使用次数大于第四阈值的所述第二类查询对象中确定K个目标查询对象。
在本公开的一个实施例中，所述构建单元，用于：获取所述K个目标查询对象中每个目标查询对象的查询数据源；基于所述K个目标查询对象中每个目标查询对象的查询数据源，预先确定所述K个目标查询对象中每个目标查询对象对应的查询结果；以缓存表的形式存储每个所述目标查询对象与其对应的查询结果之间的对应关系。
在本公开的一个实施例中，所述更改单元，用于：基于所述查询请求确定所述查询路径指向的初始表；在确定存在与所述初始表对应的所述缓存表，且所述查询请求的查询类型为预设查询类型的情况下，确定更改所述查询请求的查询路径。
在本公开的一个实施例中，所述预设查询类型至少包括：聚合函数场景下的查询类型；去重函数场景下的查询类型。
在本公开的一个实施例中，所述装置还包括：控制单元，用于在接收到针对非目标查询对象的查询请求时，根据所述非目标查询对象的查询请求所指示的查询路径，确定所述非目标查询对象的查询结果。
在本公开的一个实施例中，所述装置还包括：收集单元，用于获取集群中N个节点上的查询记录，N为大于1的整数；基于所述N个节点中每个节点上的查询记录，得到历史查询数据；将所述历史查询数据存储到第二预设数据库。
在本公开的一个实施例中，所述装置还包括：查询单元，用于接收历史查询数据的获取请求；基于所述获取请求输出所述历史查询数据；所述历史查询数据包括下述数据中的一种或几种：每个历史查询请求的查询节点标识，每个历史查询请求的查询提交时间，每个历史查询请求的查询执行时间，每个历史查询请求的用户信息。
在本公开的一个实施例中，所述装置还包括：统计单元，用于根据第三预设时间范围内的历史查询数据，统计所述第三预设时间范围内的各个历史查询请求的执行情况；输出单元，用于利用可视化工具表示所述预设时间范围内的各个历史查询请求的执行情况。
在本公开的一个实施例中，所述装置应用于Impala集群。
本公开实施例的第三方面提供一种介质，其存储有计算机程序，该程序被处理器执行时实现如前述实施例的方法。
本公开实施例的第四方面提供一种计算设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序；当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如前述实施例的方法。
根据本公开实施方式，根据历史查询数据确定K个目标查询对象，预先确定所述K个目标查询对象中每个目标查询对象对应的查询结果，并基于所述K个目标查询对象中每个目标查询对象对应的查询结果构建M个缓存表，在接收到针对所述K个目标查询对象中的目标查询对象的查询请求时，更改所述查询请求的查询路径，基于更改后的所述查询路径获取所述目标查询对象的查询结果。如此，通过预先确定每个目标查询对象的查询结果，并将每个目标查询对象对应的查询结果存储到缓存表，在接收到针对目标查询对象的查询请求时，无需执行繁琐的获取原始数据以及计算查询结果的步骤，只需更改查询请求的查询路径，即可基于更改后的查询路径快速从对应缓存表中获取目标查询对象的查询结果，提高了查询速度，提升了查询性能，由于节省了用户终端的等待时间，从而有助于提高用户的使用体验。
附图说明
通过参考附图阅读下文的详细描述，本公开示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本公开的若干实施方式，其中：
图1为根据本公开一实施方式的数据处理方法流程图一；
图2为根据本公开一实施方式的数据处理方法流程图二；
图3为根据本公开一实施方式的数据处理方法流程图三；
图4为根据本公开一实施方式的数据处理方法流程图四；
图5为根据本公开一实施方式的数据处理方法流程图五；
图6为根据本公开一实施方式的数据处理方法流程图六；
图7为根据本公开一实施方式的数据处理系统的架构示意图；
图8为根据本公开一实施方式的管理系统模块与Impala集群的交互示意图；
图9为根据本公开一实施方式的在Impala节点中插入SQL重写模块的示意图；
图10为根据本公开一实施方式的介质示意图；
图11为根据本公开一实施方式的数据处理装置组成结构示意图一；
图12为根据本公开一实施方式的数据处理装置组成结构示意图二；
图13为根据本公开一实施方式的计算设备结构示意图；
在附图中，相同或对应的标号表示相同或对应的部分。
具体实施方式
下面将参考若干示例性实施方式来描述本公开的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本公开，而并非以任何方式限制本公开的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。
本领域技术人员知道，本公开的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。
根据本公开的实施方式，提出了一种数据处理方法、装置、介质和计算设备。
在本文中，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。
下面参考本公开的若干代表性实施方式，详细阐释本公开的原理和精神。
发明概述
本申请人发现，随着大数据技术的不断发展，出现了多种数据仓库查询引擎如联机分析处理(OnLine Analytical Processing，OLAP)引擎。Impala是Apache Hadoop生态中一款重要的OLAP查询引擎，采用大规模并行处理(Massively Parallel Processing，MPP)框架，以性能优秀著称，广泛应用在商务智能(Business Intelligence，BI)类数据产品和交互式查询场景。一般来说，线上集群会存在多个Impala节点，比如包括几十个节点，或者上百个节点，甚至包括更多的节点。用户终端可以通过Java数据库连接接口(JavaDatabase Connectivity，简称JDBC)连接到线上集群的任意一个Impala节点，然后提交SQL语句，Impala节点完成查询之后，会返回查询结果。对于社区版本的Impala节点来说，当某个节点接收到用户终端提交的SQL语句时，SQL执行的相关信息就会保存在这个节点的内存中，本申请人发现，可以在这个节点的管理页面上看到所有提交到这个节点上的查询信息。通过这个节点的管理页面，可以看到这个节点上有哪些SQL执行过、提交时间、持续时间以及提交用户等信息，也可以通过Impala节点提供的SQL的执行树状图查看某个SQL的详细信息。通过Impala节点提供的这些查询信息，可以对SQL的执行过程进行分析和诊断，也可以排查SQL执行慢的原因，为运维提供一些参考信息。
本申请人发现，首先，用户终端通过JDBC连接到线上集群的任意一个Impala节点，然后提交SQL。由于线上集群的节点较多，如果业务的某个SQL执行出现了问题或者执行很慢，需要排查原因，最直接的方法是通过管理页面查看整个SQL的执行概况，从而分析是哪里出了问题。由于无法直接知道这个SQL提交到哪个节点上，因此需要去每个节点上进行查找，非常麻烦，对运维工作有一定的影响。其次，由于这些SQL都是存储在内存中的，所以一旦节点崩溃或者重启，那么提交到这个节点上的SQL记录会被释放掉，我们无法再从管理页面上看到这些SQL的执行信息。最后，即使服务没有崩溃或重启，由于SQL记录是存储在内存中的，所以一般我们都会配置一个固定的数量，保存最新的若干条SQL，例如保存最新的2048条记录。一旦提交到节点上的SQL超过这个阈值，那么之前的SQL记录则会自动从内存中清除。内存资源通常是很宝贵的，因此存储在节点上的历史查询数量是非常有限的。
本申请人还发现，Impala虽然是MPP架构，查询性能好，但是由于当前数据量越来越大，在部分场景下，也存在着一定的性能问题。尤其是某些查询，一天反复查询多次，如果每次都重新提交，那么Impala节点需要进行重新计算，这样是非常消耗资源的。
这里我们举一个例子，例如：
order_id country sales
1001 China 1000
1002 US 1000
假设我们当前有一张表t1，这个表包含三列：订单号(order_id)、国家(country)以及销售额(sales)。如果想知道这个表中包含了哪些国家，可以通过下面的SQL语句进行查询：
SELECT country FROM t1 GROUP BY country
通过这个SQL，我们可以获取表t1中包含了哪些国家。但是，如果表中的数据非常大，例如有上百亿、千亿的数据，那么查询将比较耗时。Impala节点需要扫描所有的表中数据，然后进行计算，最终算出有多少个国家。我们知道，全世界国家的数量大约有200个左右。如果我们先计算出来结果，再将结果缓存，当用户终端实际进行查询时，直接查询缓存的结果即可，查询性能将大大提升。同理，如果要计算在每个国家的销售额，可以通过下面的SQL语句进行查询：
SELECT country,SUM(sales)FROM t1 GROUP BY country
同样，我们可以将销售额的结果缓存下来，当实际查询时，直接查询缓存的结果即可，这对提升查询性能也是非常有帮助的。
基于上述发现，本申请人对Impala社区版目前存在的历史查询数据不能集中、持久化保存，以及部分场景下查询性能低下的问题，归纳如下：
历史查询数据分散地保存在Impala集群的各个节点的内存中，当需要定位到具体SQL时，工作量大，并且容易因为节点崩溃或重启等丢失历史查询信息，这对分析和运维工作都造成了一定程度的影响，也不利于进行查询优化；
部分场景下的查询性能低下，如果Impala集群同时存在大量的SQL语句，会导致集群负载很高，进而影响到其他查询的正常执行。
有鉴于此，本公开提供一种数据处理方法、装置、介质和计算设备，该数据处理方法包括：根据历史查询数据确定K个目标查询对象，K为正整数；预先确定所述K个目标查询对象中每个目标查询对象对应的查询结果，并基于所述K个目标查询对象中每个目标查询对象对应的查询结果构建M个缓存表，M为大于等于1且小于等于K的整数；在接收到针对所述K个目标查询对象中的目标查询对象的查询请求时，更改查询请求的查询路径；其中，更改后的查询路径指向目标查询对象对应的缓存表；基于更改后的查询路径获取目标查询对象的查询结果。
如此，通过预先确定每个目标查询对象的查询结果，并将每个目标查询对象的查询结果存储到缓存表中，在接收到针对目标查询对象的查询请求时，无需执行繁琐的获取原始数据以及计算查询结果等步骤，只需更改查询请求的查询路径，即可基于更改后的查询路径快速从对应缓存表中获取目标查询对象的查询结果，提高了查询速度，提升了查询性能，由于节省了用户终端侧的等待时间，从而也有助于提高用户的使用体验。
在介绍了本公开的基本原理之后，下面具体介绍本公开的各种非限制性实施方式。
示例性方法
本公开提供了一种数据处理方法，如图1所示，包括：
S101：根据历史查询数据确定K个目标查询对象，K为正整数；
S102：预先确定所述K个目标查询对象中每个目标查询对象对应的查询结果，并基于所述K个目标查询对象中每个目标查询对象对应的查询结果构建M个缓存表，M为大于等于1且小于等于K的整数；
S103：在接收到针对所述K个目标查询对象中的目标查询对象的查询请求时，更改所述查询请求的查询路径；其中，更改后的所述查询路径指向所述目标查询对象对应的缓存表；
S104：基于更改后的所述查询路径获取所述目标查询对象的查询结果。
本实施例可以应用于电子设备，该电子设备包括但不限于固定设备和/或移动设备，例如，固定设备包括但不限于服务器，比如云服务器、普通服务器等服务器。例如，移动设备包括但不限于终端设备，比如智能手机、平板电脑等终端设备。
在S101中，所述历史查询数据可以是电子设备如服务器记录的一段时间内的查询数据。这里，所述一段时间对应的时间阈值可以根据实际情况如用户需求进行设定或调整，如一周、或一个月、或一季度、或一年等。这里，查询数据是指用户终端发送的预查询的数据内容，示例性地，数据内容包括但不限于销售额、主要销往地区、销量同比等内容。比如，数据内容为商品A的销售额。又比如，数据内容为商品A的主要出口国家。再比如，数据内容为商品A在同类商品中的销售占比。实际处理中数据内容可以包含更多的情况，本实施例不做穷举。
在S101中，所述目标查询对象使用频率或查询频率大于一定阈值的对象。比如，目标查询对象为商品出口国家的数量。又比如，目标查询对象为商品销往某个国家如英国的销量。再比如，目标查询对象为商品在某个地区的销售额。这里，对目标查询对象不做穷举。其中，所述一定阈值可以根据实际情况如设计需求进行设定或调整。示例性地，一定阈值＝10000，或20000，或100000等，可以理解，上述10000、20000和100000都是示意性的，这里不做穷举。
在S102中，所述目标查询对象的查询结果是指针对所述目标查询对象向用户终端返回的结果。示例性的，“查询结果”是指具体的统计值，比如，商品A的主要出口国家数＝200个。又比如，商品A的年销量＝10万件。再比如，商品A在2020年第一季度的销售额＝2亿。
在S103中，缓存表存储的是查询结果，也即"经过运算后的值"。具体地，缓存表存储的是对第一对象(即"目标查询对象")进行处理后得到的第二对象(即目标查询对象的查询结果)。比如，缓存表存储有对各个表中的商品A的销往国家进行处理后得到的销往国家总数。又比如，缓存表存储有对各个表中的商品A的销量进行处理后得到的销量总和。再比如，缓存表存储有对各个表中的商品A的销售额进行处理后得到的销售额总和。这里，对缓存表存储的具体内容不做穷举。
在S103中，一般来说，同一目标查询对象的查询结果只有一个。多个目标查询对象分别对应的查询结果，可存储在同一个缓存表中。即，同一个缓存表可存储多个目标查询对象分别对应的查询结果。示例性地，缓存表1存储有目标查询对象1的查询结果1，目标查询对象2的查询结果2，目标查询对象3的查询结果3，…，目标查询对象m的查询结果m。如此，在接收到针对目标查询对象m的查询请求时，更改目标查询对象m的查询请求的查询路径，使更改后的查询路径指向目标查询对象m所在缓存表1，从缓存表1中获取目标查询对象m的查询结果，提高了查询速度。
根据本实施例所述方法，通过预先确定每个目标查询对象的查询结果，并在缓存表中存储每个目标查询对象对应的查询结果，在接收到针对目标查询对象的查询请求时，无需执行繁琐的获取原始数据以及计算查询结果等步骤，只需更改查询请求的查询路径，即可基于更改后的查询路径快速从对应缓存表中获取目标查询对象的查询结果，提高了查询速度，提升了查询性能，由于节省了用户终端侧的等待时间，从而有助于提高用户的使用体验。
基于图1所示数据处理方法，在一些实施例中，如图2所示，所述方法还可以包括：
S105：将所述M个缓存表集中式存储至第一预设数据库中，所述第一预设数据库是具有持久化存储功能的数据库。
示例性地，所述第一预设数据库是具有持久化存储功能的数据库。比如，所述第一预设数据库可以是MySQL数据库。
通过上述实施方式，将缓存表集中式存储至具有持久化存储功能的第一预设数据库中，相对于将历史查询数据分散地保存在各个Impala节点的内存的存储方式而言，解决了历史查询数据不能集中且持久化保存的问题；避免了因节点崩溃或重启或超阈值等原因导致的SQL记录丢失或被释放，降低因SQL记录丢失或被释放带来的对查询分析、优化、运维的影响。同时，由于预先将缓存表集中式存储至具有持久化存储功能的第一预设数据库中，能够便于后续快速获取目标查询对象的查询结果，为快速向用户终端返回查询结果提供数据支撑。
基于图1所示数据处理方法，在一些实施例中，根据历史查询数据确定K个目标查询对象，包括：根据所述历史查询数据统计第一预设时间范围内各个第一类查询对象的查询频率或查询次数；从所述第一预设时间范围内所述查询频率大于第一阈值或所述查询次数大于第二阈值的所述第一类查询对象中确定K个目标查询对象。
其中，第一类查询对象是用户输入的查询对象。
其中，第一预设时间范围可以根据实际情况如最近访问量进行设定或调整。示例性地，第一预设时间范围为最近一周，或最近一个月，或最近一季度，或最近一年内。
其中，第一阈值或第二阈值可以根据实际情况如最近访问量进行设定或调整。示例性地，第一阈值为X1，第二阈值为X2，那么，从第一预设时间范围内查询频率大于X1的第一类查询对象中确定K个目标查询对象；或者从第一预设时间范围内查询次数大于X2的第一类查询对象中确定K个目标查询对象。
其中，从第一预设时间范围内查询频率大于X1的第一类查询对象中确定K个目标查询对象，包括：在第一预设时间范围内查询频率大于X1的第一类查询对象的数量P大于或等于K的情况下，从P个第一类查询对象中选择出查询频率排名前K的第一类查询对象作为目标查询对象，或者从P个第一类查询对象中随机选择出K个第一类查询对象作为目标查询对象。
其中，从第一预设时间范围内查询次数大于X2的第一类查询对象中确定K个目标查询对象，包括：在第一预设时间范围内查询次数大于X2的第一类查询对象的数量Q大于或等于K的情况下，从Q个第一类查询对象中选择出查询次数排名前K的第一类查询对象作为目标查询对象，或者从Q个第一类查询对象中随机选择出K个第一类查询对象作为目标查询对象。
可以理解，上述K的值可以根据P的值或Q的值进行调整。比如，K的值小于或等于P的值或Q的值。
通过上述实施方式，能够结合历史查询数据筛选出更符合查询实际情况如查询热度的K个目标查询对象，进而为后续预先确定查询结果提供数据支撑。
基于图1所示数据处理方法，在一些实施例中，根据历史查询数据确定K个目标查询对象，包括：根据所述历史查询数据统计第二预设时间范围内各个第二类查询对象的使用频率或使用次数；从所述第二预设时间范围内所述使用频率大于第三阈值或所述使用次数大于第四阈值的所述第二类查询对象中确定K个目标查询对象。
其中，第二类查询对象是节点计算查询结果时使用的数据。示例性地，第二类查询对象为计算时所需要用到的中间变量。比如，第二类查询对象为商品A的同类商品在第一季度的销售总量，在计算商品A在第一季度的销售占比时将用到商品A的同类商品在第一季度的销售总量。又比如，第二类查询对象为世界上国家的数量，在计算商品A在全世界的遍布区域时将用到世界上国家的数量。再比如，第二类查询对象为商品A全年的销售额，在计算商品A的10月份销售额占全年销售额的占比时将用到商品A全年的销售额。
其中，第二预设时间范围可以根据实际情况如最近计算量进行设定或调整。示例性地，第二预设时间范围为最近一周，或最近一个月，或最近一季度，或最近一年内。
其中，第三阈值或第四阈值可以根据实际情况如最近访问量进行设定或调整。示例性地，第三阈值为X3，第四阈值为X4，那么，从第二预设时间范围内查询频率大于X3的第二类查询对象中确定K个目标查询对象；或者从第二预设时间范围内查询次数大于X4的第二类查询对象中确定K个目标查询对象。
其中，从第二预设时间范围内查询频率大于X3的第二类查询对象中确定K个目标查询对象，包括：在第二预设时间范围内查询频率大于X3的第二类查询对象的数量R大于或等于K的情况下，从R个第二类查询对象选择出查询频率排名前K的第二类查询对象作为目标查询对象，或者从R个第二类查询对象随机选择出K个第二类查询对象作为目标查询对象。
其中，从第二预设时间范围内查询次数大于X4的第二类查询对象中确定K个目标查询对象，包括：在第二预设时间范围内查询次数大于X4的第二类查询对象的数量S大于或等于K的情况下，从S个第二类查询对象中选择出查询次数排名前K的第二类查询对象作为目标查询对象，或者从S个第二类查询对象中随机选择出K个第二类查询对象作为目标查询对象。
可以理解，上述K的值可以根据R的值或S的值进行调整。比如，K的值小于或等于R的值或S的值。
通过上述实施方式，能够结合历史查询数据以及计算查询结果时所使用的数据，筛选出更符合查询实际情况如中间变量数据的K个目标查询对象，进而为后续预先确定查询结果提供数据支撑。
基于图1所示数据处理方法，在一些实施例中，预先确定所述K个目标查询对象中每个目标查询对象对应的查询结果，并基于所述K个目标查询对象中每个目标查询对象对应的查询结果构建M个缓存表，包括：获取所述K个目标查询对象中每个目标查询对象的查询数据源；基于所述K个目标查询对象中每个目标查询对象的查询数据源，预先确定所述K个目标查询对象中每个目标查询对象对应的查询结果；以缓存表的形式存储每个所述目标查询对象与其对应的查询结果之间的对应关系。
其中，查询数据源包括计算目标查询对象的查询结果时所需用到的数据。进一步地，查询数据源还可包括计算目标查询对象的查询结果时所需用到的数据的存储路径。
需要说明的是，预先确定的起始时间或截止时间，可以根据实际情况进行设定，比如，预先确定的截止时间记为第一时间，即在第一时间完成预先确定，那么，执行预先确定的时间在第一时间之前开始执行。又比如，预先确定的开始时间记为第二时间，即在第二时间开始执行预先确定，那么，在一段时间后才能完成预先确定。
示例性地，第一时间为每天凌晨1:00，或每天凌晨0:30。
示例性地，第二时间为每天凌晨0:30，或每天凌晨0:01。
可以理解，上述第一时间和第二时间的值都是示意性的，这里不做穷举。
在一些实施方式中，以缓存表的形式存储每个所述目标查询对象与其对应的查询结果之间的对应关系，包括：在一个缓存表中存储K个目标查询对象与其对应的查询结果之间的对应关系。
也就是说，将K个目标查询对象与其对应的查询结果之间的对应关系存储到同一个缓存表中。如此，便于后续快速更改查询路径，提高查询速度。
在一些实施方式中，以缓存表的形式存储每个所述目标查询对象与其对应的查询结果之间的对应关系，包括：将K个目标查询对象与其对应的查询结果之间的对应关系分散存储至M个缓存表，M为大于等于1且小于等于K的整数。
如此，便于后续不断增加目标查询对象，提高目标查询对象的容纳量。
通过上述实施方式，预先确定所述K个目标查询对象中每个目标查询对象对应的查询结果，并基于所述K个目标查询对象中每个目标查询对象对应的查询结果构建M个缓存表，能够为实现快速查询提供数据支撑。
基于图1所示数据处理方法，在一些实施例中，更改所述查询请求的查询路径，包括：基于所述查询请求确定所述查询路径指向的初始表；在确定存在与所述初始表对应的所述缓存表，且所述查询请求的查询类型为预设查询类型的情况下，更改所述查询请求的查询路径。
其中，初始表是在更改查询路径之前，查询请求指向的表。
其中，基于查询请求确定所述查询路径指向的初始表，包括：将查询请求对应的查询语句所指向的表确定为初始表。
示例性地，初始表记为t1，初始表的缓存表记为t1_cache，那么，更改查询请求的查询路径时，将t1修改为t1_cache。
其中，所述预设查询类型至少包括：聚合函数场景下的查询类型；去重函数场景下的查询类型。
其中，在SQL中，可以使用聚合函数快速实现数据的聚合分析。聚合函数是对列中的一系列数据进行处理，返回单个统计值。示例性地，聚合函数包括：用于表征返回选取结果集中所有值的总和的SUM()函数，用于表征返回选取结果集中所有值的最大值的MAX()，用于表征返回选取结果集中所有值的最小值的MIN()函数，用于表征返回选取结果集中所有值的平均值的AVG()函数，用于表征返回选取结果集中行的数目的COUNT()函数。
其中，在SQL中，可以使用去重函数计算非重复结果的数目。示例性地，去重函数包括用于返回唯一不同的值的DISTINCT()函数。
通过上述实施方式，由于缓存表中存储有目标查询对象与查询结果的对应关系，通过将查询路径指向缓存表，不再执行原有的查询路径，直接从缓存表中获取目标查询对象的查询结果，能够大大提升查询速度。
基于图1所示数据处理方法，在一些实施例中，如图3所示，所述方法还包括：
S106：在接收到针对非目标查询对象的查询请求时，根据所述非目标查询对象的查询请求所指示的查询路径，确定所述非目标查询对象的查询结果。
其中，非目标查询对象是除目标查询对象之外的查询对象。
通过上述实施方式，在接收到针对非目标查询对象的查询请求时，不改变非目标查询对象的查询请求的查询路径，能够保证非目标查询对象的查询请求的顺利执行，保证非目标查询对象的查询请求不受目标查询对象的影响。
基于图1所示数据处理方法，在一些实施例中，如图4所示，所述方法还包括：
S107：获取集群中N个节点上的查询记录，N为大于1的整数；
S108：基于所述N个节点中每个节点上的查询记录，得到历史查询数据；将所述历史查询数据存储到第二预设数据库。
本实施例，不对N的数值进行强制性限定。N可以等于集群包括的节点的总数，还可以是小于集群包括的节点的总数。
其中，第二预设数据库与第一预设数据库可以相同，也可以不同。
通过上述实施方式，通过将历史查询数据做集中处理，不仅有助于后续快速获取历史查询数据，还便于统计分析以及发现适宜优化查询的场景以及各场景下适宜优化查询的目标查询对象；另外，还能避免因节点崩溃或重启等原因丢失历史查询信息而影响优化查询、分析和运维等工作。基于图1所示数据处理方法，在一些实施例中，如图5所示，所述方法还包括：
S109：接收所述历史查询数据的获取请求；
S110：基于所述获取请求输出所述历史查询数据；
其中，所述历史查询数据包括下述数据中的一种或几种：每个历史查询请求的查询节点标识，每个历史查询请求的查询提交时间，每个历史查询请求的查询执行时间，每个历史查询请求的用户信息。
可以理解，上述所列举的数据仅是节点记录的历史查询数据的一部分，这里不做穷举。
通过上述实施方式，能够根据需求从第二预设数据库顺利获取所需的历史查询数据。
基于图1所示数据处理方法，在一些实施例中，如图6所示，所述方法还包括：
S111：根据第三预设时间范围内的历史查询数据，统计所述第三预设时间范围内的各个历史查询请求的执行情况；
S112：利用可视化工具表示所述第三预设时间范围内的各个历史查询请求的执行情况。
其中，第三预设时间范围可以根据实际情况如统计范围进行设定或调整。示例性地，第三预设时间范围为最近两周，或最近两个月，或最近一季度，或最近一年内。
本实施例不对可视化工具进行限定。比如，可视化工具可以是网易的有数产品。
利用可视化工具展示各个历史查询请求的执行情况，比如，展示按编辑状态计数的统计信息，按查询状态计数的统计信息，按照网易有数API类型计数的统计信息，按查询触发类型计数的统计信息，每小时查询数、查询成功数及失败数，进而可以很清楚地了解到，某一天中，历史查询的成功/失败数量、每个小时的查询成功/失败数量等信息。
通过上述实施方式，利用可视化工具表示第三预设时间范围内的各个历史查询请求的执行情况，为后续分析、维护工作提供有效的数据支撑。
上述数据处理方法可应用于需要提升查询性能的集群，如Impala集群。
图7示出了数据处理系统的架构示意图，如图7所示，数据处理系统包括管理系统模块、缓存表生成模块、SQL重写模块。其中，管理系统模块主要负责对历史查询数据的集中、持久化存储；缓存表生成模块主要负责缓存表的构造和定期更新；SQL重写模块主要负责对用户终端提交的查询请求按照一定规则进行重写。下面分别对三个模块进行详细介绍。
管理系统模块，是基于社区版本的Impala集群所单独开发的一个模块。管理系统模块与Impala集群主要包括的模块的交互示意图如图8所示，管理系统模块与集群中的Impala节点进行通信，获取保存在各个节点上的查询，然后将各个节点上的查询收集起来，存储到数据库中。这样，可以随时在管理系统模块上查看历史的查询数据，并进行分析和优化工作。
举例来说，通过收集到的历史查询数据，借助可视化工具如网易有数产品，则可以了解整个集群的执行概况，根据收集到的历史查询信息，构建相应地图表，通过图表可以很清楚地了解到，某一天中，历史查询的成功/失败数量、每个小时的查询成功/失败数量等信息。除此之外，还可以通过排序，很方便地了解到集群中查询最慢的前G个SQL，G为大于或等于1的整数，比较清楚地了解整个集群的SQL执行情况，什么时间段提交的SQL比较多、哪些SQL执行的比较慢，从而有助于针对性地采取优化措施。
管理系统模块提供了一个统一的入口，可以基于某一段时间内的历史查询数据，分析当前业务的线上查询使用情况。比如查询位于哪个节点、执行时间、提交用户等信息。由于我们已经将历史查询数据保存到数据库，即使Impala节点进行了重启，历史查询数据也不会丢失，从而不会影响关于查询的分析和优化工作。
缓存表生成模块，主要负责根据管理系统模块收集到的历史查询数据进行分析，然后构造相应的缓存表，并定期对缓存表进行更新。
举例来说，“SELECT country,SUM(sales)FROM t1 GROUP BY country”这个SQL，表示求取当前t1表中各个国家的(country)的销售额(sales)总和。可以基于这个SQL来构造一个缓存表：
CREATE TABLE t1_cache(country STRING,sum_sales BIGINT)STORED ASPARQUET；
基于用户终端提交的查询构造了新的缓存表t1_cache，保持国家这一列不变，仍然是country。对于销售额，我们计算了求和，所以我们用sum_sales代替了原来的sales，如果需要计算平均值，我们可以增加avg_sales；如果需要计算最大值，可以计算max_sales等。接着，我们通过“INSERT OVERWRITE t1_cache SELECT country,SUM(sales)AS sum_sales FROM t1 GROUP BY country”这个SQL进行定期的更新操作，如此，通过缓存表生成模块，每天定期执行上述SQL，就能知晓最新的销售额数据。
SQL重写模块，主要负责根据缓存表生成模块生成的缓存表和相关重写规则，对用户终端提交的查询请求进行重写。
其中，重写规则包括在查询请求的查询类型为预设查询类型的情况下，对查询请求的查询路径进行重写；其中，进行重写包括：更改所述查询请求的查询路径。其中，预设查询类型至少包括：聚合函数场景下的查询类型；去重函数场景下的查询类型。
发明人在研发过程中，经过大量统计、分析、实验等工作后发现，分组或者DISTINCT场景和聚合函数场景，尤其适应于重写，若对分组或者DISTINCT场景和聚合函数场景下的查询请求进行重写，能够大大提升查询性能。
具体地，SQL重写模块基于所述查询请求确定所述查询路径指向的初始表；在确定存在与所述初始表对应的所述缓存表，且所述查询请求的查询类型为预设查询类型的情况下，更改所述查询请求的查询路径；否则，不更改所述查询请求的查询路径。
1、针对分组或者DISTINCT场景下的重写规则
在这种场景下，如果SQL中出现了分组或者DISTINCT的操作，并且存在对应的缓存表的情况下，将进行重写，具体将查询路径指向的初始表更改为该初始表对应的缓存表。
举例来说，“SELECT DISTINCT country FROM t1”这个SQL的含义是求t1表中出现了哪些国家(country)。当用户将SQL提交到了Impala节点之后，Impala节点进行判断：如果存在t1表对应的缓存表t1_cache，且缓存表t1_cache保存了国家(country)的数据，则将该SQL重写为：
SELECT DISTINCT country FROM t1_cache。
2、针对聚合函数场景下的重写规则
在这种场景下，如果SQL中出现了聚合函数，例如SUM(求和)、AVG(取平均值)、MAX(取最大值)等，并且存在对应的缓存表的情况下，将会进行重写，具体将查询路径指向的初始表更改为该初始表对应的缓存表。举例来说，“SELECT country,SUM(sales)FROM t1GROUP BY country”这个SQL的含义是求取每个国家的销售额。当用户将SQL提交到了Impala节点之后，Impala节点会进行判断：如果存在t1表对应的缓存表t1_cache，缓存表t1_cache保存了country的数据，并且对销售额(sales)进行了求和(SUM)的计算，则将该SQL重写为：
SELECT country,SUM(sum_sales)FROM t1_cache GROUP BY country。
可以理解，重写规则适应的场景不限于上述列举的场景，还可包括其他场景。
由于按照重写规则进行重写后，查询的是缓存表而不是原始表，由于缓存表会比原始表小很多，因此可以加快响应速度，大大提升查询性能，从而提升用户体验。
SQL重写模块可以是内嵌在Impala节点中的一个模块，如图9所示，在Impala节点中插入一个"SQL重写模块"，其余模块都是Impala本身的代码处理逻辑。将社区版本的流程分为三个阶段：SQL第一阶段(SQL Parse)、SQL第二阶段(SQL Analyze)和SQL第三阶段(SQLExecute)。当Impala节点完成了SQL Parse之后，会进行缓存重写，重写完成之后，再继续Impala本身的后续流程。这里，选择在SQL Parse之后进行重写，主要存在两个原因：1)在SQL Parse之后，SQL会被解析为相应的数据结构，便于进行缓存匹配和改写；2)在SQLAnalyze阶段，会进行一些具体的分析和加载操作，在此之后再进行SQL重写就比较麻烦和复杂。因此，出于代码开发复杂度和代码入侵性的考虑，申请人选择了在SQL Parse之后和SQL Analyze之前插入SQL重写模块，不仅有助于提升数据查询的安全性，还能使Impala节点分别针对目标查询对象和非目标查询对象进行不同的处理，对目标查询对象的查询请求进行重写，对非目标查询对象的查询请求不进行重写，既保证了目标查询对象的快速查询，又保证了非目标查询对象的稳定查询。
上述数据处理系统的架构提供了基于历史查询数据进行SQL缓存重写的优化方案，该优化方案通过对历史查询进行集中的持久化存储，然后构造缓存表，最后对SQL进行缓存重写，解决了Impala集群存在的历史查询数据不能集中、持久化保存，以及部分场景下查询性能低下等问题。
应理解，图9所示的在Impala节点中插入SQL重写模块为一种可选的具体实现方式，本领域技术人员可以基于图9的例子进行各种显而易见的变化和/或替换，得到的技术方案仍属于本公开实施例的公开范围。
示例性介质
在介绍了本公开示例性实施方式的方法之后，接下来，参考图10对本公开示例性实施方式的介质进行说明。
在一些可能的实施方式中，本公开的各个方面还可以实现为一种计算机可读介质，其上存储有程序，当程序被处理器执行时用于实现本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的数据处理方法中的步骤。
具体地，上述处理器执行上述程序时用于实现如下步骤：根据历史查询数据确定K个目标查询对象，K为正整数；预先确定所述K个目标查询对象中每个目标查询对象对应的查询结果，并基于所述K个目标查询对象中每个目标查询对象对应的查询结果构建M个缓存表，M为大于等于1且小于等于K的整数；在接收到针对所述K个目标查询对象中的目标查询对象的查询请求时，更改所述查询请求的查询路径；其中，更改后的所述查询路径指向所述目标查询对象对应的缓存表；基于更改后的所述查询路径获取所述目标查询对象的查询结果。
需要说明的是：上述的介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是但不限于：电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(Random Access Memory，RAM)、只读存储器(Read-Only Memory，ROM)、可擦式可编程只读存储器(Erasable Programmable Read-OnlyMemory，EPROM)或闪存、光纤、便携式紧凑盘只读存储器(Compact Disc Read-OnlyMemory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。
如图10所示，描述了根据本公开的实施方式的介质1000，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序，并可以在设备上运行。然而，本公开不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于：电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，上述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络—包括局域网(Local Area Network，LAN)或广域网(Wide Area Network，WAN)—连接到用户计算设备。
示例性装置
在介绍了本公开示例性实施方式的方法之后，接下来，对本公开示例性实施方式的装置进行说明。
本公开实施例提供的一种数据处理装置如图11所示，该数据处理装置包括：确定单元1101，用于根据历史查询数据确定K个目标查询对象，K为正整数；构建单元1102，用于预先确定所述K个目标查询对象中每个目标查询对象对应的查询结果，并基于所述K个目标查询对象中每个目标查询对象对应的查询结果构建M个缓存表，M为大于等于1且小于等于K的整数；更改单元1103，用于在接收到针对所述K个目标查询对象中的目标查询对象的查询请求时，更改所述查询请求的查询路径；其中，更改后的所述查询路径指向所述目标查询对象对应的缓存表；获取单元1104，用于基于更改后的所述查询路径获取所述目标查询对象的查询结果。
在本公开的一个实施例中，如图12所示，所述装置还可包括：存储单元1105，用于将所述M个缓存表集中式存储至第一预设数据库中，所述第一预设数据库是具有持久化存储功能的数据库。
在本公开的一个实施例中，所述确定单元1101，用于：根据所述历史查询数据统计第一预设时间范围内各个第一类查询对象的查询频率或查询次数；从所述第一预设时间范围内所述查询频率大于第一阈值或所述查询次数大于第二阈值的所述第一类查询对象确定K个目标查询对象。
在本公开的一个实施例中，所述确定单元1101，用于：根据所述历史查询数据统计第二预设时间范围内各个第二类查询对象的使用频率或使用次数；从所述第二预设时间范围内所述使用频率大于第三阈值或所述使用次数大于第四阈值的所述第二类查询对象中确定K个目标查询对象。
在本公开的一个实施例中，所述构建单元1102，用于：获取所述K个目标查询对象中每个目标查询对象的查询数据源；基于所述K个目标查询对象中每个目标查询对象的查询数据源，预先确定所述K个目标查询对象中每个目标查询对象对应的查询结果；以缓存表的形式存储每个所述目标查询对象与其对应的查询结果之间的对应关系。
在本公开的一个实施例中，所述更改单元1103，用于：基于所述查询请求确定所述查询路径指向的初始表；在确定存在与所述初始表对应的所述缓存表，且所述查询请求的查询类型为预设查询类型的情况下，确定更改所述查询请求的查询路径。
在本公开的一个实施例中，所述预设查询类型至少包括：聚合函数场景下的查询类型；去重函数场景下的查询类型。
在本公开的一个实施例中，如图12所示，所述装置还可包括控制单元1106，用于：在接收到针对非目标查询对象的查询请求时，根据所述非目标查询对象的查询请求所指示的查询路径，确定所述非目标查询对象的查询结果。
在本公开的一个实施例中如图12所示，所述装置还可包括收集单元1107，用于：获取集群中N个节点上的查询记录，N为大于1的整数；基于所述N个节点中每个节点上的查询记录，得到所述历史查询数据；将所述历史查询数据存储到第二预设数据库。
在本公开的一个实施例中，如图12所示，所述装置还可包括查询单元1108，用于：接收所述历史查询数据的获取请求；基于所述获取请求输出所述历史查询数据；其中，所述历史查询数据包括下述数据中的一种或几种：每个历史查询请求的查询节点标识，每个历史查询请求的查询提交时间，每个历史查询请求的查询执行时间，每个历史查询请求的用户信息。
在本公开的一个实施例中，如图12所示，所述装置还可包括：统计单元1109，用于根据第三预设时间范围内的历史查询数据，统计所述第三预设时间范围内的各个历史查询请求的执行情况；输出单元1110，用于利用可视化工具表示所述预设时间范围内的各个历史查询请求的执行情况。
本公开数据处理装置可应用于需要提升查询性能的集群，如Impala集群。
本公开数据处理装置中各模块的功能可以参见上述方法中的对应描述，在此不再赘述。
本公开所述的数据处理装置，能够预先确定每个目标查询对象的查询结果，并在缓存表中存储每个目标查询对象对应的查询结果，在接收到针对目标查询对象的查询请求时，无需执行繁琐的获取原始数据以及计算查询结果等步骤，只需更改查询请求的查询路径，即可基于更改后的查询路径快速从对应缓存表中获取目标查询对象的查询结果，提高了查询速度，提升了查询性能，由于节省了用户终端侧的等待时间，从而也有助于提高用户的使用体验。
示例性计算设备
在介绍了本公开示例性实施方式的方法、介质和装置之后，接下来，参考图13对本公开示例性实施方式的计算设备进行说明。
所属技术领域的技术人员能够理解，本公开的各个方面可以实现为系统、方法或程序产品。因此，本公开的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。
在一些可能的实施方式中，根据本公开实施方式的计算设备可以至少包括至少一个处理单元以及至少一个存储单元。其中，存储单元存储有程序代码，当程序代码被处理单元执行时，使得处理单元执行本说明书上述“示例性方法”部分中描述的根据本公开的各种示例性实施方式的数据处理方法中的步骤。
下面参照图13来描述根据本公开的这种实施方式的计算设备1300。图13显示的计算设备1300仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。
如图13所示，计算设备1300以通用计算设备的形式表现。计算设备1300的组件可以包括但不限于：上述至少一个处理单元1301、上述至少一个存储单元1302，连接不同系统组件(包括处理单元1301和存储单元1302)的总线1303。
总线1303包括数据总线、控制总线和地址总线。
存储单元1302可以包括易失性存储器形式的可读介质，例如随机存取存储器(RAM)13021和/或高速缓存存储器13022，可以进一步包括非易失性存储器形式的可读介质，例如只读存储器(ROM)13023。
存储单元1302还可以包括具有一组(至少一个)程序模块13024的程序/实用工具13025，这样的程序模块13024包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。
计算设备1300也可以与一个或多个外部设备1304(例如键盘、指向设备等)通信。这种通信可以通过输入/输出(Input/Output，I/O)接口1305进行。并且，计算设备1300还可以通过网络适配器1306与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图13所示，网络适配器1306通过总线1303与计算设备1300的其它模块通信。应当理解，尽管图13中未示出，可以结合计算设备1300使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、独立磁盘冗余阵列(RedundantArray of Independent Disks，RAID)系统、磁带驱动器以及数据备份存储系统等。
应当注意，尽管在上文详细描述中提及了数据处理装置的若干单元/模块或子单元/子模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之，上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。
此外，尽管在附图中以特定顺序描述了本公开方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。
虽然已经参考若干具体实施方式描述了本公开的精神和原理，但是应该理解，本公开并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本公开旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。

Claims (18)

1.一种数据处理方法，其特征在于，应用于社区版本的Impala集群，包括：
根据历史查询数据确定K个目标查询对象，K为正整数；
获取所述K个目标查询对象中每个目标查询对象的查询数据源；
基于所述K个目标查询对象中每个目标查询对象的查询数据源，预先确定所述K个目标查询对象中每个目标查询对象对应的查询结果；
以缓存表的形式存储每个所述目标查询对象与其对应的查询结果之间的对应关系得到M个缓存表，M为大于等于1且小于等于K的整数；
在接收到针对所述K个目标查询对象中的目标查询对象的查询请求时，基于所述查询请求确定所述查询请求的查询路径指向的初始表，在确定存在与所述初始表对应的缓存表，且所述查询请求的查询类型为预设查询类型的情况下，更改所述查询请求的查询路径；其中，更改后的所述查询路径指向所述目标查询对象对应的缓存表，所述预设查询类型至少包括聚合函数场景下的查询类型和去重函数场景下的查询类型；
基于更改后的所述查询路径获取所述目标查询对象的查询结果；
其中，针对聚合函数场景由SQL重写模块执行重写，所述重写包括在确定存在与所述初始表对应的缓存表，且所述查询请求的查询类型为预设查询类型的情况下，更改所述查询请求的查询路径；
所述SQL重写模块为内嵌在Impala节点中的一个模块，社区版本的流程分为三个阶段：SQL第一阶段SQL Parse、SQL第二阶段SQL Analyze和SQL第三阶段SQL Execute，当所述Impala节点完成SQL Parse后，所述SQL重写模块执行重写，重写完成后所述Impala节点再继续执行本身的后续流程。
2.根据权利要求1所述的方法，其中，所述方法还包括：
将所述M个缓存表集中式存储至第一预设数据库中，所述第一预设数据库是具有持久化存储功能的数据库。
3.根据权利要求1所述的方法，其中，所述根据历史查询数据确定K个目标查询对象，包括：
根据所述历史查询数据统计第一预设时间范围内各个第一类查询对象的查询频率或查询次数；
从所述第一预设时间范围内所述查询频率大于第一阈值或所述查询次数大于第二阈值的所述第一类查询对象中确定K个目标查询对象。
4.根据权利要求1所述的方法，其中，所述根据历史查询数据确定K个目标查询对象，包括：
根据所述历史查询数据统计第二预设时间范围内各个第二类查询对象的使用频率或使用次数；
从所述第二预设时间范围内所述使用频率大于第三阈值或所述使用次数大于第四阈值的所述第二类查询对象中确定K个目标查询对象。
5.根据权利要求1所述的方法，其中，所述方法还包括：
在接收到针对非目标查询对象的查询请求时，根据所述非目标查询对象的查询请求所指示的查询路径，确定所述非目标查询对象的查询结果。
6.根据权利要求1所述的方法，其中，所述方法还包括：
获取集群中N个节点上的查询记录，N为大于1的整数；
基于所述N个节点中每个节点上的查询记录，得到所述历史查询数据；
将所述历史查询数据存储到第二预设数据库。
7.根据权利要求6所述的方法，其中，所述方法还包括：
接收所述历史查询数据的获取请求；
基于所述获取请求输出所述历史查询数据；
其中，所述历史查询数据包括下述数据中的一种或几种：
每个历史查询请求的查询节点标识，
每个历史查询请求的查询提交时间，
每个历史查询请求的查询执行时间，
每个历史查询请求的用户信息。
8.根据权利要求6所述的方法，其中，所述方法还包括：
根据第三预设时间范围内的历史查询数据，统计所述第三预设时间范围内的各个历史查询请求的执行情况；
利用可视化工具表示所述第三预设时间范围内的各个历史查询请求的执行情况。
9.一种数据处理装置，其特征在于，应用于社区版本的Impala集群，包括：
确定单元，用于根据历史查询数据确定K个目标查询对象，K为正整数；
构建单元，用于获取所述K个目标查询对象中每个目标查询对象的查询数据源，基于所述K个目标查询对象中每个目标查询对象的查询数据源，预先确定所述K个目标查询对象中每个目标查询对象对应的查询结果，以缓存表的形式存储每个所述目标查询对象与其对应的查询结果之间的对应关系得到M个缓存表，M为大于等于1且小于等于K的整数；
更改单元，用于在接收到针对所述K个目标查询对象中的目标查询对象的查询请求时，基于所述查询请求确定所述查询请求的查询路径指向的初始表，在确定存在与所述初始表对应的缓存表，且所述查询请求的查询类型为预设查询类型的情况下，更改所述查询请求的查询路径；其中，更改后的所述查询路径指向所述目标查询对象对应的缓存表，所述预设查询类型至少包括聚合函数场景下的查询类型和去重函数场景下的查询类型；
获取单元，用于基于更改后的所述查询路径获取所述目标查询对象的查询结果；
其中，针对聚合函数场景由SQL重写模块执行重写，所述重写包括在确定存在与所述初始表对应的缓存表，且所述查询请求的查询类型为预设查询类型的情况下，更改所述查询请求的查询路径；
所述SQL重写模块为内嵌在Impala节点中的一个模块，社区版本的流程分为三个阶段：SQL第一阶段SQL Parse、SQL第二阶段SQL Analyze和SQL第三阶段SQL Execute，当所述Impala节点完成SQL Parse后，所述SQL重写模块执行重写，重写完成后所述Impala节点再继续执行本身的后续流程。
10.根据权利要求9所述的装置，其中，所述装置还包括：
存储单元，用于将所述M个缓存表集中式存储至第一预设数据库中，所述第一预设数据库是具有持久化存储功能的数据库。
11.根据权利要求9所述的装置，其中，所述确定单元，用于：
根据所述历史查询数据统计第一预设时间范围内各个第一类查询对象的查询频率或查询次数；
从所述第一预设时间范围内所述查询频率大于第一阈值或所述查询次数大于第二阈值的所述第一类查询对象确定K个目标查询对象。
12.根据权利要求9所述的装置，其中，所述确定单元，用于：
根据所述历史查询数据统计第二预设时间范围内各个第二类查询对象的使用频率或使用次数；
从所述第二预设时间范围内所述使用频率大于第三阈值或所述使用次数大于第四阈值的所述第二类查询对象中确定K个目标查询对象。
13.根据权利要求9所述的装置，其中，所述装置还包括：
控制单元，用于在接收到针对非目标查询对象的查询请求时，根据所述非目标查询对象的查询请求所指示的查询路径，确定所述非目标查询对象的查询结果。
14.根据权利要求9所述的装置，其中，所述装置还包括：
收集单元，用于获取集群中N个节点上的查询记录，N为大于1的整数；基于所述N个节点中每个节点上的查询记录，得到历史查询数据；将所述历史查询数据存储到第二预设数据库。
15.根据权利要求14所述的装置，其中，所述装置还包括：
查询单元，用于接收所述历史查询数据的获取请求；基于所述获取请求输出所述历史查询数据；
其中，所述历史查询数据包括下述数据中的一种或几种：
每个历史查询请求的查询节点标识，
每个历史查询请求的查询提交时间，
每个历史查询请求的查询执行时间，
每个历史查询请求的用户信息。
16.根据权利要求14所述的装置，其中，所述装置还包括：
统计单元，用于根据第三预设时间范围内的历史查询数据，统计所述第三预设时间范围内的各个历史查询请求的执行情况；
输出单元，用于利用可视化工具表示所述预设时间范围内的各个历史查询请求的执行情况。
17.一种介质，其存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1-8中任一所述的方法。
18.一种计算设备，其特征在于，包括：
一个或多个处理器；
存储装置，用于存储一个或多个程序；
当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1-8中任一所述的方法。
CN202110321215.3A 2021-03-25 2021-03-25 一种数据处理方法、装置、介质和计算设备 Active CN113032430B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110321215.3A CN113032430B (zh) 2021-03-25 2021-03-25 一种数据处理方法、装置、介质和计算设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110321215.3A CN113032430B (zh) 2021-03-25 2021-03-25 一种数据处理方法、装置、介质和计算设备

Publications (2)

Publication Number Publication Date
CN113032430A CN113032430A (zh) 2021-06-25
CN113032430B true CN113032430B (zh) 2023-12-19

Family

ID=76473786

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110321215.3A Active CN113032430B (zh) 2021-03-25 2021-03-25 一种数据处理方法、装置、介质和计算设备

Country Status (1)

Country Link
CN (1) CN113032430B (zh)

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9436735B1 (en) * 2015-07-14 2016-09-06 International Business Machines Corporation Access path optimization through system statistics
CN108205561A (zh) * 2016-12-19 2018-06-26 北京国双科技有限公司 数据查询系统、方法及装置
CN108268476A (zh) * 2016-12-30 2018-07-10 北京国双科技有限公司 数据查询方法及装置
CN108984553A (zh) * 2017-06-01 2018-12-11 北京京东尚科信息技术有限公司 缓存方法和装置
CN110032567A (zh) * 2019-04-24 2019-07-19 江苏满运软件科技有限公司 报表查询方法、装置、服务器和存储介质
CN110990439A (zh) * 2019-12-13 2020-04-10 深圳前海环融联易信息科技服务有限公司 基于缓存的快速查询方法、装置、计算机设备及存储介质
CN111259044A (zh) * 2020-01-15 2020-06-09 网易（杭州）网络有限公司 一种数据查询方法、装置、设备及介质
CN111475506A (zh) * 2020-03-30 2020-07-31 广州虎牙科技有限公司 数据存储、查询的方法、装置、系统、设备、存储介质
CN111858676A (zh) * 2020-07-24 2020-10-30 政采云有限公司 一种数据处理的方法及装置
CN111949856A (zh) * 2020-08-11 2020-11-17 北京金山云网络技术有限公司 基于web的对象存储查询方法及装置
CN112084210A (zh) * 2020-09-28 2020-12-15 中国建设银行股份有限公司 数据处理方法、装置、电子设备及存储介质

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9378216B2 (en) * 2009-09-29 2016-06-28 Oracle America, Inc. Filesystem replication using a minimal filesystem metadata changelog
US8380703B2 (en) * 2010-07-26 2013-02-19 International Business Machines Corporation Feedback loop between a query optimizer and a cache manager
US10185744B2 (en) * 2015-06-23 2019-01-22 Sap Se Caching views on historical data
US20170185673A1 (en) * 2015-12-25 2017-06-29 Le Holdings (Beijing) Co., Ltd. Method and Electronic Device for QUERY RECOMMENDATION
US10713248B2 (en) * 2017-07-23 2020-07-14 AtScale, Inc. Query engine selection

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9436735B1 (en) * 2015-07-14 2016-09-06 International Business Machines Corporation Access path optimization through system statistics
CN108205561A (zh) * 2016-12-19 2018-06-26 北京国双科技有限公司 数据查询系统、方法及装置
CN108268476A (zh) * 2016-12-30 2018-07-10 北京国双科技有限公司 数据查询方法及装置
CN108984553A (zh) * 2017-06-01 2018-12-11 北京京东尚科信息技术有限公司 缓存方法和装置
CN110032567A (zh) * 2019-04-24 2019-07-19 江苏满运软件科技有限公司 报表查询方法、装置、服务器和存储介质
CN110990439A (zh) * 2019-12-13 2020-04-10 深圳前海环融联易信息科技服务有限公司 基于缓存的快速查询方法、装置、计算机设备及存储介质
CN111259044A (zh) * 2020-01-15 2020-06-09 网易（杭州）网络有限公司 一种数据查询方法、装置、设备及介质
CN111475506A (zh) * 2020-03-30 2020-07-31 广州虎牙科技有限公司 数据存储、查询的方法、装置、系统、设备、存储介质
CN111858676A (zh) * 2020-07-24 2020-10-30 政采云有限公司 一种数据处理的方法及装置
CN111949856A (zh) * 2020-08-11 2020-11-17 北京金山云网络技术有限公司 基于web的对象存储查询方法及装置
CN112084210A (zh) * 2020-09-28 2020-12-15 中国建设银行股份有限公司 数据处理方法、装置、电子设备及存储介质

Also Published As

Publication number Publication date
CN113032430A (zh) 2021-06-25

Similar Documents

Publication Publication Date Title
US10261862B2 (en) Data replication in a database management system
US10372723B2 (en) Efficient query processing using histograms in a columnar database
US20140156683A1 (en) Integrating event processing with map-reduce
US10572508B2 (en) Consistent query execution in hybrid DBMS
JP2016519810A (ja) 半構造データのためのスケーラブルな分析プラットフォーム
US8577871B2 (en) Method and mechanism for out-of-the-box real-time SQL monitoring
US11640382B2 (en) Optimizing database performance through intelligent data partitioning orchestration
US11210274B2 (en) Prediction and repair of database fragmentation
US10678789B2 (en) Batch data query method and apparatus
US10599649B2 (en) Real time query planner statistics with time based changing
CN111008235A (zh) 一种基于Spark的小文件合并方法及系统
CN113297057A (zh) 内存分析方法、装置及系统
US11586616B2 (en) Automatically updating column data type
CN117349323B (zh) 数据库的数据处理方法及装置、存储介质及电子设备
US20120101984A1 (en) Method for performance tuning a database
CN113032430B (zh) 一种数据处理方法、装置、介质和计算设备
US20230153286A1 (en) Method and system for hybrid query based on cloud analysis scene, and storage medium
CN111666302A (zh) 用户排名的查询方法、装置、设备及存储介质
CN110888909B (zh) 一种评估内容的数据统计处理方法及装置
CN104317820B (zh) 报表的统计方法和装置
CN110737683A (zh) 一种基于抽取的商业智能分析平台自动分区方法及装置
CN113220530B (zh) 数据质量监控方法及平台
Seenivasan Improving the Performance of the ETL Jobs
US20150134919A1 (en) Information processing apparatus and data access method
CN113553320B (zh) 数据质量监控方法及装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
TA01 Transfer of patent application right

Effective date of registration: 20231109

Address after: 310052 Room 301, Building No. 599, Changhe Street Network Business Road, Binjiang District, Hangzhou City, Zhejiang Province

Applicant after: Hangzhou NetEase Shuzhifan Technology Co.,Ltd.

Address before: 310052 Building No. 599, Changhe Street Network Business Road, Binjiang District, Hangzhou City, Zhejiang Province, 4, 7 stories

Applicant before: NETEASE (HANGZHOU) NETWORK Co.,Ltd.

TA01 Transfer of patent application right
GR01 Patent grant
GR01 Patent grant