最全【开源SPL】列存数据仓库怎样更高效

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

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

需要这份系统化资料的朋友,可以戳这里获取

写在前面

很多数据仓库产品都采用了列式存储。如果数据表的总列数很多而计算涉及的列很少,采用列存就只读取需要的列即可,能够减少硬盘访问量,提高性能。特别是数据量非常大时,硬盘扫描和读取的时间占比很大,这时候列存的优势会很明显。

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

目录
    • 写在前面
      • 一、压缩
      • 二、并行
      • 三、查找
      • 四、回顾与总结
      • 五、SPL 资料

        一、压缩

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

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

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

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

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

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

        开源数据计算引擎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选项,就可以做并行计算了。

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

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

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

        需要这份系统化资料的朋友,可以戳这里获取

        正体系化!**

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

        需要这份系统化资料的朋友,可以戳这里获取