《GPU 数据库核心技术综述》论文学习

原创

喜欢打篮球的普通人 2023-03-07 09:10:50 博主文章分类：数据库系统原理 ©著作权

文章标签 数据库人工智能 database 数据核函数 文章分类 jQuery 前端开发

©著作权归作者所有：来自51CTO博客作者喜欢打篮球的普通人的原创作品，请联系作者获取转载授权，否则将追究法律责任

文章目录

一、背景
二、GPU 数据库分类与层次

1.商用型C-GDBMS 中分为3类
2.研究型R-GDBMS

三、查询编译器

1.GDBMS编译模型
2.GPU数据处理模型

四、查询处理器

1.GPU关系代数和并发原语
2.复杂关系算子
3.空间数据查询
4.KBE查询执行引擎
5.GPU事务处理

五、查询优化器

1.代价模型

1.GDBMS 代价模型之难
2.算子代价估计的方法
3.算子的选择率估计

2.查询重写
3.异构计算任务队列
4.真实GDBMS系统中的优化器

六、存储管理

1.GDBMS数据存储体系
2.GPU数据压缩
3.GPU索引技术

一、背景

1.GPU性能极高

GPU 与 CPU 具有不同的体系结构和处理模式,将更多的片上空间用于计算单元,控制单元和缓存单元相对很少,使得单块 GPU 上拥有数千个并发计算核心。因此,在同样的主频下,GPU 能够取得更高的并发计算能力,也使 GPU 具有满足大数据处理需求的巨大潜能。
在时空数据 OLAP 分析任务和结果的可视化展示方面,几十个 GPU 的 GPU 数据库可以取得近千台普通 CPU 服务的数据库处理能力,而其响应时间甚至更短。

2.GPU数据库功能上日趋完善

基于商务智能 BI 的可视化交互式图表查询界面支持标准 SQL 查询语言，往往只要几分钟就可以完成以往数天乃至一周的工作。
GoAI(GPU open analytics initiative,GPU 开放分析计划)产业联盟和 GPU 数据帧(GPU data frame,GDF)构建了数据库库和人工智能应用程序之间数据交换标准,使数据科学家可以停留在 GPU 上的同时探索数据,训练机器学习算法并构建人工智能应用程序。

GPU数据库领域的核心研究内容：

查询编译器(query compilation)：将用户的 SQL 语言描述的查询需求转化为 CPU- GPU 异构计算环境下的查询计划;
查询处理器(query processing)：应用 GPU 并行计算技术实现关系型数据处理的各种算子,挖掘 GPU 峰值计算能力;
查询优化器(query optimizer)：用机器学习乃至人工智能技术,结合 CPU-GPU 异构计算环境和查询计划特点以及数据分布特征,生成最优(次优)的异构查询计划;
存储管理器(memory management)：需要在异构数据存储管理、数据存储格式、数据压缩、数据访问等问题上做出决策

二、GPU 数据库分类与层次

GDBMS(GPU database management system or GPU accelerated database management system，使用 GPU 进行或加速数据增删改查的数据库管理系统)。

分为研究型R-GDBMS: for research和商用型C-GDBMS: for commercial

《GPU 数据库核心技术综述》论文学习_数据库

1.商用型C-GDBMS 中分为3类

第 1 类是支持 GPU 计算的传统数据库.
这类 GDBMS 在已有传统数据库基础之上,将特定算子部署到GPU 上用以加速的查询处理,包括以 PostgreSQL 为基础的 PG-Storm 系统和 DB2 的扩展模块 DB2 BLU.
这类数据库与现有数据库集成度高、周边工具完善、且具有一定的与 OLTP 系统集成的能力;

第 2 类是非内存型 GDBMS,

使用 GPU 完成全部或者大部分数据库关系运算,可以分析超过 10TB 的数据量,包括 SQream 和 BlazingDB;

第 3 类是内存型 GDBMS,

该类系统将数据全部驻留内存,以发挥 GPU 的全部潜在性能、提高数据处理速度,可以处理 1TB~10TB 的较小数据集,包括 OmniSci(原 MapD),Kinetica(原 GPUDB),MegaWise,
Brytlyt

