自己研发BI工具的疑惑

[kufee]

国内自己在做BI工具的公司也很多了，但还是无法与国外的大厂商抗衡，而我们还有必要在做这一块吗？现在感到比较疑惑。
我的团队也正在做着一个数据分析工具，但是否能成功还是未知数，还要继续下去吗？请大家谈谈你们的看法，给我们一些意见。

我们正在做的工具介绍写在了这里：http://blog.bicubes.com/wkufee

[老沈]

首先鼓励kufee，一定要继续做下去！

我也负责一个国产BI产品（www.esensoft.com）的设计研发，而且我们已有不少成功案例，这足以让你鼓起勇气了吧？

IT界有很多公司，很会鼓噪名声；有一些公司，则踏踏实实做技术。相信一点：付出总有汇报。沙里淘金，只有金子才能被人记住。呵呵

[Qing]

强烈支持！赞美的话在此我就不多说了，主要说说意见。

看到这样的olap工具，不得不说思路还是有些局限。为什么在国内看到原创的工具研发不是报表工具就是olap工具呢？而且kufee还在这个介绍里面提到molap跟rolap的区别，这点也是非常有趣的。因为国内的olap几乎全部是rolap路线。为什么？可能是rolap的技术架构是比较灵活的那种，在关系数据库的基础上，将olap元数据设计出来，再辅以展现，就可以实现基本功能。而molap，要设计多维数据库去存储数据，研发工作自然非常有点难度。所以说，rolap的门槛较低。但如果是因为这个原因，就选择自主研发这种产品，那么不得不说，这个决定不靠谱。而国内出现了不少这种不靠谱的产品研发，算是一种审美疲劳了。

我想自主开发不一定就是开发一种跟现有某种产品功能一样的东西，试图用民族的去替代它。可是，现在有很多开源的产品啊，那种东西的国际界限很淡，比如同样是rolap的开源实现，mondrian。人家已经做得不错，内部结构都是开放的，所有人都可以参考，不是秘密。那为什么要开发新的工具？我认为应该抓住现有产品的不足之处，选取薄弱环节去加强。

比如说，现有olap产品性能不行，我有一技术，可以让传统的rolap引擎加速10倍，那就可以集中精力在这上面，而外围的功能，尽可能不要多花精力。或者，我有一种非常强大的展现技术，只要你扔进去一堆数，甭管什么数，总能以最恰当的方式渲染成分析图，这种技术好，那就盯住这块。这些都是一个个的点，而不是一个大而全的产品。对于我们在技术领域落后的国度（没人否认这一点吧），我认为这是一个比较现实的自主研发之路。

不要去试图开发一个很大的系统，而是抓住需求的缝隙。BI通常是一个综合体，有各种不同的技术，存储方式的技术有改进的空间，分布式计算的技术也有改进的空间，如果说这些对于我们中国的大多数人来说，是高难度的话。为一种用户体验创造一种新方式也是一种产品。

使用过olap的人难道没有觉得他的操作是非常奇怪的吗？他其实根本就是半成品，总是要拖拉维度、度量，为什么不能根据使用者的习惯来自动选择维度、度量，为什么不能自我从那些数据里面发现一些异常？为什么他就不能好用一点？这些问题是有需求的，而好处在于，目前，这种需求大家都还在探索，国外也没什么很好的解决方案。而且，在用户体验这个层面来看，不同地域的人习惯不同，所以，而我们面对着最直接的需求。为什么要跟在国外产品的后面，而不去探索我们自己的需求呢？为什么一定要等国外先创造出一种东西，我们再去模仿呢？

也许kufee的产品中还有很多亮点没有显露出来，如果有这些亮点，它的存在是为了什么需求？那就尽量放大这个亮点去满足这种需求，80%的精力放在这上面，而忽略一些不重要的，现在已经有了的技术。

如果你说，我并不知道现在还有那种需求是没有被满足的，如何去寻找突破口。问题就在于此，在不知道需求的情况下，去搞研发，那就是闭门造车。虽然这个成语已经在软件行业用滥了，但不可否认，我们周边太多这样的事情。与其去花精力研发，不如先挖掘市场的需求。不然，真的就成了玩具。

对于Kufee的团队，非常希望能够继续做下去，但不是开发那些无聊的功能，而是搞点有意思的东西。如果你要搞olap，千万别再说什么钻取、切片之类的概念，那玩意儿是大路货。

泼了大盆凉水，kufee感觉如何？我想你既然已经问出了"还要继续下去吗"的问题，应该也是到了一个需要思考的阶段。希望我们能够探讨更加深入，去搞一些有意思的玩意儿。

2008/9/3 kufee <WKu...@gmail.com>

国内自己在做BI工具的公司也很多了，但还是无法与国外的大厂商抗衡，而我们还有必要在做这一块吗？现在感到比较疑惑。
我的团队也正在做着一个数据分析工具，但是否能成功还是未知数，还要继续下去吗？请大家谈谈你们的看法，给我们一些意见。

我们正在做的工具介绍写在了这里：http://blog.bicubes.com/wkufee..

[老沈]

BI产品的核心指标只有2个：展现的能力、展现的性能。
展现性能比较好理解，就是运行效率，这个自然MOLAP有优势，因为MOLAP是事先做好了全部组合的聚集。但是真正的数据仓库系统，是很少采用
MOLAP技术的，因为MOLAP带来性能的同时，是存储空间的的急剧增长，而且对聚集数据的查询也丢失了很多基于明细数据的信息。一个2亿行的事实
标，带15个维度，谁用MOLAP存储看看。随着64位、大内存、并行处理、列式数据库等技术的普及，本人愚见ROLAP将越来越成为主流。
对于分析能力，最典型的例子是很多复杂报表的实现。国外的产品在复杂报表上一直是短项，他们的设计团队在设计时，很难去研究清楚中国人的报表有多么“博
大精深”。这也许是国内一些报表工具软件有一定市场的原因。当然，分析能力还有很多其他方面，如灵活的BI门户、高级数据分析数据挖掘能力、开发接口等
等。

想清楚了BI产品的核心指标，每个产品就可以突出自己之长。我在设计BI产品时，突出强调：
1、完全在线的RIA应用。比如提供纯WEB方式的拖拉拽OLAP、提供在线的报表设计工具。这是拜AJAX技术所赐。
2、报表设计尽可能强大、简便，任何复杂报表都要能方便实现。
3、提供端到端的产品，而不是面向开发者的产品，这需要良好的交互界面和语义层做支撑。
4、针对国内垂直管理的特点，提供中心部署，各级使用的解决方案。比如一个部署在省中心的数据平台，允许各级人员定义自己的分析和报表，系统能严格控制
各级的数据级次和权限。
5、支持聚集主题定义和导航，解决ROLAP的性能问题。
6、提供便捷的BI门户，允许用户拖拉报表对象，象拼积木一样完成信息交付的“最后一公里”
7、其他BI的主流功能也都不应该太弱。

另外，kufee似乎对MSTR的智能CUBE情有独钟，其实那只是一个概念，起核心是聚集主题。也就是允许在基本主题下，定义很多维度组合的聚集主
题；当用户对基本主题发起查询时，系统能通过一个导航引擎，自动找到最佳的一个聚集主题。

[st lin]

说实话，本人领导一个小团队研发国产BI产品，涉及OLAP，Dashboard，报表设计工具，KPI展现等，已经有3年多，但是我已经退出来了，带着迷茫。

研发BI产品带有一定的风险，一是技术上，二是商业上。

技术上讲，能实现到哪种程度，比如olap工具，你能实现molap吗，不能，能实现rolap吗，你能比现有的mondrian更加高效吗？就算是mondrian，它就能适用于商业应用吗，不能，事实上，mondrian依旧是个技术玩具，至少从目前来看，离应用还太遥远了。

商业上，olap工具能给你的业务带来何种商业价值，你是单独卖BI工具吗，我想是不可能的，你的olap工具能比得上SqlServer分析服务吗，人家一个数据库才1万块。那么，跟业务产品结合？我认为这才是我们自主研发BI最有价值的体现。因为从商业上讲，任何带点智能分析的业务都可以称得上是BI，比如财务分析，全面预算，成本管理，全面绩效管理。而这些业务，对纯技术要求并不一定高深，简单的olap功能就能满足这些业务，据我了解oracle全面预算管理软件，数据收集，业务操作，分析界面等都是典型的，简化的olap功能。

