CN114385555A - 一种数据查询方法、装置、设备及存储介质 - Google Patents
一种数据查询方法、装置、设备及存储介质 Download PDFInfo
- Publication number
- CN114385555A CN114385555A CN202011638412.XA CN202011638412A CN114385555A CN 114385555 A CN114385555 A CN 114385555A CN 202011638412 A CN202011638412 A CN 202011638412A CN 114385555 A CN114385555 A CN 114385555A
- Authority
- CN
- China
- Prior art keywords
- file
- data
- attributes
- files
- 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.)
- Pending
Links
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/10—File systems; File servers
- G06F16/14—Details of searching files based on file metadata
- G06F16/148—File search processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/13—File access structures, e.g. distributed indices
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Library & Information Science (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本申请公开了一种数据查询方法、装置、设备及存储介质,数据处理系统在接收到数据查询请求后,并非是从数据量较大的第一文件中查询用户所需的目标数据,而是从数据量较小的第二文件中查询目标数据。其中,该多个第二文件具体是根据第一文件生成。第一文件与第二文件均可以是聚合数据形成的文件或者没有经过聚合处理的原始数据形成的文件,或者第一文件为原始数据形成的文件,第二文件为聚合数据形成的文件。由于每次查询数据时,是遍历数据量较小的第二文件,从而可以有效减少数据查询过程中所需遍历的数据量,进而可以有效提升查询数据的效率。
Description
本申请要求于2020年10月19日提交中国国家知识产权局、申请号为202011118445.1、申请名称为“一种加快数据聚合查询的方法”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
技术领域
本申请实施例涉及数据处理技术领域,尤其涉及一种数据查询方法、装置、设备及存储介质。
背景技术
在大数据时代,每次从海量数据中所查询到的数据,通常是海量数据中的冰山一角,即最终查询到的数据为海量数据中的一小部分数据,而在查询过程中需要遍历数据的数据量较大,这种查询方式通常称之为“冰山查询”。但是,由于每次查询数据时需要遍历的数据量较大,遍历时间较长,这使得“冰山查询”的查询效率通常较低。因此,目前亟需一种能够有效提高数据查询效率的数据查询方法。
发明内容
本申请实施例提供一种数据查询方法、装置、设备、存储介质以及计算机程序产品,以有效提高数据查询效率。
第一方面,本申请实施例提供一种数据查询方法,数据处理系统在接收到数据查询请求后,可以从多个第二文件中确定出包括用户所需查询的目标数据的目标文件,并在该目标文件中查询出目标数据。其中,该数据查询请求用于在数据量较大的第一文件中查询目标数据,而第一文件对应于多个第二文件,并且该多个第二文件具体是根据第一文件生成的,从而每个第二文件的数据量小于第一文件的数据量。由于在查询目标数据的过程中,是对数据量较小的第二文件进行遍历,而并非是对数据量较大的第一文件进行遍历,如此,可以有效减少数据查询过程中所需遍历的数据量,从而可以有效提升查询数据的效率。
其中,第一文件可以是原始数据所形成的文件,第二文件可以是基于原始数据所生成的数据量更少的文件;或者,第一文件可以是基于对原始数据进行预聚合后得到的聚合数据所生成的文件,而第二文件可以是基于该聚合数据所生成的数据量更少的文件;再或者,第一文件为原始数据所形成的文件,而第二文件可以是对原始数据进行预聚合后生成的包括聚合数据的文件,每个第二文件中所包括的聚合数据的数据量小于所有原始数据对应的聚合数据的数据量。本实施例中,对于第一文件以及第二文件的具体实现方式并不进行限定。
在一种可能的实施方式中,第一文件包括多个属性,而第二文件包括多个属性中的至少一个属性,则数据处理系统在从多个第二文件中确定包括目标数据的目标文件时,具体可以是根据数据查询请求中的目标属性从多个第二文件中确定出包括目标属性的第二文件作为目标文件。如此,可以根据所需查询的目标数据所具有的目标属性,快速定位出具有该目标属性的第二文件,从而可以从该第二文件中查找出用户所需的目标数据。
在一种可能的实施方式中,在目标文件中查询目标数据时,数据处理系统具体可以是将基于数据查询请求所生成的计划树中的第一文件替换为确定出的目标文件,即通过修改计划树中的访问逻辑实现将对第一文件的访问修改为对目标文件的访问,以便实现从数据量较小的目标文件中查询数据。
在一种可能的实施方式中,第一文件基于原始数据进行生成,而数据处理系统可以根据第一文件中的多个属性中的预设属性对于第一文件进行聚合运算得到聚合文件,然后,在生成多个文件时,数据处理系统具体可以将聚合文件根据预设属性(一个或者多个属性)所包括的值进行分区,从而将聚合文件划分为多个部分,并且每个分区包括至少一个值对应的数据,针对于每个分区可以单独形成一个第二文件。如此,基于第一文件划分得到多个数据量较小的第二文件,可以降低后续数据查询过程中所需遍历的数据量。
在一种可能的实施方式中,所述每个聚合文件不仅包括聚合数据,还可以包括生成该聚合数据所对应的原始数据。
在一种可能的实施方式中,数据处理系统在将聚合文件根据预设属性所包括的值进行分区时,具体可以是在内存中对聚合文件根据预设属性所包括的值进行分区,从而在形成第二文件时,具体可以是在对起重一个分区中的数据进行序列化形成第二文件,并将该第二文件持久化存储后,再对下一个分区中的数据进行序列化处理。如此,可以在内存中多多个第二文件逐个进行序列化,并且,数据处理系统有限的物理内存通常更容易支持每次对较小数据量的聚合数据进行序列化,从而可以尽可能避免因为数据处理系统的物理内存空间不足而导致分区数据的序列化过程失败。
在一种可能的实施方式中,数据处理系统可以是通过属性组合的方式生成第二文件,具体的,针对于每个第二文件,数据处理系统可以从第一文件中的N个属性中获取M个属性,并基于该M个属性对应的数据形成第二文件,从而可以得到包括M值相同的第二文件以及M值不同的第二文件,并且,M值相同的第二文件所包括的属性也不完全相同。如此,通过属性组合的方式,所得到的不同第二文件对应于不同的属性组合。
在一种可能的实施方式中,数据处理系统在从第一文件中的N个属性中获取M个属性,并且该M个属性对应的数据形成第二文件时,具体可以是将第一文件读取至内存,并从该第一文件中获取M个属性,然后,对M个属性对应的数据进行聚合运算,从而可以对聚合运算后的数据进行序列化,形成第二文件。如此,可以实现多个数据量较小的第二文件生成。
在一种可能的实施方式中,当第二文件中包括聚合数据时,数据处理系统还可以对在目标文件中查询到的目标数据进行二次聚合运算,并将经过二次聚合运算所得到的数据作为查询结果反馈给用户。如此,可以进一步方便用户快速获取其所需查询的数据。
在一种可能的实施方式中,每个第二文件的数据量大于一定阈值,这样,所存储的各个第二文件的数量可以较少,相应的,所需存储的各个第二文件的元数据的数量也减少。如此,可以避免由于第二文件的元数据过多而导致数据查询效率被降低。
第二方面,基于与第一方面的方法实施例同样的发明构思,本申请实施例提供了一种数据查询装置。该装置具有实现上述第一方面的各实施方式对应的功能。该功能可以通过硬件实现,也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。
第三方面,本申请实施例提供一种设备,包括:处理器和存储器;该存储器用于存储指令,当该计算装置运行时,该处理器执行该存储器存储的该指令,以使该设备执行上述第一方面或第一方面的任一实现方式中的数据查询方法。需要说明的是,该存储器可以集成于处理器中,也可以是独立于处理器之外。装置还可以包括总线。其中,处理器通过总线连接存储器。其中,存储器可以包括可读存储器以及随机存取存储器。
第四方面,本申请实施例还提供一种可读存储介质,所述可读存储介质中存储有程序或指令,当其在计算机上运行时,使得上述第一方面或第一方面的任一实现方式中的数据查询方法被执行。
第五方面,本申请实施例还提供一种包含指令的计算机程序产品,当其在计算机上运行时,使得计算机执行上述第一方面或第一方面的任一实现方式中的任意数据查询方法。
另外,第二方面至六方面中任一种实现方式所带来的技术效果可参见第一方面中不同实现方式所带来的技术效果,或者可参见第二方面中不同实现方式所带来的技术效果,此处不再赘述。
附图说明
为了更清楚地说明本申请实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请中记载的一些实施例,对于本领域普通技术人员来讲,还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的一示例性数据处理系统的结构示意图;
图2为一示例性原始数据示意图;
图3为本申请实施例提供的一种数据查询方法的流程示意图;
图4为本申请实施例的一示例性查询语句输入界面示意图;
图5为对图2所示原始数据进行聚合后得到的聚合数据示意图;
图6为本申请实施例提供的又一示例性数据处理系统的结构示意图;
图7为本申请实施例提供的生成第二文件的方法流程示意图;
图8为基于第一文件生成多个第二文件的示意图;
图9为本申请实施例提供的属性组合界面的示意图;
图10为本申请实施例提供的一示例性树形索引结构示意图;
图11为生成第二文件以及利用第二文件支持数据查询的流程示意图;
图12为本申请实施例提供的一种数据查询装置的结构示意图;
图13为本申请实施例提供的一种设备的硬件结构示意图。
具体实施方式
参见图1,为一示例性数据处理系统的结构示意图。如图1所示,数据处理系统100可以包括协调节点(coordinator node)101、执行节点(worker node)102。其中,执行节点102可以访问数据源103中的原始数据(original data),数据源103可以包括一种或者多种数据源,如图1所示的hive、oracle数据源等。
数据处理系统100可以对外提供客户端(client)104,用于与用户进行人机交互,以便基于用户输入的查询语句执行相应的数据查询过程。举例来说,如图2所示,数据源103中存储的原始数据可以是不同国家所使用的不同浏览器的点击量以及所使用浏览器采用的语种。用户可以在客户端104上输入结构化查询语言(Structured Query Language,SQL)语句:select sum(Impressions)from cube_test where country<‘MX’and browser<‘firefox’group by browser,以期望查询“country”属性的属性值小于“MX”并且“browser”属性的属性值小于“Firefox”的浏览器点击量总和(sum(Impressions))。协调节点101可以通过客户端104接收到用户输入的SQL语句,并对该SQL语句进行语法分析以及语义分析。其中,语法分析,是指协调节点101利用SQL语言的语法规则校验该SQL语句是否存在语法错误;语义分析,是指协调节点101分析该SQL语句的语义是否合法。当SQL语句的语法以及语义均合法后,协调节点101可以根据该SQL语句生成计划树,该计划树指示了对数据进行计算、分析以及访问等操作的执行计划。然后,协调节点101可以通过一个或者多个优化器对计划树进行优化,并将优化后所得到的计划树发送给执行节点102执行,具体可以是通过相应的调度器确定将计划树发送至执行节点102中的哪个执行器进行执行。执行节点102,可以由一个或者多个执行器构成(图1中以包括执行器1至执行器N作为示例),其可以根据接收到的计划树执行相应计划:从数据源103中读取“country”属性的属性值小于“MX”并且“browser”属性的属性值小于“firefox”的原始数据(即图2中文件编号0、1、2的三行数据),并根据读取到的原始数据对点击量进行求和计算,计算结果为“500”(即0+100+400),然后再将该计算结果“500”(也即此次查询结果)通过协调节点101返回给客户端104,以便在客户端104上该计算结果“400”呈现给用户。
图2所示的数据源103中存储的原始数据仅作为一种示例,实际应用时,数据源103中存储的原始数据的数据量通常较为庞大,如其行数可能达到千万级甚至亿级等。此时,执行节点102所需遍历的原始数据过多而使得数据处理系统100查询数据的效率降低。
基于此,本申请实施例提供了一种数据查询方法,用以提高数据处理系统100查询数据的效率。具体实现时,数据处理系统100可以根据接收到的数据查询请求,从多个数据量较小的文件中确定出包含所需查询的目标数据的目标文件,并在确定出的数据量较小的目标文件中查询目标数据,而并非是从数据量较大的海量数据中查询数据,由于所需遍历的数据量得到有效减少,从而数据处理系统100查询数据的效率可以得到有效提升。
为使本申请的上述目的、特征和优点能够更加明显易懂,下面将结合附图对本申请实施例中的各种非限定性实施方式进行示例性说明。显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例,都属于本申请保护的范围。
如图3所示,为本申请实施例中一种数据查询方法的流程示意图,该方法可以应用于如图1所示的数据处理系统100中,并可以由数据处理系统100或者该数据处理系统100中相应的节点执行,本实施例中,以数据处理系统100中的多个节点协同执行该方法为例进行示例性说明,该方法具体可以包括:
S301:协调节点101接收数据查询请求,该数据查询请求用于在第一文件中查询目标数据,其中,第一文件对应于多个第二文件,该多个第二文件具体是根据第一文件生成,并且每个第二文件的数据量小于第一文件的数据量。
数据处理系统100所能访问的数据源103中的原始数据在被存储时,可以形成数据量较大的文件,以下称之为第一文件。用户所需的目标数据即可以从该第一文件中进行查询。
本实施例中,数据处理系统100可以预先根据第一文件生成多个数据量较小的第二文件,其中,每个第二文件的数据量小于第一文件的数据量,并且,不同第二文件所包含的数据存在差异,该第一文件以及第二文件可以用于支持数据处理系统100的数据查询任务。其中,基于第一文件如何生成多个不同的第二文件的具体实现方式,可以参见后文相关之处描述,在此不做赘述。
作为一种接收数据查询请求的实施示例,数据处理系统100包括客户端104,并且,该客户端104可以向用户呈现如图4所示的查询语句输入界面。用户可以在该客户端104呈现的查询语句输入界面上的特定区域内输入相应的查询语句,以便数据处理系统100反馈用户所期望的查询结果。比如,对于图2所示的原始数据,用户可以在查询语句输入界面上输入SQL语句:select sum(Impressions)from cube_test where country<‘MX’andbrowser<‘firefox’group by browser,以期望查询“country”属性的属性值小于“MX”并且“browser”属性的属性值小于“Firefox”的浏览器点击量总和(sum(Impressions))。然后,客户端104基于该数据查询语句生成相应的数据查询请求,并将该数据查询请求发送给协调节点101,以便基于该数据查询请求查询到用户所需的目标数据。
值得注意的是,本实施例中是以第一文件为原始数据所形成的文件为例进行说明,在其它实施例中,第一文件也可以是基于原始数据进行预聚合后得到的聚合数据所形成的文件。基于第一文件与第二文件的具体实现存在如下组合:
第一文件可以是原始数据形成的文件,第二文件为基于原始数据所生成的数据量更少的文件,如可以直接将第一文件划分成多个数据量较小的多个第二文件等。
或者,第一文件可以是基于对原始数据进行预聚合后得到的聚合数据所生成的文件,而第二文件可以是基于该聚合数据所生成的数据量更少的文件,此时,第二文件中的数据可以是聚合数据,并且,每个第二文件中所包含的聚合数据的数据量小于该第一文件中所包括的聚合数据的数据量。
再或者,第一文件为原始数据所形成的文件,而第二文件可以是对原始数据进行预聚合后生成的包括聚合数据的文件,并且每个第二文件中所包括的聚合数据的数据量小于所有原始数据对应的聚合数据的数据量。本实施例中,对于第一文件以及第二文件的具体实现方式并不进行限定。
其中,数据处理系统100可以针对于海量的原始数据,基于一个属性或者属性集(包括多个属性)对具有该属性的数据计算聚合值,可以称之为预聚合(pre-aggregation),比如可以是将多个具有相同属性的原始数据聚合为新的数据(也即为上述聚合数据),例如图2所示的原始数据经过聚合运算后可以得到如图5所示的聚合数据等,该聚合数据具有原始数据的部分或者全部属性,而聚合数据的属性值可以是该多个原始数据的属性值的累加等。这样,在查询数据时,数据处理系统100可以直接查找出用户所期望的聚合数据(也即预先计算出的聚合值),而可以不用查找原始数据再进行聚合运算,从而可以有效提高数据查询效率。
S302:协调节点101从多个第二文件中确定包括目标数据的目标文件。
通常情况下,第一文件包含用户所需的目标数据,但是由于第一文件中数据量较多,若通过遍历第一文件中数据以查找出目标数据,则数据处理系统100的数据查询效率会因为所需遍历的数据量过多而被降低。因此,本实施例中,数据处理系统100在查询目标数据时,并非是从第一文件中遍历数据,而是从数据量较小的一个或者多个第二文件中遍历出用户所需的目标数据。
示例性的,协调节点101基于接收到的数据查询请求进行语义、语法分析,并根据该数据查询请求生成计划树,此时,该计划树计划访问的文件为第一文件。然后协调节点101可以根据该数据查询请求确定目标数据的目标属性,比如,当用户输入针对图2所示原始数据的查询语句为:select sum(Impressions)from cube_test where country<‘MX’group by browser时,协调节点101可以根据基于该查询语句生成的数据查询请求确定查询条件为:查找属性“country”(国家)的属性值小于“MX”的目标数据,则该目标数据的目标属性为“country”。接着,协调节点101可以根据该目标属性以及各个第二文件对应的元数据(该元数据描述了第二文件的属性和/或属性值范围),从多个第二文件中确定出与该目标属性相符合的目标文件,如可以将具有该目标属性的第二文件作为目标文件。其中,目标文件可以包括一个或者多个第二文件。最后,协调节点101可以基于确定出的目标文件改写计划树的执行逻辑,即将计划树中对于第一文件的访问逻辑替换为对于目标文件的访问逻辑,并将修改后的计划树发送给执行节点,以便于执行节点基于该计划树从相应的第二文件中查询用户所需数据。
在进一步可能的实施方式中,协调节点101还可以利用一个或者多个优化器对修改后的计划树进行优化,并将优化后的计划树发送给执行节点102,以便进一步提高执行节点102查询目标数据的效率。
S303:执行节点102在确定出的目标文件中查询目标数据。
具体实现时,执行节点102可以根据接收到的计划树确定对目标文件进行访问,并从确定的目标文件中遍历数据,以查询到满足查询条件的数据,该数据也即为用户所需的目标数据。
需要说明的是,由于在查询目标数据的过程中,是从数据量较小的目标文件(也即第二文件)中进行数据遍历,而并非是从数据量较大的第一文件中进行遍历,如此,可以有效减少数据查询过程中所需遍历的数据量,从而可以有效提升查询数据的效率。
进一步的,对于执行节点102在目标文件中所访问到的目标数据,可以将其通过协调节点101转发给客户端104,以便客户端104可以向用户呈现查询到的目标数据。
在一些可能的实施方式中,目标文件中的数据为原始数据,此时,执行节点102可以对该原始数据进行聚合,并将聚合得到的聚合数据反馈给客户端104,从而客户端104向用户呈现的查询结果为聚合数据。或者,目标文件中的数据为基于原始数据所得到的聚合数据时,执行节点102还可以对该目标文件中的部分或者全部聚合数据(也即目标数据)进行二次聚合运算,并将二次聚合运算后所得到的聚合数据作为查询结果反馈给客户端104,以便于客户端104将其呈现给用户。
图3所示实施例中,是以数据处理系统处理数据查询请求的角度对本申请实施例的技术方案进行示例。实际应用时,数据处理系统在处理数据查询请求之前,还可以预先根据第一文件生成多个不同的第二文件,并且,第二文件中的数据可以是原始数据,也可以是基于原始数据所生成的聚合数据。以下将以第一文件中的数据为原始数据、第二文件中的数据为聚合数据为例,对本申请实施例中生成第二文件的具体实现过程进行示例性描述。
参阅图6,在图1所示的数据处理系统基础上,还可以新增聚合节点105,并由聚合节点105实现对原始数据进行聚合运算以及将得到的聚合数据序列化至数据源103中。其中,序列化,是指将数据由当前格式(如Java语言中的对象格式)转换为存储格式,以使得该数据能够在存储区域中存储。当然,在其它实施方式中,也可以是将聚合数据序列化至数据处理系统100中的其它节点,或者序列化至聚合节点105所能访问的其它位置,如本地文件系统或者分布式文件系统(hadoop distributed file system,HDFS)等。为便于描述,下面以图6所示的新增聚合节点105执行聚合数据序列化方法并将聚合数据序列化至数据源103为例,对本申请实施例的技术方案进行示例性说明。如图7所示,生成第二文件的方法流程具体可以包括:
S701:聚合节点105获取第一文件,该第一文件是由原始数据形成。
原始数据,即为本实施例中需要进行聚合的数据,其在数据源103中存储时可以形成第一文件,而聚合节点105可以通过访问数据源103以获取包括原始数据的第一文件。
其中,聚合节点105可以由软件实现。例如,聚合节点105可以是作为功能模块,与执行节点102部署于同一物理设备(如服务器等网络设备等)。可选地,为了提升聚合节点105的运算能力,也可以利用单独的硬件实现聚合节点105的功能。例如,该聚合节点105可以是独立于执行节点102进行配置的服务器等设备,或者,可以是利用专用集成电路(application-specific integrated circuit,ASIC)实现,或可编程逻辑器件(programmable logic device,PLD)实现,上述PLD可以是复杂程序逻辑器件(complexprogrammable logical device,CPLD),现场可编程门阵列(field-programmable gatearray,FPGA),通用阵列逻辑(generic array logic,GAL)或其任意组合实现,并可以集成于执行节点102所在物理设备。
S702:聚合节点105根据获取的第一文件,生成多个不同的第二文件,其中,每个第二文件所包括的聚合数据的数据量小于第一文件中原始数据对应的所有聚合数据的数据量。
S703:聚合节点105对多个第二文件逐个进行序列化。
本实施例中,聚合节点105可以对于获取的第一文件中的原始数据进行聚合运算,生成原始数据对应的聚合数据,这样,后续数据处理系统100在查询数据时,可以从聚合数据中查找出用户所需的目标数据。由于聚合数据的数据量通常小于原始数据的数据量,因此,数据处理系统100从聚合数据中查找出目标数据的查询效率,通常可以高于从原始数据中查找出目标数据的查询效率。
通常情况下,聚合节点105会将聚合数据序列化到持久性存储区域(如硬盘等)。由于聚合数据的格式与该聚合数据在持久性存储区域中的存储格式并不相同,如计算得到的聚合数据在jave语言中通常作为对象存在,而在聚合数据可能是以二进制数据进行存储(或者转换成其它格式进行存储)。因此,聚合节点105在存储聚合数据之前,通常会先在内存中将该聚合数据进行格式转换,并在将所有聚合数据全部完成格式转换后,再从该内存中将格式转换后的聚合数据写入相应的存储区域。
但是,基于海量的原始数据所计算出的聚合数据的数据量通常也较大,这使得在聚合节点105在将聚合数据序列化到持久性存储区域时,可能会因为数据处理系统100的物理内存空间的限制而无法在物理内存中将生成的所有聚合数据的格式全部转换为存储格式,即在转换部分聚合数据后数据处理系统100的物理内存已经被占用完全,无法支持剩余聚合数据的格式转换,从而导致聚合数据的序列化过程失败。
为此,本实施例中,聚合节点105可以根据第一文件生成多个数据量较小的第二文件,以便聚合节点105在序列化聚合数据时,每次可以仅对较小数据量的第二文件进行序列化,从而提高聚合数据的序列化成功率。
在一种生成第二文件的实施方式中,聚合节点105可以是通过属性组合来聚合原始数据,从而根据不同属性组合生成不同第二文件。具体的,在生成第二文件时,聚合节点105可以从第一文件的N个属性中获取M个属性(M<N,且均正整数),并将第一文件读取至内存;然后,聚合节点105可以在内存中根据该M个属性对第一文件进行聚合运算,得到该M个属性对应的聚合数据;接着,聚合节点105可以将该M个属性对应的聚合数据进行序列化,形成第二文件,并将该第二文件存储至持久化存储区域,如硬盘等。其中,基于第一文件的N个属性可以得到多种不同的属性组合,不同属性组合所包括属性数量和/或属性类别之间存在差异,每种属性组合可以生成一个第二文件。例如,对于图1所示的第一文件,其所具有的属性可以包括“国家”(country)、“浏览器”(browser)、“语种”(languages,属于区域设置中的一种)以及“点击量”(impressions),则聚合节点105基于这四种属性所得到的属性组合可以有(国家,浏览器,点击量)、(国家、语种、点击量)、(浏览器,语种,点击量)、(国家,点击量)、(浏览器,点击量)、(语种,点击量)这6种属性组合。然后,聚合节点105可以分别根据每个属性组合所包括的属性,对第一文件进行聚合,得到多个不同的第二文件,例如基于上述6种属性组合可以得到如图8所示的多个第二文件。其中,针对于每个第二文件,其聚合数据的数据量均小于利用四种属性对该原始数据进行聚合后所得到的所有聚合数据。
作为一种示例,属性的组合方式,除了可以是由聚合节点105根据不同属性进行自由组合之外,也可以是由用户进行确定。比如,数据处理系统100可以对外向用户呈现如图9所示的属性组合界面,该属性组合界面例如可以是通过客户端104呈现给用户;用户可以在该属性组合界面上定义原始数据对应的属性,如定义“国家”、“浏览器”、“语种”以及“点击量”等属性,并由用户基于定义的属性在该界面上输入多种属性组合。这样,聚合节点105可以根据用户输入的多种属性组合生成相应的多个第二文件。
在另一种生成第二文件的示例性实现方式中,聚合节点105可以先根据第一文件生成所有的聚合数据,该所有的聚合数据可以形成聚合文件,然后,聚合节点105可以将该聚合文件划根据预设属性所包括的值进行分区,例如具体可以是在内存中对聚合文件进行分区,从而每个分区可以形成一个第二文件,如此,对第一文件进行分区后,可以形成多个不同的第二文件,不同第二文件中预设属性的属性值不同,每个第二文件中包括的聚合数据均为原始数据对应的所有聚合数据的子集,从而每个第二文件中包括的聚合数据的数据量小于原始数据对应的所有聚合数据的数据量。其中,该预设属性可以包括一种属性,也可以是包括多种属性,本实施例对此并不进行限定。
相应的,在序列化每个第二文件时,可以在对其中一个分区中的聚合数据进行序列化形成第二文件,并将该第二文件持久化存储后,再对下一个分区的聚合数据进行序列化处理,如此,可以实现对多个第二文件的逐个序列化。并且,每次序列化的第二文件的数据量较小,不容易出现因为物理空间不足而导致第二文件序列化失败的问题。
在一些实施方式中,聚合节点105在划分聚合文件时,可以是按照预设的划分规则对聚合文件进行划分,该预设的划分规则例如可以是属性的字典序、第二文件中包括的聚合数据在树形索引结构中对应的节点数量上限以及属性的属性值差值上限中的任一种或多种。
其中,属性的字典序,是指按照字典序对聚合数据对应的某种属性(以下称之为预设属性)的属性值进行排序。其中,字典序,也可以称之为字母顺序,即按照字母顺序对属性值进行排列。相应的,按照属性的字典序划分聚合数据,即是指基于一种(或者多种)预设属性,按照字典序对该预设属性的属性值进行排序,并依据排序划分聚合数据。仍以图5所示的聚合文件为例,假设预设属性为“country”,则聚合节点105可以先按照字典序对预设属性的属性值“AU”、“CA”、“MX”、“USA”进行排序,然后每隔两个属性值对该聚合文件中的聚合数据进行划分,即可以将属性值为“AU”以及“CA”的聚合数据(也即文件编号0至2的三行数据)划入一个第二文件,将属性值为“MX”、“USA”的聚合数据(也即文件编号3至7的五行数据)划入一个第二文件,每个第二文件中属性“country”的属性值仅包括两种,不同第二文件中属性“country”的属性值不同。
第二文件中包括的聚合数据在树形索引结构中对应的节点数量上限,是指聚合节点105可以基于聚合数据构成树形索引结构,聚合数据可以是该树形索引结构中的节点,从而对聚合数据进行划分,也即为对该树形索引结构的子树进行划分,而划分得到的每个子树所包括的节点数量不超过该节点数量上限。如此,该树形索引结构可以划分为多个子树,并且,每个子树对应于一个第二文件,每个子树中包括的节点对应于该第二文件中包括的相应聚合数据。
举例来说,基于图5所示的聚合数据可以生成如图10所示的树形索引结构(未显示全部的中间节点),图10所示的树形索引结构也可以是称之为星形树(star tree)。图10所示的树形索引结构可以包括根节点(root node)、中间节点(intermediate node)、叶子节点(leaf node)以及星形节点(star node)。
其中,根节点是指图10中最顶端的节点,每棵树通常仅具有一个根节点。叶子节点,是指没有子节点(或者称之为下游节点)的节点,每棵树中通常包括一个或者多个叶子节点,并且,叶子节点存储的“点击量”的值为聚合数据。中间节点,是指树中非根节点、非叶子节点以及非星形节点的其它节点,每个中间节点既具有上游节点,也具有下游节点。中间节点存储的“点击量”的值为其各个子节点的“点击量”的值之和,属于聚合数据。星形节点,为特定类型的节点,该星形节点存储“点击量”的值为同一层的其它多个节点存储的“点击量”的值之和,属于聚合数据。
图10所示的树形索引结构中,可以按照属性进行分层,其中,最顶端的一层为根节点,可以不表示聚合数据,相应的,该层节点可以不具有属性。而从根节点向下的每一层,可以表征一种属性。如图10中所示,第二层表征属性“国家”,第三层表征属性“浏览器”,第四层表征属性“语种”。相应的,聚合节点105在对图10所示的树形索引结构进行划分时,例如可以是按照属性“国家”以及“浏览器”将树形索引结构划分为5个子树,如图10所示。每个子树对应于一个第二文件,并且,每个第二文件可以包括多个聚合数据(对应于子树中的中间节点、星形节点以及叶子节点)。当然,也可以是基于一种属性对树形索引结构进行划分,本实施例对此并不进行限定。
属性的属性值差值上限,是指每个第二文件中不同聚合数据在预设属性的属性值之间的最大差值不超过该差值上限。聚合节点105在划分聚合文件时,可以计算该聚合文件中不同聚合数据在该预设属性的属性值之间的差异,从而可以以某个聚合数据的属性值为基准,将与该属性值之间的属性值差值不超过差值上限的聚合数据划入同一个第二文件;然后,继续从未划入该第二文件中的剩余聚合数据中再以一个聚合数据的属性值为基准,按照上述类似过程,将剩余聚合数据中与该属性值之间的属性值差值不超过差值上限的聚合数据划入另一个第二文件。以此类推,直至最终未划入任意一个第二文件的剩余聚合数据之间在该属性的属性值差值均不超过差值上限,则可以将最后剩余的聚合数据作为最后一个第二文件。如此,可以根据属性值差值上限划分得到多个不同的第二文件,并且,每个第二文件中的聚合数据之间在该属性的属性值差值均不超过该差值上限。
实际应用中,聚合节点105也可以是结合上述字典序、节点数量上限以及属性值差值上限中的多种信息对聚合数据进行划分,本实施例对此并不进行限定。
在一种可能的实施方式中,每个第二文件还可以具有相应的元数据,该元数据可以用于描述第二文件的数据范围,例如描述该第二文件中聚合数据的属性值范围等,以便对多个第二文件进行管理。实际应用时,该第二文件的属性值范围可以作为该第二文件的标识等。或者,第二文件的元数据可以用于描述第二文件的属性信息,比如,当基于属性组合划分得到第二文件时,元数据可以用于描述其对应的第二文件中包括的聚合数据具有哪些属性。或者,第二文件的元数据可以用于描述第二文件的数据量大小、存储位置等信息。当然,第二文件的元数据也可以是用于同时描述上述多种信息,如可以同时描述聚合数据的属性值范围以及数据量大小等,本实施例对此并不进行限定。
值得注意的是,若划分得到的每个第二文件中所包括的聚合数据的数据量较小,则对聚合数据进行划分并且进行序列化后,可能会得到数量较多的小文件,每个小文件即为第二文件完成序列化后所生成的文件。通常情况下,针对于每个小文件,数据处理系统100通常会为每个小文件生成相应的元数据,如用于描述该小文件的存储位置、存储大小、属性以及属性值范围等信息。由于小文件的数量较多,相应的,小文件对应的元数据的数量也较多,此时,较多数量的文件元数据不仅会占用数据处理系统100较多的存储资源,而且,数据处理系统100在查询数据时,需要遍历大量的元数据来定位目标文件,这就降低了数据处理系统100响应的查询效率。
因此,在进一步可能的实施方式中,聚合节点105还可以结合预设数量阈值来生成第二文件。具体的,聚合节点105在生成第二文件时,还可以确定当前生成的第二文件中包括的聚合数据的数据量是否大于预设数量阈值,并且,当其不大于该预设数量阈值时,聚合节点105可以从剩余的聚合数据中为该第二文件添加新的聚合数据,而当其大于该预设数量阈值时,聚合节点105无需添加新的聚合数据。如此,基于聚合节点105所生成的多个第二文件,既可以提高聚合数据的序列化成功率,也可以是避免聚合数据序列化后生成过多的小文件而降低数据处理系统100的数据查询效率。
实际应用时,聚合节点105不仅可以将聚合数据进行序列化,还可以将聚合数据与原始数据一起进行序列化,此时,聚合节点105所生成的第二文件中不仅可以包括聚合数据,还可以包括生成该部分聚合数据所对应的原始数据。
实际应用中,在聚合节点105完成聚合数据(或者聚合数据以及原始数据)的序列化后,数据处理系统100可以基于序列化后的多个第二文件支持相应的数据查询。
值得注意的是,上述实施例中,是以第一文件为原始数据形成的文件而第二文件为聚合数据形成的文件为例进行说明。实际应用时,第一文件与第二文件均可以是由聚合数据形成的文件,或者第一文件与第二文件均可以是原始数据形成的文件,其具体实现方式与上述实施例描述的方法过程类似,可参见前述相关之处描述,在此不做赘述。
为便于理解,本申请提供了如图11所示的生成第二文件以及利用第二文件支持数据查询的整个流程。参见图11,该流程具体包括:
S1101:聚合节点105获取由原始数据形成的第一文件。
S1102:聚合节点105基于第一文件生成多个数据量较小的第二文件。
S1103:聚合节点105对多个第二文件逐个进行序列化。
S1104:客户端104接收用户输入的查询语句。S1105:客户端104基于接收到的查询语句生成数据查询请求,并将该数据查询请求传递给协调节点101。
S1106:协调节点101对该查询语句进行语义、语法分析,并根据该查询语句生成计划树。
S1107:协调节点101根据查询语句确定查询条件。
S1108:协调节点101可以根据该查询条件以及各个第二文件对应的元数据,改写计划树的执行逻辑。
实际应用时,协调节点101可以先查询数据处理系统100是否存在第二文件,具体可以是根据聚合节点105所提供的第二文件的元数据进行确定,当存在第二文件时,协调节点101可以根据查询条件以及第二文件的元数据改写计划树的执行逻辑,如将计划树中对于原始数据的访问逻辑修改为对于某个(或者某些)第二文件的访问逻辑等。
具体的,如图6所示,聚合节点105中可以包括生成模块(generator)1051、查询模块(selector)1052以及元数据模块(metadata)1053。其中,聚合节点105可以通过生成模块1051完成上述根据原始数据生成多个第二文件以及对各个第二文件的序列化,其具体实现可参见上述相关之处描述,在此不做赘述。其中,在序列化各个第二文件时,可以由元数据模块1053记录各个第二文件对应的元数据,如各个第二文件与原始数据之间的映射关系。
相应的,在查询数据时,协调节点101可以通过聚合节点105中的元数据模块1053获取各个第二文件的元数据,以便根据查询条件以及元数据模块1053提供的各个第二文件的元数据,确定从哪个或者哪些第二文件中查找聚合数据。
比如,基于图2所示的原始数据,可以按照属性“国家”生成第二文件A以及第二文件B,其中,第二文件A包括属性值为“AU”以及“CA”对应的聚合数据,其元数据可以为“国家=AU~CA”,第二文件B包括属性值“MX”以及“USA”对应的聚合数据,其元数据可以为“国家=MX~USA”。当查询条件为查找属性“国家”的属性值小于“MX”的聚合数据时,协调节点101可以将查询条件分别与第二文件A、第二文件B的元数据进行比较,确定查询条件与元数据“国家=AU~CA”相匹配,从而协调节点101可以确定从第二文件A中查询数据,并可以将计划树中访问原始数据的逻辑修改为访问第二文件A的逻辑。
又比如,当生成的第二文件如图6所示时,各个第二文件的元数据可以是生成各个第二文件对应的属性组合。假设查询条件为查找属性“国家”的属性值小于“MX”且“浏览器”属性的属性值小于“Firefox”的聚合数据时,协调节点101可以将查询条件与图6所示的各个第二文件对应的元数据进行匹配,确定该查询条件与属性组合(国家,浏览器,点击量)相匹配,从而协调节点101可以确定从该属性组合对应的第二文件(也即图6中第1排第1个第二文件)中查询数据,并可以将计划树中访问原始数据的逻辑修改为访问该第二文件的逻辑。
S1109:协调节点101利用一个或者多个优化器对生成的计划树进行优化。
S1110:协调节点101将优化后的计划树发送给执行节点102。
S1111:执行节点102根据接收到的计划树,指示聚合节点105中的查询模块1052在相应第二文件中查询数据。
比如,当计划树中的数据访问逻辑为访问第二文件A时,查询模块1052可以访问第二文件A中的聚合数据,并根据访问到的聚合数据生成相应的查询结果。
本实施例中,查询模块1052可以直接将查找到的第二文件中的部分或者全部聚合数据作为查询结果。
而在其它可能的实施方式中,查询模块1052也可以是对访问的第二文件中的聚合数据进行二次聚合运算。比如,当查询模块1052访问多个第二文件时,查询模块1052可以对多个第二文件中的聚合数据再次进行聚合运算,如将两个第二文件中的聚合值“点击量”进行求和运算(也即为二次聚合运算)等,并将二次聚合运算所生成的新的聚合结果作为查询结果。
本实施例中,当查询模块1052的数据处理能力较高时,查询模块1052根据查找到的第二文件中的部分或者全部聚合数据可以生成查询结果并返回给执行节点102。在其它实施例中,查询模块1052的数据处理能力较低,此时,查询模块1052可以将查询到的第二文件中的聚合数据反馈给执行节点102,由执行节点102根据接收到的聚合数据进行相应的计算,如对接收到的聚合数据进行二次聚合运算等,或者在接收到的聚合数据中进一步查找出满足查询条件的聚合数据等。本申请对此并不进行限定。
S1112:聚合节点105可以向执行节点102反馈查询结果。
值得注意的是,针对于每个查询任务,执行节点102从聚合节点102访问到的聚合数据的数据量较小,对于执行节点102与聚合节点105之间的带宽资源占用较小,因此,执行节点102与聚合节点105之间的带宽资源可以支持多个查询任务同时执行,支持更高数量查询任务的并发访问。比如,假设针对于每个查询任务,执行节点102从聚合节点105访问到聚合数据所需的最大带宽不超过1G(吉),而执行节点102与聚合节点105之间的总带宽为5G,则执行节点102可以同时支持至少5个查询任务的数据访问,具体可以是执行节点102上的五个线程并行从聚合节点105访问聚合数据等。
S1113:执行节点102通过协调节点101将查询结果返回给客户端104。
S1114:客户端104向用户呈现该查询结果。
值得注意的是,本实施例中各个步骤的具体实现方式,可以参见前述实施例中的相关之处描述,在此不做赘述。
上文中结合图1至图11,详细描述了本申请所提供的数据查询方法,下面将结合图12至图13,描述根据本申请所提供的数据查询装置以及设备。
与上述方法同样的发明构思,本申请实施例还提供一种数据查询装置,该数据查询装置可以实现上述图3所示的实施例中数据处理系统的功能。参见图12所示,该数据查询装置1200可以包括:
获取模块1201,用于接收数据查询请求,所述数据查询请求用于在第一文件中查询目标数据,所述第一文件对应多个第二文件,所述多个第二文件根据所述第一文件生成,每个第二文件的数据量小于所述第一文件的数据量;
确定模块1202,用于从所述多个第二文件中确定包括所述目标数据的目标文件;
查询模块1203,用于在所述目标文件中查询所述目标数据。
在一种可能的实施方式中,所述第一文件包括多个属性,所述第二文件包括所述多个属性中的至少一个属性,所述确定模块1202具体用于根据所述数据查询请求中的目标属性从所述多个第二文件中确定包括所述目标属性的第二文件为所述目标文件。
在一种可能的实施方式中,所述查询模块1203,具体用于将根据所述数据查询请求生成的计划树中的第一文件替换为所述目标文件。
在一种可能的实施方式中,所述装置1200还包括:
聚合模块1204,用于根据所述第一文件中的多个属性中的预设属性对所述第一文件进行聚合运算得到聚合文件;
分区模块1205,用于将所述聚合文件根据所述预设属性所包括的值进行分区,每个分区包括至少一个值对应的数据;
文件生成模块1206,用于针对每个分区形成一个第二文件。
在一种可能的实施方式中,所述分区模块1205,具体用于在内存中对所述聚合文件根据所述预设属性所包括的值进行分区;
所述文件生成模块1206,具体用于在对其中一个分区中的数据进行序列化,形成第二文件,并将所述第二文件持久化存储后,再对下一个分区的数据进行序列化处理。
在一种可能的实施方式中,所述获取模块1201,还用于从所述第一文件中的N个属性中获取M个属性,所述M个属性对应的数据形成所述第二文件,对于所述多个第二文件,包括M值相同的第二文件及M值不同的第二文件,对于M值相同的第二文件,所包括的属性不完全相同。
在一种可能的实施方式中,所述获取模块1201,具体用于:
将所述第一文件读取至内存,从所述第一文件中获取M个属性;
对所述M个属性对应的数据进行聚合运算;
对聚合运算后的数据进行序列化,形成第二文件;
将所述第二文件存储至持久化存储区域。
本实施例中的数据查询装置1200,对应于图3所示的数据查询方法,因此,对于本实施例数据查询装置1200中各个功能模块的具体实现及其所具有的技术效果,可以参见图3所示实施例中的相关之处描述,在此不做赘述。
此外,本申请实施例还提供一种设备,如图13所示,设备1300中可以包括通信接口1310、处理器1320。可选的,设备1300中还可以包括存储器1330。其中,存储器1330可以设置于设备1300内部,还可以设置于设备1300外部。示例性地,上述图2所示实施例中各个动作均可以由处理器1320实现。处理器1320可以通过通信接口1310获取数据源中的第一文件,并用于实现图3中所执行的任一方法。在实现过程中,处理流程的各步骤可以通过处理器1320中的硬件的集成逻辑电路或者软件形式的指令完成图3中执行的方法。为了简洁,在此不再赘述。处理器1320用于实现上述方法所执行的程序代码可以存储在存储器1330中。存储器1330和处理器1320连接,如耦合连接等。
本申请实施例的一些特征可以由处理器1320执行存储器1330中的程序指令或者软件代码来完成/支持。存储器1330上在加载的软件组件可以从功能或者逻辑上进行概括,例如,图12所示的确定模块1202、查询模块1203、聚合模块1204、分区模块1205以及文件生成模块1206。而获取模块501的功能可以由通信接口1310实现。
本申请实施例中涉及到的任一通信接口可以是电路、总线、收发器或者其它任意可以用于进行信息交互的装置。比如设备1300中的通信接口1310,示例性地,该其它装置可以是与该设备1300相连的设备,比如,可以是发送读数据命令或者写数据命令的主机等。
本申请实施例中涉及的处理器可以是通用处理器、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件,可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成,或者用处理器中的硬件及软件模块组合执行完成。
本申请实施例中的耦合是装置、模块或模块之间的间接耦合或通信连接,可以是电性,机械或其它的形式,用于装置、模块或模块之间的信息交互。
处理器可能和存储器协同操作。存储器可以是非易失性存储器,比如硬盘(harddisk drive,HDD)或固态硬盘(solid-state drive,SSD)等,还可以是易失性存储器(volatile memory),例如随机存取存储器(random-access memory,RAM)。存储器是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质,但不限于此。
本申请实施例中不限定上述通信接口、处理器以及存储器之间的具体连接介质。比如存储器、处理器以及通信接口之间可以通过总线连接。所述总线可以分为地址总线、数据总线、控制总线等。
基于以上实施例,本申请实施例还提供了一种计算机存储介质,该存储介质中存储软件程序,该软件程序在被一个或多个处理器读取并执行时可实现上述任意一个或多个实施例提供数据处理系统100执行的方法。所述计算机存储介质可以包括:U盘、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。
基于以上实施例,本申请实施例还提供了一种芯片,该芯片包括处理器,用于实现上述实施例所涉及的数据处理系统100的功能,例如用于实现图3中所执行的方法。可选地,所述芯片还包括存储器,所述存储器,用于处理器所执行必要的程序指令和数据。该芯片,可以由芯片构成,也可以包含芯片和其他分立器件。
本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的术语在适当情况下可以互换,这仅仅是描述本申请的实施例中对相同属性的对象在描述时所采用的区分方式。
显然,本领域的技术人员可以对本申请实施例进行各种改动和变型而不脱离本申请实施例的范围。这样,倘若本申请实施例的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。
Claims (16)
1.一种数据查询方法,其特征在于,所述方法包括:
接收数据查询请求,所述数据查询请求用于在第一文件中查询目标数据,所述第一文件对应多个第二文件,所述多个第二文件根据所述第一文件生成,每个第二文件的数据量小于所述第一文件的数据量;
从所述多个第二文件中确定包括所述目标数据的目标文件;
在所述目标文件中查询所述目标数据。
2.根据权利要求1所述的方法,其特征在于,所述第一文件包括多个属性,所述第二文件包括所述多个属性中的至少一个属性,所述从所述多个第二文件中确定包括所述目标数据的目标文件包括:
根据所述数据查询请求中的目标属性从所述多个第二文件中确定包括所述目标属性的第二文件为所述目标文件。
3.根据权利要求1或2所述的方法,其特征在于,所述在所述目标文件中查询所述目标数据包括:
将根据所述数据查询请求生成的计划树中的第一文件替换为所述目标文件。
4.根据权利要求1至3任一项所述的方法,其特征在于,所述方法还包括:
根据所述第一文件中的多个属性中的预设属性对所述第一文件进行聚合运算得到聚合文件;
将所述聚合文件根据所述预设属性所包括的值进行分区,每个分区包括至少一个值对应的数据;
针对每个分区形成一个第二文件。
5.根据权利要求4所述的方法,其特征在于,所述将所述聚合文件根据所述预设属性所包括的值进行分区包括:
在内存中对所述聚合文件根据所述预设属性所包括的值进行分区;
所述针对每个分区形成一个第二文件包括:
在对其中一个分区中的数据进行序列化,形成第二文件,并将所述第二文件持久化存储后,再对下一个分区的数据进行序列化处理。
6.根据权利要求1至5任一项所述的方法,其特征在于,所述方法还包括:
从所述第一文件中的N个属性中获取M个属性,所述M个属性对应的数据形成所述第二文件,对于所述多个第二文件,包括M值相同的第二文件及M值不同的第二文件,对于M值相同的第二文件,所包括的属性不完全相同。
7.根据权利要求6所述的方法,其特征在于,所述从所述第一文件中的N个属性中获取M个属性,所述M个属性对应的数据形成所述第二文件包括:
将所述第一文件读取至内存,从所述第一文件中获取M个属性;
对所述M个属性对应的数据进行聚合运算;
对聚合运算后的数据进行序列化,形成第二文件;
将所述第二文件存储至持久化存储区域。
8.一种数据查询装置,其特征在于,所述装置包括:
获取模块,用于接收数据查询请求,所述数据查询请求用于在第一文件中查询目标数据,所述第一文件对应多个第二文件,所述多个第二文件根据所述第一文件生成,每个第二文件的数据量小于所述第一文件的数据量;
确定模块,用于从所述多个第二文件中确定包括所述目标数据的目标文件;
查询模块,用于在所述目标文件中查询所述目标数据。
9.根据权利要求8所述的装置,其特征在于,所述第一文件包括多个属性,所述第二文件包括所述多个属性中的至少一个属性,所述确定模块具体用于根据所述数据查询请求中的目标属性从所述多个第二文件中确定包括所述目标属性的第二文件为所述目标文件。
10.根据权利要求8或9所述的装置,其特征在于,所述查询模块,具体用于将根据所述数据查询请求生成的计划树中的第一文件替换为所述目标文件。
11.根据权利要求8至10任一项所述的装置,其特征在于,所述装置还包括:
聚合模块,用于根据所述第一文件中的多个属性中的预设属性对所述第一文件进行聚合运算得到聚合文件;
分区模块,用于将所述聚合文件根据所述预设属性所包括的值进行分区,每个分区包括至少一个值对应的数据;
文件生成模块,用于针对每个分区形成一个第二文件。
12.根据权利要求11所述的装置,其特征在于,所述分区模块,具体用于在内存中对所述聚合文件根据所述预设属性所包括的值进行分区;
所述文件生成模块,具体用于在对其中一个分区中的数据进行序列化,形成第二文件,并将所述第二文件持久化存储后,再对下一个分区的数据进行序列化处理。
13.根据权利要求8至12任一项所述的装置,其特征在于,所述获取模块,还用于从所述第一文件中的N个属性中获取M个属性,所述M个属性对应的数据形成所述第二文件,对于所述多个第二文件,包括M值相同的第二文件及M值不同的第二文件,对于M值相同的第二文件,所包括的属性不完全相同。
14.根据权利要求13所述的装置,其特征在于,所述获取模块,具体用于:
将所述第一文件读取至内存,从所述第一文件中获取M个属性;
对所述M个属性对应的数据进行聚合运算;
对聚合运算后的数据进行序列化,形成第二文件;
将所述第二文件存储至持久化存储区域。
15.一种设备,其特征在于,所述设备包括处理器和存储器;
所述处理器用于执行所述存储器中存储的指令,以使得所述设备执行权利要求1至7中任一项所述的方法。
16.一种计算机可读存储介质,其特征在于,包括指令,所述指令用于实现权利要求1至7中任一项所述的方法。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/CN2021/124250 WO2022083520A1 (zh) | 2020-10-19 | 2021-10-16 | 一种数据查询方法、装置、设备及存储介质 |
EP21881937.3A EP4209918A4 (en) | 2020-10-19 | 2021-10-16 | DATA QUERY METHOD AND APPARATUS, DEVICE, AND RECORDING MEDIUM |
US18/301,609 US20230259490A1 (en) | 2020-10-19 | 2023-04-17 | Data query method and apparatus, device, and storage medium |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011118445 | 2020-10-19 | ||
CN2020111184451 | 2020-10-19 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN114385555A true CN114385555A (zh) | 2022-04-22 |
Family
ID=81194806
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202011638412.XA Pending CN114385555A (zh) | 2020-10-19 | 2020-12-31 | 一种数据查询方法、装置、设备及存储介质 |
Country Status (4)
Country | Link |
---|---|
US (1) | US20230259490A1 (zh) |
EP (1) | EP4209918A4 (zh) |
CN (1) | CN114385555A (zh) |
WO (1) | WO2022083520A1 (zh) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114741434B (zh) * | 2022-06-10 | 2022-09-06 | 北京亿赛通科技发展有限责任公司 | 一种海量es搜索数据的预统计方法及系统 |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102289482A (zh) * | 2011-08-02 | 2011-12-21 | 北京航空航天大学 | 一种非结构化数据查询方法 |
US11461356B2 (en) * | 2015-09-25 | 2022-10-04 | Mongodb, Inc. | Large scale unstructured database systems |
US20170228422A1 (en) * | 2016-02-10 | 2017-08-10 | Futurewei Technologies, Inc. | Flexible task scheduler for multiple parallel processing of database data |
CN107169033B (zh) * | 2017-04-17 | 2020-03-31 | 东北大学 | 基于数据模式转换和并行框架的关系数据查询优化方法 |
US11232365B2 (en) * | 2018-06-14 | 2022-01-25 | Accenture Global Solutions Limited | Digital assistant platform |
CN111339078A (zh) * | 2018-12-19 | 2020-06-26 | 北京京东尚科信息技术有限公司 | 数据实时存储方法、数据查询方法、装置、设备、介质 |
CN111723161A (zh) * | 2019-03-20 | 2020-09-29 | 阿里巴巴集团控股有限公司 | 一种数据处理方法、装置及设备 |
-
2020
- 2020-12-31 CN CN202011638412.XA patent/CN114385555A/zh active Pending
-
2021
- 2021-10-16 WO PCT/CN2021/124250 patent/WO2022083520A1/zh unknown
- 2021-10-16 EP EP21881937.3A patent/EP4209918A4/en active Pending
-
2023
- 2023-04-17 US US18/301,609 patent/US20230259490A1/en active Pending
Also Published As
Publication number | Publication date |
---|---|
WO2022083520A1 (zh) | 2022-04-28 |
EP4209918A1 (en) | 2023-07-12 |
US20230259490A1 (en) | 2023-08-17 |
EP4209918A4 (en) | 2024-02-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8219564B1 (en) | Two-dimensional indexes for quick multiple attribute search in a catalog system | |
US5884320A (en) | Method and system for performing proximity joins on high-dimensional data points in parallel | |
US20140351239A1 (en) | Hardware acceleration for query operators | |
WO2017019879A1 (en) | Multi-query optimization | |
US9946752B2 (en) | Low-latency query processor | |
EP3362916B1 (en) | Signature-based cache optimization for data preparation | |
US10783142B2 (en) | Efficient data retrieval in staged use of in-memory cursor duration temporary tables | |
CN112860692B (zh) | 一种数据库表结构转换方法、装置及其电子设备 | |
US20150120652A1 (en) | Replicated data storage system and methods | |
CN113688127A (zh) | 数据压缩技术 | |
CN114090695A (zh) | 分布式数据库的查询优化的方法和装置 | |
CN108140022B (zh) | 数据查询方法和数据库系统 | |
CN111125199B (zh) | 一种数据库访问方法、装置及电子设备 | |
Wang et al. | Efficient query processing framework for big data warehouse: an almost join-free approach | |
US20230259490A1 (en) | Data query method and apparatus, device, and storage medium | |
CN113297057A (zh) | 内存分析方法、装置及系统 | |
CN113282579A (zh) | 一种异构数据存储与检索方法、装置、设备及存储介质 | |
CN106980673B (zh) | 内存数据库表索引更新方法及系统 | |
Álvarez-García et al. | Compact and efficient representation of general graph databases | |
Packiaraj et al. | Hypar-fca: a distributed framework based on hybrid partitioning for fca | |
RU2393536C2 (ru) | Способ унифицированной семантической обработки информации, обеспечивающий в рамках одной формальной модели представление, контроль семантической правильности, поиск и идентификацию описаний объектов | |
US20220215021A1 (en) | Data Query Method and Apparatus, Computing Device, and Storage Medium | |
CN114817226A (zh) | 政府数据的处理方法及装置 | |
Mullangi et al. | SCISSOR: scalable and efficient reachability query processing in time-evolving hierarchies | |
Li et al. | An improved distributed query for large-scale RDF data |
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 |