一种用于数据查询的加速处理方法及装置

技术领域

本申请涉及信息处理技术领域，特别是涉及一种用于数据查询的加速处理方法及装置、对应关系确定方法及装置、计算机可读存储介质、电子设备。

背景技术

随着互联网技术的高速发展，应用场景的不断增加，数据应用的需求越来越多，为快速响应需求，很多企业都不同程度的存在烟囱式的开发模式，这种烟囱式开发模式导致企业不同应用系统之间的数据是割裂的、没有联通的，造成数据的重复加工，进而导致研发效率、数据存储和计算资源的浪费，使大数据的应用成本越来越高，并带来指标口径不一致等问题。

产生上述问题的根源在于数据无法联通共享，为解决这一问题，数据中台应运而生。数据中台可以将企业不同应用系统的数据统一整合起来，借助大数据平台完成数据的统一加工处理，并对外提供数据服务。

在实际使用过程中，数据中台上可能会有上百万个数据集，且单个数据集中的数据量也非常多，针对一些慢数据进行数据查询分析时，耗时较长，用户体验较差。

发明内容

本申请提供了一种用于数据查询的加速处理方法及装置、对应关系确定方法及装置、计算机可读存储介质、电子设备，可以预先确定查询性能等级与加速引擎类型之间的对应关系，分析确定目标数据对应的目标查询性能等级后，可以根据对应关系确定目标查询性能等级对应的目标加速引擎，由目标加速引擎对目标数据进行查询分析，可有效缩短查询分析的耗时，提高分析效率。

本申请提供了如下方案：

一种用于数据查询的加速处理方法，包括：

第一服务端获得客户端关联的用户针对目标数据集提交的查询请求，从所述目标数据集中确定待分析的目标数据：

确定所述目标数据集对应的操作空间，并在所述操作空间创建包含所述目标数据的第一数据表；

确定所述第一数据表对应的目标查询性能等级，并根据加速引擎类型与查询性能等级之间的对应关系，确定所述目标查询性能等级对应的目标加速引擎；

在所述目标加速引擎对应的数据库中创建第二数据表，以便将所述第一数据表中的目标数据导入所述第二数据表，由所述目标加速引擎关联的第二服务端对所述目标数据进行查询分析，生成查询响应发送给所述客户端。

其中，所述确定所述目标数据集对应的操作空间，并在所述操作空间创建包含所述目标数据的第一数据表，包括：

根据所述目标数据集的元信息，确定所述目标数据集所属的项目空间，作为所述目标数据集对应的操作空间；

进入所述项目空间，并在所述项目空间提交创建所述第一数据表的SQL语句，所述创建所述第一数据表的SQL语句包括：表示所述目标数据的数据SQL语句，以及在所述数据SQL语句外包装的创建新表SQL语句。

其中，所述确定所述第一数据表对应的目标查询性能等级，包括：

获得根据预设数据量阈值划分的至少两个查询性能等级；

获得所述第一数据表中目标数据的目标数据量，并根据所述预设数据量阈值，确定所述目标数据量对应的目标查询性能等级。

其中，所述方法还包括：

获得所述目标数据集的使用频率信息；

根据所述使用频率信息和所述目标数据量，确定所述第一数据表对应的目标查询性能等级。

其中，所述在所述目标加速引擎对应的数据库中创建第二数据表，以便将所述第一数据表中的目标数据导入所述第二数据表，包括：

调整所述第一数据表在所述操作空间的生命周期，确保调整后的第一数据表不被清理；

将所述调整后的第一数据表确定为所述第二数据表。

其中，所述在所述目标加速引擎对应的数据库中创建第二数据表，以便将所述第一数据表中的目标数据导入所述第二数据表，包括：

控制在所述目标加速引擎对应的数据库中创建所述第二数据表；

获得所述第一数据表中的目标数据，写入至所述第二数据表。

其中，所述在所述目标加速引擎对应的数据库中创建第二数据表，以便将所述第一数据表中的目标数据导入所述第二数据表，包括：

控制在所述目标加速引擎对应的数据库中创建所述第二数据表；

控制所述目标加速引擎关联的第二服务端获得所述第一数据表中的目标数据写入至所述第二数据表。

其中，所述目标数据为整表导入的所述目标数据集的全部数据；或者，所述目标数据为根据所述查询请求确定的所述目标数据集的部分数据。

其中，所述方法还包括：

确定所述用户对数据查询的加速需求发生变化时，对所述对应关系进行更新处理。

其中，如果所述加速需求发生变化为需要加入新的加速引擎，所述对所述对应关系进行更新处理，包括：

获得所述新的加速引擎的接口调用信息，以便在需要时通过所述接口调用信息控制所述新的加速引擎进行加速处理；

确定所述新的加速引擎对应的查询性能等级，更新所述对应关系。

一种用于数据查询的加速处理方法，包括：

客户端提供用于提交查询请求的数据查询界面，通过所述数据查询界面获得针对目标数据集的查询请求，提交至第一服务端，以便所述第一服务端从所述目标数据集中确定待分析的目标数据，并在所述目标数据集对应的操作空间创建包含所述目标数据的第一数据表，进而根据加速引擎类型与查询性能等级之间的对应关系，确定所述第一数据表对应的目标查询性能等级对应的目标加速引擎，在所述目标加速引擎对应的数据库中创建第二数据表，并将所述目标数据导入所述第二数据表；

获得所述目标加速引擎关联的第二服务端针对所述第二数据表中的目标数据进行查询分析生成的查询响应。

