CN110555080B - 一种联机分析处理方法、装置及系统 - Google Patents

一种联机分析处理方法、装置及系统 Download PDF

Info

Publication number
CN110555080B
CN110555080B CN201810291182.0A CN201810291182A CN110555080B CN 110555080 B CN110555080 B CN 110555080B CN 201810291182 A CN201810291182 A CN 201810291182A CN 110555080 B CN110555080 B CN 110555080B
Authority
CN
China
Prior art keywords
query
data set
physical
cube
target
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
CN201810291182.0A
Other languages
English (en)
Other versions
CN110555080A (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.)
Huaban Payment Shenzhen Co ltd
Original Assignee
Huawei Technologies 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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN201810291182.0A priority Critical patent/CN110555080B/zh
Publication of CN110555080A publication Critical patent/CN110555080A/zh
Application granted granted Critical
Publication of CN110555080B publication Critical patent/CN110555080B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明的实施例提供一种联机分析处理方法、装置及系统,涉及通信领域,可降低cube的查询响应时间,并提高整个HOLAP系统中的资源利用率。该方法包括:获取目标时间段内接收到的一个或多个查询请求,其中每个查询请求用于请求查询至少一个数据集;根据所述一个或多个查询请求确定实际物理化属性与预期物理化属性不相符的目标数据集,所述物理化属性用于指示数据集具有虚拟特性或者物理特性;将所述预期物理化属性作为所述目标数据集修改后的实际物理化属性,使得所述目标数据集按照修改后的实际物理化属性被更新。

Description