那么，我为什么讲商业上的风险？是因为我们企业领导对BI研发认识不足，并不清楚BI能为企业带来什么，而技术人员又不太懂业务，导致研发几年以后发现，研究成果无法转换成产品。

显然，研发BI的公司多数都是软件公司，大多数公司所宣传的BI产品都是报表工具（如润乾），或者少数的Olap工具（如尚南），这种都是纯技术型的BI公司，没有从业务上智能，也就是说，比较少提供专业的业务分析软件的。

我在研发BI产品过程中，遇到如下几个问题供参考：

1） 人才不足，无法招聘到相关从业人员，也就是说，这类人才没有形成规模。

2） 收入差异，研发国产BI，不如做BI实施，事实上，我们的同事都溜走了，经不住外部的诱惑。

3） 领导认识不足，资源投入不足，领导们并未充分理解BI的核心，停留在报表和olap的表面，也无法在人力资源上给予充分的支持。

4） 业务人才不足，做BI产品，必须深入了解业务知识，才能脱离旋转切片等幼稚的想法。

5） 技术能力不足，我们做ROLAP，参考mondrian，但是遇到性能问题，对内存耗用太大，因为我们刚开始就试图做成通用的olap工具，没有做功能范围界定，我们做Web BI组件，没有现成的Chart控件，JFreeChart交互性太差，我们用Ajax，发现现有的开源Ajax框架不成熟，自己开发工作量太大，效果也不见得好。

总之，很多问题，都能导致你崩溃，就像在沙漠中，没有计划，没有方向，慢慢走啊走。

所以，我建议，在确定要做国产BI研发前，也做好充分的产品规划和可行性研究，不要走一步算一步，不要轻信开源软件，除了简单的报表工具外，其他集成性的BI开源软件Patenho，OpenI等都不具备可用性。

本人虽然暂时退出这个领域，但是还是心有不甘，希望将来有一天，能有真正的重量级国产BI软件产生，我也好混水摸鱼，呵呵。如果各位大侠知道现在有这样的公司，赶紧告诉小弟：）

 

在08-9-4，Qing <happ...@gmail.com> 写道：

[kufee]

非常感谢两位的鼓励和意见，让我受到了很多的启发，基于你们的意见我说说我的看法。
首先是为什么我要做这个工具，主要是因为我们公司在用的报表软件无法满足树型纬度任意组合的要求，我也去了解过很多相关的工具，都没有得到满意的答案，
这是我要自己开发的出发点。包括我是最近才去了解的cognos和mstr 这两个工具也没有给到我这个问题的答案。
关于树型纬度组合的问题，可以看看我们的工具是怎么做的：http://blog.bicubes.com/wkufee/312
你们的工具是如何解决这个问题的呢？我很想知道。

mondrian也去了解过，也想过在基础上来封装，但有3个问题让我放弃了；
1、它的交互界面不适合直接给用户使用；
2、它的思路跟我的有差异，我们如果在它的基础来封装，必然要对它的内部结构了解清楚，这会花费我们太多的精力，而且还不好控制；
3、它不支持树型纬度的组合，公式定义能力太弱；

我也非常赞成搞一些有意思的玩意，但我并未真正进入这个行业，只是有兴趣，自己多学习一下而已，对我来说树型纬度组合就算是新鲜的玩意了吧，或者你们会
觉得这也是大路货了，呵呵。
qing所说的的有意思的玩意是否可以搞个专题拿出来跟大家分享和探讨一下，或者可以给我们更多的启发。
我本身的计划是在把这个工具成功应用到我们公司的财政项目后再加入挖掘的功能，这可能也不算什么新鲜的东西了。

其实我并不是对mstr的cube情有独钟，只是最近看到，引起共鸣而已；至于你说的聚集主题我并不了解是什么东西，或者你可以举个例子说明一下；
我想mstr的cube也不只是概念而已，在我的工具里是存在这样的cube模拟对象的，它是类似于molap工具在数据仓库存储的cube，只是它只
是需要的时候才虚拟出来，并可以缓存下来，这可以给olap的功能带来良好的灵活性，但要解决其快速寻址的能力，这也是你说的展现性能的一方面。
我也认同rolap将越来越成为主流，并不是说因为做一个多维数据库有难度，而是molap有比较难解决的弱项，一是数据容量的问题，如老沈所述；二是
其产生众多的cube表难于管理。而rolap主要的问题是性能，但这个问题有很多的解决办法，如数据库的调优、硬件的升级，虚拟cube也是解决办法
的一方面。

[老沈]

Kefee：
你说的“树型纬度任意组合”对BI产品而言确实大都支持，我们的产品就支持，而且允许用户在WEB上拖拉行维、列维，及指标，就能产生行、列都能收放的
报表。
我个人认为这是一个经典的带层次维的交叉OLAP而已。

聚集主题就是实现做好汇总的主题表，而你的“cube模拟对象”是动态产生汇总的（说白一点就是SQL中带SUM Group by），ROLAP的性
能就是因为这种动态汇总带来的。所以你所谓的“cube模拟对象”是不能解决性能问题的。

“数据库的调优、硬件的升级”等对ROLAP性能提升非常有限，正如MSTR的技术文档上所言，解决ROLAP性能的最好办法是聚集主题。当然，采用列
式数据库也会极大提升ROLAP的性能，如SybaseIQ等。

[老沈]

修正笔误：聚集主题就是事先做好汇总的主题表

[st lin]

我想你并未真正了解mondrian,mondrian的维度结构跟SqlServer 2000一样，支持标准维度，时间维度，父子维度。mondrian的支持多种查询接口，内部接口是mdx，类似于SqlServer2005，但它还支持jolap，xmla等业界标准接口。 mdx查询语言是工业标准，任何olap分析都可以通过mdx查询得到，就像essbase，microstrategy，sap等，虽然内部查询不是通过mdx语言进行的，但都支持对等的mdx查询，说明mdx查询本身是功能完备的。就像sql语句用来查询关系数据库一样，mdx生来就是用来查询多维数据库的，mdx还是微软发明的，所以kufee所讲的mondrian公式定义能力太差是不存在的，因为mdx允许你定义非常复杂的多维表达式，可以访问多维空间中任意的节点，另外，说mondrian不支持树状维度交叉组合也是不存在的，因为这也是mdx的基本特性之一。mondrian本身是没有界面的，界面是jpivot项目做的，是做的很差，不过你可以自己实现界面展现。

每个人的知识背景不一样，对维度的理解也不同，而不同产品对维度的实现也是不一样的。在是否支持不齐整维度上面，olap产品就分为两派，SqlServer2000的父子维属于不齐整维，据我了解，很多产品是不支持不齐整维的，比如microstrategy，essbase等。根据这一点区分，olap是介于数据仓库和报表之间的，我认为支持不齐整维的产品更倾向于报表，而不支持不齐整维的产品更倾向于数据仓库标准的。从建设数据仓库的角度看，不齐整维会带来很多问题，比如语义不清，因为节点上的级别不具备业务含义，只能采用第一级、第二级这样的称谓，将不齐整维拉平整理变成齐整的维，会带来清晰的语义结构，每个节点都对应一个有业务含义的字段。从olap实现本身来讲，不齐整维会带来查询阻抗性，因为维度上节点的值无法通过group by直接汇总，这和rolap的基本原理是相悖的，如果有这类维度，需要做特殊的处理。从报表层面上，国内的部分领导喜欢看不齐整维度的报表，如果支持这种维度，如果有多个不齐整维度交叉，性能会是灾难性的，而且界面也会混乱。从建模的角度来看，支持不齐整维也是放任设计人员不去抽象业务，因为很多现实中的维度都是不齐整的，如地区，组织结构等。

因为，我在认识到这种维度的问题后，开始渐渐不支持使用父子维了，在数据仓库设计阶段就杜绝使用它。

看来kufee的blog，觉得kufee的olap认识应该是从报表出发的，也就是说从报表需求触发了olap的诉求。你需要的是一种非常复杂的交叉表，带树状结构的交叉表，润乾报表算是比较出名的报表产品，它实际上也不支持这种需求的。我认为，做olap产品，需要在报表和分析之间权衡。

我很想在这里探讨一个维度结构问题，首先我要定义清楚概念，这里只讨论标准维度，不讨论不齐整维度。