一种用于数据查询的加速处理方法，包括：

确定目标加速引擎对应的数据库中创建第二数据表并导入目标数据时，所述目标加速引擎关联的第二服务端对所述目标数据进行查询分析，生成查询响应，所述第二数据表由第一服务端创建，所述第一服务端用于获得客户端针对目标数据集提交的查询请求，从所述目标数据集中确定所述目标数据，并在所述目标数据集对应的操作空间创建包含所述目标数据的第一数据表，进而根据加速引擎类型与查询性能等级之间的对应关系，确定所述第一数据表对应的目标查询性能等级对应的目标加速引擎，在所述目标加速引擎对应的数据库中创建所述第二数据表；

将所述查询响应发送至所述客户端。

一种对应关系确定方法，包括：

第二客户端获得查询性能等级信息以及加速引擎类型信息；

确定查询性能等级与加速引擎类型之间的对应关系，以便在针对数据查询进行加速处理时，获得包含待分析的目标数据的第一数据表对应的目标查询性能等级，并根据所述对应关系确定与所述目标查询性能等级对应的目标加速引擎，由所述目标加速引擎对所述目标数据进行查询分析。

一种用于数据查询的加速处理装置，应用于第一服务端，所述装置包括：

数据确定单元，用于获得客户端关联的用户针对目标数据集提交的查询请求，从所述目标数据集中确定待分析的目标数据；

第一数据表创建单元，用于确定所述目标数据集对应的操作空间，并在所述操作空间创建包含所述目标数据的第一数据表；

加速引擎确定单元，用于确定所述第一数据表对应的目标查询性能等级，并根据加速引擎类型与查询性能等级之间的对应关系，确定所述目标查询性能等级对应的目标加速引擎；

第二数据表创建单元，用于在所述目标加速引擎对应的数据库中创建第二数据表，以便将所述第一数据表中的目标数据导入所述第二数据表，由所述目标加速引擎关联的第二服务端对所述目标数据进行查询分析，生成查询响应发送给所述客户端。

一种用于数据查询的加速处理装置，应用于客户端，所述装置包括：

查询请求提交单元，用于提供用于提交查询请求的数据查询界面，通过所述数据查询界面获得针对目标数据集的查询请求，提交至第一服务端，以便所述第一服务端从所述目标数据集中确定待分析的目标数据，并在所述目标数据集对应的操作空间创建包含所述目标数据的第一数据表，进而根据加速引擎类型与查询性能等级之间的对应关系，确定所述第一数据表对应的目标查询性能等级对应的目标加速引擎，在所述目标加速引擎对应的数据库中创建第二数据表，并将所述目标数据导入所述第二数据表；

查询响应获得单元，用于获得所述目标加速引擎关联的第二服务端针对所述第二数据表中的目标数据进行查询分析生成的查询响应。

一种用于数据查询的加速处理装置，应用于目标加速引擎关联的第二服务端，所述装置包括：

查询响应生成单元，用于确定所述目标加速引擎对应的数据库中创建第二数据表并导入目标数据时，对所述目标数据进行查询分析，生成查询响应，所述第二数据表由第一服务端创建，所述第一服务端用于获得客户端针对目标数据集提交的查询请求，从所述目标数据集中确定所述目标数据，并在所述目标数据集对应的操作空间创建包含所述目标数据的第一数据表，进而根据加速引擎类型与查询性能等级之间的对应关系，确定所述第一数据表对应的目标查询性能等级对应的目标加速引擎，在所述目标加速引擎对应的数据库中创建所述第二数据表；

查询响应发送单元，用于将所述查询响应发送至所述客户端。

一种对应关系确定装置，应用于第二客户端，所述装置包括：

信息获得单元，用于获得查询性能等级信息以及加速引擎类型信息；

对应关系确定单元，用于确定查询性能等级与加速引擎类型之间的对应关系，以便在针对数据查询进行加速处理时，获得包含待分析的目标数据的第一数据表对应的目标查询性能等级，并根据所述对应关系确定与所述目标查询性能等级对应的目标加速引擎，由所述目标加速引擎对所述目标数据进行查询分析。

一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前述任一项所述的方法的步骤。

一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令，所述程序指令在被所述一个或多个处理器读取执行时，执行前述任一项所述的方法的步骤。

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

通过本申请，第一服务端可以接入多个数据库，并可根据数据库的查询特性对数据库引擎进行分类，建立加速引擎类型与查询性能等级之间的对应关系。需要进行加速处理时，可以先分析确定包含待分析的目标数据的第一数据表对应的目标查询性能等级，再根据预设对应关系确定目标查询性能等级对应的目标加速引擎，由目标加速引擎关联的第二服务端对目标数据进行查询分析，实现加速。如此通过选取与目标数据更适配的目标加速引擎进行数据查询分析的方案，可有效缩短查询分析的耗时，提高分析效率；此外，加速处理的实现过程也更为简便，开发和运维成本较低，且在加速处理过程中还可对用户屏蔽加速细节，降低对用户专业性的要求。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是本申请实施例提供的系统架构的示意图；

图2是本申请实施例提供的方法的流程图；

图3是本申请实施例提供的加速处理的时序图；

图4是本申请实施例提供的生成ODPS SQL的示意图；

图5是本申请实施例提供的加速处理装置的一种示意图；

图6是本申请实施例提供的加速处理装置的另一种示意图；