一种联机分析处理方法、装置及系统
技术领域
本发明涉及通信领域,尤其涉及一种联机分析处理方法、装置及系统。
背景技术
联机分析处理(On-Line Analytical Processing,OLAP)是使分析人员、管理人员或执行人员能够从多角度对信息进行快速、一致、交互地存取,从而对数据获得更深入了解的一类软件技术。如图1所述,在OLAP系统中,可将某一数据以多维数据集(本申请实施例中也可称为cube)的形式进行存储,从而反映出该数据在多个维度上的特征。
具体的,OLAP有多种实现方式,根据存储数据的方式不同可以分为ROLAP(Relational OLAP)、MOLAP(Multidimensional OLAP)以及HOLAP(Hybrid OLAP)等。其中,MOLAP表示基于多维数据组织的OLAP实现方式,在MOLAP中每个cube一般是经过物理化后持久存储在MOLAP的服务器中,经过物理化的cube可以直接被读取,但每个cube均需预先被物理化。ROLAP表示基于关系数据库的OLAP实现方式,在ROLAP中每个cube一般是以虚拟化的形式被定义的,当接收到具体的cube查询请求时,才会触发ROLAP的服务器基于该cube的定义生成cube内的实际数据从而被读取,这种cube的使用方式虽然较为灵活,但每次生成的cube内的实际数据不做持久化存储,因此每次响应查询请求时均需要消耗计算资源实时计算cube内的实际数据。
而HOLAP是基于上述MOLAP和ROLAP进行混合数据组织的OLAP实现方式。如图2所示,在HOLAP中需要对每一个cube是否被物理化的物化属性进行记录,这样,当用户请求已经被物理化的cube时,可指示MOLAP的服务器提供该cube的查询服务,当用户请求还没有被物理化的cube时,可指示ROLAP的服务器提供该cube的查询服务。
但是,管理员在HOLAP中设置的被物理化的cube和没有被物理化的cube时可能与用户的实际使用需求发生偏差。例如,管理员预先将cube1设置为没有被物理化的cube,但如果用户对cube1的查询频率较高时,每次接收到cube1的查询请求后均需要由MOLAP的服务器对cube1进行物理化后才能提供该cube1的查询服务,不仅增加了cube的查询响应时间,同时增加了整个HOLAP中的资源开销。
发明内容
本发明的实施例提供一种联机分析处理方法、装置及系统,可降低cube的查询响应时间,并提高整个HOLAP系统中的资源利用率。
为达到上述目的,本发明的实施例采用如下技术方案:
第一方面,本发明的实施例提供一种联机分析处理方法,包括:获取目标时间段内接收到的一个或多个查询请求,其中每个查询请求用于请求查询至少一个数据集;进而,根据上述一个或多个查询请求可确定出实际物理化属性与预期物理化属性不相符的目标数据集,一个数据集的物理化属性用于指示该数据集具有虚拟特性或者物理特性;那么,将目标数据集的实际物理化属性修改为预期物理化属性后,可使得目标数据集按照修改后的实际物理化属性被更新。也就是说,本申请中可基于各个数据集的查询频率,动态的调整相应数据集的物理化属性,使得更新后的目标数据集的实际物理化属性与其预期物理化属性相符,这样,整个HOLAP系统可以根据用户对不同数据集的查询需求智能的调整各个数据集的物理化属性,从而降低数据集的查询响应时间,并提高整个HOLAP系统中的资源利用率。
在一种可能的设计方法中,上述每个查询请求中包括请求查询的数据集的标识,其中,上述根据一个或多个查询请求确定实际物理化属性与预期物理化属性不相符的目标数据集,具体包括:获取混合联机分析处理(HOLAP)系统中存储的所有数据集的标识;将所有数据集中除所述一个或多个查询请求中请求查询的数据集之外的数据集作为目标数据集。那么,这些目标数据集均为在目标时间段内没有被查询过的数据集,后续可将这些目标数据集的物理化属性修改为下线状态,从而减轻HOLAP系统内维护各个数据集时的资源开销。
在一种可能的设计方法中,上述每个查询请求中包括请求查询的数据集的标识,以及该查询请求的查询时间;其中,上述根据一个或多个查询请求确定实际物理化属性与预期物理化属性不相符的目标数据集,具体包括:根据所述一个或多个查询请求的查询时间以及请求查询的数据集的标识,确定在所述目标时间段内满足预设查询频率的候选数据集,以及所述候选数据集的预期物理化属性;并且,获取所述候选数据集的实际物理化属性;若所述候选数据集的实际物理化属性与所述候选数据集的预期物理化属性不相符,则将所述候选数据集作为目标数据集。
示例性的,所述候选数据集为:在所述目标时间段内查询量最高的X1(X1≥1)个数据集,如果这些数据集具有虚拟特性,则每次响应这些数据集的查询请求时,还需要额外对这些数据集进行物理化,生成物理化的数据集,容易造成资源浪费和响应时间增加,因此,可设置所述候选数据集的预期物理化属性为具有物理特性;或者,所述候选数据集为:在所述目标时间段内查询量最低的Y1(Y1≥1)个数据集,如果这些数据集具有物理特性,则说明这些数据集一直占用存储资源却很少被访问,造成资源浪费,因此,可设置所述候选数据集的预期物理化属性为具有虚拟特性。
进一步地,上述每个查询请求中还包括响应该查询请求所花费的响应时长;此时,上述候选数据集为:在目标时间段内响应时长最长的K1(K1≥1)个数据集,如果这些数据集具有虚拟特性,则每次响应这些数据集的查询请求时,同样也需要额外对这些数据集进行物理化,生成物理化的数据集,因此,可设置所述候选数据集的预期物理化属性为具有物理特性。
在一种可能的设计方法中,所述每个查询请求中包括请求查询的数据集的标识、该数据集的实际物理化属性以及该查询请求的查询时间;其中,根据所述一个或多个查询请求,确定实际物理化属性与预期物理化属性不相符的目标数据集,包括:根据所述一个或多个查询请求,将实际物理化属性满足预设物理化属性条件且实际查询频率满足预设查询频率的数据集确定为所述目标数据集。
示例性的,所述目标数据集为:在所述目标时间段内查询量最高、且实际物理化属性为具有虚拟特性的X2个数据集,所述目标数据集的预期物理化属性为具有物理特性,X2≥1;或者,所述目标数据集为:在所述目标时间段内查询量最低、且实际物理化属性为具有物理特性的Y2个数据集,所述候选数据集的预期物理化属性为具有虚拟特性,Y1≥1。
进一步地,所述每个查询请求中还包括响应该查询请求所花费的响应时长;其中,所述候选数据集为:在所述目标时间段内响应时长最长,且实际物理化属性为具有虚拟特性的K2个数据集,所述候选数据集的预期物理化属性为具有物理特性,K2≥1。
在一种可能的设计方法中,在获取目标时间段内接收到的一个或多个查询请求之前,还包括:接收并存储接收到的数据集的查询请求。
第二方面,本申请的实施例提供一种HOLAP系统,包括:元数据库、数据集分析模块以及查询记录模块;所述查询记录模块,用于:存储所述HOLAP系统接收到的查询请求,所述查询请求用于请求查询至少一个数据集;所述元数据库,用于:存储所述HOLAP系统中每个数据集的实际物理化属性;所述数据集分析模块,用于:从所述查询记录模块获取目标时间段内接收到的一个或多个查询请求;根据所述一个或多个查询请求,确定实际物理化属性与预期物理化属性不相符的目标数据集,所述物理化属性用于指示数据集具有虚拟特性或者物理特性;以及,将所述预期物理化属性作为所述目标数据集修改后的实际物理化属性,使得所述目标数据集按照修改后的实际物理化属性被更新。
在一种可能的设计方法中,所述一个或多个查询请求中的每个查询请求包括请求查询的数据集的标识,所述元数据库,还用于存储所述HOLAP系统中每个数据集的标识;所述数据集分析模块,具体用于:从所述元数据库中获取所述HOLAP系统中每个数据集的标识;将除所述一个或多个查询请求中请求查询的数据集之外的数据集作为所述目标数据集,所述目标数据集的预期物理化属性为具有虚拟特性。
在一种可能的设计方法中,每个查询请求包括请求查询的数据集的标识,以及该查询请求的查询时间;所述数据集分析模块,具体用于:根据所述一个或多个查询请求的查询时间以及请求查询的数据集的标识,确定在所述目标时间段内满足预设查询频率的候选数据集,以及所述候选数据集的预期物理化属性;从所述元数据库中获取所述候选数据集的实际物理化属性;若所述候选数据集的实际物理化属性与所述候选数据集的预期物理化属性不相符,则将所述候选数据集作为所述目标数据集;其中,所述候选数据集为:在所述目标时间段内查询量最高的X1个数据集,所述候选数据集的预期物理化属性为具有物理特性,X1≥1;或者,所述候选数据集为:在所述目标时间段内查询量最低的Y1个数据集,所述候选数据集的预期物理化属性为具有虚拟特性,Y1≥1。
进一步地,每个查询请求还包括响应该查询请求所花费的响应时长;其中,所述候选数据集为:在所述目标时间段内响应时长最长的K1个数据集,所述候选数据集的预期物理化属性为具有物理特性,K1≥1。
在一种可能的设计方法中,每个查询请求包括请求查询的数据集的标识、实际物理化属性以及该查询请求的查询时间;所述数据集分析模块,具体用于:根据所述一个或多个查询请求,将实际物理化属性满足预设物理化属性条件且实际查询频率满足预设查询频率的数据集确定为所述目标数据集;其中,所述目标数据集为:在所述目标时间段内查询量最高、且实际物理化属性为具有虚拟特性的X2个数据集,所述目标数据集的预期物理化属性为具有物理特性,X2≥1;或者,所述目标数据集为:在所述目标时间段内查询量最低、且实际物理化属性为具有物理特性的Y2个数据集,所述候选数据集的预期物理化属性为具有虚拟特性,Y1≥1。
进一步地,每个数据集的查询请求还包括响应该查询请求所花费的响应时长;其中,所述候选数据集为:在所述目标时间段内响应时长最长,且实际物理化属性为具有虚拟特性的K2个数据集,所述候选数据集的预期物理化属性为具有物理特性,K2≥1。
在一种可能的设计方法中,所述系统还包括数据集查询接口;所述数据集查询接口,用于:提供所述HOLAP系统中数据集的同一查询接口;所述数据集分析模块,还用于:接收所述数据集查询接口发送的数据集的查询请求;将所述查询请求存储至所述查询记录模块。
在一种可能的设计方法中,所述系统还包括多维联机分析处理MOLAP服务器和关系联机分析处理ROLAP服务器;所述MOLAP服务器,用于:当所述目标数据集的实际物理化属性修改为具有物理特性时,将所述目标数据集转换为具有物理特性的数据集;所述ROLAP服务器,用于:当所述目标数据集的实际物理化属性修改为具有虚拟特性时,将所述目标数据集转换为具有虚拟特性的数据集。
第三方面,本申请的实施例提供一种联机分析处理装置,包括:处理器、存储器和通信接口;该存储器用于存储计算机执行指令,该处理器与该存储器耦接,当联机分析处理装置运行时,该处理器执行该存储器存储的该计算机执行指令,以使联机分析处理装置执行上述任一项联机分析处理方法。
第四方面,本申请实施例提供一种计算机可读存储介质,该计算机可读存储介质中存储有指令,当该指令在上述任一项联机分析处理装置上运行时,使得联机分析处理装置执行上述任一项联机分析处理方法。
第五方面,本申请实施例提供一种包含指令的计算机程序产品,当其在上述任一项联机分析处理装置上运行时,使得联机分析处理装置执行上述任一项联机分析处理方法。
本申请的实施例中,上述联机分析处理装置或HOLAP系统中各模块的名字对设备本身不构成限定,在实际实现中,这些装置或模块可以以其他名称出现。只要各个装置或模块的功能和本申请的实施例类似,即属于本申请权利要求及其等同技术的范围之内。
另外,第二方面至第五方面中任一种设计方式所带来的技术效果可参见上述第一方面中不同设计方法所带来的技术效果,此处不再赘述。
附图说明
图1为现有技术中多维数据集的示意图;
图2为现有技术中HOLAP的系统架构示意图;
图3为本发明实施例提供的一种HOLAP的系统架构示意图;
图4为本发明实施例提供的一种联机分析处理方法的交互示意图一;
图5为本发明实施例提供的一种联机分析处理方法的交互示意图二;
图6为本发明实施例提供的一种联机分析处理方法的交互示意图三;
图7为本发明实施例提供的一种联机分析处理装置的结构示意图一;
图8为本发明实施例提供的一种联机分析处理装置的结构示意图二。
具体实施方式
以下,术语“第一”、“第二”仅用于描述目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本申请实施例的描述中,除非另有说明,“多个”的含义是两个或两个以上。
OLAP是针对特定问题的联机数据访问与分析方法。在OLAP系统中,可通过多维的方式对数据进行分析、查询和报表。
其中,维是人们观察数据的特定角度。例如,一个企业在考虑产品的销售情况时,可以从时间、地区和产品等不同角度来深入观察产品的销售情况。这里的时间、地区和产品就是维。而这些维的不同组合和所考察的度量指标构成的多维数组则是OLAP分析的基础,可形式化表示为(维1,维2,……,维n,度量指标),例如(地区、时间、产品、销售额)。
多维分析是指对以多维形式组织起来的数据采取切片(slice)、切块(dice)、钻取(drill-down和roll-up)、旋转(pivot)等各种分析动作,以求剖析数据,使用户能从多个角度、多侧面地观察数据库中的数据,从而深入理解包含在数据中的信息。
在OLAP系统中,数据库中的数据通常以“cube”的形式展示其多维特性。而cube又可以划分为具有虚拟特性的虚拟化cube和具有物理特性的物理化cube。其中,物理化cube是指对cube的各个维度进行定义后,按照该定义生成的多维数据集,通常可持久化的存储在数据库中。而虚拟化cube是指仅对cube的各个维度进行了定义,还未生成实际数据(例如多维数据集)的虚拟多维数据集。后续可基于接收到的cube请求为相应的虚拟化cube生成实际的多维数据集并提供给用户。
进一步地,OLAP又可进一步划分为基于多维数据库的MOLAP、基于关系数据库的ROLAP以及基于上述MOLAP和ROLAP进行混合数据组织的HOLAP三种实现方式。
其中,MOLAP系统中的cube一般是物理化的cube,这样在多维分析时可直接基于用户的cube查询请求为用户提供相应的物理化cube;而ROLAP系统中的cube一般是虚拟化的cube,因此在多维分析时需要先基于用户的cube查询请求生成相应虚拟化cube的实际数据,进而向用户提供该cube的实际数据,当完成该cube查询请求后,可删除该cube的实际数据。
也就是说,cube具体可以包括两部分,一部分是对该cube各个维度的定义,另一部分是按照该定义生成的cube内的实际数据。一般,cube的定义中会设置该cube的物理化属性(例如cube_is_virtual选项),当cube_is_virtual=false时,可认为该cube具有物理特性(即物理化的cube),MOLAP系统的服务器会按照cube的定义生成cube内的实际数据并存储;当cube_is_virtual=true时,可认为该cube具有虚拟特性(即虚拟化的cube),此时,ROLAP系统中的服务器仅维护该cube的定义,在后续接收到该cube的查询请求时可实时生成该cube中的实际数据。
在HOLAP系统中,集成了上述MOLAP系统中的物理化cube以及上述ROLAP系统中的虚拟化cube。因此,当用户请求的cube已经被物理化时,可按照MOLAP由MOLAP系统的服务器提供该cube的查询服务,相应的,当用户请求的cube没有被物理化时,可按照ROLAP由ROLAP系统的服务器提供该cube的查询服务,实现更加灵活的多维分析服务。
HOLAP系统中的物理化cube和虚拟化cube是管理员在创建HOLAP系统时预先设置的,例如,管理员预先将cube1-cube10设置为物理化cube,由MOLAP系统的服务器创建cube1-cube10后对其维护和管理,相应的,管理员可将cube11-cube20设置为虚拟化cube,由ROLAP系统的服务器管理。但是,在实际使用过程中用户对cube是否物理化的需求可能与预先设置的cube的物理化属性不相符。
例如,在一段时间内用户频繁请求查询cube11,但由于cube11为虚拟化的cube,因此每次接收到用户查询cube11的查询请求时,均需要ROLAP系统的服务器先按照cube11的定义生成cube11的实际数据,进而将cube11的实际数据反馈给用户,造成cube查询请求的响应变慢,以及HOLAP系统的资源开销增大等问题。
又例如,由于cube1为物理化的cube,因此每次HOLAP系统中的源数据更新时,均需要MOLAP系统的服务器使用更新后的源数据重新生成各个物理化的cube1-cube10。那么,当用户对cube1的查询频率很低时,频繁的生成物理化的cube1无疑造成系统资源的浪费。
对此,本发明实施例提供的一种联机分析处理方法可应用于HOLAP系统300中,如图3所示,该HOLAP系统300中除了包括与现有HOLAP系统中相同的cube查询接口(HOLAPFacade)301、元数据库(Metadata)302、MOLAP服务器303以及ROLAP服务器304之外,还包括cube分析模块305以及查询记录模块306。
其中,查询记录模块306与cube分析模块305相连,cube分析模块305还与cube查询接口301以及元数据库302相连。
具体的,仍如图3所示,cube查询接口301用于向用户或其他设备提供虚拟化cube和物理化cube的统一查询接口。例如,该cube查询接口301具体可以是OLAP4J或者JOLAP或者mdXML等标准接口。示例性的,用户或其他设备可以基于MDX(multidimensionalexpressions,多维表达式)这种语法向cube查询接口301中输入查询请求,以请求查询某一具体cube(例如cube1)中的数据内容。
进一步地,cube查询接口301接收到上述查询请求后,可通过IF1接口在元数据库302中查询上述cube1的物理化属性,即cube1为虚拟化的cube还是物理化cube。其中,元数据库302中记录有HOLAP系统300中每一个cube的ID(cube_ID)、cube的名称(cube_name)、cube所属的数据库对象的标识(cube_schema_Id)、cube所属的数据库对象的名称(cube_schema_name)以及cube的物理化属性等属性信息。
那么,当上述cube1为物理化的cube时,cube查询接口301可以通过IF2接口将上述查询请求路由至MOLAP服务器303中,由MOLAP服务器303提供cube1的查询服务。相应的,当上述cube1为虚拟化的cube时,cube查询接口301可以通过IF3接口将上述查询请求路由至ROLAP服务器304中,由ROLAP服务器304提供cube1的查询服务。
在本申请实施例中,每当cube查询接口301接收到对某一cube的查询请求时,仍如图3所示,cube查询接口301还可以通过IF8接口将该查询请求发送给cube分析模块305,由cube分析模块305通过IF9接口将该查询请求所请求的cube的标识(例如上述cube_Id或cube_name)、查询时间(例如cube_query_time)以及响应该查询请求所花费的响应时长(例如cube_query_spent_time)存储在查询记录模块306中。
这样,cube分析模块305可以从查询记录模块306中获取到一定时间内请求频率较高或较低的cube,例如,cube分析模块305可计算得到最近一周内请求频率最高cube为cube1,请求频率最低cube为cube2。进而,cube分析模块305可以从元数据库302中进一步查询上述cube1和cube2的物理化属性。
对于请求频率最高的cube1,如果cube1为虚拟化的cube,则说明每次查询cube1时均需要ROLAP服务器304将虚拟化的cube1转换为物理化的cube1。因此,cube分析模块305可以通过IF10接口在元数据库302中将cube1的物理化属性修改为物理化的cube。例如,将cube1的物理化属性从“cube_is_virtual=true”修改为“cube_is_virtual=false”。
这样,MOLAP服务器303通过IF6接口(图3中未示出)检测到cube1的物理化属性被修改后,可将虚拟化的cube1转换为物理化的cube1,并将物理化的cube1持久存储在MOLAP服务器303中。后续,当cube查询接口301接收到cube1的查询请求时,可直接由MOLAP服务器303提供已经物理化的cube1,从而减少每次对cube1物理化时造成的资源浪费以及查询该cube1时的等待时间。
相应的,对于请求频率最低的cube2,如果cube2为物理化的cube,说明已经被物理化的cube2在MOLAP服务器303中很少被查询,但每次MOLAP服务器303更新cube时都需要重新对cube2进行物理化,造成资源浪费。因此,cube分析模块305可以通过IF10接口在元数据库302中将cube2的物理化属性修改为虚拟化的cube。例如,将cube2的物理化属性从“cube_is_virtual=false”修改为“cube_is_virtual=true”。
这样,ROLAP服务器304通过IF7接口(图3中未示出)检测到cube2的物理化属性被修改后,仅需维护cube2的定义,而MOLAP服务器303检测到cube2的物理化属性被修改后,可将物理化的cube2(即cube2的定义以及cube2的数据)从MOLAP服务器303中删除。后续,cube查询接口301接收到cube2的查询请求时,可由ROLAP服务器304将虚拟化的cube2转换为物理化的cube2,以完成cube2的查询服务。
可以看出,本申请实施例提供的HOLAP系统300通过增设cube分析模块305以及查询记录模块306,可基于接收到的历史cube查询请求动态地调整不同cube的物里化属性,使得请求频率较高的cube可以以物理化的形式存储在MOLAP服务器303中直接被读取,而请求频率较低的cube可以以虚拟化的形式存储在ROLAP服务器304中,在需要读取该cube时被物理化,从而可降低整个HOLAP系统中cube的查询响应时间及资源开销。
其中,上述IF1接口至IF10接口具体可以为文件接口或REST(RepresentationalState Transfer,表述性状态传递)等标准接口。另外,IF1接口至IF10接口中的多个接口之间可以复用,本申请实施例对此不做任何限制。
需要说明的是,上述HOLAP系统300中的各个模块可以为独立的实体设备,或者,也可以将上述HOLAP系统300中的各个模块集成在一个或多个实体设备或者虚拟机中实现上述HOLAP方案,本申请实施例对此不做任何限制。
以下,将结合图3通过具体实施例详细阐述本申请实施例提供的一种联机分析处理方法,如图4所示,该方法包括:
401、cube查询接口301将接收到的查询请求发送至cube分析模块305,该查询请求中携带有待查询的cube的标识以及该查询请求的时间信息。
402、cube分析模块305将上述查询请求存储至查询记录模块306。
在步骤401-402中,cube查询接口301每次接收到查询某一cube的查询请求时,可将该查询请求发送给cube分析模块305,由cube分析模块305将该查询请求持久化的存储至查询记录模块306中。
其中,存储至查询记录模块306的每个查询请求中均包括本次请求查询的cube的标识,例如,该标识可以是该cube的ID(cube_Id)、cube的名称(cube_name)、cube所属的数据库对象的标识(cube_schema_Id)或者cube所属的数据库对象的名称(cube_schema_name)等能够唯一表示该cube的任意标识。
另外,存储至查询记录模块306的每个查询请求中还包括接收到本次查询请求时的查询时间(cube_query_time)以及完成本次查询请求的响应时长(cube_query_spent_time)等时间信息。
这样,如表1所示,查询记录模块306中记录有cube查询接口301每次接收到的查询请求中请求查询的cube和查询时间的详情。其中,同一个cube可以被多次请求查询,这些cube可以是MOLAP服务器303中的物理化cube,也可以是ROLAP服务器304中的虚拟化cube,本申请实施例对此不作任何限制。
表1
待查询的cube的标识 查询时间 响应时长
foo_1234 2018-1-14,8:46:02 30s
foo_1235 2018-1-14,17:15:26 14s
…… …… ……
示例性的,上述查询记录模块306可以是一个关系型数据库,cube查询接口301可以通过JDBC(Java DataBase Connectivity,Java数据库连接)技术,使用SQL(StructuredQuery Language,结构化查询语言)将cube的查询请求存储至查询记录模块306中。
以PostgreSQL为例,以下为创建表1所示的查询请求表的一种可能的实现方式:
Figure BDA0001617562520000071
Figure BDA0001617562520000081
403、cube分析模块305从查询记录模块306中获取目标时间段内的N个查询请求,N≥1。
在步骤403中,cube分析模块305可以定期从查询记录模块306中获取目标时间段内cube查询接口301接收到的所有查询请求,得到上述N个查询请求。
例如,cube分析模块305可以每周日从查询记录模块306中查询最近一周内接收到的N个查询请求。当然,上述目标时间段的具体时间以及cube分析模块305获取上述N个查询请求的具体时间可以由本领域技术人员根据实际经验和实际应用场景进行设置,本申请实施例对此不做任何限制。
404、cube分析模块305确定上述N个查询请求所请求的cube中满足预设查询频率的候选cube,以及该候选cube的预期物理化属性。
其中,满足上述预设查询频率的候选cube具体可以为:目标时间段内查询量最高的X1(X1≥1)个cube,目标时间段内查询量最低的Y1(Y1≥1)个cube或者目标时间段内响应时长最长的K1(K1≥1)个cube等。
那么,在步骤404中,cube分析模块305可以根据上述N个查询请求中每个查询请求内携带的查询时间和响应时长,统计出满足上述预设查询频率的候选cube,该候选cube可以为一个或多个。
示例性的,以下为cube分析模块305从查询记录模块306中查询候选cube的一种可能的实现方式:
SELECT cube_id,count(1)AS cube_count
FROM CA_QUERY_DATA
WHERE cube_query_time BETWEEN'2017-11-01'AND'2017-11-30'//从查询记录模块306中查询2017-11-01至2017-11-30内被请求查询的cube
GROUP BY cube_id,//按照cube_id分组
ORDER BY cube_count DESC
LIMIT 1//按照cube查询数量降序的顺序获取位于首位的cube的id
对于目标时间段内查询量最高的X1个cube,由于其查询频率较高,那么,如果将这些cube设置为虚拟化的cube,则每次响应这些cube的查询请求时,还需要ROLAP服务器304额外对这些cube进行物理化,生成物理化的cube,容易造成资源浪费和响应时间增加。因此,可将这些cube的预期物理化属性设置为物理化的cube。
对于目标时间段内查询量最低的Y1个cube,由于其查询频率较低,那么,如果将这些cube设置为物理化的cube,则这些cube一直占用MOLAP服务器303中的存储资源却很少被访问,造成资源浪费。因此,可将这些cube的预期物理化属性设置为虚拟化的cube。
对于目标时间段内响应时长最长的K1个cube,由于查询这些cube所花费的时长较长,那么,如果将这些cube设置为虚拟化的cube,则每次响应这些cube的查询请求时,同样也需要ROLAP服务器304额外对这些cube进行物理化,生成物理化的cube。因此,可将这些cube的预期物理化属性设置为物理化的cube。
这样,cube分析模块305可以确定出满足上述预设查询频率的候选cube的预期物理化属性,后续,如下述步骤405-406所示,如果候选cube的实际物理化属性与其预期物理化属性不相符,则cube分析模块305可以修改候选cube的实际物理化属性。
405、cube分析模块305从元数据库302中获取上述候选cube的实际物理化属性。
406、若候选cube的实际物理化属性与预期物理化属性不相符,则cube分析模块305将该候选cube作为目标cube并在元数据库302中将目标cube的实际物理化属性修改为上述预期物理化属性。
在步骤405中,cube分析模块305还可以根据上述目标cube的标识,从元数据库302中获取上述目标cube的实际物理化属性。例如,cube分析模块305可以通过HTTP(HyperText Transfer Protocol,超文本传输协议)REST接口读取元数据库302中记录的上述目标cube的实际物理化属性。
例如,上述目标cube为cube1,上述步骤404中cube分析模块305为cube1确定的预期物理化属性为虚拟化的cube1。那么,在步骤405中,cube分析模块305可进一步从元数据库302中获取cube1的实际物理化属性,例如,cube1的实际物理化属性为物理化的cube。
由于上述cube1的实际物理化属性与cube1的预期物理化属性不相符,因此,在步骤406中,cube分析模块305可以在元数据库302中将cube1的实际物理化属性修改为虚拟化的cube1,使得cube1修改后的实际物理化属性与cube1的预期物理化属性相符。
示例性的,以下为cube分析模块305将元数据库302中虚拟化的目标cube修改为物理化的目标cube的一种可能的实现方式:
URI:/meta/{schema_id}/{cube_id}?cube_is_virtual=true//查找实际物理化属性为虚拟化的cube
HTTP Method:PUT
cube_is_virtual=false//修改为物理化的cube
在本申请的另一些实施例中,如图5所示,在cube分析模块305从查询记录模块306中获取目标时间段内的N个查询请求(即步骤403)之后,cube分析模块305还可以执行以下步骤501-503以替代上述步骤404-406。
501、cube分析模块305从元数据库302中获取当前HOLAP系统中所有cube的标识。
502、cube分析模块305确定需要下线的目标cube。
503、cube分析模块305在元数据库302中将目标cube的状态修改为下线状态。
具体的,在步骤501-503中,结合HOLAP系统中所有cube的标识以及上述N个查询请求中涉及的cube标识,cube分析模块305可确定出所有cube中在目标时间段内没有被查询过的cube,进而将这些cube确定为需要下线的cube(即目标cube)。此时,cube分析模块305可以在元数据库302中将这些需要下线的cube的物理化属性从online状态修改为offline状态。
示例性的,以下为cube分析模块305将元数据库302中的目标cube进行下线的一种可能的实现方式:
URI:/meta/{schema_id}/{cube_id}state=offline
HTTP Method:PUT//将目标cube的物理化属性修改为下线状态
后续,如果目标cube原本为MOLAP服务器303中物理化的cube,则MOLAP服务器303检测到元数据库302中目标cube的物理化属性变为offline状态时,MOLAP服务器303可删除该目标cube的定义和实际数据。如果目标cube原本为ROLAP服务器304中虚拟化的cube,则ROLAP服务器304检测到元数据库302中目标cube的物理化属性变为offline状态时,ROLAP服务器303可删除该目标cube的定义,从而减轻HOLAP系统内维护各个cube时的资源开销。
在本申请的另一些实施例中,如表2所示,cube分析模块305还可以将待查询的cube的物理化属性携带在其查询请求中,并存储至查询记录模块306。例如,cube查询接口301接收到查询cube1的查询请求后,可从元数据库302中获取cube1的物理化属性,例如cube_is_virtual=false(即cube1为物理化的cube)。进而,将cube1的标识、查询时间、响应时长以及物理化属性一并携带在查询请求中发送给cube分析模块305。
表2
待查询的cube的标识 查询时间 响应时长 物理化属性
foo_1234 2018-1-14,8:46:02 30s false
foo_1235 2018-1-14,17:15:26 14s true
…… …… ……
这样,如图6所示,cube分析模块305还可以执行以下步骤601以替代上述步骤403-405。
601、cube分析模块305从查询记录模块306中查询目标时间段内物理化属性满足预设条件,且查询频率满足预设查询频率的目标cube。
具体的,cube分析模块305后续可从查询记录模块306中直接查询目标时间段内物理化属性满足预设条件,且查询频率满足预设查询频率的目标cube。例如,从查询记录模块306中查询目标时间段内查询量最高,且cube_is_virtual=true的X2(X2≥1)个cube;又例如,从查询记录模块306中查询目标时间段内查询量最低,且cube_is_virtual=false的Y2(Y2≥1)个cube;又例如,从查询记录模块306中查询目标时间段内响应时长最长,且cube_is_virtual=true的K2(K2≥1)个cube等。
后续,与步骤406类似的,cube分析模块305可在元数据库302中修改上述目标cube的实际物理化属性,使目标cube的实际物理化属性与预期物理化属性相同。
示例性的,以下为cube分析模块305从查询记录模块306中查询目标cube的一种可能的实现方式:
SELECT cube_id,count(1)AS cube_count
FROM CA_QUERY_DATA
WHERE cube_query_time BETWEEN'2017-11-01'AND'2017-11-30'//从查询记录模块306中查询2017-11-01至2017-11-30内被请求查询的cube
AND cube_is_virtual=true//并且查询上述2017-11-01至2017-11-30内被请求查询的cube中实际物理化属性为虚拟化的cube
GROUP BY cube_id,//按照cube_id分组
ORDER BY cube_count DESC
LIMIT 1//按照cube查询数量降序的顺序获取位于首位的cube的id(即2017-11-01至2017-11-30内查询量最高,且cube_is_virtual=true的目标cube)
407、MOLAP服务器303(或ROLAP服务器304)按照上述目标cube修改后的实际物理化属性,更新自身存储的cube。
MOLAP服务器303(或ROLAP服务器304)可以定期查看元数据库302中记录的每个cube的属性信息,当cube分析模块305在元数据库302中修改了目标cube的实际物理化属性后,与该目标cube相关的MOLAP服务器303(或ROLAP服务器304)可按照上述目标cube被修改后的实际物理化属性,重新更新自身存储的cube。
例如,如果cube分析模块305将cube1从虚拟化的cube修改为物理化的cube,那么,MOLAP服务器303检测到这一变化后,可按照虚拟化的cube1的定义生成物理化的cube1,并存储在MOLAP服务器303中。同时,原本维护cube1的ROLAP服务器304可以删除自身已存储的与cube1相关的数据。后续当cube查询接口301再次接收到查询cube1的查询请求时,可路由至MOLAP服务器303提供cube1的查询服务。
又例如,如果cube分析模块305将cube2从物理化的cube修改为虚拟化的cube,那么,原本维护cube2的MOLAP服务器303检测到这一变化后,可将已存储的物理化的cube2中的实际数据删除,同时,ROLAP服务器304检测到这一变化后,可将cube2的定义作为虚拟化的cube进行维护。后续当cube查询接口301再次接收到查询cube2的查询请求时,可路由至ROLAP服务器304提供cube2的查询服务。
408、(可选的)cube分析模块305将查询记录模块306中目标cube的查询请求删除。
与步骤402类似的,cube查询接口301可以通过JDBC技术,使用SQL从查询记录模块306中将目标cube的查询请求删除,避免已使用过的目标cube对cube分析模块305后续计算新的目标时间段内不同cube的查询频率时产生影响。
示例性的,以下为cube分析模块305从查询记录模块306中删除2017-11-01至2017-11-30这一目标时间段内目标cube(例如目标cube的标识为foo_1234和foo_2234)的一种可能的实现方式:
DELETE
FROM CA_QUERY_DATA//从查询记录模块306中
WHERE cube_query_time BETWEEN'2017-11-01'AND'2017-11-30'AND cube_idin('foo_1234','foo_2234')//删除2017-11-01至2017-11-30之间cube的ID为foo_1234和foo_2234的查询请求
至此,本申请实施例提供的一种联机分析处理方法可基于各个cube的查询频率,动态的调整相应cube的物理化属性,将查询频率较高的虚拟化cube转化为物理化cube,避免每次查询该cube时进行物理化操作导致资源浪费,相应的,将查询频率较低的物理化cube转化为虚拟化cube,避免查询频率较低的cube占用HOLAP系统中的存储资源。这样一来,整个HOLAP系统可以根据用户对不同cube的查询需求智能的调整各个cube的物理化属性,从而降低cube的查询响应时间,并提高整个HOLAP系统中的资源利用率。
可以理解的是,上述HOLAP中的各个模块等为了实现上述功能,其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,本申请实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请实施例的范围。
本申请实施例可以根据上述方法示例对上述HOLAP中cube分析模块305(本申请实施例中也可称为联机分析处理装置)等进行功能模块的划分,例如,可以对应各个功能划分各个功能模块,也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现,也可以采用软件功能模块的形式实现。需要说明的是,本申请实施例中对模块的划分是示意性的,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。
在采用对应各个功能划分各个功能模块的情况下,图7示出了上述实施例中所涉及的联机分析处理装置的一种可能的结构示意图,该联机分析处理装置用于实现以上各个方法实施例中记载的方法,其包括:获取单元701、保存单元702、确定单元703以及修改单元704。
获取单元701用于支持联机分析处理装置执行图4中的过程401、403、405,以及图5中的过程501,以及图6中的过程601;保存单元702用于支持联机分析处理装置执行图4中的过程402;确定单元703用于支持联机分析处理装置执行图4中的过程404,以及图5中的过程502;修改单元704用于支持联机分析处理装置执行图4中的过程406,以及图5中的过程503。其中,上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述,在此不再赘述。
在采用集成的单元的情况下,可将上述确定单元703以及修改单元704集成为处理模块,将保存单元702作为存储模块,将获取单元701作为通信模块。
此时,如图8所示,示出了上述实施例中所涉及的联机分析处理装置的一种可能的结构示意图。其中,处理模块802用于对联机分析处理装置的动作进行控制管理。通信模块803用于支持联机分析处理装置与HOLAP系统内的其他网络实体的通信。存储模块801用于保存联机分析处理装置的程序代码和数据。其中,上述联机分析处理方法涉及的各步骤的所有相关内容均可以援引到上述实施例各步骤的相关描述,在此不再赘述。
示例性的,处理模块802可以是处理器或控制器,例如可以是中央处理器(CentralProcessing Unit,CPU),GPU,通用处理器,数字信号处理器(Digital Signal Processor,DSP),专用集成电路(Application-Specific Integrated Circuit,ASIC),现场可编程门阵列(Field Programmable Gate Array,FPGA)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框,模块和电路。所述处理器也可以是实现计算功能的组合,例如包含一个或多个微处理器组合,DSP和微处理器的组合等等。
通信模块803可以是收发器、收发电路、输入输出设备或通信接口等。例如,通信模块803具体可以是蓝牙装置、Wi-Fi装置、外设接口等等。
存储模块801可以是存储器,该存储器可以包括高速随机存取存储器(RAM),还可以包括非易失存储器,例如磁盘存储器件、闪存器件或其他易失性固态存储器件等。
在上述实施例中,可以全部或部分的通过软件,硬件,固件或者其任意组合来实现。当使用软件程序实现时,可以全部或部分地以计算机程序产品的形式出现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时,全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质,(例如,软盘,硬盘、磁带)、光介质(例如,DVD)或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。
以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何在本申请揭露的技术范围内的变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以所述权利要求的保护范围为准。