我们知道，维度（Dimension）是有很多属性（Attribute）组成的，这里的属性对应着一个字段。比如一个维度地区由国家、省份、城市组成。那么，在你的潜意识里，是先有维度还是先有属性，有些人是马上想起维度树，国家、省份、城市等属性挂在上面，而另一些人可能首先想到的国家、省份、城市这些有业务含义的属性，在他们眼里，也许这三个属性就称为三个观察维度。

那么我们来看产品是怎么做的，在传统早期的维度定义中，比如sqlserver2000，都是要设计完整的维度结构，然后展现工具中维度作为一个整体被拖来拖去，感觉有点笨拙。而其它产品，比如microstrategy，它没有维度概念，只有实体entity，也就是上面的属性（国家，省份，城市），这些属性将可以定义穿透路径，对于展现工具来讲，这些实体就是维度，界面上直接操作实体对象。其他非olap产品，也是直接操作属性的，比如brio，Qlikview，我想，后者可能更符合操作习惯。而且，我发现，有一种趋势，维度作为整体概念正在转变，转变成microstrategy的这种结构。比如sqlserver2005新的维度结构，它首先表现为属性，后才表现为维度，一个属性默认是一个属性维。Oracle开始推行的BIEE也是这种趋势。还有一点，以前的维度之间不存在关联，而sqlserver2005，开始可以定义关联，而关联关系，是以属性为中心的产品的本质特性。
所以，我个人认为，olap作为一种物理结构应该会渐渐消失，取代的是具备丰富语义和关联定义的数据业务语义层，前端产品根据用户动作动态拼装查询结构，而olap技术，只是作为一种实现模型存在于BI产品内部，物理的cube建模将会消失。

目前国内的国产BI软件，我想主要还是满足报表需求为重点，而国内报表的复杂需求不具备国际性，我们如果一直拘泥于这种市场需求，我们将离国际产品越来越远。
 

在08-9-4，kufee <WKu...@gmail.com> 写道：

[老沈]

st lin看来对维度模型有非常深入的研究。

至于到底是维度还是实体，其实这是一个由来已久的经典问题，即Kimball 的MD理论和Innom的CDW理论。

以前的一些产品，如MSTR7.0以前的版本，Essbase，Cognus等等，都认为OLAP数据必须是多维的，也即必须是星形或雪花模型，所以才
要分得很清楚事实表和维表。Kimball认为企业数据仓库中的数据是多维的，构建企业数据仓库必须建立全局的一致性维度，搭建企业数据的总线架构，已
方便展现和扩充。
而Innom认为在构建实际的企业全局数据仓库过程中，数据关系是非常复杂的，全部转化为星形或雪花等多维模型并不容易，所以允许明细数据是3NF，而
DataMart也是MD的。一些新的BI产品已经支持3NF模式，所以才有弱化维度概念，而采用了实体、属性等数据库概念。

关于不齐整维，个人认为无需讨论，这是必须要支持的，因为现实世界到处是这样的层级维。不仅仅是报表要支持，即席查询当然也要支持，否则一定会被用户诟
病。

关于中国式报表，我依然认为这是国内BI产品必须要牢牢把握好的，这是很可能超越国外BI产品的一个闪光点。这里套用一句老话：只有中国的，才是世界
的。况且，在国内的BI应用中（我想国外也差不多吧），70％的应用是报表，如果上了一个BI系统，却发现有10％的报表无法实现，用户会的评价也不会
好到那里去吧。

[kufee]

老沈：
我不知道你是否真的了解我说的树型纬度任意组合，其实是不是拖拉并不重要，最后出来的是带层次维的交叉olap也不重要，先让我们把焦点方在一个维的组
成，关键有两点：
1、组合的元素本身是树型的，并且可定义需要某个元素的哪个级别，并不是全关联；
2、这些组合是由用户动态来做的，而不是由开发人员在一开始就设定好的，更不是用更多的表事先把组合的纬度生成出来；
如果做到这两点就可以了。我的确没有见过有报表工具或者olap工具有做过这样的演示例子，所以我并不确定是否他们可以实现，或者你可以拿个例子来说明
一下。

你这样说聚集主题如果是这样的话，其实这是一个解决性能问题很自然的做法，当你有这个需要的时候就会想到的，这其实跟molap的思想是差不多的，关键
是你要做好维护更多数据集的准备，这只是工作量的问题了。我所谓的“cube模拟对象”是从缓存的角度去解决性能问题，如果这不能解决性能问题的话，以
同样的角度聚集主题也不是解决性能问题的办法。
而cube模拟对象的确是包括了你说的“SQL中带SUM Group by”，但这只是它的一部分，并不是全部。
如果你认为：ROLAP的性能就是因为这种动态汇总带来的，那聚集主题表只是把这个工作提前了，并没有省略吧，cube模拟对象也可以做到提前准备，而
它具有更多的灵活性。

st lin：
是的，我对mondrian的研究并不是很多，只是个大概，但你说所说的这些特性我还是略知一二的，父子纬度我没有说它不支持，关键是组合，还是由用户
定义的，如上所述；如果要实现一个3级的树型都还要做一个临时表来记录父子id的关系的话是不可以接受的。我说的不支持是不准确的，其实真要实现，没有
哪个工具是做不到的，问题是它的实现足够方便吗？
润乾实际也算是可以做到的，我们公司现在有的报表就是拿润乾来实现的，但就实现不够方便灵活。
至于纬度和实体的概念，我想也没什么太大关系，你的工具是以哪个观点去实现的就继续做下去就好，遇到不同的结构就转化吧，其实这一件事来的，从不同的角
度去看而已。
你最后所说的观点：物理的cube建模将会消失；是否表示你不认同molap的方法呢？
其实我也不认为报表不是olap的重点，更不是bi的重点，olap的重点是数据分析，而报表是展现的手段，图也是，但这些东西是你的工具必须有的。是
否国际性，也没必要那么快关注，自己的市场都做不好的话，就别指望能走出去了。

[kufee]

stlin:
另外我所说的mondrian的公式定义能力弱，是相对来说的，或者对你来说是不存在的，但对我来说的确是存在的，简单的说，很多基本的公式都不提
供；
你也别跟我说mdx可以做到，我的客户连sql都不会用的；
你也别说可以自己扩展，我之前就说过了：

[老沈]

Kufee：
我确实没理解清楚你的Cube模拟对象，或许你的描述还不够清楚。
正如qing所言，要研发自己的BI产品，但一定不能闭门造车。聚集主题的设计和导航是数据仓库大师们研究的一个重要内容，可不是我闭门造出来
的。MSTR的智能立方体其实就是聚集主题。我这里有一本大师们写的关于聚集主题的书，推荐给大家
《Mastering.Data.Warehouse.Aggregates.Solutions.for.Star.Schema.Performance》。

另外，我再次跟你确认，你说的树型维度任意组合那两点，我们的产品确实支持，而且业务用户可以在WEB上来事先这样的分析。

[kufee]

老沈：
我会再去了解一下聚集主题和导航这些东西，我现在的理解是它把最明细的数据事先汇总并用表或者其他东西来保存，我如果没理解错的话，MSTR的智能立方
体应该不是那么简单；它描述的特性有2点：
1.自动地创建和同步立方体——在运行中创建立方体，并自动地刷新数据来满足实时分析的需要
2.从汇总数据向详细交易数据任意钻取——从立方体随意无缝钻取到整个数据仓库范围的能力
第二点应该是你说的导航吧，而第一点很清晰的说明了它是虚拟出来的，并不是物理存在的，应该是在内存中模拟出来的。你认为呢？

其实我知道你们的产品是一定可以做到的，毕竟你们对中国式的复杂报表很重视，但操作起来是否方便灵活呢？所以我想你给个例子我看看而已，这样方便继续讨
论下去，或者你参考一下我博客的例子，你们是如何实现的，大概说说，截个图来看看就更好了。这个东西的需求还有很多变种的，我们可以深入讨论一下。

[kufee]

老沈：
我找到了一些你们的描述：颗粒问题是数据仓库建模是特别重要的一个概念。颗粒越细，越能满足用户的各种分析需求，但面对海量数据，会遇到性能问题。建立
聚集主题（使数据颗粒变粗）是提升分析性能的重要手段。但聚集会丢失分析的灵活性，甚至会丢失一些维度。举例：对于一个超市的销售主题，最细的颗粒是每
笔业务中的每件商品。如果我们只按天的颗粒来建设主题，则显然无法实现按时间段的分析，也会丢失掉购物常客、职员等纬度信息。
我应该没有理解错你所说的聚集主题，但奇怪的是导航是什么呢？它不能解决你丢失信息的问题吗？

