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

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

来源:数据蒋堂

作者:蒋步星

本文长度为1800字,建议阅读4分钟

本文谈谈OLAP,并分析OLAP应当具备的功能。

被狭义化的OLAP

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

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

更广义的OLAP过程

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

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

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

股票分析师会猜测满足某种条件的股票容易上涨;

公司经理对哪些销售员擅长对付难度大的客户心里会有数;

班主任也大概知道偏科同学的成绩都有什么特征;

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

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

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

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

这个月内连涨3天的股票,第4天还继续上涨的比率有多大?

哪些半年不出单的客户在更换了销售人员后半年就出单了?

语文和数学成绩都在前10名的学生,英语成绩排名是怎样的?

...

多维分析的局限

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

恐怕不能!

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

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

我们需要怎样的OLAP?

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

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

1. 关联查询

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

2. 交互计算

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

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

相关推荐