1.本发明属于大数据数据仓库领域，涉及一种大数据数据仓库查询引擎性能提升的方法及装置，尤其是一种基于数据仓库的向量化设计与实现方法及装置。
背景技术：
：：2.随着数据库软硬件技术的发展，经典的sql计算引擎逐渐成为数据仓库的性能瓶颈，尤其是对于涉及到大量计算的数据仓库查询。3.经典的sql计算引擎中，expression(表达式)层面采用expressiontree来解析执行，sql中的filter(过滤)条件对应的expressiontree，如图1所示，基于expressiontree的解析执行往往使得一些看上去很简单的表达式执行起来很复杂，以sql的filter条件为例：c1《100andc4＝10这个filter条件在数据库中会被转换为包含7个节点的expressiontree，对于表中的每行数据，这7个节点的eval(评估)虚函数都会被触发一次。operator(操作符)层面采用的是火山模型，使用operatortree来解析执行，operator之间则通过迭代器来串联，这样sql在数据库中实际上会被编译为如图1所示的operatortree，火山模型虽然带来了实现简单和干净的好处，但是每次计算一行结果都会有一个很长的next(下一步)虚函数调用链，而且operatornext虚函数中一般还会有一个expressioneval虚函数调用链。虽然虚函数调用本身开销并不算特别大，但是仍需要花费一定的时间，而虚函数内部的操作可能就是一个简单的轻量级计算，但每一行数据都需要若干次的虚函数调用，当数据量非常大的时候，这个开销就会变得十分可怕。4.综上所述，经典的sql计算引擎无论是expression(表达式)还是operator(操作符)，其计算时都大量使用到虚函数，由于每行数据都需要经过这一系列的运算，导致计算框架开销比较大，而且由于虚函数的大量使用，也影响了编译器的优化空间。技术实现要素：5.为了解决经典的sql执行引擎在数据非常大的情况下执行效率低的问题，本发明提供一种基于数据仓库的向量化设计与实现方法及装置。6.为实现上述目的，本发明采用下述技术方案：7.在本发明一实施例中，提出了一种基于数据仓库的向量化设计与实现方法，该方法包括：8.在向量化执行引擎中，operator层面采用火山模型，按照一次处理一组元组的方式，使用operatortree来解析执行；9.在向量化执行引擎中，采用列储存结构；10.在向量化执行引擎中，实现hashagg算子和hashjoin算子的向量化。11.进一步地，通过引入低基数的全局字典，将两个基于字符串的操作转换为一个基于整数的操作。12.进一步地，hashagg算子的向量化实现如下：13.对输入的元组在分组列上批量计算hash值；根据计算出的hash值批量计算hashbucket值；14.构建hashtable，采用开放寻地址法的冲突处理方式，记录元组对应的hashentry；若内存占用超过内存限制，则将元组写入磁盘；15.计算聚合结果，并更新到对应的hashentry上；16.遍历hashtable输出聚合结果，扫描每一个hashentry，将聚合结果以及聚合列拼接成元组并返回；17.若存在下一组的元组，则重置当前已遍历结束的hashtable，重新构建下一组的hashtable并执行上述所有步骤，直至所有元组处理完毕。18.进一步地，hashjoin算子的向量化实现如下：19.对scan内表中的元组进行批量计算，得到hash值和hashbucket值；20.对scan内表构建hashtable；21.对scan外表中的元组批量计算hash值和hashbucket值；22.使用scan外表中的元组探测scan内表构建的hashtable，再进行批量的匹配，若匹配，则通过一个标记数组在对应位置上进行标记，若不匹配，则找到hashbucket的下一个位置继续进行匹配，直到匹配成功或者hashbucket链匹配结束；23.根据标记数组将匹配成功的行转换为对应的列输出。24.在本发明一实施例中，还提出了一种基于数据仓库的向量化设计与实现装置，该装置包括：25.向量化执行模块，用于在向量化执行引擎中，operator层面采用火山模型，按照一次处理一组元组的方式，使用operatortree来解析执行；26.向量化存储模块，用于在向量化执行引擎中，采用列储存结构；27.向量化算子实现模块，用于在向量化执行引擎中，实现hashagg算子和hashjoin算子的向量化。28.进一步地，通过引入低基数的全局字典，将两个基于字符串的操作转换为一个基于整数的操作。29.进一步地，hashagg算子的向量化实现如下：30.对输入的元组在分组列上批量计算hash值；根据计算出的hash值批量计算hashbucket值；31.构建hashtable，采用开放寻地址法的冲突处理方式，记录元组对应的hashentry；若内存占用超过内存限制，则将元组写入磁盘；32.计算聚合结果，并更新到对应的hashentry上；33.遍历hashtable输出聚合结果，扫描每一个hashentry，将聚合结果以及聚合列拼接成元组并返回；34.若存在下一组的元组，则重置当前已遍历结束的hashtable，重新构建下一组的hashtable并执行上述所有步骤，直至所有元组处理完毕。35.进一步地，hashjoin算子的向量化实现如下：36.对scan内表中的元组进行批量计算，得到hash值和hashbucket值；37.对scan内表构建hashtable；38.对scan外表中的元组批量计算hash值和hashbucket值；39.使用scan外表中的元组探测scan内表构建的hashtable，再进行批量的匹配，若匹配，则通过一个标记数组在对应位置上进行标记，若不匹配，则找到hashbucket的下一个位置继续进行匹配，直到匹配成功或者hashbucket链匹配结束；40.根据标记数组将匹配成功的行转换为对应的列输出。41.在本发明一实施例中，还提出了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现前述基于数据仓库的向量化设计与实现。42.在本发明一实施例中，还提出了一种计算机可读存储介质，计算机可读存储介质存储有执行基于数据仓库的向量化设计与实现计算机程序。43.有益效果：44.1、本发明的向量化执行引擎采用列存储结构，可以只读取必要的列数据，提高读取效率；可以使用压缩算法，得到更好的压缩比；可以使用列排序或者稀疏索引，加速数据的查询效率。针对向量化聚合查询的效果，测试查询少量和大量数据的执行结果，可以得出采用列存储结构的执行时间更短，数据量越大效果越明显，采用列存储结构的执行时间甚至可以缩短到采用行存储结构的执行时间的1/8。45.2、本发明的向量化执行引擎仍然采用火山模型，但是按照一次处理一组元组的方式，实现批量读取和批量处理，大大减少了虚函数调用开销，cpu可以把更多的时间集中到实际的计算上，效率会更高。46.3、本发明通过引入低基数的全局字典，将两个基于字符串的操作转换为一个基于整数的操作，可以将cpu周期减少一个数量级，使扫描、散列、相等和内存拷贝等操作的性能以及整体查询性能提高数倍，整体查询性能提高了300％以上。附图说明47.图1是本发明经典的sql计算引擎在expression层面和operator层面进行解析执行的示意图；48.图2是本发明基于数据仓库的向量化设计与实现方法架构图；49.图3是本发明向量化执行引擎的存储结构由行存储变为列存储的示意图；50.图4是本发明一实施例的hashagg算子的向量化实现示意图；51.图5是本发明一实施例的hashjoin算子的向量化实现示意图；52.图6是本发明一实施例的将两个基于字符串的组转换为一个基于整数的组的示意图；53.图7是本发明基于数据仓库的向量化设计与实现装置结构示意图；54.图8是本发明计算机设备结构示意图。具体实施方式55.下面将参考若干示例性实施方式来描述本发明的原理和精神，应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本发明，而并非以任何方式限制本发明的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。56.本领域技术人员知道，本发明的实施方式可以实现为一种装置、装置、节点、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。57.本发明的实施方式，提出了一种基于数据仓库的向量化设计与实现方法及装置，向量化执行引擎允许在每个运算符中使用simd同时处理多行数据，同时向量化执行以元组为单位处理数据，提高了cpu缓存的命中率，充分的利用了cpu和缓存等资源，可以扩展到其他应用领域，如数据挖掘和多媒体检索等。58.下面参考本发明的若干代表性实施方式，详细阐释本发明的原理和精神。59.图2是本发明基于数据仓库的向量化设计与实现方法架构图。如图2所示，该方法包括：60.1、向量化执行引擎61.(1)在向量化执行引擎中，operator层面仍然采用火山模型，使用operatortree来解析执行，火山模型的最大好处是实现简单，每个operator都只需要完成其自身特定的功能，operator之间是完全解耦合的，编译器只需要根据sql逻辑构造对应的operator，然后将operator串联起来即可。62.(2)在减小框架开销方面，使用均摊开销。若每次通过operatortree生成一行数据即一个元组的开销是c的话，经典的sql执行引擎的计算框架总开销就是c*n，其中n为参与计算的总行数；若将每次生成一行数据改为每次生成一批数据即一组元组的话，由于每次调用的开销是相对恒定的，因此计算框架的总开销就可以减小到c*n/m，其中m是每批数据的行数，这样每一行的开销就减小为原来的1/m，当m比较大时，计算框架的开销就不会成为系统瓶颈了。63.2、向量化存储结构64.(1)行存储65.如图3所示，每一个元组的每一列实际上是连续存储的，这样的优点是易于添加或者修改一个元组，但在读取数据时可能会额外读到不需要的列，比较适合于包含大量高并发增删改查事务的oltp(联机事务处理)场景。66.(2)列存储67.如图3所示，每一列是单独存储的，这样就可以只读取需要的列，元组的写入需要操作多个文件，比较适合于包含大数据量读取和复杂计算的olap(联机分析处理)场景。68.向量化执行引擎的存储结构采用列存储结构，只需要读取必要的列数据，提高列存的读取效率。通过snappy压缩算法(现有压缩算法)，列存能实现更好的压缩比。通过字典中列排序或者稀疏索引，加速数据的查询效率。同时这种列存储结构还为上层计算的性能优化提供了很大的便利。69.3、向量化执行实例70.向量化算子实现原则：一个是尽可能地将复杂的循环处理过程拆解成多个简单的小循环，以便批量地对同种类型的数据进行快速循环处理；另一个是减少分支以及数据依赖等。71.实现常见算子的向量化，比如在大数据数据仓库查询中，hashjoin(哈希连接)算子是sql最为核心的算子，实现hashjoin算子的向量化，join性能有一倍或者30-40％提升，若join数据量大的话，性能提升也是很明显的。同时实现交集、差集、crossjoin、scannode和窗口函数等。hashagg算子使用两个列进行分组并对每个组内进行count计算，包含两个步骤：一是构建hashtable并在每个hashentry上计算聚合结果；二是遍历hashtable，计算最终的聚合结果。向量化将这些操作可以通过简单的循环来进行批量处理，包括hash值和hashbucket值的计算，以及聚合结果的计算，可以显著提高计算的效率。72.下面以hashagg(哈希聚合)算子和hashjoin(哈希连接)算子为例，来实现向量化改造。73.(1)hashagg算子74.如图4所示，是一个简单的查询，两列做分组，再分别进行hashagg操作。75.具体改造过程如下：76.(a)对输入的元组在分组列上批量使用hash函数(现有技术)计算hash(哈希)值；根据计算的hash值批量使用hash函数(现有技术)计算hashbucket(哈希桶)值。77.(b)构建hashtable(哈希表)，采用open-addressing(开放寻地址法，现有技术)的冲突处理方式，记录元组对应的hashentry(哈希条目)，hashentry中有三个字段：hash、value和next，分别对应哈希值、元组和下一组元组哈希值；如果内存占用超过内存限制，则元组需要写入磁盘。78.hashtable(哈希表)构建如下：79.根据元组计算一个hash值；80.创建一个数组作为hashtable；81.确定元组在数组中的位置，根据hash值和数组的最大索引值进行与运算得到索引的位置；82.获取该位置是否有元组，若没有元组，直接把元组放在该位置；83.若有元组，判断元组是否完全相等，若相同，将该元组替换为当前元组；84.若有元组，但元组不完全相等，遍历此位置链表，将元组放在链表最后一位。85.(c)通过聚合函数算子计算，如sum、avg、count等，得到聚合结果，并将其更新到对应的hashentry上。86.(d)遍历hashtable输出聚合结果，扫描每一个hashentry，将聚合结果以及聚合列拼接成元组并返回。87.(e)若存在下一组的元组，则重置当前已遍历结束的hashtable，重新构建下一组的hashtable并执行上述所有步骤，直至所有元组处理完毕。88.(2)hashjoin算子89.选择常见的内连接进行向量化，以图5为例来介绍hashjoin算子向量化的过程。具体改造过程如下：90.(a)对scan内表(内连接的一张表)中的元组使用hash函数(现有技术)进行批量计算，得到hash值和hashbucket值。91.(b)对scan内表构建hashtable。92.(c)对scan外表(内连接的另外一张表)中的元组批量计算hash值和hashbucket值。93.(d)使用scan外表中的元组探测scan内表构建的hashtable，再进行批量的匹配(通过scan内外表的key来匹配)，若匹配，通过一个标记数组在对应位置上进行标记，若不匹配，需要找到hashbucket的下一个位置继续进行匹配，直到匹配成功或者hashbucket链匹配结束。94.(e)根据标记数组将匹配成功的行转换为对应的列输出，比如通过外表匹配的key找到对应的pc1。95.4、高效的数据结构和算法96.高效的数据结构和算法可以将cpu周期减少一个数量级，例如引入一个低基数的全局字典，可以将基于字符串的操作转换为基于整数的操作。如图6所示，通过操作将两个基于字符串的组转换为一个基于整数的组。97.需要说明的是，尽管在上述实施例及附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。98.基于同一发明构思，本发明还提出一种基于数据仓库的向量化设计与实现装置。该装置的实施可以参见上述方法的实施，重复之处不再赘述。以下所使用的术语“模块”，可以是实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。99.图7是本发明基于数据仓库的向量化设计与实现装置结构示意图。如图7所示，该装置包括：100.向量化执行模块101，用于在向量化执行引擎中，operator层面采用火山模型，按照一次处理一组元组的方式，使用operatortree来解析执行。101.向量化存储模块102，用于在向量化执行引擎中，采用列储存结构。102.向量化算子实现模块103，用于在向量化执行引擎中，实现hashagg算子和hashjoin算子的向量化。103.hashagg算子的向量化实现如下：104.对输入的元组在分组列上批量计算hash值；根据计算出的hash值批量计算hashbucket值；105.构建hashtable，采用开放寻地址法的冲突处理方式，记录元组对应的hashentry；若内存占用超过内存限制，则将元组写入磁盘；106.计算聚合结果，并更新到对应的hashentry上；107.遍历hashtable输出聚合结果，扫描每一个hashentry，将聚合结果以及聚合列拼接成元组并返回；108.若存在下一组的元组，则重置当前已遍历结束的hashtable，重新构建下一组的hashtable并执行上述所有步骤，直至所有元组处理完毕。109.hashjoin算子的向量化实现如下：110.对scan内表中的元组进行批量计算，得到hash值和hashbucket值；111.对scan内表构建hashtable；112.对scan外表中的元组批量计算hash值和hashbucket值；113.使用scan外表中的元组探测scan内表构建的hashtable，再进行批量的匹配，若匹配，则通过一个标记数组在对应位置上进行标记，若不匹配，则找到hashbucket的下一个位置继续进行匹配，直到匹配成功或者hashbucket链匹配结束；114.根据标记数组将匹配成功的行转换为对应的列输出。115.通过引入低基数的全局字典，将两个基于字符串的操作转换为一个基于整数的操作。116.应当注意，尽管在上文详细描述中提及了基于数据仓库的向量化设计与实现装置的若干模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多模块的特征和功能可以在一个模块中具体化。反之，上文描述的一个模块的特征和功能可以进一步划分为由多个模块来具体化。117.基于前述发明构思，如图8所示，本发明还提出一种计算机设备200，包括存储器210、处理器220及存储在存储器210上并可在处理器220上运行的计算机程序230，处理器220执行计算机程序230时实现前述基于数据仓库的向量化设计与实现方法。118.基于前述发明构思，本发明还提出一种计算机可读存储介质，计算机可读存储介质存储有执行前述基于数据仓库的向量化设计与实现的计算机程序。119.本发明提出的基于数据仓库的向量化设计与实现方法及装置，向量化执行引擎采用列存储结构，可以只读取必要的列数据，提高读取效率；可以使用压缩算法，得到更好的压缩比；可以使用列排序或者稀疏索引，加速数据的查询效率。针对向量化聚合查询的效果，测试查询少量和大量数据的执行结果，可以得出采用列存储结构的执行时间更短，数据量越大效果越明显，采用列存储结构的执行时间甚至可以缩短到采用行存储结构的执行时间的1/8。向量化执行引擎仍然采用火山模型，但是按照一次处理一组元组的方式，实现批量读取和批量处理，大大减少了虚函数调用开销，cpu可以把更多的时间集中到实际的计算上，效率会更高。通过引入低基数的全局字典，将两个基于字符串的操作转换为一个基于整数的操作，可以将cpu周期减少一个数量级，使扫描、散列、相等和内存拷贝等操作的性能以及整体查询性能提高数倍，整体查询性能提高了300％以上。120.虽然已经参考若干具体实施方式描述了本发明的精神和原理，但是应该理解，本发明并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本发明旨在涵盖所附权利要求的精神和范围内所包含的各种修改和等同布置。121.对本发明保护范围的限制，所属领域技术人员应该明白，在本发明的技术方案的基础上，本领域技术人员不需要付出创造性劳动即可做出的各种修改或变形仍在本发明的保护范围以内。当前第1页12当前第1页12