图7是本申请实施例提供的加速处理装置的再一种示意图；

图8是本申请实施例提供的对应关系确定装置的示意图；

图9是本申请实施例提供的电子设备的示意图。

具体实施方式

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

本申请实施例中，通过数据中台，除了可以对企业内部不同应用系统的数据进行统一整合之外，还可以将数据中台建设能力对外输出，承载第三方用户(可以是不同行业、不同企业的第三方用户)在不同应用场景下的大数据加工、数据可视化等处理需求。

以数据中台产品(用于大数据数据加工、数据可视化的应用搭建工具)为例，发明人在使用过程中发现，数据中台产品上承载有超过百万个数据集，且随着更多用户数据的产生，数据集的数量还会持续增加，其中超过75％的数据集为慢数据，即查询速度比较慢的数据，例如，使用了开放数据处理服务(ODPS，Open Data Processing Service)数据源的数据集，在进行ODPS查询时，其平均查询耗时在60秒，其中，耗时10秒以上的查询占99.66％，查询效率低、性能差，严重影响用户使用体验。

作为一种示例，慢数据可以为存储在ODPS上的数据；或者，也可以不关注数据来源，而是将查询速度或读取速度低于预设速度的数据确定为慢数据，可以理解地，预设速度可以根据实际使用需求设置，本申请实施例对此不做具体限定。

为了提高慢数据的查询分析速度，目前较为常见的实现方案有以下两种：

现有实现方案一：

BI分析平台本身不具有针对慢数据集的加速处理方案，而是通过外接第三方分析引擎的方式，进行数据查询的加速处理。也就是说，可以将BI分析平台的慢数据作为输入，提交至第三方分析引擎做计算处理，BI分析平台可以直接使用第三方分析引擎处理好的结果，以此实现加速。例如，BI分析平台为Power BI(英文：Power Business Intelligence，是微软推出的BI可视化工具)、第三方分析引擎为Apache Kylin(是一个开源的分布式分析引擎)。

这种实现方式下，一方面在BI分析平台搭建第三方分析引擎，导致使用成本、维护成本较高；另一方面，对BI(英文：Business Intelligence，中文：商业智能)用户的专业性要求较高，例如，使用Kylin进行智能分析加速时，需要用户熟悉Kylin的维度建模思想，这样，BI用户才能根据PowerBI输入的数据确定自定义维度，提交至Kylin，由Kylin进行维度聚合输出处理结果，用户的学习、使用成本较高。

具体实现过程可参照以下示例：

如果Power BI输入至Kylin的数据集为表1所示消费者的原始订单数据，针对这个数据集进行加速处理时，BI用户可以先明确需要分析的维度信息，例如，自定义维度为：商品，则将该自定义维度信息提交至Kylin后，Kylin可以遍历数据集中的数据，解析获得商品维度下所有的维值，例如，维值信息为：男装、女装。然后，Kylin可以对每个维值进行聚合处理，获得商品维度下的指标输出至Power BI，例如，输出指标为：男装的销售额、女装的销售额。

表1

以上仅为针对订单数据所举简单示例，在实际应用过程中，数据集可能涉及成百上千维度的数据，在进行查询分析时，需要BI用户选择合适的自定义维度，Kylin才能有针对性的进行维度聚合，对用户的专业性要求较高。

现有实现方案二：

BI分析平台通过自研算法实现针对慢数据集的加速处理，例如，FineBI(BI分析平台服务提供商)、Tableu(是一种轻量级可视化工具)等，其算法核心是将数据抽取后写入内存，这样，在进行数据分析时便可进行内存计算，以此实现加速。

这种实现方案主要基于查询时加速的设计思想，从算法层面解决原本查询性能差的问题。以在BI分析平台进行ODPS查询为例，确定好需要进行加速处理的ODPS数据集后，可以通过构建索引的方式，将数据集从ODPS导入BI分析平台服务器的本地内存，通过内存计算的方式实现加速。需要说明的是，数据实际仍存储在ODPS上，只是需要查询分析时才临时导入平台服务器。

该实现方式下，在进行首次查询时，并不知晓需要抽取哪些数据导入内存，故还是采用原有查询方案，实现的亦是分钟级的查询速度，性能较差；但在下次查询时可以通过内存计算的方式，完成数据查询分析，也就是说，多次查询时的整体速度会有所提高，目前可以使亿级大数据量下的展示速度达到秒级。

这种通过自研算法实现加速的方案，相对降低了对BI用户专业性的要求，用户体验更好，但其开发和运维的成本较高；另外，把数据导入内存，还带来一个严重的问题，就是内存计算比较消耗资源，加大了平台服务器设备的使用成本与维护成本。

在面对慢数据查询分析耗时长这一问题时，本申请实施例提供了一种基于预计算的智能加速方案，可有效提高数据查询分析的速度。

从系统架构角度而言，参见图1，本申请实施例用于数据查询的加速处理系统可以包括客户端、第一服务端和第二服务端。其中，客户端可以部署在用户关联的终端设备上，以网页形式或者独立的应用程序的形式存在，供用户操作使用。需要进行智能加速处理时，客户端可以提供数据查询界面，并通过数据查询界面获得用户针对目标数据集提交的查询请求，发送至第一服务端。

第一服务端可以部署在大数据平台的服务器上，接收客户端提交的查询请求，确定待分析的目标数据，分析选取与目标数据更适配的目标加速引擎，进而由目标加速引擎关联的第二服务端对目标数据进行查询分析，以此为用户提供数据查询的智能加速服务。

