【数据蒋堂】我们需要怎样的OLAP?

被狭义化的OLAP

OLAP是商业智能应用中重要的组成部分,这个词从字面上理解是在线分析的意思,也就是由用户,特别是业务人员,面对数据进行各种分析操作。

但是,现在的OLAP概念被严重狭义化了。说到OLAP,基本上仅指多维分析,也就是针对一个事先建设好的数据立方体,按指定维度层次进行汇总并呈现成表格或图形,再辅以钻取、聚合、旋转、切片等操作以变换维度层次及汇总范围。多维分析的基本思路认为,直接观察大范围统计值过于粗略,无法精确定位问题,需要剥茧抽丝似地对可能有问题的大范围统计值一步步钻取到更细层次,以达到分析目的。

更广义的OLAP过程

多维分析就是在线分析的全部吗?

我们来考察这样一种数据分析过程。

任何一个行业中有多年工作经验的从业人员一般都会对自己从事的业务产生一些猜测,如:

股票分析师会猜测满足某种条件的股票容易上涨;
公司经理对哪些销售员擅长对付难度大的客户心里会有数;
班主任也大概知道偏科同学的成绩都有什么特征;

这些猜测是预测的基础。业务系统运行一段时间后会积累出大量数据,这些猜测就很可能被这些积累的数据验证,证实了则可作为一种规律性的结论,用于指导下一步的动作,证伪了则再重新猜测。

这才是在线分析应该做的事情!基本的动作就是猜测和验证,其目的是从历史数据中找到规律或支撑某些结论的论据。而在线分析软件要做的事情,就是帮助业务人员针对数据去验证猜测。

这里需要注意的是,这些猜测都是由有经验的业务人员做出的,而不是软件系统!之所以需要在线,是由于许多猜测都是业务人员看到了某个中间结果后临时想出来的。不可能也不需要事先设计端到端的完整路径,也就是无法建模。而且由于其临时性,业务人员在验证猜测时也无法借助技术人员的能力。

技术上,就是需要让业务人员有能力对数据进行灵活交互式的查询和计算。比如结合上面举的例子,用户要完成的计算可能是这样的:

这个月内连涨3天的股票,第4天还继续上涨的比率有多大?
哪些半年不出单的客户在更换了销售人员后半年就出单了?
语文和数学成绩都在前10名的学生,英语成绩排名是怎样的?
...

多维分析的局限

显然,上述计算都可以由历史数据计算出来,但是,用多维分析技术能实现吗?

恐怕不能!

多维分析在技术上有两个不足:一是立方体要事先准备,业务用户没有临时设计和改造立方体的能力,一旦有新的分析需求则必须重建立方体;二是立方体上可实施的分析动作单调,只有钻取、聚合、切片、旋转等少数几种,难以完成多步骤的复杂计算行为。近年来流行的敏捷BI产品都有多维分析功能,在操作的流畅性和界面的炫丽度都较早期OLAP产品有较大的提升,但本质功能并没有变,该不能算的还是不能算。

多维分析确实能够得到一些有益的信息,比如经常举的例子,成本过高时可以精确定位出到底是哪个部门和业务造成的。但是,多维分析却得不到前述例子中我们希望从数据中获得的规律性结论,而毕竟有了规律性结论才能预测并指导工作。从这个意义上讲,把在线分析仅仅理解成多维分析是不完整的。

我们需要怎样的OLAP?

用于规律发现(更确切地说是规律验证)的OLAP软件应当是什么样的呢?

前面说过,从技术上讲,规律验证可以看成是一种针对数据的查询和计算过程,其关键点在于这种过程可以由业务人员自由定义,无须技术人员参与。结合当前的应用环境,我们认为这种OLAP应当具体这样两种功能:

1. 关联查询

分析的第一步是获取数据。许多企业都有建设好的数据仓库,可由业务人员自行查询。这里强调关联的意义在于,绝大多数软件都不能很好地让业务人员实现带有关联的查询需求,必须事先由技术人员建模消除关联(类似多维分析的立方体建设),而业务人员的需求常常超过事先建模的范围,又必须求助于技术人员,这样就使在线分析的基础不存在了。

2. 交互计算

有了数据后就是计算。这种计算的特点在于要根据上一步的结果临时决定下一步动作,不能事先设计程序,所以必须是交互式的,很象计算器的模式。另外,这里需要计算的数据都是批量的结构化数据,而非简单的数值,区别于普通数值计算器,可以把这个功能形象地称为数据计算器。Excel在一定程度上就拥有这种能力,使得它事实上成为应用最广泛的桌面BI工具。不过Excel对于多层次数据和有规则操作支持还不够好,难以完成前述例子中的计算过程。

那么,该如何妥善地提供这两个功能呢?这不是一两句话能解释清楚的,需要仔细分析现有技术手段的细节,找出问题所在后加以改进,我们将在后续文章中会陆续涉及。

专栏作者简介

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

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

数据蒋堂

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

原文发布时间为:2017-05-14

本文作者:蒋步星

时间: 2024-10-07 15:52:16

【数据蒋堂】我们需要怎样的OLAP?的相关文章

【数据蒋堂】第11期:不要对自助BI期望过高

