没错，列式存储非常牛。但是，Ta还可以更高效

很多数据仓库产品都采用了列式存储。如果数据表的总列数很多而计算涉及的列很少，采用列存就只读取需要的列即可，能够减少硬盘访问量，提高性能。

特别是数据量非常大时，硬盘扫描和读取的时间占比很大，这时候列存的优势会很明显。

那么，是不是只要用了列存就一定能做到性能最佳呢？我们来看看，列式存储在哪些方面还可以做的更高效。

压缩

结构化数据的编码方式一般都不会非常紧凑，常常还有一定的可压缩余地。数据仓库通常会在列存的基础上对数据进行压缩，在物理上减少数据存储量，从而减少读取时间，提高性能。数据表相同字段的数据类型一般都是一样的，甚至有些情况取值都很接近，这样的一批数据通常会有较好的压缩率。

列存是将相同字段值存储在一起的，所以比行存更有利于数据压缩。

但是，通用的压缩算法不能假定数据有某种特征，只能将数据当作随意的字节流去编码，有时并不能获得最好的压缩率。而且，高压缩率的算法压缩出来的数据，解压缩时常常会增加CPU的运算量，消耗更多的时间。这部分多消耗的时间，甚至会大于压缩节省的硬盘读取时间，得不偿失。

如果我们先对数据做一些处理，人为地制造某些数据特征来利用，再配合压缩算法，就可以实现较高的压缩率，同时保持较低的CPU消耗。

将数据排序后存储就是一个有效的处理方法。数据表中常常有许多维度字段，比如地区、日期等。这些维度的取值基本都在一个小集合范围内，数据量大时会有很多重复取值。如果数据是按这些列排序的，则相邻记录之间取值相同的情况就很常见。这时，使用很轻量级的压缩算法也能获得很好的压缩率。简单来讲，可以直接存储列值及其重复次数，而不必把同样的值存储多遍，少占用的空间是相当可观的。

排序的次序也有讲究。要尽量把字段值较长的列放在前面排序。比如有地区和性别两个列，地区的值（“北京”、“上海”等）字符数要大于性别（“男”、“女”），则先地区、后性别排序的效果就要好于反过来的情况。

我们还可以进行数据类型的优化，比如将字符串、日期等转换为适当的数值编码。如果把地区、性别字段都转换为小整数编号，字段值的长度就一样了。这时，可以选择重复情况更多的字段排到前面。例如性别只有两个枚举值，而地区则相对较多。所以各条记录中，性别重复的会更多，先性别、后地区排序所占用空间通常会更小。

开源数据计算引擎SPL提供的列存方案，就实现了这种压缩算法。把有序数据追加进SPL的组表时，默认会自动执行上述方法，只记录一次值和重复计数。

SPL建立有序列存组表，并完成遍历计算的写法，大致是这样：

示例代码1：有序压缩列存和遍历计算

A1：建立原数据的游标，并按照f1,f2,f3三个字段排序。

A2：建立新的组表，指定f1,f2,f3三个字段有序。将已经排好序的数据写入组表。

A3：打开已经建好的新组表，做分组汇总。

在下面这个测试中，SPL采用数据类型优化和有序压缩列存后，数据存储量减少了31%，而计算性能提高了9倍多。测试结果见下图：

这个测试更详细的信息请参考： 多维分析后台实践 3：维度排序压缩

并行

多线程并行可以充分利用多CPU计算能力，是重要的提速手段。而要并行就需要先把数据分段。行存分段比较简单，按数据量大体平均分段，再找记录结束标记确定分段点位置即可。但列存不能采用同样的办法。由于列存的不同列是分别存储的，也必须分别分段。又因为不定长字段和压缩数据的存在，各个列相同的分段点位置不一定会落在同一条记录上，会导致读取错误。

业界普遍采用分块方案解决列存分段同步性问题：块内数据用列式存储，分段必须以块为单位，在块内不再分段并行 。实施这种方法，要先确定每一块的数据量大小。如果数据表总数据量固定，以后也不再追加数据，则很容易计算出一个合适的块大小。但数据表一般都会有新增数据不断追加进来，这就会出现块大小如何确定的矛盾。假如块较大，在初期总数据量较小时，分块数会比较少，无法做到灵活分段。而均匀、灵活的分段是决定并行计算性能的关键。假如块较小，在数据量增长后分块数会变得很多，列数据在物理上将被拆成很多不连续的小块，会多读入分块之间的少量无用数据。考虑硬盘的寻道时间，分块数越多这个问题越严重。很多数据仓库或大数据平台都无法解决这个分块大小和分块数的矛盾，所以很难充分利用并行计算提升性能。

SPL提供了倍增分段方式，将固定（物理）分块改为动态（逻辑）分块，可以很好的解决这个矛盾。具体做法是：为每列数据建立固定大小（例如 1024 个索引位）的索引区，每个索引位存储一条记录的起始位置，相当于一条记录为一块。追加记录到索引位填满后，重写索引区，丢弃偶数索引位，奇数位向前移动，空出索引区后一半位置。相当于将分块数缩减为 512 个，两条记录为一块。