在不同的使用场景下，第一服务端部署的平台服务器也可以有所不同。以ODPS查询为例，第一服务端可以部署在ODPS平台的服务器上，为用户的ODPS查询进行加速处理；或者，第一服务端还可以部署在能承载ODPS数据的其他大数据平台的服务器上，例如，部署在数据中台的服务器上，用户通过数据中台进行ODPS查询时，可以通过本申请实施例提供的方案进行智能加速，大大缩短ODPS查询的耗时。

第二服务端可以部署在数据库关联的数据库引擎上，确定数据库中创建第二数据表并导入目标数据时，可以对目标数据进行查询分析，生成查询响应发送至客户端供用户查看。作为一种示例，第二服务端可以直接与客户端通信，将查询响应发送至客户端；或者，第二服务端可以将查询响应发送至第一服务端，由第一服务端将查询响应转发至客户端。

下面对本申请实施例提供的具体实现方案进行详细说明。

本申请实施例从第一服务端的角度，提供了一种用于数据查询的加速处理方法，参见图2所示流程图，可以包括：

S101：第一服务端获得客户端关联的用户针对目标数据集提交的查询请求，从所述目标数据集中确定待分析的目标数据。

本申请实施例中，用户可以通过查询请求灵活指定待分析的目标数据。具体地，目标数据可以是整表导入的目标数据集的全部数据；或者，可以是根据查询请求中包括的查询条件，过滤后的目标数据集的部分数据。

以在数据中台上实现数据查询为例，输入的目标数据集可以为数据中台上的原始数据集，用户可通过书写SQL的方式或者通过导入表的方式灵活构造用于加速处理的数据集，即，确定出待分析的目标数据，如此便可将原始数据集转化为一个通用的数据集SQL，作为加速处理的输入，执行后续处理步骤。

作为一种示例，构建好SQL数据集后，可以通过启动加速任务的方式，触发执行后续加速处理的步骤。

S102：确定所述目标数据集对应的操作空间，并在所述操作空间创建包含所述目标数据的第一数据表。

进行加速处理时，可以先明确目标数据集所属的操作空间，并在该操作空间内对目标数据集中的表进行操作控制。

具体地，可以根据目标数据集的元信息，确定目标数据集所属的项目空间，作为目标数据集对应的操作空间。以ODPS查询为例，项目空间(Project)是ODPS的基本组织单元，它类似于传统数据库的Database或Schema的概念，是进行多用户隔离和访问控制的主要边界。用户可以对项目空间中的对象，例如：表(Table)、资源(Resource)、函数(Function)、实例(Instance)进行访问控制。

进行加速处理时，可以在项目空间创建包含目标数据的第一数据表。具体地，可以进入目标数据集所属的项目空间，在该项目空间提交创建第一数据表的SQL语句，其中，创建第一数据表的SQL语句包括：表示目标数据的数据SQL语句，以及在数据SQL语句外包装的创建新表SQL语句。具体可参见图4所示生成ODPS SQL的示意图，左边为加速处理输入的数据集SQL，右边为服务端生成提交至ODPS Project的ODPS SQL，可以创建一个包含目标数据的第一数据表。

本申请实施例中，可以通过设置生命周期的方式，将第一数据表配置为临时表，即完成加速处理后可以删除的表，如此可保证本申请实施例的加速处理方案执行后，不会对目标数据集所属的操作空间产生任何影响。

除了上述通过提交创建新表SQL语句的方式生成第一数据表之外，还可以借助其他工具生成第一数据表，例如，通过dataX实现，本申请实施例对此不做具体限定。

在实际应用过程中，数据中台可以包括以下功能模块：请求模块、数据处理模块和元数据库模块，可以将本申请实施例提供的加速处理功能配置于数据处理模块，即，本申请实施例的第一服务端可以具体部署于数据处理模块，由数据处理模块实现智能加速功能。

参加图3所示时序图，获得目标数据后，可以通过请求模块触发数据处理模块执行智能加速。数据处理模块通过查询元数据库模块，确定目标数据集使用了ODPS数据源，可以运行ODPS任务(任务Task是ODPS的基本计算单元)，根据目标数据集的元信息确定目标数据集对应的ODPS Project，并在ODPS Project上提交ODPS SQL，即，在输入的数据SQL外，再包装一层创建新表SQL语句“CREATE TABLEAS”，以将目标数据写入ODPS表，即本申请实施例的第一数据表。

作为一种示例，本申请实施例还可以保存针对目标数据集进行加速处理时产生的日志信息。例如，数据处理模块通过元数据库模块查询数据集和数据源后，可以控制元数据库模块创建一条针对当前加速任务的记录，用于记录目标数据集的加速状态以及各加速状态对应的时间等日志信息。其中，加速状态至少可以包括：开始执行加速、加速执行中、加速成功、加速失败等状态，具体可结合实际使用需求设置。

如果目标数据集的日志信息中，加速状态为加速处理失败，可以重新进行加速处理，例如，重新启动针对SQL数据集的加速任务；或者，可以确定失败原因，返回执行失败原因对应的步骤，也就是说，可以记录加速处理的节点信息，例如：创建第一数据表、选取目标加速引擎、创建第二数据表，明确失败原因对应的节点，返回执行该节点对应的步骤。

S103：确定所述第一数据表对应的目标查询性能等级，并根据加速引擎类型与查询性能等级之间的对应关系，确定所述目标查询性能等级对应的目标加速引擎。

