WO2017096939A1 - 一种在基于HDFS的spark-sql大数据处理系统上建立索引的方法 - Google Patents

一种在基于HDFS的spark-sql大数据处理系统上建立索引的方法 Download PDF

Info

Publication number
WO2017096939A1
WO2017096939A1 PCT/CN2016/094925 CN2016094925W WO2017096939A1 WO 2017096939 A1 WO2017096939 A1 WO 2017096939A1 CN 2016094925 W CN2016094925 W CN 2016094925W WO 2017096939 A1 WO2017096939 A1 WO 2017096939A1
Authority
WO
WIPO (PCT)
Prior art keywords
index
data
file
sql
spark
Prior art date
Application number
PCT/CN2016/094925
Other languages
English (en)
French (fr)
Inventor
张鋆
冯骏
Original Assignee
深圳市华讯方舟软件技术有限公司
华讯方舟科技有限公司
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 深圳市华讯方舟软件技术有限公司, 华讯方舟科技有限公司 filed Critical 深圳市华讯方舟软件技术有限公司
Publication of WO2017096939A1 publication Critical patent/WO2017096939A1/zh

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
    • 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
    • G06F16/134—Distributed indices
    • 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
    • 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

Definitions

  • the invention relates to a method for establishing an index on a data processing system, in particular to a method for establishing an index on a spark-sql big data processing system based on HDFS.
  • Spark-sql is based on the big data processing platform spark, adding the ability to support standard sql query statements.
  • the Spark big data processing platform is a general-purpose parallel framework of Hadoop MapReduce open sourced by Berkeley. It has the advantages of Hadoop MapReduce.
  • the Spark big data processing program needs to master the scala language and write code based on the open API function interface. It is cumbersome and complicated, and a large number of SQL languages mastered by traditional database developers cannot be used on spark.
  • the birth of spark-sql solves the above problem. It applies the traditional database table concept to the spark processing framework. Users can create tables and queries with sql statements just like traditional database tables. Spark-sql automatically converts the corresponding operations into spark. Internal operations mask complex processing details.
  • spark-sql does not support indexing on data tables, that is, it does not support indexing statements similar to traditional databases, such as:
  • the traditional relational database After receiving the above command, the traditional relational database begins to index the c column of the a table.
  • indexes there are many types of indexes, such as B-tree indexes, Hash indexes, GiST indexes, GIN indexes, and so on.
  • B-tree indexes the principle of indexing a relational database is as follows:
  • the database opens up a separate storage area for storing the index tree.
  • Each node of the B-tree corresponds to each element in the b column, and each node further includes a pointer, and the pointer records the corresponding element of the node and is saved in the number According to the corresponding location in the library file.
  • the new element is also inserted into the B-tree (the B-tree is automatically adjusted), and the tree node records the location of the element in the database file.
  • the column b deletes an element
  • the element is also removed from the B-tree (the B-tree is automatically adjusted).
  • the database index is based on the entity file stored in the database, that is, the "corresponding location in the database file" mentioned above.
  • the database file can be customized according to the needs, so the corresponding position of the data in the file can have different representation methods, but the overall idea is It records the exact position of an element in the file. When you search for the element, you don't need to traverse the file. You can use this recorded position to quickly locate the record by some means, so as to speed up the search.
  • the data file corresponds to the table t, which has two columns a and b, wherein the b column establishes an index. That is, the index of the right tree structure, the elements in each node in the index have pointers to the corresponding elements of the data file, and the index itself is also stored as a file.
  • the table t When the table t inserts an element, according to the value of the b column, the corresponding index tree is dynamically modified; correspondingly, when the table t deletes the element, the content in the index tree is also dynamically deleted.
  • the indexing technology of the traditional relational database has been relatively mature.
  • the general principle is expressed here.
  • the implementation methods are various, and the expressions are usually not fixed, but the basic principles are all the same.
  • the establishment methods and implementation steps of other indexes are no longer here. One by one.
  • spark-sql because its underlying file storage is different from traditional relational databases (usually HDFS, not the usual Linux or Windows file system), and usually a table is very large, a table can even be associated with thousands. Tens of thousands of physical files, so the spark-sql design did not create the index function. Its design focus is on emphasizing the concurrency of data processing and ignoring the efficiency of processing.
  • spark-sql searches the entire data table, usually at spark-sql.
  • the amount of data is very large.
  • a database may correspond to multiple physical files. Spark-sql searches all files through concurrent technology.
  • First Spark-sql parses the sql statement, and then locates the data file of table t (there are 4 files here). Then divide these files into multiple blocks according to a specific size, and assign them to different work processes. The work process sequentially scans all the file blocks contained in the entire table, finds the row with the b column value of 22. After finding it, it returns result.
  • spark_sql does not have an index
  • the method of table search is relatively simple, and there is inefficiency, and all rows of all data files need to be scanned.
  • the current spark-sql has no data indexing mechanism, which can not make the query speed optimal. Compared with the traditional relational database, there is a problem of inefficiency.
  • the technical problem to be solved by the present invention is to provide a method for establishing an index on a spark-sql big data processing system based on HDFS, which can adapt spark-sql to more and more flexible application scenarios and speed up spark-sql. Execute the sql statement to query the speed, improve the execution efficiency of spark-sql, and fully take advantage of spark-sql's ability to handle big data.
  • the present invention provides a method for establishing an index on a spark-sql big data processing system based on HDFS, and adds an index and deletes an index on an HDFS-based spark-sql big data processing system through a SQL statement. Insert data, delete data, automatically determine whether there is an index in the query column when the data is queried, if it exists, look up the file block contained in the index, and filter the file block that does not need to be queried.
  • index file When adding an index, you first need to add an index file.
  • the format of the index file can be set according to the configuration and other instructions. Commonly used are B-tree, Hash index and other formats, and then traverse all the records in the original table to determine each record. The value of the column that needs to be indexed is located in the HDFS or other file system, and then the column value of the record and the corresponding file information are recorded and written into the index tree structure.
  • the loop traverses all the records, saves the index structure in the form of a file, and finally updates the table metadata information, and writes the new index information into the metadata of the table for use in subsequent queries.
  • the data table increases the data flow and follows the original process. After the data is added, the file name of the data is recorded, and the index node is constructed according to the returned file name.
  • the deleted data After deleting a piece of data, it is judged whether the deleted data involves an index. If an index is involved, the corresponding index structure needs to be adjusted to delete the index node associated with the data.
  • the data flow deletion process follows the original process, and only after the data deletion is completed, the index information corresponding to the deleted data is added.
  • the method for establishing an index on the HDFS-based spark-sql big data processing system has the following beneficial effects compared with the prior art.
  • spark-sql After adding index function to spark-sql, it can effectively increase the query speed. For example, a typical spark-sql data table with a size of 1000GB and 1GB file is stored in 1000 files. If you query a single record, the original method needs to scan 1000. After the files are indexed, only one file needs to be scanned, and the efficiency is increased by 1000 times. According to the general situation, combined with the traditional relational database experience, the spark-sql database that is indexed is 100-10000 times faster or faster than the query speed of the SQL statement without indexes.
  • FIG. 1 is a schematic diagram of a common data table and an index tree structure in the prior art.
  • FIG. 2 is a schematic diagram of a query when there is no index on the spark-sql big data processing system of HDFS in the prior art.
  • Figure 3 is a flow chart showing an increase in indexing of the present invention.
  • Figure 5 is a flow chart of the added data of the present invention.
  • Figure 6 is a flow chart of deletion data of the present invention.
  • Figure 7 is a flow chart of the query data of the present invention.
  • FIG. 8 is a schematic structural diagram of an HDF distributed storage system.
  • FIG. 9 is a schematic diagram showing the structure of a data table and an index tree in the distributed storage system of the present invention.
  • the method for establishing an index on the spark-sql big data processing system based on the HDFS implements the spark-sql support index function, which can be increased by a SQL statement like a traditional relational database.
  • Index, delete index, insert data, delete data automatically determine whether there is an index in the query column when the data is queried, if there is, find the file block contained in the index, filter the file block that does not need to be queried, and achieve the purpose of speeding up the query. .
  • Adding an index refers to adding an index to a column based on the original data table, and subsequent queries for this column can be accelerated by the index.
  • index file When adding an index, you first need to add an index file.
  • the format of the index file can be set according to the configuration and other instructions. Commonly used are B-tree, Hash index and other formats, and then traverse all the records in the original table to determine each record.
  • the value of the column that needs to be indexed is located in the HDFS or other file system, and then the column value of the record and the corresponding file information are recorded and written into the index tree structure. Loop through all the records, save the index structure in the form of a file, and finally update the table metadata information, and write the new index information into the metadata of the table for use in subsequent queries.
  • Deleting the index process of a column of a table is relatively simple. You only need to locate the corresponding index file to delete it, and update the table metadata information, and delete the index information in the metadata.
  • the data flow deletion process follows the original process, and only after the data deletion is completed, the index information corresponding to the deleted data is added.
  • spark-sql which is different from the index of the traditional database, and is designed to handle large amounts of data.
  • the traditional database capacity is 10GB.
  • spark-sql can achieve 1PB, which is 100,000 times the normal traditional database capacity.
  • a common data table generally corresponds to physical files on several file systems.
  • the typical deployment method of spark-sql is combined with HDFS. It stores files in a distributed storage manner.
  • a data table can correspond to Thousands or even tens of thousands of files stored on HDFS, as shown in Figure 8.
  • a spark-sql node consists of several spark nodes, and the underlying storage is used.
  • HDFS distributed storage system. That is, the data file exists in HDFS.
  • t1-p1 represents the part1 part of table t1, which is a physical file.
  • t1-p2 represents the part2 file of table t1, and the whole table t1 consists of 7 files of p1-p7; similarly, table t2 consists of 3 files are composed.
  • the original query process scans all table files when querying sql statements.
  • Spark-sql parses the above sql statement, and then looks up the database file corresponding to table t. The result is 7 files of t1-p1, t1-p2, t1-p3, t1-p4, t1-p5, t1-p6, t1-p7. In the case of not considering the file too large, spark-sql will create 7 query tasks, corresponding to these 7 files to start scanning queries, scan all files until you find a record line that meets the conditions.
  • the present invention refers to the principle of general indexing and on the basis of this, improves the storage characteristics of spark-sql.
  • the index granularity of the present invention is different from the traditional database index.
  • the traditional database index generally points to the address of a certain record in the file. Since a database table file of spark-sql usually consists of many files, the idea adopted by this method is to record one record. The index of a field is located in a file, that is, in which file the record is recorded. When searching for this record, it only needs to directly locate a file according to the index, instead of scanning the file. All files.
  • the table t consists of 7 files of t1-p1, t1-p2, t1-p3, t1-p4, t1-p5, t1-p6, t1-p7, and table t has 2 fields a and b. , where the b field is indexed, assuming there are several records (there are no records shown here), and an index as shown in Figure 9 is created.
  • the table record is the original record inserted into the table.
  • the B-tree index is established on column b.
  • Each node in the index tree records the value in the database record corresponding to the node and the corresponding physical file in the HDFS file system where the record is located.
  • the table t When the table t inserts an element, according to the value of the b column, the corresponding index tree is dynamically modified; corresponding, When the table t deletes the element, the content in the index tree is also dynamically deleted.
  • the index concept of spark-sql in the present invention is similar to the traditional database, but it is fundamentally different.
  • the present invention is based on the characteristics of spark-sql processing big data, and changes the index granularity from a certain position in the file of the traditional database. Spark a file in the database to avoid scanning a large number of invalid files and avoid wasting system resources.
  • the index in the present invention is applicable to all sql statements, that is, in simple or complex sql queries, any query operation involving an index column will first locate the file according to the index, and then perform sql query operation in the located file, which is Traditional relational database practices have fundamental differences.
  • Indexing create index myindex on t(b); where the keyword is create index on
  • View index show index from t; where the keyword is show index from
  • Delete index drop index myindex on t; where the keyword is drop index on
  • Spark-sql is different from the traditional relational database.
  • One of the key points of the present invention is that the index is based on a file, that is, the index points to a specific file on an HDFS or other file system, rather than the content in the file. Larger than traditional databases. Under the premise that the database table is indexed according to the present invention, the invalid query file can be effectively filtered, and the range of the queried file can be narrowed, thereby improving query efficiency.
  • the established index includes but is not limited to a unique index, a primary key index, a multi-attribute index, a partial index, and an expression index. These index types are consistent with the concepts in traditional databases; the data structures used to build indexes include but are not limited to B-trees, Hash, GiST, GIN, etc. These data structures are consistent with the concepts in traditional databases.
  • the database tables established in spark-sql are not indexed, and the query speed and query efficiency are limited.
  • the query speed can be increased by several orders of magnitude.
  • query efficiency and query speed are comparable to traditional relational databases.

