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

“ 
开篇辞


《数据蒋堂》的作者蒋步星,从事信息系统建设和数据处理长达20多年的时间。他丰富的工程经验与深厚的理论功底相互融合、创新思想与传统观念的相互碰撞,虚拟与现实的相互交织,产生出了一篇篇的沥血之作。此连载的内容涉及从数据呈现、采集到加工计算再到存储以及挖掘等各个方面。大可观数据世界之远景、小可看技术疑难之细节。针对数据领域一些技术难点,站在研发人员的角度从浅入深,进行全方位、360度无死角深度剖析;对于一些业内观点,站在技术人员角度阐述自己的思考和理解。蒋步星还会对大数据的发展,站在业内专家角度给予预测和推断。静下心来认真研读你会发现,《数据蒋堂》的文章,有的会让用户避免重复前人走过的弯路,有的会让攻城狮面对扎心的难题茅塞顿开,有的会为初入行业的读者提供一把开启数据世界的钥匙,有的甚至会让业内专家大跌眼镜,产生思想交锋。



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

即对立方体按某些维度分组汇总某些测度。其中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访问量,从而提高性能。

当然,列存也并不全是好处。

因为不减少计算量,列存对于内存数据用处不大。不过压缩存储方式仍然有意义,可以减少内存占用。

使用列存会使分段并行及建立索引的处理变得更复杂,各个列需要同步分段才能并行处理,索引也需要同步指向所有列,而使用压缩机制后同步更为麻烦。不过,总得来讲,在数据已经确定不再变化时,虽然麻烦,但难度并不算大,只是别忘处理了就行。

列存还会加大硬盘的并发压力,在总字段数不多或取用字段较多时并没有优势。对于机械硬盘,如果再使用并行手段进一步加剧并发压力,很可能导致性能不升反降的结果,对于易于并发的固态硬盘使用列存较为合适。

专栏作者简介

蒋步星,润乾软件创始人、首席科学家

清华大学计算机硕士,著有《非线性报表模型原理》等,1989年,中国首个国际奥林匹克数学竞赛团体冠军成员,个人金牌;2000年,创立润乾公司;2004年,首次在润乾报表中提出非线性报表模型,完美解决了中国式复杂报表制表难题,目前该模型已经成为报表行业的标准;2014年,经过7年开发,润乾软件发布不依赖关系代数模型的计算引擎——集算器,有效地提高了复杂结构化大数据计算的开发和运算效率;2015年,润乾软件被福布斯中文网站评为“2015福布斯中国非上市潜力企业100强”;2016年,荣获中国电子信息产业发展研究院评选的“2016年中国软件和信息服务业十大领军人物”;2017年, 自主创新研发新一代的数据仓库、云数据库等产品即将面世。

原文发布时间为:2017-04-07

本文作者:蒋步星

时间: 2024-10-31 17:52:30

【数据蒋堂】多维分析的后台性能优化手段的相关文章

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

多维分析就是针对一个事先准备好的数据立方体实施旋转.切片(切块).钻取等交互操作的过程,经常也被直接称为OLAP.它的后台运算在结构上很简单,如果用SQL语法描述,大体形式为: SELECT D,..., SUM(M), ... FROM C WHERE D'=d' AND ... GROUP BY D,... 即对立方体按某些维度分组汇总某些测度.其中C是数据立方体,D,...是选出维度,M,...是聚合测度,聚合函数也可以不是SUM.D'是切片维度,切块时条件为D IN (d,...),WH

高性能Javascript笔记 数据的存储与访问性能优化_javascript技巧

局部变量也就可以理解为在函数内部定义的变量,很明显访问局部变量要比域外的变量要快,因为它位于作用域链的第一个变量对象中(关于作用域链的介绍可以阅读这篇文章).变量在作用域链的位置越深,访问所需要的时间就越长,全局变量总是最慢的,因为它们位于作用域链的最后一个变量对象. 每种数据类型的访问都需要付出点性能代价,对于直接量和局部变量基本都能消费得起,而访问数组项和对象成员则要代价高点.下图显示了不同浏览器,分别对这四种数据类型进行了200'000次操作所用的时间. 由上图可以看出,要想优化代码的性能

java web性能优化问题

问题描述 java web性能优化问题 Java web后台性能优化: 1.可以把数据放在application里面: 2.可以把数据作为static变量的值,放在常量类里: 3.可以把数据放到缓存. 三种方式孰优孰劣,以及各自有什么优缺点? 解决方案 Java Web性能优化Java Web性能优化Java Web性能优化原则