以一台普通服务器配备多个 GPU 显卡就能取得分布式大数据系统一个集群的处理能力.超大吞吐量、超低时延以及更低的成本,让 GDBMS 在 OLAP 业务上优势明显

2.研究型R-GDBMS

研究原型 GDBMS 将重点放在了全 GPU 计算上，DB的数据数据可以在 GPU 显存上存储的情况下,GPU 加速所能获得的最高性能.根据支持显卡厂商,可分为专用 GDBMS （因为使用 CUDA 而只能在
Nvidia 显卡上运行）和通用 GDBMS（后者使用 OpenCL,在 Nvidia 卡和 AMD 卡上都可以运行）。

三、查询编译器

• 首先,查询编译器需要利用 CUDA\OpenCL 编译工具生成 GPU 可执行代码,同时要创新 SQL 编译模式,尽可能减少 SQL 编译的开销,使整体的性能最优;

• 其次,传统的“火山模型”不适合 GPU 计算,GDBMS 查询编译器面临着关系数据处理模式的变化,需要将向量化(vector-wise)、一次一算子(operator-at-a-time)和批量执行(bulk processing model)这 3 种策略结合起来
（1）向量化，原指将多个关系型数据以向量形式作为一个 SIMD(single instruction multiple data)指令的多个操作数来处理的方法,可以有效提高查询处理吞吐量.
（2）在 GPU 中,向量化思想可以用 GPU的单指令多线程(single instruction multiple thread,简称 SIMT)进一步加大数据处理的吞吐量;
（3）“一次一算子”与“一次一数据”是数据处理的两种模式:
前者就是先将所有数据同时完成第 1 个算子的处理,并保存中间结果,作为下一个算子的输入数据,直至全部处理完;
而后者是指先让一条数据经过所有算子计算得出结果,再计算下一条数据的策略,是基于 CPU 计算常采用的策略;
（4）批量执行就是尽可能一批处理更多的数据,通过提高单次处理数据的数量,弥补处理频次不高的缺点;

GDBMS 借鉴了 CPU 计算中的向量化、 “一次一算子”、批量执行这 3 种策略,并使之适应 GPU 大规模并发计算的特点

1.GDBMS编译模型

DBMS 大多采用解释型的 SQL 前端

通过语法解析、语义解析模块将查询query解析为，可为查询执行引擎使用的内部任务表示，即逻辑执行树

GDBMS 查询编译器采用 3 种不同的编译模型来解决异构环境下 SQL 编译难题,即 JIT 代码生成(并发原语)、 SQL 虚拟机和适配器模式

基于底层虚拟机(LLVM)编译器框架来即时编译 SQL 代码（预编译并发原语），是目前 GDBMS 系统编译器实现的主流方法。
（1）该方法使用基于 LLVM[32]的 nvcc 编译器，将关系算子分为更小的原语 primitives，并把原语预编译为架构无关汇编代码 PTX，在运行时，由编译器只需完成 SQL 语言到算子的编译工作；
（2）查询执行器在优化器指导之下完成算子到并发原语的映射。
虚拟机模式
优点：将 SQL 编译为操作码(opcode)作为中间表示,将整个 DB 系统视为一个虚拟机,Opcode 操作码对应的算子被预编译为cudabin 可执行代码,直接发送到 GPU 端执行（CUDA 编译器由google提出）。
缺点：虚拟机模式放弃了SQL 优化的机会,无法提供查询重写、基于代价的优化;
适配器模式
GPUDB 编译器直接使用代码生成模块,将 SQL 直接编译为 CUDA 或 OpenCL 驱动能执行的代码，以算子为单位进行即时编译，适配器模式在运行时的编译负载会比较高。

2.GPU数据处理模型

,从数据处理模型来看,可分为 3 种:

迭代模式(iteration)
改进版的火山模型，如增加每次迭代的数据量、使用 SIMD 指令一次处理多个数据、推拉结合的数据获取方式等
批量模式(batching)
将每个查询编译为可执行代码，采用完全物化的方式处理所有数据。
但在实现 ad-hoc 查询上,面临灵活度不够、物化存储空间要求过高的问题。
二者的混合
比如微批量化查询处理.该类方案使用不同的粒度作为数据处理的单元,仍然在逻辑上组织成树型结构,让数据自底向上流动完成查询操作,兼具迭代模型的灵活性和批处理的高吞吐量的优点