本申请实施例在进行慢数据查询时，可以充分利用不同数据库的查询性能优势，将原有通过单一数据库实现的查询分析，灵活分配到与第一数据表更适配的数据库执行，可有效缩短查询分析的耗时，提高查询效率。也就是说，第一服务端可以接入多个数据库，并可根据数据库的查询特性对数据库引擎进行分类，建立加速引擎类型与查询性能等级之间的对应关系。进行智能加速时，可以获得第一数据表对应的目标查询性能等级，并根据预设对应关系确定一个更满足用户查询性能要求的目标加速引擎，由目标加速引擎关联的第二服务端进行数据查询分析，实现智能加速的目的。

本申请实施例中，可以由第二客户端创建查询性能等级与加速引擎类型之间的对应关系。具体地，第二客户端获得查询性能等级信息以及加速引擎类型信息；确定查询性能等级与加速引擎类型之间的对应关系，以便在进行数据查询时，根据第一数据表对应的目标查询性能等级，分析确定与目标查询性能等级对应的目标加速引擎，由目标加速引擎关联的第二服务端对目标数据进行查询分析，实现数据查询分析的智能加速处理。

作为一种示例，可以结合第一数据表中目标数据的目标数据量，确定第一数据表的目标查询性能等级。具体地，可以根据使用需求确定至少一个预设数据量阈值，并据此划分出至少两个查询性能等级；获得第一数据表中目标数据的目标数据量，根据预设数据量阈值，确定目标数据量对应的目标查询性能等级。

对应于此，数据库的查询特性可以体现为数据库的承载上限，可以根据数据库承载的数据量划分数据库引擎的类型。其中，数据库的承载上限并非数据库本身的承载能力上限，而是根据查询性能确定的，在查询性能较好时所能承载的最大数据量。可以理解地，查询性能较好可以由用户根据使用需求确定，例如，用户希望查询耗时可以达到秒级，则符合秒级要求的便可认为查询性能较好。

例如，第一服务端接入的数据库为：RDS(英文：Relational Database Service，中文：关系型数据库服务)、ADB(AnalyticDB，是一个分析型数据库)，两个数据库可服务于不同数据量的场景，通常RDS数据库承载的数据量相对较小，使用成本低：ADB更适用于海量数据分析，使用成本相对较高。

本申请实施例中，可以根据RDS的承载上限，将预设数据量阈值确定为20万，并据此划分出两个查询性能等级：数据量＜20万时，表示小数据量场景的查询性能等级1；目标数据量≥20万，表示大数据量场景的查询性能等级2。对应的，可以划分出两种加速引擎类型：可对小数据量查询进行加速处理的加速引擎类型1，本示例中即为RDS引擎；可对大数据量查询进行加速处理的加速引擎类型2，本示例中即为ADB引擎。

可以理解地，预设数据量阈值的个数、取值等可根据实际使用需求、所选数据库的承载上限等因素确定，本申请实施例对此可不做具体限定。

上述示例中，可以获得下表2所示加速引擎类型与查询性能等级之间的对应关系。

表2

综上，如果第一数据表中目标数据的目标数据量低于预设数据量阈值20万，可以确定目标数据量对应的目标查询性能等级为等级1，由RDS引擎对目标数据进行查询分析，实现加速；如果目标数据量高于20万，可以确定目标查询性能等级为等级2，由ADB引擎对目标数据进行查询分析，实现加速。

除数据量维度之外，还可以综合其他维度确定第一数据表对应的目标查询性能等级，例如，目标数据集的使用频率信息。也就是说，对于高频数据和低频数据，可以由不同类型的加速引擎完成查询分析，故在进行加速引擎分类时，除了可以考虑数据库的查询特性之外，还可以考虑数据使用频率。

作为一种示例，目标数据集的使用频率信息可以体现为：预设时间段内的查询次数，可以将查询次数低于预设次数的数据集确定为低频数据，反之则可确定为高频数据。或者，目标数据集的使用频率信息可以体现为：其他可表示访问频次的信息，例如，数据集的最近一次访问时间，可以计算最近一次访问时间距离当前时间的时间差，将时间差超过预设时间阈值的数据集确定为低频数据，反之则可确定为高频数据。

本申请实施例中，根据使用频率信息和目标数据量，确定第一数据表对应的目标查询性能等级，可以体现为：在使用频率信息表示目标数据集为高频数据时，再结合目标数据量，确定第一数据表对应的目标查询性能等级。

对于高频数据来说，如果数据查询耗时长，对用户体验的影响较大，故可结合高频数据的数据量，确定对应的目标查询性能等级，由与目标查询性能等级相匹配的加速引擎，对高频数据进行数据查询分析，实现加速。

对于低频数据来说，偶尔进行的数据查询耗时长，对用户体验的影响相对不大，故对于低频数据可以采用现有方案完成数据查询分析。以通过数据中台实现ODPS查询为例，可以调用ODPS引擎完成数据查询分析。

或者，也可以根据用户使用需求，为低频数据配置进行加速处理的加速引擎，例如，MCQA引擎(英文：MaxCompute Query Acceleration)。MCQA引擎可以对中、小数据量查询作业进行加速优化，将执行时间从分钟级缩减至秒级，同时还可以完全兼容原ODPS的查询功能。

