前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >数据蒋堂 | 不要对自助BI期望过高

数据蒋堂 | 不要对自助BI期望过高

作者头像
数据派THU
发布2018-01-29 15:46:23
7960
发布2018-01-29 15:46:23
举报
文章被收录于专栏:数据派THU数据派THU

来源:数据蒋堂

作者:蒋步星

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

本文分三个层面讨论自助BI是否能够真正满足用户需求。

从早期的多维分析(OLAP)到近年来的敏捷BI,BI产品厂商一直在强调自助能力,宣称可以由业务人员自己分析数据,而用户方也常常有强烈的此类需求,双方一拍即合,很容易形成购买行为。但是,BI产品的自助功能真的能让业务用户自己随心所欲地分析数据吗?

“分析”这个词并没有一个业界公认的严格定义,所以不能说这些BI产品是否过份宣传了。不过,就大多数缺乏BI应用经验的用户所期望的工作内容而言,自助分析的目标就可以说远远达不到!从经验上看,最好的情况也就能解决30%左右的问题而已,而大多数BI产品连这个数也达不到,只能处理10%左右的需求。

我们分为三个层面讨论这个问题。

多维分析

多维分析是指针对某个事先建好的数据集(称为立方体)做交互操作。这是大多数BI产品目前能够提供出来的分析能力,尽管新一代产品在界面美观度和操作方便度上有了不小的进步,但能完成的运算功能并没有本质变化。

多维分析的主要问题是有个建模过程,也就是事先准备数据集。如果要分析的数据都可以限定在某个数据集中,且动作只限于产品提供的那些(旋转、钻取、切片之类),那么没有问题。但这是个小概率事件,实际应用中经常会超出这个范围。增加一个以前没想到的数据项,和另一个数据集做一个关联运算,都会导致再建模。而建模需要求助于技术人员,这样业务人员的自助就无从谈起了。

做到多维分析这一步,只能解决10%左右的自助需求,这是BI产品最常见的自助能力。

关联查询

为解决多维分析的局限性,有些BI产品开始提供关联查询能力。一般是在多维分析前面增加一步,能够基于多个数据集关联计算出新的数据集再来做多维分析,或者在多维分析过程中支持多个立方体间的某些关联运算。这相当于允许业务用户一定程度可以自己建模。

不过,实现关联查询并不容易,其根源是关系数据库对关联运算(JOIN)的定义过于简单造成的,导致数据集之间的关联关系看起来过于繁琐,超出许多业务人员的理解能力。这个困境在BI产品的界面协助下能有一些改善,好的BI产品能够让业务人员正确处理没有形成环的关联关系。但是,要从根本上解决问题,就要改变数据库层的数据组织模型。而几乎所有的BI产品都不会重新定义数据库的数据模型,其关联查询能力就会受限。

一个可用于检验BI产品关联能力的通俗例子:查询女经理的男员工。这个很简单的查询需求中涉及到同一数据集的多次关联,大多数BI产品都处理不了(除非事先建模)。

有了关联查询能力后,BI产品能解决的自助需求占比能提高到20%-30%,具体程度要看产品提供的关联能力的强弱。

过程计算

剩下70%左右或更多的需求,都会涉及到多步骤有过程的计算。而过程计算完全超出BI产品的设计目标,甚至可以不被认为是数据分析,但却是用户特别希望解决的问题,也就是让业务人员能够随心所欲地(在其权限范围内)获取数据。

一个简单办法是使用BI产品导出基本数据,由业务人员自己用Excel等桌面工具去做。但是,Excel并不擅长处理多层次数据的关联运算,而且数据量大了也撑不住,在许多应用场景无法胜任。

在没有更好的交互计算技术出现之前,这些问题还是需要技术人员才能解决。在这个前提下,BI产品能做的事就不是让业务人员自己实现过程计算,而是要想法提高业务人员获取技术资源的效率,以及技术人员实现需求的开发效率。

具体来讲有两个方面:一是建立历史问题库,某些以前曾经做过的问题,可以直接由业务人员直接调出算法改变参数执行;即使是新需求,也可以找到类似问题以协助技术人员准确理解,技术人员和业务人员的理解不一致是造成事务延期的主要因素之一;二是提供高效且可管理的开发技术,让技术人员能快速编写和修改计算代码,并可将这些代码存入历史算法库中保管和再次执行。目前业界并没有多少适合的技术,SQL可管理性较好,但编写繁琐而难以处理有过程计算;存储过程需要再编译而不方便再次执行;Java代码也要再编译而基本上不可管理;其它脚本语言的集成性又较差也难以入库管理和再次执行。

结语

针对于用户最普遍的自助数据需求,当前BI产品的能力实际上是相当弱的。经常的情况是:BI厂商说的是多维分析,而用户想的是那些需要过程计算才能解决的问题,这个错位就会导致期望高而失望大的局面。用户要清楚自己的自助需求:是否做到多维分析就够了?有多少关联查询需求?业务人员是否会提出大量需要过程计算的问题?这样才能设定合理的期望值,知道BI产品对自己的作用在哪里,不被产品的花哨界面和流畅操作迷惑,避免事后的遗憾。

专栏作者简介

润乾软件创始人、首席科学家

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

数据蒋堂

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

往期回顾:

【数据蒋堂】报表的数据计算层

【数据蒋堂】报表应用的三层结构

【数据蒋堂】列式存储的另一面

【数据蒋堂】硬盘的性能特征

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

【数据蒋堂】1T数据到底有多大

【数据蒋堂】索引的本质是排序

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

【数据蒋堂】非结构化数据分析是忽悠

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

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2017-06-16,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 数据派THU 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
腾讯云 BI
腾讯云 BI(Business Intelligence,BI)提供从数据源接入、数据建模到数据可视化分析全流程的BI能力,帮助经营者快速获取决策数据依据。系统采用敏捷自助式设计,使用者仅需通过简单拖拽即可完成原本复杂的报表开发过程,并支持报表的分享、推送等企业协作场景。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档