GDBMS 普遍采用向量化一次一算子数据处理模式,并以此改造查询编译器，原因如下：

首先,迭代模式并不适合 GDBMS,因为火山模型赖以存在的虚函数机制因为 GPU 缺乏对应的复杂逻辑控制模块,在 GPU 上不可实现或者引起严重的线程分支恶化问题。
GPU应采取的操作是：
将列数据细粒度分配给 GPU 线程,并用循环展开的方式,可有效减少控制指令总量,有效降低分支恶化的风险
列式处理更适合 GDBMS
一次一列来处理数据时,由于每列数据类型一致,可以用向量化方式处理,避免了分支判断劣化性能问题；
GDBMS 系统普遍采用列式处理模型[30],比如 Ocelot[13],CoGaDB[10]等
由于 GPU 的大规模并行编程模型依赖于对数据的并行处理,很多算法想在 GPU 上运行必须适应单指令多线程(SIMT)的编程范式,所以需要对关系算子进行并行化改造
“一次一算子”的数据处理模式就是:让数据在 GPU向量化算子间流动，每次采用完全物化的策略保存算子输出的中间结果，作为下一个算子的输入数据
为了降低物化代价，通过适当分区切分数据，采用数据流水化处理(pipelining data processing),有效提高数据处理并行度

四、查询处理器

GDBMS 查询处理引擎，接受处理查询编译器输出的查询计划树 QEP(query execution plan)并执行查询返回结果。

GDBMS 查询处理引擎面对的核心问题是：

功能上，如何利用 GPU 实现关系代数运算,即实现选择、投影、连接、聚合基本的关系算子,同时还需要实现的空间数据(geo-spatial data)处理、 OLAP 聚合查询等功能复杂的算子
在执行模式上，GPU 上执行的代码被称为 kernel 核函数，以核函数为基础的查询处理技术(KBE)是GDBMS 查询处理引擎的必然选择
（1）如何在 GPU 高并发SIMT 模式下以何种粒度切分关系查询树来最大化查询处理性能，是 GDBMS 面临的性能挑战
（2）GDBMS采用的策略：
在逻辑查询树级别，用 KBE 融合或切分的策略，提升 GPU 的资源利用率和查询并发度;
在算子级别，则采用了设计专门针对 GPU 优化的算子的方法，即数据并发原语的方法

1.GPU关系代数和并发原语

在 GPU 上实现选择、投影、连接等基本关系代数算子,是实现 GDBMS 数据库的基础。

.CUDA/OpenCL 赋予了程序员使用 C\C++代码控制 GPU 大规模并行环境的能力,简化了GDBMS 开发的难度,促进了GDBMS 的繁荣。
GDBMS使用分层设计，将关系代数功能拆解为算子层(operator)和原语层(primitives)两部分，设计了一系列的适应 GPU 计算的数据并行原语(primitives)。
如下所示是大部分的 GPU 并发原语
eg：比如:scatter 原语[43]通过分区散射操作,在每个 load-store 周期内处理一个分区的散射操作,增加了数据访问聚合读写；
很多算子映射成原语的单个或多个组合,能够充分利用 GPU 高并发计算能力.通过以上原语的排列组合,大部分简单的关系代数算子可以进行有效拆解.比如选择算子可以用 filter 原语实现,同时,filter 原语是由 map 原语、 prefix sum 原语和 scatter 原语实现的。

2.复杂关系算子

Join 算子

:GDBMS 在处理 Join 算子上比 CPU 方案效果好得多，这是由于 Join 算子是计算制约算子(compute-bounded)决定的
如何进一步优化GPU 上 Join 算子算法以及如何调整连接顺序(join-order problem)，仍是GDBMS 领域收益最高的研究热点之一

OLAP 聚集函数算子

聚集函数算子是又一个计算负载很高(compute-bounded)的关系代数算子,适合使用 GPU 加速。
在 OLAP 分析工作任务中,切片(slicing)、切块(dicing)、上卷(Roll-up)、向下钻取(drill-down)以及数据立方(cube)函数是OLAP 业务中经常用到的算子，结合
sum,average,maximum,minimum,median,count 等各类聚集函数，提供给用户

3.空间数据查询

