OLAP工具毁了商业智能

interstage

IT技术人员就是太浪漫了,以为设计一个可变化和自适应的架构,就能包含业务人员的分析思维.

如果是这样我们就进入了认识方法论矛盾了.

如果这个架构用认识方法中的演绎法来构造,那么必然导致先验论。演绎法必须以一定的基本原理为前提，在不引入更基本的基本原理之前，这些基本原理是不可能通过演绎法本身被发现或证明的。而引入更基本的基本原理之后，这些基本原理虽然能被演绎法所发现或证明，但是所引入的那些更基本的基本原理却又不能被演绎法本身所发现或证明。因此依此类推，演绎法要能作为一种完全的、根本性的方法而存在，就必须假设存在一些“先验”的、根本性的、绝对的真理，这些真理是不可能被演绎法本身所发现或证明的，而其他的一切知识却都可以从这些“先验”真理中推演出来。

如果这个架构用认识方法中的归纳法来构造,必然出现所谓的休谟问题。休谟认为，由归纳前提到归纳结论的推理，是建立在所谓的“归纳原理”之上的。而归纳原理本身却又正是归纳的结果。因此，这里就犯了循环论证的错误。也就是说纯粹的、单一的归纳法的使用也不具有合理性的基础。休谟问题也被称之为“归纳合理性问题”。

这就是认知方法的基本原理.认知过程应该是思维和实践的统一体,你就不能剥夺业务人员的思维和实践的要求,这才是BI最大的成功所在.

interstage

从这2个分析逻辑来看,演绎法认知在BI中可以理解为OLAP分析,因为纬度模型是验证的经验得出来的,而归纳法认知在BI中理解为数据挖掘,因为通过数学算法(神经元,决策树,回归,聚类等)来实证的.

但在BI实践中,OLAP和数据挖掘都会出现分析上问题,必须两者结合.我们举经典的"啤酒和尿布"结果来谈这2种分析上的问题.
1,OLAP分析来得到啤酒和尿布,假设这2类商品都属于业务人员来管理，他根据经验认为“如果他给小孩子来买尿布的时候，同时也会买啤酒”，那么这种可能性有多大，根据对数据的收集，发现这2种商品同时成立的次数很多，验证他的判断。
  问题在于,业务人员管理的商品很多，很难就每2种商品做同时分析，只有对由经验预知的“啤酒和尿布”来做判断，这样会失去其他商品的相关性。
  而目前OLAP分析应用系统受制于IT部门的数据模型，如果需要新的分析角度来验证，需要IT部门重新定义数据模型，分析变成了日常统计，这种应用也没什么用处。
2,用数据挖掘分析来得到啤酒和尿布,分析人员通过相关性的数学算法（FP-growth算法），从几万中商品的信息进行计算，发现“啤酒和尿布”相关的强度和支持度很大.
  但问题也出来了,分析人员会找出很多与”啤酒“相关的商品，但这些相关性的商品因此缺乏经验支撑，不了解出现的原因，因此，“啤酒和尿布”的相关性被采纳的同时，可能“啤酒和花生”也被采纳。
  而目前数据挖掘分析出来的结果,经常得到“地球人都知道”或者“地球人都不知道”的报表。归纳法的应用系统对企业也没有太大的改善.

我们不能因为“啤酒和尿布”这个榜样而忽略了它产生的过程.过程就是OLAP分析和数据挖掘分析结合得到了这个结果.

我在这里并没质疑过数据挖掘工具,却在质疑OLAP工具,就是这个原因,因为,我们目前OLAP工具还没有让业务人员经常使用经验法分析,就无法给数据挖掘分析提供帮助,这样导致数据挖掘分析也架空了.

所以,还是这句话:OLAP工具毁了商业智能.

interstage

我在曾经数据库原厂商工作了4年,我也是从DW技术实践出来,从DW到BI,我也曾经认为BI的问题,可以用DW来解决.但实际中却很难,厂商所谓solution也是经验的积累,未必都适合. 直到我真正接触用户的业务部门(而不是IT部门)的人员,我突然发现,其实他们的思维和分析能力并不是我们IT全部能理解的,而IT要通过理解他们来设计他们认为的分析角度(纬度),是永远延后和失真的.
   在这种情况下,我们BI项目的确很难达到预期,但我们不能因为难,而放弃创新的思维.