Claims (19)

1.一种联机分析处理OLAP方法,其特征在于,包括:
获取目标时间段内接收到的一个或多个查询请求,其中,每个查询请求用于请求查询至少一个数据集,所述每个查询请求中包括请求查询的数据集的标识,以及该查询请求的查询时间;
根据所述一个或多个查询请求中每个查询请求的查询时间以及请求查询的数据集的标识,确定在所述目标时间段内满足预设查询频率的候选数据集,以及所述候选数据集的预期物理化属性;
获取所述候选数据集的实际物理化属性;
若所述候选数据集的实际物理化属性与所述候选数据集的预期物理化属性不相符,则将所述候选数据集作为目标数据集;所述物理化属性用于指示数据集具有虚拟特性或者物理特性;
将所述预期物理化属性作为所述目标数据集修改后的实际物理化属性,使得所述目标数据集按照修改后的实际物理化属性被更新。
2.根据权利要求1所述的方法,其特征在于,
所述候选数据集为:在所述目标时间段内查询量最高的X1个数据集,所述候选数据集的预期物理化属性为具有物理特性,X1≥1;或者,
所述候选数据集为:在所述目标时间段内查询量最低的Y1个数据集,所述候选数据集的预期物理化属性为具有虚拟特性,Y1≥1。
3.根据权利要求1所述的方法,其特征在于,所述每个查询请求中还包括响应该查询请求所花费的响应时长;
其中,所述候选数据集为:在所述目标时间段内响应时长最长的K1个数据集,所述候选数据集的预期物理化属性为具有物理特性,K1≥1。
4.根据权利要求1-3中任一项所述的方法,其特征在于,在获取目标时间段内接收到的一个或多个查询请求之前,还包括:
接收并存储接收到的数据集的查询请求。
5.一种联机分析处理OLAP方法,其特征在于,包括:
获取目标时间段内接收到的一个或多个查询请求,其中,每个查询请求用于请求查询至少一个数据集,所述每个查询请求中包括请求查询的数据集的标识、该数据集的实际物理化属性以及该查询请求的查询时间;
根据所述一个或多个查询请求,将实际物理化属性满足预设物理化属性条件且实际查询频率满足预设查询频率的数据集确定为目标数据集;所述物理化属性用于指示数据集具有虚拟特性或者物理特性;
将预期物理化属性作为所述目标数据集修改后的实际物理化属性,使得所述目标数据集按照修改后的实际物理化属性被更新。
6.根据权利要求5所述的方法,其特征在于,
所述目标数据集为:在所述目标时间段内查询量最高、且实际物理化属性为具有虚拟特性的X2个数据集,所述目标数据集的预期物理化属性为具有物理特性,X2≥1;或者,
所述目标数据集为:在所述目标时间段内查询量最低、且实际物理化属性为具有物理特性的Y2个数据集,所述目标数据集的预期物理化属性为具有虚拟特性,Y2≥1。
7.根据权利要求5所述的方法,其特征在于,所述每个查询请求中还包括响应该查询请求所花费的响应时长;
其中,所述目标数据集为:在所述目标时间段内响应时长最长,且实际物理化属性为具有虚拟特性的K2个数据集,所述目标数据集的预期物理化属性为具有物理特性,K2≥1。
8.根据权利要求5-7中任一项所述的方法,其特征在于,在获取目标时间段内接收到的一个或多个查询请求之前,还包括:
接收并存储接收到的数据集的查询请求。
9.一种混合联机分析处理HOLAP系统,其特征在于,包括:元数据库、数据集分析模块以及查询记录模块;
所述查询记录模块,用于:存储所述HOLAP系统接收到的查询请求,所述查询请求用于请求查询至少一个数据集;
所述元数据库,用于:存储所述HOLAP系统中每个数据集的实际物理化属性;
所述数据集分析模块,用于:从所述查询记录模块获取目标时间段内接收到的一个或多个查询请求,所述每个查询请求中包括请求查询的数据集的标识,以及该查询请求的查询时间;根据所述一个或多个查询请求中每个查询请求的查询时间以及请求查询的数据集的标识,确定在所述目标时间段内满足预设查询频率的候选数据集,以及所述候选数据集的预期物理化属性;从所述元数据库中获取所述候选数据集的实际物理化属性;若所述候选数据集的实际物理化属性与所述候选数据集的预期物理化属性不相符,则将所述候选数据集作为目标数据集;所述物理化属性用于指示数据集具有虚拟特性或者物理特性;以及,将所述预期物理化属性作为所述目标数据集修改后的实际物理化属性,使得所述目标数据集按照修改后的实际物理化属性被更新。
10.根据权利要求9所述的系统,其特征在于,
其中,所述候选数据集为:在所述目标时间段内查询量最高的X1个数据集,所述候选数据集的预期物理化属性为具有物理特性,X1≥1;或者,所述候选数据集为:在所述目标时间段内查询量最低的Y1个数据集,所述候选数据集的预期物理化属性为具有虚拟特性,Y1≥1。
11.根据权利要求10所述的系统,其特征在于,所述一个或多个查询请求中的每个查询请求还包括响应该查询请求所花费的响应时长;
其中,所述候选数据集为:在所述目标时间段内响应时长最长的K1个数据集,所述候选数据集的预期物理化属性为具有物理特性,K1≥1。
12.根据权利要求9-11中任一项所述的系统,其特征在于,所述系统还包括数据集查询接口;
所述数据集查询接口,用于:提供所述HOLAP系统中数据集的同一查询接口;
所述数据集分析模块,还用于:接收所述数据集查询接口发送的数据集的查询请求;将所述查询请求存储至所述查询记录模块。
13.根据权利要求9-11中任一项所述的系统,其特征在于,所述系统还包括多维联机分析处理MOLAP服务器和关系联机分析处理ROLAP服务器;
所述MOLAP服务器,用于:当所述目标数据集的实际物理化属性修改为具有物理特性时,将所述目标数据集转换为具有物理特性的数据集;
所述ROLAP服务器,用于:当所述目标数据集的实际物理化属性修改为具有虚拟特性时,将所述目标数据集转换为具有虚拟特性的数据集。
14.一种混合联机分析处理HOLAP系统,其特征在于,包括:元数据库、数据集分析模块以及查询记录模块;
所述查询记录模块,用于:存储所述HOLAP系统接收到的查询请求,所述查询请求用于请求查询至少一个数据集;
所述元数据库,用于:存储所述HOLAP系统中每个数据集的实际物理化属性;
所述数据集分析模块,用于:从所述查询记录模块获取目标时间段内接收到的一个或多个查询请求,所述一个或多个查询请求中的每个查询请求包括请求查询的数据集的标识、实际物理化属性以及该查询请求的查询时间;根据所述一个或多个查询请求,将实际物理化属性满足预设物理化属性条件且实际查询频率满足预设查询频率的数据集确定为目标数据集;所述物理化属性用于指示数据集具有虚拟特性或者物理特性;以及,将预期物理化属性作为所述目标数据集修改后的实际物理化属性,使得所述目标数据集按照修改后的实际物理化属性被更新。
15.根据权利要求14所述的系统,其特征在于,
所述目标数据集为:在所述目标时间段内查询量最高、且实际物理化属性为具有虚拟特性的X2个数据集,所述目标数据集的预期物理化属性为具有物理特性,X2≥1;或者,所述目标数据集为:在所述目标时间段内查询量最低、且实际物理化属性为具有物理特性的Y2个数据集,所述目标数据集的预期物理化属性为具有虚拟特性,Y2≥1。
16.根据权利要求15所述的系统,其特征在于,
所述一个或多个查询请求中的每个数据集的查询请求还包括响应该查询请求所花费的响应时长;
其中,所述目标数据集为:在所述目标时间段内响应时长最长,且实际物理化属性为具有虚拟特性的K2个数据集,所述目标数据集的预期物理化属性为具有物理特性,K2≥1。
17.根据权利要求14-16任一项所述的系统,其特征在于,所述系统还包括数据集查询接口;
所述数据集查询接口,用于:提供所述HOLAP系统中数据集的同一查询接口;
所述数据集分析模块,还用于:接收所述数据集查询接口发送的数据集的查询请求;将所述查询请求存储至所述查询记录模块。
18.根据权利要求14-16中任一项所述的系统,其特征在于,所述系统还包括多维联机分析处理MOLAP服务器和关系联机分析处理ROLAP服务器;
所述MOLAP服务器,用于:当所述目标数据集的实际物理化属性修改为具有物理特性时,将所述目标数据集转换为具有物理特性的数据集;
所述ROLAP服务器,用于:当所述目标数据集的实际物理化属性修改为具有虚拟特性时,将所述目标数据集转换为具有虚拟特性的数据集。
19.一种联机分析处理装置,其特征在于,包括:处理器、存储器和通信接口;
所述存储器用于存储计算机执行指令,所述处理器与所述存储器耦接,当所述联机分析处理装置运行时,所述处理器执行所述存储器存储的所述计算机执行指令,以使所述联机分析处理装置执行如权利要求1-8中任一项所述的联机分析处理方法。
CN201810291182.0A 2018-03-30 2018-03-30 一种联机分析处理方法、装置及系统 Active CN110555080B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201810291182.0A CN110555080B (zh) 2018-03-30 2018-03-30 一种联机分析处理方法、装置及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810291182.0A CN110555080B (zh) 2018-03-30 2018-03-30 一种联机分析处理方法、装置及系统