依次类推，重复追加数据、填满、重写索引区的过程。随着数据量的增加，块的大小（块内记录数）不断翻倍。所有列的索引区要同步填充，且填满后同步重写，始终保持一致。这种办法实质上是以记录数作为分段依据的，而不是字节数，所以可以保证各个列即使分别分段也是同步的，不会出现错位的情况。

以动态块为单位分段时，块个数保持在 512 到 1024 之间（记录数小于 512 除外），可以满足分段灵活的要求。各列的动态块对应记录数完全相同，也可以满足分段均匀的要求。数据量无论大小，都可以获得良好的分段效果。倍增分段原理的详细介绍参见这里：SPL 的倍增分段。

示例代码1中生成的组表T，缺省采用了倍增分段方案。要用T做并行计算，只要将A3代码做简单修改：

=file("T.ctx").open().cursor@m().groups(…;sum(amt1),avg(amt2),max(amt3+amt4),…)

  

 

  
1
 

cursor函数加上@m选项，就可以做并行计算了。

后续再追加数据时，不需要重新生成一遍组表。打开组表直接追加即可，代码大致是这样的：

> file("T.ctx").open().append@i(cs)

  

 

  
1
 

这里要保证游标cs中的待追加数据，按照f1,f2,f3三个字段继续有序。实际应用中，待追加数据不一定满足这个条件。

查找

列存比较适合遍历计算，比如分组汇总等。对于大多数查找任务来讲，列存却会导致更差的性能。

在不用索引的时候，通常的列存即使已经有序存储，也无法使用二分法查找。这个原因，和上面并行分段介绍的一样，还是因为列存不能保证各列的同步性，可能会出现错位，导致读取错误。这时列存数据只能用遍历法来查找了，性能会很差。

列存数据表上也可以建立索引来避免遍历，但非常麻烦。理论上讲，要在索引中把各个字段的物理位置都记录下来，索引容量就会比行存时的索引大很多，甚至可能和原数据表一样大（因为每个字段都有个物理位置，索引中的数据量和原数据相同，仅是数据类型简单）。而且，读取时也要分别到各个字段的数据区去读，而硬盘有个最小读取单位，这会导致各列的总读取量远远超过行存，表现出来就是查找性能差很多。

SPL采用倍增分段机制后，可以较迅速按记录序号在列存格式中找到各字段值，就可以执行二分法了。

同时，索引中记录整条记录的序号即可，容量就能小得多，和行存时差不多。不过，使用二分法或索引查找的时候，仍然需要到各个字段的数据块分别读取，性能还是赶不上行存。所以，如果要追求极致的查找性能，还是要采用行存。实际应用中，最好是让程序员根据计算的需要来选择是否列存。但是，有些数据仓库做成了透明机制，不允许用户自由选择行存和列存，就很难达到最佳效果了。

SPL则将这个自由度留给了开发人员，可以根据实际需要来决定是否采用列存、哪些数据采用列存，从而获得极致性能。

在前面的介绍中，组表缺省使用列存，但也提供行存模式，可以在创建时用选项 @r 指明。

示例代码1中的A2可以改为：

=file("T_r.ctx").create@r(#f1,#f2,#f3,f4,…).append@i(A1)

  

 

  
1
 

这样生成的就是行存组表。有了列存和行存两个组表，程序员即可根据需要自由选择使用。

对遍历和查找性能要求都很高的场景，就只能用存储空间来换计算时间。也就是将数据冗余存储两遍，列存用于遍历，行存用于查找。不过，这种共存方案的数据要冗余两遍，且行存还要再建立索引，所以整体占用的硬盘空间会比较大。

SPL 还提供了一种带值索引，在建立索引时把其它字段值一起复制过来。原组表继续采用列存用于遍历，而索引本身已经保存了字段值并使用行存，在查找时一般不再访问原表，能获得更好的性能。带值索引和行列共存方案一样，都能兼顾遍历、查找的性能。而且，带值索引相当于行存加上索引，比行列共存方案占用的空间更小。

示例代码2：带值索引

A2 建立索引IDS时，把要引用的字段f4,amt1,amt2抄在参数中，就可以在索引中复制这些字段值。以后取出目标值时，只要涉及字段在这部分内，就不必再读取原表。

回顾与总结

采用列存可以只读取需要的列，在总列数较多、计算涉及的列较少时，能减少硬盘访问量，提高性能。但仅此还不够，列存数据仓库还要在数据压缩、多线程并行和查找计算等方面做优化以将列存的效果做到最佳。

开源数据计算引擎SPL充分利用数据有序存储的特征，在保持低 CPU 消耗的前提下，实现了较高压缩率的压缩算法，大幅减少了物理存储量，进一步提高了性能。SPL还提供倍增分段机制，解决了列存分段难题，让列存数据也能充分利用并行计算来提高效率。并且，SPL能够自由建立行存、列存数据表，允许开发者自主选择使用，且提供了带值索引机制，可以同时实现高性能遍历和查找计算。

文章来源: notomato.blog.csdn.net，作者：不吃西红柿丶，版权归原作者所有，如需转载，请联系作者。

原文链接：notomato.blog.csdn.net/article/details/125884442