大数据驱动性能优化

本文示例以PC的优化端为例,目前AE在这块的工作还主要在PC端,但文中的方法对无线端完全适用 1. 概念 1.1 什么是大数据驱动性能优化? 性能优化其实就是用各种可行的优化手段降低页面Latency,从而提升用户体验.通常会遇到如下困难: Latency降低了,真的提升了用户体验吗? 在AE的性能优化的灰度实验中,遇到了性能提升,转化率反而下降的情况,最后大家猛然醒悟,如果我的优化根本就是用户不可见的呢?比如减少了某个异步资源的加载,这个异步加载会降低pageload,但它可能就是一个用于统计

【AliExpress】大数据驱动性能优化

该文章来自阿里巴巴技术协会(ATA) 本文示例以PC的优化端为例,目前AE在这块的工作还主要在PC端,但文中的方法对无线端完全适用 1. 概念 1.1 什么是大数据驱动性能优化? 性能优化其实就是用各种可行的优化手段**降低页面Latency,从而提升用户体验**.通常会遇到如下困难: Latency降低了,真的提升了用户体验吗? 在AE的性能优化的灰度实验中,遇到了性能提升,转化率反而下降的情况,最后大家猛然醒悟,如果我的优化根本就是用户不可见的呢?比如减少了某个异步资源的加载,这个异步加载会

Oracle数据库性能优化技术开发者网络Oracle_oracle

正在看的ORACLE教程是:Oracle数据库性能优化技术开发者网络Oracle.介绍:细处着手,巧处用功.高手和菜鸟之间的差别就是:高手什么都知道,菜鸟知道一些.电脑小技巧收集最新奇招高招,让你轻松踏上高手之路.  摘要: Oracle数据库是当前应用最广泛的大型数据库之一,而其性优化直接关系到系统的运行效率.本文以数据库性能优化的基本原则为出发点,阐述了在数据库设计阶段如何避免竞争和如何优化数据访问,在数据库运行阶段如何从操作系统和数据库实例级别上调整内存和I/O来达到数据库性能优化的各种技

HBase最佳实践-读性能优化策略

任何系统都会有各种各样的问题,有些是系统本身设计问题,有些却是使用姿势问题.HBase也一样,在真实生产线上大家或多或少都会遇到很多问题,有些是HBase还需要完善的,有些是我们确实对它了解太少.总结起来,大家遇到的主要问题无非是Full GC异常导致宕机问题.RIT问题.写吞吐量太低以及读延迟较大. Full GC问题之前在一些文章里面已经讲过它的来龙去脉,主要的解决方案目前主要有两方面需要注意,一方面需要查看GC日志确认是哪种Full GC,根据Full GC类型对JVM参数进行调优,另一方

【数据蒋堂】功夫都在报表外--漫谈报表性能优化

应用系统中的报表,作为面向业务用户的窗口,其性能一直被高度关注.用户输入参数后都希望立即就能看到统计查询结果,等个十几二十秒还能接受,等到三五分钟的用户体验就非常恶劣了. 那么,报表为什么会慢,又应当从哪里入手进行性能调优呢? 数据准备 当前应用中的报表大都用报表工具开发,当报表响应太慢时,不明就里的用户就会把矛头指向使用报表工具的开发人员或者报表工具厂商.其实,大多数情况报表的慢只是个表现,背后的原因是数据准备太慢,在数据进入报表环节之前就已经慢了,这时再去优化报表开发或压迫报表工具并没有用处

【数据蒋堂】第3期:功夫都在报表外-漫谈报表性能优化

应用系统中的报表,作为面向业务用户的窗口,其性能一直被高度关注.用户输入参数后都希望立即就能看到统计查询结果,等个十几二十秒还能接受,等到三五分钟的用户体验就非常恶劣了. 那么,报表为什么会慢,又应当从哪里入手进行性能调优呢? 数据准备 当前应用中的报表大都用报表工具开发,当报表响应太慢时,不明就里的用户就会把矛头指向使用报表工具的开发人员或者报表工具厂商.其实,大多数情况报表的慢只是个表现,背后的原因是数据准备太慢,在数据进入报表环节之前就已经慢了,这时再去优化报表开发或压迫报表工具并没有用处