CN117312370A - 数据查询方法、系统及相关设备 - Google Patents

数据查询方法、系统及相关设备 Download PDF

Info

Publication number
CN117312370A
CN117312370A CN202311375013.2A CN202311375013A CN117312370A CN 117312370 A CN117312370 A CN 117312370A CN 202311375013 A CN202311375013 A CN 202311375013A CN 117312370 A CN117312370 A CN 117312370A
Authority
CN
China
Prior art keywords
data
index
lake
file
data lake
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
Application number
CN202311375013.2A
Other languages
English (en)
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.)
Shenzhen Shenxinfu Information Security Co ltd
Original Assignee
Shenzhen Shenxinfu Information Security 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 Shenzhen Shenxinfu Information Security Co ltd filed Critical Shenzhen Shenxinfu Information Security Co ltd
Priority to CN202311375013.2A priority Critical patent/CN117312370A/zh
Publication of CN117312370A publication Critical patent/CN117312370A/zh
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2228Indexing structures
    • G06F16/2255Hash tables

Abstract

本申请公开了数据查询方法、系统及相关设备,该方法包括:基于当前数据湖的快照信息构建当前数据湖的索引;其中,当前数据湖以行为标记的形式记录较比历史数据湖发生过的数据变更情况;依据索引信息,输出请求查询的目标数据在当前数据湖中的存储位置。相比于查询时无索引的情况,基于快照信息为数据湖构建索引并利用该索引,有助于大幅度减少对数据湖中目标数据的查询用时,增强结果反馈效率。此外,以行为标记的形式写有数据湖上发生过的数据变更操作,可有效避免数据变更时大幅度地进行索引重建,浪费运行资源,同时,能溯源性记录数据湖变更前后产生的存储差异,即反馈数据在不同时间对数据湖空间的占用情况。

Description

