最具影响力的数字化技术在线社区

168大数据

 找回密码
 立即注册

QQ登录

只需一步,快速开始

1 2 3 4 5
打印 上一主题 下一主题
开启左侧

【数据蒋堂】第 1 期:多维分析的后台性能优化手段

[复制链接]
跳转到指定楼层
楼主
发表于 2018-8-24 09:17:17 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

马上注册,结交更多数据大咖,获取更多知识干货,轻松玩转大数据

您需要 登录 才可以下载或查看,没有帐号?立即注册

x

多维分析就是针对一个事先准备好的数据立方体实施旋转、切片(切块)、钻取等交互操作的过程,经常也被直接称为 OLAP。它的后台运算在结构上很简单,如果用 SQL 语法描述,大体形式为:
SELECT D,…, SUM(M), … FROM C WHERE D’=d’ ANDGROUP BY D,…


即对立方体按某些维度分组汇总某些测度。其中 C 是数据立方体,D,…是选出维度,M,…是聚合测度,聚合函数也可以不是 SUM。D’是切片维度,切块时条件为 D IN (d,…),WHERE 中还可以增加针对某些测度的条件,一般也就是选出某个区间内的值。
OLAP 需要即时响应,对性能要求很高,而这个运算形式虽然很简单,但数据量大时的计算量也不小,如果不设法优化,效率就可能很差。下面我们介绍多维分析后台建设时几种经常被采用的性能优化手段。
预先汇总 预先汇总是早期 OLAP 产品常用的手段,简单地就是拿空间换时间。把部分或者全部维度组合(GROUP BY 子句)的汇总值(SELECT 中的聚合测度)先计算出来保存,以后的计算可以直接取出或从这些中间结果再计算,性能会好很多。
预先汇总占用的空间有点大。如果保存全部维度组合,一般应用场景下(十几到几十个维度,维度取值范围在几到几十之间),简单计算可知,空间占用会比原始立方体大数倍到数十倍((k1+1)(k2+1)…与 k1*k2*…之间的比,还要考虑多种聚合函数)。虽然要保证即时响应时立方体都不会太大,但再大几十倍经常也还是难以接受的。
折衷办法是只保存部分维度组合。OLAP 过程中在界面上呈现出来的分组维度(GROUP BY 子句)不会太多,可以只汇总所有 m 个维度的组合,在 m 不太大时(一般不超过 5),空间增长还可以容忍,而用户的大多数操作都可以得到较迅速响应。
麻烦在于,部分汇总解决不了针对其它维度的切片条件,钻取动作就是以切片为基础的。而且,即使全量汇总也无法处理测度上的条件(比如销售额超过 1000 元的统计),而多维分析时常常允许这些动作,甚至聚合函数也可能带有条件(只合计 100 元以下的费用),这些都无法使用预先汇总的结果。
预先汇总只能解决小部分最常见的计算,更多的情况还是要靠硬遍历。
分段并行 多维分析本质上是过滤和分组汇总,这种运算很容易并行。只要简单地数据拆成多段后分别处理,收集到结果再汇总。各个子任务之间没有依赖关系,无论是单机多线程还是集群多机或者综合有之,都不难实现。
多维分析的结果是要呈现给人看的,而人可以观察的数据量远远小于现代计算机的内存。可以放入内存的小结果集不需要和外存交换,程序设计复杂度较低,运算性能也好。如果运算时发现结果集太大是可以直接报告给界面相应信息并中止。
实践测试表明:多线程计算时,不要采用各子任务向同一个结果集汇总的方案,这样看起来会减少内存占用(各子任务共用一个最终结果集),但多线程抢占同一资源需要的同步动作会严重影响性能。
线程数也不是越多越好,显然超过 CPU 核数就没有意义了。如果数据在外存,还要考虑硬盘的并发能力,一般会比 CPU 核数小很多,具体合适的数值需要实际测试才知道。
在数据不再变化时分段也容易,按记录数切分后设置分段点即可。数据可追加时要做到较平均的分段会有些麻烦,以后再另外撰文陈述。
对于单个计算任务,并行后常常有数倍的性能提升。但是,OLAP 操作本身就是个并发性事务,即使用户数不大,也足以抵消并行计算带来的性能提升。
还要再想办法。
排序索引 没有切片的汇总运算总是要涉及全量数据,如果不是预先汇总,也没什么办法再减少计算量了。但有切片运算时(钻取动作),如果数据能合理组织,就未必要遍历所有数据了。
如果我们为维度 D 建立索引(即把各记录的 D 值及记录位置按 D 值排序),那么涉及 D 的切片条件就可以迅速定位到相应的记录上(简单二分法),不需要遍历全量数据,计算量常常会有数量级的减少(取决于 D 的取值范围)。理论上我们可以为每个维度都建立索引,这个成本并不算高,这样只要涉及有切片时,性能就会大幅提升。
需要指明的是,为多个维度 D1,D2 建立的多字段索引用处并不大,它不能用于迅速定位只有 D2 的切片,只能用于对 D1,D2 都有切片条件的情况。在选择取值范围最大的那个切片维度用于定位后,计算量减少已经很多了,其它维度的切片可以仍用遍历手段。
不幸的是,这种原始方案只适用于可以频繁小量访问的内存数据。如果数据量大到必须放在外存中(而这是经常发生的),按索引大量取出实际上并未连续存储的数据时,性能并不会有明显提高。外存数据必须被真实排序、保证相应切片的数据是连续存储的,性能提升才会有效。
如果对每个维度都做排序,那相当于数据要被复制若干倍,这个成本就有点高了。
一个折衷的办法是把做两个,按维度 D1,…,Dn 排序一次,再按 Dn,…,D1 排序一次,数据量只是翻倍,还能容忍。总能找到一个切片维度在两个维度排序列的前半部分,这样该维度切片的数据还是基本连续的,性能提升仍会较为明显。
列存压缩 对付多维分析还有个大杀器:列式存储。
多维分析的立方体中字段(维度和测度)常常都很多,几十个上百个都很正常,但同时需要取用的字段并不多,如果不算切片维度,通常也就 5 个左右或更少。而切片可以用上面的索引方案解决,实际要遍历的字段也仍然不多。
这时候列存就会有巨大优势了。外存计算的 IO 时间占比相当大,减少数据读取量比减少运算量常常能更有效地提高性能。一个 100 个字段的立方体,如果只取 5 个字段时,IO 开销只有 1/20,这会带来数量级的性能提升。
列存还有个优势是可以压缩数据量。如果按前述所说将数据按维度 D1,…,Dn 排序存储,我们会发现 D1 在连续许多记录中取值都相同,D2 也是类似,但程度会弱一些,越往后的维度连续相同的程度越弱,Dn 就会几乎没有相同连续值。连续相同的值没必要重复存储,可以只存一次并记录个数,这样将可以进一步减少存储量,也就是减少外存 IO 访问量,从而提高性能。
当然,列存也并不全是好处。
因为不减少计算量,列存对于内存数据用处不大。不过压缩存储方式仍然有意义,可以减少内存占用。
使用列存会使分段并行及建立索引的处理变得更复杂,各个列需要同步分段才能并行处理,索引也需要同步指向所有列,而使用压缩机制后同步更为麻烦。不过,总得来讲,在数据已经确定不再变化时,虽然麻烦,但难度并不算大,只是别忘处理了就行。
列存还会加大硬盘的并发压力,在总字段数不多或取用字段较多时并没有优势。对于机械硬盘,如果再使用并行手段进一步加剧并发压力,很可能导致性能不升反降的结果,对于易于并发的固态硬盘使用列存较为合适。


作者:279400248
链接:http://c.raqsoft.com.cn/article/1533814436775
来源:乾学院
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

楼主热帖
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏 转播转播 分享分享 分享淘帖 赞 踩

168大数据 - 论坛版权1.本主题所有言论和图片纯属网友个人见解,与本站立场无关
2.本站所有主题由网友自行投稿发布。若为首发或独家,该帖子作者与168大数据享有帖子相关版权。
3.其他单位或个人使用、转载或引用本文时必须同时征得该帖子作者和168大数据的同意,并添加本文出处。
4.本站所收集的部分公开资料来源于网络,转载目的在于传递价值及用于交流学习,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。
5.任何通过此网页连接而得到的资讯、产品及服务,本站概不负责,亦不负任何法律责任。
6.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源,若标注有误或遗漏而侵犯到任何版权问题,请尽快告知,本站将及时删除。
7.168大数据管理员和版主有权不事先通知发贴者而删除本文。

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

站长推荐上一条 /1 下一条

关于我们|小黑屋|Archiver|168大数据 ( 京ICP备14035423号|申请友情链接

GMT+8, 2024-4-29 03:50

Powered by BI168大数据社区

© 2012-2014 168大数据

快速回复 返回顶部 返回列表