分布式内存列式数据库的查询引擎系统及查询方法

文档序号:10471246阅读:308来源:国知局
分布式内存列式数据库的查询引擎系统及查询方法
【专利摘要】本发明公开了一种分布式内存列式数据库的查询引擎系统及查询方法,查询方法包括:资源管理模块确定一个主查询引擎负责与用户之间的会话;主查询引擎将用户发送的SQL语言转换为查询计划;资源管理模块为主查询引擎分配从查询引擎;主查询引擎将查询计划分割成至少两个子任务,并为每个子任务分配从查询引擎;在当前子任务的前驱子任务全部执行完成后执行当前子任务,将当前子任务执行完成产生的中间数据传输至后继子任务所在的从查询引擎,并将当前子任务完成状态发送至主查询引擎;主查询引擎通知客户在从查询引擎获取最终结果数据。本发明提供的分布式内存列式数据库的查询引擎系统及查询方法,可以得到良好的查询效率。
【专利说明】
分布式内存列式数据库的查询引擎系统及查询方法
技术领域
[0001]本发明涉及数据库技术领域,具体涉及一种分布式内存列式数据库的查询引擎系统及查询方法。
【背景技术】
[0002]NewSQL是对各种新的可扩展、高性能数据库的简称,这类数据库不仅具有NoSQL对海量数据的存储管理能力,还保持了传统数据库支持ACID和SQL等特性。一般来说,NewSQL大致分为三类:新架构,采用全新的数据库平台,采取不同的设计方法,例如GoogleSpanner、Clustrix、VoltDB以及MemSQL; SQL查询引擎,高度优化的SQL存储引擎,提供了MySQL相同的编程接口,但扩展性比内置的引擎InnoDB更好;透明分片,提供分片的中间件层,数据库自动分割在多个节点运行。随着时间的推移,这三种类型的NewSQL数据库已经逐渐融合,诞生了面向联机分析处理(OLAP,Online Analytical Processing)的大规模分布式内存列式数据库。
[0003]查询引擎是数据库系统的核心部分,负责整个数据库系统查询计算任务的执行调度。一条用户输入的SQL语句,在数据库系统中首先会进行SQL语句词法语法解析生成语法树,再经过数据库查询优化器对语法树进行变形,最后转化成数据库查询引擎可以识别的查询计划。查询计划告诉查询引擎怎样执行,怎样从数据库底层存储引擎中提取数据,对数据进行变形最后转换成用户想要的结果。
[0004]HIVE是基于Hadoop的一个数据仓库工具,并提供简单的SQL查询功能,可以将SQL语句转换成MapReduce任务进行运行。对于SQL语句SELECT c_custkey FROM customerJOIN nat1n ON customer.C_NAT10NKEY = nat1n.N_NAT1NKEY JOIN lineitem ONlineitem.L_PARTKEY = customer.C_CUSTKEY,HIVE 对一次 SQL 查询计划和任务执行流程如图1所示。HIVE真正执行的是MapReduce任务,所以会把查询计划转化为MapReduce任务集合,原查询计划被转化成两个MapReduce任务。其中,JOBl负责计算Jo ini,也就是line item表和customer表的Jo in运算;J0B2负责计算Jo in2,也就是计算Jo in I结果和nat1n表的Join运算,最终输出结果。JOBl执行完成之后,会把中间结果数据写入外部存储系统,J0B2才可以开始执行,并且J0B2会从外部存储系统读取JOBl产生的中间结果然后进行计算工作。HIVE的缺点显而易见,其底层采用MapReduce计算模型,对于每两个MapReduce计算任务之间的数据共享,只能将其中一个计算任务的结果输出到外部存储系统(分布式文件系统或者本地文件系统),后一个计算任务从外部存储系统读取数据进行计算,导致大量的磁盘I/O,以至于整个查询过程延迟较高。
[0005]Spark-SQL是另外一种数据仓库工具,和HIVE功能类似,但是Spark-SQL底层采用Spark计算模型而不是MapReduce计算模型。对于SQL语句SELECT c_custkey FROMcustomer JOIN nat1n ON customer.C_NAT10NKEY = nat1n.N_NAT10NKEY JOINlineitem ON Iineitem.L_PARTKEY= customer.C_CUSTKEY,Spark-SQU^—次SQL查询计划和任务执行流程如图2所示。Stage I主要用来处理查询计划中的ScanTable (lineitem)和ScanTable(customer),分别对应RDDl和RDD2。由于RDD为分布式弹性数据集,对应多个物理节点,每个物理节点会执行对应的任务,所以一个RDD由多个并行执行的Task(任务)得到,例如RDDl就由Taskl-1、Taskl_2计算得到。读取完I inei tem表和customer表内容后,Stage2主要用来处理Joinl操作和ScanTable (nat1n)操作,分别生成RDD3和RDD4。最后,Stage3用来完成Join2操作。Spark-SQL在计算延迟上相对于HIVE要快很多,但是依然存在一些缺点。[000?] 其一在于Spark-SQL底层采用scala语言实现,整体运行在Java虚拟机上,其内存管理机制依赖于Java虚拟机。而Java虚拟机内存管理机制是一种通用的内存管理机制,在数据库查询引擎中,没有针对数据库查询引擎做定制化的内存优化,导致Spark-SQL在计算过程中消耗大量的内存空间。
[0007]其二在于Spark-SQL任务执行过程中按照阶段顺序执行,如Stage2开始执行的前提条件是Stage I执行完成,Stage3执行的前提条件是Stage2执行完成。每个Stage包含若干个可并行执行的Task(任务),每个Stage的执行延迟由该Stage中执行时间最长的Task决定。由此产生一个问题,执行快的Task完成之后会等待同一Stage中其他未执行完成的Task,待同一Stage中所有任务执行完成之后,下一Stage中的Task才可以开始执行。例如,Taskl-l、Taskl-2、Task2-l 以及Task2-2在Stagel 中,Task3-1 和Task3-2在Stage2中,Task3-2依赖于Taskl-1、Taskl-2以及Task2-1 的计算结果。如果Taskl-1、Taskl-2以及Task2_l任务执彳丁完成而Task2_2未执彳丁完成,那么即使Task3_l满足执彳丁条件,在Spark计算框架的约束条件下,Task3_l仍然不能开始执行,需要等到Task2_2执行完成之后才开始执行。若Task2-2执行时间太长,则会影响整个计算过程的计算延迟。