[kufee]

老沈：
还有你们解决数据更新的问题了吗？也就是明细数据发生了变化，你的主题表能同步更新吗？还是定期更新呢？
不过一般是定期更新，同步更新的消耗太大了，那如果是定期的话，这个频率的问题是要看项目情况的，而且是否会影响到服务器的性能也是要考虑的。

[老沈]

kufee：

一个原子主题，可能会根据分析需要建立很多聚集主题（最极端的就是MOLAP的CUBE，基本上是任何可能的维度组合），比如可能会有50个聚集主题，
这样当用户想实现一个报表时，很难去确定到底要用哪个聚集主题，也许某些聚集都不是他创建的。为了方便用户管理和使用，最好的办法是让用户还是只看到原
来那个基本主题，聚集主题是透明，似乎并不存在。当用户对基本主题发起查询时，OLAP引擎自动能从众多聚集主题中找到最佳的一个，然后重定向到这个聚
集主题执行查询。这就是聚集主题导航！

至于聚集主题的刷新，我们允许通过执行计划或事件来触发。执行计划举例：每个月几号凌晨几点可是执行刷新。事件触发：当系统规定的事件（比如ETL），
或通过JavaScript去侦测事件发生时，执行刷新。你说得对，聚集刷新要顾及服务器允许的窗口事件，这需要根据具体的案例来合理安排。

[stlin]

上面有几个观点我分别说明我的认识。
老沈说的聚集主题是ROLAP实现最重要的学术方向之一的，在Microstategy中没有物理cube，正如我前面讲的，olap在
microstrategy中表现为实现内核，你称它为olap产品也好，不是也好，事实上Microstrategy本身并没有将它是Olap产品，
只是业界，市场上这么称谓。你可以把它看成跟brio，Qlikview类似的产品，只是比它们俩更强大一点，具备更强的语义和展示能力。聚集主题是动
态创建的，根据事实表和维度级别组合动态生成，因为维度级别组合的数量太多，所以，有时候会出现多个聚集主题都满足一次查询请求，这时候就需要智能搜索
最佳的一个，microstrategy搜索的依据是看数据量，因为任何事实表和维表的记录数在microstrategy中都是元数据，它成为框架元
数据。所以kufee所讲的“1.自动地创建和同步立方体”是正确的，这里立方体只是一个虚拟的概念，物理上存在的确实是聚集主题的元数据和物理数据。
你们俩之间没有冲突，老沈了解的可能更深入一点。
kufee所讲的“2.从汇总数据向详细交易数据任意钻取”，这个跟聚集主题是没有关系的，microstrategy中钻取有很多表现形式，包括a)
高级别的实体汇总数据钻取到低级别的汇总数据，比如从国家钻到省份，因为microstrategy没有cube的物理结构，所以实体间的关系需要定
义，实体间可以定义父子关系，也可以定义特殊的钻取路径，这些都是它的元数据。b)从汇总数据直接钻取到最明细的交易数据。c)报表层面上a报表可以穿
透到b报表，只要它们俩之间定义好穿透关系。
kufee所讲的mdx功能太弱，无法满足他的需要，这个我承认mdx不是万能的，但我想常用的分析功能它都是支持的，而且还可以自定义函数。当然，我
不是要针对你反驳你什么，我只是把我知道的一些知识表达出现，相信这里有很多同仁会有感触的，因为他们跟我一样曾经研究过这些东西。
我也希望通过ttnn这个平台，把我们这些从事国产BI的孤独的战士联合起来，共同学习进步。因为，我们太缺乏交流，太难了，呵呵。

[cnzhangzhen]

看到这个贴子我很激动，真的。
我自己曾经是一个应用程序程序员，误打误撞进了BI的领域。在一个所谓牛比的公司里，天天写一些无聊的报表。

1 我看到国内真的有人在做BI工具，而不是仅仅是做BI实施的人，从心底里敬佩。

2 我曾经不屑那些将OPENI改改就号称自己研发的国内某些公司。但是我现在改变想法了，能够将诸如pentaho中的东东能做到商用的程度，这本来
就是一个不太容易的过程。

3 我曾经和一些做市场的朋友和老总们接触过，其实BI的概念已经在一些领域被广泛接受，问题是，
1 产品的价格问题。动辄数百万，玩不起。
2 产品的维护和使用问题。根本上能单位内部能玩二次开发的人太少了。请的BIer又太贵。
3 产品不能适合国内的企业、单位的特定需求。

Qlikview是个不错的产品，势头不错。从易用性上来说，正是他们所寻求的模式。

4 我们在这里讨论molap和rolap，其实没什么意义，真正能够解决用户的需求和问题的（同时代价是最小的），就是最好的。

我自己也在业余时间折腾一些小的分析工具，比如PICALO（www.picalo.org）。 大家可以交流一下;)

我目前在一家ERP厂商工作，做一些财务方面的BI报表。

> > 或通过JavaScript去侦测事件发生时，执行刷新。你说得对，聚集刷新要顾及服务器允许的窗口事件，这需要根据具体的案例来合理安排。- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[kufee]

其实我从来就不认为虚拟的cube和聚集主题又什么冲突，因为这是两样东西，即使没有聚集主题虚拟的cube是一样的运作，只是在认为有性能问题的时候
就会用到聚集主题。
2.从汇总数据向详细交易数据任意钻取，我是说mstr的智能立方体也是支持这个功能的，就只是钻取，没什么好说的。
我对mstr的认识根本谈不上深入，只是看了一些他的资料，在一开始我就说明了，而智能立方体是引起了我的共鸣，因为我的工具也有。
至于mdx我从来没说过他功能太弱，它跟sql一样该干什么就干什么，而mondrian的公式能力怎么样，这个每个人有每个人的看法，我说过这是相对
的，我认为它弱是它不能满足我，而stlin认为不弱是它满足了你而已，当然也有可能是我不会用，但你是否可以用它来实现我blog的例子呢？
其实我是欢迎更激烈的讨论的，甚至偏激一点都可以，这样有时更能激发出新的思维，所以你针对我的观点来反驳也是受欢迎的，但我想给个建议你：先充分理解
别人意思，避免断章取义或者误换概念。
至于你的知识，在这里表达可能引起的感触不会很多，因为太零散了；如果你能有个完整的专题应该会引起更多同仁的关注。

[Qing]

看来有些火气了啊。对于Kufee对stlin的批评，说断章取义或是偷换概念，这是所有交流中必定出现的，所以就不用抱怨了，其实每个人都是如此。谁能借助语言清楚表达自己所想？谁能沉下心来理解别人所言？没有这样的人！

kufee一开始抛出这个话题是想寻求一些志同道合者的启发，这个目的应该是达到了吧。你看一下子蹦出多少好汉出来，都是搞产品开发的。在国内搞这个不容易，没什么实际好处，被视为理想主义者。我认为stlin的回复还是非常中肯的，对一些细节问题做了一些剖析，而对于你认为那个开源产品不能够满足你的所需，我想stlin可能是这个产品的拥护者，你说不行，他说行，这当然也是正常的。干脆拿出个案例pk得了。

不过pk也未必有用，因为一旦大家都坚持自己的想法，就算证明什么，那一方输了的都不服气，认为还有什么客观导致了对方胜利。

在对kufee一开始的回复中，我说了一堆，虽然是泼冷水，但其实还是隔着点什么，没捅破。我不想打击这种难得的激情，但也许我还是应该说的直白一点：

开发这个玩意儿，纯粹就是瞎折腾！！！

也许这玩意儿你们自己现在都感到是鸡肋，我觉得你现在需要的换个思路，去花点时间去考虑一下你们要实现的是什么样的价值，你们的核心价值在哪儿。如果你们很少思考这个问题，那么你们现在就停止吧，如果一直在思考，就当我上面说了那个意见是在放屁。

你问什么有意思的玩意儿，我也一直在想，在想一个决策人员到底需要什么。至今，我能想到的那种工具描述了一番，请参见《魔星的故事》。

http://groups.google.com/group/ttnn/browse_thread/thread/bc830ce8531e132c/fed364c9bf717cb7

如果觉得这个讨论有些凌乱，请参加《ttnn bi观点》200805期，那里有比较完整的全文。这玩意儿有意思吗？觉得有意思的，可以一起来探讨一下。

[st lin]

看来技术人员是没得交流了，也许我写的是零散了点，但还是有不少同仁私下联系我，说明确实引起了些感触。有时间我会写一些专题。

因为在这个帖子中看到了一些熟悉的东西，感到兴奋，随便发言了一些想法，没有跟谁争论的本意。我对kufee的工作表示尊敬，也对所有从事这份工作的同仁表示尊敬，包括上面的老沈，gongmd等等。

另外，kufee所说的blog中的例子，我认为确实是mdx或者其他olap产品能够实现的，那些都是olap基本的功能，或许是我没有深刻理解kufee的思想，kufee是否可以在这个帖子中描述一下你认为难实现的报表功能，大家可以一起讨论如何实现，或者其他产品怎么实现的，这样才能提高我们的实现能力。

借这个帖子，我想知道，有没有哪个公司在做业务分析软件，即Analytic application，类似于Hyperion Financial Manager，Planning and Budgeting，EPM或者BSC等。我想做这些软件比纯技术产品应该有更大的市场和机会，而且实现难度可能更小。我想BI在技术上被国外远远抛在后面，业务上应该可以跟紧一点，而且中国人做的业务软件应该更适合国人的使用习惯。

2008/9/6 kufee <WKu...@gmail.com>

[st lin]

Qlikview确实不错，设计思想独特，界面好看，应用简单，cnzhangzhen用过吗，谈谈你的认识。还有，你说的PICALO似乎是个开源软件，能否简单介绍一下，好像跟传统的BI不太一样。 因为我们公司曾经跟Qlikview合作过，期望在我们的ERP产品中集成Qlikview，所以研究过Qlikview，这里也简单介绍一下。

介绍之前，谈一下我对开发BI软件的一个非常强烈的观点，我们这里所谈的BI软件应该是数据仓库之上的报表工具和分析工具，这些BI工具的解决方案我把它分为以下几类：

1） 类似于水晶的纯报表工具。这类产品大概包括模块：报表模板，报表设计器，报表执行引擎。

2） 带BI服务器的报表工具，如水晶企业版。这类产品大概包括模块：报表模板，报表设计器，报表发布，报表服务器，后台调度等。

3） 带olap服务器的解决方案。这类产品包括Olap服务器，OLAP模型设计器，报表设计器，报表服务器，后台调度等。

4） 类似Brio的文件式分析工具。 通过设计Bqy文件，发布到Brio服务器上，或者直接在Brio客户端执行。大概包括模块：Bqy设计器，客户端浏览器，BI服务器，后台调度等。

5） 带有完整数据、业务、界面元数据的BI解决方案。类似于Microstrategy，Oracle BIEE，这些软件的特点是没有明显的OLAP概念，而是从数据仓库、主题、报表、分析等层面分别建立元数据，包括模块：元数据框架设计器，BI服务器。Microstrategy的所有元数据都放在一块，而BIEE的元数据区分清晰，分为物理层、逻辑层、表示层，各层分别有对应的服务器。

6） 完全内存的BI产品，如Qlikview，在内存越来越便宜的今天，这是一个很好的发展方向。

7） 其他。

其实以上分类不是科学的。 国产BI软件一般是1，2，3类的。很多公司的发展思路是先做存报表工具，然后试图发展OLAP工具，因为市场宣传和认识问题，好像没有olap就不能称为BI。他们没有认识到OLAP的真正价值，OLAP只是一个中间模型媒介，它是为前端展示服务的，它的优点是统一的Cube模型带来标准，和预先存储带来查询性能提升。但是从BI产品的价值来讲，OLAP不是不可或缺的。我的观点是如果让我来设计一套新的BI产品，我不会再去试图发展物理存在的OLAP产品，我会在选择没有OLAP的解决方案，简单的解决方案我会选择Brio或者Qlikview这种类型的，复杂的解决方案我会选择Microstrategy或BIEE这种类型的。我有这样的观点，是多年研发和推广的结果，研发上因为OLAP有太多的业界标准，实现这些标准太累了，不实现又不敢向市场宣传，推广上就是我们本公司的人都无法理解Cube，维度概念，他们更习惯于用Brio、Qlikview这样直观的设计和操作方式。

不管有没有物理的OLAP工具，BI产品所实现的分析功能都是一样的，我大胆建议，国内产商可以考虑下不需OLAP的BI解决方案。如果是有实力的产商，Microstrategy和BIEE的完整元数据的BI产品可以参考，这种元数据体系有很多优点，框架统一，结构清晰，可扩展等等。

 

OK，现在介绍Qlikview的特点，优缺点。

特点：

1） 纯内存，因为纯内存存储，因为它有自己独特的内存数据库，内存数据存储结构，它们遵循一个专利技术AQL，这个专利受到各大公司的青睐，SAP、Oracle等都购买了该专利，Qlikview应该是该专利的首创或者第一个应用产品。这个专利的特点是它不遵从传统的关系数据库理论，没有主外键，它的数据是高度压缩的。据产商的数据表明，关系数据库的数据读到它的内存数据库中，可以压缩至少10倍以上。如果有人想看这个专利我这里有，呵呵。

2） 文件式，类似于Brio。一个文件是一个独立的分析文件，这个文件中包括数据、界面等。将文件发布到服务器上，就成为一个主题。

3） 界面风格是页签式的。

4） 整个界面上的组件都是相关联的，严格的MVC模式。这被宣传为点击分析，意思是界面上任何组件动作都可能触发其他组件更新。

5） 具备数据抽取模块，可以写抽取脚本从数据库中根据脚本抽取到内存数据库中。

优点：

1） 界面美观，操作方便，组件方便。

2） 实施简单，上手快。

缺点：

1） 无法动态更新数据，也就是说一个文件一经装载，就无法动态更新它，需要重启服务器。

2） 纯web的客户端还不稳定，bug很多。现在只能用ActiveX，IE插件或者纯客户端。

3） 对内存要求高，性能似乎没有宣传的那么高。

4） 二次开发困难。

以上只是个人认识，不一定准确。

 

2008/9/6 cnzhangzhen <cn.zha...@gmail.com>

[st lin]

    呵呵，这个不算火气。我相信kufee现在正处在非常有激情的创造时期，我也曾经经历过，这种时期非常美好，真的。

    我说过我已经退出这领域，主要是从大环境和个人发展考虑的。我也希望能给各位同仁一点建议，或者能贡献一点经验教训。

    我个人认为从大环境上看，不适合我继续开发BI软件，纯粹的技术产品未能给我和公司带来任何价值，与现有业务产品结合缺少有能力的专业人士，我本人也没有这个能力和魄力。另外据我了解真正完全从事这个领域的公司一般都是小的报表公司，这些报表产品市场前景也不容乐观，除了少数几个。从个人发展考虑，国产BI一般都在国内软件公司做的，这种公司一般工资都不高的，也许你的能力似乎很强，但是如果无法带来商业价值，还只是一堆狗屎。

    我的观点跟Qing有点类似，要嘛做点有价值的东西，要嘛就不做。有价值意味着能带来市场和商业价值，同时也能提高个人的收入。如果不能认识到这一点，你很容易耗费几年青春后发现你成为一个技术高手，但好像没有什么成就感，同时发现就业机会不多，呵呵。

    希望大家都能好好规划一下自己的未来。我想我们这些国产BI软件的勇士们应该是这个论坛里最穷的人了，呵呵。

 

2008/9/6 Qing <happ...@gmail.com>

[老沈]

刚痛快打完一场网球回家，看到了 lin的帖子，澡都还没洗，忍不住要说两句。

一个BI研发的失败着，一个遇到挫折就放弃的人，却臆断国内的IT人都做不好BI产品，都跟你一样懦弱，都跟你一样贫穷，而且使用的是如此恶俗的语言，
真令人惊讶！在此我可以响亮地抽你一拍：请记住这个产品BI@Report，完全国人研发的BI平台！今年的销售收入是好几千万（商业保密起见不便公布
具体数字），核心工程师的收入非常不错。在多次与国外大牌产品的竞标中，凭借优良的技术胜出。

再说标准，OLAP的标准是什么你也讲不明白呀，却被吓得不管深入研究，不敢技术实现，只能理解成吓破胆了。标准只是国外厂商用来控制市场得商业手段，
就如当下议论纷纷的OOXML,MDX同样只是微软独家鼓吹的东东，很遗憾该玩意儿有很多缺陷，就连Oracle等也没有支持，更别提ISO了。你提到
的QlikView，难道不是靠颠覆性的创新技术取胜的吗？要是Qlikview也拘泥于其他公司的所谓标准，说不定也如你的研发一样郁郁而终了。

你开口闭口QlikView，其实根本没理解QlikView的应用价值。由于受内存。架构等因素限制，QlikView只适合做局部数据的BI展现，
换言之，很适合跟OLTP做集成，从而大大提升OLTP系统的报表和查询能力，而并不适合用于构建企业数据中心。客观地讲，你们在ERP上整合
Qlikview是不错的，但要是构建比如一个省级的税收分析平台，选择Qlikview是荒缪的。

国内有很多IT人，常常因为自己学会了、实施过几个国外的产品而沾沾自喜，以为自己就是此行中的老大了，真让人不知道说什么才好。中国的IT届，需要更
多雷军、曹真，虽然过程艰辛，虽然可能摔的鼻青脸肿，就算万一失败，也是一种悲壮！这才是中国IT的希望......

[st lin]

误闯入这个帖子，被这么多高人误会，是我的悲哀。如果有冒犯的地方，请多多见谅。

上面哪里有恶俗的语言？有也是我的自嘲，请不要误会。

我虽然不才，但也没那么傻否定整个中国，我知道人外有人，天外有天，肯定有很多高手。我看过老沈的BI@Report，是做的很不错，希望再接再厉，为中国加油。

如有冒犯，纯属无意，请恕我没有表达清楚，我本善意。

我不会再谈论这些了，祝福大家，Qing帮我删除我的发言。

2008/9/6 老沈 <zls...@sina.com>

[kufee]

是啊，是有点火，但想清楚一点，毕竟不能象要求自己那样要求别人；但对别人的问题的理解后作出回答是基本的礼貌吧，但某人从一开始就不断的变换话题，不
断的显摆，从来没有正面回应过我的问题，这样不如自己开一个显摆贴再找几个fans来感触一下好了，唉！算了，总有这样的人的！

"开始抛出这个话题是想寻求一些志同道合者的启发"，是的，我是这个目的，但没有达到，至今也只有你和老沈的回复给了我更多的思考，另外有一个让我在不
断的解析，他却完全沉浸在自己的知识范围中，不断的显摆着自己以为很高深的知识，但olap就那几个概念，说的没错自然就中肯了，只是不搭调啊！

至于那个开源是否满足，我在前面就说过："如果要实现一个3级的树型都还要做一个临时表来记录父子id的关系的话是不可以接受的。我说的不支持是不准确
的，其实真要实现，没有 哪个工具是做不到的，问题是它的实现足够方便吗？ "其实我很想知道别人的工具是怎么做这个的，但只有老沈告诉我他的产品是可
以的，但也还不知道是怎么做的，我期待他更具体的说明；当然stlin你要是想继续讨论，我希望能从这个问题开始，如果你认为没得交流就算了，敢情你不
是技术人员一样。也欢迎更多的朋友讨论这个问题，给我答案，谢谢。

你说的魔星是个很有意思的东西，其实我也考虑过如何对不同的人展示分析结果，我也计划在后面做挖掘和决策这块，这个东西应该会有启发。

但有价值的东西，不是说你一做就能做出来的，有时也是从没价值的东西演化而来的，就像你说的魔星，我想他的设计师也是在做了很多没价值的东西后得到的灵
感，甚至没价值的东西也是他这个有价值东西的一部分，你认为呢？如果象后面某人说"要做就做有价值的"，会不会眼高手低而一事无成呢？

老沈已经对某人的这翻言论口诛笔伐了，我就不多说什么了，我提醒一下，有价值的东西不是你认为要做就能做好的，不然也不是有价值的东西了，如果真的是有
价值的东西必然是有难度的，如果不能认识到这一点，你很容易-耗费几年青春后发现你什么都没有，同时发现就业机会没有，呵呵。 －－唉，烦！



On 9月6日, 下午7时38分, Qing <happys...@gmail.com> wrote:
> 看来有些火气了啊。对于Kufee对stlin的批评，说断章取义或是偷换概念，这是所有交流中必定出现的，所以就不用抱怨了，其实每个人都是如此。谁能借助语-言清楚表达自己所想？谁能沉下心来理解别人所言？没有这样的人！
>
> kufee一开始抛出这个话题是想寻求一些志同道合者的启发，这个目的应该是达到了吧。你看一下子蹦出多少好汉出来，都是搞产品开发的。在国内搞这个不容易，没-什么实际好处，被视为理想主义者。我认为stlin的回复还是非常中肯的，对一些细节问题做了一些剖析，而对于你认为那个开源产品不能够满足你的所需，我想st-lin可能是这个产品的拥护者，你说不行，他说行，这当然也是正常的。干脆拿出个案例pk得了。

>
> 不过pk也未必有用，因为一旦大家都坚持自己的想法，就算证明什么，那一方输了的都不服气，认为还有什么客观导致了对方胜利。
>
> 在对kufee一开始的回复中，我说了一堆，虽然是泼冷水，但其实还是隔着点什么，没捅破。我不想打击这种难得的激情，但也许我还是应该说的直白一点：
>
> 开发这个玩意儿，纯粹就是瞎折腾！！！
>

> 也许这玩意儿你们自己现在都感到是鸡肋，我觉得你现在需要的换个思路，去花点时间去考虑一下你们要实现的是什么样的价值，你们的核心价值在哪儿。如果你们很少思-考这个问题，那么你们现在就停止吧，如果一直在思考，就当我上面说了那个意见是在放屁。
>
> 你问什么有意思的玩意儿，我也一直在想，在想一个决策人员到底需要什么。至今，我能想到的那种工具描述了一番，请参见《魔星的故事》。http://groups.google.com/group/ttnn/browse_thread/thread/bc830ce8531e...<http://groups.google.com/group/ttnn/browse_thread/thread/bc830ce8531e...>

[kufee]

补充一下，我开这个话题是想了解同行在这个领域上做了些什么，做到什么程度，有什么特点，思路是怎样的，在市场有没有生存的空间，跟国外产品比较的优缺
点等；除了这些我还想了解我们正在做的olap这块在某些方面是否有优势，哪怕是在操作性方面的一丁点优势，或者有人直接告诉我：你的东西没有优势，这
个已经做的很好了，是这么做的......
在我的认识范围内我认为的优势主要有两点（也是写在博客的前两个例子，对这个话题有兴趣的朋友请移步到我的blog），欢迎你们的批评指教：
1、树型纬度的组合；
2、依赖公式的多次计算；

基于以上提到的各个方面的讨论，我认为还不够深入，所以觉得目的还没有达到；希望大家广开思路，集思广益。

On 9月8日, 上午9时35分, kufee <WKu...@gmail.com> wrote:
> 是啊，是有点火，但想清楚一点，毕竟不能象要求自己那样要求别人；但对别人的问题的理解后作出回答是基本的礼貌吧，但某人从一开始就不断的变换话题，不
> 断的显摆，从来没有正面回应过我的问题，这样不如自己开一个显摆贴再找几个fans来感触一下好了，唉！算了，总有这样的人的！
>
> "开始抛出这个话题是想寻求一些志同道合者的启发"，是的，我是这个目的，但没有达到，至今也只有你和老沈的回复给了我更多的思考，另外有一个让我在不
> 断的解析，他却完全沉浸在自己的知识范围中，不断的显摆着自己以为很高深的知识，但olap就那几个概念，说的没错自然就中肯了，只是不搭调啊！
>
> 至于那个开源是否满足，我在前面就说过："如果要实现一个3级的树型都还要做一个临时表来记录父子id的关系的话是不可以接受的。我说的不支持是不准确
> 的，其实真要实现，没有 哪个工具是做不到的，问题是它的实现足够方便吗？ "其实我很想知道别人的工具是怎么做这个的，但只有老沈告诉我他的产品是可
> 以的，但也还不知道是怎么做的，我期待他更具体的说明；当然stlin你要是想继续讨论，我希望能从这个问题开始，如果你认为没得交流就算了，敢情你不
> 是技术人员一样。也欢迎更多的朋友讨论这个问题，给我答案，谢谢。
>
> 你说的魔星是个很有意思的东西，其实我也考虑过如何对不同的人展示分析结果，我也计划在后面做挖掘和决策这块，这个东西应该会有启发。
>
> 但有价值的东西，不是说你一做就能做出来的，有时也是从没价值的东西演化而来的，就像你说的魔星，我想他的设计师也是在做了很多没价值的东西后得到的灵
> 感，甚至没价值的东西也是他这个有价值东西的一部分，你认为呢？如果象后面某人说"要做就做有价值的"，会不会眼高手低而一事无成呢？
>
> 老沈已经对某人的这翻言论口诛笔伐了，我就不多说什么了，我提醒一下，有价值的东西不是你认为要做就能做好的，不然也不是有价值的东西了，如果真的是有
> 价值的东西必然是有难度的，如果不能认识到这一点，你很容易-耗费几年青春后发现你什么都没有，同时发现就业机会没有，呵呵。 －－唉，烦！
>
> On 9月6日, 下午7时38分, Qing <happys...@gmail.com> wrote:
>
>
>

> > 看来有些火气了啊。对于Kufee对stlin的批评，说断章取义或是偷换概念，这是所有交流中必定出现的，所以就不用抱怨了，其实每个人都是如此。谁能借助语--言清楚表达自己所想？谁能沉下心来理解别人所言？没有这样的人！
>
> > kufee一开始抛出这个话题是想寻求一些志同道合者的启发，这个目的应该是达到了吧。你看一下子蹦出多少好汉出来，都是搞产品开发的。在国内搞这个不容易，没--什么实际好处，被视为理想主义者。我认为stlin的回复还是非常中肯的，对一些细节问题做了一些剖析，而对于你认为那个开源产品不能够满足你的所需，我想s-t-lin可能是这个产品的拥护者，你说不行，他说行，这当然也是正常的。干脆拿出个案例pk得了。

>
> > 不过pk也未必有用，因为一旦大家都坚持自己的想法，就算证明什么，那一方输了的都不服气，认为还有什么客观导致了对方胜利。
>
> > 在对kufee一开始的回复中，我说了一堆，虽然是泼冷水，但其实还是隔着点什么，没捅破。我不想打击这种难得的激情，但也许我还是应该说的直白一点：
>
> > 开发这个玩意儿，纯粹就是瞎折腾！！！
>

> > 也许这玩意儿你们自己现在都感到是鸡肋，我觉得你现在需要的换个思路，去花点时间去考虑一下你们要实现的是什么样的价值，你们的核心价值在哪儿。如果你们很少思--考这个问题，那么你们现在就停止吧，如果一直在思考，就当我上面说了那个意见是在放屁。

>
> > 你问什么有意思的玩意儿，我也一直在想，在想一个决策人员到底需要什么。至今，我能想到的那种工具描述了一番，请参见《魔星的故事》。http://groups.google.com/group/ttnn/browse_thread/thread/bc830ce8531e...<http://groups.google.com/group/ttnn/browse_thread/thread/bc830ce8531e...>
>

> > 如果觉得这个讨论有些凌乱，请参加《ttnn bi观点》200805期，那里有比较完整的全文。这玩意儿有意思吗？觉得有意思的，可以一起来探讨一下。- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[Steven]

看样子大家不回答，不广开思路，集思广益是不行了，呵呵

用语委婉一些可能会效果好一点，毕竟大家跟你又不认识，何况还涉及到思路的问题，如果都说要去做俯卧撑就自言自语了：）

做技术这么久，发现做技术的不考虑别人的感受好像是一个通病，包括自己，所以以后准备潜下心来好好改变改变

 

 

2008-09-08

---

Steven

---

发件人： kufee

发送时间： 2008-09-08  15:46:26

收件人： ttnn BI 观点

抄送：

主题： Re: 自己研发BI工具的疑惑

补充一下，我开这个话题是想了解同行在这个领域上做了些什么，做到什么程度，有什么特点，思路是怎样的，在市场有没有生存的空间，跟国外产品比较的优缺

点等；除了这些我还想了解我们正在做的olap这块在某些方面是否有优势，哪怕是在操作性方面的一丁点优势，或者有人直接告诉我：你的东西没有优势，这

个已经做的很好了，是这么做的......

在我的认识范围内我认为的优势主要有两点（也是写在博客的前两个例子，对这个话题有兴趣的朋友请移步到我的blog），欢迎你们的批评指教：

1、树型纬度的组合；

2、依赖公式的多次计算；

基于以上提到的各个方面的讨论，我认为还不够深入，所以觉得目的还没有达到；希望大家广开思路，集思广益。

On 9月8日, 上午9时35分, kufee <WKu...@gmail.com> wrote:

> 是啊，是有点火，但想清楚一点，毕竟不能象要求自己那样要求别人；但对别人的问题的理解后作出回答是基本的礼貌吧，但某人从一开始就不断的变换话题，不

> 断的显摆，从来没有正面回应过我的问题，这样不如自己开一个显摆贴再找几个fans来感触一下好了，唉！算了，总有这样的人的！

>

> "开始抛出这个话题是想寻求一些志同道合者的启发"，是的，我是这个目的，但没有达到，至今也只有你和老沈的回复给了我更多的思考，另外有一个让我在不

> 断的解析，他却完全沉浸在自己的知识范围中，不断的显摆着自己以为很高深的知识，但olap就那几个概念，说的没错自然就中肯了，只是不搭调啊！

>

> 至于那个开源是否满足，我在前面就说过："如果要实现一个3级的树型都还要做一个临时表来记录父子id的关系的话是不可以接受的。我说的不支持是不准确

> 的，其实真要实现，没有 哪个工具是做不到的，问题是它的实现足够方便吗？ "其实我很想知道别人的工具是怎么做这个的，但只有老沈告诉我他的产品是可

> 以的，但也还不知道是怎么做的，我期待他更具体的说明；当然stlin你要是想继续讨论，我希望能从这个问题开始，如果你认为没得交流就算了，敢情你不

> 是技术人员一样。也欢迎更多的朋友讨论这个问题，给我答案，谢谢。

>

> 你说的魔星是个很有意思的东西，其实我也考虑过如何对不同的人展示分析结果，我也计划在后面做挖掘和决策这块，这个东西应该会有启发。

>

> 但有价值的东西，不是说你一做就能做出来的，有时也是从没价值的东西演化而来的，就像你说的魔星，我想他的设计师也是在做了很多没价值的东西后得到的灵

> 感，甚至没价值的东西也是他这个有价值东西的一部分，你认为呢？如果象后面某人说"要做就做有价值的"，会不会眼高手低而一事无成呢？

>

> 老沈已经对某人的这翻言论口诛笔伐了，我就不多说什么了，我提醒一下，有价值的东西不是你认为要做就能做好的，不然也不是有价值的东西了，如果真的是有

> 价值的东西必然是有难度的，如果不能认识到这一点，你很容易-耗费几年青春后发现你什么都没有，同时发现就业机会没有，呵呵。 －－唉，烦！

>

> On 9月6日, 下午7时38分, Qing <happys...@gmail.com> wrote:

>

>

>

> > 看来有些火气了啊。对于Kufee对stlin的批评，说断章取义或是偷换概念，这是所有交流中必定出现的，所以就不用抱怨了，其实每个人都是如此。谁能借助语--言清楚表达自己所想？谁能沉下心来理解别人所言？没有这样的人！

>

> > kufee一开始抛出这个话题是想寻求一些志同道合者的启发，这个目的应该是达到了吧。你看一下子蹦出多少好汉出来，都是搞产品开发的。在国内搞这个不容易，没--什么实际好处，被视为理想主义者。我认为stlin的回复还是非常中肯的，对一些细节问题做了一些剖析，而对于你认为那个开源产品不能够满足你的所需，我想s-t-lin可能是这个产品的拥护者，你说不行，他说行，这当然也是正常的。干脆拿出个案例pk得了。

>

> > 不过pk也未必有用，因为一旦大家都坚持自己的想法，就算证明什么，那一方输了的都不服气，认为还有什么客观导致了对方胜利。

>

> > 在对kufee一开始的回复中，我说了一堆，虽然是泼冷水，但其实还是隔着点什么，没捅破。我不想打击这种难得的激情，但也许我还是应该说的直白一点：

>

> > 开发这个玩意儿，纯粹就是瞎折腾！！！

>

> > 也许这玩意儿你们自己现在都感到是鸡肋，我觉得你现在需要的换个思路，去花点时间去考虑一下你们要实现的是什么样的价值，你们的核心价值在哪儿。如果你们很少思--考这个问题，那么你们现在就停止吧，如果一直在思考，就当我上面说了那个意见是在放屁。

>

> > 你问什么有意思的玩意儿，我也一直在想，在想一个决策人员到底需要什么。至今，我能想到的那种工具描述了一番，请参见《魔星的故事》。http://groups.google.com/group/ttnn/browse_thread/thread/bc830ce8531e...<http://groups.google.com/group/ttnn/browse_thread/thread/bc830ce8531e...>

>

> > 如果觉得这个讨论有些凌乱，请参加《ttnn bi观点》200805期，那里有比较完整的全文。这玩意儿有意思吗？觉得有意思的，可以一起来探讨一下。- 隐藏被引用文字 -

>

> - 显示引用的文字 -

[kufee]

我在这里也只是对stlin的某些发言表示不满，而其他都是认认真真的思考和讨论的，或者吧，我需要更委婉一点，更耐心一点，对前面一些过激的言论，我
表示道歉。
其实我认为不认识也是没关系的，多点以事论是就好了。
我希望大家能回到这个帖子的中心问题，其他的问题我们可以私下讨论，对于前面一些不合适的言论我再次道歉。

On 9月8日, 下午3时59分, "Steven" <tanhm1...@gmail.com> wrote:
> 看样子大家不回答，不广开思路，集思广益是不行了，呵呵
> 用语委婉一些可能会效果好一点，毕竟大家跟你又不认识，何况还涉及到思路的问题，如果都说要去做俯卧撑就自言自语了：）
> 做技术这么久，发现做技术的不考虑别人的感受好像是一个通病，包括自己，所以以后准备潜下心来好好改变改变
>
> 2008-09-08
>

> Steven

> > > 看来有些火气了啊。对于Kufee对stlin的批评，说断章取义或是偷换概念，这是所有交流中必定出现的，所以就不用抱怨了，其实每个人都是如此。谁能借助语---言清楚表达自己所想？谁能沉下心来理解别人所言？没有这样的人！
>
> > > kufee一开始抛出这个话题是想寻求一些志同道合者的启发，这个目的应该是达到了吧。你看一下子蹦出多少好汉出来，都是搞产品开发的。在国内搞这个不容易，没---什么实际好处，被视为理想主义者。我认为stlin的回复还是非常中肯的，对一些细节问题做了一些剖析，而对于你认为那个开源产品不能够满足你的所需，我想-s-t-lin可能是这个产品的拥护者，你说不行，他说行，这当然也是正常的。干脆拿出个案例pk得了。

>
> > > 不过pk也未必有用，因为一旦大家都坚持自己的想法，就算证明什么，那一方输了的都不服气，认为还有什么客观导致了对方胜利。
>
> > > 在对kufee一开始的回复中，我说了一堆，虽然是泼冷水，但其实还是隔着点什么，没捅破。我不想打击这种难得的激情，但也许我还是应该说的直白一点：
>
> > > 开发这个玩意儿，纯粹就是瞎折腾！！！
>

> > > 也许这玩意儿你们自己现在都感到是鸡肋，我觉得你现在需要的换个思路，去花点时间去考虑一下你们要实现的是什么样的价值，你们的核心价值在哪儿。如果你们很少思---考这个问题，那么你们现在就停止吧，如果一直在思考，就当我上面说了那个意见是在放屁。

>
> > > 你问什么有意思的玩意儿，我也一直在想，在想一个决策人员到底需要什么。至今，我能想到的那种工具描述了一番，请参见《魔星的故事》。http://groups.google.com/group/ttnn/browse_thread/thread/bc830ce8531e...<http://groups.google.com/group/ttnn/browse_thread/thread/bc830ce8531e...>
>
> > > 如果觉得这个讨论有些凌乱，请参加《ttnn bi观点》200805期，那里有比较完整的全文。这玩意儿有意思吗？觉得有意思的，可以一起来探讨一下。- 隐藏被引用文字 -
>

> > - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[老沈]

针对kufee执着要求答案的问题，我再次回复：
1、树型纬度的组合；
这只是一个经典的多维分析，你可能把这个问题弄玄乎了。
我们的用户操作方式是这样的：
1）拖放若干个树型维到“行维区”，树型维可以进一步设置层级，或则只挑选某几行，甚至可以错层挑选
2）拖放若干个树型维到“列维区”
3）拖选指标（支持多个，也可以在指标上增加增幅、排名、占比等派生指标选项）
4）选择一些筛选指标
5）Run！
系统自动产生行列都可以收放的报表，用户可以在报表上展开、收起。

2、依赖公式的多次计算；
这个问题似乎说的是公式的嵌套。
一般可以有两种解决非那方案
1）物化常用公式指标
2）把嵌套公式迭代成一较大的公式，这种迭代对用户是透明的

不知以上答复可否让你满意。

[老沈]

当然，内容说说很容易，实现确实有难度。没有做过的难以想象个中艰辛，特别是在WEB上用AJAX技术实现。

这些问题个主题模型关系不大，只要是Star-scheme，都可支持。

个人认为，这种即席查询毕竟还是比较规范的，行＋列＋指标，模型很清楚；真正复杂的是一些变态报表，要做到什么样的报表都能直观、简便地定义出来，而且
无需拼SQL，而且生成的SQL相对还是比较优化的，这才是最难的。也许这可以算是所谓的“从混沌到有序”吧

[hunter]

立足现实，利用好资源，走出自己的路！老沈说的很鼓舞我们的斗志！

也许，社会保障更完善，或者生态有所改善的时候，更有可能出现更多超越雷军，并且取得更大商业成就的玩家。

[kufee]

请原谅我的执着，这两点我们虽然是实现了，但我觉得是不够理想的，想再跟你请教一下。

我所说的操作除了用户的操作，还有立方体开发人员的操作，开发人员的操作主要是数据清洗和元数据定义，也就是事前准备；而中间表，临时表等的事前准备是
我最不愿意看到的，这是最后的一种选择。

由于多个树型纬度（每个纬度都是没有关系的，组合的关系要到分析的过程中通过事实表来确定）的组合是动态构成，下级的纬度是受上层纬度的约束，而明细数
据只记录着这些数据的最末级纬度信息，度量的汇总也是要根据这些约束和纬度层次的，所以我们不得已要个每个树型纬度定义一系列的数据规则，如：它的父
ID字段，最大层级，各级编码长度等等；这是我们在做一个分析之前要准备的元数据，而且要求树型纬度的一些字段必须符合某些规则，如各级编码长度一致；
虽然需要分析的数据都是经过清洗的，问题不大，但我还是认为不够灵活，当然我们也有解决这个问题的另一个方案，就是利用模拟立方体来遍历汇总，但响应速
度会慢一点。

这是我们觉得不够理想的地方，不知道你们的事前准备需要做些什么，有没有这些不灵活的规则。

依赖公式，如果用嵌套来解决也是一种办法，但会增加了用户的操作难度，物化也有问题，会带来额外的工作量；这个我们以后再深入讨论吧。

我不是很了解你提到的ajax这个技术是什么意思，应该和这些问题没什么关系。

感谢你的答复，这样的讨论可能会比较细节一点，如果你觉得太细节了，不想讨论，就不讨论，没关系，以后有机会再请教。也可以聊聊你们的产品在别的方面做
的如何。

[visuallion]

Qing说的很有道理

[mail....@gmail.com]

看了一下老沈公司的产品,易用性似乎不是很好,界面也比较简单啊.
ps 我主要看了分析那一块的.
On Thu, 04 Sep 2008 11:22:26 +0800, 老沈 <zls...@sina.com> wrote:

> 首先鼓励kufee，一定要继续做下去！
>
> 我也负责一个国产BI产品（www.esensoft.com）的设计研发，而且我们已有不少成功案例，这足以让你鼓起勇气了吧？
>
> IT界有很多公司，很会鼓噪名声；有一些公司，则踏踏实实做技术。相信一点：付出总有汇报。沙里淘金，只有金子才能被人记住。呵呵
> >

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[kufee]

做了一些录像放在博客：http://blog.bicubes.com/wkufee/370
欢迎大家拍砖，最好能拍的详细一点。

[kufee]

图形这块现在用的是jfreechart，表现力不够强，打算换chartdirector，大家还有没有更好的图型工具推荐啊。
有一个要求是图要能和表交互。

> > Using Opera's revolutionary e-mail client:http://www.opera.com/mail/- 隐藏被引用文字 -
>
> - 显示引用的文字 -