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

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

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

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

压缩

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

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

但是,通用的压缩算法不能假定数据有某种特征,只能将数据当作随意的字节流去编码,有时并不能获得最好的压缩率。而且,高压缩率的算法压缩出来的数据,解压缩时常常会增加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选项,就可以做并行计算了。

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

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

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

查找

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

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

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

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

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

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

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

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

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

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

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

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

示例代码2:带值索引

A
1 =file("T.ctx").open()
2 =A1.index(IDS;f1;f4,amt1,amt2)
3 =A1.icursor(f1,f4;f1==123456).fetch()
4 =A1.icursor(f4,amt2;f1>=123456 && f2<=654321)

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

回顾与总结

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

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

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/494261.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

Android实现电子邮箱客户端

本文主要讲述了安卓平台上利用QQ邮箱SMTP协议&#xff0c;POP3协议发送与接收消息的实现 发送邮件核心代码 import java.security.Security; import java.util.Date; import java.util.Properties; import javax.mail.Authenticator; import javax.mail.Message; …

谷歌AI涉足艺术、太空、外科手术,再强调AI七原则

来源&#xff1a;网易智能9月18日上午&#xff0c;Google在上海的2018世界AI 大会上举办了一场名为“AI触手可及”的主题论坛。在论坛上&#xff0c;Google全球副总裁、工程研究员Jay Yagnik 携Google 不同领域的研究者发表了演讲&#xff0c;重点阐述了Google AI在自家产品上的…

单个手指的手势识别

本文来自http://blog.csdn.net/hellogv/ &#xff0c;引用必须注明出处&#xff01; 本文把Aforge的运动识别与前面介绍的手写识别融合在一起&#xff0c;实现单个手指的手势识别。下图演示了本文代码运行的结果&#xff0c;图片有点大&#xff0c;请稍候。。。 我预先让程序学…

Apifox:满足你对 Api 的所有幻想

文章目录⌚️ 一、Api 管理的难点在哪&#xff1f;&#x1f4f1; 二、Apifox 是什么&#xff1f;&#x1f4bf; 三、接口设计 (接口文档)⌨️ 3.1 接口文档&#x1f4bb; 3.2 快速上手&#x1f5a8; 3.3 接口路径&#x1f4bd; 四、团队管理&#x1f4fd; 4.1 权限管理⏱ 4.2 项…

百度地图综合

本文主要包括百度地图API的综合应用&#xff0c;主要内容如下 地图图层展示&#xff0c;包括热力图与实时路况图 添加覆盖物&#xff0c;包括图片&#xff0c;文字&#xff0c;折线等地图控制&#xff0c;包括俯视&#xff0c;旋转&#xff0c;放大&#xff0c;缩小等定位&…

国内Api行业,可以内卷到什么程度?

随着移动应用以及智能设备爆发增长&#xff0c;同时越来越多的零售商、媒体、政府和金融服务公司开始公开Web API&#xff0c;API的使用越来越多。 现在&#xff0c;每日API调用量在不断飙升&#xff0c;早在2009年&#xff0c;Facebook每天API调用量就已经达到了50亿。如何能…

自动驾驶关键技术报告:惯性导航和背后的芯片大战

来源&#xff1a;智东西摘要&#xff1a;惯性导航将成为自动驾驶定位信息融合的中心。惯性导航系统由于具有的输出信息不间断、不受外界干扰的独特优势&#xff1b;同时可以将多种传感器的信息以及车身信息进行更深层次的融合&#xff0c;为决策层提供精确可靠的连续的车辆位置…

3D打印产业化机遇与挑战

来源&#xff1a;3D科学谷3D打印的突出特点有两个&#xff1a;免除模具以及制造成本对设计的复杂性不敏感。免除模具的特点使得3D打印适合用于产品原型、试制零件、备品备件、个性化定制、零件修复、医疗植入物、医疗导板、牙科产品、耳机产品等小批量个性化的产品。而传统制造…

Android之ExpandableListView

ExpandableListView可以用来表现多层级的listView&#xff0c;本文主要是ExpandableListView的一个简单实现 布局文件 <LinearLayout xmlns:android"http://schemas.android.com/apk/res/android"xmlns:tools"http://schemas.android.com/tools"andro…

Api -- 连接世界的Super Star