innovate511

interstage同学，我觉得你后来一直在宣扬OLAP产品，忽略事物的本质了呢。我不但是技术人员，同时也是项目管理人员，需求分析人员，如果要更好地做项目，当然要考虑各方面，而不能只从一个角度去考虑问题。而产品厂商则不同，在他们眼里什么问题都可以用他们的工具解决，不错，每个产品宣传的时候都是宣传起设计理念而非产品本身，但产品哪个产品没有自己的局限性呢？

至于是否剥夺了业务人员的思维和实践的要求，这只是一个嚼头，做过多年BI的人都知道，业务人员的需求是随着公司的发展，业务的发展逐步完善他们的需求。说白了，业务人员（包括乙方的业务分析人员）在考虑需求的时候，根本不会考虑你后台或者OLAP模型是这么设计的，只会说这个是我需要的，你帮我做出来，这也会限制业务人员的思维和实践？

我们不否认好的BI工具会带来更好的操作性和丰富的展现功能。但如果要说到业务逻辑的实现，恐怕还不是BI工具的强项。如果去调查一下的话，500强企业基本先有数据模型，再有业务模型的吧，也就是说首先建设好EDW，提供可靠的，集成的，稳定的，含有丰富历史信息的数据，然后根据具体的BI需求建设维度模型，基本上标准的流程都是一旦有需求变化或者新的业务逻辑需求，首先考虑的是维度模型的加强，然后用BI工具去实现。

再说一个关键问题，BI仅仅是OLAP吗？数据挖掘呢？就算OLAP也能做查询和报表，有的客户也可能要求独立从数据仓库/集市直接搞，而不是通过OLAP。

说到思维，OLAP厂商能想到逻辑以及业务逻辑预留（也就是这里说的让业务人员自己去分析业务），资深的DW设计师难道会不知道么？而且他们不仅仅会想到OLAP要用，而且数据挖掘可能会用，不用OLAP技术做的查询、固定报表会用，不用你这个OLAP产品的客户也能用。所以关键就是，如果OLAP厂商把DW设计师的一部分事情做了，那么就不需要那么资深的设计师（至少是维度模型设计师），但一旦没有这个OLAP工具，厂商该如何去解决业务问题？厂商想做高质量的数据挖掘也做不了？厂商把业务逻辑转换的函数公开、模型公开？这可能么？所以我知道是这家OLAP厂商在剥夺业务人员的思维，还是其他什么人在剥夺业务人员的思维，你如果喜欢用了，只能更好地依赖这个产品而已。

总结几句，DWBI发展至今，由于通往罗马不只一条路，导致了现在DW和BI前端的合作与搏奕并存。有点感觉BI厂商越来越想越过门槛争夺DW的“工作”。产品，有利于提高实施效率，但却把人的思维给限制了。不仅仅是BI前端，ETL、行业模型都在产品化。不过我并没有看见业界的水平整体有多大的提高，因为使用ETL工具的人如果对工具不够熟练，或者对ETL流程不熟悉，或者测试不够完善，ETL的问题依然存在。行业模型能让更多人入门建模，但是一旦新需求或者需求不一样，那还得依赖BI去辅助实现，至于BI工具能不能实现，他们也不管了。

innovate511

最初由 interstage 发布
[B]我在曾经数据库原厂商工作了4年,我也是从DW技术实践出来,从DW到BI,我也曾经认为BI的问题,可以用DW来解决.但实际中却很难,厂商所谓solution也是经验的积累,未必都适合. 直到我真正接触用户的业务部门(而不是IT部门)的人员,我突然发现,其实他们的思维和分析能力并不是我们IT全部能理解的,而IT要通过理解他们来设计他们认为的分析角度(纬度),是永远延后和失真的.
   在这种情况下,我们BI项目的确很难达到预期,但我们不能因为难,而放弃创新的思维. [/B]