从早期的多维分析(OLAP)到近年来的敏捷BI,BI产品厂商一直在强调自助能力,宣称可以由业务人员自己分析数据,而用户方也常常有强烈的此类需求,双方一拍即合,很容易形成购买行为.但是,BI产品的自助功能真地能让业务用户自己随心所欲地分析数据吗? "分析"这个词并没有一个业界公认的严格定义,所以不能说这些BI产品是否过份宣传了.不过,就大多数缺乏BI应用经验的用户所期望的工作内容而言,自助分析的目标就可以说远远达不到!从经验上看,最好情况也就能解决30%左右的问题而已,而大多数BI产品连

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

" 开篇辞 <数据蒋堂>的作者蒋步星,从事信息系统建设和数据处理长达20多年的时间.他丰富的工程经验与深厚的理论功底相互融合.创新思想与传统观念的相互碰撞,虚拟与现实的相互交织,产生出了一篇篇的沥血之作.此连载的内容涉及从数据呈现.采集到加工计算再到存储以及挖掘等各个方面.大可观数据世界之远景.小可看技术疑难之细节.针对数据领域一些技术难点,站在研发人员的角度从浅入深,进行全方位.360度无死角深度剖析:对于一些业内观点,站在技术人员角度阐述自己的思考和理解.蒋步星还会对大数据的发展

【数据蒋堂】第31期:JOIN简化 - 维度对齐

那么问题来了,这显然是个有业务意义的JOIN,它算是前面所说的哪一类呢? 这个JOIN涉及了表Orders和子查询A与B,仔细观察会发现,子查询带有GROUP BY id的子句,显然,其结果集将以id为主键.这样,JOIN涉及的三个表(子查询也算作是个临时表)的主键是相同的,它们是一对一的同维表,仍然在前述的范围内. 但是,这个同维表JOIN却不能用上一期说的写法简化,子查询A,B都不能省略不写. 可以简化书写的原因在于:我们假定事先知道数据结构中这些表之关联关系.用技术术语的说法,就是知道数据

数据蒋堂 | 有序分组

我们知道,SQL延用了数学上的无序集合概念,所以SQL的分组并不关注过待分组集合中成员的次序.我们在前面讨论过的等值分组和非等值分组,也都没有关注过这个问题,分组规则都是建立在本身的成员取值本身上.但如果我们要拓展SQL,以有序集合为考虑对象时,那就必须考虑成员次序对分组的影响了,而且,现实业务中有大量的有序分组应用场景. 一个简单的例子:将一个班的学生平均分成三份(假定人数能被3整除).按我们在前面所说的分组定义,这也可以看成是一种分组,但这个运算在SQL中却很难写出来,因为分组依据和成员取值

【数据蒋堂】第27期:非常规聚合

标准SQL中提供了五种最常用的聚合运算:SUM/COUNT/AVG/MIN/MAX.观察这几个运算,我们发现它们都可以看成是一个以集合为参数返回单值的函数,我们就先把这个共同点理解为聚合运算的定义,把集合变成单值,多个值变成一个值,也就是发生了"聚合",所以叫聚合运算. 那么很显然,有集合的时候就可以应用聚合运算了,所以SUM/COUNT这些运算可以针对一个数据表(记录集合)实施. 分组运算的结果是一批分组子集,那么每个子集上也可以应用聚合运算,这也就是SQL的分组运算了.其实针对全集

【数据蒋堂】第17期:SQL的困难源于关系代数

在结构化数据处理领域,SQL无疑是应用最广泛的工作语言,不仅被所有关系数据库采用,许多新进的大数据平台也将实现SQL作为目标.但现实是,面对当前纷杂的计算查询需求,SQL在很多方面并不够好用.我们在前面说过SQL的过程性问题,这其实并不是最关键的问题,SQL的更大困难来源于其理论基础,即关系代数. 关系代数是一种代数体系.我们无法在本文的篇幅中严格定义代数体系这个概念,只能通俗地解释.人们为解决某种运算问题,定义了一些数据对象及针对这些数据对象的一套运算规则,确保这些运算的封闭性和自洽性,就可以

数据蒋堂 | SQL的困难源于关系代数

在结构化数据处理领域,SQL无疑是应用最广泛的工作语言,不仅被所有关系数据库采用,许多新进的大数据平台也将实现SQL作为目标.但现实是,面对当前纷杂的计算查询需求,SQL在很多方面并不够好用.我们在前面说过SQL的过程性问题,这其实并不是最关键的问题,SQL的更大困难来源于其理论基础,即关系代数. 关系代数是一种代数体系.我们无法在本文的篇幅中严格定义代数体系这个概念,只能通俗地解释.人们为解决某种运算问题,定义了一些数据对象及针对这些数据对象的一套运算规则,确保这些运算的封闭性和自洽性,就可以

【数据蒋堂】第30期:JOIN简化 - 消除关联

我们将等值JOIN分成三种情况来分别讨论,分情况相当于加强了条件,我们可以充分利用每种情况下的特征. 1. 外键属性化 先看个例子,设有如下两个表: employee表和delpartment表的主键都是其中的id字段,employee表的department字段是指向department表的外键,department表的manager字段又是指向employee表的外键.这是很常规的表结构设计. 现在我们想问一下:哪些美国籍员工有一个中国籍经理? 用SQL写出来是这样的: SELECT A.*

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

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