文章目录&#x1f34f; 一、api 的定义&#xff1a;数据共享模式定义 4 大种类&#x1f356; 二、api 使用场景&#xff1a;互联网时代&#xff0c;api 无处不在2.1 sql 查询2.2 数据传输&#x1f364; 三、开放 api&#xff08;OpenAPI&#xff09;&#xff1a;开放双赢&#…

2018全球最强物联网公司揭晓!

来源&#xff1a;数字化企业根据Gartner预测&#xff0c; 到2020年将有超过200亿台联网设备&#xff0c;市场价值将达3000亿美元之巨。随着垂直应用上的不断细分&#xff0c;以及与AI的加速整合&#xff0c;物联网不仅将持续地变革人们的生活和工作&#xff0c;市场规模也将持续…

Android之解析GML并显示

本例主要实现在APP中解析GML数据并显示 GML,地理标记语言&#xff08;外语全称&#xff1a;Geography MarkupLanguage、外语缩写&#xff1a;GML&#xff09;&#xff0c;它由开放式地理信息系统协会&#xff08;外语缩写&#xff1a;OGC&#xff09;于1999年提出&#xff0c;…

中国电子学会发布《新一代人工智能领域十大最具成长性技术展望(2018-2019年)》...

来源&#xff1a;中国电子学会当前&#xff0c;全球正在经历科技和产业高度耦合、深度迭加的新一轮变革&#xff0c;大数据的形成、理论算法的革新、计算能力的提升及网络设施的演进驱动人工智能进入新一轮创新发展高峰期&#xff0c;新技术持续获得突破性进展&#xff0c;呈现…

晓得不,中间表是这样被消灭的

目录 一、中间表的产生 1、一步算不出来 2、实时计算等待时间过长 3、多样性数据源参加计算 4、中间表难以删除 二、文件计算 三、高性能文件格式 四、易管理性 五、多数据源支持 六、集成性 七、资料 一、中间表的产生 中间表是数据库中专门存放中间计算结果的数据…

美国五大科技巨头的人工智能竞赛

来源&#xff1a;资本实验室毫无疑问&#xff0c;人工智能已经开始渗透到各行各业&#xff0c;并正在改变我们的工作方式和生活方式。2017年&#xff0c;全球与人工智能相关的资金投入总额达到152亿美元&#xff0c;比上一年增加144&#xff05;。而无论在投资&#xff0c;还是…

模拟Struts2实现

本文主要是一个模拟的Struts2的简单实现 真正的MVC架构 实现主要思路 定义一个过滤器&#xff0c;接收传递过去的Action&#xff0c;根据处理的结果重定向或者转发。 首先定义index.jsp <% page language"java" import"java.util.*" pageEncoding&q…

实战教学--怎样提高报表呈现的性能?

报表的性能很重要&#xff0c;是一个总被谈及的问题&#xff0c;跑的慢的报表用户体验恶劣&#xff0c;无法忍受。解决这些慢的性能问题&#xff0c;也成了项目方和工程师头疼的事情。一出状况&#xff0c;就得安排技术好的&#xff0c;能力强的工程师去救火&#xff0c;本来利…

WiFi共享精灵 - 不需路由器一键轻松把网线共享给手机、笔记本等同时无线上网...

现在人们身边手机、游戏机等各种使用WiFi上网的设备已经越来越多&#xff0c;但经常遇到一些地方只有有线网络&#xff0c;或者没有无线路由器的情况&#xff0c;这时&#xff0c;用笔记本上网&#xff0c;然后把网络通过WiFi共享给其他设备上网那么就最合适了。我们之前有介绍…

干货|李开复最新刷屏演讲:人工智能最难取代这13种工作,也最容易威胁人性与爱!...

来源&#xff1a;澎湃新闻这两年&#xff0c;创新工场董事长兼首席执行官李开复&#xff0c;一直为人工智能站台和奔走&#xff0c;还出新书帮助人们规划未来的AI生活。他预言&#xff0c;中国有望在全球范围内首先实现OMO&#xff08;Online-Merge-Offline&#xff0c;线上线下…

Apifox vs Eolink,国内 Api 工具哪家强?

目前行业内有 postman、jmeter 为代表开源 Api 工具派系&#xff0c;我想对大家对这两个词并不陌生。虽然它们能解决基本的接口测试&#xff0c;但是无法解决接口链路上的所有问题&#xff0c;一个工具难以支持整个过程。 在国内&#xff0c;我们可以看到有国产 API 管理工具&…