Abstract

一种在基于HDFS的spark-sql大数据处理系统上建立索引的方法，通过SQL语句在基于HDFS的spark-sql大数据处理系统上增加索引，删除索引，插入数据，删除数据，在数据查询的时候，自动判断查询列是否存在索引，如果存在，则查找索引包含的文件块，过滤不需要查询的文件块。给spark-sql增加索引功能后，能有效增加查询速度，例如一个典型的spark-sql数据表，大小为1000GB，1GB一个文件存放，分为1000个文件，如果查询单条记录，原先做法需要扫描1000个文件，建立索引后，只需要扫描1个文件即可，效率提高1000倍。按照一般情况估算，结合传统的关系型数据库经验，建立索引的spark-sql数据库比没有索引的sql语句查询速度执行要快100-10000倍或更多。

Description

一种在基于HDFS的spark-sql大数据处理系统上建立索引的方法 技术领域
本发明涉及一种在数据处理系统上建立索引的方法，尤其涉及一种在基于HDFS的spark-sql大数据处理系统上建立索引的方法。
背景技术
Spark-sql是在大数据处理平台spark的基础上，增加了支持标准sql查询语句的功能。
Spark大数据处理平台是Berkeley所开源的类Hadoop MapReduce的通用并行框架，它拥有Hadoop MapReduce所具有的优点；但是Spark大数据处理程序的编写需要掌握scala语言，并且基于开放的API函数接口进行代码编写，繁琐而且复杂，并且大量的传统数据库开发人员所掌握的SQL语言无法在spark上使用。spark-sql的诞生解决了上述问题，它将传统的数据库表概念应用到spark处理框架，用户可以像操作传统数据库表那样，用sql语句建表和查询，spark-sql自动将相应操作转化为spark内部操作，屏蔽了复杂的处理细节。
但是由于spark大数据处理平台的特殊性，spark-sql不支持在数据表上建立索引，即不支持类似于传统数据库的建立索引语句，例如：
create index myindex on table t(b)；
意为：在表t的b列上建立名为myindex的一般索引。
传统关系型数据库在接收到上述命令后，即开始为a表的c列建立索引。
索引的类型有很多种，例如B-树索引，Hash索引，GiST索引，GIN索引等等。以B-树索引为例，关系型数据库建立索引原理如下：
数据库开辟一块单独的存储区域，用来存储索引树。
根据需要索引的列(例子中为名为b的列)中的字段生成B-树。并将此树保存到指定存储区域。其中B-树的每个节点对应b列中每个元素，另外每个节点中还包含一个指针，该指针记录了这个节点对应元素保存在数 据库文件中的相应位置。
当b列插入新元素时，也要将新元素插入B-树(B-树会自动调整)，同时该树节点记录该元素在数据库文件中的位置。
当b列删除元素时，也要将元素从B-树中删除(B-树会自动调整)。
数据库索引基于数据库存储的实体文件，即上面所说的“数据库文件中的相应位置”，数据库文件可以根据需要自定义格式，所以数据在文件中的相应位置可以有不同表示方法，但总体思路都是记录了一个元素在文件中的确切位置，后续查找该元素时，不需要遍历文件，而可以借助这个已经记录的位置通过某种方法快速定位记录，从而达到加快查找的目的。
如图1所示，数据文件对应表t，有a，b两列，其中b列建立了一个索引。即右边树结构的索引，索引中每个节点中的元素有指向数据文件相应元素位置的指针，其中索引本身也作为一个文件存储起来。
当查询数据时，例如查询语句
Select*from t where b＝22；
表示查询表t中b列等于22的所有行。首先数据库先解析sql语句，然后发现b列存在索引。
然后，直接从索引树中快速找到22元素，根据22元素的指针，定位到元素值为22的b列所在的行，其地址为0x90，然后直接根据地址，取出这一行，返回结果为“522”。
当表t插入元素时，根据b列的值，会动态修改相应的索引树；相应的，当表t删除元素时，也会动态删减索引树中的内容。
传统关系数据库的索引技术已经比较成熟，这里表述的是其一般原理，其实现方式多种多样，表现形式通常不固定，但基本原理都是相通的，其它索引的建立方法和实现步骤这里不再一一赘述。
对于spark-sql，由于其底层的文件存储方式不同于传统关系型数据库(通常采用HDFS，而不是一般的Linux或Windows文件系统)，而且通常一个表容量很大，一个表甚至会关联到成千上万个物理文件，所以spark-sql设计之时并没有创建索引的功能。其设计重点在于强调数据处理的并发能力而忽略了处理的效率问题。
通常spark-sql进行数据查询时，会搜索整个数据表，通常spark-sql处 理的数据量很大，一个数据库可能对应于多个物理文件，spark-sql会通过并发技术，对所有文件进行搜索。
如图2所示，以同样的sql查询语句为例：
Select*from t where b＝22；
首先Spark-sql解析sql语句，然后定位到表t的数据文件(这里有4个文件)。然后将这几个文件根据特定大小拆分成多个块，分配给不同的工作进程处理，工作进程顺序扫描整个表包含的所有文件分块，找到b列值为22的行，找到之后，返回结果。
可以看出，spark-sql在没有索引的情况下，进行表搜索的方式比较简单，存在效率低下，需要扫描全部的数据文件的所有行。
除了简单的select语句，传统关系数据库在所有涉及到查询的地方包括复杂查询，子查询，嵌套查询等等都会应用索引技术，来减少查询量，加快查询速度，spark-sql没有这样的机制。
综上所述，当前的spark-sql由于没有数据索引机制，无法使得查询速度达到最优，相比于传统关系型数据库，存在效率低下的问题。
发明内容
本发明要解决的技术问题是提供一种在基于HDFS的spark-sql大数据处理系统上建立索引的方法，该方法可以使spark-sql适应于更多、更灵活的应用场景，加快spark-sql执行sql语句进行查询的速度，提高spark-sql的执行效率，更充分地发挥spark-sql处理大数据能力的优势。
为了解决上述技术问题，本发明提供了一种在基于HDFS的spark-sql大数据处理系统上建立索引的方法，通过SQL语句在基于HDFS的spark-sql大数据处理系统上增加索引，删除索引，插入数据，删除数据，在数据查询的时候，自动判断查询列是否存在索引，如果存在，则查找索引包含的文件块，过滤不需要查询的文件块。
增加索引时，首先需要新增一个索引文件，索引文件的格式可以根据配置和其它指令设置，常用的有B-树、Hash索引等格式，然后遍历原有表中所有记录，确定每条记录所需要索引的列的值位于HDFS或其他文件系统中位置，再记录该记录的列值和对应的文件信息，写入索引树结构。循 环遍历所有记录，以文件形式保存索引结构，最后更新表元数据信息，将新的索引信息写入表的元数据中，以备后续查询使用。
删除某表某列的索引时，只需要定位到相应的索引文件将其删除，并更新表元数据信息，同时删除元数据中的索引信息即可。
插入一条数据后，判断插入的数据是否涉及到索引，如果涉及索引，则需要调整相应的索引结构，将这条数据和它相关联的文件信息也加入到索引结构中去。
在整个流程中，数据表增加数据流程沿用原流程不变，只在数据增加完成后，记录数据所在的文件名，根据此返回的文件名构造索引节点。
删除一条数据后，判断删除的数据是否涉及到索引，如果涉及索引，则需要调整相应的索引结构，将这条数据关联的索引节点删除。
在整个流程中，其中数据表删除数据流程沿用原流程不变，只在数据删除完成后，增加删除数据对应的索引信息
查询数据时，根据数据列值，查询索引文件中相应的节点元素，然后读取元素值，从而获取该数据所对应文件所在的文件名，然后继续原查询流程，原查询流程最后将读取这个表中所有的数据文件进行查询，在这之前根据上一步获取的文件名，过滤掉无效文件，然后对剩下的文件继续执行查询流程，然后根据查询的数据执行SQL操作，最后返回查询结果。
将一条记录中某个字段的索引定位到某个文件，即记录了这条记录包含在哪个文件中，后续查找这条记录时，只需要根据索引直接定位到某个文件，而不用扫描这个表所包含的所有文件。
本发明在基于HDFS的spark-sql大数据处理系统上建立索引的方法与现有技术相比具有以下有益效果。
对spark-sql增加索引功能后，能有效增加查询速度，例如一个典型的spark-sql数据表，大小为1000GB，1GB一个文件存放，分为1000个文件，如果查询单条记录，原先做法需要扫描1000个文件，建立索引后，只需要扫描1个文件即可，效率提高1000倍。按照一般情况估算，结合传统的关系型数据库经验，建立索引的spark-sql数据库比没有索引的sql语句查询速度执行要快100-10000倍或更多。
附图说明
以下结合附图和具体实施方式对本发明在基于HDFS的spark-sql大数据处理系统上建立索引的方法作进一步的详细描述。
图1是现有技术中普通数据表与索引树结构示意图。
图2是现有技术中在HDFS的spark-sql大数据处理系统上没有索引时的查询原理图。
图3是本发明的增加索引流程图。
图4是本发明的删除索引流程图。
图5是本发明的增加数据流程图。
图6是本发明的删除数据流程图。
图7是本发明的查询数据流程图。
图8是HDF分布式存储系统结构示意图。
图9是本发明分布式存储系统中数据表与索引树结构示意图。
具体实施方式
如图3至图9所示，本实施方式在基于HDFS的spark-sql大数据处理系统上建立索引的方法实现了spark-sql增加支持索引功能，能够像传统关系型数据库那样，通过SQL语句增加索引，删除索引，插入数据，删除数据，在数据查询的时候，自动判断查询列是否存在索引，如果存在，则查找索引包含的文件块，过滤不需要查询的文件块，达到加快查询速度的目的。
1)如图3所示，增加索引流程。
增加索引指在原有数据表的基础上，为某一列增加索引，后续针对此列的查询可以通过索引加速。
增加索引时，首先需要新增一个索引文件，索引文件的格式可以根据配置和其它指令设置，常用的有B-树、Hash索引等格式，然后遍历原有表中所有记录，确定每条记录所需要索引的列的值位于HDFS或其他文件系统中位置，再记录该记录的列值和对应的文件信息，写入索引树结构。循环遍历所有记录，以文件形式保存索引结构，最后更新表元数据信息，将新的索引信息写入表的元数据中，以备后续查询使用。
2)如图4所示，删除索引流程。
删除某表某列的索引流程较为简单，只需要定位到相应的索引文件将其删除，并更新表元数据信息，同时删除元数据中的索引信息即可。
3)如图5所示，插入数据流程(表已有索引)。
插入一条数据后(包括批量插入，实际为连续单条数据插入)，会判断插入的数据是否涉及到索引，如果涉及索引，则需要调整相应的索引结构，将这条数据和它相关联的文件信息也加入到索引结构中去。
在整个流程中，其中数据表增加数据流程沿用原流程不变，只在数据增加完成后，记录数据所在的文件名，根据此返回的文件名构造索引节点。
4)如图6所示，删除数据流程(表已有索引)。
删除一条数据后(包括批量删除，实际为连续单条数据删除)，会判断删除的数据是否涉及到索引，如果涉及索引，则需要调整相应的索引结构，将这条数据关联的索引节点删除。
在整个流程中，其中数据表删除数据流程沿用原流程不变，只在数据删除完成后，增加删除数据对应的索引信息。
5)如图7所示，查询数据流程(表有索引)。
查询数据时，根据数据列值，查询索引文件中相应的节点元素，然后读取元素值，从而获取该数据所对应文件所在的文件名，然后继续原查询流程，原查询流程最后将读取这个表中所有的数据文件进行查询，在这之前根据上一步获取的文件名，过滤掉无效文件，然后对剩下的文件继续执行查询流程。经过过滤的文件数量会大大减少，减少查询负担，然后根据查询的数据执行SQL操作，最后返回查询结果。
在此特别强调的是，本实施方式基于spark-sql的索引，不同于传统数据库的索引，其设计目的是为了处理大数据量的。传统数据库容量以10GB为例，spark-sql可以做到1PB，即10万倍普通传统数据库容量。
普通数据库一张数据表一般对应若干个文件系统上的物理文件，而spark-sql典型部署方式与HDFS相结合，是以一种分布式存储的方式来存储文件，其一张数据表可以对应于数千个乃至上万个存储在HDFS上的文件，如图8所示。
通常一个spark-sql节点由若干个spark节点组成，其底层存储采用 HDFS分布式存储系统。即数据文件存在于HDFS。图中，t1-p1表示表t1的part1部分，它是一个物理文件，同理t1-p2表示表t1的part2文件，整个表t1由p1-p7共7个文件组成；同样地，表t2由3个文件组成。
原查询流程在进行sql语句查询时，会扫描所有表文件。
例如Select*from t where b＝22
Spark-sql解析上述sql语句，然后查找表t对应的数据库文件，结果为t1-p1，t1-p2，t1-p3，t1-p4，t1-p5，t1-p6，t1-p7一共7个文件，在不考虑文件过大切分的情况下，spark-sql会建立7个查询任务，分别对应这7个文件开始扫描查询，扫描所有文件，直到找到符合条件的记录行。
本发明参考一般索引的原理并在此基础上针对spark-sql存储特点加以改进。
本发明的索引粒度不同于传统数据库索引，传统数据库索引一般指向某条记录在文件内的地址，由于spark-sql一个数据库表文件通常由很多文件组成，所以本法采取的思路为，将一条记录中某个字段的索引定位到某个文件，即记录了这条记录包含在哪个文件中，后续查找这条记录时，只需要根据索引直接定位到某个文件，而不用扫描这个表所包含的所有文件。
引用以上述例子，表t有t1-p1，t1-p2，t1-p3，t1-p4，t1-p5，t1-p6，t1-p7一共7个文件组成，表t有2个字段a和b，其中b字段建立了索引，假设其中有若干条记录(这里没有显示全部记录)，建立如图9所示的索引。
其中表记录为插入到表中的原始记录，插入的同时，在b列上建立B-树索引。索引树中每个节点记录了该节点对应的数据库记录中的值以及该记录所在HDFS文件系统中对应的物理文件。
当查询数据时，例如查询语句。
Select*from t where b＝22；
表示查询表t中b列等于22的所有行。首先数据库先解析sql语句，然后发现b列存在索引。
然后直接从索引树中快速找到22元素，根据22元素的指针，定位到元素值为22的b列所在的物理文件为t1-p7，然后仅读取这一个文件内容进行查找，找到记录后返回。
当表t插入元素时，根据b列的值，会动态修改相应的索引树；对应的， 当表t删除元素时，也会动态删减索引树中的内容。
可以看出，本发明中spark-sql的索引概念与传统数据库虽然类似，但有着根本的不同，本发明是根据spark-sql处理大数据特点，将索引粒度从传统数据库的文件中某位置改为spark数据库中某个文件，从而避免扫描大量无效文件，避免浪费系统资源。
本发明中的索引适用于所有sql语句，即在无论简单或者复杂sql查询中，但凡涉及到索引列的查询操作，都会先根据索引定位文件，然后在定位的文件中进行sql查询操作，这与传统关系数据库做法具有根本区别。
本发明的关键点
1、在spark-sql上增加支持索引的机制，例如支持以下sql语句：
建立索引：create index myindex on t(b)；其中关键字为create index on
查看索引：show index from t；其中关键字为show index from
删除索引：drop index myindex on t；其中关键字为drop index on
2、基于文件的索引机制
Spark-sql与传统关系型数据库不同，本发明的关键点之一在于，索引建立在文件基础上，即索引指向一个HDFS或者其它文件系统上的一个具体文件，而不是文件中的内容，粒度要比传统数据库大。在数据库表根据本发明建立索引的前提下，能够有效过滤无效查询文件，能够缩小所查询的文件范围，从而提高查询效率。
3、建立的索引包含但不限于唯一索引，主键索引，多属性索引，部分索引，表达式索引。这些索引类型与传统数据库中的概念一致；建立索引所使用的数据结构包含但不限于B-树，Hash，GiST，GIN等，这些数据结构与传统数据库中的概念一致。
本发明的优点如下。
目前没有公开的对spark-sql支持索引技术的实时方案和方法。
所以目前公开技术中，spark-sql中建立的数据库表都是没有索引的，其查询速度和查询效率被限制，通过对spark-sql建立索引机制，可以提高查询速度若干数量级。可以做到海量数据情况下，查询效率和查询速度与传统关系型数据库不相上下。
需要说明的是，以上参照附图所描述的各个实施例仅用以说明本发明 而非限制本发明的范围，本领域的普通技术人员应当理解，在不脱离本发明的精神和范围的前提下对本发明进行的修改或者等同替换，均应涵盖在本发明的范围之内。此外，除上下文另有所指外，以单数形式出现的词包括复数形式，反之亦然。另外，除非特别说明，那么任何实施例的全部或一部分可结合任何其它实施例的全部或一部分来使用。