上述示例中，根据数据库查询特性以及数据使用频率划分的加速引擎类型，可以包括：可对高频、小数据量查询进行加速处理的加速引擎类型1′，本示例中即为RDS引擎；可对高频、大数据量查询进行加速处理的加速引擎类型2′，本示例中即为ADB引擎；可对低频数据查询进行加速处理的加速引擎类型3′，本示例中即为MCQA引擎。如此，可获得下表3所示的对应关系，新增了表示低频数据的查询性能等级3。

表3

结合表3所举示例，在实际使用过程中，可以获取当前时间T

可以理解地，在实际使用过程中，在使用频率信息表示目标数据集为低频数据时，亦可结合数据量进行综合分析，确定合适的加速引擎，即还可划分出如下加速引擎类型：可对低频、小数据量查询进行加速处理的加速引擎类型；可对低频、大数据量查询进行加速处理的加速引擎类型。具体可根据用户的使用需求确定，本申请实施例对此不做限定。

由上文介绍可知，加速引擎类型与查询性能等级之间的对应关系，对确定目标加速引擎起着至关重要的作用。在实际使用过程中，如果用户对数据查询的加速需求发生变化，还可以对对应关系进行更新处理，以便在后续进行智能加速处理时，可以根据更新后的对应关系，确定适配的加速引擎，以满足用户变化后的加速需求。

用户对数据查询的加速需求发生变化可以有多种表现形式，下面进行举例说明。

1.用户对查询速度的要求发生变化

在用户对查询速度的要求发生变化时，可以调整预设数据量阈值，重新划分查询性能等级；和/或，可以调整查询性能等级对应的加速引擎类型。例如，如果用户降低了对查询速度的要求，可以将预设数据量阈值从20万调整为30万，即，低于30万数据量的数据改由RDS引擎进行加速处理；或者，可以将等级3对应的加速引擎类型从MCQA引擎调整为ODPS引擎。

2.用户对加速处理的使用成本的要求发生变化

通过加速引擎进行加速处理，通常需要付出一定的使用成本，如果用户调整使用成本，选用其他加速引擎时，也可以对对应关系进行更新处理。

例如，ClickHouse(是一个开源的列式数据库DBMS，英文：Database ManagementSystem，中文：数据库管理系统)同样适用于海量数据分析，且使用成本相对ADB低一些，需要调低使用成本时，可以将等级2对应的加速引擎类型从ADB引擎调整为ClickHouse引擎，获得表4所示对应关系。

表4

或者，更新对应关系还可以体现为：将ClickHouse引擎新增为等级2对应的加速引挚，获得表5所示对应关系。

表5

此时，等级2对应ADB和ClickHouse2个加速引擎，在实际使用过程中，还可以进一步根据两个数据库的使用量、使用率、查询特性(例如，ADB的关联查询性能较好，ClickHouse的单表查询性能较好)等因素，从2个加速引擎中确定目标加速引擎，对目标数据进行加速处理。

由上文介绍可知，用户对数据查询的加速需求发生变化，可能不需要加入新的加速引擎，对查询性能等级、查询性能等级与已有加速引擎之间的对应关系，进行更新处理即可。或者，还可能需要加入新的加速引擎，对应于此，第一服务端除了要确定新的加速引擎对应的查询性能等级，更新对应关系之外，还需要获得新的加速引擎的接口调用信息，这样，在后续进行智能加速处理的过程中，如果将新的加速引擎确定为目标加速引擎，可以通过接口调用信息调用该新的加速引擎，完成加速处理。

需要说明的是，新的加速引擎对应的查询性能等级，可能是对应关系中已存在的等级，也可能是根据新的加速引擎的查询特性确定的新的等级，本申请实施例对此不做具体限定。

在加速需求发生变化时对对应关系进行更新处理，可以使本申请实施例的加速处理方案更具灵活性、普适性以及功能延展性，能更好地满足用户需求。

S104：在所述目标加速引擎对应的数据库中创建第二数据表，以便将所述第一数据表中的目标数据导入所述第二数据表，由所述目标加速引擎关联的第二服务端对所述目标数据进行查询分析，生成查询响应发送给所述客户端。

具体地，确定好目标加速引擎后，可以在目标加速引擎对应的数据库中创建第二数据表，将目标数据导入第二数据表，进而由目标加速引擎关联的第二服务端对第二数据表中的目标数据进行查询分析，生成查询响应发送给用户。

根据所选目标加速引擎的不同，创建第二数据表、将目标数据导入第二数据表的实现方式，可能会有所不同，下面进行举例说明。

表作为数据存储单元，可分为两种类型：外部表及内部表。以ODPS查询为例，内部表的所有数据都存储在ODPS中，外部表的数据则不存储于ODPS中。

如果第二数据表为内部表，可以调整第一数据表在操作空间的生命周期，确保调整后的第一数据表不被清理；将调整后的第一数据表确定为第二数据表。可以理解地，第二数据表中包含目标数据。例如，目标加速引擎为MCQA引擎时，可以按照上述调整第一数据表生命周期的方式，获得第二数据表。具体地，图3中的数据处理模块控制在ODPS Project中，将保存目标数据的临时表改为正式的加速表，即可由MCQA引擎执行后续查询分析过程，生成查询响应发送给用户。