Publications (2)

Publication Number Publication Date
CN110555080A CN110555080A (zh) 2019-12-10
CN110555080B true CN110555080B (zh) 2023-02-14

Family

ID=68733614

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810291182.0A Active CN110555080B (zh) 2018-03-30 2018-03-30 一种联机分析处理方法、装置及系统

Country Status (1)

Country Link
CN (1) CN110555080B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111143411A (zh) * 2019-12-23 2020-05-12 跬云(上海)信息科技有限公司 动态流式预计算方法及装置、存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102663117A (zh) * 2012-04-18 2012-09-12 中国人民大学 面向数据库与Hadoop混合平台的OLAP查询处理方法
CN104361118A (zh) * 2014-12-01 2015-02-18 中国人民大学 一种适应协处理器的混合olap查询处理方法
EP2980707A1 (en) * 2014-07-31 2016-02-03 Deutsche Telekom AG Method for creating a database clone of a distributed database, system for creating a database clone of a distributed database, program and computer program product
CN106844703A (zh) * 2017-02-04 2017-06-13 中国人民大学 一种面向数据库一体机的内存数据仓库查询处理实现方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060195492A1 (en) * 2005-02-25 2006-08-31 Microsoft Corporation Method and apparatus for implementing an adaptive data warehouse

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102663117A (zh) * 2012-04-18 2012-09-12 中国人民大学 面向数据库与Hadoop混合平台的OLAP查询处理方法
EP2980707A1 (en) * 2014-07-31 2016-02-03 Deutsche Telekom AG Method for creating a database clone of a distributed database, system for creating a database clone of a distributed database, program and computer program product
CN104361118A (zh) * 2014-12-01 2015-02-18 中国人民大学 一种适应协处理器的混合olap查询处理方法
CN106844703A (zh) * 2017-02-04 2017-06-13 中国人民大学 一种面向数据库一体机的内存数据仓库查询处理实现方法

