CN112269792A - 数据查询方法、装置、设备及计算机可读存储介质 - Google Patents
数据查询方法、装置、设备及计算机可读存储介质 Download PDFInfo
- Publication number
- CN112269792A CN112269792A CN202011452389.5A CN202011452389A CN112269792A CN 112269792 A CN112269792 A CN 112269792A CN 202011452389 A CN202011452389 A CN 202011452389A CN 112269792 A CN112269792 A CN 112269792A
- Authority
- CN
- China
- Prior art keywords
- query
- target
- data
- dimension
- result
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 83
- 238000003860 storage Methods 0.000 title claims abstract description 32
- 238000006116 polymerization reaction Methods 0.000 claims abstract description 161
- 238000013499 data model Methods 0.000 claims abstract description 123
- 238000004364 calculation method Methods 0.000 claims abstract description 42
- 235000019580 granularity Nutrition 0.000 claims abstract description 39
- 230000004044 response Effects 0.000 claims abstract description 17
- 238000001914 filtration Methods 0.000 claims description 98
- 238000005259 measurement Methods 0.000 claims description 31
- 230000014509 gene expression Effects 0.000 claims description 26
- 238000004590 computer program Methods 0.000 claims description 20
- 230000001174 ascending effect Effects 0.000 claims description 12
- 230000015654 memory Effects 0.000 claims description 11
- 239000002245 particle Substances 0.000 claims description 6
- 230000008569 process Effects 0.000 description 30
- 230000002776 aggregation Effects 0.000 description 24
- 238000004220 aggregation Methods 0.000 description 24
- 230000006870 function Effects 0.000 description 18
- 238000005516 engineering process Methods 0.000 description 17
- 238000010586 diagram Methods 0.000 description 10
- 238000013500 data storage Methods 0.000 description 9
- 238000012545 processing Methods 0.000 description 8
- 238000007726 management method Methods 0.000 description 6
- 101100042371 Caenorhabditis elegans set-3 gene Proteins 0.000 description 5
- 101150055297 SET1 gene Proteins 0.000 description 5
- 101150117538 Set2 gene Proteins 0.000 description 5
- 238000004458 analytical method Methods 0.000 description 4
- 239000000470 constituent Substances 0.000 description 4
- 238000013461 design Methods 0.000 description 4
- 230000006399 behavior Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 3
- 238000007405 data analysis Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 238000013179 statistical model Methods 0.000 description 3
- 238000004422 calculation algorithm Methods 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 238000013473 artificial intelligence Methods 0.000 description 1
- 125000003118 aryl group Chemical group 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000005553 drilling Methods 0.000 description 1
- 238000004880 explosion Methods 0.000 description 1
- 238000007667 floating Methods 0.000 description 1
- 238000007373 indentation Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 238000005096 rolling process Methods 0.000 description 1
Images
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/22—Indexing; Data structures therefor; Storage structures
- G06F16/2282—Tablespace storage structures; Management thereof
-
- 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/2425—Iterative querying; Query formulation based on the results of a preceding query
-
- 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/2428—Query predicate definition using graphical user interfaces, including menus and forms
-
- 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
- G06F16/244—Grouping and aggregation
-
- 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/24558—Binary matching operations
- G06F16/2456—Join operations
-
- 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/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- 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/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/283—Multi-dimensional databases or data warehouses, e.g. MOLAP or ROLAP
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Mathematical Physics (AREA)
- Computational Linguistics (AREA)
- Human Computer Interaction (AREA)
- Software Systems (AREA)
- Computing Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本申请公开了数据查询方法、装置、设备及计算机可读存储介质。方法包括:获取针对目标数据模型的数据查询请求;基于数据查询请求和目标数据模型对应的目标元数据,在目标数据模型对应的至少两个物理表中确定数据查询请求对应的目标物理表,至少两个物理表包括基础表和根据需求进行预聚合计算后得到的预聚合表,任一预聚合表用于记录至少两种粒度的数据;基于数据查询请求和目标物理表,获取数据查询请求对应的目标查询数据。基于此,无需根据维度的所有组合分别进行预聚合计算即可得到用于实现数据查询的物理表,计算量较小;利用一个预聚合表记录至少两种粒度的数据,能够有效减少数据库中存储的表的数量,有利于提升数据查询的响应速度。
Description
技术领域
本申请实施例涉及计算机领域,特别涉及一种数据查询方法、装置、设备及计算机可读存储介质。
背景技术
在大数据时代,对数据进行查询尤其重要,目前存在多种数据查询方法,基于ROLAP(Relational Online Analytical Processing,基于关系型数据库的在线联机分析处理)实现的数据查询方法是较为常用的一种提供决策服务的数据查询方法。ROLAP使用关系型数据库进行数据存储,利用关系型数据库中存储的表实现对数据的查询。
相关技术中,关系型数据库中存储的表为根据维度的所有组合分别进行预聚合计算后得到的汇总表,每个汇总表用于记录根据维度的一种组合进行预聚合计算后得到的一种粒度的数据。在此种过程中,预聚合计算的计算量较大,数据库中的存储的表的数量较多,数据存储量较大,导致数据查询的响应速度较慢。
发明内容
本申请实施例提供了一种数据查询方法、装置、设备及计算机可读存储介质,可用于提高数据查询的响应速度。
一方面,本申请实施例提供了一种数据查询方法,所述方法包括:
获取针对目标数据模型的数据查询请求;
基于所述数据查询请求和所述目标数据模型对应的目标元数据,在所述目标数据模型对应的至少两个物理表中确定所述数据查询请求对应的目标物理表,所述目标元数据基于所述至少两个物理表确定,所述至少两个物理表包括基础表和根据需求进行预聚合计算后得到的预聚合表,所述基础表用于记录基础数据,任一预聚合表用于记录至少两种粒度的数据;
基于所述数据查询请求和所述目标物理表,获取所述数据查询请求对应的目标查询数据。
另一方面,提供了一种数据查询装置,所述装置包括:
第一获取单元,用于获取针对目标数据模型的数据查询请求;
确定单元,用于基于所述数据查询请求和所述目标数据模型对应的目标元数据,在所述目标数据模型对应的至少两个物理表中确定所述数据查询请求对应的目标物理表,所述目标元数据基于所述至少两个物理表确定,所述至少两个物理表包括基础表和根据需求进行预聚合计算后得到的预聚合表,所述基础表用于记录基础数据,任一预聚合表用于记录至少两种粒度的数据;
第二获取单元,用于基于所述数据查询请求和所述目标物理表,获取所述数据查询请求对应的目标查询数据。
在一种可能实现方式中,所述数据查询请求携带待查询度量;所述确定单元,用于确定所述数据查询请求对应的逻辑维度集合;基于所述目标数据模型的模型标识和所述待查询度量,确定查询条件;在所述目标元数据中查询与所述查询条件匹配的第一查询结果,所述第一查询结果由至少一个查询子结果构成,任一查询子结果中包括所述目标数据模型对应的一个物理表的表标识;基于所述逻辑维度集合,对所述第一查询结果进行过滤,得到第二查询结果,将所述第二查询结果中满足选取条件的查询子结果作为目标查询子结果;将所述目标查询子结果中包括的表标识指示的物理表确定为所述数据查询请求对应的目标物理表。
在一种可能实现方式中,所述确定单元,还用于响应于所述数据查询请求还携带待查询维度,由所述待查询维度构成所述数据查询请求对应的逻辑维度集合;响应于所述数据查询请求还携带过滤条件信息,确定所述过滤条件信息对应的参考维度,由所述参考维度构成所述数据查询请求对应的逻辑维度集合;响应于所述数据查询请求还携带待查询维度和过滤条件信息,确定所述过滤条件信息对应的参考维度,将所述待查询维度和所述参考维度的并集作为所述数据查询请求对应的逻辑维度集合;响应于所述数据查询请求未携带待查询维度和过滤条件信息,将空集作为所述数据查询请求对应的逻辑维度集合。
在一种可能实现方式中,所述数据查询请求还携带待查询维度和过滤条件信息,所述任一查询子结果中还包括匹配维度和不可聚合维度;所述确定单元,还用于在所述第一查询结果中,将包括的匹配维度不满足第一条件的查询子结果删除,得到参考查询结果,所述不满足第一条件用于指示包括的匹配维度中不包含所述逻辑维度集合中的全部维度;在所述参考查询结果中,将包括的不可聚合维度不满足第二条件的查询子结果删除,得到第二查询结果,所述不满足第二条件用于指示包括的不可聚合维度中存在任一不可聚合维度既不属于所述待查询维度,也不属于所述过滤条件信息指示的单过滤条件对应的维度。
在一种可能实现方式中,所述第一查询结果中的查询子结果根据匹配维度数量升序排列,或者根据匹配维度数量降序排列;所述第二查询结果中的查询子结果的排列先后顺序与所述第一查询结果中对应的查询子结果的排列先后顺序相同;所述确定单元,还用于响应于所述第一查询结果中的查询子结果根据匹配维度数量升序排列,将所述第二查询结果中位于第一位的查询子结果作为目标查询子结果;响应于所述第一查询结果中的查询子结果根据匹配维度数量降序排列,将所述第二查询结果中位于最后一位的查询子结果作为目标查询子结果。
在一种可能实现方式中,所述第二获取单元,用于基于所述数据查询请求和所述目标物理表,确定目标结构化查询语句;在存储有所述目标物理表的数据库中,执行所述目标结构化查询语句,得到所述数据查询请求对应的目标查询数据。
在一种可能实现方式中,所述目标物理表为预聚合表;所述数据查询请求携带待查询维度、待查询度量和过滤条件信息;所述目标物理表为目标查询子结果中包括的表标识指示的物理表,所述目标查询子结果中还包括目标维度组合子集;所述第二获取单元,还用于基于所述待查询维度,确定维度查询语句;基于所述待查询度量,确定度量查询语句;基于所述过滤条件信息,确定过滤条件查询语句;基于所述目标物理表的表标识,确定物理表查询语句;基于所述目标维度组合子集和所述目标物理表对应的至少一个目标预聚合维度,确定维度约束查询语句;将所述维度查询语句对应的模型相关列、所述度量查询语句对应的模型相关列、所述过滤条件查询语句对应的模型相关列以及所述维度约束查询语句对应的模型相关列的并集作为目标模型相关列;基于所述目标模型相关列的表达式,确定模型相关列查询语句;基于所述维度查询语句、所述度量查询语句、所述过滤条件查询语句、所述物理表查询语句、所述维度约束查询语句和所述模型相关列查询语句,确定目标结构化查询语句。
在一种可能实现方式中,所述目标维度组合子集为基于所述至少一个目标预聚合维度确定的至少一个参考维度组合子集中的一个参考维度组合子集;所述第二获取单元,还用于将所述目标维度组合子集中的维度作为第一维度,确定所述第一维度对应的第一汇总标识符;确定所述至少一个目标预聚合维度中除所述第一维度外的第二维度对应的第二汇总标识符;将用于指示所述第一维度不具有所述第一汇总标识符,且所述第二维度具有所述第二汇总标识符的查询语句作为维度约束查询语句。
在一种可能实现方式中,所述目标物理表为第一类型的预聚合表,所述至少一个参考维度组合子集通过对所述至少一个目标预聚合维度进行任意组合得到;或者,所述目标物理表为第二类型的预聚合表,所述至少一个参考维度组合子集通过对所述至少一个目标预聚合维度进行分层组合得到;或者,所述目标物理表为第三类型的预聚合表,所述至少一个参考维度组合子集通过对所述至少一个目标预聚合维度进行单独组合得到。
在一种可能实现方式中,所述目标物理表中记录的数据的粒度的数量与所述至少一个参考维度组合子集的数量相同。
在一种可能实现方式中,所述装置还包括:
第三获取单元,用于获取所述目标数据模型对应的至少两个物理表;基于所述至少两个物理表,确定所述目标数据模型对应的目标元数据;
存储单元,用于对所述至少两个物理表和所述目标元数据进行存储。
另一方面,提供了一种计算机设备,所述计算机设备包括处理器和存储器,所述存储器中存储有至少一条计算机程序,所述至少一条计算机程序由所述处理器加载并执行,以实现上述任一所述的数据查询方法。
另一方面,还提供了一种计算机可读存储介质,所述计算机可读存储介质中存储有至少一条计算机程序,所述至少一条计算机程序由处理器加载并执行,以实现上述任一所述的数据查询方法。
另一方面,还提供了一种计算机程序产品或计算机程序,所述计算机程序产品或计算机程序包括计算机指令,所述计算机指令存储在计算机可读存储介质中。计算机设备的处理器从所述计算机可读存储介质读取所述计算机指令,处理器执行所述计算机指令,使得所述计算机设备执行上述任一所述的数据查询方法。
本申请实施例提供的技术方案至少带来如下有益效果:
在本申请实施例中,数据查询的实现过程依赖目标数据模型对应的至少两个物理表,目标数据模型对应的至少两个物理表包括基础表和根据需求进行预聚合计算后得到的预聚合表。也就是说,无需根据维度的所有组合分别进行预聚合计算即可得到用于实现数据查询的物理表,预聚合计算量较小。此外,利用一个预聚合表记录至少两种粒度的数据,能够有效减少数据库中存储的表的数量,减少数据存储量,有利于提升数据查询的响应速度。
附图说明
为了更清楚地说明本申请实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的一种数据查询方法的实施环境的示意图;
图2是本申请实施例提供的一种数据查询方法的流程图;
图3是本申请实施例提供的一种数据查询平台的界面示意图;
图4是本申请实施例提供的一种数据查询过程的示意图;
图5是本申请实施例提供的一种目标结构化查询语句的示意图;
图6是本申请实施例提供的一种数据查询装置的示意图;
图7是本申请实施例提供的一种数据查询装置的示意图;
图8是本申请实施例提供的一种服务器的结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合附图对本申请实施方式作进一步地详细描述。
对本申请实施例中涉及的若干个名词进行解释。
SQL(Structured Query Language,结构化查询语言):即结构化数据的查询语言,在关系数据库中查询数据使用。
OLAP(Online Analytical Processing,在线联机分析处理):是一种数据库应用方式,它是对用户透明的,即用户只需要将它看待成普通的数据库引擎向它发送查询请求即可。而对于OLAP引擎来讲,除了需要将细粒度的数据进行存储外,还需要提前对细粒度的数据预聚合,在数据库中冗余存储,以此来实现“空间换时间”,从而让查询速度更快。
ROLAP(Relational OLAP,基于关系型数据库的OLAP):使用关系型数据库(Relational Database,RDB)进行数据存储,它将预聚合数据以多个表的形式存储在RDB中。它将用户的OLAP操作转换成SQL,然后提交到数据库中执行;为了缩短查询响应时间,它会根据用户操作的维度和度量将SQL查询定位到最合适的表上去。其中,预聚合数据是指事先按不同粒度计算好的汇总数据;OLAP操作是指对数据的查询请求,如上卷、下钻、过滤、合并等。本申请实施例中提供的数据查询方法为一种ROLAP解决方案,即一种基于关系型数据库的在线联机分析处理解决方案。
在一些实施例中,本申请实施例提供的数据查询方法能够应用在云技术领域中,用于存储数据的数据库为云技术下的数据库。在介绍本申请实施例之前,需要引入一些云技术领域内的基本概念。
云技术(Cloud Technology):是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来,实现数据的计算、储存、处理和共享的一种托管技术。云技术是基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称,可以组成资源池,按需所用,灵活便利。云计算技术将变成云技术领域的重要支撑。技术网络系统的后台服务需要大量的计算、存储资源,如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用,将来每个物品都有可能存在自己的识别标志,都需要传输到后台系统进行逻辑处理,不同程度级别的数据将会分开处理,各类行业数据皆需要强大的系统后盾支撑,需要通过云计算来实现。
云存储(Cloud Storage):是在云计算概念上延伸和发展出来的一个新的概念,分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能,将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作,共同对外提供数据存储和业务访问功能的一个存储系统。
数据库(Database):简而言之可视为电子化的文件柜——存储电子文件的处所,用户可以对文件中的数据进行新增、查询、更新、删除等操作。所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。
数据库管理系统(Database Management System,DBMS)是为管理数据库而设计的电脑软件系统,一般具有存储、截取、安全保障、备份等基础功能。数据库管理系统可以依据它所支持的数据库模型来作分类,例如关系式、XML(Extensible Markup Language,即可扩展标记语言);或依据所支持的计算机类型来作分类,例如服务器集群、移动电话;或依据所用查询语言来作分类,例如SQL、XQuery(XML查询语言);或依据性能冲量重点来作分类,例如最大规模、最高运行速度;亦或其他的分类方式。不论使用哪种分类方式,一些DBMS能够跨类别,例如,同时支持多种查询语言。
在一些实施例中,本申请实施例提供的数据查询方法能够应用在区块链技术领域中,用于存储数据的数据库为基于区块链技术的数据库系统(以下简称为“区块链系统”)中的数据库。上述区块链系统在本质上属于一种去中心化式的分布式数据库系统,采用共识算法保持区块链上不同节点设备所记载的账本数据一致,通过密码算法保证不同节点设备之间账本数据的加密传送以及不可篡改,通过脚本系统来拓展账本功能,通过网络路由来进行不同节点设备之间的相互连接。
在区块链系统中可以包括一条或多条区块链,区块链是一串使用密码学方法相关联产生的数据块,每一个数据块中包含了一批次网络交易的信息,用于验证其信息的有效性(防伪)和生成下一个区块。
区块链系统中的节点设备之间可以组成点对点(Peer To Peer,P2P)网络,P2P协议是一个运行在传输控制协议(Transmission Control Protocol,TCP)之上的应用层协议。在区块链系统中,任一节点设备可以具备如下功能:1)路由,节点设备具有的基本功能,用于支持节点设备之间的通信;2)应用,用于部署在区块链中,根据实际业务需求而实现特定业务,记录实现功能相关的数据形成账本数据,在账本数据中携带数字签名以表示数据来源,将账本数据发送至区块链系统中的其他节点设备,供其他节点设备在验证账本数据来源以及完整性成功时,将账本数据添加至临时区块中,其中,应用实现的业务可以包括钱包、共享账本、智能合约等;3)区块链,包括一系列按照先后的时间顺序相互接续的区块,新区块一旦加入到区块链中就不会再被移除,区块中记录了区块链系统中节点设备提交的账本数据。
在一些实施例中,每个区块中可以包括本区块存储交易记录的哈希值(本区块的哈希值)以及前一区块的哈希值,各区块通过哈希值连接形成区块链。另外,区块中还可以包括有区块生成时的时间戳等信息,区块中还可以包括本申请实施例中涉及的元数据以及物理表等。
本申请实施例提供了一种数据查询方法,请参考图1,其示出了本申请实施例提供的数据查询方法的实施环境的示意图。该实施环境包括:终端101和服务平台102。其中,服务平台102包括服务器1021和数据库1022。服务器1021用于获取数据查询请求对应的目标查询数据,数据库1022用于存储元数据和物理表。需要说明的是,本申请实施例对数据库1022的数量不加以限定,用于存储元数据的数据库和用于存储物理表的数据库可以为同一个数据库,也可以为不同的数据库。
终端101能够将数据查询请求发送至服务平台102中的服务器1021上,也能够接收服务平台102中的服务器1021返回的目标查询数据。服务器1021能够接收终端101发送的数据查询请求,也能够从数据库1022中获取目标数据模型对应的目标元数据和数据查询请求对应的目标查询数据,还能够将目标查询数据返回至终端101。
在一种可能实现方式中,终端101是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等,但并不局限于此。服务器1021可以是独立的物理服务器,也可以是多个物理服务器构成的服务器集群或者分布式系统,还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(ContentDelivery Network,内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。终端101以及服务器1021可以通过有线或无线通信方式进行直接或间接地连接,本申请在此不做限制。
本领域技术人员应能理解上述终端101和服务平台102仅为举例,其他现有的或今后可能出现的终端或服务平台如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
基于上述图1所示的实施环境,本申请实施例提供一种数据查询方法,以该方法应用于服务平台102中的服务器1021为例。如图2所示,本申请实施例提供的方法包括如下步骤201至步骤203。
在步骤201中,获取针对目标数据模型的数据查询请求。
数据查询请求用于指示用户的数据查询意图,数据查询请求由终端获取并发送给服务器,由此,服务器通过接收终端发送的数据查询请求,获取到数据查询请求。示例性地,本申请实施例中的终端是指数据查询平台的前端,服务器是指数据查询平台的后台查询引擎,例如,在ROLAP场景下,服务器可视为ROLAP引擎。
目标数据模型是指终端提供的一种或多种数据模型中被选中的数据模型。终端提供的数据模型可视为数据查询平台的前端提供的供用户选择的数据模型。在本申请实施例中,数据模型是提供数据查询服务的基本实体,类似于数据库中的表。针对目标数据模型的数据查询请求用于指示需要在目标数据模型下进行数据查询。
数据模型的基本组成单元是列,列可分为维度列和度量列,一个数据模型可以包含任意数量的维度列和度量列。数据模型类似于数据仓库中“主题”的概念,数据模型涉及的数据可以来自一个或多个表,每个表可以提供不同的维度与度量。在一个数据模型里,不同表的度量和维度,有相同的计算逻辑,以保持数据一致性。数据模型的底层实现细节,对查询数据的用户是透明的。查询数据时,用户无需关心数据模型的底层细节,只需表达清楚需要查询的数据模型即可。
本申请实施例对终端提供的供用户选择的数据模型的设置方式不加以限定,示例性地,数据模型根据数据查询平台能够提供的数据分析功能进行设置,不同的数据分析功能对应不同的数据查询模型。
在一种可能实现方式中,数据查询请求携带待查询维度、待查询度量和过滤条件信息。待查询维度是指用户选择的维度,维度是指观察数据的角度;待查询度量是指用户选择的度量,度量是指被观察的统计值;过滤条件信息用于指示用户选择的过滤条件。
在示例性实施例中,数据查询请求携带的待查询度量有且仅有一个。在示例性实施例中,数据查询请求不携带任何待查询维度,也即说明用户没有选择任何维度。在示例性实施例中,数据查询请求不携带任何过滤条件信息,也即说明用户没有选择任何过滤条件。
针对目标数据模型的数据查询请求由终端根据用户在数据查询平台上的选择操作确定。用户可以根据自身需要,对维度和度量用鼠标进行拖拽操作,从而实现对各种粒度的数据查询,而不是像普通固定报表那样,只能查询固定粒度的数据。本申请实施例以数据模型作为提供数据查询的基本实体,用户进行数据查询前,应先指定是哪个数据模型。数据模型的底层细节对用户是隐藏的,对用户可见的是数据模型中的维度与度量。
例如,数据查询平台的界面示意图如图3所示,在图3中,用户指定的数据模型(即目标数据模型)为用户行为统计模型,该用户行为统计模型中的度量包括文章点击pv(pageview,页面浏览量),文章点击uv(unique visitor,独立访客数量)和人均点击pv。该用户行为统计模型中的维度包括日期、用户ID、用户性别、用户年龄、文章ID、文章类型、文章品类和文章来源。用户选择的度量包括文章点击pv、文章点击uv和人均点击pv,用户选择的维度包括日期和用户性别,用户选择的过滤条件包括对日期和用户年龄的约束。在用户点击图3中的“查询”按钮301后,终端获取针对目标数据模型的数据查询请求。
本申请实施例对数据查询请求的表现形式不加以限定,只要能够准确表达用户的查询意图即可。示例性地,本申请实施例提出一种逻辑SQL的表现形式来描述用户的数据查询请求。
逻辑SQL不能直接用来在RDB里执行,需要转换成数据库能够识别的物理SQL才可以,所以称其为逻辑SQL。示例性地,逻辑SQL利用JSON(JavaScript Object Notation,JS对象简谱)格式来表示,逻辑SQL的格式如下所示。
在上述逻辑SQL的格式中,“SELECT”(选择)、“Selected_Dim_List”(选择的维度)、“Selected_Measure”(选择的度量)、“FROM”(从)以及“WHERE”(位置)均为关键字。${Selected_Dim_List}、${Selected_Measure}、${Model_ID}和${Filter}是指需要填充的部分,接下来对需要填充的4个部分分别进行介绍。
${Selected_Dim_List}:一个数组,用于表示用户选择的维度,数组中可以有一个或多个维度,也可以为空。当为空时,表示用户没有选择任何维度。本申请实施例中将用户选择的维度称为待查询维度。
${Selected_Measure}:一个字符串,用于表示用户选择的度量,在本申请实施例中要求有且只有一个度量。本申请实施例中将用户选择的度量称为待查询度量。
${Model_ID}:一个字符串,用于表示用户想要查询的目标数据模型的模型标识。
${Filter}:一个JSON,用于表示用户选择的过滤条件,它是个嵌套结构。这个JSON里有2个成员,AND_OR(过滤条件间的关系)与Filter_List(过滤条件列表)。Filter_List是一个数组,里面的成员可以是具体的SQL过滤表达式,也可以是个${Filter}。根据用户的实际情况,${Filter}部分可以为空,空表示用户没有选择任何过滤条件。
示例性地,数据查询请求的一个实例如下所示。
上述数据查询请求的实例表示这样一个查询意图:查询123号模型中,20200701这天20到30岁的用户在各文章品类上的“人均点击pv”。
在步骤202中,基于数据查询请求和目标数据模型对应的目标元数据,在目标数据模型对应的至少两个物理表中确定数据查询请求对应的目标物理表,至少两个物理表包括基础表和根据需求进行预聚合计算后得到的预聚合表,任一预聚合表用于记录至少两种粒度的数据。
其中,目标元数据基于至少两个物理表确定,基础表用于记录基础数据。
在获取数据查询请求后,服务器基于数据查询请求和目标数据模型对应的目标元数据,在目标数据模型对应的至少两个物理表中确定数据查询请求对应的目标物理表。目标数据模型对应的目标元数据是基于目标数据模型对应的至少两个物理表确定的,目标数据模型对应的目标元数据用于对目标数据模型进行详细描述。目标数据模型对应的至少两个物理表是指用于实现目标数据模型的表。在本申请实施例中,目标数据模型对应的至少两个物理表包括基础表和根据需求进行预聚合计算得到的预聚合表,基础表用于记录基础数据,任一预聚合表用于记录至少两种粒度的数据。示例性地,数据的粒度的粗细用于指示涉及的维度的数量的多少,涉及的维度的数量越多,数据的粒度越细。
在一种可能实现方式中,基础表是指数据仓库中常规意义上的事实表,用于记录未进行任何预聚合计算的基础数据,每个基础表用于记录一种粒度的数据。本申请实施例对目标数据模型对应的至少两个物理表中包括的基础表和预聚合表的数量不加以限定,也就是说,至少两个物理表中可能包括一个或多个基础表,以及一个或多个预聚合表。
示例性地,目标数据模型对应的至少两个物理表中包括的基础表中至少存在一个最细粒度的基础表,该最细粒度的基础表能够提供用户所需的一切维度和度量,也可以提供任意维度组合的度量查询结果。除该最细粒度的基础表外,目标数据模型对应的至少两个物理表中还可能包括一个或多个根据需求确定的基础表,本申请实施例对此不加以限定。目标数据模型对应的至少两个物理表中还包括一个或多个根据需求进行预聚合计算后得到的预聚合表。示例性地,需求由用户通过终端发送,或者由服务器根据用户的历史查询记录分析得到,本申请实施例对此不加以限定,需求能够指示出用户经常需要查询的维度以及度量等信息。需要说明的是,根据需求进行预聚合计算得到预聚合表的过程可以由开发人员人工进行,也可以由编写的程序自动执行,本申请实施例对此不加以限定。
目标数据模型对应的至少两个物理表中的基础表和预聚合表,开发人员可以根据实际的需求来自行决定,不限表个数。每个表可以是不同的维度与度量组合。这样一来,N(N为不小于1的整数)个维度的汇总,就不需要聚合2N次,这极大地降低了度量聚合的计算量和数据存储量。
在实现步骤202之前,需要先获取目标数据模型对应的至少两个物理表,然后根据目标数据模型对应的至少两个物理表,确定目标数据模型对应的目标元数据,对至少两个物理表和目标元数据进行存储。在一种可能实现方式中,对至少两个物理表和所述目标元数据进行存储的过程为:将目标数据模型对应的至少两个物理表存储在第一数据库中,将目标元数据存储在第二数据库中。第一数据库和第二数据库可以为同一个数据库,也可以为不同的数据库,本申请实施例对此不加以限定。本申请实施例以第一数据库和第二数据库为不同的数据库为例进行说明,示例性地,第一数据库还称为关系数据库,第二数据库还称为元数据库。
在示例性实施例中,服务器能够基于数据查询请求,从用于存储元数据的元数据库中获取目标数据模型对应的目标元数据。
ROLAP是由存储在RDB中的多个物理表来实现的,但这物理表以及表物理之间的关系对用户是隐藏的,对用户可见的只有数据模型的维度列与度量列。将这多个物理表映射成为一个数据模型,就需要在元数据库里进行。元数据库是指存储数据模型对应的元数据的库,数据模型对应的元数据包括数据模型信息、物理表信息、列信息等。服务器依赖元数据库实现数据查询。
数据模型对应的元数据的形式根据经验设置,或者根据应用场景灵活调整,本申请实施例对此不加以限定,只要能够使服务器能够基于元数据实现数据查询业务即可。在示例性实施例中,数据模型对应的元数据利用按照下表1至表6指示的格式分别生成的六个元数据表进行表示。
其中,按照表1指示的格式生成的元数据表用于描述数据模型的列组成,标明列是维度还是度量。按照表2指示的格式生成的元数据表用于定义数据模型中每列的物理表来源,以及其计算表达式。按照表3指示的格式生成的元数据表用于确定数据模型中的度量对应的可聚合维度与不可聚合维度。在不同的物理表中,其对应的可聚合维度与不可聚合维度,可以相同,也可以不同。按照表4指示的格式生成的元数据表用于描述组成数据模型的物理表有哪些,以及它们的类型,其中group表示基础表,cube表示第一类型的预聚合表,rollup表示第二类型的预聚合表,groupingsets表示第三类型的预聚合表。示例性地,按照表1至表4指示的格式生成的元数据表均由开发人员根据实际的物理表进行填充得到。
按照表5指示的格式生成的元数据表用于描述数据模型由哪些子表组成,每个子表对应一种粒度,示例性地,按照表5指示的格式生成的元数据表依赖于按照表4指示的格式生成的元数据表生成,生成过程可以为根据编写的程序自动推算生成。按照表6指示的格式生成的元数据表用于描述子表中的各个度量的不可聚合维度,示例性地,按照表6指示的格式生成的元数据表依赖于按照表3和5指示的格式生成的元数据表生成,生成过程可以为根据编写的程序自动推算生成。
接下来,对上述表1至表6中涉及的相关概念进行介绍。
(1)关于维度列与度量列的介绍。
列,也被称为字段,是关系数据库中表的基本组成单位。一个表由多个列组成,列分为不同的数据类型,比如int、string等。但在本申请中,除了作为表的基本组成单位,列也是数据模型的基本组成单位,数据模型的列是一个逻辑的概念,需要通过一定的计算逻辑映射到表的物理列上。列分为两类:维度列与度量列。
维度,原是数据仓库设计中的概念,由主键及相关属性组成。例如,在表7所示的用户维度中,user_id列是维度主键,user_sex、user_name、user_age和user_city这4列是维度属性。在本申请中,将这5列统称为维度列。
度量,是与维度相对应的概念,它是数值型的统计量,比如pv、uv、duration(持续时间)等。例如,在表8中,date、user_sex和article_type列是维度列,read_duration列是度量列。例如,以一款资讯类的手机应用程序为例,在用户在该应用程序中点击资讯文章进行浏览的场景下,uv是指点击文章的用户数,需要对用户去重计算;pv是指用户的文章点击次数;duration是指用户的文章阅读时长。
(2)关于度量的可聚合与不可聚合的介绍。
可聚合与不可聚合,都是针对度量来说的。它跟具体的维度有关,也跟具体的表有关。需要说明的是,度量的预聚合计算是在该度量的可聚合维度下进行的预聚合计算。接下来,结合下述表9和表10的实例对度量的可聚合和不可聚合进行说明。
在上述表9和表10中,pv与uv是度量列,其他列是维度列。以从这2个表中用SQL查询语句查询uv为例。当从表9中查询时,能够使用sum(uv)函数查询,但只能在user_sex(性别)维度上进行汇总,不能在date(日期)维度上汇总。因为一个user_id(用户标识)只对应一个user_sex,男性(male)用户数加女性(female)用户数等于总用户数,这不会涉及user_id重复计算问题,也就是说,user_sex维度上不会有user_id重复的问题。而date维度上是有user_id重复的。所以,uv对于表9中的date维度是不可聚合的,而对于user_sex维度是可聚合的,即度量是否可聚合跟具体的维度有关。
当从表10中查询时,情况就不一样了。不管是在哪个维度上求汇总,都可以使用count(distinct user_id)这个聚合函数,因为它是去重计算,不会有user_id重复计算的问题。所以,uv对于表10中的date维度是可聚合的,即度量是否可聚合跟具体的表有关。
(3)关于基础表与预聚合表的介绍。
本申请所说的表,即是指数据库中的物理表。在本申请中,为了优化存储提出了基础表和预聚合表的存储方式。
基础表,是数据仓库中常规意义上的事实表,由维度列与度量列组成。例如,在表11所示的基础表中,维度列为date_id(日期标识)、user_sex和article_type(文章类型),度量列为pv。维度集合{date_id, user_sex, article_type},就是该表11的粒度表示。一个基础表中,只存储一种粒度的数据。
预聚合表,与基础表不同,其目的是在一个表中同时存储多种粒度的数据。不同的粒度,以维度列上的汇总标识符来区别。在示例性实施例中,汇总标识符根据不同的数据类型做相应的约定,例如,string型对应的汇总标识符为TOTAL;int型对应的汇总标识符为99999999;日期型对应的汇总标识符为2099-12-31。在实际开发中,需要将这些汇总标识符定义为关键字,避免与真实数据混淆。例如,在表12所示的预聚合表中,user_sex列和article_type列是具有汇总标识符TOTAL的。表12中的第3行数据的意义为:20200413这天所有男性对应的uv为1105;表12中的第7行数据的意义为:20200413这天的图文文章对应的uv为1022;表12中的第9行数据的意义为:20200413这天对应的总uv为1708。
在示例性实施例中,预聚合表可能具有一种或多种类型,不同的类型具有不同的维度组合方式。在一种可能实现方式中,预聚合表的类型有三种,分别为第一类型(记为cube)、第二类型(记为rollup)和第三类型(记为groupingsets)。示例性地,cube、rollup和groupingsets与Hive_SQL(基于Hadoop的一个数据仓库工具中的SQL查询语句)中相应的汇总关键字相对应。
示例性地,在不同的类型下,对于同一个预聚合维度列表{D1, D2, …, DN}中的预聚合维度进行组合的方式不同,在不同的组合方式下,得到的维度组合子集也不同。
在第一类型cube下,对预聚合维度列表中的预聚合维度进行任意组合。当预聚合维度列表中的预聚合维度的数量为N(N为不小于1的整数)时,任意组合后得到的维度组合子集的数量是2N个。例如,假设预聚合维度列表中的预聚合维度为D2和D3,则对预聚合维度列表中的预聚合维度进行任意组合后得到的维度组合子集的数量为4个,分别为{}、{D2}、{D3}和{D2, D3},其中,{}表示空集,表示不在D2和D3维度上进行预聚合计算;{D2}表示在D2维度上进行预聚合计算;{D3}表示在D3维度上进行预聚合计算;{D2, D3}表示在D2和D3维度上进行预聚合计算。
示例性地,假定维度的汇总标识符均为TOTAL,对于第一类型cube的预聚合表而言,SQL查询语句select D1, D2, D3, sum(pv) from t group by D1, cube(D2, D3),等价于下述语句。
在第二类型rollup下,对预聚合维度列表中的预聚合维度进行分层组合,当预聚合维度列表中的预聚合维度的数量为N(N为不小于1的整数)时,分层组合后得到的维度组合子集的数量是N+1个。例如,假设预聚合维度列表中的预聚合维度为D2和D3,则对预聚合维度列表中的预聚合维度进行分层组合后得到的维度组合子集的数量为3个,分别为{}、{D2}和{D2, D3}。
示例性地,假定维度的汇总标识符均为TOTAL,对于第二类型rollup的预聚合表而言,SQL查询语句select D1, D2, D3, sum(pv) from t group by D1, rollup(D2, D3),等价于下述语句。
在第三类型groupingsets下,对预聚合维度列表中的预聚合维度进行单独组合,当预聚合维度列表中的预聚合维度的数量为N(N为不小于1的整数)时,单独组合得到的维度组合子集的数量是N个。例如,假设预聚合维度列表中的预聚合维度为D2和D3,则对预聚合维度列表中的预聚合维度进行单独组合后得到的维度组合子集的数量为2个,分别为{D2}和{D3}。
示例性地,假定维度的汇总标识符均为TOTAL,对于第三类型groupingsets的预聚合表而言,SQL查询语句select D1, D2, D3, sum(pv) from t group by D1,groupingsets(D2, D3),等价于下述语句。
在示例性实施例中,对于预聚合表,除了需要指明其预聚合的类型(如,cube、rollup、groupingsets)外,还应明确其预聚合维度列表,即明确其对应的至少一个预聚合维度。示例性地,预聚合维度列表是指在Hive_SQL中的汇总关键字后面的维度列表,比如,上述SQL查询语句中的cube(D2, D3)、rollup(D2, D3)和groupingsets(D2, D3)均指示{D2, D3}为预聚合维度列表。
(4)关于子表的介绍。
本申请实施例中所称的子表,是一种逻辑概念,并非真实存在于数据库中的物理表,其目的是提供元数据服务。它主要是对于预聚合表来说的,用于描述其记录的数据的粒度,一个子表对应一种粒度。一个预聚合表对应的子表的数量等于该预聚合表记录的数据的粒度的数量,也即预聚合维度列表对应的维度组合子集的数量。也就是说,预聚合表用于记录的数据的粒度的数量与预聚合表对应的预聚合维度列表对应的维度组合子集的数量相同,一个维度组合子集对应一种粒度的数据。
示例性地,对于第一类型cube的预聚合表,假设预聚合维度列表为{D2, D3},则该预聚合表对应的子表的信息如表13所示(假定汇总标识符为TOTAL)。
由上述表13可知,对于第一类型cube的预聚合表而言,在预聚合维度列表为{D2,D3}的情况下,该预聚合表对应4个子表。子表能够利用父表加上“汇总表示”的限制进行表示。例如,对于子表z1,由如下方式进行表示:SELECT * FROM父表 WHERE D2 = ‘TOTAL’AND D3 = ‘TOTAL’。
在示例性实施例中,汇总表示的生成规则为:维度组合子集中的维度不具有汇总标识符(如,TOTAL),预聚合维度列表中的其他维度具有汇总标识符(如,TOTAL)。
需要说明的是,对于物理表中的基础表,由于一个基础表只记录一种粒度的数据,所以基础表对应的子表就是基础表自身,因此,基础表的汇总表示为空。
在预先存储好目标数据模型对应的至少两个物理表以及目标数据模型对应的目标元数据的前提下,服务器基于数据查询请求和目标数据模型对应的目标元数据,在目标数据模型对应的至少两个物理表中确定目标数据查询请求对应的目标物理表。目标物理表为目标数据模型对应的至少两个物理表中能够最快响应数据查询请求的物理表。目标物理表可能是指基础表,也可能是指预聚合表,这与数据查询请求以及至少两个物理表的实际情况有关。
在一种可能实现方式中,数据查询请求携带待查询度量,基于数据查询请求和目标数据模型对应的目标元数据,在目标数据模型对应的至少两个物理表中确定数据查询请求对应的目标物理表的过程包括以下步骤2021至步骤2024。
步骤2021:确定数据查询请求对应的逻辑维度集合。
逻辑维度集合是指数据查询请求涉及到的维度的集合。确定数据查询请求对应的逻辑维度集合的方式与数据查询请求携带的信息有关。在一种可能实现方式中,数据查询请求除携带待查询度量外,还包括以下4种情况:数据查询请求还携带待查询维度;数据查询请求还携带过滤条件信息;数据查询请求还携带待查询维度和过滤条件信息;数据查询请求未携带待查询维度和过滤条件信息。
在不同的情况下,确定数据查询请求对应的逻辑维度集合的方式不同。在一种可能实现方式中,确定数据查询请求对应逻辑维度集合的方式为:响应于数据查询请求还携带待查询维度,由待查询维度构成数据查询请求对应的逻辑维度集合;响应于数据查询请求还携带过滤条件信息,确定过滤条件信息对应的参考维度,由参考维度构成数据查询请求对应的逻辑维度集合;响应于数据查询请求还携带待查询维度和过滤条件信息,确定过滤条件信息对应的参考维度,将待查询维度和参考维度的并集作为数据查询请求对应的逻辑维度集合;响应于数据查询请求未携带待查询维度和过滤条件信息,将空集作为数据查询请求对应的逻辑维度集合。
其中,过滤条件信息用于指示用户对数据查询过程做的约束,过滤条件信息对应的参考维度是指在过滤条件信息中被约束的维度,通过对过滤条件信息进行解析即可确定过滤条件信息对应的参考维度。
示例性地,对于数据查询请求利用逻辑SQL进行表示的情况,从逻辑SQL中的${Selected_Dim_List}和${Filter}中识别出所有的维度,得到逻辑维度集合,将逻辑维度集合记为${Column_Set}。
步骤2022:基于目标数据模型的模型标识和待查询度量,确定查询条件;在目标元数据中查询与查询条件匹配的第一查询结果,第一查询结果由至少一个查询子结果构成,任一查询子结果中包括目标数据模型对应的一个物理表的表标识。
查询条件基于目标数据模型的模型标识和待查询度量确定,用于指示在目标元数据中需要查询的信息。例如,目标数据模型的模型标识记为${Model_ID},待查询度量记为${Selected_Measure},则查询条件基于${Model_ID}和${Selected_Measure}确定。
本申请实施例对查询条件的表现形式不加以限定,示例性地,查询条件的表现形式为SQL查询语句。在示例性实施例中,对于查询条件的表现形式为SQL查询语句的情况,基于目标数据模型的模型标识和待查询度量确定的查询条件与目标元数据的表示方式有关。例如,以目标元数据利用按照表1至表6指示的格式分别生成的六个元数据表进行表示为例,基于${Model_ID}和${Selected_Measure}确定的查询条件利用下述SQL查询语句表示。
在上述SQL查询语句中,SELECT、FROM、JOIN、AND、WHERE、ORDER BY以及ASC均为SQL中的关键字,上述SQL查询语句中涉及的相关语句的含义均能够根据按照表5指示的格式生成的元数据表以及按照表6指示的格式生成的元数据表确定,此处不再赘述。例如,m5.table_name表示按照表5指示的格式生成的元数据表中的物理表的表名。在本申请实施例中,以表标识为表名为例进行说明。m6.non_aggr_dims表示按照表6指示的格式生成的元数据表中的度量对应的不可聚合维度列表。需要说明的是,语句“ORDER BY m5.sub_table_dims_cnt ASC”表示根据按照表5指示的格式生成的元数据表中的子表中的维度数量进行升序排列。需要说明的是,以上所述SQL查询语句仅为查询条件的一种示例性表示方式,本申请实施例并不局限于此。
示例性地,在目标元数据中查询与查询条件匹配的第一查询结果的过程为在按照表5指示的格式生成的元数据表以及按照表6指示的格式生成的元数据表中查询与查询条件匹配的第一查询结果。将第一查询结果记为Rows_Set_1。第一查询结果由至少一个查询子结果构成,任一查询子结果包括目标数据模型对应的一个物理表的表标识。构成第一查询结果的查询子结果的数量取决于实际情况。本申请实施例对任一查询子结果中包括的表标识的类型不加以限定,示例性地,本申请实施例中,任一查询子结果中包括的表标识为表名,该表名即为按照表5指示的格式生成的元数据表中的物理表的表名。
在一种可能实现方式中,任一查询子结果均对应一个子表,任一查询子结果中还包括匹配维度和不可聚合维度。其中,匹配维度是指任一查询子结果对应的子表中的所有维度,不可聚合维度是指该任一查询子结果对应的子表中的度量在子表中的不可聚合维度。示例性地,查询子结果中包括的匹配维度是指按照表5指示的格式生成的元数据表中的sub_table_all_dims列下的数据。查询子结果中包括的不可聚合维度是指按照表6指示的格式生成的元数据表中的non_aggr_dims列下的数据。不同的查询子结果中包括的匹配维度可能相同,也可能不同;不同的查询子结果中包括的不可聚合维度可能相同,也可能不同。
在一种可能实现方式中,第一查询结果中的查询子结果根据匹配维度数量升序排列,或者根据匹配维度数量降序排列,本申请实施例对此不加以限定。匹配维度数量是指查询子结果中包括的匹配维度的数量。在示例性实施例中,不同的查询子结果对应的匹配维度数量可能相同,在根据匹配维度数量升序排列或者根据匹配维度数量降序排列的过程中,对应相同的匹配维度数量的查询子结果随机排列或者根据参考方式进行排列,本申请实施例对此不加以限定。
步骤2023:基于逻辑维度集合,对第一查询结果进行过滤,得到第二查询结果,将第二查询结果中满足选取条件的查询子结果作为目标查询子结果。
第一查询结果中可能存在无法实现数据查询请求对应的数据查询业务的查询子结果,所以需要基于逻辑维度集合对第一查询结果进行过滤,得到第二查询结果。在一种可能实现方式中,对于数据查询请求还携带待查询维度和过滤条件信息,任一查询子结果中还包括匹配维度和不可聚合维度的情况,基于逻辑维度集合,对第一查询结果进行过滤,得到第二查询结果的过程包括以下步骤2023a和步骤2023b。
步骤2023a:在第一查询结果中,将包括的匹配维度不满足第一条件的查询子结果删除,得到参考查询结果,不满足第一条件用于指示包括的匹配维度中不包含逻辑维度集合中的全部维度。
第一查询结果中的每个查询子结果中均包括匹配维度,根据包括的匹配维度对第一查询结果中的查询子结果进行初步过滤。在根据包括的匹配维度对第一查询结果中的查询子结果进行初步过滤的过程中,将包括的匹配维度不包含逻辑维度集合中的全部维度的查询子结果删除。在将包括的匹配维度不包含逻辑维度集合中的全部维度的查询子结果删除后,得到参考查询结果。
也就是说,从第一查询结果Rows_Set_1中删除掉包括的匹配维度不包含逻辑维度集合中全部维度的查询子结果,得到参考查询结果(记为Rows_Set_2)。即检查Rows_Set_1中各个查询子结果包括的sub_table_all_dims列下的数据(即匹配维度),是否包含了${Column_Set}中的所有维度,若未包含${Column_Set}中的所有维度则将该查询子结果从Rows_Set_1中删除。在示例性实施例中,第一查询结果利用表的形式体现,每个查询子结果为表中的一行数据,在删除第一查询结果中的查询子结果的过程中,保持行序,也即保持查询子结果的排列先后顺序不变。
步骤2023b:在参考查询结果中,将包括的不可聚合维度不满足第二条件的查询子结果删除,得到第二查询结果,不满足第二条件用于指示包括的不可聚合维度中存在任一不可聚合维度既不属于待查询维度,也不属于过滤条件信息指示的单过滤条件对应的维度。
每个查询子结果中均包括不可聚合维度,根据包括的不可聚合维度对初步过滤后得到的参考查询结果中的查询子结果进行进一步地过滤。在根据包括的不可聚合维度对初步过滤后得到的参考查询结果中的查询子结果进行进一步地过滤的过程中,将包括的不可聚合维度不满足第二条件的查询子结果删除。在将包括的不可聚合维度不满足第二条件的查询子结果删除后,得到第二查询结果。其中,不满足第二条件是指包括的不可聚合维度中存在任一不可聚合维度既不属于待查询维度,也不属于过滤条件信息指示的单过滤条件对应的维度。
当某一查询子结果包括的不可聚合维度不满足第二条件时,说明根据该查询子结果对应的子表无法实现数据查询请求指示的数据查询业务。过滤条件信息指示的单过滤条件是指不会引起聚合计算的过滤条件。示例性地,假设过滤条件信息指示的两个过滤条件分别为:日期为1月1日;年龄为20岁到30岁之间。其中,“日期为1月1日”这一过滤条件为单过滤条件,该单过滤条件对应的维度为“日期”;“年龄为20岁到30岁之间”这一过滤条件为非单过滤条件,该非单过滤条件对应的维度为“年龄”。
也就是说,对参考查询结果Rows_Set_2的各个查询子结果进行检查,看各个查询子结果中包括的non_aggr_dims列下的数据(即不可聚合维度)是否出现在了${Select_Dim_List}中,或者是否属于${Filter}指示的单选过滤条件对应的维度。若某一查询子结果包括的non_aggr_dims列下的数据中存在一个维度,它既没有出现在${Select_Dim_List}中,也不属于单选过滤条件对应的维度,则从Rows_Set_2中删除该查询子结果,所有查询子结果都检查完后,得到第二查询结果(记为Rows_Set_3)。示例性地,参考查询结果Rows_Set_2为表的形式,每个查询子结果为表中的一行数据,在删除查询子结果时保持行序不变。
需要说明的是,以上所述步骤2023a和步骤2023b仅为基于逻辑维度集合,对第一查询结果进行过滤,得到第二查询结果的实现方式的一种示例性描述,本申请实施例并不局限于此。示例性地,基于逻辑维度集合,对第一查询结果进行过滤,得到第二查询结果的过程还可以为:在第一查询结果中,将包括的不可聚合维度不满足第二条件的查询子结果删除,得到第二参考查询结果;在第二参考查询结果中,将包括的匹配维度不满足第一条件的查询子结果删除,得到第二查询结果。示例性地,基于逻辑维度集合,对第一查询结果进行过滤,得到第二查询结果的过程还可以为:在第一查询结果中,将包括的匹配维度不满足第一条件或者包括的不可聚合维度不满足第二条件的查询子结果删除,得到第二查询结果。
无论哪种方式,均能够得到第二查询结果。在得到第二查询结果后,将第二查询结果中满足选取条件的查询子结果作为目标查询子结果。示例性地,第二查询结果中满足选取条件的查询子结果为包括的匹配维度的数量最少的查询子结果。示例性地,当包括的匹配维度的数量最少的查询子结果有多个时,从该多个查询子结果中任选一个查询子结果作为目标查询子结果。
在一种可能实现方式中,第一查询结果中的查询子结果根据匹配维度数量升序排列,或者根据匹配维度数量降序排列。在对第一查询结果进行过滤的过程中,查询子结果的排列先后顺序保持不变,也就是说,第二查询结果中的查询子结果的排列先后顺序与第一查询结果中对应的查询子结果的排序先后顺相同。在此种情况下,将第二查询结果中满足选取条件的查询子结果作为目标查询子结果的实现方式为:响应于第一查询结果中的查询子结果根据匹配维度数量升序排列,将第二查询结果中位于第一位的查询子结果作为目标查询子结果;响应于第一查询结果中的查询子结果根据匹配维度数量降序排列,将第二查询结果中位于最后一位的查询子结果作为目标查询子结果。
步骤2024:将目标查询子结果中包括的表标识指示的物理表确定为数据查询请求对应的目标物理表。
目标查询子结果中包括的表标识指示的物理表即为满足数据查询请求的要求的物理表,且查询速度最快。将目标查询子结果中包括的表标识指示的物理表确定为数据查询请求对应的目标物理表,由此,确定用于实现数据查询所直接依赖的目标物理表。示例性地,表标识为元数据中记录的物理表的表名。
在示例性实施例中,若第二查询结果中不包括任何查询子结果,也即Rows_Set_3为空,则说明无法满足数据查询请求的要求,返回报错信息,以提示用户无法查询到与数据查询请求匹配的数据。示例性地,报错信息为“无相应粒度支持”。
在步骤203中,基于数据查询请求和目标物理表,获取数据查询请求对应的目标查询数据。
在基于步骤202确定目标物理表后,基于数据查询请求和目标物理表,获取数据查询请求对应的目标查询数据。在一种可能实现方式中,该步骤203的实现方式为:基于数据查询请求和目标物理表,确定目标结构化查询语句;在存储有目标物理表的数据库中,执行目标结构化查询语句,得到数据查询请求对应的目标查询数据。
数据查询请求无法被数据库直接识别,需要将数据查询请求转换为数据库能够直接识别的结构化查询语句。不同的数据库能够直接识别的结构化查询语句的形式可能相同,也可能不同,本申请实施例对此不加以限定。示例性地,对于数据查询请求利用逻辑SQL表示的情况,此处确定的目标结构化查询语句可称为物理SQL。
目标结构化查询语句的组成结构与存储有目标物理表的数据库有关,本申请实施例对此不加以限定。在一种示例性实施例中,目标物理表为预聚合表;数据查询请求携带待查询维度、待查询度量和过滤条件信息;目标物理表为目标查询子结果中包括的表标识指示的物理表,目标查询子结果中还包括目标维度组合子集。在此种情况下,基于数据查询请求和目标物理表,确定目标结构化查询语句的过程包括以下4个步骤。
步骤1:基于待查询维度,确定维度查询语句;基于待查询度量,确定度量查询语句;基于过滤条件信息,确定过滤条件查询语句;基于目标物理表的表标识,确定物理表查询语句。
维度查询语句用于指示用户需要查询的维度,根据待查询维度能够直接确定维度查询语句。度量查询语句用于指示用户需要查询的度量,根据待查询度量能够直接确定维度查询语句。过滤条件查询语句用于指示用户选择的过滤条件,根据过滤条件信息能够直接确定过滤条件查询语句。物理表查询语句用于指示数据查询所依据的物理表,根据目标物理表的表标识,能够直接确定物理表查询语句。
步骤2:基于目标维度组合子集和目标物理表对应的至少一个目标预聚合维度,确定维度约束查询语句。
目标查询子结果中包括的目标维度组合子集用于指示该目标查询子结果对应的子表的粒度。示例性地,查询子结果中包括的维度组合子集是指按照表5指示的格式生成的元数据表中的sub_table_comb_subset列下的数据。目标物理表对应的至少一个目标预聚合维度是指目标物理表对应的预聚合维度列表中的维度。示例性地,任一物理表对应的预聚合列表从目标元数据中的按照表2指示的格式生成的元数据表中的comb_dims列下的数据中得到。
目标维度组合子集为基于目标物理表对应的至少一个目标预聚合维度确定的至少一个参考维度组合子集中的一个参考维度组合子集。基于目标物理表对应的至少一个目标预聚合维度确定至少一个参考维度组合子集的方式随着目标物理表的预聚合的类型不同而有所不同,在不同的确定方式下,确定的至少一个参考维度组合子集也不同。
目标物理表可能为第一类型的预聚合表,也可能为第二类型的预聚合表,还可能为第三类型的预聚合表,本申请实施例对此不加以限定。第一类型的预聚合表、第二类型的预聚合表以及第三类型的预聚合表的相关介绍详见步骤202中的相关内容,此处不再赘述。当目标物理表为第一类型的预聚合表时,至少一个个参考维度组合子集通过对至少一个目标预聚合维度进行任意组合得到。当目标物理表为第二类型的预聚合表时,至少一个参考维度组合子集通过对至少一个目标预聚合维度进行分层组合得到。当目标物理表为第三类型的预聚合表时,至少一个参考维度组合子集通过对至少一个目标预聚合维度进行单独组合得到。
在一种可能实现方式中,每个参考维度组合子集均对应一种粒度的数据。也就是说,目标物理表中记录的数据的粒度的数量与至少一个参考维度组合子集的数量相同。
在一种可能实现方式中,基于目标维度组合子集和目标物理表对应的至少一个目标预聚合维度,确定维度约束查询语句的方式为:将目标维度组合子集中的维度作为第一维度,确定第一维度对于的第一汇总标识符;确定至少一个目标预聚合维度中除第一维度外的第二维度对应的第二汇总标识符;将用于指示第一维度不具有第一汇总标识符,且第二维度具有第二汇总标识符的查询语句作为维度约束查询语句。
在一种可能实现方式中,第一维度对于的第一汇总标识符基于第一维度对于的数据类型确定,第二维度对于的第二汇总标识符基于第二维度对于的数据类型确定。第一维度对应的数据类型以及第二维度对应的数据类型可以从目标元数据中的按照表1指示的格式生成的元数据表中得知,也可以从维度和数据类型的对应关系中得知,本申请实施例对此不加以限定。不同的数据类型对应不同的汇总标识符,在确定维度对应的数据类型后,进一步确定维度对应的汇总标识符。在示例性实施例中,维度对应的汇总标识符从数据类型和汇总标识符的对应关系中得知。数据类型和汇总标识符的对应关系根据经验设置,例如,string型对应的汇总标识符为TOTAL;int型对应的汇总标识符为99999999;日期型对应的汇总标识符为2099-12-31。
在确定第一维度对应的第一汇总标识符以及第二维度对应的第二汇总标识符后,将用于指示第一维度不具有第一汇总标识符,且第二维度具有第二汇总标识符的查询语句作为维度约束查询语句。示例性地,维度约束查询语句用于对目标查询子结果对应的子表的维度约束进行描述,该维度约束查询语句的表示方式与步骤202中介绍的子表的汇总表示的表示方式相同。在示例性实施例中,子表的汇总表示可以预先存储,此种情况下,可以直接基于目标查询子结果对应的子表的汇总表示,确定维度约束查询语句。
需要说明的是,第一维度的数量可能为一个或多个,本申请实施例对此不加以限定。对于第一维度的数量为多个的情况,第一维度对应的数据类型是指各个第一维度分别对应的数据类型,不同的第一维度对应的数据类型可能相同,也可能不同。第一维度对应的第一汇总标识符是指根据各个第一维度分别对应的数据类型,确定的各个第一维度分别对应的汇总标识符。第一维度不具有第一汇总标识符是指各个第一维度均不具有对应的第一汇总标识符。
同理地,第二维度的数量可能为一个或多个,本申请实施例对此不加以限定。对于第二维度的数量为多个的情况,第二维度对应的数据类型是指各个第二维度分别对应的数据类型,不同的第二维度对应的数据类型可能相同,也可能不同。第二维度对应的第二汇总标识符是指根据各个第二维度分别对应的数据类型,确定的各个第二维度分别对应的汇总标识符。第二维度具有第二汇总标识符是指各个第二维度均具有对应的第二汇总标识符。
步骤3:将维度查询语句对应的模型相关列、度量查询语句对应的模型相关列、过滤条件查询语句对应的模型相关列以及维度约束查询语句对应的模型相关列的并集作为目标模型相关列;基于目标模型相关列的表达式,确定模型相关列查询语句。
模型相关列是指目标数据模型中的列,维度查询语句对应的模型相关列是指维度查询语句中涉及的目标数据模型中的维度列,度量查询语句对应的模型相关列是指度量查询语句中涉及的目标数据模型中的度量列,过滤条件查询语句对应的模型相关列是指过滤条件查询语句中涉及的目标数据模型中的维度列,维度约束查询语句对应的模型相关列是指维度约束查询语句中涉及的目标数据模型中的维度列。
将维度查询语句对应的模型相关列、度量查询语句对应的模型相关列、过滤条件查询语句对应的模型相关列以及维度约束查询语句对应的模型相关列的并集作为目标模型相关列。目标模型相关列即为目标数据模型中与数据查询请求相关的列。在确定目标模型相关列后,基于目标模型相关列的表达式,确定模型相关列查询语句。在示例性实施例中,目标模型相关列的表达式从目标元数据中的按照表2指示的格式生成的元数据表中获取。
在一种可能实现方式中,基于目标模型相关列的表达式,确定模型相关列查询语句的方式为:通过指定关键字将目标模型相关列的表达式与目标模型相关列的列名连接起来,得到模型相关列查询语句。
步骤4:基于维度查询语句、度量查询语句、过滤条件查询语句、物理表查询语句、维度约束查询语句和模型相关列查询语句,确定目标结构化查询语句。
在得到维度查询语句、度量查询语句、过滤条件查询语句、物理表查询语句、维度约束查询语句和模型相关列查询语句后,按照目标结构化查询语句的组成结构进行填充,得到目标结构化查询语句。
需要说明的是,以上步骤1至步骤4仅以目标物理表为预聚合表,且数据查询请求携带待查询维度、待查询度量和过滤条件信息为例进行说明。对于数据查询请求不携带待查询维度的情况,维度查询语句置为指定语句;对于数据查询请求不携带过滤条件信息的情况,过滤条件语句置为指定语句。指定语句根据经验设置,例如,指定语句为“1 = 1”。
在示例性实施例中,目标物理表还可能为基础表。对于目标物理表为基础表的情况,目标结构化查询语句的组成结构保持不变,也就是说,目标结构化查询语句仍然基于维度查询语句、度量查询语句、过滤条件查询语句、物理表查询语句、维度约束查询语句和模型相关列查询语句确定。对于目标物理表为基础表的情况,维度查询语句、过滤条件查询语句、物理表查询语句以及模型相关列查询语句的确定方式与目标物理表为预聚合表的情况下的确定方式相同。由于基础表的子表是其自身,所以不需要维度约束,将维度约束查询语句置为指定语句,例如,将维度约束查询语句置为“1 = 1”。
示例性地,以ClickHouse(一种用于OLAP的列式数据库管理系统)数据库为例,ClickHouse数据库支持的结构化查询语句的组成结构如下。
在上述组成结构中,WITH、SELECT、FROM、WHERE、AND和GROUP BY均是SQL中的关键字,WHERE 1 = 1是SQL中的条件逻辑判断表达式。${Related_Column_Expression_Alias}表示模型相关列查询语句;${Select_Dim_List}表示维度查询语句;${Selected_Measure}表示度量查询语句;${Table}表示物理表查询语句;${Filter}表示过滤条件查询语句;{Sub_Table_Dims_Desc}表示维度约束查询语句。根据上述组成结构可以看出,生成目标结构化查询语句的过程中,需要填充以下7个部分。
SELECT关键字后的${Selected_Dim_List}:根据用户选择的维度列表确定,即根据待查询维度确定。
${Selected_Measure}:根据用户选择的度量确定,即根据待查询度量确定。
${Table}:根据找到的最合适的查询表的表标识确定,即根据目标物理查询表的表标识确定。
${Filter}:根据数据查询请求携带的过滤条件信息确定。没有过滤条件信息时,此部分置为“1 = 1”即可。
${Sub_Table_Dims_Desc}:用于指示子表的维度约束描述,等价于子表的汇总表示;若${Table}指示的目标物理表为基础表,则将此部分置为“1 = 1”即可。
GROUP BY关键字后的${Selected_Dim_List}:此部分与SELECT关键字后的${Selected_Dim_List}是完全一致的。需要说明的是,若${Selected_Measure}指示的度量对应的表达式不带有聚合函数,则将此部分置为“1 = 1”即可。示例性地,${Selected_Measure}指示的度量对应的表达式从目标元数据中的按照表2指示的格式生成的元数据表中获取。
${Related_Column_Expression_Alias}:用于指示模型相关列的别名。相关列,指的是${Selected_Dim_List}、${Selected_Measure}、${Filter}和${Sub_Table_Dims_Desc}中所涉及到的模型的相关列的并集,即目标模型相关列。示例性地,在目标元数据中的按照表2指示的格式生成的元数据表中,找到目标模型相关列在${Table}指示的目标物理表中对应的表达式,通过SQL关键字“AS”将表达式与列别名连接起来,得到${Related_Column_Expression_Alias}。列别名取column_name即可。
在示例性实施例中,以数据查询请求利用逻辑SQL表示、逻辑SQL中的数据为JSON格式的数据、目标结构化查询语句为物理SQL为例,将逻辑SQL中的JSON数据转化成物理SQL时,需要做适当处理。例如,假设逻辑SQL中的过滤条件信息利用如下的JSON格式表示。
此种情况下,在获取过滤条件查询语句${Filter}时,需要将上述格式的过滤条件信息处理成“user_age BETWEEN 20 AND 30 AND date_id = 20200701”。
在获取目标结构化查询语句后,在存储有目标物理表的数据库中,执行目标结构化查询语句,得到数据查询请求对应的目标查询数据。示例性地,服务器获取的目标查询数据为一个数据集对象,服务器在获取目标查询数据之后,通过解析将数据集对象转化为JSON格式,然后将JSON格式的目标查询数据返回发送数据查询请求的终端,终端将JSON格式的目标查询数据转化成方便用户阅读的表格或者图形,然后展示给用户。
示例性地,对于用户而言,服务器的操作对用户无感,用户在选择度量、维度以及过滤条件并点击“查询”按钮后,服务器即执行本申请实施例提供的数据查询方法,将查询的目标查询数据返回终端,终端展示目标查询数据,例如,终端利用表格的形式展示目标查询数据,如图3中的302所示。本申请实施例对在存储有目标物理表的数据库中,执行目标结构化查询语句的过程不加以限定,根据目标物理表中包括的数据以及目标结构化查询语句的内容不同,执行目标结构化查询语句的过程可能有所不同,执行目标结构化查询语句得到目标查询数据的耗时也可能不同。
在示例性实施例中,数据查询过程如图4所示。1、用户登录终端,选择所需的维度、度量以及过滤条件等,示例性地,本申请实施例中的终端是指数据查询平台的web(网络)前端;2、终端将用户选择的维度、度量以及过滤条件,以逻辑SQL的形式(即数据查询请求)提交给服务器,示例性地,本申请实施例中的服务器是指ROLAP引擎;3、服务器接收到逻辑SQL后,确定用于存储元数据的元数据库;4、服务器在元数据库中获取所需的目标元数据;5、服务器根据目标元数据,确定目标物理表表,将逻辑SQL转换为物理SQL(即目标结构化查询语句),确定用于存储物理表的关系数据库;6、服务器在关系数据库中执行物理SQL,得到的目标查询数据;7、服务器将获取到的目标查询数据转换为JSON格式的数据,返回给终端;8、终端将JSON格式的数据以表格或图形等方式展示给用户。
本申请实施例中所提出数据查询方法可视为数据查询平台的应用场景中的一种ROLAP引擎的实现方案。当ROLAP引擎接收到一个数据查询请求后,它会到数据库中进行智能检索,找到最适合当前数据查询请求的目标物理表,然后再进行查询处理,最后再将目标查询数据返回。
在本申请实施例中,设计了基础表与预聚合表的方式,使得用户可根据实际使用需要,来自行决定做哪些维度组合的预聚合,而不是做多个维度的任意组合。这样以来,既可以满足实际需求,也不会引起数据爆炸。此外,本申请实施例设计了逻辑SQL的查询方式。逻辑SQL,类似于数据库的物理SQL,它使用简单,可读性强,工程上更容易开发推广,除了便于程序解析外,还可以很方便地由JSON格式转化为SQL格式,这大大提高了可阅读性,方便分析。
进一步地,本申请实施例提出的预聚合表的数据存储方式,有这样几个优点:首先,这方便了用户在一个表中存储多种粒度的数据;其次,本申请实施例将预聚合表细分为cube、rollup、groupingsets类型,与Hive或者Spark(一种基于内存计算的大数据并行计算框架)的SQL中的汇总关键字一一对应,这样就可以使用Hive或者Spark的SQL进行数据预聚合处理,从而充分利用Hive或者Spark集群并行计算的优势,使得预聚合计算变得方便快捷;第三,在进行预聚合计算时,多个维度中选取哪些维度进行组合计算,可根据需求自行决定,而不是做维度的任意组合,这大大减少了数据预聚合的计算量和存储量;第四,存储表以带有维度信息的方式来存储,而不是仅存储维度主键,所以查询时并不涉及维表与事实表的关联,能显著提高查询响应速度。
在本申请实施例中,数据查询的实现过程依赖目标数据模型对应的至少两个物理表,目标数据模型对应的至少两个物理表包括基础表和根据需求进行预聚合计算后得到的预聚合表。也就是说,无需根据维度的所有组合分别进行预聚合计算即可得到用于实现数据查询的物理表,预聚合计算量较小。此外,利用一个预聚合表记录至少两种粒度的数据,能够有效减少数据库中存储的表的数量,减少数据存储量,有利于提升数据查询的响应速度。
在本申请实施例中,提供了一种数据查询的实例,以便于理解数据查询的具体实现过程。示例性地,本申请实施例中提到的数据查询过程是指ROLAP的实现过程,数据查询的过程由ROLAP引擎实现,ROLAP引擎可视为一种服务器。
本申请实施例提供的数据查询的实例在这样一个分析需求下实现:一款资讯APP(Application,应用程序)的数据分析师,需要按如下表14所示的维度与度量进行数据分析,除了要求查询速度尽可能快之外,数据分析师希望ROLAP引擎对度量能提供尽可能多的维度组合结果。
在上述表14中,数据类型列中的int表示整型,string表示字符串型,float表示浮点型。含义列中的pv是指页面浏览量(page view),uv是指独立访客数量(uniquevisitor)。
在示例性实施例中,开发人员使用本申请实施例提供的ROLAP存储方案,设计了6个物理表,存储于RDB(如,ClickHouse)中。这6个物理表分别如表15至表20所示。
需要说明的是,在上述表15至表20中,表类型group用于标识基础表,表类型cube用于标识第一类型的预聚合表,表类型rollup用于标识第二类型的预聚合表,表类型groupingsets用于标识第三类型的预聚合表。假设表15所示的物理表的表名为t0,表16所示的物理表的表名为t1,表17所示的物理表的表名为t2,表18所示的物理表的表名为t3,表19所示的物理表的表名t4,将表20所示的物理表的表名为t5。其中,t0和t1为基础表,t2至t5为预聚合表。
在基础表t0和基础表t1中,以星号(*)标识出主键,在预聚合表t2至预聚合表t5中,以星号(*)标识出预聚合维度。在不同的预聚合表中,预聚合维度的类型以及数量可以相同,也可以不同。
从上述表15至表20可以看出,表15所示的物理表是最细粒度的表,数据分析师所需的一切维度和度量均可从此表得出,它可以提供任意维度组合的度量查询结果。但遗憾的是,由于其粒度过细会导致其数据量过大,无法满足查询及时性的要求(比如1秒)。故此,开发人员又设计了表16至表20所示的物理表,用于对表15所示的物理表做预聚合存储,因为其维度个数较少,所以数据粒度较粗,其数据量也就会减少很多,可以满足查询及时性的要求。
上述预聚合表t2至预聚合表t5的聚合类型分别为cube/rollup/groupingsets/cube,开发人员能够使用Hive平台,在Hive_SQL脚本中使用汇总关键字(cube/rollup/groupingsets)实现预聚合计算,这使得开发工作得以大大简化。
在示例性实施例中,在设计好表15至表20所示的物理表后,开发人员能够根据物理表填充模型的元数据,从而得到模型对应的元数据。在本申请实施例中,根据表15至表20所示的物理表填充得到的元数据包括6个元数据表,这6个元数据表分别如下述表21至表26所示。该表21至表26可看作根据表15至表20所示的物理表按照图2所示的实施例中提供的表1至表6指示的格式生成的元数据表。下述表21至表26的具体含义参见图2所示的实施例中提供的表1至表6以及上述表14,此处不再赘述。
需要说明的是,由于篇幅原因,在上述表22中,省略了与表名为t3以及表名为t4的物理表相关的内容。
需要说明的是,由于篇幅原因,在上述表26中,省略了与表名为t3、表名为t4以及表名为t5的物理表相关的内容。
有了模型的元数据,就有了对模型的详细描述。当接收到用户的查询请求后,就可以通过元数据来提供ROLAP服务,即提供数据查询服务。
示例性地,本申请实施例中的数据查询请求的实例如下。
本申请实施例提供的ROLAP服务可以分为三个阶段:第一阶段:确定目标物理表,即确定从哪个物理表中查询数据;第二阶段:生成目标结构化查询语句,即生成用于数据库查询的SQL查询语句;第三阶段:执行目标结构化查询语句,即执行目标结构化查询语句并返回结果,即返回目标查询数据。
第一阶段:确定目标查询表。
这是最核心的一个阶段,因为ROLAP提升查询响应速度的关键就在于此。通过如下4个步聚,就能从众多的物理表中找到一个查询最快的目标物理表。
1-1、确定逻辑维度集合。
根据上述数据查询请求可知,逻辑维度集合${Colunmn_Set} = {user_age,article_category, date_id}。
1-2、获取第一查询结果。
以${Model_ID} = 123和${Selected_Measure} = pv_avg为查询条件,在上述表25所示的元数据表和表26所示的元数据表中进行查询,得到的第一查询结果Row_set_1如表27所示。
需要说明的是,上述表27中包括行标号分别为1至10的10行数据,每行数据均对应一个查询子结果,行标号分别为1至10的10行数据是按照匹配维度数量升序排列的。
1-3、对第一查询结果进行过滤,得到第二查询结果。
对第一查询结果进行过滤的过程包括以下步骤1-3a和1-3b。
1-3a、基于匹配维度进行过滤。
逻辑维度集合${Column_Set} = {user_age, article_category, date_id},匹配维度为表27中的sub_table_all_dims列下的数据,根据表27可知,行标号为1、3、4、7的行对应的匹配维度中不包含逻辑维度集合中的user_age,行标号为2、5的行对应的匹配维度中不含逻辑维度集合中的article_category,因此,将表27中的行标号为1、2、3、4、5和7的行,得到的参考查询结果Rows_Set_2如表28所示。
1-3b、基于不可聚合维度进行过滤。
不可聚合维度为表28中的non_aggr_dims列下的数据,由于表28中的行标号为8和9的行对应的不可聚合维度中的article_type既没有出现在${Select_Dim_List}中,也不属于${Filter}中的单选过滤条件,所以将表28中的行标号为8和9的行删除,最后得到的第二查询结果Rows_Set_3如表29所示。
需要说明的是,在对第一查询结果进行过滤的过程中,行序保持不变,每行对应的行标号保持不变。
1-4、确定目标物理表。
第二查询结果Rows_Set_3的第一行数据中的表标识为t2,即将物理表t2确定为目标物理表。
第二阶段:生成目标结构化查询语句。
根据上述数据查询请求实例以及确定出的物理表t2,能够确定以下内容1至内容7。
内容1、SELECT关键字后的维度查询语句${Selected_Dim_List}表示为:{user_age, article_category}。
内容2、度量查询语句${Selected_Measure}表示为:pv_avg。
内容3、物理表查询语句${Table}表示为:t2。
内容4、过滤条件查询语句${Filter}表示为:user_age BETWEEN 20 AND 30 ANDdate_id = 20200701。
内容5、关于维度约束查询语句${Sub_Table_Dims_Desc}:
Rows_Set_3的第1行对应的目标维度组合子集sub_table_comb_subset为{user_age,article_category}。通过表24所示的元数据表可以得知物理表t2对应的至少一个预聚合维度comb_dims为{user_age, article_type, article_category}。从表21所示的元数据表中可以得知user_age维度对应的数据类型为int,所以user_age维度对应的汇总标识符为99999999;article_type维度与article_category维度对应的数据类型均为string,所以article_type维度与article_category维度对应的汇总标识符均为TOTAL。因此,维度约束查询语句${Sub_Table_Dims_Desc}表示为:user_age != 99999999 AND article_category != ‘TOTAL’ AND article_type = ‘TOTAL’。
内容6、关于GROUP BY关键字后的维度查询语句${Selected_Dim_List}:
根据表22所示的元数据表可知,物理表t2中的pv_avg的表达式为“sum(pv)/sum(uv)”,是带有聚合函数sum的,所以此部分不能省略,也即GROUP BY关键字后的维度查询语句${Selected_Dim_List}表示为{user_age, article_category}。
内容7、关于模型相关列查询语句${Related_Column_Expression_Alias}:
维度查询语句${Selected_Dim_List}对应的模型相关列是{user_age, article_category},度量查询语句${Selected_Measure}对应的模型相关列是{pv_avg},过滤条件查询语句${Filter}对应的模型相关列是{user_age, date_id},维度约束查询语句${Sub_Table_Dims_Desc}对应的模型相关列是{user_age, article_category, article_type}。因此,目标模型相关列为{date_id, article_category, article_type, user_age, pv_avg}。
通过查询表22所示的元数据表,可以确定目标模型相关列在物理表t2中的表达式,进而确定模型相关列查询语句${Related_Column_Expression_Alias}为如下所示。
其中,关键字AS前的内容表示目标模型相关列的表达式,关键字AS后的内容表示目标模型相关列的列名。
通过确定上述内容1至内容7后,最终得到的目标结构化查询语句如图5所示(为了方便阅读,手动做了适当的换行与缩进处理)。
第三阶段:执行目标结构化查询语句。
在存储有物理表t2的数据库(如,ClickHouse数据库)中执行目标结构化查询语句,得到的目标查询数据。ROLAP引擎将目标查询数据转换为JSON格式并返回终端,例如,部分JSON格式的目标查询数据如下所示。
在将JSON格式的目标查询数据返回终端后,终端将JSON格式的目标查询数据转化成方便用户阅读的表格或图形展示给用户,至此,完成整个数据查询过程。
参见图6,本申请实施例提供了一种数据查询装置,该装置包括:
第一获取单元601,用于获取针对目标数据模型的数据查询请求;
确定单元602,用于基于数据查询请求和目标数据模型对应的目标元数据,在目标数据模型对应的至少两个物理表中确定数据查询请求对应的目标物理表,目标元数据基于至少两个物理表确定,至少两个物理表包括基础表和根据需求进行预聚合计算后得到的预聚合表,基础表用于记录基础数据,任一预聚合表用于记录至少两种粒度的数据;
第二获取单元603,用于基于数据查询请求和目标物理表,获取数据查询请求对应的目标查询数据。
在一种可能实现方式中,数据查询请求携带待查询度量;确定单元602,用于确定数据查询请求对应的逻辑维度集合;基于目标数据模型的模型标识和待查询度量,确定查询条件;在目标元数据中查询与查询条件匹配的第一查询结果,第一查询结果由至少一个查询子结果构成,任一查询子结果中包括目标数据模型对应的一个物理表的表标识;基于逻辑维度集合,对第一查询结果进行过滤,得到第二查询结果,将第二查询结果中满足选取条件的查询子结果作为目标查询子结果;将目标查询子结果中包括的表标识指示的物理表确定为数据查询请求对应的目标物理表。
在一种可能实现方式中,确定单元602,还用于响应于数据查询请求还携带待查询维度,由待查询维度构成数据查询请求对应的逻辑维度集合;响应于数据查询请求还携带过滤条件信息,确定过滤条件信息对应的参考维度,由参考维度构成数据查询请求对应的逻辑维度集合;响应于数据查询请求还携带待查询维度和过滤条件信息,确定过滤条件信息对应的参考维度,将待查询维度和参考维度的并集作为数据查询请求对应的逻辑维度集合;响应于数据查询请求未携带待查询维度和过滤条件信息,将空集作为数据查询请求对应的逻辑维度集合。
在一种可能实现方式中,数据查询请求还携带待查询维度和过滤条件信息,任一查询子结果中还包括匹配维度和不可聚合维度;确定单元602,还用于在第一查询结果中,将包括的匹配维度不满足第一条件的查询子结果删除,得到参考查询结果,不满足第一条件用于指示包括的匹配维度中不包含逻辑维度集合中的全部维度;在参考查询结果中,将包括的不可聚合维度不满足第二条件的查询子结果删除,得到第二查询结果,不满足第二条件用于指示包括的不可聚合维度中存在任一不可聚合维度既不属于待查询维度,也不属于过滤条件信息指示的单过滤条件对应的维度。
在一种可能实现方式中,第一查询结果中的查询子结果根据匹配维度数量升序排列,或者根据匹配维度数量降序排列;第二查询结果中的查询子结果的排列先后顺序与第一查询结果中对应的查询子结果的排列先后顺序相同;确定单元602,还用于响应于第一查询结果中的查询子结果根据匹配维度数量升序排列,将第二查询结果中位于第一位的查询子结果作为目标查询子结果;响应于第一查询结果中的查询子结果根据匹配维度数量降序排列,将第二查询结果中位于最后一位的查询子结果作为目标查询子结果。
在一种可能实现方式中,第二获取单元603,用于基于数据查询请求和目标物理表,确定目标结构化查询语句;在存储有目标物理表的数据库中,执行目标结构化查询语句,得到数据查询请求对应的目标查询数据。
在一种可能实现方式中,目标物理表为预聚合表;数据查询请求携带待查询维度、待查询度量和过滤条件信息;目标物理表为目标查询子结果中包括的表标识指示的物理表,目标查询子结果中还包括目标维度组合子集;第二获取单元603,还用于基于待查询维度,确定维度查询语句;基于待查询度量,确定度量查询语句;基于过滤条件信息,确定过滤条件查询语句;基于目标物理表的表标识,确定物理表查询语句;基于目标维度组合子集和目标物理表对应的至少一个目标预聚合维度,确定维度约束查询语句;将维度查询语句对应的模型相关列、度量查询语句对应的模型相关列、过滤条件查询语句对应的模型相关列以及维度约束查询语句对应的模型相关列的并集作为目标模型相关列;基于目标模型相关列的表达式,确定模型相关列查询语句;基于维度查询语句、度量查询语句、过滤条件查询语句、物理表查询语句、维度约束查询语句和模型相关列查询语句,确定目标结构化查询语句。
在一种可能实现方式中,目标维度组合子集为基于至少一个目标预聚合维度确定的至少一个参考维度组合子集中的一个参考维度组合子集;第二获取单元603,还用于将目标维度组合子集中的维度作为第一维度,确定第一维度对应的第一汇总标识符;确定至少一个目标预聚合维度中除第一维度外的第二维度对应的第二汇总标识符;将用于指示第一维度不具有第一汇总标识符,且第二维度具有第二汇总标识符的查询语句作为维度约束查询语句。
在一种可能实现方式中,目标物理表为第一类型的预聚合表,至少一个参考维度组合子集通过对至少一个目标预聚合维度进行任意组合得到;或者,目标物理表为第二类型的预聚合表,至少一个参考维度组合子集通过对至少一个目标预聚合维度进行分层组合得到;或者,目标物理表为第三类型的预聚合表,至少一个参考维度组合子集通过对至少一个目标预聚合维度进行单独组合得到。
在一种可能实现方式中,目标物理表中记录的数据的粒度的数量与至少一个参考维度组合子集的数量相同。
在一种可能实现方式中,参见图7,该装置还包括:
第三获取单元604,用于获取目标数据模型对应的至少两个物理表;基于至少两个物理表,确定目标数据模型对应的目标元数据;
存储单元605,用于对至少两个物理表和目标元数据进行存储。
在本申请实施例中,数据查询的实现过程依赖目标数据模型对应的至少两个物理表,目标数据模型对应的至少两个物理表包括基础表和根据需求进行预聚合计算后得到的预聚合表。也就是说,无需根据维度的所有组合分别进行预聚合计算即可得到用于实现数据查询的物理表,预聚合计算量较小。此外,利用一个预聚合表记录至少两种粒度的数据,能够有效减少数据库中存储的表的数量,减少数据存储量,有利于提升数据查询的响应速度。
需要说明的是,上述实施例提供的装置在实现其功能时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将设备的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的装置与方法实施例属于同一构思,其具体实现过程详见方法实施例,这里不再赘述。
图8是本申请实施例提供的一种服务器的结构示意图,该服务器可因配置或性能不同而产生比较大的差异,可以包括一个或多个处理器(Central Processing Units,CPU)801和一个或多个存储器802,其中,该一个或多个存储器802中存储有至少一条计算机程序,该至少一条计算机程序由该一个或多个处理器801加载并执行,以实现上述各个方法实施例提供的数据查询方法。当然,该服务器还可以具有有线或无线网络接口、键盘以及输入输出接口等部件,以便进行输入输出,该服务器还可以包括其他用于实现设备功能的部件,在此不做赘述。
在示例性实施例中,还提供了一种计算机设备,该计算机设备包括处理器和存储器,该存储器中存储有至少一条计算机程序。该至少一条计算机程序由一个或者一个以上处理器加载并执行,以实现上述任一种数据查询方法。
在示例性实施例中,还提供了一种计算机可读存储介质,该计算机可读存储介质中存储有至少一条计算机程序,该至少一条计算机程序由计算机设备的处理器加载并执行,以实现上述任一种数据查询方法。
在一种可能实现方式中,上述计算机可读存储介质可以是只读存储器(Read-OnlyMemory,ROM)、随机存取存储器(Random Access Memory,RAM)、只读光盘(Compact DiscRead-Only Memory,CD-ROM)、磁带、软盘和光数据存储设备等。
在示例性实施例中,还提供了一种计算机程序产品或计算机程序,该计算机程序产品或计算机程序包括计算机指令,该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令,处理器执行该计算机指令,使得该计算机设备执行上述任一种数据查询方法。
需要说明的是,本申请的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以上示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
应当理解的是,在本文中提及的“多个”是指两个或两个以上。“和/或”,描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
以上所述仅为本申请的示例性实施例,并不用以限制本申请,凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。
Claims (14)
1.一种数据查询方法,其特征在于,所述方法包括:
获取针对目标数据模型的数据查询请求;
基于所述数据查询请求和所述目标数据模型对应的目标元数据,在所述目标数据模型对应的至少两个物理表中确定所述数据查询请求对应的目标物理表,所述目标元数据基于所述至少两个物理表确定,所述至少两个物理表包括基础表和根据需求进行预聚合计算后得到的预聚合表,所述基础表用于记录基础数据,任一预聚合表用于记录至少两种粒度的数据;
基于所述数据查询请求和所述目标物理表,获取所述数据查询请求对应的目标查询数据。
2.根据权利要求1所述的方法,其特征在于,所述数据查询请求携带待查询度量;所述基于所述数据查询请求和所述目标数据模型对应的目标元数据,在所述目标数据模型对应的至少两个物理表中确定所述数据查询请求对应的目标物理表,包括:
确定所述数据查询请求对应的逻辑维度集合;
基于所述目标数据模型的模型标识和所述待查询度量,确定查询条件;在所述目标元数据中查询与所述查询条件匹配的第一查询结果,所述第一查询结果由至少一个查询子结果构成,任一查询子结果中包括所述目标数据模型对应的一个物理表的表标识;
基于所述逻辑维度集合,对所述第一查询结果进行过滤,得到第二查询结果,将所述第二查询结果中满足选取条件的查询子结果作为目标查询子结果;
将所述目标查询子结果中包括的表标识指示的物理表确定为所述数据查询请求对应的目标物理表。
3.根据权利要求2所述的方法,其特征在于,所述确定所述数据查询请求对应的逻辑维度集合,包括:
响应于所述数据查询请求还携带待查询维度,由所述待查询维度构成所述数据查询请求对应的逻辑维度集合;
响应于所述数据查询请求还携带过滤条件信息,确定所述过滤条件信息对应的参考维度,由所述参考维度构成所述数据查询请求对应的逻辑维度集合;
响应于所述数据查询请求还携带待查询维度和过滤条件信息,确定所述过滤条件信息对应的参考维度,将所述待查询维度和所述参考维度的并集作为所述数据查询请求对应的逻辑维度集合;
响应于所述数据查询请求未携带待查询维度和过滤条件信息,将空集作为所述数据查询请求对应的逻辑维度集合。
4.根据权利要求2所述的方法,其特征在于,所述数据查询请求还携带待查询维度和过滤条件信息,所述任一查询子结果中还包括匹配维度和不可聚合维度;所述基于所述逻辑维度集合,对所述第一查询结果进行过滤,得到第二查询结果,包括:
在所述第一查询结果中,将包括的匹配维度不满足第一条件的查询子结果删除,得到参考查询结果,所述不满足第一条件用于指示包括的匹配维度中不包含所述逻辑维度集合中的全部维度;
在所述参考查询结果中,将包括的不可聚合维度不满足第二条件的查询子结果删除,得到第二查询结果,所述不满足第二条件用于指示包括的不可聚合维度中存在任一不可聚合维度既不属于所述待查询维度,也不属于所述过滤条件信息指示的单过滤条件对应的维度。
5.根据权利要求2-4任一所述的方法,其特征在于,所述第一查询结果中的查询子结果根据匹配维度数量升序排列,或者根据匹配维度数量降序排列;所述第二查询结果中的查询子结果的排列先后顺序与所述第一查询结果中对应的查询子结果的排列先后顺序相同;
所述将所述第二查询结果中满足选取条件的查询子结果作为目标查询子结果,包括:
响应于所述第一查询结果中的查询子结果根据匹配维度数量升序排列,将所述第二查询结果中位于第一位的查询子结果作为目标查询子结果;
响应于所述第一查询结果中的查询子结果根据匹配维度数量降序排列,将所述第二查询结果中位于最后一位的查询子结果作为目标查询子结果。
6.根据权利要求1所述的方法,其特征在于,所述基于所述数据查询请求和所述目标物理表,获取所述数据查询请求对应的目标查询数据,包括:
基于所述数据查询请求和所述目标物理表,确定目标结构化查询语句;
在存储有所述目标物理表的数据库中,执行所述目标结构化查询语句,得到所述数据查询请求对应的目标查询数据。
7.根据权利要求6所述的方法,其特征在于,所述目标物理表为预聚合表;所述数据查询请求携带待查询维度、待查询度量和过滤条件信息;所述目标物理表为目标查询子结果中包括的表标识指示的物理表,所述目标查询子结果中还包括目标维度组合子集;所述基于所述数据查询请求和所述目标物理表,确定目标结构化查询语句,包括:
基于所述待查询维度,确定维度查询语句;基于所述待查询度量,确定度量查询语句;基于所述过滤条件信息,确定过滤条件查询语句;基于所述目标物理表的表标识,确定物理表查询语句;
基于所述目标维度组合子集和所述目标物理表对应的至少一个目标预聚合维度,确定维度约束查询语句;
将所述维度查询语句对应的模型相关列、所述度量查询语句对应的模型相关列、所述过滤条件查询语句对应的模型相关列以及所述维度约束查询语句对应的模型相关列的并集作为目标模型相关列;基于所述目标模型相关列的表达式,确定模型相关列查询语句;
基于所述维度查询语句、所述度量查询语句、所述过滤条件查询语句、所述物理表查询语句、所述维度约束查询语句和所述模型相关列查询语句,确定目标结构化查询语句。
8.根据权利要求7所述的方法,其特征在于,所述目标维度组合子集为基于所述至少一个目标预聚合维度确定的至少一个参考维度组合子集中的一个参考维度组合子集;所述基于所述目标维度组合子集和所述目标物理表对应的至少一个目标预聚合维度,确定维度约束查询语句,包括:
将所述目标维度组合子集中的维度作为第一维度,确定所述第一维度对应的第一汇总标识符;
确定所述至少一个目标预聚合维度中除所述第一维度外的第二维度对应的第二汇总标识符;
将用于指示所述第一维度不具有所述第一汇总标识符,且所述第二维度具有所述第二汇总标识符的查询语句作为维度约束查询语句。
9.根据权利要求8所述的方法,其特征在于,所述目标物理表为第一类型的预聚合表,所述至少一个参考维度组合子集通过对所述至少一个目标预聚合维度进行任意组合得到;或者,
所述目标物理表为第二类型的预聚合表,所述至少一个参考维度组合子集通过对所述至少一个目标预聚合维度进行分层组合得到;或者,
所述目标物理表为第三类型的预聚合表,所述至少一个参考维度组合子集通过对所述至少一个目标预聚合维度进行单独组合得到。
10.根据权利要求8或9所述的方法,其特征在于,所述目标物理表中记录的数据的粒度的数量与所述至少一个参考维度组合子集的数量相同。
11.根据权利要求1-4、6-9任一所述的方法,其特征在于,所述基于所述数据查询请求和所述目标数据模型对应的目标元数据,在所述目标数据模型对应的至少两个物理表中确定所述数据查询请求对应的目标物理表之前,所述方法还包括:
获取所述目标数据模型对应的至少两个物理表;
基于所述至少两个物理表,确定所述目标数据模型对应的目标元数据;
对所述至少两个物理表和所述目标元数据进行存储。
12.一种数据查询装置,其特征在于,所述装置包括:
第一获取单元,用于获取针对目标数据模型的数据查询请求;
确定单元,用于基于所述数据查询请求和所述目标数据模型对应的目标元数据,在所述目标数据模型对应的至少两个物理表中确定所述数据查询请求对应的目标物理表,所述目标元数据基于所述至少两个物理表确定,所述至少两个物理表包括基础表和根据需求进行预聚合计算后得到的预聚合表,所述基础表用于记录基础数据,任一预聚合表用于记录至少两种粒度的数据;
第二获取单元,用于基于所述数据查询请求和所述目标物理表,获取所述数据查询请求对应的目标查询数据。
13.一种计算机设备,其特征在于,所述计算机设备包括处理器和存储器,所述存储器中存储有至少一条计算机程序,所述至少一条计算机程序由所述处理器加载并执行,以实现如权利要求1至11任一所述的数据查询方法。
14.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质中存储有至少一条计算机程序,所述至少一条计算机程序由处理器加载并执行,以实现如权利要求1至11任一所述的数据查询方法。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011452389.5A CN112269792B (zh) | 2020-12-11 | 2020-12-11 | 数据查询方法、装置、设备及计算机可读存储介质 |
PCT/CN2021/128244 WO2022121560A1 (zh) | 2020-12-11 | 2021-11-02 | 数据查询方法、装置、设备及计算机可读存储介质 |
US17/980,380 US11989176B2 (en) | 2020-12-11 | 2022-11-03 | Data query method and apparatus, device, and computer-readable storage medium |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011452389.5A CN112269792B (zh) | 2020-12-11 | 2020-12-11 | 数据查询方法、装置、设备及计算机可读存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN112269792A true CN112269792A (zh) | 2021-01-26 |
CN112269792B CN112269792B (zh) | 2021-07-02 |
Family
ID=74350018
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202011452389.5A Active CN112269792B (zh) | 2020-12-11 | 2020-12-11 | 数据查询方法、装置、设备及计算机可读存储介质 |
Country Status (3)
Country | Link |
---|---|
US (1) | US11989176B2 (zh) |
CN (1) | CN112269792B (zh) |
WO (1) | WO2022121560A1 (zh) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113742312A (zh) * | 2021-01-28 | 2021-12-03 | 北京沃东天骏信息技术有限公司 | 一种数据库的运维管理方法和装置 |
CN114004190A (zh) * | 2022-01-05 | 2022-02-01 | 芯行纪科技有限公司 | 基于物理版图的多层级信息获取及可扩展操作的方法 |
CN114356965A (zh) * | 2022-03-18 | 2022-04-15 | 杭州湖畔网络技术有限公司 | 动态表单的生成方法、系统、服务器及存储介质 |
CN114357276A (zh) * | 2021-12-23 | 2022-04-15 | 北京百度网讯科技有限公司 | 数据查询方法、装置、电子设备以及存储介质 |
WO2022121560A1 (zh) * | 2020-12-11 | 2022-06-16 | 腾讯科技(深圳)有限公司 | 数据查询方法、装置、设备及计算机可读存储介质 |
CN115455010A (zh) * | 2022-11-09 | 2022-12-09 | 以萨技术股份有限公司 | 一种基于milvus数据库的数据处理方法、电子设备及存储介质 |
WO2022262737A1 (zh) * | 2021-06-17 | 2022-12-22 | 中兴通讯股份有限公司 | 数据处理方法、装置、芯片及计算机可读存储介质 |
CN116226297A (zh) * | 2023-05-05 | 2023-06-06 | 深圳市唯特视科技有限公司 | 数据模型的可视化搜索方法、系统、设备及存储介质 |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115292353B (zh) * | 2022-10-09 | 2022-12-27 | 腾讯科技(深圳)有限公司 | 数据查询方法、装置、计算机设备和存储介质 |
CN115934846A (zh) * | 2023-02-06 | 2023-04-07 | 北京仁科互动网络技术有限公司 | 列式储存数据库clickhouse的数据同步方法 |
CN117573698B (zh) * | 2024-01-15 | 2024-04-05 | 广州思迈特软件有限公司 | 数据查询方法及存储介质 |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102682118A (zh) * | 2012-05-15 | 2012-09-19 | 北京久其软件股份有限公司 | 一种多维数据模型访问方法及装置 |
CN104317936A (zh) * | 2014-10-31 | 2015-01-28 | 北京思特奇信息技术股份有限公司 | 一种基于星型模型的rolap解析引擎设计方法及装置 |
US20170322974A1 (en) * | 2016-05-06 | 2017-11-09 | InsightSoftware.com International | Sql double counting resolver |
CN108241692A (zh) * | 2016-12-26 | 2018-07-03 | 北京国双科技有限公司 | 数据的查询方法及装置 |
CN110377668A (zh) * | 2019-06-18 | 2019-10-25 | 深圳市华傲数据技术有限公司 | 数据分析方法和系统 |
CN111061767A (zh) * | 2019-12-10 | 2020-04-24 | 美林数据技术股份有限公司 | 一种基于内存计算与sql计算的数据处理方法 |
CN111309729A (zh) * | 2020-02-13 | 2020-06-19 | 湖南快乐阳光互动娱乐传媒有限公司 | 一种数据查询方法及装置 |
Family Cites Families (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6408292B1 (en) * | 1999-08-04 | 2002-06-18 | Hyperroll, Israel, Ltd. | Method of and system for managing multi-dimensional databases using modular-arithmetic based address data mapping processes on integer-encoded business dimensions |
WO2008092147A2 (en) * | 2007-01-26 | 2008-07-31 | Information Resources, Inc. | Analytic platform |
CA2792871A1 (en) * | 2010-03-11 | 2011-09-15 | Entegrity LLC | Methods and systems for data aggregation and reporting |
US20120005151A1 (en) * | 2010-07-01 | 2012-01-05 | Vineetha Vasudevan | Methods and systems of content development for a data warehouse |
US10642852B2 (en) * | 2016-09-26 | 2020-05-05 | Splunk Inc. | Storing and querying metrics data |
CN108572963A (zh) * | 2017-03-09 | 2018-09-25 | 北京京东尚科信息技术有限公司 | 信息获取方法和装置 |
US10198532B2 (en) * | 2017-03-15 | 2019-02-05 | Sas Institute Inc. | Reducing data storage, memory, and computational time needed for ad-hoc data analysis |
CN108804459B (zh) * | 2017-05-02 | 2020-10-09 | 杭州海康威视数字技术股份有限公司 | 数据查询方法及装置 |
US11354373B2 (en) * | 2018-12-14 | 2022-06-07 | Sisense Ltd. | System and method for efficiently querying data using temporal granularities |
US10990612B2 (en) * | 2018-12-28 | 2021-04-27 | Microsoft Technology Licensing, Llc | Metric-centric transformations of multidimensional database data |
US11334594B2 (en) * | 2019-10-19 | 2022-05-17 | Microsoft Technology Licensing, Llc | Data model transformation |
CN112269792B (zh) * | 2020-12-11 | 2021-07-02 | 腾讯科技(深圳)有限公司 | 数据查询方法、装置、设备及计算机可读存储介质 |
-
2020
- 2020-12-11 CN CN202011452389.5A patent/CN112269792B/zh active Active
-
2021
- 2021-11-02 WO PCT/CN2021/128244 patent/WO2022121560A1/zh active Application Filing
-
2022
- 2022-11-03 US US17/980,380 patent/US11989176B2/en active Active
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102682118A (zh) * | 2012-05-15 | 2012-09-19 | 北京久其软件股份有限公司 | 一种多维数据模型访问方法及装置 |
CN104317936A (zh) * | 2014-10-31 | 2015-01-28 | 北京思特奇信息技术股份有限公司 | 一种基于星型模型的rolap解析引擎设计方法及装置 |
US20170322974A1 (en) * | 2016-05-06 | 2017-11-09 | InsightSoftware.com International | Sql double counting resolver |
CN108241692A (zh) * | 2016-12-26 | 2018-07-03 | 北京国双科技有限公司 | 数据的查询方法及装置 |
CN110377668A (zh) * | 2019-06-18 | 2019-10-25 | 深圳市华傲数据技术有限公司 | 数据分析方法和系统 |
CN111061767A (zh) * | 2019-12-10 | 2020-04-24 | 美林数据技术股份有限公司 | 一种基于内存计算与sql计算的数据处理方法 |
CN111309729A (zh) * | 2020-02-13 | 2020-06-19 | 湖南快乐阳光互动娱乐传媒有限公司 | 一种数据查询方法及装置 |
Non-Patent Citations (2)
Title |
---|
中国地质环境监测院: "《地质灾害防治信息化建设理论与技术方法》", 30 June 2016, 北京:地质出版社 * |
郭彦丽 等: "《商务智能 实战案例分析》", 31 August 2017, 北京:北京理工大学出版社 * |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2022121560A1 (zh) * | 2020-12-11 | 2022-06-16 | 腾讯科技(深圳)有限公司 | 数据查询方法、装置、设备及计算机可读存储介质 |
US11989176B2 (en) | 2020-12-11 | 2024-05-21 | Tencent Technology (Shenzhen) Company Limited | Data query method and apparatus, device, and computer-readable storage medium |
CN113742312A (zh) * | 2021-01-28 | 2021-12-03 | 北京沃东天骏信息技术有限公司 | 一种数据库的运维管理方法和装置 |
WO2022262737A1 (zh) * | 2021-06-17 | 2022-12-22 | 中兴通讯股份有限公司 | 数据处理方法、装置、芯片及计算机可读存储介质 |
WO2023116086A1 (zh) * | 2021-12-23 | 2023-06-29 | 北京百度网讯科技有限公司 | 数据查询方法、装置、电子设备以及存储介质 |
CN114357276A (zh) * | 2021-12-23 | 2022-04-15 | 北京百度网讯科技有限公司 | 数据查询方法、装置、电子设备以及存储介质 |
CN114357276B (zh) * | 2021-12-23 | 2023-08-22 | 北京百度网讯科技有限公司 | 数据查询方法、装置、电子设备以及存储介质 |
CN114004190A (zh) * | 2022-01-05 | 2022-02-01 | 芯行纪科技有限公司 | 基于物理版图的多层级信息获取及可扩展操作的方法 |
CN114356965A (zh) * | 2022-03-18 | 2022-04-15 | 杭州湖畔网络技术有限公司 | 动态表单的生成方法、系统、服务器及存储介质 |
CN114356965B (zh) * | 2022-03-18 | 2022-06-14 | 杭州湖畔网络技术有限公司 | 动态表单的生成方法、系统、服务器及存储介质 |
CN115455010A (zh) * | 2022-11-09 | 2022-12-09 | 以萨技术股份有限公司 | 一种基于milvus数据库的数据处理方法、电子设备及存储介质 |
CN115455010B (zh) * | 2022-11-09 | 2023-02-28 | 以萨技术股份有限公司 | 一种基于milvus数据库的数据处理方法、电子设备及存储介质 |
CN116226297A (zh) * | 2023-05-05 | 2023-06-06 | 深圳市唯特视科技有限公司 | 数据模型的可视化搜索方法、系统、设备及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
US20230073666A1 (en) | 2023-03-09 |
WO2022121560A1 (zh) | 2022-06-16 |
CN112269792B (zh) | 2021-07-02 |
US11989176B2 (en) | 2024-05-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN112269792B (zh) | 数据查询方法、装置、设备及计算机可读存储介质 | |
US11537635B2 (en) | Hadoop OLAP engine | |
Ali et al. | Comparison between SQL and NoSQL databases and their relationship with big data analytics | |
Zafar et al. | Big data: the NoSQL and RDBMS review | |
Song et al. | HaoLap: A Hadoop based OLAP system for big data | |
US20130191523A1 (en) | Real-time analytics for large data sets | |
Chavan et al. | Survey paper on big data | |
Liang et al. | Express supervision system based on NodeJS and MongoDB | |
WO2016168211A1 (en) | High performance big data computing system and platform | |
US20100235344A1 (en) | Mechanism for utilizing partitioning pruning techniques for xml indexes | |
CN105159971B (zh) | 一种云平台数据检索方法 | |
Vajk et al. | Automatic NoSQL schema development: A case study | |
Oussous et al. | NoSQL databases for big data | |
Hashem et al. | Evaluating NoSQL document oriented data model | |
Shakhovska et al. | Big Data Model" Entity and Features" | |
Dhanda | Big data storage and analysis | |
Krstić et al. | Testing the performance of NoSQL databases via the database benchmark tool | |
Singh | NoSQL: A new horizon in big data | |
ElDahshan et al. | A COMPARATIVE STUDY AMONG THE MAIN CATEGORIES OF NoSQL DATABASES | |
Babić et al. | Querying data in NoSQL databases | |
SEMI-STRUCTURED et al. | Mohamad Hasan Evgeny Panidi Vladimir Badenko | |
Bayomy et al. | Adopting Quality Attributes Based Quantitatively Methodology Using Deep Learning to NoSQL Databases | |
Ahuja et al. | Data: Its Nature and Modern Data Analytical Tools | |
Siddesh et al. | Driving big data with hadoop technologies | |
Vyawahare et al. | NoSql Database |
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 | ||
REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40037483 Country of ref document: HK |
|
GR01 | Patent grant | ||
GR01 | Patent grant |