那我也补充一下，我也曾在原厂商工作，做过公司自己的全球EDW项目。项目中业务逻辑实现都必须经过DW去实现，没听说过直接前端去实现的，如果要说对数据的处理，那就是聚合、合计等非业务转换事务。这种DWBI紧密结合但又各尽其职的局面，持续了8年以上了，起到了好的效果。我不知道依赖BI工具很多的项目是否能持续5年以上。

我非常理解现阶段BI工具起到的重要角色，主要原因就是BI工具开发更加直接，如果工具提供的函数丰富，有时会开发更快，如果数据量不大，效率也不是问题。但这是治标不治本的办法，本质的东西还得DW与BI前端各行其职。最典型的例子，就是如果多维模型采用统一建模，那么所有数据集市的数据都会具有一致性、可靠性的特点，不但业务问题解决了，同时效率会得到保证。不敢想象在海量数据项目里，大量逻辑转换是由BI Server完成的，会有啥后果。

interstage

我在已经的描述中曾经提到过BI有5大应用,1,日常报表;2,即席查询;3,OLAP分析;4,数据挖掘;5,KPI/BSC.
我为什么但举OLAP分析和数据挖掘的例子,因为这2个例子是能够说明分析能力,而BI的预期在于给企业提供分析,而不是给企业提供日常报表,或者给领导看仪表盘. 所以,我会说OLAP工具毁了BI.
而没说BI工具毁了BI.   如果你认为BI预期不是给企业提供分析,而是给企业提供日常报表,或者给领导看仪表盘的话. 那你的描述对正确的.
    按照你的描述:就是说首先建设好EDW，提供可靠的，集成的，稳定的，含有丰富历史信息的数据，然后根据具体的BI需求建设维度模型，基本上标准的流程都是一旦有需求变化或者新的业务逻辑需求，首先考虑的是维度模型的加强，然后用BI工具去实现。
  这个描述,只是解决了DW,但没有解决BI的问题.DW是技术人员的舞台,而BI是业务人员的舞步,我们不能由于业务人员的舞步非常好,就把所有的功劳归于技术人员的舞台设计的好.
我一直感觉,技术人员谈DW多,谈BI的少,而很喜欢重DW轻BI.其实这是2个层面的使用方式.如果完全兼容的话,那为什么85年Inmon定义了DW,94年e.f.codd还要定义BI.

interstage

最初由 innovate511 发布
[B]
那我也补充一下，我也曾在原厂商工作，做过公司自己的全球EDW项目。项目中业务逻辑实现都必须经过DW去实现，没听说过直接前端去实现的，如果要说对数据的处理，那就是聚合、合计等非业务转换事务。这种DWBI紧密结合但又各尽其职的局面，持续了8年以上了，起到了好的效果。我不知道依赖BI工具很多的项目是否能持续5年以上。

我非常理解现阶段BI工具起到的重要角色，主要原因就是BI工具开发更加直接，如果工具提供的函数丰富，有时会开发更快，如果数据量不大，效率也不是问题。但这是治标不治本的办法，本质的东西还得DW与BI前端各行其职。最典型的例子，就是如果多维模型采用统一建模，那么所有数据集市的数据都会具有一致性、可靠性的特点，不但业务问题解决了，同时效率会得到保证。不敢想象在海量数据项目里，大量逻辑转换是由BI Server完成的，会有啥后果。 [/B]

呵呵,你恰恰受了目前BI前端的影响,认为BI工具就应该由大量逻辑转换和函数转化功能组成. 这就是我反对的BI工具. 所以我支持把这样放入DW. 我认为BI前端应该是业务人员的工具.所以你目前看到的BI功能不适合业务部门,应该放入DW.
如果有一个BI工具,就是定位为业务人员分析的工具,这些功能属于DW的. 你是不是就认为它不是BI工具了.

这就是讨论的问题. 我是从OLAP概念核心谈BI工具,你从目前BI工具的功能谈BI工具,你我都认为BI工具对BI项目有问题.唯一的区别是,我认为目前OLAP工具毁了BI,你认为目前的BI工具管的事情太多了.但你举的例子是管DW的事情太多,我举的例子是管业务人员太多.
这样不就验证了我的观念:OLAP工具毁了BI

innovate511