Also Published As

Publication number Publication date
CN110555080A (zh) 2019-12-10

Similar Documents

Publication Publication Date Title
CN113051351B (zh) 修剪索引以增强数据库查询处理
US20070226177A1 (en) Evaluating a current partitioning of a database
US11086841B1 (en) Streams on shared database objects
CN113632073B (zh) 数据源上的可扩展流
US11347730B1 (en) Object dependency tracking in a cloud database system
US11537613B1 (en) Merge small file consolidation
US11461327B1 (en) Query plan caching for networked database systems
US20230169202A1 (en) Cloud data sharing for applications
US9229969B2 (en) Management of searches in a database system
CN110555080B (zh) 一种联机分析处理方法、装置及系统
US20170293626A1 (en) Managing persistent database result sets
CN109844723B (zh) 使用基于服务的统计信息进行主控建立的方法和系统
WO2016092604A1 (ja) データ処理システムおよびデータアクセス方法
US11580082B2 (en) Object storage system with control entity quota usage mapping
US11204717B2 (en) Object storage system with access control quota status check
US11995080B1 (en) Runtime join pruning to improve join performance for database tables
US11734451B1 (en) Secure continuous compliance enforcement on a data exchange system
US11550793B1 (en) Systems and methods for spilling data for hash joins
US12007994B1 (en) Partition granular selectivity estimation for predicates
US11593306B1 (en) File defragmentation service
US11157205B2 (en) Object storage system with control entity quota enforcement
US20230222121A1 (en) Clustering and compaction of materialized views on a database system
US20240235942A1 (en) Efficient transfer of collected discovery data
CN115757863A (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
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20231219

Address after: 518054 Room 201, building A, 1 front Bay Road, Shenzhen Qianhai cooperation zone, Shenzhen, Guangdong

Patentee after: Huaban Payment (Shenzhen) Co.,Ltd.

Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen

Patentee before: HUAWEI TECHNOLOGIES Co.,Ltd.

TR01 Transfer of patent right