数据查询方法、系统及相关设备
技术领域
本申请实施例涉及互联网技术领域,尤其涉及数据查询方法、系统及相关设备。
背景技术
数据湖作为数据库的延伸,常用来存储大量数据。但目前,面对数据湖写入或删除某些数据等变更数据,或数据存量较大的情况,容易在数据湖中查找不到目标数据或查找用时较长。
针对于此,有必要提供有效的解决方案。
发明内容
本申请实施例提供了数据查询方法、系统及相关设备,用于提高对数据湖中数据的查询效率。
本申请实施例第一方面提供一种数据查询方法,包括:
基于当前数据湖的快照信息构建所述当前数据湖的索引;其中,所述快照信息用于记录所述当前数据湖的文件被快照时包含的数据信息,所述当前数据湖以行为标记的形式记录较比历史数据湖发生过的数据变更情况,所述行为标记包含新增、删除或修改数据,所述索引关联有各数据在数据湖文件中的存储位置信息;
依据所述索引信息,输出请求查询的目标数据在所述当前数据湖中的存储位置。
可选地,所述基于当前数据湖的快照信息构建所述当前数据湖的索引,包括:
使用哈希算法计算所述当前数据湖中各条数据记录对应的哈希值;
将每一所述数据记录在数据湖文件中的存储位置信息与相应的所述哈希值进行绑定,以得到每一条所述数据记录的映射对,并将所述映射对存放到不同的哈希桶中;
排布各所述哈希桶所存的所述映射对信息,以构建得所述当前数据湖的索引。
可选地,所述存储位置信息包含所存数据在数据湖中对应所属的文件路径、所述所存数据在文件中的位置。
可选地,所述基于当前数据湖的快照信息构建所述当前数据湖的索引,包括:
将所述当前数据湖中所有数据记录对应的关键字和存储位置信息,按平衡树规则排布以得到充当所述索引的索引树。
可选地,所述当前数据湖的获得过程包括:
基于变更操作请求在指定文件中添加相应的行为标记内容,以得到所述当前数据湖;其中,所述指定文件为所述历史数据湖内被请求变更的文件。
可选地,所述行为标记内容用于指出新写入的数据、示意删除或修改所述指定文件中的部分数据内容。
可选地,所述依据所述索引信息,输出请求查询的目标数据在所述当前数据湖中的存储位置,包括:
对于不引用索引规则的查询语句,解析所述查询语句,以判断所述当前数据湖中被请求读取的待读文件是否对应存在索引;所述索引规则表示数据及数据存储位置之间在记载上存在映射关系;
若存在索引,则依据所述索引记载的目录项内容改写所述查询语句,以获得引用索引规则后的新版查询语句;
依据所述新版查询语句的指示信息,查找出所述目标数据在所述待读文件中的存储位置,所述指示信息表示优先通过索引字段读取出所述待读文件的位置信息。
可选地,所述方法还包括:对于不存在索引的各文件,遍历所述各文件以定位出当中记有所述目标数据的目标文件,并输出所述目标数据在所述目标文件中的存储位置。
可选地,所述索引的获得过程包括:
在所述历史数据湖发生数据变更后的预设时刻,对变更得到的所述当前数据湖建立索引。
本申请第一方面所述的方法在具体实施时可采用本申请第二方面所述的内容实现。
本申请实施例第二方面提供一种数据查询系统,包括:
处理单元,用于基于当前数据湖的快照信息构建所述当前数据湖的索引;其中,所述快照信息用于记录所述当前数据湖的文件被快照时包含的数据信息,所述当前数据湖以行为标记的形式记录较比历史数据湖发生过的数据变更情况,所述行为标记包含新增、删除或修改数据,所述索引关联有各数据在数据湖文件中的存储位置信息;
查询单元,用于依据所述索引信息,输出请求查询的目标数据在所述当前数据湖中的存储位置。
本申请实施例第三方面提供一种电子设备,包括:
中央处理器,存储器以及输入输出接口;
所述存储器为短暂存储存储器或持久存储存储器;
所述中央处理器配置为与所述存储器通信,并执行所述存储器中的指令操作以执行本申请实施例第一方面或第一方面的任一具体实现方式所描述的方法。
本申请实施例第四方面提供一种计算机可读存储介质,包括指令,当所述指令在计算机上运行时,使得计算机执行如本申请实施例第一方面或第一方面的任一具体实现方式所描述的方法。
本申请实施例第五方面提供一种包含指令或计算机程序的计算机程序产品,当所述计算机程序产品在计算机上运行时,使得计算机执行如本申请实施例第一方面或第一方面的任一具体实现方式所描述的方法。
从以上技术方案可以看出,本申请实施例至少具有以下优点:
相比于查询时无索引的情况,基于快照信息为数据湖构建索引并利用该索引,有助于大幅度减少对数据湖中目标数据的查询用时,增强结果反馈效率。此外,以行为标记的形式写有数据湖上发生过的数据变更操作,可有效避免数据变更时大幅度地进行索引重建,浪费运行资源,同时,能溯源性记录数据湖变更前后产生的存储差异,即反馈数据在不同时间对数据湖空间的占用情况。
附图说明
为了更清楚地说明本申请实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请中记载的一些实施例,对于本领域普通技术人员来讲,还可以根据这些附图获得其他的附图。
需要说明的是,虽然各实施例所涉及的流程性示意图(若存在)中各个步骤按照箭头的指示依次绘制,但除非本文中有明确的说明,这些步骤的执行并没有严格的顺序限制,这些步骤可以以其它的顺序执行。而且,各实施例所涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段,这些步骤或者阶段并不必然是在同一时刻执行完成,而是可以在不同的时刻执行,这些步骤或者阶段的执行顺序也不必然是依次进行,而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
图1为本申请实施例数据查询方法的一个系统架构示意图;
图2为本申请实施例数据查询方法的一个流程示意图;
图3为本申请实施例数据查询方法的Hash索引结构示意图;
图4为本申请实施例数据查询方法的B+树索引结构示意图;
图5为本申请实施例数据查询方法的一个技术架构示意图;
图6为本申请实施例数据查询系统的一个结构示意图。
图7为本申请实施例电子设备的一个结构示意图。
具体实施方式
为了使本申请的目的、技术方案和优点更加清楚,下面将结合附图对本申请作进一步地详细描述,所描述的实施例不应视为对本申请的限制,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例,都属于本申请保护的范围。
本申请的说明书和权利要求书及附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
在以下的描述中,涉及到“一个具体实施方式”或“一个具体示例”等类似表达,其描述了所有可能实施例的子集,但是可以理解,“一个具体实施方式”或“一个具体示例”可以是所有可能实施例的相同子集或不同子集,并且可以在不冲突的情况下相互结合。在以下的描述中,涉及到的术语多个是指至少两个。本申请所说的某数值达到阈值(如果存在),在一些具体示例中,可包括前者大于阈值后者的情况;若提及“任意”或“至少一”等类似表述,具体可指所列举示例中的任一种示例或这些示例之间的任意组合。
除非另有定义,本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的,不是旨在限制本申请。
为便于理解和说明,在对本申请做进一步的详细说明之前,将对本申请实施例中涉及的名词和术语进行说明,本申请实施例中涉及的名词和术语适用于如下的解释。
Iceberg:一种用于追踪超大型分析型数据表的新格式,是物理数据文件以及他们如何构建形成表格之间的抽象层。这种格式既能够完成PB级数据表格的存储,与现有的HIVE数仓不同,能完成对这些表的行级更新,删除操作。还能够记录表的历史状态信息。每次数据表的更改,Iceberg都会生成新的快照,用户可以查询到表的历史快照状态。
Trino:是一个非常流行的分布式SQL查询引擎,旨在快速查询一个或多个异构的数据源上的大型数据集,是当前最流行的share disk的SQL引擎之一。同时也能够写入数据到不同的数据源。当然,本申请的方法也适用于HIVE引擎,但其查询效率不如Trino引擎。
索引(Index):数据库的索引是一种数据结构,通过额外的存储空间以及写入的操作来维护,可以提高从数据库中读取数据的效率,通过索引,不需要进行全表扫描,就能够快速地找到指定的数据。每个表的索引都可以建立在一个或者多个字段(如id等字段)之上。
数据湖:一个存储企业的各种各样原始数据的大型仓库,其中的数据可供存取、处理、分析及传输。数据湖从企业的多个数据源获取原始数据,并且针对不同的目的,同一份原始数据可能有多种满足特定内部模型格式的数据副本。因此,数据湖中被处理的数据可以是任意的数据类型,结构化到非结构数据都有,当前主流的数据湖有Hudi、Iceberg和Delta等项目。
B(balance)-树是一种多路自平衡的搜索树,它类似普通的平衡二叉树,不同的一点是B-树允许每个节点有更多的子节点,属于多叉树,各节点各自带数据。B+树是B-树的变体,也是一种多路搜索树,它与B-树的不同之处在于:所有关键字存储在叶子节点出现,内部节点(非叶子节点并不存储真正的data)为所有叶子结点增加了一个链指针。每个索引都对应一个B+树,B+树分为好多层,最下面的一层是叶子节点,其余是内节点,所有用户记录都存储在B+树的叶子节点,所有目录项记录都存储在内节点。
X-Scheduler:一种执行调度的框架,能够友好地在界面调度各种离线任务,比如spark程序,python程序,shell等。
Yarn的调度原理是将资源请求转换为容器请求,然后将容器请求分配到可用的节点上,一般的,YARN只提供运算资源的调度,或负责向应用程序分配资源。
请参阅图1,图1示出了一种适用于本申请实施例的应用环境示意图。本申请实施例提供的方法可应用于如图1所示的交互系统100,该交互系统100包括终端设备101以及服务器102,服务器102与终端设备101通信连接,其中,服务器102可以是传统服务器,也可以是云端服务器,在此不作具体限定。终端设备101可以是具有显示屏且支持数据输入的各种电子设备,包括但不限于智能手机、平板电脑、膝上型便携计算机、台式计算机和可穿戴式电子设备等;具体的,数据输入可以是基于终端设备101上具有的语音模块输入语音、基于字符输入模块输入字符或基于图像输入模块输入图像等,还可以是基于终端设备101上安装有的手势识别模块,使得用户可以实现手势输入等交互方式。终端设备101上可以安装有客户端应用程序,用户可以基于客户端应用程序(例如APP、小程序等)与服务器102进行通信,或还可以基于客户端应用程序实现前述数据输入。
类似的,服务器102也可以部署有服务端应用程序,该服务端应用程序可以配合前述客户端应用程序实施本方法。例如,服务端应用程序可基于当前数据湖的快照信息构建当前数据湖的索引,并依据该索引对客户端应用程序输入的查询语句进行检索,以向终端设备101返回目标数据在当前数据湖中的存储位置。上述的应用环境仅为方便理解所作的示例,可以理解的是,本申请实施例不仅局限于上述应用环境。
下面将对本申请的方法做进一步的详细说明。
请参阅图2,本申请第一方面提供一种数据查询方法的一个具体实施例,该实施例包括如下操作步骤:
21、基于当前数据湖的快照信息构建当前数据湖的索引。
其中,快照信息用于记录当前数据湖的文件被快照时包含的数据信息,当前数据湖以行为标记的形式记录较比历史数据湖发生过的数据变更情况,行为标记包含新增、删除或修改数据,索引关联有各数据在数据湖文件中的存储位置信息。
需说明的是,上述历史数据湖具体可以是,最初无数据时的空数据湖,或者是存了一部分数据后的数据湖,具体因请求查询或建立索引的时间不同而不同。
22、依据索引信息,输出请求查询的目标数据在当前数据湖中的存储位置。
可借助构建出的索引信息,快速定位出目标数据的存储位置,如其记录在当前数据湖中的文件位置,以及其在该文件中的第几行或第几列。
综上,相比于查询时无索引的情况,基于快照信息为数据湖构建索引并利用该索引,有助于大幅度减少对数据湖中目标数据的查询用时,增强结果反馈效率。此外,以行为标记的形式写有数据湖上发生过的数据变更操作,可有效避免数据变更时大幅度地进行索引重建,浪费运行资源,同时,能溯源性记录数据湖变更前后产生的存储差异,即反馈数据在不同时间对数据湖空间的占用情况。
在上述示例说明的基础上,下面将提供一些具体的可能实施示例,实际应用中,这些示例之间的实施内容可根据相应的功能原理、应用逻辑由需地结合或单独实施,具体可由实际场景而定。
请参阅图2至图5,本申请提供一种数据查询方法的另一具体实施例,该实施例包括如下操作步骤:
21、基于当前数据湖的快照信息构建当前数据湖的索引。
实际应用中,可构建并使用Hash索引或平衡树(如B+树)索引等不同形式的索引。
(1)作为一种可能的实施方式(Hash索引),步骤21的操作过程包括:使用哈希(Hash)算法计算当前数据湖中各条数据记录对应的哈希值;将每一数据记录在数据湖文件中的存储位置信息与相应的哈希值进行绑定,以得到每一条数据记录的映射对,并将映射对存放到不同的哈希桶中;排布各哈希桶所存的映射对信息,以构建得当前数据湖的索引。
在一些具体示例中,上述存储位置信息包含所存数据在数据湖中对应所属的文件路径、所存数据在文件中的位置。
如图3所示的Hash索引示意图,数据湖中所有的数据记录(record)通过Hash算法哈希到不同的哈希桶中,即各条record以哈希值的形式分放到不同桶中,每个桶存放了record对应的映射对,该映射对(即桶文件HFile)可简记为“record n→存储位置信息”,哈希值n=1、2、3…,例如,HFile可详记为“recordn→文件路径+偏移量”,或“recordn→文件路径n→偏移量”。示例性的,一条record“id=3,name=张三”当中的数值“3”与“张三”即所存数据(存储的数据),上述偏移量(x)即这条数据record在文件(如第2号文件)中的存储位置如存在文件的第x行,则相应的,这条record可记有一组键值对(键key:3,值value:2,x);故可以理解的是,Hash索引可针对具有唯一键值对的数据做定位使用。
此外,每个桶中的映射对可按各自对应的哈希值n大小排序,以构建得到包含N个桶、每个桶包含N个HFile的索引。由历史测试经验可知,100万条记录中随机读取10万条的时间会小于600毫秒,所以每个桶里面可以最多存储100万条记录,则一个存储了100个桶的索引文件可以记录1亿条记录;索引的桶文件可以常驻在内存,该内存消耗不到1MB,故可以通过两次磁盘读取获取到对应的数据,且总时间不超过1s。
如上,本申请的实施目的是,若请求查询标识id=2的这条数据,该查询语句SQL可以是select*fromtable1 where id=2,那么需要了解id=2这条数据存放在哪个文件的哪一行。由上述hash索引的说明可知,这条数据的键是id=2这个数值“2”,但是如果存在多个id=2(即键一样),各个id对应的值value又不一样(即表明这条数据存储在不同的文件中),就无法准确运行hash索引,即用hash索引难以定位目标数据真正的存储位置,故针对于此,需要另外配置相应的应对措施,如构建平衡树索引。换言之,hash索引适用于没有重复数据的情况(键值对唯一,具体是键值对里的键唯一),平衡树适合有重复数据的情况(键值对不唯一)。
(2)作为另一种可能的实施方式(平衡树索引),步骤21的操作过程包括:将当前数据湖中所有数据记录对应的关键字和存储位置信息,按平衡树规则排布以得到充当索引的索引树。此平衡树具体可以是二叉树、B+树或B-树,具体可由需选用,不做限制,下面将以B+树做示例说明。B+树是附加有限制条件的索引树,保证了树的平衡,能有效减少磁盘空间的浪费,数据仅出现在叶子节点;一般的,B+树的key均为8个字节的Bigint类型,指针为6个字节。
请参阅图4所示的B+树索引示意图,该B+树中的块称之为一个磁盘块,可以看到每个磁盘块包含几个数据项和指针,如磁盘块1包含数据项17和35,还包含指针P1、P2、P3,P1表示小于17的磁盘块,P2表示在17和35之间的磁盘块,P3表示大于35的磁盘块。真实的数据存在于叶子节点(最底层节点)即3、5、9、10、13、15、28、29、36、60、75、79、90、99。非叶子节点不存储真实的数据,只存储指引搜索方向的数据项,如顶层数据项17、35并不真实存在于数据表中(如Iceberg表)。图4所示的b+树查找过程为:如果要查找数据项29,那么首先会把磁盘块1由磁盘加载到内存,此时发生一次读或写磁盘(即IO),在内存中用二分查找确定29在17和35之间,锁定磁盘块1的P2指针,内存时间因为非常短(相比磁盘的IO)可以忽略不计,通过磁盘块1的P2指针的磁盘地址把磁盘块3由磁盘加载到内存,发生第二次IO,因29在26和30之间,锁定磁盘块3的P2指针,通过指针加载磁盘块8到内存,发生第三次IO,同时内存中做二分查找找到29,结束查询,总计三次IO。真实的情况是,3层的b+树可以表示上百万的数据,如果上百万的数据查找只需要三次IO,性能提高将是巨大的,如果没有索引,每个数据项都要发生一次IO,那么总共需要百万次的IO,显然成本非常非常高。
由历史测试经验可知,以Trino引擎中每个块block占用16KB的空间计算,每个块(block)可以有16384/14=1170条记录。示例性的,每个叶子节点数据可以限制在4KB(因为Linux最长路径为4KB),所以高度为2的树可以有4*1170=4680个记录,高度为3的树有4*1170*1170=550万条数据,高度为4的树有64亿条数据,高度为5的树超过万亿条数据。也就是说,即使万亿条数据,5次磁盘读取就能够读取出完整的数据。因为分布式存储系统HDFS的block为128MB,远大于block大小,经过压缩后,万亿数据不超过4次HDFS请求,就能够拿到文件路径和/或在文件中的行数等存储位置信息;总时间在1s左右,响应效率良好。
在一些具体示例中,当前数据湖的获得过程包括:基于变更操作请求在指定文件中添加相应的行为标记内容,以得到当前数据湖;其中,指定文件为历史数据湖内被请求变更的文件。
在一些具体示例中,行为标记内容用于指出新写入的数据、示意删除或修改指定文件中的部分数据内容。
以Iceberg表为例,Iceberg表的存储方式为Merge OnRead(写时合并),即不管是写入、更新(即修改)还是删除等变更操作,都可以在文件后面对本次操作的文件内容进行增式的标记,即增加行为标记内容,如追加所新增(add)的数据,删除也是追记出被删除(delete)的数据,以便之后打上快照(周期性地)构建出索引和溯源。比如,指定文件的当前数据为(1,2,3,4),现在做出了删除3的操作,则新存储的文件数据为:(1,2,3,4)(delete3);之后,读取时会计算得到(1,2,4),但是(1,2,3,4)这个旧文件依然存在,那么每次记录数据的元数据信息,就能找到删除3以前的数据,Iceberg的快照功能也是因为这样的原因生效的。当然,同理的,新索引上也可以增记出(delete 3)的痕迹,以便快速溯源。
在一些具体示例中,上述索引的获得过程可包括:在历史数据湖发生数据变更后的预设时刻,对变更得到的当前数据湖建立索引。具体的,可以理解的是,本申请的索引是在快照信息的基础上构建的,构建索引的时间可由需自定,例如,从减少资源损耗这一方面考虑,可以不是一发生变更操作就实时地建立索引,而是定期(即周期性地)打上快照(snapshot)后,定期基于当前快照信息构建索引,使得不会影响到正在写入数据的性能(以防资源被转用),即写入数据时追加写,不会操作已有的文件,同时有助于提升数据查询能力。可选地,当日的索引依据当日的最新快照信息建立(即按日定期),或者,推荐在合并小文件时进行索引的构建(即按事件发生的时间定期),即构建索引的时间具体可由需自定。当然,为了侧重保证数据的实时性,可以略轻视资源上的损耗,即构建索引的时间周期可以设定得间隔越小越好。至此可以看出,相比于一变动数据就重建索引的情况,在数据量高频次更新或读写的场景下,周期性地构建附加索引,可避免写入性能呈数量级性地下降。
22、依据索引信息,输出请求查询的目标数据在当前数据湖中的存储位置。
在一些具体示例中,步骤22的操作过程可包括:对于不引用索引规则的查询语句,解析查询语句,以判断当前数据湖中被请求读取的待读文件是否对应存在索引;索引规则表示数据及数据存储位置之间在记载上存在映射关系(即是否存在映射对或地址指针);若存在索引,则依据索引记载的目录项内容改写查询语句,以获得引用索引规则后的新版查询语句;依据新版查询语句的指示信息,查找出目标数据在待读文件中的存储位置,指示信息表示优先通过索引字段读取出待读文件的位置信息。
示例性的,在使用Trino引擎进行数据查询的时候,主要有下述步骤1-5:
1、用户输入查询(query)语句。如SQL语句“select*from table_1where id=1500”。
2、SQL解析,包括词法解析、语法解析等。
3、读取元数据(metadata)信息,以确定Trino引擎读取的文件如Iceberg表是否存在索引,即是否构建或分布有索引。
Metadata是Iceberg这个数据湖中有哪些表,表里有哪些字段,表里的数据存储到了哪些文件。因为Iceberg是merge on Read(写时合并),即不管是写入、更新还是删除,都是在文件后面追加数据,删除也是追加标记删除。每次变动后,会生成新的metadata,而旧版的metadata也没有消除,新旧的metadata均可以作为快照存在,使得可以针对快照生成索引文件,然后把是否有索引,索引文件存在哪里都写到旧版的metadata数据中去,等到查询的时候,会先读取旧metadata,如此就能知道表里的字段是否有索引,索引存储在了哪里。
4、通过查询优化器改写SQL,让SQL执行得更有效率。
比如有1000万条数据,分别存储在100个文件中,若想要查询id=1500的这条数据记录(假如它在第21个文件中),使用SQL“select*fromtable_1where id=1500”没有索引的时候,需要把这100个文件读取出来,再查看id=1500的数据在哪里,然后给出查询结果。而在给id字段建立了索引后,执行索引性计划就能先找到索引文件,使得由索引文件便可直接发现id=1500的数据在第21个文件中,之后,只要读取第21个文件就能快速查询到id=1500的数据,如在第21个文件的第几行找到。可见,应用索引能高效减少查找大量文件数据的工作量。简言之,改写就是改写执行计划,让SQL执行的时候,先找索引文件,以便直接过滤出目标数据在第21个文件,即预先考虑使用索引来查找数据。
5、生成并运行改写后的执行计划。
如果查询语句指定的快照(snapshot)或文件构建有索引,并且该查询语句有利用到索引字段,则优先使用索引,以便快捷过滤出目标数据所在的文件,进而加快输出目标数据在文件中的位置(如行数),即快速完成定位。
比如一张表(即数据湖文件)有id、name、age三个字段,可选择对id字段建立索引,如果查询语句有(请求)指定查找id=xxx的数据,那么就会优先过滤出id=xxx的文件,使得只读取那少量的几个文件,不用找所有的数据文件,从而加快缩小需要读取的文件内容和耗时。
换言之,本申请实施例的方法还可以包括:对于不存在索引的各文件,则遍历各文件以定位出当中记有目标数据的目标文件,并输出目标数据在目标文件中的存储位置。
如果建立索引的字段是id字段,若指定查找age=xxx的数据,那么就跟没有索引时查找的效果一致了,查询时间长,即需要读取所有的数据文件,才能定位出记有age=xxx的目标文件,最后才能在该目标文件中定位出age=xxx的位置。此情况下,相应的解决措施可以是,改写查询语句(如改成id=xxx)以便能利用到索引字段id,当然,也可以选择以age为索引字段建立一套供对应使用的索引,进而通过索引内容快速完成数据定位。
基于上述说明可得,实际应用中,可搭建出如图5所示的技术架构图。其中,步骤1、x-scheduler可以定期调度并执行构建索引的任务;步骤2、索引构建任务主要应用于Iceberg表的某个字段,并针对当前快照与数据完成索引的构建,如为Iceberg的id字段构建索引,使得Iceberg具有索引能力;具体的,可以把Iceberg表里的某部分字段(如id或age字段)抽出来,当做任意要构建索引的字段,以建立出如图3或图4的索引结构。步骤3和4、整个系统都由hadoop平台支撑,数据存储在可存海量数据的HDFS系统,任务调度为与HDFS配套的YARN调度。步骤5、最后由Trino引擎基于索引对Iceberg表进行数据查询。
由上述说明可知,本发明可通过索引提升Trino引擎查询Iceberg表的效率,大大提升对Iceberg表的查询性能(如表1),并且没有降低Iceberg表的写入性能,允许在tpc-h程序和30亿条数据的条件下,构建索引并进行明细查询:
数据量 无索引时的查询时间 有索引时的查询时间
1亿 0.9s 0.7s
10亿 3s 0.7s
30亿 6s 0.7s
表1有无索引时的查询时间比对表
由表1可以看到,随着存储数据量的增多,无索引时的查询时间逐步增加,而有索引时的查询时间基本不变,且少于无索引时的查询时间。
请参阅图6,本申请第二方面提供一种数据查询系统的一个具体示例,该系统包括:
处理单元601,用于基于当前数据湖的快照信息构建当前数据湖的索引;其中,快照信息用于记录当前数据湖的文件被快照时包含的数据信息,当前数据湖以行为标记的形式记录较比历史数据湖发生过的数据变更情况,行为标记包含新增、删除或修改数据,索引关联有各数据在数据湖文件中的存储位置信息;
查询单元602,用于依据索引信息,输出请求查询的目标数据在当前数据湖中的存储位置。
可选地,处理单元601具体用于:
使用哈希算法计算当前数据湖中各条数据记录对应的哈希值;
将每一数据记录在数据湖文件中的存储位置信息与相应的哈希值进行绑定,以得到每一条数据记录的映射对,并将映射对存放到不同的哈希桶中;
排布各哈希桶所存的映射对信息,以构建得当前数据湖的索引。
可选地,存储位置信息包含所存数据在数据湖中对应所属的文件路径、所存数据在文件中的位置。
可选地,处理单元601具体用于:
将当前数据湖中所有数据记录对应的关键字和存储位置信息,按平衡树规则排布以得到充当索引的索引树。
可选地,处理单元601具体用于:
基于变更操作请求在指定文件中添加相应的行为标记内容,以得到当前数据湖;其中,指定文件为历史数据湖内被请求变更的文件。
可选地,行为标记内容用于指出新写入的数据、示意删除或修改指定文件中的部分数据内容。
可选地,查询单元602具体用于:
对于不引用索引规则的查询语句,解析查询语句,以判断当前数据湖中被请求读取的待读文件是否对应存在索引;索引规则表示数据及数据存储位置之间在记载上存在映射关系;
若存在索引,则依据索引记载的目录项内容改写查询语句,以获得引用索引规则后的新版查询语句;
依据新版查询语句的指示信息,查找出目标数据在待读文件中的存储位置,指示信息表示优先通过索引字段读取出待读文件的位置信息。
可选地,处理单元601还用于:
对于不存在索引的各文件,遍历各文件以定位出当中记有目标数据的目标文件,并输出目标数据在目标文件中的存储位置。
可选地,处理单元601具体用于:
在历史数据湖发生数据变更后的预设时刻,对变更得到的当前数据湖建立索引。
本申请实施例中,数据查询系统各单元所执行的操作,与前述第一方面或第一方面的任一具体方法实施例所描述的操作类似),具体此处不再赘述。当然,本申请第一方面各操作的具体实现过程也可参见第二方面的相关描述实现。
请参阅图7,本申请实施例的电子设备700可以包括一个或一个以上中央处理器CPU(CPU,centralprocessing units)701和存储器705,该存储器705中存储有一个或一个以上的应用程序或数据。
其中,存储器705可以是易失性存储或持久存储。存储在存储器705的程序可以包括一个或一个以上模块,每个模块可以包括对电子设备中的一系列指令操作。更进一步地,中央处理器701可以设置为与存储器705通信,在电子设备700上执行存储器705中的一系列指令操作。
电子设备700还可以包括一个或一个以上电源702,一个或一个以上有线或无线网络接口703,一个或一个以上输入输出接口704,和/或,一个或一个以上操作系统,例如Windows ServerTM,Mac OS XTM,UnixTM,LinuxTM,FreeBSDTM等。
该中央处理器701可以执行前述第一方面或第一方面的任一具体方法实施例所执行的操作,具体不再赘述。
本申请提供的一种计算机可读存储介质,包括指令,当指令在计算机上运行时,使得计算机执行如上述第一方面或第一方面的任一具体实现方式所描述的方法。
本申请提供的一种包含指令或计算机程序的计算机程序产品,当计算机程序产品在计算机上运行时,使得计算机执行如上述第一方面或第一方面的任一具体实现方式所描述的方法。
可以理解的是,在本申请的各种实施例中,各步骤的序号大小并不意味着执行顺序的先后,各步骤的执行顺序应以其功能和内在逻辑确定,而不应对本申请实施例的实施过程构成任何限定。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统(若存在)、装置的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统或装置,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品(计算机程序产品)存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,业务服务器,或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,read-onlymemory)、随机存取存储器(RAM,random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。

Claims (12)

1.一种数据查询方法,其特征在于,包括:
基于当前数据湖的快照信息构建所述当前数据湖的索引;其中,所述快照信息用于记录所述当前数据湖的文件被快照时包含的数据信息,所述当前数据湖以行为标记的形式记录较比历史数据湖发生过的数据变更情况,所述行为标记包含新增、删除或修改数据,所述索引关联有各数据在数据湖文件中的存储位置信息;
依据所述索引信息,输出请求查询的目标数据在所述当前数据湖中的存储位置。
2.根据权利要求1所述的数据查询方法,其特征在于,所述基于当前数据湖的快照信息构建所述当前数据湖的索引,包括:
使用哈希算法计算所述当前数据湖中各条数据记录对应的哈希值;
将每一所述数据记录在数据湖文件中的存储位置信息与相应的所述哈希值进行绑定,以得到每一条所述数据记录的映射对,并将所述映射对存放到不同的哈希桶中;
排布各所述哈希桶所存的所述映射对信息,以构建得所述当前数据湖的索引。
3.根据权利要求2所述的数据查询方法,其特征在于,所述存储位置信息包含所存数据在数据湖中对应所属的文件路径、所述所存数据在文件中的位置。
4.根据权利要求1所述的数据查询方法,其特征在于,所述基于当前数据湖的快照信息构建所述当前数据湖的索引,包括:
将所述当前数据湖中所有数据记录对应的关键字和存储位置信息,按平衡树规则排布以得到充当所述索引的索引树。
5.根据权利要求1所述的数据查询方法,其特征在于,所述当前数据湖的获得过程包括:
基于变更操作请求在指定文件中添加相应的行为标记内容,以得到所述当前数据湖;其中,所述指定文件为所述历史数据湖内被请求变更的文件。
6.根据权利要求5所述的数据查询方法,其特征在于,所述行为标记内容用于指出新写入的数据、示意删除或修改所述指定文件中的部分数据内容。
7.根据权利要求1所述的数据查询方法,其特征在于,所述依据所述索引信息,输出请求查询的目标数据在所述当前数据湖中的存储位置,包括:
对于不引用索引规则的查询语句,解析所述查询语句,以判断所述当前数据湖中被请求读取的待读文件是否对应存在索引;所述索引规则表示数据及数据存储位置之间在记载上存在映射关系;
若存在索引,则依据所述索引记载的目录项内容改写所述查询语句,以获得引用索引规则后的新版查询语句;
依据所述新版查询语句的指示信息,查找出所述目标数据在所述待读文件中的存储位置,所述指示信息表示优先通过索引字段读取出所述待读文件的位置信息。
8.根据权利要求1至7中任一项所述的数据查询方法,其特征在于,所述方法还包括:对于不存在索引的各文件,遍历所述各文件以定位出当中记有所述目标数据的目标文件,并输出所述目标数据在所述目标文件中的存储位置。
9.根据权利要求1至7中任一项所述的数据查询方法,其特征在于,所述索引的获得过程包括:
在所述历史数据湖发生数据变更后的预设时刻,对变更得到的所述当前数据湖建立索引。
10.一种数据查询系统,其特征在于,包括:
处理单元,用于基于当前数据湖的快照信息构建所述当前数据湖的索引;其中,所述快照信息用于记录所述当前数据湖的文件被快照时包含的数据信息,所述当前数据湖以行为标记的形式记录较比历史数据湖发生过的数据变更情况,所述行为标记包含新增、删除或修改数据,所述索引关联有各数据在数据湖文件中的存储位置信息;
查询单元,用于依据所述索引信息,输出请求查询的目标数据在所述当前数据湖中的存储位置。
11.一种电子设备,其特征在于,包括:中央处理器,存储器以及输入输出接口;所述存储器为短暂存储存储器或持久存储存储器;
所述中央处理器配置为与所述存储器通信,并执行所述存储器中的指令操作以执行权利要求1至9中任意一项所述的方法。
12.一种计算机可读存储介质,其特征在于,包括指令,当所述指令在计算机上运行时,使得计算机执行如权利要求1至9中任意一项所述的方法。
CN202311375013.2A 2023-10-20 2023-10-20 数据查询方法、系统及相关设备 Pending CN117312370A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311375013.2A CN117312370A (zh) 2023-10-20 2023-10-20 数据查询方法、系统及相关设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311375013.2A CN117312370A (zh) 2023-10-20 2023-10-20 数据查询方法、系统及相关设备

Publications (1)

Publication Number Publication Date
CN117312370A true CN117312370A (zh) 2023-12-29

Family

ID=89237248

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311375013.2A Pending CN117312370A (zh) 2023-10-20 2023-10-20 数据查询方法、系统及相关设备

Country Status (1)

Country Link
CN (1) CN117312370A (zh)

Similar Documents

Publication Publication Date Title
Armbrust et al. Delta lake: high-performance ACID table storage over cloud object stores
JP6617117B2 (ja) 半構造データのためのスケーラブルな分析プラットフォーム
Sumbaly et al. The big data ecosystem at linkedin
CN105630864B (zh) 存储行标识符值的字典的强制排序
US8051045B2 (en) Archive indexing engine
Chavan et al. Survey paper on big data
US9697273B2 (en) Unique value calculation in partitioned table
Khalifa et al. The six pillars for building big data analytics ecosystems
US9639542B2 (en) Dynamic mapping of extensible datasets to relational database schemas
US10853368B2 (en) Distinct value estimation for query planning
CN113227998A (zh) 全面支持自主json文档对象(ajd)云服务的技术
CN107077480B (zh) 一种构建列存储数据库的方法和系统
Lee et al. Large-scale incremental processing with MapReduce
JP2016519810A (ja) 半構造データのためのスケーラブルな分析プラットフォーム
US20140046928A1 (en) Query plans with parameter markers in place of object identifiers
WO2013074665A1 (en) Data processing service
US10860562B1 (en) Dynamic predicate indexing for data stores
Vajk et al. Automatic NoSQL schema development: A case study
Ciritoglu et al. Hard: a heterogeneity-aware replica deletion for hdfs
US10095738B1 (en) Dynamic assignment of logical partitions according to query predicate evaluations
US20170270149A1 (en) Database systems with re-ordered replicas and methods of accessing and backing up databases
US20140258216A1 (en) Management of searches in a database system
Mehrotra et al. Apache Spark Quick Start Guide: Quickly learn the art of writing efficient big data applications with Apache Spark
CN117312370A (zh) 数据查询方法、系统及相关设备
Taori et al. Big Data Management

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