OLAP工具毁了商业智能

interstage · 发表于 2007-5-9 11:55

不是,我是说OLAP需要跟着用户的思考而变化,怎么办.

esestt · 发表于 2007-5-9 12:02

最初由 interstage 发布
[B]不是,我是说OLAP需要跟着用户的思考而变化,怎么办. [/B]

你能举个实际的例子好伐，实在搞不清你说什么。

interstage · 发表于 2007-5-9 12:05

从技术上讲,一个CUBE目前一到10G的容量,性能就大降了,所以基于CUBE的报表,不适合分析报表,只能做日常统计报表.

而OLAP如果建在RDB上,由于RDB传统的'时间和空间'的矛盾, 需要数据分区来支撑超过10G容量的OLAP视图,但在数据量很大的即席查询中,也变的很慢.所以,可以做报表分析,但还是受制于"分析角度"的事先定义

以上2点,就是目前数据库技术上最大的问题. 技术不足,所以咨询来补,告诉用户需要事先定义"纬度",这样是行业管理思路,把数据固化在CUBE或者ROLAP内,这样就是目前的BI.

以上BI,牺牲了什么,牺牲了业务人员对业务本身的思考能力,变的只会统计和在IT部门建设的"纬度"范围内的简单分析了.

esestt · 发表于 2007-5-9 12:16

最初由 interstage 发布
[B]从技术上讲,一个CUBE目前一到10G的容量,性能就大降了,所以基于CUBE的报表,不适合分析报表,只能做日常统计报表.

而OLAP如果建在RDB上,由于RDB传统的'时间和空间'的矛盾, 需要数据分区来支撑超过10G容量的OLAP视图,但在数据量很大的即席查询中,也变的很慢.所以,可以做报表分析,但还是受制于"分析角度"的事先定义

以上2点,就是目前数据库技术上最大的问题. 技术不足,所以咨询来补,告诉用户需要事先定义"纬度",这样是行业管理思路,把数据固化在CUBE或者ROLAP内,这样就是目前的BI.

以上BI,牺牲了什么,牺牲了业务人员对业务本身的思考能力,变的只会统计和在IT部门建设的"纬度"范围内的简单分析了. [/B]

你的意思是因为OLAP的性能和稀疏性问题，你在做CUBE是不能加入太多的维度，所以你事先咨询用户，把用户需要的维度加入CUBE，这样就限制用户的分析？

interstage · 发表于 2007-5-9 15:01

用户需要的维度加入CUBE或者OLAP,问题是,用户一开始不知道多少纬度,IT部门也不清楚,只有使用中,他们思考了才想出来的,要加了,怎么办

esestt · 发表于 2007-5-9 15:37

最初由 interstage 发布
[B]用户需要的维度加入CUBE或者OLAP,问题是,用户一开始不知道多少纬度,IT部门也不清楚,只有使用中,他们思考了才想出来的,要加了,怎么办 [/B]

我的做法是把维度都加进来，像开发一个全局数据仓库那样，我全有MOLAP，目前整个CUBE数据70G，部署在两台服务器上，度量值组按年分区，获取数据的响应时间在1秒以下，效率不是问题。

interstage · 发表于 2007-5-9 16:36

呵呵,如果就这么点数据量,这么点计算能力,当然可以,根本不要用BI思路对设计,只要RDB就可以了

esestt · 发表于 2007-5-9 16:51

最初由 interstage 发布
[B]呵呵,如果就这么点数据量,这么点计算能力,当然可以,根本不要用BI思路对设计,只要RDB就可以了 [/B]

硬件资源有限，数据是无限增长，关键是优化好。
OLAP不是必须，如果你考虑性能问题，可以试试QlikTech，比较另类的做法是内存技术，将数据分块压缩加载到内存中，性能绝对不是问题。

interstage · 发表于 2007-5-9 17:08

QlikTech 这么花图形产品,自称在内存上,其实数据量受限制,又说什么64位的内存很强,其实64位内存突破4G而已,又说有什么压缩机制,按行存储的数据那可能压缩很厉害.QlikTech就是玩虚,适合100G范围内的数据量,玩具而已!!! 我的朋友正在翻译QlikTech 的手册,化了3个多月了,他自己说的.QlikTech 最适合做DEMO和小型的数据量,大了不实用.不是BI.

interstage · 发表于 2007-5-9 17:09

BI不做OLAP和数据挖掘,你做什么?

[精华] OLAP工具毁了商业智能

浏览过的版块