在空间索引方面，将历史数据构建驻留GPU 的空间索引，能够处理大部分时空数据查询，是未来发展方向之一。

4.KBE查询执行引擎

在查询执行引擎实现方式上，由于 GDBMS 普遍采用的 CUDA\OpenCL 以核函数(kernel)为载体执行协处理器计算。

所以大部分 GDBMS 使用基于核函数(kernel based execution,简称 KBE)[40]的查询执行引擎
一种自然的实现 KBE 的方法就是将每个关系算子以一个 kernel 函数执行,大部分 GDBMS 基于此实现自己的查询处理引擎,比如 CoGaDB,MapD 等。
在此基础之上,已有研究在核函数的层次上进行合并融合或细致切分两种策略:
（1）针对数据量大或计算复杂的任务,通过将多个核函数融合(kernel fusion)到一起,共同完成查询处理;
（2）而对于相对简单的任务,则进一步切分核函数(mini-kernel),做到精细化管理,以合理利用 GPU 资源

核函数融合

优点：核函数融合技术通过增加 GPU 函数处理操作的数量来优先使用 GPU 资源,使得同样配置下更能发挥 GPU 高并发高速率的优势,同时减少核函数的数量,减低了系统调用和管理的开销,非常适合 GPU 多计算少逻辑控制的硬件特性
缺点：核函数融合技术并不能增加单位数据的计算强度,不能从根本上提高加速比;其次,核函数融合技术增加了单个核函数处理所需要的资源,以降低 GPU 资源重复利用率为代价;
最后,核函数融合技术目前还不能有效地跟查询优化器结合起来,如何有效融入真实 GDBMS 系统中是个未解之题

核函数切分

核函数切分能够以更精细的粒度管理 GPU 资源,使流水化成为可能,提高了资源利用率的同时,降低了单个核函数的运行周期,可以进一步提高查询并发度。
但是核函数切分是以更频繁的核函数调度为代价的,数据换入换出频率更高,受 PCIe 总线瓶颈影响更大,如果控制不当,很可能降低系统整体性能

小结

基于核函数的查询执行模式适应 GPU 编程的范式,是目前 GDBMS 采用的主流技术.该技术兼顾灵活性和实效性,通过将算子预编译为不同粒度的核函数,在运行时根据数据的规模启动不同维度的线程块(warp)执行查询,同时保留了进一步优化的空间
但是,基于核函数的执行策略还面临数据传输瓶颈的考验和核函数容易崩溃的问题,当数据超过一定限度或者中间结果物化代价过大超过显存容量时,需要引入全局的优化策略避免核
函数失败重做的代价.同时,KBE 策略普遍没有考虑数据规模的问题,依赖于在运行时启动多少核函数、分配多大显存的策略,在实践中,这样的策略往往过于复杂而采用全列运算来避归,付出了过大的计算代价.

5.GPU事务处理

如何在 GPU 上实现数据库事务的并发执行还是一个开放问题,需要在 GPU 并发控制算法、 GPU 数据高效获取、日志和故障恢复机制、 GPU 高效锁实现机制、乐观并发控制策略等方面进一步研究。

五、查询优化器

首先,如何建立 GDBMS 查询处理的代价模型

是查询优化的核心问题;其次,在代价模型指导下,构建适应 GPU 查询处理的启发式规则体系对查询树进行等价改写,是 GDBMS 优化器的重要问题；

再次,GDBMS 查询优化问题在一定程度上可以抽象为算子在何种类型的计算核心(CPU or GPU)上进行处理的问题

即算子分配问题,解决了算子分配问题,就能最大程度地发挥GDBMS 整体性能优势;

最后,如何在真实系统中设计实时高效的查询优化器，与数据库系统的其他模块协同工作，是制约 GDBMS 发展的关键问题

1.代价模型

代价是数据库内核对给定 SQL 任务执行成本的估计,在传统数据库中包括 CPU 执行代价和 IO 代价两部分

是逻辑查询计划向物理查询计划转化过程中选择最优物理执行计划的依据

下面介绍构建 GDBMS 代价模型所面临的挑战以及两种常用的采用代价估计方法

基于代码分析的“白盒方法”
基于学习的“黑盒方法”，并简要介绍算子选择率的估计方法

1.GDBMS 代价模型之难