如果第二数据表为外部表，可以控制在目标加速引擎对应的数据库中创建第二数据表，再将目标数据导入第二数据表。一种实现方式下，第一服务端可以获得第一数据表中的目标数据，写入至第二数据表，例如，目标加速引擎为RDS引擎时，第一服务端可以在RDS数据库中创建第二数据表，并将第一数据表中的目标数据写入第二数据表。具体地，图3中的数据处理模块控制在RDS数据库中创建DBA表(英文：Database Admin Table)，并通过批量数据查询的方式，从ODPS平台获得目标数据插入DBA表，还可将DBA表重命名为加速表，由RDS引擎对其执行后续的查询分析过程，生成查询响应发送给用户。

另一种实现方式下，第一服务端可以控制目标加速引擎关联的第二服务端获得第一数据表中的目标数据，写入至第二数据表。例如，目标加速引擎为ADB引擎或者ClickHouse引擎时，第一服务端可以在ADB引擎或者ClickHouse引擎对应的数据库中创建第二数据表，由ADB引擎或者ClickHouse引擎获得第一数据表中的目标数据，写入至第二数据表。具体地，图3中的数据处理模块控制在对应的数据库中创建ODPS外表，并在需要进行数据插入时，控制ADB引擎或者ClickHouse引擎从ODPS平台获得目标数据插入加速表，进而由ADB引擎或者ClickHouse引擎执行后续查询分析过程，生成查询响应发送给用户。

如上文所做介绍，本申请实施例中的第一数据表为可被清理的临时表，确定将第一数据表中的目标数据导入第二数据表后，可以在操作空间删除第一数据表。

综上可知，本申请实施例可以综合数据量、使用频率、使用成本等维度，智能选择与待分析的目标数据更适配的加速引擎，在提高查询分析速度的同时，还能降低加速成本、提高数据库的资源利用率。以ODPS查询为例，数据查询分析的平均耗时可以从60秒缩短到0.37秒，性能提升96.3％，大幅提升了数据分析的效率。

相较于现有实现方案一，本申请实施例在进行查询加速时，可以完全对用户屏蔽加速细节，例如，如何预计算抽取目标数据、如何选择目标加速引擎、如何将目标数据写入数据库等等，均无需用户关心，降低对用户专业性的要求，真正做到简单、高效、易用。

相较于现有实现方案二，不论是否首次查询，均可有效提高查询分析的响应速度；另外，本申请实施例通过接入高性能分析型数据库，例如RDS、ADB、ClickHouse等数据库，在进行数据查询分析时，可以有效利用其缓存能力、主备能力等，对数据中台本地设备的要求不高；同时，在开发和运维方面，也无需设计内存数据模型和物理存储模型，不用考虑存储和查询细节，需要与数据库交互时，直接使用RDS、ADB、ClickHouse的JDBC接口或SDK接口即可。

需要说明的是，上文所做介绍及表格中的RDS、ADB、ClickHouse、MCQA等加速引擎仅为示例性说明，用户可以结合实际使用需求确定进行加速处理的引擎，本申请实施例对所选加速引擎不做具体限定。

另外，需要说明的是，本申请实施例除了可以针对ODPS等离线数据，进行查询加速外，还可以针对MySQL、Hologress等在线数据的查询分析进行智能加速，具体实现过程可参照上文所做介绍，此处不再赘述。

与前述方法实施例相对应，本申请实施例还提供了一种用于数据查询的加速处理装置，可应用于第一服务端，参见图5，该装置可以包括：

数据确定单元201，用于获得客户端关联的用户针对目标数据集提交的查询请求，从所述目标数据集中确定待分析的目标数据；

第一数据表创建单元202，用于确定所述目标数据集对应的操作空间，并在所述操作空间创建包含所述目标数据的第一数据表；

加速引擎确定单元203，用于确定所述第一数据表对应的目标查询性能等级，并根据加速引擎类型与查询性能等级之间的对应关系，确定所述目标查询性能等级对应的目标加速引擎；

第二数据表创建单元204，用于在所述目标加速引擎对应的数据库中创建第二数据表，以便将所述第一数据表中的目标数据导入所述第二数据表，由所述目标加速引擎关联的第二服务端对所述目标数据进行查询分析，生成查询响应发送给所述客户端。

所述第一数据表创建单元具体可以用于：

根据所述目标数据集的元信息，确定所述目标数据集所属的项目空间，作为所述目标数据集对应的操作空间；

进入所述项目空间，并在所述项目空间提交创建所述第一数据表的SQL语句，所述创建所述第一数据表的SQL语句包括：表示所述目标数据的数据SQL语句，以及在所述数据SQL语句外包装的创建新表SQL语句。

所述加速引擎确定单元具体可以用于：

获得根据预设数据量阈值划分的至少两个查询性能等级；

获得所述第一数据表中目标数据的目标数据量，并根据所述预设数据量阈值，确定所述目标数据量对应的目标查询性能等级。

所述装置还可以包括：

使用频率获得单元，用于获得所述目标数据集的使用频率信息；

所述加速引擎确定单元具体可以用于：根据所述使用频率信息和所述目标数据量，确定所述第一数据表对应的目标查询性能等级。

所述第二数据表创建单元具体可以用于：

调整所述第一数据表在所述操作空间的生命周期，确保调整后的第一数据表不被清理；

将所述调整后的第一数据表确定为所述第二数据表。

所述第二数据表创建单元具体可以用于：

控制在所述目标加速引擎对应的数据库中创建所述第二数据表；

获得所述第一数据表中的目标数据，写入至所述第二数据表。

所述第二数据表创建单元具体可以用于：

控制在所述目标加速引擎对应的数据库中创建所述第二数据表；

控制所述目标加速引擎关联的第二服务端获得所述第一数据表中的目标数据写入至所述第二数据表。