不错，我以前国内公司时DWBI都做，在厂商里只做DW。而我现在所在公司是BI实力强于DW，是什么后果呢？这个就不用多说了，很多人都有体会。至于是不是做BI的就是搞业务的人呢？我看不是，更多的是精通BI工具，知道如何利用BI工具去实现BI。

应该说目前重BI轻DW的多于重DW轻BI的吧？如果说业务人员想通过BI实现自己想要的业务需求的话，按照这种新OLAP产品，好象不需要DW足够的支持也行？DW与BI的接口部分就是数据集市，如果设计数据集市的人不懂业务，或者对业务不够熟悉，能设计出满足各种BI需求的数据集市么？

我并没有否认BI工具对于BI项目的贡献，但是我强调的时候厂商的误导作用，认为DW建设不用考虑过多业务逻辑，我们的BI工具帮你实现BI，你看我的产品这功能也强大，那功能也强大。我仅仅不赞成的是这个问题，并没有重DW轻BI的意思。

不过我也有自己的考虑，就如BI厂商会从自己的角度看问题一样。那就是BI的实现中BI工具就完成了大部分核心的东西，开发人员的价值没有得到足够的发挥，而DW不同，即便有ETL工具和行业模型产品，但可扩展的东西很多。这也是为啥美国DWBI人才市场DW人才平均薪水高出BI开发人才30%的原因。我想BI人才的平均薪水不够高，可能也拜BI工具太强大了所赐。如果说BI是业务人员的舞步，DW是技术人员的舞台，那么DW中的行业模型该怎么解释？是不是行业模型不用考虑业务，或者说行业模型本身就已经属于这里所说的BI了？

innovate511

最初由 interstage 发布
[B]

呵呵,你恰恰受了目前BI前端的影响,认为BI工具就应该由大量逻辑转换和函数转化功能组成. 这就是我反对的BI工具. 所以我支持把这样放入DW. 我认为BI前端应该是业务人员的工具.所以你目前看到的BI功能不适合业务部门,应该放入DW.
如果有一个BI工具,就是定位为业务人员分析的工具,这些功能属于DW的. 你是不是就认为它不是BI工具了.

这就是讨论的问题. 我是从OLAP概念核心谈BI工具,你从目前BI工具的功能谈BI工具,你我都认为BI工具对BI项目有问题.唯一的区别是,我认为目前OLAP工具毁了BI,你认为目前的BI工具管的事情太多了.但你举的例子是管DW的事情太多,我举的例子是管业务人员太多.
这样不就验证了我的观念:OLAP工具毁了BI [/B]

你觉得我“认为BI工具就应该由大量逻辑转换和函数转化功能组成.”组成么？

DW和BI的最大区别，就是DW仅仅是后台，是信息的提供者，而BI是最终用户与DW之间的实现者，没有BI，DW的数据对于最终用户来说，就是死的数据，而BI这个“接口”帮助最终用户利用数据仓库的数据转换为信息和知识 。如果某个工具提供用户去分析，不管怎么说，也不可能属于DW这部分，属于BI应用了。

虽然我有相当一段时间开发过OLAP了，不过按照你说的新的OLAP工具，是否提供了很好的业务分之支撑，那这不是BI工具实现业务逻辑么？BI工具要实现业务逻辑转换，无外呼就是嵌入了很多函数或者提供SQL、脚本接口帮助实现转换。就拿你说的时间维来说，如果工具中没有这些技术，如何能实现93个时间属性并提供扩展呢？

interstage

呵呵,我们终于达成一致了,说到了问题的关键.行业模型从基础数据角度归于DW,最终的存储也放入DW.但行业模型也是业务人员经验的积累,从描述的角度归于BI工具. 如何让2者无缝结合.这就是管理视点的技术.管理视点是基于数据模型的.管理视点由业务人员设计(当然IT人员可以用管理视点先把共同的行业模型设计完),数据模型由IT部门来做. 管理视点分公用和私有,把基于行业模型首先做为公用(可以由IT部门来做),业务人员在公用的管理视点基础上,按照自己分析思维的改变,通过建立私有的管理视点来证实或者证伪自己的分析,不求助IT.
这难道不是企业理想的BI吗.