列式数据库和向量化
26 浏览量
2021-01-27
14:57:03
上传
评论
收藏 289KB PDF 举报
列式数据库和向量化列式数据库和向量化
要点
列式数据库有助于减少联机分析处理(OLAP)的负载，因为查询会涉及到列的一个子集，但这些列都有大量的行数。
列式存储格式使我们可以采用一些基于每列的轻量级压缩算法（lightweight compression algorithms） 。
向量化的数据处理通过有效使用CPU缓冲机制的方法，来开发更快速的分析查询引擎。
Arrow的列式数据结构允许使用轻量级方案，如字典编码（dictionary encoding）、位压缩（bit packing ），或是运行长度编
码（run length），这样在压缩比例一定时，可以提高查询性能。
列式数据库组织磁盘或内存中给定的连续列数据。基于列的存储方式，有助于减少联机分析处理(OLAP)的负载，因为查询会
涉及到列的一个子集，但这些列都有大量的行数。对于这类查询，使用列数据格式可以大大减少从磁盘到内存和从内存到寄存
器的数据转换。这样可以有效地提高整个存储体系的吞吐量。而且，列式格式让我们可以使用一些基于每列的轻量级压缩算
法。这种情况下，压缩算法性能会更好，因为压缩引擎的输入数据是同一类型数据，能够压缩的更好更快。
向量化处理自MonerDB-X100（Vectorwise）系统开始流行，现在已成为在现代硬件条件下构建高效分析查询引擎，进而加速
数据处理的标准。这种模式需要按列表示的数据来编写高效优化的查询处理算法。向量化的过程和传统的基于元组的查询过程
模式有着显著区别。 两种方法最主要的不同是，前者是基于列而不是基于行/元组来重写查询处理算法。连续存储的一列数
据，在内存中可以表示为一个向量，这个向量包含了该列中固定数目的一些值。
向量模式和传统模式的第二个不同是，我们可以添加一个块，而不是在查询计划树顶部一次添加一个元组。一个块由固定的一
组元组（记录）组成，它代表一组向量，这些向量和列/字段有一一对应的关系。向量块是数据的基本单元，它经由执行计划
树，从一个操作符流向另一个操作符。
图1：传统的一次添加一个元组的处理和向量化处理比较
在图1中，左侧图为传统的一次操作一个元组的处理流程。扫描运算符开始获取输入数据，并通过过滤运算符开始推动元组的
处理。接下来，过滤运算符传递符合条件的元组到聚合运算符。运算符不停调用查询计划树下层的下一个运算符。其结果就是
位于树下层的运算符把元组推向位于树顶的运算符。这就是查询的执行过程。
现在，由于有大量的函数调用，且每次函数调用时从一个运算符到另一个运算符需要处理或传输的数据不多，在这个执行过程
中，性能开销很大。其次，当仅需要处理元组里列的一个子集时，需要传递整个元组。
右侧的为一个向量模型，往该模型中添加一个向量块，每个向量有一组记录或列值。在这个数据集合中，有多少列，就有多少
向量。不断往查询计划树上面压入一批向量，它们就是查询计划中不同操作符的输入与输出。这种方法远比其它方法有效，因
为这种方法在不同的操作符间平摊了函数调用的开销，其次，操作基于列而不再基于行或元组。
向量化的代码可以充分利用CPU的缓存。例如，有10列的一行数据和只需操作一列的查询计划。在基于行的查询处理模式
中，9列数据会不必要的占用缓存，限制了可以进入缓存的数据数量。在基于列的处理中，只会读入感兴趣的列数据，这样可
以一起处理更多的值，同时有效使用了CPU的内存带宽。
向量处理背后的主要思想是，按列（或列式数据数据）工作，并把从多列到元组（行）的实际转化推迟到查询计划的很靠后的
位置进行处理，大部分情况是需要展示结果给用户时。这正是为什么查询执行算法通常会重写，来做基于列的处理。如果我们
以列式方式存储数据，但是处理代码是基于行处理编写的，那么当读到列时，就不得不组合很多列的数据来构成一个元组，并
将该元组传递给查询操作符来进行传统的逐行处理。执行过程中的元组构建迟早会影响对列式数据进行高度优化的查询处理。
现代处理器有扩展的指令集，在单独的一个指令中，该指令集可以扩展向量执行概念到多列的值。单指令多数据流（SIMD）
指令在20世纪90年代成为桌面运算主流，提高了多媒体应用如游戏的性能。
对多个值做相同改变，比如调整一个图像的亮度时，SIMD尤其有用。每个像素点的亮度由红色（R），绿色（G）和蓝色
（B）的值确定。改变亮度，要从内存读取R，G和B的值，并进行调整，调整后的值要重写回内存。不使用SIMD，像素的
RGB值会依次单个读入内存。使用SIMD，像素的RGB数据块可以在一个指令中一起进行处理。这样就极大地提高了有效性。
这些概念在分析学的数据处理中非常适用。SIMD采用和并发无关的数据级并行。SIMD指令允许在同一时钟周期内，对不同的
资源评论
