CN115033547A - 数据处理方法、装置、电子设备及系统 - Google Patents
数据处理方法、装置、电子设备及系统 Download PDFInfo
- Publication number
- CN115033547A CN115033547A CN202210388087.9A CN202210388087A CN115033547A CN 115033547 A CN115033547 A CN 115033547A CN 202210388087 A CN202210388087 A CN 202210388087A CN 115033547 A CN115033547 A CN 115033547A
- Authority
- CN
- China
- Prior art keywords
- data
- information
- extended metadata
- partition
- field
- 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/18—File system types
- G06F16/182—Distributed file systems
-
- 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
-
- 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
-
- 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
- G06F16/278—Data partitioning, e.g. horizontal or vertical partitioning
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computational Linguistics (AREA)
- Computing Systems (AREA)
- Mathematical Physics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本申请实施例提供一种数据处理方法、装置、电子设备及系统。该数据处理方法,包括:获取分布式文件系统的至少一个待处理数据,确定每一待处理数据的第一字段所在的数值范围;将数值范围划分为至少两个子数值范围;基于至少两个子数值范围,将待处理数据划分为至少两个扩展元数据文件;基于每一扩展元数据文件的数据属性,新建扩展元数据;数据属性包括每一扩展元数据文件所在的子数值范围。本申请实施例通过新建扩展元数据,对数据进一步细分,使得后续查询时只需要查询第一字段的字段信息所在的扩展元数据文件的数据,不需要扫描整个分区下的所有数据,提高了查询效率,从而提高了查询性能,避免了延迟大的问题。
Description
技术领域
本申请涉及数据处理的技术领域,具体而言,本申请涉及数据处理方法、装置、电子设备及系统。
背景技术
HDFS(Hadoop Distributed File System,分布式文件系统)是运行在通用硬件上的分布式文件系统,适用于大规模数据集。分布式文件系统的结构化数据文件可以被Hive映射成类似于数据库的分区表。
目前,Hive在分区表查询时,由于分区表的元数据,对应的数据量多,数据并未进一步细分,需要扫描整个分区下的所有数据文件,导致查询性能差和延迟大的问题。
发明内容
本申请实施例提供了一种数据处理方法、装置、电子设备及系统,用于解决由于数据没有进一步细分,导致查询性能差或延迟大的问题。
第一方面,本申请实施例提供一种数据处理方法,包括:
获取分布式文件系统的至少一个待处理数据,确定每一待处理数据的第一字段所在的数值范围;
将数值范围划分为至少两个子数值范围;
基于至少两个子数值范围,将待处理数据划分为至少两个扩展元数据文件;
基于每一扩展元数据文件的数据属性,新建扩展元数据;数据属性包括每一扩展元数据文件所在的子数值范围,扩展元数据存储在分布式文件系统中。
在一个可能的实现方式中,获取分布式文件系统的至少一个待处理数据,包括:
获取分布式文件系统的版本信息;
基于版本信息,确定分布式文件系统的根目录;
确定根目录中需要进行数据处理的至少一个分区目录;
将每一分区目录对应的数据,作为待处理数据。
在一个可能的实现方式中,将数值范围划分为至少两个子数值范围,包括:
确定根目录中需要进行数据处理的相关数据数量;相关数据数量包括以下至少一项:分区目录总数、文件总数;
基于相关数据数量,确定分区因子;分区因子用于确定每一子数值范围;
基于分区因子,将数值范围划分为至少两个子数值范围。
在一个可能的实现方式中,基于每一扩展元数据文件的数据属性,新建扩展元数据之后,包括:
基于每一扩展元数据文件,建立一个分区子目录;分区子目录为分区目录的下一级目录或同级目录,扩展元数据文件存储在分布式文件系统中;
将每一扩展元数据文件与分区子目录的对应关系,和/或每一扩展元数据文件所在的子数值范围与分区子目录对应关系,保存到扩展元数据。
第二方面,本申请实施例提供一种数据处理方法,包括:
获取查询信息,从查询信息中提取第一字段;
从扩展元数据中,确定第一字段的字段信息所在的至少一个扩展元数据文件,将至少一个扩展元数据文件的数据作为待查询数据;扩展元数据基于如第一方面的数据处理方法生成,字段信息包括数值或数值范围;
基于字段信息,从待查询数据中,确定符合查询信息的数据。
在一个可能的实现方式中,基于字段信息,从待查询数据中,确定符合查询信息的数据,包括:
基于字段信息,从待查询数据中,确定符合字段信息的候选数据;
从候选数据中,确定符合查询信息中的除字段信息外的其他信息的数据,作为确定符合查询信息的数据。
在一个可能的实现方式中,从扩展元数据中,确定第一字段的字段信息所在的至少一个扩展元数据文件,包括:
从扩展元数据中,确定第一字段的字段信息对应的至少一个子数值范围;
基于扩展元数据内的子数值范围与分区子目录对应关系,确定与至少一个子数值范围对应的至少一个分区子目录;
确定每一分区子目录对应的一个扩展元数据文件。
第三方面,本申请实施例提供一种数据处理装置,包括:
获取模块,用于获取分布式文件系统的至少一个待处理数据,确定每一待处理数据的第一字段所在的数值范围;
第一划分模块,用于将所述数值范围划分为至少两个子数值范围;
第二划分模块,用于将数值范围划分为至少两个子数值范围,基于至少两个子数值范围,将待处理数据划分为至少两个扩展元数据文件;
新建模块,用于基于每一扩展元数据文件的数据属性,新建扩展元数据;数据属性包括每一扩展元数据文件所在的子数值范围,扩展元数据存储在分布式文件系统中。
第四方面,本申请实施例提供一种数据处理装置,包括:
查询模块,用于获取查询信息,从查询信息中提取第一字段;
第一确定模块,用于从扩展元数据中,确定第一字段的字段信息所在的至少一个扩展元数据文件,将至少一个扩展元数据文件的数据作为待查询数据;扩展元数据基于如第一方面的数据处理方法生成,字段信息包括数值或数值范围;
第二确定模块,用于基于字段信息,从待查询数据中,确定符合查询信息的数据。
第五方面,本申请实施例提供一种电子设备,包括存储器、处理器及存储在存储器上的计算机程序,处理器执行计算机程序以实现第一方面或第二方面的数据处理方法的步骤。
第六方面,本申请实施例提供一种数据处理系统,包括:驱动单元、编译单元、执行单元和分布式文件系统;
分布式文件系统内存储的扩展元数据基于如第一方面的数据处理方法生成;
编译单元,与驱动单元电连接,用于接收驱动单元发送的查询信息,从查询信息中提取第一字段,从扩展元数据中确定第一信息,基于第一信息和查询信息生成第一执行信息并向驱动单元发送;第一信息包括第一字段的字段信息所在的至少一个扩展元数据文件的信息;
执行单元,与驱动单元电连接,用于接收驱动单元发送的第一执行信息,并基于第一执行信息从分布式文件系统中获取符合查询信息的数据,形成第一查询结果,将第一查询结果向驱动单元发送。
在一个可能的实现方式中,数据处理系统,还包括:元数据库;
编译单元,还用于在从查询信息中未提取到第一字段时,从元数据库中确定第二信息,基于第二信息和查询信息生成第二执行信息并向驱动单元发送;第二信息包括查询信息对应的分区目录的信息;
执行单元,还用于接收驱动单元发送的第二执行信息,并基于第二执行信息从分布式文件系统中获取符合查询信息的数据,形成第二查询结果,将第二查询结果向驱动单元发送。
本申请实施例提供一种计算机可读存储介质,其上存储有计算机程序,计算机程序被处理器执行时实现第一方面或第二方面的数据处理方法的步骤。
本申请实施例提供的技术方案带来的有益效果是:
本申请实施例获取分布式文件系统的至少一个待处理数据,确定每一待处理数据的第一字段所在的数值范围,将数值范围划分为至少两个子数值范围,使得可以基于至少两个子数值范围,将待处理数据划分为至少两个扩展元数据文件,从而基于第一字段所在的数值范围将待处理数据划分为两类数据,基于每一扩展元数据文件的数据属性,新建扩展元数据。由于扩展元数据是基于每一扩展元数据文件的数据属性得到,从而在后续查询时,从扩展元数据中,可以根据第一字段的字段信息,确定字段信息对应的至少一个扩展元数据文件,从而只需要查询扩展元数据文件的数据,不需要扫描整个分区下的所有数据,提高了查询效率,从而提高了查询性能,避免了延迟大的问题。
附图说明
为了更清楚地说明本申请实施例中的技术方案,下面将对本申请实施例描述中所需要使用的附图作简单地介绍。
图1为本申请实施例提供的一种数据处理方法的流程示意图;
图2为本申请实施例提供的另一种数据处理方法的流程示意图;
图3为本申请实施例提供的又一种数据处理方法的流程示意图;
图4为本申请实施例提供的一种第一数据处理装置的结构示意图;
图5为本申请实施例提供的一种第二数据处理装置的结构示意图;
图6为本申请实施例提供的一种数据处理系统的结构示意图;
图7为本申请实施例提供的一种查询信息转换成具体的执行任务的流程示意图;
图8为本申请实施例提供的一种电子设备的结构示意图。
具体实施方式
下面结合本申请中的附图描述本申请的实施例。应理解,下面结合附图所阐述的实施方式,是用于解释本申请实施例的技术方案的示例性描述,对本申请实施例的技术方案不构成限制。
本技术领域技术人员可以理解,除非特意声明,这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是,本申请实施例所使用的术语“包括”以及“包含”是指相应特征可以实现为所呈现的特征、信息、数据、步骤、操作、元件和/或个件,但不排除实现为本技术领域所支持其他特征、信息、数据、步骤、操作、元件、个件和/或它们的个合等。应该理解,当我们称一个元件被“连接”或“耦接”到另一元件时,该一个元件可以直接连接或耦接到另一元件,也可以指该一个元件和另一元件通过中间元件建立连接关系。此外,这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的术语“和/或”指示该术语所限定的项目中的至少一个,例如“A和/或B”指示实现为“A”,或者实现为“B”,或者实现为“A和B”。
为使本申请的目的、技术方案和优点更加清楚,下面将结合附图对本申请实施方式作进一步地详细描述。
首先对本申请涉及的几个名词进行介绍和解释:
SQL:是结构化查询语言(StructuredQueryLanguage)的简称。SQL语言是一种数据库查询和程序设计语言,用于存取数据以及查询、更新和管理关系数据库系统;同时也是数据库脚本文件的扩展名。
Hive SQL:是HiveStructuredQuery Language的缩写,提供基于SQL的查询能力,能够将SQL转化成MapReduce任务,从而简化分布式任务开发难度。
ETL:是Extract-Transform-Load的缩写,用来描述将数据从来源端经过抽取(extract)、转换(transform)、加载(load)至目的端的过程。ETL一词较常用在数据仓库,但其对象并不限于数据仓库。
元数据:Metadata,又称中介数据、中继数据,为描述数据的数据(data aboutdata),主要是描述数据属性(property)的信息,用来支持如指示存储位置、历史数据、资源查找、文件记录等功能。元数据算是一种电子式目录,为了达到编制目录的目的,必须在描述并收藏数据的内容或特色,进而达成协助数据检索的目的。
HDFS:Hadoop分布式文件系统,有着高容错性(fault-tolerant)的特点,并且设计用来部署在低廉的(low-cost)硬件上。而且它提供高吞吐量(high throughput)来访问应用程序的数据,适合那些有着超大数据集(large data set)的应用程序。
MapReduce:是一种编程模型,用于大规模数据集的并行运算。
Hive:是基于Hadoop的一个数据仓库工具,可以将结构化的数据文件映射为一张数据库表,并提供完整的SQL查询功能,可以将SQL语句转换为MapReduce任务进行运行。
经研究发现,随着湖仓一体化的融合,在湖上建仓,快速适配不同的业务需求成为未来数据仓库发展的趋势,Hive作为当前大数据领域,数据仓库建设事实上的标准,可以将存储在底层分布式文件系统HDFS上的结构化数据文件映射成类似于数据库的二维表,并能提供类SQL的查询语言(Hive SQL),使得熟悉SQL的用户可以通过Hive SQL就可以进行大数据查询、分析和ETL操作,避免再去编写复杂的MapReduce任务,整体上提升了用户的使用效率。
随着Hive表数据量的增长,单表管理的数据量往往能达到几十至几百TB(Terabyte,太字节),有的甚至上PB(PetaByte,拍字节)级别,为了近一步提升Hive SQL的查询效率,对于这样的大表往往采用分区表的形式来进行管理,也就是通过设置分区键的形式,将数据根据分区键划分到不同的HDFS目录下存储,执行查询时,在Hive SQL中指定要查询的分区条件,进行粗粒度的分区裁剪,从而避免扫描整个表的数据,达到加速查询的目的。
但是,Hive的出现虽然降低了大数据查询和分析的使用门槛,但随着单表管理数据量的增加,虽然Hive的底层执行引擎可以从MapReduce换成Tez或者Spark,来进行一定的提升,但其在大分区表查询的性能方面依然存在延迟大的问题。其中,MapReduce、Tez和Spark均为Hive引擎。
在Hive执行过程中,首先由驱动器Driver接收用户提交的Hive SQL语句,并交由编译器进行Hive SQL语法解析、语义编译、生产逻辑和物理执行计划。编译器会查询元数据库以取得表的元数据,通过优化器生成优化的执行计划,并最终由具体的执行引擎,如MapReduce,Tez,Spark进行作业的执行,当作业执行完成后,执行引擎会将分布式文件系统上的结果信息返回给驱动单元的驱动程序,最终完成整个查询过程。
在这个过程中,Hive元数据库中存储了Hive表的归属库名、表字段名、表字段类型、字段存储类型、字段序列化和反序列化解析器、以及表分区信息。其中,元数据SDS表中存储了Hive表的HDFS存储基本信息,比如建表时指定的输入格式(INPUT_FORMAT)、输出格式(OUTPUT_FORMAT)、以及压缩格式、是否分桶、HDFS路径等;Hive分区相关的元数据存储在PARTITIONS、PARTITION_KEYS、PARTITION_KEY_VALS这些表中,其中,PARTITIONS存储了分区ID(Identity Document,身份标识号)、分区名称、创建时间等基本信息,PARTITION_KEYS存储了分区字段名称、字段类型、字段顺序等,PARTITION_KEY_VALS存储了分区字段值和顺序。
受Hive本身元数据设计的限制,分区元数据信息只保存到分区目录级别,对于大分区表,其分区元数据PARTITIONS表对应的记录数就可能达到几十万。
在Hive生成和优化执行计划过程中,需要频繁访问元数据库中的数据,遍历分区下的数据文件,以获取需要的文件级别统计信息,有时单个分区下文件的数量就有上万级别,对分区目录文件的扫描会对HDFS的NameNode(主节点)产生较大的访问压力,很容易形成性能瓶颈,也会消耗较长的时间,最终导致Hive在大分区表的查询上效率非常低,延迟非常大。
进一步研究发现,Hive在大分区表查询中,由于其元数据库中的元数据只记录到对应的分区目录,设计粒度粗,无法对分区下文件做细粒度的裁剪,这种粗力度的设计导致执行计划生成和优化时需要扫描整个分区下的所有数据文件,是其在大分区表查询中查询性能差、延迟大的主要原因,这是当前技术存在的主要缺点。
本申请提供的数据处理方法、装置、电子设备及系统,旨在解决现有技术的如上技术问题。
本申请实施例提供一种数据处理方法,参见图1所示,包括:步骤S101至步骤S104。
S101、获取分布式文件系统的至少一个待处理数据,确定每一待处理数据的第一字段所在的数值范围。
可选地,第一字段为数值类型的字段,例如:订单金额。
在一些实施例中,步骤S101中,获取分布式文件系统的至少一个待处理数据,包括:
获取分布式文件系统的版本信息。
基于版本信息,确定分布式文件系统的根目录。
确定根目录中需要进行数据处理的至少一个分区目录。
将每一分区目录对应的数据,作为待处理数据。
可选地,获取分布式文件系统的版本信息是获取当前的版本信息,以获取当前的根目录。
可选地,根目录包括多个分区目录,确定根目录中需要进行数据处理的至少一个分区目录,可以包括:
确定至少一个分区目录是否满足设定的分区条件,若满足设定的分区条件,则确定分区目录需要进行数据处理。
可选地,设定的分区条件包括以下至少之一:分区目录对应的数据文件标识有可分区信息、分区目录可生成下一级分区子目录。分区条件也可以根据实际应用设置,用户通过标识分区目录及分区目录对应的数据文件实现。
可选地,每一分区目录对应至少一个数据文件,每一分区目录对应的数据为分区目录对应的数据文件里的所有数据。
具体的,确定每一待处理数据的第一字段所在的数值范围,可以包括:
确定每一待处理数据的第一字段的字段值的最小值和最大值;
根据所确定的最小值和最大值确定第一字段所在的数值范围。
可选的,可以直接将最小值和最大值作为数值范围的两个端点值。例如,第一字段所在的数值范围为0-1000。
S302、将数值范围划分为至少两个子数值范围。
在一些可能的实施方式中,将数值范围划分为至少两个子数值范围,可以包括:
根据数值范围,确定至少一个中间数值;
根据中间数值将数值范围划分为至少两个子数值范围。
可选地,例如数值范围为0-1000,确定中间数值为200、400、600和800,则可以将数值范围划分0-200、201-400、401-600、601-800、801-1000这5个子数值范围,根据待处理数据的每一数据的第一字段的字段值,对应划分成五类数据,五类数据形成五个扩展元数据文件。将所有子数值范围顺序排列,除开最后一个子数值范围,每个中间数值为子数值范围的最大值,除开第一个子数值范围和最后一个子数值范围,每个子数值范围的最小值为中间数值加上预设值,预设值可取值为1,也可以取值为0。
可选地,步骤S302中,将数值范围划分为至少两个子数值范围,包括:
确定根目录中需要进行数据处理的相关数据数量;相关数据数量包括以下至少一项:分区目录总数、文件总数。
基于相关数据数量,确定分区因子;分区因子用于确定每一子数值范围。
基于分区因子,将数值范围划分为至少两个子数值范围。
可选地,文件总数即数据文件总数,每一分区目录对应至少一个数据文件。
可选地,分区因子用于确定子数值范围的个数,并基于数值范围和子数值范围的个数,确定每一子数值范围。
可选地,基于分区因子,将数值范围划分为至少两个子数值范围,可以包括:
基于分区因子,确定子数值范围的数量;
基于所确定的子数值范围的数量,确定至少一个中间数值;
根据中间数值将数值范围划分为至少两个子数值范围。
可选地,根据所确定的子数值范围的数量N,从数值范围的最小值和最大值之间选择N-1个中间数值,形成N个子数值范围。中间数值是作为子数值范围的一个端点,选择中间数值时,尽量保持每个子数值范围的区间范围相同或相近,如上述示例中:数值范围为0-1000的划分为例,这样便于将待处理数据合理划分,进一步提高查询效率。
可选地,基于版本信息,确定分布式文件系统的根目录之后,还可以包括:确定字段总数。字段总用于作为标识信息,可不参与数据处理的过程。
S303、基于至少两个子数值范围,将待处理数据划分为至少两个扩展元数据文件。
可选地,步骤S303中,基于至少两个子数值范围,将待处理数据划分为至少两个扩展元数据文件,可以包括:
确定待处理数据的每一数据的第一字段所在的子数值范围,基于每一数据的第一字段所在的子数值范围,将待处理数据划分为至少两类数据,每类数据存储在一个扩展元数据文件中。
可选地,扩展元数据文件为JSON文件。其中,JSON是一种基于JavaScript语法子集的开放标准数据交换格式。
可选地,每个扩展元数据文件为一类数据的集合,扩展元数据文件内的数据可以以多个数据文件的形式分类存储。
S304、基于每一扩展元数据文件的数据属性,新建扩展元数据;数据属性包括每一扩展元数据文件所在的子数值范围,扩展元数据存储在分布式文件系统中。
可选地,扩展元数据是基于每一扩展元数据文件的数据属性生成,扩展元数据可以是一个扩展元数据表,包括每一扩展元数据文件和子数值范围的对应关系。
可选地,每一扩展元数据文件和子数值范围的对应信息可以是以扩展元数据文件的文件名和子数值范围对应的形式。
本申请实施例可以基于分布式文件系统存储扩展元数据,这样可以有效降低元数据集中存储导致的查询性能损失,从而达到优化查询的效果。
在一些实施例中,步骤S304中,基于每一扩展元数据文件的数据属性,新建扩展元数据之后,包括:
基于每一扩展元数据文件,建立一个分区子目录;分区子目录为分区目录的下一级目录或同级目录,扩展元数据文件存储在分布式文件系统中;
将每一扩展元数据文件与分区子目录的对应关系,和/或每一扩展元数据文件所在的子数值范围与分区子目录对应关系,保存到扩展元数据。
可选地,扩展元数据保存有扩展元数据文件与分区子目录的对应关系和/或子数值范围与分区子目录对应关系,便于后续查询时,基于第一字段的字段信息,确定字段信息所在的至少一个分区子目录,在分布式文件系统中查找到分区子目录对应的扩展元数据文件,从而对扩展元数据文件的数据进行扫描,得到符合查询信息的数据。
可选地,扩展元数据包括扩展元数据文件的数量,每一扩展元数据文件中列存储的统计描述信息,如列的最大值、最小值、类型。
可选地,分区目录可以是按时间划分的目录,例如:以年份划分,分区目录分别为2020年,2021年,2020年。每一年的分区目录均对应有至少一个数据文件,在每一年的分区目录下继续基于第一字段的数值范围进行划分,得到至少两个分区子目录和对应的扩展数据文件。
可选地,本申请实施例在Hive分区表加载Parquet或者ORC类型数据文件时,将该数据文件的列统计信息,如列的类型、编解码类型、空值、最大值、最小值等信息,统一存放到扩展元数据文件中。其中,Parquet类型数据文件是Hadoop分布式文件系统中的任何项目都可以使用压缩的高效的列式数据表示形式,是一种存储数据的格式。ORC(Optimized RowColumnar)类型数据文件,可以应用在Hadoop分布式文件系统中,是一种高效存储数据的格式。
可选地,基于每一扩展元数据文件的数据属性,新建扩展元数据之后,可以包括:
响应于扩展元数据文件或分区子目录的更新操作,对应更新扩展元数据中的相关信息。更新操作包括以下至少一项:新增、删除、修改。相关信息包括以下至少一项:扩展元数据文件和子数值范围的对应关系、扩展元数据文件与分区子目录的对应关系、子数值范围与分区子目录对应关系。对应更新扩展元数据中的相关信息是指对应新增、删除或修改相关信息。
可选地,Hive在加载数据的过程中,通过列存文件API(Application ProgramInterface,应用程序接口)获取对应数据文件所在的分区目录所对应子数值范围,将数据文件内的数据并统一更新到扩展元数据文件中。
可选地,Hive在图2所示的第3步生成逻辑执行计划阶段,可以获取本次查询涉及字段所对应的分区目录下的每一数据文件中该字段值的上限、下限、字段编码类型等扩展元数据。在图2第4步逻辑执行计划时,根据表扫描操作如挑选(Select)和过滤(Filter)操作节点,利用扩展元数据中对应的第一字段的字段信息,得到字段取值范围涉及的分区子目录,以及对应分区子目录下的扩展元数据文件,便可以实现分区文件细粒度裁剪,达到避免遍历所有分区文件的操作,从整体上可以有效降低大分区表的分区目录文件扫描数量。
可选地,参见图2所示,本申请实施例提供一种数据处理方法,包括:步骤S201至步骤S209。
S201、获取分布式文件系统的版本信息。
可选地,获取分布式文件系统的版本信息是获取当前的版本信息,以获取当前的根目录。
S202、基于版本信息,确定分布式文件系统的根目录,之后执行步骤S203和步骤S205。
可选地,根目录包括多个分区目录。
S203、确定根目录中需要进行数据处理的至少一个分区目录。
确定根目录中需要进行数据处理的至少一个分区目录,包括:
确定至少一个分区目录是否满足设定的分区条件,若满足设定的分区条件,则确定分区目录需要进行数据处理。
可选地,设定的分区条件以下至少之一:分区目录对应的数据文件标识有可分区信息、分区目录可生成下一级分区子目录。分区条件也可以根据实际应用设置,用户通过标识分区目录及分区目录对应的数据文件实现。
可选地,每一分区目录对应至少一个数据文件,每一分区目录对应的数据为分区目录对应的数据文件里的所有数据。
S204、将每一分区目录对应的数据,作为待处理数据,之后执行步骤S208。
S205、确定根目录中需要进行数据处理的相关数据数量;相关数据数量包括以下至少一项:分区目录总数、文件总数。
可选地,文件总数即数据文件总数,每一分区目录对应至少一个数据文件。
S206、基于相关数据数量,确定分区因子;分区因子用于确定每一子数值范围。
可选地,分区因子用于确定子数值范围的个数,并基于数值范围和子数值范围的个数,确定每一子数值范围。
S207、基于分区因子,将数值范围划分为至少两个子数值范围。
S208、基于至少两个子数值范围,将待处理数据划分为至少两个扩展元数据文件。
可选地,步骤S208与步骤S103的方法一致,在此不再赘述。
S209、基于每一扩展元数据文件的数据属性,新建扩展元数据;数据属性包括每一扩展元数据文件所在的子数值范围,扩展元数据存储在分布式文件系统中。
可选地,步骤S209与步骤S104的方法一致,在此不再赘述。
本申请实施例的数据出来方法提供一种新的思路,在Hive加载分区表数据的时候,在分区层面新建扩展元数据,同时为了避免元数据集中存储导致的访问性能问题,扩展元数据统一存储到分布式文件系统内,同时也将扩展元数据文件保存到分布式文件系统内。在Hive编译和执行过程中,可以通过该扩展元数据,进行高效的文件过滤和算子下推,避免大量的分区目录的数据文件扫描,从而提高了查询效率。
本申请实施例提供一种数据处理方法,参见图3所示,该数据处理方法包括:步骤S301至步骤S303。
S301、获取查询信息,从查询信息中提取第一字段。
可选地,查询信息可以是Hive SQL语句,第一字段为数值类型。
可选地,从查询信息中提取第一字段,包括:从查询信息中提取第一字段及第一字段的字段信息。
可选地,查询信息中提取第一字段,即表示查询信息包括第一字段,可以基于第一字段的字段信息从扩展元数据中查询。
S302、从扩展元数据中,确定第一字段的字段信息所在的至少一个扩展元数据文件,将至少一个扩展元数据文件的数据作为待查询数据;扩展元数据基于如上述本申请任一实施例的数据处理方法生成,字段信息包括数值或数值范围。
在一些实施例中,从扩展元数据中,确定第一字段的字段信息所在的至少一个扩展元数据文件,包括:
从扩展元数据中,确定第一字段的字段信息对应的至少一个子数值范围;
基于扩展元数据内的子数值范围与分区子目录对应关系,确定与至少一个子数值范围对应的至少一个分区子目录;
确定每一分区子目录对应的一个扩展元数据文件。
可选地,扩展元数据保存有扩展元数据文件与分区子目录的对应关系和/或子数值范围与分区子目录对应关系。基于第一字段的字段信息,确定字段信息所在的至少一个分区子目录,再确定每一分区子目录对应的一个扩展元数据文件,从而得到待查询数据。
可选地,每一扩展元数据文件包括多个数据,确定的至少一个扩展元数据文件的所有数据,组成待查询数据。
可选地,本申请实施例的扩展元数据保存有扩展元数据文件与分区子目录的对应关系和/或子数值范围与分区子目录对应关系,可以通过依次确定子数值范围和分区子目录,确定字段信息所在的至少一个扩展元数据文件,从而确定待查询数据。
S303、基于字段信息,从待查询数据中,确定符合查询信息的数据。
在一些实施例中,基于字段信息,从待查询数据中,确定符合查询信息的数据,包括:
基于字段信息,从待查询数据中,确定符合字段信息的候选数据;
从候选数据中,确定符合查询信息中的除字段信息外的其他信息的数据,作为确定符合查询信息的数据。
基于本申请实施例的技术方案,下面通过一个示例,进一步说明本申请的数据处理过程。现有一张PB级订单表,有5个字段分别是:订单ID(字符串类型),用户ID(字符串类型),商品ID(字符串类型),订单金额(数值类型),订单时间(日期类型),分区是按照日分区,对应的分区目录和数据文件以日期划分。因表数据非常大,单一分区下的数据文件非常多,如有10万个Parquet类型的文件。需要在在加载完数据后生成的扩展元数据。
可选地,订单金额为数值类型,作为第一字段,在编码中设置扩展节点(extended-info),非数值类型的扩展元数据字段,则没有对应的extended-info节点,针对数值类型的字段如订单金额则有扩展节点,标识出对应数值取值范围内的扩展元数据文件名称。
例如:扩展元数据中,子数值范围分别为1-1000,1001-2000,2001-5000,每一子数值范围都对应有扩展元数据文件和分区子目录。
针对查询语句“2022年3月11日,总数值大于1200且小于2000”,在Hive编译器优化时,可以根据该过滤条件,利用扩展节点的信息可以快速定位到分区子目录和扩展元数据文件,在基于日期划分的分区目录或分区子目录,确定符合查询信息的数据。例如,基于上述查询语句,确认每一个扩展元数据文件,这个扩展元数据文件内的数据文件包括:data012.parquet、data033.parquet、data018.parquet,只需要扫描这几个扩展元数据文件,确定满足查询信息的数据即可,从而避免扫描分区下所有的10万个文件来达到优化的效果。
本申请实施例是在当前主要以Hive为主的大数据数据仓库领域的情况下,通过将数据基于数值范围进行进一步划分,并新建扩展元数据,有效提高Hive大分区表的查询响应速度。在优化阶段,为Hive执行计划提供更准确的决策依据,从而在物理执行阶段可以有效命中分区目录下的数据文件,以及文件中的行组区域,避免大量无效的文件扫描和整体读取,可以有效地解决大分区表的查询效率问题。本申请实施例适用于针对湖仓一体化的大表查询的性能提升和优化。
本申请实施例提供一种第一数据处理装置,参见图4所示,该第一数据处理装置40包括:获取模块401、第一划分模块402、第二划分模块403和新建模块404。
获取模块401用于获取分布式文件系统的至少一个待处理数据,确定每一待处理数据的第一字段所在的数值范围。
第一划分模块402用于将数值范围划分为至少两个子数值范围。
第二划分模块403用于基于至少两个子数值范围,将待处理数据划分为至少两个扩展元数据文件。
新建模块404用于基于每一扩展元数据文件的数据属性,新建扩展元数据;数据属性包括每一扩展元数据文件所在的子数值范围,扩展元数据存储在分布式文件系统中。
可选地,获取模块401用于获取分布式文件系统的版本信息,基于版本信息,确定分布式文件系统的根目录,确定根目录中需要进行数据处理的至少一个分区目录,将每一分区目录对应的数据,作为待处理数据。
可选地,第一划分模块402用于确定根目录中需要进行数据处理的相关数据数量;相关数据数量包括以下至少一项:分区目录总数、文件总数,基于相关数据数量,确定分区因子;分区因子用于确定每一子数值范围,基于分区因子,将数值范围划分为至少两个子数值范围。
可选地,新建模块404用于基于每一扩展元数据文件,建立一个分区子目录;分区子目录为分区目录的下一级目录或同级目录,扩展元数据文件存储在分布式文件系统中;将每一扩展元数据文件与分区子目录的对应关系,和/或每一扩展元数据文件所在的子数值范围与分区子目录对应关系,保存到扩展元数据。
本实施例的第一数据处理装置可执行本申请实施例提供的任一种关于新建扩展元数据的数据处理方法,其实现原理相类似,此处不再赘述。
本申请实施例提供一种第二数据处理装置,参见图5所示,该第二数据处理装置50包括:查询模块501、第一确定模块502和第二确定模块503。
查询模块501用于获取查询信息,从查询信息中提取第一字段。
第一确定模块502用于从扩展元数据中,确定第一字段的字段信息所在的至少一个扩展元数据文件,将至少一个扩展元数据文件的数据作为待查询数据;扩展元数据基于如第一方面的数据处理方法生成,字段信息包括数值或数值范围。
第二确定模块503用于基于字段信息,从待查询数据中,确定符合查询信息的数据。
可选地,第一确定模块502用于从扩展元数据中,确定第一字段的字段信息对应的至少一个子数值范围;基于扩展元数据内的子数值范围与分区子目录对应关系,确定与至少一个子数值范围对应的至少一个分区子目录;确定每一分区子目录对应的一个扩展元数据文件。
可选地,第二确定模块503用于基于字段信息,从待查询数据中,确定符合字段信息的候选数据;从候选数据中,确定符合查询信息中的除字段信息外的其他信息的数据,作为确定符合查询信息的数据。
本实施例的第二数据处理装置可执行本申请实施例提供的任一种关于数据查询的数据处理方法,其实现原理相类似,此处不再赘述。
以下将从系统架构的角度对本申请的数据处理方法进行进一步阐述。本申请实施例提供一种数据处理系统,参见图6所示,该数据处理系统包括:驱动单元(Driver)、编译单元(Compiler)、执行单元(包括MapReduce、Tez、Spark)和分布式文件系统。
分布式文件系统内存储的扩展元数据,扩展元数据是基于本申请任一实施例的数据处理方法生成。具体的扩展元数据的生成方法在后续数据处理方法中进一步详细介绍。
编译单元与驱动单元电连接,编译单元用于接收驱动单元发送的查询信息,从查询信息中提取第一字段,从扩展元数据中确定第一信息,基于第一信息和查询信息生成第一执行信息并向驱动单元发送;第一信息包括第一字段的字段信息所在的至少一个扩展元数据文件的信息;
执行单元与驱动单元电连接,执行单元用于接收驱动单元发送的第一执行信息,并基于第一执行信息从分布式文件系统中获取符合查询信息的数据,形成第一查询结果,将第一查询结果向驱动单元发送。
可选地,驱动单元可以选用驱动器,用于接收查询信息。
查询信息可以是用户提交的Hive SQL语句。
可选地,编译单元可以选用编译器,编译器用于对Hive SQL语句进行语法解析、语义编译、生产逻辑和物理执行计划。
可选地,执行单元采用Hive引擎进行作业的执行,Hive引擎包括:默认MapReduce(即图中所示的MR)、Tez或Spark,不更换引擎Hive引擎默认的是MR。
可选地,扩展元数据文件的数据存储在分布式文件系统中。
可选地,第一字段的字段信息所在的至少一个扩展元数据文件的信息,可以的过程可以是:确定第一字段的字段信息所在的至少一个子数值范围,基于扩展元数据中的子数值范围与扩展元数据文件的对应关系,确定第一字段的字段信息所在的至少一个扩展元数据文件,作为第一信息。
可选地,扩展元数据是基于每一扩展元数据文件的数据属性生成,扩展元数据包括扩展元数据文件与子数值范围的对应关系,即每一扩展元数据文件所在的子数值范围。
可选地,扩展元数据也属于元数据,是指相当于原有的元数据进行的扩展,扩展元数据可以是扩展元数据表,第二信息是从扩展元数据表中获取的数据。
在一些实施例中,参见图6所示,数据处理系统,还包括:元数据库(MetaStore)。
编译单元还用于在从查询信息中未提取到第一字段时,从元数据库中确定第二信息,基于第二信息和查询信息生成第二执行信息并向驱动单元发送;第二信息包括查询信息对应的分区目录的信息;
执行单元还用于接收驱动单元发送的第二执行信息,并基于第二执行信息从分布式文件系统中获取符合查询信息的数据,形成第二查询结果,将第二查询结果向驱动单元发送。
可选地,元数据库存储了Hive表的分布式文件系统的分区目录的信息,即从元数据库中获取的是包括查询信息所在分区目录的元数据,作为第二信息。
可选地,第一字段为数值类型的字段,例如:订单金额。
可选地,元数据库用于存储元数据,元数据可以是元数据表,第二信息是从元数据表中获取的数据。
本申请实施例可以在查询信息包括第一字段时,从扩展元数据中确定第一信息,以确定第一字段的字段信息所在的至少一个扩展元数据文件的信息,从而使得执行单元可以基于确定的至少一个扩展元数据文件,对应扫描查询分布式文件系统中的扩展元数据文件内的数据,从而确定符合查询信息的数据,形成第一查询结果。本申请实施例通过在分布式文件系统中新建扩展元数据,可以实现包括第一字段的查询信息的快速查询提高了查询效率。
本申请实施例在查询信息不包括第一字段时,在原有的元数据库内确定查询信息对应的分区目录信息,从而可以从分布式文件系统中查找分区目录信息对应的分区下的所有数据,从而也可以在查询信息不包括第一字段时,通过元数据库查询,也可以从分布式文件系统中得到符合查询信息的数据的第二查询结果。
可选地,查询信息可以是Hive SQL语句,将Hive SQL转换成具体的执行任务的过程要经历阶段和每一阶段的输出。
可选地,查询信息转换成具体的执行任务的过程,参见图7所示,一条Hive SQL语句首先需要经过第1步语法和词法解析生成抽象语法树AST;经过第2步语义解析会生成查询块Query Block;在第3步生成逻辑执行计划中,需要遍历查询块(Query Block),执行操作树,操作树包括以下至少一种:TableScanOperator、SelectOperator、FilterOperator、JoinOperator、GroupByOperator、ReduceSinkOperator;在第4步逻辑执行计划OP tree优化中,会进行投影修剪、谓词下推、将相连的挑选(Select)和过滤(Filter)操作合并为单个操作树节点、减少不必要操作;在第5步生成物理执行计划中,会将优化的逻辑计划操作树转化为具体的执行引擎对应的任务;在第6步,经过物理执行计划(Task tree)的优化,如删除不必要的ReduceSinkOperator,减少用户提交作业数量等操作,生成优化的物理计划(Task tree)并提交执行。
本申请实施例提供一种电子设备,包括存储器、处理器及存储在存储器上的计算机程序,处理器执行计算机程序以实现本申请任一实施例的数据处理方法的步骤。
在一个可选实施例中提供了一种电子设备,如图8所示,图8所示的电子设备4000包括:处理器4001和存储器4003。其中,处理器4001和存储器4003相连,如通过总线4002相连。可选地,电子设备4000还可以包括收发器4004,收发器4004可以用于该电子设备与其他电子设备之间的数据交互,如数据的发送和/或数据的接收等。需要说明的是,实际应用中收发器4004不限于一个,该电子设备4000的结构并不构成对本申请实施例的限定。
处理器4001可以是CPU(Central Processing Unit,中央处理器),通用处理器,DSP(Digital Signal Processor,数据信号处理器),ASIC(Application SpecificIntegrated Circuit,专用集成电路),FPGA(Field Programmable Gate Array,现场可编程门阵列)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框,模块和电路。处理器4001也可以是实现计算功能的组合,例如包含一个或多个微处理器组合,DSP和微处理器的组合等。
总线4002可包括一通路,在上述组件之间传送信息。总线4002可以是PCI(Peripheral Component Interconnect,外设部件互连标准)总线或EISA(ExtendedIndustry Standard Architecture,扩展工业标准结构)总线等。总线4002可以分为地址总线、数据总线、控制总线等。为便于表示,图8中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
存储器4003可以是ROM(Read Only Memory,只读存储器)或可存储静态信息和指令的其他类型的静态存储设备,RAM(Random Access Memory,随机存取存储器)或者可存储信息和指令的其他类型的动态存储设备,也可以是EEPROM(Electrically ErasableProgrammable Read Only Memory,电可擦可编程只读存储器)、CD-ROM(Compact DiscRead Only Memory,只读光盘)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质、其他磁存储设备、或者能够用于携带或存储计算机程序并能够由计算机读取的任何其他介质,在此不做限定。
存储器4003用于存储执行本申请实施例的计算机程序,并由处理器4001来控制执行。处理器4001用于执行存储器4003中存储的计算机程序,以实现前述方法实施例所示的步骤。
本申请实施例提供一种计算机可读存储介质,其上存储有计算机程序,计算机程序被处理器执行时实现本申请任一实施例的数据处理方法的步骤。
需要说明的是,本申请的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。
应该理解的是,虽然本申请实施例的流程图中通过箭头指示各个操作步骤,但是这些步骤的实施顺序并不受限于箭头所指示的顺序。除非本文中有明确的说明,否则在本申请实施例的一些实施场景中,各流程图中的实施步骤可以按照需求以其他的顺序执行。此外,各流程图中的部分或全部步骤基于实际的实施场景,可以包括多个子步骤或者多个阶段。这些子步骤或者阶段中的部分或全部可以在同一时刻被执行,这些子步骤或者阶段中的每一子步骤或者阶段也可以分别在不同的时刻被执行。在执行时刻不同的场景下,这些子步骤或者阶段的执行顺序可以根据需求灵活配置,本申请实施例对此不限制。
以上所述仅是本申请部分实施场景的可选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本申请的方案技术构思的前提下,采用基于本申请技术思想的其他类似实施手段,同样属于本申请实施例的保护范畴。
Claims (13)
1.一种数据处理方法,其特征在于,包括:
获取分布式文件系统的至少一个待处理数据,确定每一所述待处理数据的第一字段所在的数值范围;
将所述数值范围划分为至少两个子数值范围;
基于所述至少两个子数值范围,将所述待处理数据划分为至少两个扩展元数据文件;
基于每一所述扩展元数据文件的数据属性,新建扩展元数据;所述数据属性包括每一所述扩展元数据文件所在的子数值范围,所述扩展元数据存储在所述分布式文件系统中。
2.根据权利要求1所述的数据处理方法,其特征在于,所述获取分布式文件系统的至少一个待处理数据,包括:
获取所述分布式文件系统的版本信息;
基于所述版本信息,确定所述分布式文件系统的根目录;
确定所述根目录中需要进行数据处理的至少一个分区目录;
将每一所述分区目录对应的数据,作为所述待处理数据。
3.根据权利要求2所述的数据处理方法,其特征在于,所述将所述数值范围划分为至少两个子数值范围,包括:
确定所述根目录中需要进行数据处理的相关数据数量;所述相关数据数量包括以下至少一项:分区目录总数、文件总数;
基于所述相关数据数量,确定分区因子;所述分区因子用于确定每一所述子数值范围;
基于所述分区因子,将所述数值范围划分为至少两个子数值范围。
4.根据权利要求2所述的数据处理方法,其特征在于,所述基于每一所述扩展元数据文件的数据属性,新建扩展元数据之后,包括:
基于每一所述扩展元数据文件,建立一个分区子目录;所述分区子目录为所述分区目录的下一级目录或同级目录,所述扩展元数据文件存储在所述分布式文件系统中;
将每一所述扩展元数据文件与所述分区子目录的对应关系,和/或每一所述扩展元数据文件所在的子数值范围与所述分区子目录对应关系,保存到所述扩展元数据。
5.一种数据处理方法,其特征在于,包括:
获取查询信息,从所述查询信息中提取第一字段;
从扩展元数据中,确定所述第一字段的字段信息所在的至少一个扩展元数据文件,将所述至少一个扩展元数据文件的数据作为待查询数据;所述扩展元数据基于如权利要求1-4中任一项所述的数据处理方法生成,所述字段信息包括数值或数值范围;
基于所述字段信息,从所述待查询数据中,确定符合所述查询信息的数据。
6.根据权利要求5所述的数据处理方法,其特征在于,所述基于所述字段信息,从所述待查询数据中,确定符合所述查询信息的数据,包括:
基于所述字段信息,从所述待查询数据中,确定符合所述字段信息的候选数据;
从所述候选数据中,确定符合所述查询信息中的除所述字段信息外的其他信息的数据,作为确定符合所述查询信息的数据。
7.根据权利要求5所述的数据处理方法,其特征在于,所述从扩展元数据中,确定所述第一字段的字段信息所在的至少一个扩展元数据文件,包括:
从扩展元数据中,确定所述第一字段的字段信息对应的至少一个子数值范围;
基于所述扩展元数据内的子数值范围与分区子目录对应关系,确定与所述至少一个子数值范围对应的至少一个所述分区子目录;
确定每一所述分区子目录对应的一个扩展元数据文件。
8.一种数据处理装置,其特征在于,包括:
获取模块,用于获取分布式文件系统的至少一个待处理数据,确定每一所述待处理数据的第一字段所在的数值范围;
第一划分模块,用于将所述数值范围划分为至少两个子数值范围;
第二划分模块,用于基于所述至少两个子数值范围,将所述待处理数据划分为至少两个扩展元数据文件;
新建模块,用于基于每一所述扩展元数据文件的数据属性,新建扩展元数据;所述数据属性包括每一所述扩展元数据文件所在的子数值范围,所述扩展元数据存储在所述分布式文件系统中。
9.一种数据处理装置,其特征在于,包括:
查询模块,用于获取查询信息,从所述查询信息中提取第一字段;
第一确定模块,用于从扩展元数据中,确定所述第一字段的字段信息所在的至少一个扩展元数据文件,将所述至少一个扩展元数据文件的数据作为待查询数据;所述扩展元数据基于如权利要求1-4中任一项所述的数据处理方法生成,所述字段信息包括数值或数值范围;
第二确定模块,用于基于所述字段信息,从所述待查询数据中,确定符合所述查询信息的数据。
10.一种电子设备,其特征在于,包括存储器、处理器及存储在存储器上的计算机程序,其特征在于,所述处理器执行所述计算机程序以实现权利要求1-4或5-7中任一项所述数据处理方法的步骤。
11.一种数据处理系统,其特征在于,包括:驱动单元、编译单元、执行单元和分布式文件系统;
所述分布式文件系统内存储的扩展元数据基于如权利要求1-4中任一项所述的数据处理方法生成;
所述编译单元,与所述驱动单元电连接,用于接收所述驱动单元发送的查询信息,从所述查询信息中提取第一字段,从所述扩展元数据中确定第一信息,基于所述第一信息和所述查询信息生成第一执行信息并向所述驱动单元发送;所述第一信息包括所述第一字段的字段信息所在的至少一个扩展元数据文件的信息;
所述执行单元,与所述驱动单元电连接,用于接收所述驱动单元发送的所述第一执行信息,并基于所述第一执行信息从分布式文件系统中获取符合查询信息的数据,形成第一查询结果,将所述第一查询结果向所述驱动单元发送。
12.根据权利要求11所述的数据处理系统,其特征在于,还包括:元数据库;
所述编译单元,还用于在从所述查询信息中未提取到第一字段时,从所述元数据库中确定第二信息,基于所述第二信息和所述查询信息生成第二执行信息并向所述驱动单元发送;所述第二信息包括所述查询信息对应的分区目录的信息;
所述执行单元,还用于接收所述驱动单元发送的第二执行信息,并基于所述第二执行信息从分布式文件系统中获取符合查询信息的数据,形成第二查询结果,将所述第二查询结果向所述驱动单元发送。
13.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现权利要求1-4或5-7中任一项所述数据处理方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210388087.9A CN115033547A (zh) | 2022-04-13 | 2022-04-13 | 数据处理方法、装置、电子设备及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210388087.9A CN115033547A (zh) | 2022-04-13 | 2022-04-13 | 数据处理方法、装置、电子设备及系统 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN115033547A true CN115033547A (zh) | 2022-09-09 |
Family
ID=83119775
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210388087.9A Pending CN115033547A (zh) | 2022-04-13 | 2022-04-13 | 数据处理方法、装置、电子设备及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115033547A (zh) |
-
2022
- 2022-04-13 CN CN202210388087.9A patent/CN115033547A/zh active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN107247808B (zh) | 一种分布式NewSQL数据库系统及图片数据查询方法 | |
CN109299102B (zh) | 一种基于Elastcisearch的HBase二级索引系统及方法 | |
Xie et al. | Simba: Efficient in-memory spatial analytics | |
US8396852B2 (en) | Evaluating execution plan changes after a wakeup threshold time | |
CN101196890B (zh) | 聚合数据库运行时信息和分析应用性能的方法及装置 | |
US8924373B2 (en) | Query plans with parameter markers in place of object identifiers | |
CN104620239A (zh) | 自适应查询优化 | |
JP6471262B2 (ja) | データ処理システム | |
CN105630881A (zh) | 一种rdf的数据存储方法和查询方法 | |
CN105989015B (zh) | 一种数据库扩容方法和装置以及访问数据库的方法和装置 | |
CN111078705A (zh) | 基于Spark平台建立数据索引方法及数据查询方法 | |
Song et al. | Haery: a Hadoop based query system on accumulative and high-dimensional data model for big data | |
CN113918605A (zh) | 数据查询方法、装置、设备以及计算机存储介质 | |
CN111125216B (zh) | 数据导入Phoenix的方法及装置 | |
CN110990423B (zh) | Sql语句的执行方法、装置、设备和存储介质 | |
CN115391424A (zh) | 数据库查询的处理方法、存储介质与计算机设备 | |
CN115374121A (zh) | 数据库索引的生成方法、机器可读存储介质与计算机设备 | |
CN115391346A (zh) | 数据库聚合索引的生成方法、存储介质与计算机设备 | |
CN115033547A (zh) | 数据处理方法、装置、电子设备及系统 | |
CN115952323A (zh) | 对大规模超图的查询方法及系统 | |
CN112835932B (zh) | 业务表的批量处理方法及装置、非易失性存储介质 | |
US10762084B2 (en) | Distribute execution of user-defined function | |
JP2004192657A (ja) | 情報検索システム、情報検索方法および情報検索用プログラムを記録した記録媒体 | |
CN112182028B (zh) | 基于分布式数据库的表的数据行数查询方法和装置 | |
CN113946580B (zh) | 一种海量异构日志数据检索中间件 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |