OLAP工具毁了商业智能

kinghq

两位的发言给我的感觉就是：由工具而谈其应用。但是对我来说，我更从应用的角度去考虑有没有一条清晰的思路。所以，我倾向于架构。

现在来说需要把目前形成的思路清晰化一下，看能不能解决我的问题。目前来说已经有好几个工具进入了我的视野了。下一步就是把这些合在一起，进行一下原型验证。

等忙过了这段时间再仔细研究几位的发言。

interstage

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

interstage

最初由 kinghq 发布
[B]两位的发言给我的感觉就是：由工具而谈其应用。但是对我来说，我更从应用的角度去考虑有没有一条清晰的思路。所以，我倾向于架构。

现在来说需要把目前形成的思路清晰化一下，看能不能解决我的问题。目前来说已经有好几个工具进入了我的视野了。下一步就是把这些合在一起，进行一下原型验证。

等忙过了这段时间再仔细研究几位的发言。 [/B]

呵呵,我的说法是工具毁了应用,这是一个立论,需要大家一起来辩论.你既不说"不是工具毁了应用",也不说"是工具毁了应用". 却说应用成功于架构,是不是你的提议是无所谓"是不是工具毁了应用",应该是"应用的好坏取决于架构而不是工具".
  但我们来讨论一下架构,你认为什么样的架构是BI应用的成功关键.

interstage

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

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

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

呵呵,这些不是BI工具的核心功能,其实BI工具的核心是如何将DW中元数据转化为业务人员有效的分析角度. 至于这些功能是用很多函数或者提供SQL、脚本接口帮助实现转换,不应该是问题的关键. 如果BI工具过分去强调很多函数或者提供SQL、脚本接口帮助实现转换等功能,它的对象只能是IT部门,而不是业务部门

interstage

技术人员过分关注DW,认为500强企业是DW基础上讲BI.我们看到了技术人员的薪水是多高.如果只有基于DW的BI才是成功的BI.但中小企业就承担不起DW的建设了.难道他们就不搞BI了. 这也是为什么INMON定义了DW后,为什么Codd还要定义BI.

kinghq

BI工具是为了让业务部门自主实现BI，也就是所谓的证实和证伪？而现在的OLAP工具要想作为BI工具的话就妨碍了这种目的的实现，是么？那么让IT部门干什么呢，尤其那些没有DW的小企业？如果没有DW也可以做BI，那为什么还要投入那么多资金做DW并说什么支持决策（DW的定义也是这么定义的吧）？如果这种情况下做BI，那么相关的数据支持又是什么实现的呢（现在业务部门自己内部数据上报；即使我们现在有了系统，也可以这么干）？

另外，我理解这里很多人都是做DW出身，而且大部分都因为BI这个商业概念而过来的。因为原来做DW的时候就是说能做BI工具能做的工作。要不然，就没有了业务需求的支持了；DW只成了一个技术概念——尽管这个概念对一个企业的IT投资来说非常重要。

这应该说是做DW人的不幸，因为忙活了半天做出来的东西可能又是几年前已经做出来的效果，只是更漂亮一点而已（我已经见识了，不管是死数据还是活数据）。但是如果把DW也作为一种技术或工具，看能不能给我们带来其他的价值，那就不一样了。记得经分一期的时候就没把什么分析作为重点，但做的人还是做到分析上。即使我们现在做DW，也不是指望做到分析上的；但做的人还是做到分析上了。所以，做技术，不管是什么技术，包括DW和OLAP工具都要发挥其本身对我们的其他重大价值。这是咨询能够做的工作。

但就我们的实际情况来说，真的给了一种BI工具能给业务部门用，那也得是业务部门自己提出才行。就目前来说，业务部门会提出采购这样的BI工具吗？

就我现在的构想来说，整个项目需要解决三个问题：系统性能、解决方法和业务知识。针对每个问题，不管是IT部门提出，还是业务部门提出，或者是其他人提出，只要得到共识，并能得到解决支持，那就行了。我在这里提出的两个思路以及今天沟通确定的另一个思路使得这个构想有了一定的基础；如果有好的工具支持，那么只要能够灵活应用，应该更能满足对整个项目的要求。

jameszhuangmin

这个问题之所以会引起这样的热烈探讨，还是因为各从不同角度来看DWBI。

DW为BI提供了数据存储。BI是DW的应用或者说是DW的表现。二者之间本来就是合作关系，不存在冲突。

DW工具厂商努力将业务逻辑在存储逻辑中能够完整表达出来。BI工具厂商也努力将业务逻辑能够在工具中直接转换成表现逻辑。大家都没有错。

可惜的是这三个逻辑关系不在一条直线上，他们之间是三角关系，你中有我，我中有你。也就是说：存储逻辑中有业务逻辑的一部分，表现逻辑中也有业务逻辑的一部分。是业务逻辑将存储逻辑（DW）和表现逻辑（BI）联接在一起了。

业务人员是带着业务逻辑的眼光来使用BI系统的，业务人员操作的是BI前端，根本看不见DW。用业务人员的话来说就是：管你是DW还是BI？只要能让我看到我想看的数据就是好猫。

所以，我认为DW和BI间没有必要一定要划得很清楚。DW是管数据的，你就把数据管好，做到海量、完整、快速就是你该做的事。BI是用来表现数据的，你就好好表现，报表、即席查询（Ad-Hoc）、OLAP分析、数据挖掘、KPI/BSC五层应用都能够准确表现，让用户方便使用就是BI该做的事。各做各的事，各尊各的法。

业务逻辑在DW中能够描述出来的，就用DW来描述，描述得别扭的就不要描述了，强迫描述了，DW的性能就下来了。业务逻辑在BI中能表现的就尽量表现，表现不了的，就别勉强了。咋办？编程开发吧！

还是那句话：软件的价值在于应用。只要东西做出来了，业务人员才不管你是怎么做出来的。

jameszhuangmin

最初由 kinghq 发布
[B]1. BI工具是为了让业务部门自主实现BI，也就是所谓的证实和证伪？

2. 而现在的OLAP工具要想作为BI工具的话就妨碍了这种目的的实现，是么？

3. 那么让IT部门干什么呢，尤其那些没有DW的小企业？

4. 如果没有DW也可以做BI，那为什么还要投入那么多资金做DW并说什么支持决策（DW的定义也是这么定义的吧）？如果这种情况下做BI，那么相关的数据支持又是什么实现的呢（现在业务部门自己内部数据上报；即使我们现在有了系统，也可以这么干）？

5. 但就我们的实际情况来说，真的给了一种BI工具能给业务部门用，那也得是业务部门自己提出才行。就目前来说，业务部门会提出采购这样的BI工具吗？

6. 如果有好的工具支持，那么只要能够灵活应用，应该更能满足对整个项目的要求。 [/B]

kinghq，可以回答你这几个问题。

1. 是的，完全正确。BI出来的结果可能是众所周知的事实（业务人员会笑话说：这个不用算我都知道，呵呵，地球人都知道！），这个就是证实，证明了分析的方法是正确的可信的，那么换上新的事实数据再出来的结果也是可信的。但是对业务人员面对新的数据就不一定能凭经验推算出这个结果了。

2. BI 应用有5个层次。大部分的OLAP工具只覆盖了在1~2.5层，2.5~5层不是OLAP该做的事情。

3. 这个问题最后回答你。

4. 从技术角度来讲没有DW照样可以做BI，只要不担心业务系统被搞死就行；不一定要DW，ODS就可以提供数据支持，甚至于直接连接到业务数据库上也可以用（这样做会很不道德，呵呵）。

5. 呵呵，在大部分企业中不要指望业务部门提出这样的要求，业务人员不知道这个世界上有DW，还有一个好玩的家伙叫做BI工具。更不要指望一上来让业务部门提出需求，只会大眼对小眼。我建议你先按照你对业务的理解做一个简单的原型系统，但是要有心理准备，这个系统就是让业务人员来批评的，呵呵，就算是抛砖引玉吧。只有看过这个原型后，业务人员才会有感性认识：哦，原来我的数据还能这样看啊，呵呵，我要做到这个样子，行不？我要做成那样的，行不？这样才能进入角色。（呵呵，这年头IT人员是越来越累了。）

6. 没有你要的这样的工具，只有相对合适的。

回答你的第3个问题：IT部门在BI项目中的角色，甚至于BI项目交付后IT部门的角色完全取决于你对项目范围的定义、系统结构的设计、采用什么样的方法论、还有对工具的合适选择。

innovate511

首先, 作为技术人员来说, 都希望做大项目, 越小的项目(数据量小、业务量小），对DW的依赖越小，BI虽然对中小企业的作用可能并没那么大，但在数据方面不需要太多处理，DW的很多概念和方法论几乎可以缩小到最小。

其次，无论是谁，大家都承认DW和BI的关系是紧密结合以及他们的分工。我这里只是想申明一点，由于DWBI解决方案太过灵活，但最合理的方案往往只有一种，需要多种项目经验，很多人的总结形成。而实施项目的人和做产品的人思路不可能一样，商业目的不同。我只能这么说吧，厂商自己的项目，很多用处不大的产品也没用上，而是以方****和核心，工具为辅助，当有必要的时候就会选择适合的工具。而当厂商需要推广产品的时候，就会说我整套解决方案是如何如何的好，其实主要想卖产品为主。

大家都知道DW是管数据的，但是也都知道在数据集市这个层次，数据已经不是单纯的数据了，而是为了业务分析而建，面向的不仅仅DW中的主题，而是主题里具体的BI应用。我想实际项目中出现问题的地方就在于，更多需求和需求变化是否通过数据集市的数据模型处理，还是BI工具直接处理。如果DWBI的分工不划清楚，就会导致，这种摸凌两角的问题各种处理方案都有，项目实施进度不一定能把握，走了弯路后也许才能走。

我建议把业务逻辑统统拿到数据模型中去实现，有几个原因：
1. 效率的保证，BI服务器面向很多用户的直接访问，如果再处理很多业务逻辑，特别是大数据量，简直会要命的。而后台服务器不同，ETL本来就是它该做的事情。上面一位兄弟说“强迫描述了，DW的性能就下来了”，我想说反了吧，这是DW的强项，怎么会有性能因素呢，呵呵。
我用自己几个实际项目例子说明。早期移动的报表都是直接来自业务系统，然后客户开始大量要月报、年报，如果直接来自业务系统，那速度是相当地慢，于是我们设计了中间存储（数据集市都算不上），效率大大提高。最近某大型制造业项目，在上DW前，打算所有报表直接来自ERP，用BI工具直接制作报表，导致1/3报表打印时间需要半小时以上，我们只能给客户解释，毕竟客户的流程不允许自己建任何中间存储。而且很多报表的业务逻辑是一样的，但每次打印不同的报表都得再次运算一次，效率肯定是省不下来的了。

2. 整体性。BI工具实现业务逻辑，本身只是面向某个具体的BI应用，甚至某个客户的具体BI应用，无法与所有BI应用共享其逻辑转换的成果，如果按照严格流程，每个类似的BI需求都得开发和测试一遍，同时不能保证数据一致性。
3. 可扩展性。如果数据模型实现新的业务逻辑转换，不但最底层的表得到这个信息，就连再次基础之上的高粒度表、不同周期的表、不同BI应用的聚合表/视图都能“鸡犬升天”，任你任何BI需求都能得到满足。而BI工具来实现的话，反正我不知道如何去实现这种扩展性。
4. 易开发维护。大家知道BI工具对于前端开发人员来说非常方便，但如果BI工具对于某些业务逻辑不提供相关的函数，那么有的东西不方便实现。而DW的ETL不同，ETL工具不行，还可以用语言开发。DW的核心是存储，那就是数据模型，只要能达到目标模型，那就是胜利。而BI的核心是什么？是展现、商业智能，它的核心不包含“转换”，多功能转换只是附属功能而已。而且DW发展到现在阶段，数据模型也在半产品化，并非新需求在后台实现就会很麻烦，会废很多功夫。

既然BI工具是编程做的，DW的ETL也是编程的，真不知道啥业务逻辑只能在BI工具实现而无法在DW的ETL过程实现，恐怕应该是反过来说吧。而且数据模型可以移植成为知识财产，不知道BI工具除了工具本身和在所在项目的价值外，在其他方面有知识财产么？当然分析模型这是BI份内之事，也是BI的核心作用，不应算在DWBI之争中。

所以我一直建议，在项目中，DWBI有争论的“地盘”最好拿到DW去，理由有上述几点，如果BI工具有更好的理由争夺这块有“纷争的底盘”，那么我也受教了，这里也没白来。 不过我也替BI工具说句公道话，现在客户常见的，包括一些高难度的展现已经能实现了，只是要求开发人员熟练掌握BI开发的技巧，并非要开发人员自己去开发才行，现在报表展现比较强的，我觉得Cognos ReportNet算是其中的佼佼者。

jameszhuangmin

最初由 innovate511 发布
[B]上面一位兄弟说“强迫描述了，DW的性能就下来了”，我想说反了吧，这是DW的强项，怎么会有性能因素呢，呵呵。
我用自己几个实际项目例子说明。早期移动的报表都是直接来自业务系统，然后客户开始大量要月报、年报，如果直接来自业务系统，那速度是相当地慢，于是我们设计了中间存储（数据集市都算不上），效率大大提高。最近某大型制造业项目，在上DW前，打算所有报表直接来自ERP，用BI工具直接制作报表，导致1/3报表打印时间需要半小时以上，我们只能给客户解释，毕竟客户的流程不允许自己建任何中间存储。而且很多报表的业务逻辑是一样的，但每次打印不同的报表都得再次运算一次，效率肯定是省不下来的了。
[/B]

其中有二个问题：
1. 错误理解我的意思，我并不是说有DW的效率要比没有DW的来得低。我的意思是：在DW中强迫描述一个业务模型会降低DW的效率。原来一个用星形模型描述的加上BI工具的处理能力就能解决的业务逻辑，如果一定要在DW中强制描述而变成了星或者雪花甚至雪暴模型，这样一定是会将DW的效率降低。

2. 移动原来的做法本来就算错误的。