SQL 优化过程可以分为逻辑优化和物理优化两个阶段:

在逻辑优化阶段
优化器根据关系代数等价定律、算子下推启发式规则、子查询重写等规则对逻辑执行计划进行改写,以得到执行代价更小的物理执行计划;
物理优化阶段
需要为逻辑查询计划中的算子选择特定的算法和数据访问方法，并选择其中代价最低的一条生成路径作为最终的查询计划；

传统磁盘为中心的数据库查询执行代价估计

以磁盘 IO 和 CPU 计算的加权平均和作为最终的查询执行代价

分布式数据库的代价估计

通信代价

内存数据库的代价估计

代价估计的重点是内存访问

造成 PCIe 总线数据传输开销成为了 GDBMS 代价估计的重点和难点的原因如下：

在 GDBMS 中,必须根据 tuple 计算的位置(在 CUP 中还是在 GPU 中)来分别计算其代价.在 GPU 中,计算的代价由于其速率更高所以必须乘以一个经验系数(比如 0.1);
GDBMS 中存储层次体系更加复杂——既包括传统的缓存-内存-硬盘三级存储管理,又包括主机内存与 GPU 设备内存的异构存储体系管理,这决定了 GDBMS 必须设计独有的、能够充分反映 GDBMS 存储特性的访存代价估计函数。
GDBMS 的性能瓶颈在于主机内存与 GPU 显存之间的数据拷贝，可以类比于分布式数据库中的网络通信开销,这也是在代价估计中必须考虑的最重要的因素.
其次，在多 GPU 环境的系统中，由于多 GPU 往往共享 PCIe 总线，因此多 GPU 下性能并不呈现简单的线性增长，而且与之相关的管理成本和决策空间也相应变大。

2.算子代价估计的方法

基于代码分析的方法认为,查询的执行取决于生成指令的代码，因此可以通过静态的代码分析方法将 GPU 上执行的关系代数算子的执行代价精确估计,包括传输代价、计算代价、传回代价及内存访问代价。

这种方法依赖于对每个算子的精确估计
缺点：
由于采用了静态的“白盒”分析的方法,只能针对算子级别进行分析,没有考虑多查询并发情况下算子之间的相互影响以及系统运行时
的负载情况，不可避免地将在运行时发生错误；
而且随着系统的进化,任何代码上的微小改动都将对代价估计产生影响，对代价估计模块的维护成本也随之增高，在扩展性和可维护性上面临巨大挑战

基于学习的方法将算子视作黑盒通过机器学习的方法,经过观测算子的过往行为,估计该算子的执行代价，并在运行时利用反馈机制修正算子代价.

这种方法在一定程度上避免了静态方法的一些问题,但同样不够完美:
首先，基于学习的方法需要一定的训练过程,这在实际生产环境下面临冷启动缺乏基础统计数据的问题，造成优化器可发挥作用的时效性低，切换任务后面临新的“训练空窗期”；
其次，基于学习的方法对算子代价的估计是不精确的
执行计划的代价估计需要考虑的空间过大,很难在训练阶段穷举所有的情况,这就造成了对算子代价的估计模型的训练上面临训练样本空间和测试样本空间不重叠、训练样本过少的问题,模型必然存在精度不高的问题
最后,现有基于学习的方法没有考虑多显卡、多计算节点分布式的应用场景,低估了 PCIe 总线瓶颈的影响.

3.算子的选择率估计

对于一个特定的关系算子来说,基数估计(cardinality estimation)就是对算子运行前后数据的变化量评估的技术。

选择率是指满足算子条件的数据数量与数据总量之间的比值。
算子选择率的精确估计对中间结果大小估计、算子代价估计、最优 join 顺序等都有重要影响，不但直接决定了优化器的准确性，甚至对 GPU 内存管理产生直接影响
目前最好的解决方案是基于抽样的柱状图方法，即等宽或等值地抽取数据，事先建立多区间的统计条形图，查询时，结合查询条件及柱状图信息估计算子的选择率

2.查询重写

查询重写是指优化器对逻辑查询树等价变形，以达到提高查询效率的目的。

