我们需要怎样的 OLAP

2024-08-28 00:04
文章标签 需要 怎样 olap

本文主要是介绍我们需要怎样的 OLAP,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

OLAP 这个词从字面上理解是在线分析的意思,也就是由人员面对数据进行各种交互式的分析操作。
但是,现在的OLAP 概念被 BI 软件给严重狭义化了。面向业务分析时说到 OLAP,在技术上经常就只有多维分析的功能,也就是针对一个事先建设好的数据立方体,按指定维度层次进行汇总并呈现成表格或图形,再辅以钻取、聚合、旋转、切片等操作以变换维度层次及汇总范围。这些大家都很熟悉,就不再细说了。
多维分析就是在线分析的全部吗?

我们来考察这样一种数据分析过程。
任何一个行业中有多年工作经验的从业人员一般都会对自己从事的业务产生一些猜测,如:

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

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

这些猜测是预测的基础。业务系统运行一段时间后会积累出大量数据,这些猜测就很可能被这些积累的数据验证,证实了则可作为一种规律性的结论,用于指导下一步的动作,证伪了则再重新猜测。
这才是在线分析应该做的事情!基本的动作就是猜测和验证,其目的是从历史数据中找到规律或支撑某些结论的论据。而在线分析软件要做的事情,就是帮助使用人员针对数据去验证猜测。

这里需要注意的是,这些猜测都是由有业务经验的人做出的,而不是软件系统!之所以需要在线,是由于许多猜测都是使用人员看到了某个中间结果后临时想出来的。不可能也不需要事先设计端到端的完整路径,也就是无法建模。
技术上,就是需要让使用人员有能力对数据进行灵活交互式的查询和计算。比如结合上面举的例子,用户要完成的计算可能是这样的:

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

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

显然,上述问题都可以通过对历史数据计算而回答出来,但是,用多维分析技术能实现吗?
恐怕不能!
多维分析在技术上有两个不足:一是立方体要事先准备,使用人员通常没有临时设计和改造立方体的能力,一旦有新的分析需求则必须重建立方体;二是立方体上可实施的分析动作单调,只有钻取、聚合、切片、旋转等少数几种,难以完成多步骤的复杂计算行为。近年来流行的敏捷 BI 产品在操作的流畅性和界面的炫丽度都较早期 OLAP 产品有较大的提升,但本质计算功能并没有增长多少,还是在做多维分析,该不能算的还是不能算。
多维分析确实能够得到一些有益的信息,比如经常举的例子,成本过高时可以精确定位出到底是哪个部门和业务造成的。但是,多维分析却得不到前述例子中我们希望从数据中获得的规律性结论,而毕竟有了规律性结论才能预测并指导工作。从这个意义上讲,把在线分析仅仅理解成多维分析是不完整的。

那么,用于规律发现(更确切地说是规律验证)的 OLAP/BI 软件应当是什么样的呢?
前面说过,从技术上讲,规律验证可以看成是一种针对数据的查询和计算过程,其关键点在于这种过程可以由分析人员自由定义,也就是 OLAP/BI 软件应当具有由业务人员自主实施交互计算的功能。
获取数据后就是计算。这种计算的特点在于要根据上一步的结果临时决定下一步动作,不能事先设计过程,所以必须是交互式的,很象计算器的模式。另外,这里需要计算的数据都是批量的结构化数据,而非简单的数值,区别于普通数值计算器,可以把这个功能形象地称为数据表格计算器
Excel 在一定程度上就拥有这种能力,结果事实上 Excel 才是成为应用最广泛的桌面分析工具。不过 Excel 对于较复杂的数据运算以及要反复要执行的动作也会力不从心,比如刚才举例中的计算都不是很容易直接用 Excel 中完成。

这时候就要借助编程的力量了,支持步骤的程序语言可以写出非常复杂的运算。但遗憾的是,没有多少合适的程序语言。作为 Excel 中自带的程序语言,VBA 天然可以运行在 Excel 中,但 VBA 不是一种集合化的语法,代码编程复杂度很高,也不擅长处理结构化数据。至于 Python,我们之前也讲过,它只是看上去很美,实际上很难,大部分人根本学不会,而且只能运行在 Excel 的外部,也很不方便。
业内可能只有 esProc SPL 才是适合 Excel 分析师使用的程序语言了,SPL 有强大的结构化数据处理能力,特别地,SPL 还提供了 Excel 插件,允许用户在 Excel 中直接使用 SPL 代码完成 Excel 很难实现的复杂运算。

编程有一定的门槛,还是有些业务分析人员学不会编程,那这些问题可以由技术人员配合解决。这时候 OLAP 软件要做的事就不是让业务人员自己实现过程计算,而是要提高业务人员获取技术资源的效率,以及技术人员实现需求的开发效率。
具体来讲有两个方面:一是建立历史问题库,某些以前曾经做过的问题,可以由业务人员直接调出算法改变参数执行;即使是新需求,也可以找到类似问题以协助技术人员准确理解,技术人员和业务人员的理解不一致是造成事务延期的主要因素之一;二是提供高效且可管理的开发技术,让技术人员能快速编写和修改计算代码,并可将这些代码存入历史算法库中保管和再次执行。
不过,这件事业界也没有多少适合的技术,SQL 可管理性较好,但编写繁琐而难以处理有过程计算;存储过程需要再编译而不方便再次执行;Java 代码也要再编译而基本上不可管理;Python 这类脚本语言的集成性又较差,而且版本一致性不好,也难以入库管理和在较大范围内执行。
对于这个场景,esProc SPL 也是更好的选择。SPL 功能强大,代码开发效率高,还适合大数据,脚本化的代码也很容易入库管理和再次利用。