【发明内容】

[0008]本发明所要解决的是现有数据库查询引擎计算效率低的问题。
[0009]本发明通过下述技术方案实现:
一种分布式内存列式数据库的查询引擎系统,包括资源管理模块、至少一个主查询引擎以及至少一个从查询引擎;所述主查询引擎用于将SQL语言转换为查询计划,将查询计划分割成至少两个子任务,并负责监控和调度查询计划的执行过程;所述从查询引擎用于执行所述主查询引擎分配的子任务;所述资源管理模块用于负责系统资源的管理和分配。
[0010]可选的,所述系统资源包括CPU计算资源和内存资源。
[0011]基于上述分布式内存列式数据库的查询引擎系统,本发明还提供一种分布式内存列式数据库的查询方法,包括:资源管理模块确定一个主查询引擎负责与用户之间的会话;主查询引擎将用户发送的SQL语言转换为查询计划;资源管理模块为主查询引擎分配从查询引擎,并建立从查询引擎与主查询引擎之间的通信;主查询引擎将查询计划分割成至少两个子任务,并为每个子任务分配从查询引擎;从查询引擎将子任务添加到任务队列,在当前子任务的前驱子任务全部执行完成后执行当前子任务,将当前子任务执行完成产生的中间数据传输至后继子任务所在的从查询引擎,并将当前子任务完成状态发送至主查询引擎;在整个查询计划完成后,主查询引擎通知客户在从查询引擎获取最终结果数据。
[0012]本发明将查询计划分割为若干有依赖关系的子任务,并将子任务分配至相应的从查询引擎的任务队列中,由从查询引擎依次执行任务队列中的子任务,而不会出现在Spark-SQL中,后一阶段中某个任务虽然满足可执行条件,却由于Spark-SQL执行框架的限制,而不能开始执行计算任务的缺点。因此,采用本发明提供的分布式内存列式数据库的查询方法,可以得到良好的查询效率。
[0013]可选的,子任务采用物理算子表示,所述物理算子包括提取列数据操作、连接操作、条件过滤操作、分组操作、聚合函数操作、排序操作以及将最终结果数据还原成行表的操作中的至少一种。
[0014]可选的,主查询引擎根据代价模型为每个子任务分配从查询引擎。采用代价模型为每个子任务分配从查询引擎,可以为每个子任务分配执行代价最小的从查询引擎,从而进一步提高查询效率。
[0015]可选的,主查询引擎根据代价模型为每个子任务分配从查询引擎包括:根据从查询引擎的元数据信息获取从查询引擎所在节点的IP以及该节点存储的数据库表信息和列信息;根据数据本地化原则分配查询计划中每项提取列数据操作的执行节点IP;采用贪心算法选取非提取列数据操作的执行节点。
[0016]可选的,每个子任务的状态包括等待执行状态、正在计算状态、分发数据状态、执行完毕状态以及执行失败状态。
[0017]可选的,当前子任务的初始状态为等待执行状态,在当前子任务所在从查询引擎收到当前子任务所有前驱子任务执行完成产生的中间数据后,将当前子任务的状态改为正在计算状态;当前子任务计算完成后,将当前子任务的状态改为分发数据状态,并将计算产生的中间数据发送至后继子任务所在的从查询引擎;若中间数据发送成功,将当前子任务的状态改为执行完毕状态;若等待执行状态与正在计算状态之间、正在计算状态与分发数据状态之间或者分发数据状态与执行完毕状态之间出现故障,将当前子任务的状态改为执行失败状态;在当前子任务的状态发生改变时,异步通知主查询引擎。
[0018]可选的,从查询引擎之间传输的中间数据为经过压缩处理的列数据。在传统数据库执行引擎中,中间数据按表的形式出现,数据存储按照行来存储,然而在大部分分析型业务场景下,用户仅关系一个关系表中的若干属性,采用行存储的方式在计算过程中会额外加载用户所不关心的属性数据,从而造成内存的浪费,采用列存储的方式很好地解决了这一问题。
[0019]可选的,所述压缩处理包括位压缩处理和字典压缩处理。采用字典压缩处理以及位压缩处理的方式可以进一步降低内存开销,提高内存的使用效率。
[0020]本发明与现有技术相比,具有如下的优点和有益效果:
本发明提供的分布式内存列式数据库的查询引擎系统及查询方法,通过异步调度每个子任务的执行提高整体运算效率,即将查询计划分割为若干有依赖关系的子任务,并将子任务分配至相应的从查询引擎的任务队列中,由从查询引擎依次执行任务队列中的子任务。进一步,从查询引擎之间传输的数据为经过压缩处理的列数据,解决采用行存储的方式在计算过程中额外加载用户所不关心的属性数据而造成内存的浪费问题。
【附图说明】
[0021]此处所说明的附图用来提供对本发明实施例的进一步理解,构成本申请的一部分,并不构成对本发明实施例的限定。在附图中:
图1是HIVE的一次SQL查询计划和任务执行流程示意图; 图2是Spark-SQL的一次SQL查询计划和任务执行流程示意图;
图3是本发明实施例的分布式内存列式数据库的查询引擎系统的部分结构示意图;
图4是本发明实施例的一次SQL查询计划示意图;
图5是本发明实施例的任务执行流程示意图;
图6是本发明实施例的子任务的执行状态转换示意图;
图7是本发明实施例的从查询引擎之间传输数据的示意图。
【具体实施方式】
[0022]为使本发明的目的、技术方案和优点更加清楚明白,下面结合实施例和附图,对本发明作进一步的详细说明,本发明的示意性实施方式及其说明仅用于解释本发明,并不作为对本发明的限定。
实施例
[0023]本实施例提供一种分布式内存列式数据库的查询引擎系统,所述分布式内存列式数据库的查询引擎系统包括资源管理模块、至少一个主查询引擎以及至少一个从查询引擎。
[0024]具体地,所述主查询引擎通过解析SQL语言将SQL语言转换为查询计划,将查询计划分割成至少两个子任务后分发给所述从查询引擎执行,并负责监控和调度查询计划的执行过程以及容错处理。与现有技术中类似,查询计划用树状结构表示。所述从查询引擎用于执行所述主查询引擎分配的子任务,所述资源管理模块用于负责系统资源的管理和分配。进一步,所述系统资源包括CPU计算资源和内存资源。图3是本实施例的分布式内存列式数据库的查询引擎系统的部分结构示意图,主查询引擎31对应三个从查询引擎:从查询引擎32、从查询引擎33以及从查询引擎34。
[0025]本实施例还提供基于上述分布式内存列式数据库的查询引擎系统的分布式内存列式数据库的查询方法,包括:
步骤SI,资源管理模块确定一个主查询引擎负责与用户之间的会话。具体地,在用户有查询需求时,资源管理模块在资源池中创建一个主查询引擎负责与用户之间的会话。
[0026]步骤S2,主查询引擎将用户发送的SQL语言转换为查询计划。主查询引擎通过词法解析和语法解析,并基于规则的查询优化,将SQL语言转换成为查询计划。与现有技术中类似,查询计划用树状结构表示。
[0027]步骤S3,资源管理模块为主查询引擎分配从查询引擎,并建立从查询引擎与主查询引擎之间的通信。在将SQL语言转换成为查询计划后,主查询引擎向资源管理模块申请计算资源,资源管理模块分配从查询引擎给主查询引擎,并建立从查询引擎和主查询引擎之间的网络连接。
[0028]步骤S4,主查询引擎将查询计划分割成至少两个子任务,并为每个子任务分配从查询引擎。由于本实施例中查询引擎面向的是分布式内存列式数据库,数据表在分布式列数据库中按列存储,并且每一列根据值范围被切割成若干分片。针对这一特性,本实施例抽象出了若干物理算子,用来表示查询计划中某一个具体的子任务。所述物理算子包括提取列数据操作、连接操作、条件过滤操作、分组操作、聚合函数操作、排序操作以及将最终结果数据还原成行表的操作中的至少一种。
[0029]提取列数据操作:S卩GetColumn算子,负责提取列数据库中某一列的数据,GetColumn算子本身可以附加限制条件,例如GetColumn(Teacher.age Teacher.age > 1),表示提取Teacher表的age列,并且age值大于I。
[0030]连接操作:即Join算子,负责执行Join运算,包括Left Join,Right Join,FullJoin 等。
[0031]条件过滤操作:S卩Filter算子,负责执行条件过滤操作,主要包括AND和OR等逻辑运算。
[0032]分组操作:S卩GroupBy算子,负责执行GroupBy分组操作,用于满足SQL语句中GroupBy关键字的功能。
[0033]聚合函数操作:即AGG算子,包括Max(求最大值),Avg(求平均值)等数据库常用操作。
[0034]排序操作:S卩Order算子,用于对需要排序的列进行排序操作。
[0035]最终结果数据还原成行表的操作:S卩BuildRow算子,用于将列数据库最终结果数据还原成用户可以理解的行表,将最终结果以关系表的形式展现给用户。
[0036]举例说明,一条具体的SQL语句SELECTc_custkey FROM customer JOIN nat1nON customer.C_NAT1NKEY = nat1n.N_NAT1NKEY JOIN lineitem ON lineitem.L_PARTKEY= customer.C_CUSTKEY,经过主查询引擎解析生成的查询计划如图4所示,分割成的子任务如图5所示,包括六个从查询引擎:从查询引擎Slave-QEl、从查询引擎Slave-QE2、从查询引擎Slave_QE3、从查询引擎Slave_QE4、从查询引擎Slave_QE5以及从查询引擎Slave-QE6o
[0037]假设每个列均有两个分片,那么针对每一个列的分片上都有一个GetColumn算子,由于每个列的分片有值域范围,那么针对每个分片也会产生基于该分片范围的Join算子。参考图5,如1111节点表示列1^?41?1'1^¥与(:_^51'1^¥的等值连接操作,在实际的子任务中,Joinl被拆分成两个具体的物理算子,Joinl-1和Joinl-2,分别负责值域范围在1-100和值域范围在101-150的等值Join操作。依次类推,查询计划中Join2也被拆分为两个具体的Join算子。
[0038]进一步,本实施例中主查询引擎是根据代价模型为每个子任务分配从查询引擎。具体地,主查询引擎根据从查询引擎的元数据信息获取从查询引擎所在节点的IP以及该节点存储的数据库表信息和列信息。根据数据本地化原则分配查询计划中每项提取列数据操作的执行节点IP。例如在图5中,从查询引擎Slave-QEl所在物理节点存储L_PARTKEY列的分片数据,那么针对该分片数据的GetColumn算子就分配到从查询引擎Slave-QEl所在物理节点上执行。依次类推,每一个分片的Ge tCo Iumn算子的执行节点均在对应数据所在的节点执行。对于非GetColumn算子执行节点的选取采用贪心算法,非GetColumn算子执行节点在其儿子算子节点的执行节点中选取,分别计算在每个儿子算子节点物理节点上执行的执行代价,选择执行代价最小的物理节点执行。原则依据代价计算公式:执行代价=网络代价+计算代价=节点间网络负载X传输数据量+节点任务负载X计算数据量。在图5中,Joinl-1算子执行节点要么在从查询引擎Slave-QEl,要么在从查询引擎Slave-QE3,这里选择从查询引擎Slave-QEl作为执行节点的依据就是通过分别计算Joinl-1算子在从查询引擎Slave-QEl节点上的执行代价和在从查询引擎SlaveQE-3节点上的执行代价,计算确定在从查询引擎Joinl-1上执行代价更小,所以最终的执行物理节点选择为从查询引擎Slave-QEl。
[0039]步骤S5,从查询引擎将子任务添加到任务队列,在当前子任务的前驱子任务全部执行完成后执行当前子任务,将当前子任务执行完成产生的中间数据传输至后继子任务所在的从查询引擎,并将当前子任务完成状态发送至主查询引擎。具体地,每个子任务包括等待执行状态、正在计算状态、分发数据状态、执行完毕状态以及执行失败状态这五种状态,并且每个子任务会维护该子任务的前驱子任务列表和后继子任务列表,每个子任务的执行状态转换图如图6所示。
[0040]以图4所示的Joinl-1算子为例,其前驱算子列表为GetColumn(L_PARTKEY SliceI [1-100]),GetColumn (C_CUSTKEY Slice I [ 1-150]),其后继算子列表为Join2_l算子。Joinl-1算子初始状态为等待执行,当Joinl-1算子所在物理节点收到其所有前驱算子发送来的数据之后,Joinl-1算子状态改为正在计算,Joinl-1算子计算完成之后,将当前算子改为分发数据,并且将计算结果数据通过网络发送给后继算子所在的从查询引擎。数据发送成功,当前算子任务执行完成。若其中某一步出现故障,即等待执行状态与正在计算状态之间、正在计算状态与分发数据状态之间或者分发数据状态与执行完毕状态之间出现故障,算子状态会被置为执行失败。当然,Joinl-1算子状态每发生一次变化,都会实时的向主查询引擎汇报当前算子状态。每个算子的执行是相互独立的,每个算子执行过程中,状态一旦发生改变,就会异步通知主查询引擎,并将结果数据推送给后继算子所在的执行物理节点。通过这种方式,子任务的执行完全依赖于前驱子任务是否完成,而不需要像Spark或者MapReduce—样,分阶段去执行任务。
[0041]在步骤S5中,从查询引擎与从查询引擎之间传输的中间数据为经过压缩处理的列数据,采用压缩处理方法包括位压缩处理与字典压缩处理,以图7所示的数据结构为例,中间数据包含三个向量,即字典向量、偏移量向量和位置向量。字典向量对原始数据进行排序,然后去重处理,将冗余的数据丢弃,节省内存存储空间。至于偏移量向量和位置向量,由于这两个向量里面存储的均为整数,这里采用位压缩策略。在计算机中,一个INT型占四个字节,S卩32bit,可表示的数据范围在-2147483648?2147483647,对于图7所示的偏移量向量和位置向量,向量中整数的最大值可以确定下来。所以在大多数情况下,存储一个数字用不了 32bit。假设偏移量向量或者位置向量中整数的最大值为A,那么存储一个数字所用的比特数为log2A向上取整,对比传统采用INT型或者LONG型变量来存储整数,采用这种方式更加节省内存。
[0042]步骤S6,在整个查询计划完成后,主查询引擎通知客户在从查询引擎获取最终结果数据。至此,完成整个查询工作。
[0043]以上所述的【具体实施方式】,对本发明的目的、技术方案和有益效果进行了进一步详细说明,所应理解的是,以上所述仅为本发明的【具体实施方式】而已,并不用于限定本发明的保护范围,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
【主权项】
1.一种分布式内存列式数据库的查询引擎系统,其特征在于,包括资源管理模块、至少一个主查询引擎以及至少一个从查询引擎; 所述主查询引擎用于将SQL语言转换为查询计划,将查询计划分割成至少两个子任务,并负责监控和调度查询计划的执行过程; 所述从查询引擎用于执行所述主查询引擎分配的子任务; 所述资源管理模块用于负责系统资源的管理和分配。2.根据权利要求1所述的分布式内存列式数据库的查询引擎系统,其特征在于,所述系统资源包括(PU计算资源和内存资源。3.—种基于权利要求1或2所述的分布式内存列式数据库的查询引擎系统的分布式内存列式数据库的查询方法,其特征在于,包括: 资源管理模块确定一个主查询引擎负责与用户之间的会话; 主查询引擎将用户发送的SQL语言转换为查询计划; 资源管理模块为主查询引擎分配从查询引擎,并建立从查询引擎与主查询引擎之间的通信; 主查询引擎将查询计划分割成至少两个子任务,并为每个子任务分配从查询引擎; 从查询引擎将子任务添加到任务队列,在当前子任务的前驱子任务全部执行完成后执行当前子任务,将当前子任务执行完成产生的中间数据传输至后继子任务所在的从查询引擎,并将当前子任务完成状态发送至主查询引擎; 在整个查询计划完成后,主查询引擎通知客户在从查询引擎获取最终结果数据。4.根据权利要求3所述的分布式内存列式数据库的查询方法,其特征在于,子任务采用物理算子表示,所述物理算子包括提取列数据操作、连接操作、条件过滤操作、分组操作、聚合函数操作、排序操作以及将最终结果数据还原成行表的操作中的至少一种。5.根据权利要求4所述的分布式内存列式数据库的查询方法,其特征在于,主查询引擎根据代价模型为每个子任务分配从查询引擎。6.根据权利要求5所述的分布式内存列式数据库的查询方法,其特征在于,主查询引擎根据代价模型为每个子任务分配从查询引擎包括: 根据从查询引擎的元数据信息获取从查询引擎所在节点的IP以及该节点存储的数据库表信息和列信息; 根据数据本地化原则分配查询计划中每项提取列数据操作的执行节点IP; 采用贪心算法选取非提取列数据操作的执行节点。7.根据权利要求3所述的分布式内存列式数据库的查询方法,其特征在于,每个子任务的状态包括等待执行状态、正在计算状态、分发数据状态、执行完毕状态以及执行失败状??τ O8.根据权利要求7所述的分布式内存列式数据库的查询方法,其特征在于,当前子任务的初始状态为等待执行状态,在当前子任务所在从查询引擎收到当前子任务所有前驱子任务执行完成产生的中间数据后,将当前子任务的状态改为正在计算状态;当前子任务计算完成后,将当前子任务的状态改为分发数据状态,并将计算产生的中间数据发送至后继子任务所在的从查询引擎;若中间数据发送成功,将当前子任务的状态改为执行完毕状态;若等待执行状态与正在计算状态之间、正在计算状态与分发数据状态之间或者分发数据状态与执行完毕状态之间出现故障,将当前子任务的状态改为执行失败状态;在当前子任务的状态发生改变时,异步通知主查询引擎。9.根据权利要求3所述的分布式内存列式数据库的查询方法,其特征在于,从查询引擎之间传输的中间数据为经过压缩处理的列数据。10.根据权利要求9所述的分布式内存列式数据库的查询方法,其特征在于,所述压缩处理包括位压缩处理和字典压缩处理。
【文档编号】G06F17/30GK105824957SQ201610193220
【公开日】2016年8月3日
【申请日】2016年3月30日
【发明人】段翰聪, 王瑾, 闵革勇, 聂晓文, 郑松, 张博
【申请人】电子科技大学
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1