其中，所述目标数据为整表导入的所述目标数据集的全部数据；或者，所述目标数据为根据所述查询请求确定的所述目标数据集的部分数据。

所述装置还可以包括：

对应关系更新单元，用于确定所述用户对数据查询的加速需求发生变化时，对所述对应关系进行更新处理。

如果所述加速需求发生变化为需要加入新的加速引擎，所述对应关系更新单元具体可以用于：

获得所述新的加速引擎的接口调用信息，以便在需要时通过所述接口调用信息控制所述新的加速引擎进行加速处理；

确定所述新的加速引擎对应的查询性能等级，更新所述对应关系。

与前述方法实施例相对应，本申请实施例还提供了一种用于数据查询的加速处理装置，可应用于客户端，参见图6，该装置可以包括：

查询请求提交单元301，用于提供用于提交查询请求的数据查询界面，通过所述数据查询界面获得针对目标数据集的查询请求，提交至第一服务端，以便所述第一服务端从所述目标数据集中确定待分析的目标数据，并在所述目标数据集对应的操作空间创建包含所述目标数据的第一数据表，进而根据加速引擎类型与查询性能等级之间的对应关系，确定所述第一数据表对应的目标查询性能等级对应的目标加速引擎，在所述目标加速引擎对应的数据库中创建第二数据表，并将所述目标数据导入所述第二数据表；

查询响应获得单元302，用于获得所述目标加速引擎关联的第二服务端针对所述第二数据表中的目标数据进行查询分析生成的查询响应。

与前述方法实施例相对应，本申请实施例还提供了一种用于数据查询的加速处理装置，可应用于目标加速引擎关联的第二服务端，参见图7，该装置可以包括：

查询响应生成单元401，用于确定所述目标加速引擎对应的数据库中创建第二数据表并导入目标数据时，对所述目标数据进行查询分析，生成查询响应，所述第二数据表由第一服务端创建，所述第一服务端用于获得客户端针对目标数据集提交的查询请求，从所述目标数据集中确定所述目标数据，并在所述目标数据集对应的操作空间创建包含所述目标数据的第一数据表，进而根据加速引擎类型与查询性能等级之间的对应关系，确定所述第一数据表对应的目标查询性能等级对应的目标加速引擎，在所述目标加速引擎对应的数据库中创建所述第二数据表；

查询响应发送单元402，用于将所述查询响应发送至所述客户端。

与前述方法实施例相对应，本申请实施例还提供了一种对应关系确定装置，可应用于第二客户端，参见图8，该装置可以包括：

信息获得单元501，用于获得查询性能等级信息以及加速引擎类型信息；

对应关系确定单元502，用于确定查询性能等级与加速引擎类型之间的对应关系，以便在针对数据查询进行加速处理时，获得包含待分析的目标数据的第一数据表对应的目标查询性能等级，并根据所述对应关系确定与所述目标查询性能等级对应的目标加速引擎，由所述目标加速引擎对所述目标数据进行查询分析。

另外，本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前述方法实施例中任一项所述的方法的步骤。

以及一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令，所述程序指令在被所述一个或多个处理器读取执行时，执行前述方法实施例中任一项所述的方法的步骤。

其中，图9示例性的展示出了电子设备的架构，例如，设备1500可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理，飞行器等。

参照图9，设备1500可以包括以下一个或多个组件：处理组件1502，存储器1504，电源组件1506，多媒体组件1508，音频组件1510，输入/输出(I/O)接口1512，传感器组件1514，以及通信组件1516。

处理组件1502通常控制设备1500的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理元件1502可以包括一个或多个处理器1520来执行指令，以完成本公开技术方案提供的方法的全部或部分步骤。此外，处理组件1502可以包括一个或多个模块，便于处理组件1502和其他组件之间的交互。例如，处理部件1502可以包括多媒体模块，以方便多媒体组件1508和处理组件1502之间的交互。

存储器1504被配置为存储各种类型的数据以支持在设备1500的操作。这些数据的示例包括用于在设备1500上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器1504可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件1506为设备1500的各种组件提供电力。电源组件1506可以包括电源管理系统，一个或多个电源，及其他与为设备1500生成、管理和分配电力相关联的组件。

多媒体组件1508包括在设备1500和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件1508包括一个前置摄像头和/或后置摄像头。当设备1500处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件1510被配置为输出和/或输入音频信号。例如，音频组件1510包括一个麦克风(MIC)，当设备1500处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器1504或经由通信组件1516发送。在一些实施例中，音频组件1510还包括一个扬声器，用于输出音频信号。

I/O接口1512为处理组件1502和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件1514包括一个或多个传感器，用于为设备1500提供各个方面的状态评估。例如，传感器组件1514可以检测到设备1500的打开/关闭状态，组件的相对定位，例如所述组件为设备1500的显示器和小键盘，传感器组件1514还可以检测设备1500或设备1500一个组件的位置改变，用户与设备1500接触的存在或不存在，设备1500方位或加速/减速和设备1500的温度变化。传感器组件1514可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件1514还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件1514还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件1516被配置为便于设备1500和其他设备之间有线或无线方式的通信。设备1500可以接入基于通信标准的无线网络，如WiFi，或2G、3G、4G/LTE、5G等移动通信网络。在一个示例性实施例中，通信部件1516经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信部件1516还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例中，设备1500可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器1504，上述指令可由设备1500的处理器1520执行以完成本公开技术方案提供的方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

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