CN111078705A - 基于Spark平台建立数据索引方法及数据查询方法 - Google Patents
基于Spark平台建立数据索引方法及数据查询方法 Download PDFInfo
- Publication number
- CN111078705A CN111078705A CN201911324622.9A CN201911324622A CN111078705A CN 111078705 A CN111078705 A CN 111078705A CN 201911324622 A CN201911324622 A CN 201911324622A CN 111078705 A CN111078705 A CN 111078705A
- Authority
- CN
- China
- Prior art keywords
- data
- index
- file
- memory
- value
- 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/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/2228—Indexing structures
-
- 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
-
- 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/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
- G06F16/2471—Distributed queries
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Computational Linguistics (AREA)
- Software Systems (AREA)
- Probability & Statistics with Applications (AREA)
- Mathematical Physics (AREA)
- Fuzzy Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明提供一种基于Spark平台建立数据索引方法,包括,为数据表创建内存索引,该内存索引对应的索引表包括两个字段,两个字段分别表示索引字段,以及该索引字段对应的数据文件清单;扫描数据表下的所有数据文件,针对索引字段的每个值搜寻索引字段值出现在哪些数据文件中,将所有的<索引字段值,数据文件清单>键值对写入索引表中。本发明在生成内存索引数据时不再索引到文件的偏移量,仅仅索引到文件,索引表数据大大缩小,无需再分配额外的job去分布式并行处理,极大的提升查询性能。
Description
技术领域
本发明涉及一种在数据处理***上建立索引的方法,尤其涉及一种基于Spark平台建立数据索引方法以及数据查询方法。
背景技术
随着近20多年来计算技术的不断革新,企业积累了大量数据。数字传感器的进步使得通信***越来越广泛的使用,尤其是移动平台和移动终端的飞速增长;***运行产生的大量日志以及越来越多的企业采用无纸化办公的工作方式,这些情况都使得企业积攒了海量数据资源,数据规模已经增长到了传统软件无法承载的地步,并且随着人们对现代科技越来越多的依赖,数据将会以更快的速度增长下去。
在分析海量数据的场景下,单台服务器的处理能力已不能满足要求,于是企业就用多台计算机来并行处理这些海量数据,即采用分布式计算架构,典型的代表软件是hadoop、spark等。更准确的说,spark只是一个并行计算框架,而hadoop中包含计算框架MapReduce和分布式文件***HDFS;Hadoop更广泛地说还包括在其生态***上的其他***,如Hbase、Hive等;而Spark生态***已经发展成为一个包含多个子项目的集合,其中包含Spark SQL、Spark Streaming、GraphX、MLlib等子项目,Spark是MapReduce的替代方案,性能提升近百倍,Spark SQL是Spark之上提供结构化数据SQL查询与分析的查询引擎,是MapReduce之上的Hive的替代方案。
Apache Spark是一种快速、通用、可扩展的大数据分析引擎。它是不断壮大的大数据分析解决方案家族中备受关注的明星成员,为分布式数据集的处理提供了一个有效框架,并以高效的方式处理分布式数据集。Spark集批处理、实时流处理、交互式查询与图计算于一体,避免了多种运算场景下需要部署不同集群带来的资源浪费。
Spark大数据处理平台在对数据进行分析计算前,首先要将数据文件从磁盘载入内存,而由于目前Spark大数据处理平台不支持对数据文件创建索引并使用索引快速定位要扫描的数据文件清单或者数据文件的一部分,因此,每次计算时都要载入全部的数据文件到内存,造成了大量磁盘IO;而绝大多数情况下,用户对大量数据进行查询时都要指定筛选条件,以便得到自己关心的较少量的查询结果,因此不包含筛选内容的数据文件或数据块无需载入内存扫描。
发明内容
本发明的目的在于提供一种基于Spark平台建立数据索引方法,在生成内存索引数据时不再索引到文件的偏移量,仅仅索引到文件,索引表数据大大缩小,无需再分配额外的job去分布式并行处理,极大的提升查询性能。
本发明提供的基于Spark平台建立数据索引方法,包括:(1)为数据表创建内存索引,该内存索引对应的索引表包括两个字段,两个字段分别表示索引字段,以及该索引字段对应的数据文件清单;(2)扫描数据表下的所有数据文件,针对索引字段的每个值搜寻索引字段值出现在哪些数据文件中,将所有的<索引字段值,数据文件清单>键值对写入索引表中。
为方便快捷地数据查询,所述步骤(2)中,按照索引字段值的升序或降序将键值对写入索引表中。
本发明重新设计SparkSQL中的内存索引创建机制,生成的索引表只有索引字段的值、文件清单两列,索引表按照索引字段的值升序或降序排序,索引表数据相对于现有技术缩小了许多。
本发明还提供一种基于Spark平台建立数据索引方法,建立存储索引,极大地提升查询性能,包括:(1)创建数据表时,设定两个表属性,分别为create.store.index、row.index.rows,分别表示是否创建存储索引、行索引行数;(2)向数据表中导入数据时,先判断是否需要创建存储索引,即,表属性create.store.index是否开启,若开启,则统计需要导入的数据的总行数,按照表属性row.index.rows设置的行索引行数对数据行进行分组;针对每个行组分别计算行组数据的起始地址以及各个列的最大值、最小值、平均值、行个数;将计算得到的每个行组的统计信息写在文件头部,一个行组对应一行统计信息,作为行索引;(3)统计整个文件的数据起始地址以及各个列的最大值、最小值、平均值、行个数,然后将这些统计信息写入文件末尾,单独作为一行,作为文件索引。
本发明还提供一种基于Spark平台的数据查询方法,利用内存索引进行查询,内存索引数据时不再索引到文件的偏移量,仅仅索引到文件,索引表数据大大缩小,无需再分配额外的job去分布式并行处理,极大的提升查询性能,包括:判断数据表是否包含内存索引,如果不包含内存索引,则针对所有数据文件生成计算job;如果包含内存索引并且查询语句要对索引字段值进行筛选,则读取索引表,根据索引字段值从索引表中获取到数据文件清单,为数据文件清单的每个数据文件生成只扫描该数据文件的计算job。
优选地,索引表中的索引字段值以及数据文件清单是按照索引字段值的升序或降序存储的,使用二分法在索引表中查找索引字段值对应的的数据文件清单。
优选地,如果包含内存索引,但查询语句不是要对索引字段值进行筛选,则针对所有数据文件分别生成计算job。
优选地,在执行计算job过程中,(1)判断是查询语句否包含谓词,如果包含谓词,则对谓词进行解析,获得想要查询的数据;(2)读取数据文件的末尾,判断是否有存储索引;(3)如果有存储索引,则读取索引数据并判断索引的范围是否可能包含所述想要查询的数据,如果可能包含,则加载相应数据到内存中;如果数据文件不可能存在所述想要查询的数据,则返回空数据。
优选地,所述步骤(3)具体为,获取文件索引,将所述想要查询的数据是否落入文件索引记载的最大值、最小值之间,如果位于两者之间则索引的范围可能包含所述想要查询的数据;逐条读取行索引,获取要扫描的行组,根据行索引中的行组数据的起始地址读取行组数据,对数据进行解析后加载至内存。
本发明还提供一种基于Spark平台的数据查询方法,通过存储索引查询数据,极大地提升查询性能,包括:(1)判断是查询语句否包含谓词,如果包含谓词,则对谓词进行解析,获得想要查询的数据;(2)读取数据文件的末尾,判断是否有存储索引;(3)如果有存储索引,则读取索引数据并判断索引的范围是否可能包含所述想要查询的数据,如果可能包含,则加载相应数据到内存中;如果数据文件不可能存在所述想要查询的数据,则返回空数据。
优选地,所述步骤(3)具体为,获取文件索引,将所述想要查询的数据是否落入文件索引记载的最大值、最小值之间,如果位于两者之间则索引的范围可能包含所述想要查询的数据;逐条读取行索引,获取要扫描的行组,根据行索引中的行组数据的起始地址读取行组数据,对数据进行解析后加载至内存。
本发明重新设计SparkSQL中的内存索引创建机制,生成的索引表只有索引字段的值、文件清单两列,索引数据缩小许多,在扫描数据表前,先检索内存索引得到要扫描的文件清单,然后针对这些文件清单生成相对应的计算任务,每个计算任务负责各自的文件扫描,从而避免原先的针对每个数据文件都生成计算任务造成很多任务做无用功。
附图说明
图1为ORC文件结构图;
图2为Parquet、JSON、Avro文件结构图;
图3为Spark文件读写编程接口层次图;
图4为SparkSQL提交job架构图;
图5为Spark创建内存索引编程接口层次图;
图6为job执行流程图;
图7为Spark应用数据索引整体流程图;
图8为用户应用程序访问Spark接口模型图;
图9为SparkSQL优化器生成job过程中获取数据文件清单流程图;
图10为Spark应用程序使用内存索引流程图;
图11为Parquet、JSON、Avro文件读取流程图。
具体实施方式
本发明是在Spark技术实现的基础之上给出如前所述技术缺陷的改进方案,因此以下将详细描述Spark目前所采用的技术方案。
Spark大数据处理平台所处理的数据按照格式分类可以分为:结构化数据、半结构化数据和非结构化数据。针对半结构化数据和非结构化数据,由Spark平台自身或其上的Spark Streaming、GraphX、MLlib等模块进行处理;针对结构化数据,主要是由Spark平台之上的SparkSQL模块来处理。对于半结构化数据和非结构化数据,Spark大数据平台并不提供任何索引支持,而对于结构化数据,Spark支持创建性能低下的内存索引以及仅支持对ORC格式数据文件创建存储索引,但无论是内存索引还是存储索引,都只是支持创建,却并不支持使用这些索引。鉴于Spark大数据处理平台仅对结构化数据支持有限的索引,因此以下只详细描述Spark大数据处理平台针对结构化数据创建内存索引和存储索引的技术方案。
1)针对结构化数据创建内存索引
对结构化数据创建内存索引的功能是由SparkSQL模块提供的,SparkSQL模块是Spark平台上使用类SQL引擎对结构化进行查询的模块,包含类SQL语言词法解析器、语法解析器、编译器、优化器等,并最终将类SQL语句转化为Spark平台计算框架能够执行的作业提交执行。相应地,对结构化数据创建索引时,也是使用类似SQL语言的语句来进行,如下所示:
以上简单的类SQL指令在数据表base_table_name上基于列col_name创建了一个内存索引,名称叫index_name,并指定了存储索引数据的表名index_table_name。索引表里面的字段包括:索引列的值、该值对应的数据文件路径、该值所在行的行首在文件中的偏移量。至于索引表的数据稍后通过重建索引的命令生成。由于索引表存储了索引列所有可能取值的所有文件路径及在文件中的偏移量,因此当对数据表进行查询时,若对索引字段指定了筛选条件,又判断该表存在索引,那么就可以直接读取相应的索引表数据,从索引表中得知被筛选的记录分布在哪些数据文件以及这些文件的哪些位置,从而只载入这些文件到内存进行扫描。为了描述清楚,以下简单举例如下:
假如有以下数据表test:
表1数据表字段表
字段名称 | 字段类型 |
value | string |
key | string |
通过以下命令创建索引:
create index test_index on table test(key)
as'org.apache.hadoop.hive.ql.index.compact.CompactIndexHandler'
with deferred rebuild
IN TABLE test_index_table;
执行以上创建索引语句后,将自动创建如下新表,也称作test表的索引表:
表2索引表字段表
字段名称 | 字段类型 |
key | string |
_bucketname | string |
_offsets | array[bigint] |
其中,索引表中key字段,就是原表中key字段的值,_bucketname字段,代表数据文件对应的文件路径,_offsets代表该key值所在行的行首在文件中的偏移量,由于同个文件中可能有相同key值的多个记录行,因此,该字段类型为数组。
其实,索引表就相当于一个在原表索引列上的一个汇总表。需要注意的是,这种汇总是以文件为单位的,每个文件单独汇总,因为偏移量是以当前文件为基准的。
创建了索引后,下一步是重建索引,重建索引即是扫描整个数据表的所有数据文件,计算索引字段所有的取值分别位于哪些文件及文件的什么位置,然后将所有这些信息写入索引表中,供查询时使用。虽然重建索引本身仍要扫描所有数据文件,并且可能要花较多时间,但索引数据一旦生成后,将来的查询将会受益。
为了表述清楚,接着创建索引的例子继续举例如下:
假设test表对应的数据文件内容为:
以上数据文件经SparkSQL模块解析为以下表数据:
表3数据表数据范例表
执行重建索引命令后,则索引表数据为:
表4索引表数据范例表
key | _bucketname | _offsets |
10 | hdfs://dn1:9000/user/hive/warehouse/test/test.data | [35,0] |
11 | hdfs://dn1:9000/user/hive/warehouse/test/test.data | [5,26] |
12 | hdfs://dn1:9000/user/hive/warehouse/test/test.data | [11,18] |
Spark大数据处理平台只支持创建内存索引,并不支持查询时使用该索引。因为如果要使用索引,通常的做法如下:
首先额外生成一个job,根据对索引列的过滤条件,从索引表中过滤出索引列的值对应的文件路径及偏移量,输出到磁盘上的一个临时文件中,然后生成正式的查询job,该查询job根据这个临时文件中的数据文件路径和偏移量,筛选原始input文件,只将匹配的数据文件或文件的数据块载入内存。
如果采用以上实现方式,虽然数据文件的磁盘IO减少了,但额外多了一个job来扫描索引表,由于索引表的数据通常情况下也比较大,并且涉及到两次作业的调度,因此大多数情况下,性能反而不如不使用索引,可能因为这个原因,Spark放弃了对索引的使用。
2)针对结构化数据创建存储索引
结构化数据主流的文件格式有Parquet、ORC、JSON、Avro等,目前Spark大数据处理平台只支持对ORC数据格式文件创建存储索引,因此以下详述对ORC存储索引的支持。
图1是ORC文件的结构图。由图可知,ORC文件由文件头File Footer、Postscript和多个Stripe组成,每个Stripe又由Stripe头Stripe Footer和实际数据、行组索引组成。实际数据按行数分成多个组,每个组称作行组,例如每10000行数据记录组成一个行组,如果某个Stripe中有10万行记录,那么它就包含10个行组,每个行组可以单独建立一条索引记录,称作行索引,行索引统计了对应的行组中各个列的最小值、最大值、平均值、行数等。
除了行索引,在ORC文件的File Footer中也可以包含一条存储索引记录,称作文件索引,文件索引统计了当前整个文件的所有数据的所有列的最小值、最大值、平均值、行数等。
另外在每个Stripe中也可以包含一条存储索引记录,称作Stripe索引,Stripe索引统计了当前Stripe中数据的所有列的最小值、最大值、平均值、行数等。
综上所述,ORC文件提供了三个层级的存储索引,分别是文件索引、Stripe索引、行索引。所有三种层级格式一致,只不过统计的范围不同,索引粒度不同,文件索引对整个文件进行统计,粒度最大。由于存储索引统计了各个列的最大值、最小值等,当查询语句对某些列指定了筛选值时,可迅速根据存储索引判断筛选值是否落入最小值与最大值之间,若落入,则说明有可能包含筛选的数据,需要扫描数据;若不落入,则说明不可能包含筛选的数据,就没有必要再扫描数据了,而且存储索引只是记录统计信息,数据量小,即使最坏的情况下也不会给查询造成额外的比较大的性能损失。
尽管存储提供了轻量级的索引机制,且Spark大数据平台在生成ORC数据文件时支持在文件中写入存储索引,但Spark大数据处理平台的文件读取器却并不支持对ORC文件中的索引进行解析,也因此查询时并不会使用这些存储索引。
以下对本发明采用的技术方案进行详细描述。
1)使用SparkSQL创建Parquet、JSON、Avro数据文件时(Parquet、JSON、Avro文件结构如图2所示),按照设置的行数对数据行进行分组,并为每一个行组生成一条存储索引记录,最后生成文件索引记录,具体如下:
1.创建数据表时,添加对“是否创建存储索引”和“行索引行数”两个表属性的支持;
2.向数据表导入数据时,修改SparkSQL创建数据文件的处理逻辑,首先根据数据表的属性判断是否要创建存储索引,若要,则根据设置的行索引行数生成索引记录并计算记录中各项统计值,最后生成文件索引,索引包括的值有:数据起始位置在文件中的偏移量,所有列的最小值、最大值、平均值、行数。
2)使用Spark大数据处理平台的编程接口开发应用时,允许从Spark编程接口类继承自己的接口类,并在自己的接口类中重写数据文件读写函数,具体如下:
1.将Spark编程接口类SparkContext中的文件读写函数定义为虚函数,即可被子类重写;
2.如图3所示,用户如果要在半结构化或非结构化数据文件中创建自定义的存储索引,只需从编程接口SparkContext类继承一个自己的类,并且只需重写文件读、写函数即可;使用这种设计还有一个好处,可以将文件的读写操作封装在一起,方便配套使用,因为如果向文件中写入了自定义的存储索引并重新设计了文件结构,那么也必须实现相应的文件读取器,以便能识别并解析这种文件结构及其中的存储索引;
3.当用户实例化SparkContext时,只须实例化一个从其继承的一个接口类的对象,使用的接口仍然是SparkContext,其它所有操作无需改动,这其中也包括文件读写操作,只是应用实际运行时执行的文件读写操作是自己实现的版本。
3)重用SparkSQL中目前已支持的创建内存索引和重建内存索引的SQL语句,但修改重建内存索引的执行逻辑,并且增加对索引的检索功能,具体如下:
1.生成索引数据时,不再索引到文件中的偏移量,而仅仅索引到文件即可,即索引表删除_offsets字段,同时将_bucketname字段的类型string修改为array[string],即同一个索引字段值在多个数据文件中出现时,将所有这些数据文件列在一个清单中。新的索引表字段如下:
表5新索引表的字段表
字段名 | 字段类型 |
被索引的字段名 | 被索引的字段的类型 |
_bucketname | Array[string] |
2.索引数据生成完后,按照索引字段值进行从小到大排序,此时对于索引字段的每个值仅有一行记录,因此可以应用二分法查找等算法快速定位到这一行,继而迅速获知当前索引字段的值出现在哪些文件中;
3.如图4所示,修改SparkSQL模块中的SQL优化器,在生成计算job前,首先判断数据表是否包含内存索引,若不包含内存索引,直接针对所有数据文件生成计算job,若包含内存索引并且查询语句要对索引字段值进行筛选,则读取索引表,使用二分法查找检索到相应索引字段值,继而获取到要扫描的文件清单,然后生成只扫描清单中文件的job,不在清单中的数据文件不会被生成的job处理。由于此时的索引表数据相对之前缩小了许多,并且索引字段的每个值只会出现一行,方便使用快速查找算法,因此无需再分配额外的job去分布式并行处理,增加不必要的多次job调度,因此查询性能可极大的提升。
4)使用Spark大数据处理平台的编程接口开发应用时,允许从Spark编程接口类继承自己的接口类,并在自己的接口类中添加创建内存索引和检索内存索引两个功能函数,具体如下:
1.在Spark编程接口类SparkContext中添加创建内存索引和检索内存索引两个虚函数,以便从其继承的子类可以重写;
2.如图5所示,用户如果要在处理半结构化或非结构化数据时使用自定义的内存索引,只需从编程接口SparkContext类继承一个自己的类,然后重写创建内存索引和检索内存索引的具体实现;其中创建内存索引是在内存中创建一个数据结构,可以是树、堆、HASH表、映射等,应用程序可以根据需要创建多个这样的数据结构,在需要检索内存索引时,应用这些数据结构的检索算法即可,通过检索内存索引,可以获取要操作的数据文件列表,之后再读取这些文件并进行相关计算。
3.当用户实例化SparkContext时,只须实例化一个从其继承的一个接口类的对象,使用的接口仍然是SparkContext,其它所有操作无需改动,相对于以前的处理逻辑,只是在对数据计算前额外创建一个内存索引,之后每当要扫描数据文件时可通过先检索内存索引得到要扫描的文件清单,而不是直接扫描所有数据文件。
5)针对Parquet、ORC、JSON、Avro分别添加对应的文件读取器,替换原来的默认统一使用Hive的扫描表的方式,这些文件读取器除了拥有Hive扫描表的基本功能,还需要添加如下两项功能:
1.能够解析SparkSQL下推给文件读取器的谓词,这里的谓词即是SQL查询语句里面的where子句,亦即是对字段的筛选条件。如图6所示,当在SparkSQL模块中打开了下推谓词后,该谓词会在SQL语句解析、编译、优化并最终生成的执行job中以一定的格式传递给该Job中读取数据文件的接口,也就是可以传递给文件读取器,但需要文件读取器解析并处理;
2.加载数据文件到内存前,先读取数据文件的末尾,判断是否有存储索引,以及是否有多级存储索引,若有,则读取索引数据并判断索引的范围是否可能包含想要查询的数据,若可能,则根据数据起始位置的偏移量加载相应的数据到内存中,无需加载的数据则直接跳过,若整个文件经判断不可能存在想要筛选的数据,则文件读取器向上层返回空数据。
综上,分别创建了数据的内存索引和存储索引后,就可以在以后的查询中反复使用内存索引或存储索引,当然也可以同时使用内存索引和存储索引,即所谓的二级索引机制,通过使用二级索引,既可以大幅裁剪计算任务数以及任务调度带来的时间开销,又能以分布式并行的方式大幅缩减数据文件的磁盘IO,使用二级索引的整体流程图如图7所示,即,先应用内存索引获得数据文件,再针对每个数据文件应用存储索引获得所需的数据。
以下结合具体实例对本发明的技术方案进行进一步描述。
(1)本发明对于在SparkSQL中生成Parquet、JSON、Avro文件时支持创建存储索引的具体实现:
1)创建Parquet、JSON、Avro数据表时,允许指定两个表属性:create.store.index、row.index.rows,其中create.store.index指示是否要在生成表数据时创建存储索引;row.index.rows指示创建行索引时的间隔行数(即行索引行数);
2)创建数据表后,当向数据表中导入数据时,数据将以相应格式的文件的形式存储,在创建Parquet、JSON、Avro格式文件前,先判断数据表属性create.store.index是否开启,若未开启,执行Spark原有的处理逻辑;若开启,则统计数据的总行数,按照表属性row.index.rows设置的行间隔对数据行进行分组,然后针对每个行组分别计算行组数据的起始地址以及各个列的最大值、最小值、平均值、行个数,接着将每个行组的统计信息写在文件头部,一个行组对应一行统计条目,所有这些条目组成了行索引,行索引数据格式如下表所示:
表6 Parquet、JSON、Avro行索引数据格式表
3)行索引写入完成后,接着写入实际的数据,最后统计整个文件的数据起始地址以及各个列的最大值、最小值、平均值、行个数,然后将这些统计信息写入文件末尾,单独作为一行,称作文件索引,文件索引的数据格式如下表所示:
表7 Parquet、JSON、Avro文件索引数据格式表
对于ORC文件,同样可以使用以上方案建立存储索引。
(2)本发明对于在Spark应用开发中支持自定义文件读写操作的具体实现:
将Spark编程接口SparkContext中所有的文件读写函数设置为虚函数,以便可以被派生的接口改写;用户基于Spark开发新的应用程序或改写现有的应用程序时,步骤如下:
1)从SparkContext继承一个自定义接口类,针对SparkContext中的虚函数根据需要选择其中一些进行重写;
2)创建一个SparkContext接口引用和一个自定义接口类的对象,并将创建的对象实例化给SparkContext接口引用;
3)使用SparkContext接口引用调用SparkContext中的所有接口函数,包括虚函数,其中虚函数的调用将实际调用自定义接口类中的实现版本,图8是用户程序访问SparkContext编程接口的模型图。
(3)本发明对于在SparkSQL中支持创建内存索引和检索内存索引的具体实现:
1)通过CREATE INDEX命令可以为数据表创建一个内存索引,该命令标记数据表拥有内存索引以及索引字段是什么,且根据命令的参数创建一个索引表,并将该索引表链接到数据表,以便能通过数据表访问到索引表;
2)通过REBUILD INDEX命令可以重建索引,该命令将扫描数据表下的所有数据文件,针对索引字段的每个值搜寻出现在哪些文件中,然后将所有<索引字段值,数据文件清单>键值对按照索引字段值升序或降序排序后写入对应的索引表中。
3)在JDBC/ODBC客户端输入SQL语句查询时,Spark大数据处理平台的SparkSQL模块对接收的SQL语句进行解析、编译、优化,最终生成执行job,在生成job的过程中,改写获取数据文件清单的执行逻辑,使之能应用内存索引快速定位到需要扫描的文件,图9是详细的获取数据文件清单的执行流程图,即,先判断是否包含内存索引,如果不包含,则返回数据表下所有的数据文件清单,如果包含,判断查询语句是否要对索引字段值进行筛选,如果不进行筛选,则返回数据表下所有的数据文件清单,如果进行筛选,则读取索引表,根据要筛选的索引字段值快速定位到索引项,获取索引项存储的数据文件清单。
(4)本发明对于在Spark应用开发中支持创建内存索引和检索内存索引的具体实现:
在Spark编程接口SparkContext中新增两个虚函数:createIndex、searchIndex,默认实现为空;用户基于Spark开发新的应用程序或改写现有的应用程序时,步骤如下:
1)从SparkContext继承一个自定义接口类(用户若既要使用存储索引又要使用内存索引,可以使用同一个自定义接口类),针对SparkContext中的虚函数createIndex、searchIndex进行重写;
2)创建一个SparkContext接口引用和一个自定义接口类的对象,并将创建的对象实例化给SparkContext接口引用;
3)使用SparkContext接口引用调用SparkContext中的createIndex、searchIndex来创建和使用内存索引,该调用将实际调用自定义接口类中的实现版本,图10是用户开发Spark应用程序并使用内存索引的一般流程图。
(5)本发明对于添加Parquet、ORC、JSON、Avro文件读取器的具体实现:
1)创建Parquet、ORC、JSON、Avro文件读取器类;
2)SparkSQL生成job时,在对数据文件进行加载解析时,修改处理逻辑,根据当前查询的数据表的数据格式类型调用相对应的文件读取器接口;
3)分别实现Parquet、ORC、JSON、Avro文件读取器的文件读取操作,首先能够判断并解析上层传递的谓词,然后对存储索引进行读取和解析,决定要加载的数据,接着对要加载的数据格式进行解析,解析完成后缓存到内存中,以供后续的计算处理,图11是Parquet、JSON、Avro文件读取器执行流程图,
即,(1)判断是查询语句否包含谓词,如果不包含谓词,则加载整个数据文件的数据,如果包含谓词,则对谓词进行解析,获得想要查询的数据;(2)读取数据文件的末尾,判断是否有存储索引,即,create.store.index开启;(3)如果没有存储索引,则加载整个数据文件的数据,如果有存储索引,则读取索引数据并判断索引的范围是否可能包含所述想要查询的数据,如果可能包含,则加载相应数据到内存中,具体来说,即,判读为有存储索引后,获取文件索引,将所述想要查询的数据是否落入文件索引记载的最大值、最小值之间,如果位于两者之间则索引的范围可能包含所述想要查询的数据;逐条读取行索引,获取要扫描的行组(将所述想要查询数据与行索引中记录的最大值、最小值比较,落入两者之间,则该行组的数据需要加载至内存),根据行索引中的行组数据的起始地址读取行组数据,对数据进行解析后加载至内存。如果数据文件不可能存在所述想要查询的数据,则返回空数据。
ORC文件读取器与之类似,只不过中间还要读取stripe中的索引,过程与读取文件索引相同,不再赘述。
本发明提供的数据索引方法及查询方法:
(1)结构化数据处理方面,使用SparkSQL模块处理主流格式的结构化数据文件(Parquet、ORC、JSON、Avro)时,除了支持在ORC文件中创建存储索引,也增加支持在Parquet、JSON、Avro文件中创建存储索引;其它格式数据处理方面,使用Spark应用程序编程接口开发应用程序时,提供接口可自定义实现任何数据文件的存储索引创建,用户想对半结构化、非结构化、自定义数据格式文件创建存储索引时可使用接口自主开发。
支持的ORC格式数据文件的存储索引可以在数据查询时正常使用,极大提升了ORC表的查询性能;新增支持在Parquet、JSON、Avro格式数据文件中创建存储索引,并可以在数据查询时正常使用它们,极大提升Parquet、JSON、Avro数据表的查询性能。添加ORC格式文件读取器,能够解析层传递给它们的SQL语句的谓词和ORC数据文件中的文件索引、Stripe索引、行索引,并根据这些存储索引决定哪些数据需要载入内存,哪些数据可以直接忽略。
在写Parquet、JSON、Avro格式文件的功能函数中新增支持写入文件索引和行索引,添加Parquet、JSON、Avro格式文件读取器,能够解析上层传递给它们的SQL语句的谓词和相对应的数据文件中的文件索引、行索引,并根据这些存储索引决定哪些数据需要载入内存,哪些数据可以直接忽略。
(2)结构化数据处理方面,在SparkSQL中支持创建新型的内存索引并在查询时能够使用该索引提升性能;其它格式数据处理方面,使用Spark应用程序编程接口开发应用程序时,提供接口可自定义实现任何数据文件的内存索引创建,用户想对半结构化、非结构化、自定义数据格式文件创建内存索引时可使用接口自主开发。重新设计在SparkSQL模块中已经支持的针对结构化数据的内存索引,并基于这种新型的内存索引设计方案实现了在数据查询时可以高效快速地应用索引,达到了提升整体性能的目的。重新设计SparkSQL中的内存索引创建机制,生成的索引表只有索引字段的值、文件清单两列,索引表按照索引字段的值升序排序。
在SparkSQL模块的SQL优化器中添加对内存索引使用的支持,在扫描数据表前,先检索内存索引得到要扫描的文件清单,然后针对这些文件清单生成相对应的计算任务,每个计算任务负责各自的文件扫描,从而避免原先的针对每个数据文件都生成计算任务造成很多任务做无用功。
(3)结构化数据处理方面,ORC、Parquet、JSON、Avro数据文件的文件读取器支持对存储索引的解析,并按照存储索引决定是否加载当前文件或文件的一部分到内存中;其它格式数据处理方面,提供接口可实现自己的文件读取器,并在其中支持对相应文件的存储索引的解析;使用Spark应用程序编程接口开发应用程序时,提供接口可自定义实现对任何存储索引的解析。
(4)基于Spark大数据处理平台的编程接口开发应用程序时,允许用户从编程接口继承自己的类,并在该类中重写创建内存索引、检索内存索引功能函数,以及文件读写函数,并在文件读写函数中实现存储索引的创建的解析;Spark平台编程接口SparkContext添加两个虚函数:创建内存索引、检索内存索引,同时将所有的文件读写函数修改为虚函数,允许用户从SparkContext继承自己的类,并重写虚函数实现,允许用户继续使用SparkContext接口开发,但该接口的实例对象可以是自定义的类对象。
(5)通过同时使用内存索引和存储索引,可实现对数据建立二级索引,两者相结合,既可以大幅裁剪计算任务数以及任务调度带来的时间开销,又能以分布式并行的方式大幅缩减数据文件的磁盘IO。
Claims (10)
1.一种基于Spark平台建立数据索引方法,其特征在于:(1)为数据表创建内存索引,该内存索引对应的索引表包括两个字段,两个字段分别表示索引字段,以及该索引字段对应的数据文件清单;(2)扫描数据表下的所有数据文件,针对索引字段的每个值搜寻索引字段值出现在哪些数据文件中,将所有的<索引字段值,数据文件清单>键值对写入索引表中。
2.如权利要求1所述的基于Spark平台建立数据索引方法,其特征在于:所述步骤(2)中,按照索引字段值的升序或降序将键值对写入索引表中。
3.一种基于Spark平台建立数据索引方法,其特征在于:(1)创建数据表时,设定两个表属性,分别为create.store.index、row.index.rows,分别表示是否创建存储索引、行索引行数;(2)向数据表中导入数据时,先判断是否需要创建存储索引,即,表属性create.store.index是否开启,若开启,则统计需要导入的数据的总行数,按照表属性row.index.rows设置的行索引行数对数据行进行分组;针对每个行组分别计算行组数据的起始地址以及各个列的最大值、最小值、平均值、行个数;将计算得到的每个行组的统计信息写在文件头部,一个行组对应一行统计信息,作为行索引;(3)统计整个文件的数据起始地址以及各个列的最大值、最小值、平均值、行个数,然后将这些统计信息写入文件末尾,单独作为一行,作为文件索引。
4.一种基于Spark平台的数据查询方法,其特征在于:判断数据表是否包含内存索引,如果不包含内存索引,则针对所有数据文件生成计算job;如果包含内存索引并且查询语句要对索引字段值进行筛选,则读取索引表,根据索引字段值从索引表中获取到数据文件清单,为数据文件清单的每个数据文件生成只扫描该数据文件的计算job。
5.如权利要求4所述的基于Spark平台的数据查询方法,其特征在于:索引表中的索引字段值以及数据文件清单是按照索引字段值的升序或降序存储的,使用二分法在索引表中查找索引字段值对应的的数据文件清单。
6.如权利要求4所述的基于Spark平台的数据查询方法,其特征在于:如果包含内存索引,但查询语句不是要对索引字段值进行筛选,则针对所有数据文件分别生成计算job。
7.如权利要求4、5或6所述的基于Spark平台的数据查询方法,其特征在于:在执行计算job过程中,(1)判断是查询语句否包含谓词,如果包含谓词,则对谓词进行解析,获得想要查询的数据;(2)读取数据文件的末尾,判断是否有存储索引;(3)如果有存储索引,则读取索引数据并判断索引的范围是否可能包含所述想要查询的数据,如果可能包含,则加载相应数据到内存中;如果数据文件不可能存在所述想要查询的数据,则返回空数据。
8.如权利要求7所述的基于Spark平台的数据查询方法,其特征在于:所述步骤(3)具体为,获取文件索引,将所述想要查询的数据是否落入文件索引记载的最大值、最小值之间,如果位于两者之间则索引的范围可能包含所述想要查询的数据;逐条读取行索引,获取要扫描的行组,根据行索引中的行组数据的起始地址读取行组数据,对数据进行解析后加载至内存。
9.一种基于Spark平台的数据查询方法,其特征在于:(1)判断是查询语句否包含谓词,如果包含谓词,则对谓词进行解析,获得想要查询的数据;(2)读取数据文件的末尾,判断是否有存储索引;(3)如果有存储索引,则读取索引数据并判断索引的范围是否可能包含所述想要查询的数据,如果可能包含,则加载相应数据到内存中;如果数据文件不可能存在所述想要查询的数据,则返回空数据。
10.如权利要求9所述的基于Spark平台的数据查询方法,其特征在于:所述步骤(3)具体为,获取文件索引,将所述想要查询的数据是否落入文件索引记载的最大值、最小值之间,如果位于两者之间则索引的范围可能包含所述想要查询的数据;逐条读取行索引,获取要扫描的行组,根据行索引中的行组数据的起始地址读取行组数据,对数据进行解析后加载至内存。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911324622.9A CN111078705A (zh) | 2019-12-20 | 2019-12-20 | 基于Spark平台建立数据索引方法及数据查询方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911324622.9A CN111078705A (zh) | 2019-12-20 | 2019-12-20 | 基于Spark平台建立数据索引方法及数据查询方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN111078705A true CN111078705A (zh) | 2020-04-28 |
Family
ID=70316181
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201911324622.9A Pending CN111078705A (zh) | 2019-12-20 | 2019-12-20 | 基于Spark平台建立数据索引方法及数据查询方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111078705A (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111797063A (zh) * | 2020-06-28 | 2020-10-20 | 中孚信息股份有限公司 | 一种流式数据处理方法与*** |
CN114185934A (zh) * | 2021-12-15 | 2022-03-15 | 广州辰创科技发展有限公司 | 一种基于天盾数据库列存储的索引及查询方法及*** |
CN116955363A (zh) * | 2023-09-21 | 2023-10-27 | 北京四维纵横数据技术有限公司 | 无模式数据创建索引方法、装置、计算机设备及介质 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105631003A (zh) * | 2015-12-28 | 2016-06-01 | 北京赛思信安技术股份有限公司 | 支持海量数据分组统计的智能索引构建、查询及维护方法 |
CN106484877A (zh) * | 2016-10-14 | 2017-03-08 | 东北大学 | 一种基于hdfs的文件检索*** |
CN107103032A (zh) * | 2017-03-21 | 2017-08-29 | 中国科学院计算机网络信息中心 | 一种分布式环境下避免全局排序的海量数据分页查询方法 |
CN107122443A (zh) * | 2017-04-24 | 2017-09-01 | 中国科学院软件研究所 | 一种基于Spark SQL的分布式全文检索***及方法 |
CN108009270A (zh) * | 2017-12-18 | 2018-05-08 | 江苏润和软件股份有限公司 | 一种基于分布式内存计算的文本检索方法 |
-
2019
- 2019-12-20 CN CN201911324622.9A patent/CN111078705A/zh active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105631003A (zh) * | 2015-12-28 | 2016-06-01 | 北京赛思信安技术股份有限公司 | 支持海量数据分组统计的智能索引构建、查询及维护方法 |
CN106484877A (zh) * | 2016-10-14 | 2017-03-08 | 东北大学 | 一种基于hdfs的文件检索*** |
CN107103032A (zh) * | 2017-03-21 | 2017-08-29 | 中国科学院计算机网络信息中心 | 一种分布式环境下避免全局排序的海量数据分页查询方法 |
CN107122443A (zh) * | 2017-04-24 | 2017-09-01 | 中国科学院软件研究所 | 一种基于Spark SQL的分布式全文检索***及方法 |
CN108009270A (zh) * | 2017-12-18 | 2018-05-08 | 江苏润和软件股份有限公司 | 一种基于分布式内存计算的文本检索方法 |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111797063A (zh) * | 2020-06-28 | 2020-10-20 | 中孚信息股份有限公司 | 一种流式数据处理方法与*** |
CN114185934A (zh) * | 2021-12-15 | 2022-03-15 | 广州辰创科技发展有限公司 | 一种基于天盾数据库列存储的索引及查询方法及*** |
CN116955363A (zh) * | 2023-09-21 | 2023-10-27 | 北京四维纵横数据技术有限公司 | 无模式数据创建索引方法、装置、计算机设备及介质 |
CN116955363B (zh) * | 2023-09-21 | 2023-12-26 | 北京四维纵横数据技术有限公司 | 无模式数据创建索引方法、装置、计算机设备及介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN107247808B (zh) | 一种分布式NewSQL数据库***及图片数据查询方法 | |
US20170083573A1 (en) | Multi-query optimization | |
EP3014488B1 (en) | Incremental maintenance of range-partitioned statistics for query optimization | |
US11693912B2 (en) | Adapting database queries for data virtualization over combined database stores | |
US20070250517A1 (en) | Method and Apparatus for Autonomically Maintaining Latent Auxiliary Database Structures for Use in Executing Database Queries | |
US12047098B2 (en) | Data compression techniques | |
CN111078705A (zh) | 基于Spark平台建立数据索引方法及数据查询方法 | |
CN112988782B (zh) | Hive支持交互式查询的方法、装置及存储介质 | |
US20170270162A1 (en) | Query optimization method in distributed query engine and apparatus thereof | |
US11803550B2 (en) | Workload-aware column imprints | |
US11429629B1 (en) | Data driven indexing in a spreadsheet based data store | |
KR102541934B1 (ko) | 빅데이터 증강분석 프로파일링 시스템 | |
US11514236B1 (en) | Indexing in a spreadsheet based data store using hybrid datatypes | |
US8832157B1 (en) | System, method, and computer-readable medium that facilitates efficient processing of distinct counts on several columns in a parallel processing system | |
US8280869B1 (en) | Sharing intermediate results | |
Sinthong et al. | AFrame: Extending DataFrames for large-scale modern data analysis (Extended Version) | |
US11500839B1 (en) | Multi-table indexing in a spreadsheet based data store | |
US10762084B2 (en) | Distribute execution of user-defined function | |
KR20230054216A (ko) | 빅데이터 신뢰성과 활용성 극대화를 위한 빅데이터 증강분석 프로파일링 방법 및 장치 | |
Dayal et al. | Optimization of analytic data flows for next generation business intelligence applications | |
KR102668905B1 (ko) | 서버 마이그레이션 방법 및 이러한 방법을 수행하는 장치 | |
KR102675553B1 (ko) | 워크스페이스 백업 방법 및 이러한 방법을 수행하는 장치 | |
KR102634367B1 (ko) | 인공지능모델 캐싱 방법 및 이러한 방법을 수행하는장치 | |
KR102636753B1 (ko) | 워크스페이스 마이그레이션 방법 및 이러한 방법을수행하는 장치 | |
KR102680768B1 (ko) | 비정형 데이터에 대한 바이너리화를 수행하는 방법 및 이러한 방법을 수행하는 장치 |
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 |