目前的研究主要致力于改进 Join 算子的性能和合理消减 copy 算子来控制数据 PCIe 总线传输总量上。
join算子改写
文献针对 SSBM 测试提出了 invisible join 技术,对星型模式下的事实表与多个维表外键连接(star join)进行优化。
该技术通过将 JOIN 重写为事实表上的多个 Select 操作,并用布尔代数将多个选择的结果合并,以减少后续 JOIN 阶段的整体数据量。
减少 copy 算子
对于查询优化,可以通过查询重写技术减少 copy 算子的数量为目标,来减少在 PCIe 上来回反复传输的数据量，从而提升性能
表连接的顺序是查询性能优化的关键.在现有的 GDBMS 中,各系统放弃了连接顺序的优化,采用确定性的查询计划构建方法，目前,多表连接顺序判定仍然是数据库优化领域开放问题之一,还没有一个可以利用GPU 加速该问题求解的成熟方案

3.异构计算任务队列

GDBMS 与传统 CPU 数据库的不同之处在于,可以利用 CPU-GPU 异构计算平台并行处理数据

为保证多个计算设备(CPU 和 GPU)处于“繁忙”状态，保证系统整体性能，给每个计算核心维护一个工作队列，根据启发式规则，将查询计划树中相互独立的算子分配给工作队列并发执行

4.真实GDBMS系统中的优化器

HyPE 优化器框架采用可移植分层设计,在很好地解决了查询性能预测(query performance prediction)和算子分配问题

该系统采用基于学习的方法,由 3 个部分组成:代价估计器(cost estimator,简称 STEMOD)、算法选择器(device-algorithm selector,简称 ALRIC)、异构查询优化器(hybrid query optimizer,简称 HOPE）

• 首先,在 HyPE 中,假设算子跟其处理的数据是一个整体 OP(A,D)，OP 表示算子、 A 表示使用的算法、 D表示处理的数据。
则物理执行计划可视为一个算子的流处理器；
对于逻辑执行树进行拓扑排序来序列化算子，消除算子间的数据依赖，保证每个算子执行时其子算子均已执行完毕；
• 其次,算子流中的算子依次经过优化器 HyPE 中,经由代价估计器(cost estimator,简称 STEMOD)，算法选择器(device-algorithm selector,简称 ALRIC)、异构查询优化器(hybrid query optimizer,简称HOPE)[70]，为特定算子选择合适的实现算法，并根据启发规则为算子分配合适的处理器

HyPE 的 3 个模块内部工作流程如图 4 所示

对于查询计划中的每个算子 O，在算法选择器中选出其对应的CPU\GPU 算法 A，经由代价估计器，以测试数据集 D 和算子的参数 P 运行机器学习算法，估计对应算法的代价，最后由异构查询优化器按照启发式规则选择最终的算法和执行计算核心，并将选择结果反馈给系统作为后续
尽管 HyPE 优化器基于机器学习的方法估计算子执行代价，并组合多种启发式规则选择算子的物理实现算法，但是将查询优化问题等价为在运行时处理算子分配问题的优化策略对 GDBMS 来说未必是最有效的

PG-Storm，brytlyt/BrytlytDB基于开源数据库 PostgreSQL，复用了 PostgreSQL 优化器模块。

通过计算 cost,在查询执行加护中插入适合的 GPU 算子(Join、 Scan、聚合等),将计算任务分配到 GPU 端加速,取得了较好的效果。
这种编译期静态分配的任务分配策略，避免了 HyPE 优化器在运行时决策算子分配问题的负载，可以取得确定性的性能提升

六、存储管理

传统的 DBMS 与 GDBMS 在存储管理器上存在以下不同.

第一，从功能上说,面向磁盘的数据库主要包括内存管理和外存管理两部分;而对于 GDBMS 来说,还增加了 GPU 显存管理的任务.如何充分发挥异构存储体系的性能优势,是 GDBMS 数据管理最核心的问题;
第二，压缩数据能够有效减少需要处理的数据总量，进而成比例增加 GDBMS 的性能。
如何在 GPU 异构显存体系下尽可能获得更大的压缩比,充满了挑战;
第三，索引能够加速以硬盘为中心的数据查询处理，但是在 GDBMS 大量物化的全量处理模型中是否还有存在的价值、如何发挥索引长处加速查询处理，也是 GDBMS 存储管理需要研究的重要问题.