开源SPL源码地址

这篇关于我们需要怎样的 OLAP的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1113162

相关文章

关于数据埋点,你需要了解这些基本知识

产品汪每天都在和数据打交道,你知道数据来自哪里吗? 移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式,可以区分为: 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定

业务中14个需要进行A/B测试的时刻[信息图]

在本指南中,我们将全面了解有关 A/B测试 的所有内容。 我们将介绍不同类型的A/B测试,如何有效地规划和启动测试,如何评估测试是否成功,您应该关注哪些指标,多年来我们发现的常见错误等等。 什么是A/B测试? A/B测试(有时称为“分割测试”)是一种实验类型,其中您创建两种或多种内容变体——如登录页面、电子邮件或广告——并将它们显示给不同的受众群体,以查看哪一种效果最好。 本质上,A/B测

Vue2电商项目(二) Home模块的开发;(还需要补充js节流和防抖的回顾链接)

文章目录 一、Home模块拆分1. 三级联动组件TypeNav2. 其余组件 二、发送请求的准备工作1. axios的二次封装2. 统一管理接口API----跨域3. nprogress进度条 三、 vuex模块开发四、TypeNav三级联动组件开发1. 动态展示三级联动数据2. 三级联动 动态背景(1)、方式一:CSS样式(2)、方式二:JS 3. 控制二三级数据隐藏与显示--绑定styl

使用WebP解决网站加载速度问题,这些细节你需要了解

说到网页的图片格式,大家最常想到的可能是JPEG、PNG,毕竟这些老牌格式陪伴我们这么多年。然而,近几年,有一个格式悄悄崭露头角,那就是WebP。很多人可能听说过,但到底它好在哪?你的网站或者项目是不是也应该用WebP呢?别着急,今天咱们就来好好聊聊WebP这个图片格式的前世今生,以及它值不值得你花时间去用。 为什么会有WebP? 你有没有遇到过这样的情况?网页加载特别慢,尤其是那

LabVIEW程序员是怎样成长为大佬

成为一名LabVIEW编程领域的“大佬”需要时间、实践、学习和解决复杂问题的经验。尽管LabVIEW作为一种图形化编程语言在初期可能相对容易上手,但要真正成为精通者,需要在多个层面上深入理解。以下是LabVIEW程序员如何逐步成长为“大佬”的路径: 1. 打好基础 LabVIEW的大佬们通常在初期会打下非常坚实的基础,理解LabVIEW编程的核心概念,包括: 数据流编程模型:Lab

插件maven-search:Maven导入依赖时,使用插件maven-search拷贝需要的依赖的GAV

然后粘贴: <dependency>    <groupId>mysql</groupId>    <artifactId>mysql-connector-java</artifactId>    <version>8.0.26</version> </dependency>

js基础需要注意的点

1 js中单引号和双引号都能创建字符串,但是html的元素属性规定必须用双引号,所以js优先用单引号定义字符串。

十四、我们应当怎样做需求分析:子用例与扩展用例

用例模型作为UML中4+1视图中非常重要的一员,非常集中地体现了面向对象的分析与设计思想。用例模型将现实世界中连续的一个一个业务流程,按照场景划分到了一个一个的用例中。由于场景的出现,使得用例中的业务流程存在着高度的内聚性,从而成为了日后各种对象的雏形。同时,在用例分析中,又将那些存在于各个用例中的,相同或相近的业务操作提取出来,形成一个一个的子用例或扩展用例,又体现了面向对象设计中的复用性。现在

十三、我们应当怎样做需求分析:查询报表分析

在我以往的用例分析中,使用这样格式的用例模式,对于大多数业务操作流程来说是得心应手的,但对于有些功能来说总感觉不对劲。感觉不对劲的,就是那些查询、汇总与报表功能。对于这部分功能,需要我们描述的不是什么操作流程,而更重要的是那些数据项、数据来源、报表格式、数据链接,以及使用者、使用频率的说明。而这些,在以往的用例说明格式中统统都没有,怎么办呢?俗话说“东西是死的人是活的”,把我们的用例格式改改吧。

九、我们应当怎样做需求分析:功能角色分析与用例图

在我们进行一系列需求调研工作的同时,我们的需求分析工作也开始启动了。需求调研与需求分析工作应当是相辅相伴共同进行的。每次参加完需求调研回到公司,我们就应当对需求调研的成果进行一次需求分析。当下一次开始进行需求调研时,我们应当首先将上次需求分析的结果与客户进行确认,同时对需求分析中提出的疑问交给客户予以解答。这就是一个需求捕获->需求整理->需求验证->再需求捕获的过程。  但是,当我们经