【开源SPL】列存数据仓库怎样更高效_spl 开源(1)，大数据开发开发基础入门教程

本文链接：https://blog.youkuaiyun.com/tencentes/article/details/137888589

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新大数据全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注大数据）

正文

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

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

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

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


	A
1	=file(“T_ordinary.ctx”).open().cursor(f1,f2,f3,f4,…).sortx(f1,f2,f3)
2	>file(“T.ctx”).create(#f1,#f2,#f3,f4,…).append@i(A1)
3	=file(“T.ctx”).open().cursor().groups(…;sum(amt1),avg(amt2),max(amt3+amt4),…)

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),…)

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

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

&gt; file("T.ctx").open().append@i(cs)

这里要保证游标cs中的待追加数据，按照f1,f2,f3三个字段继续有序。实际应用中，待追加数据不一定满足这个条件。对于这种情况，SPL也给出了高性能的解决方案，具体方法请参考：SPL 的有序存储。

三、查找

列存比较适合遍历计算，比如分组汇总等。对于大多数查找任务来讲，列存却会导致更差的性能。在不用索引的时候，通常的列存即使已经有序存储，也无法使用二分法查找。这个原因，和上面并行分段介绍的一样，还是因为列存不能保证各列的同步性，可能会出现错位，导致读取错误。这时列存数据只能用遍历法来查找了，性能会很差。

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

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

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

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

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

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

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

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

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

示例代码2：带值索引