Claims (9)

  1. 一种在基于HDFS的spark-sql大数据处理系统上建立索引的方法，其特征在于：通过SQL语句在基于HDFS的spark-sql大数据处理系统上增加索引，删除索引，插入数据，删除数据，在数据查询的时候，自动判断查询列是否存在索引，如果存在，则查找索引包含的文件块，过滤不需要查询的文件块。
  2. 根据权利要求1所述在基于HDFS的spark-sql大数据处理系统上建立索引的方法，其特征在于：增加索引时，首先需要新增一个索引文件，索引文件的格式可以根据配置和其它指令设置，常用的有B-树、Hash索引等格式，然后遍历原有表中所有记录，确定每条记录所需要索引的列的值位于HDFS或其他文件系统中位置，再记录该记录的列值和对应的文件信息，写入索引树结构，循环遍历所有记录，以文件形式保存索引结构，最后更新表元数据信息，将新的索引信息写入表的元数据中，以备后续查询使用。
  3. 根据权利要求1所述在基于HDFS的spark-sql大数据处理系统上建立索引的方法，其特征在于：删除某表某列的索引时，只需要定位到相应的索引文件将其删除，并更新表元数据信息，同时删除元数据中的索引信息即可。
  4. 根据权利要求1所述在基于HDFS的spark-sql大数据处理系统上建立索引的方法，其特征在于：插入一条数据后，判断插入的数据是否涉及到索引，如果涉及索引，则需要调整相应的索引结构，将这条数据和它相关联的文件信息也加入到索引结构中去。
  5. 根据权利要求1所述在基于HDFS的spark-sql大数据处理系统上建立索引的方法，其特征在于：在整个流程中，数据表增加数据流程沿用原流程不变，只在数据增加完成后，记录数据所在的文件名，根据此返回的文件名构造索引节点。
  6. 根据权利要求1所述在基于HDFS的spark-sql大数据处理系统上建立索引的方法，其特征在于：删除一条数据后，判断删除的数据是否涉及到索引，如果涉及索引，则需要调整相应的索引结构，将这条数据关联 的索引节点删除。
  7. 根据权利要求1所述在基于HDFS的spark-sql大数据处理系统上建立索引的方法，其特征在于：在整个流程中，其中数据表删除数据流程沿用原流程不变，只在数据删除完成后，增加删除数据对应的索引信息。
  8. 根据权利要求1所述在基于HDFS的spark-sql大数据处理系统上建立索引的方法，其特征在于：查询数据时，根据数据列值，查询索引文件中相应的节点元素，然后读取元素值，从而获取该数据所对应文件所在的文件名，然后继续原查询流程，原查询流程最后将读取这个表中所有的数据文件进行查询，在这之前根据上一步获取的文件名，过滤掉无效文件，然后对剩下的文件继续执行查询流程，然后根据查询的数据执行SQL操作，最后返回查询结果。
  9. 根据权利要求1所述在基于HDFS的spark-sql大数据处理系统上建立索引的方法，其特征在于：将一条记录中某个字段的索引定位到某个文件，即记录了这条记录包含在哪个文件中，后续查找这条记录时，只需要根据索引直接定位到某个文件，而不用扫描这个表所包含的所有文件。
PCT/CN2016/094925 2015-12-10 2016-08-12 一种在基于HDFS的spark-sql大数据处理系统上建立索引的方法 WO2017096939A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510918956.4A CN105574093B (zh) 2015-12-10 2015-12-10 一种在基于HDFS的spark-sql大数据处理系统上建立索引的方法
CN201510918956.4 2015-12-10

Publications (1)

Publication Number Publication Date
WO2017096939A1 true WO2017096939A1 (zh) 2017-06-15

Family

ID=55884224

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/094925 WO2017096939A1 (zh) 2015-12-10 2016-08-12 一种在基于HDFS的spark-sql大数据处理系统上建立索引的方法

Country Status (2)

Country Link
CN (1) CN105574093B (zh)
WO (1) WO2017096939A1 (zh)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110674154A (zh) * 2019-09-26 2020-01-10 浪潮软件股份有限公司 一种基于Spark的对Hive中数据进行插入、更新和删除的方法
CN110928835A (zh) * 2019-10-12 2020-03-27 虏克电梯有限公司 基于海量存储的新型文件存储系统和方法
CN111125216A (zh) * 2019-12-10 2020-05-08 中盈优创资讯科技有限公司 数据导入Phoenix的方法及装置
CN111752804A (zh) * 2020-06-29 2020-10-09 中国电子科技集团公司第二十八研究所 一种基于数据库日志扫描的数据库缓存系统
CN112231321A (zh) * 2020-10-20 2021-01-15 中国电子科技集团公司第二十八研究所 一种Oracle二级索引及索引实时同步方法
CN113297204A (zh) * 2020-07-15 2021-08-24 阿里巴巴集团控股有限公司 索引生成方法及装置

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105574093B (zh) * 2015-12-10 2019-09-10 深圳市华讯方舟软件技术有限公司 一种在基于HDFS的spark-sql大数据处理系统上建立索引的方法
CN106599062A (zh) * 2016-11-18 2017-04-26 北京奇虎科技有限公司 一种SparkSQL系统中的数据处理方法和装置
CN106844415B (zh) * 2016-11-18 2021-08-20 北京奇虎科技有限公司 一种SparkSQL系统中的数据处理方法和装置
CN106777278B (zh) * 2016-12-29 2021-02-23 海尔优家智能科技（北京）有限公司 一种基于Spark的数据处理方法及装置
CN107092685A (zh) * 2017-04-24 2017-08-25 广州新盛通科技有限公司 一种联合使用文件系统和rdbms存储事务数据的方法
CN107368517B (zh) * 2017-06-02 2018-07-13 上海恺英网络科技有限公司 一种大数据流查询的方法及设备
CN107391555B (zh) * 2017-06-07 2020-08-04 中国科学院信息工程研究所 一种面向Spark-Sql检索的元数据实时更新方法
CN110019497B (zh) * 2017-08-07 2021-06-08 北京国双科技有限公司 一种数据读取方法及装置
CN108132986B (zh) * 2017-12-14 2020-06-16 北京航天测控技术有限公司 一种飞行器海量传感器试验数据的快速处理方法
CN108874897B (zh) * 2018-05-23 2019-09-13 新华三大数据技术有限公司 数据查询方法及装置
CN110046176B (zh) * 2019-04-28 2023-03-31 南京大学 一种基于Spark的大规模分布式DataFrame的查询方法
CN112015729B (zh) * 2019-05-29 2024-04-02 核桃运算股份有限公司 数据管理装置、方法及其计算机存储介质
CN111177102B (zh) * 2019-12-25 2022-07-19 苏州浪潮智能科技有限公司 一种实现hdfs启动加速的优化方法及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101727465A (zh) * 2008-11-03 2010-06-09 中国移动通信集团公司 分布式列存储数据库索引建立、查询方法及装置与系统
CN103631910A (zh) * 2013-11-26 2014-03-12 烽火通信科技股份有限公司 一种分布式数据库多列复合查询的系统及方法
CN104133867A (zh) * 2014-07-18 2014-11-05 中国科学院计算技术研究所 分布式顺序表片内二级索引方法及系统
CN105574093A (zh) * 2015-12-10 2016-05-11 深圳市华讯方舟软件技术有限公司 一种在基于HDFS的spark-sql大数据处理系统上建立索引的方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2417342A (en) * 2004-08-19 2006-02-22 Fujitsu Serv Ltd Indexing system for a computer file store
CN101344881A (zh) * 2007-07-09 2009-01-14 中国科学院大气物理研究所 海量文件型数据的索引生成方法及装置和搜索系统
CN104462291B (zh) * 2014-11-27 2018-01-09 杭州华为数字技术有限公司 一种数据处理的方法及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101727465A (zh) * 2008-11-03 2010-06-09 中国移动通信集团公司 分布式列存储数据库索引建立、查询方法及装置与系统
CN103631910A (zh) * 2013-11-26 2014-03-12 烽火通信科技股份有限公司 一种分布式数据库多列复合查询的系统及方法
CN104133867A (zh) * 2014-07-18 2014-11-05 中国科学院计算技术研究所 分布式顺序表片内二级索引方法及系统
CN105574093A (zh) * 2015-12-10 2016-05-11 深圳市华讯方舟软件技术有限公司 一种在基于HDFS的spark-sql大数据处理系统上建立索引的方法

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110674154A (zh) * 2019-09-26 2020-01-10 浪潮软件股份有限公司 一种基于Spark的对Hive中数据进行插入、更新和删除的方法
CN110674154B (zh) * 2019-09-26 2023-04-07 浪潮软件股份有限公司 一种基于Spark的对Hive中数据进行插入、更新和删除的方法
CN110928835A (zh) * 2019-10-12 2020-03-27 虏克电梯有限公司 基于海量存储的新型文件存储系统和方法
CN111125216A (zh) * 2019-12-10 2020-05-08 中盈优创资讯科技有限公司 数据导入Phoenix的方法及装置
CN111125216B (zh) * 2019-12-10 2024-03-12 中盈优创资讯科技有限公司 数据导入Phoenix的方法及装置
CN111752804A (zh) * 2020-06-29 2020-10-09 中国电子科技集团公司第二十八研究所 一种基于数据库日志扫描的数据库缓存系统
CN113297204A (zh) * 2020-07-15 2021-08-24 阿里巴巴集团控股有限公司 索引生成方法及装置
CN113297204B (zh) * 2020-07-15 2024-03-08 阿里巴巴集团控股有限公司 索引生成方法及装置
CN112231321A (zh) * 2020-10-20 2021-01-15 中国电子科技集团公司第二十八研究所 一种Oracle二级索引及索引实时同步方法
CN112231321B (zh) * 2020-10-20 2022-09-20 中国电子科技集团公司第二十八研究所 一种Oracle二级索引及索引实时同步方法

Also Published As

Publication number Publication date
CN105574093A (zh) 2016-05-11
CN105574093B (zh) 2019-09-10

Similar Documents

Publication Publication Date Title
WO2017096939A1 (zh) 一种在基于HDFS的spark-sql大数据处理系统上建立索引的方法
CN109299102B (zh) 一种基于Elastcisearch的HBase二级索引系统及方法
US10642831B2 (en) Static data caching for queries with a clause that requires multiple iterations to execute
US20160147804A1 (en) Forced ordering of a dictionary storing row identifier values
JP6964384B2 (ja) 異種データソース混在環境におけるフィールド間の関係性の自動的発見のための方法、プログラム、および、システム
US8938430B2 (en) Intelligent data archiving
US9268804B2 (en) Managing a multi-version database
US11269954B2 (en) Data searching method of database, apparatus and computer program for the same
US10127252B2 (en) History and scenario data tracking
EP2843567A1 (en) Computer-implemented method for improving query execution in relational databases normalized at level 4 and above
KR20170024039A (ko) 유연한 스키마를 사용한 데이터 관리
US9830319B1 (en) Hierarchical data extraction mapping and storage machine
CN112231321B (zh) 一种Oracle二级索引及索引实时同步方法
EP3867772B1 (en) Distributed join index for shared-nothing and log-structured databases
CN109885585B (zh) 支持存储过程、触发器与视图的分布式数据库系统和方法
KR20150098660A (ko) 활성 데이터베이스 쿼리의 유지
CN111078709A (zh) 一种基于数仓工具hive的非更新方式的增量拉链实现方法
KR20150043929A (ko) 데이터베이스 관리 방법, 시스템 및 데이터베이스 트리 구조
D’silva et al. Secondary indexing techniques for key-value stores: Two rings to rule them all
WO2016169322A1 (zh) 数据库的查询方法和装置、计算机存储介质
WO2019174558A1 (zh) 一种数据索引方法及装置
Trivedi et al. Codd: Constructing dataless databases
Leeka et al. RQ-RDF-3X: going beyond triplestores
Devulapalli et al. Attribute storage design for object-based storage devices
US20220043821A1 (en) Method for performing multi-caching on data sources of same type and different types by using cluster-based processing system and device using the same

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16872135

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16872135

Country of ref document: EP

Kind code of ref document: A1