新型olap的设想

[Qing]

上次跟老沈的聊天中，提到一个问题，当时没有说清楚，今天试着来沉淀一下。

那天他给我演示他们的产品，之后，我有一种感慨，为什么每种产品的olap功能几乎都是一样的。分成多个主题（或者叫做cube）都是左边一棵树，两个分叉，一个分叉是度量，另一个是维度。右边，则是数据区域，可以将维度或度量拖拽过来，旋转，诸如此类。而众多产品之间的区别可能是在细微之处，比如操作的简便性、排序，一些小图标之类的。不管如何，大框架极其雷同（以前提到的google analytics的多维分析不属此类）。

我想这原因可能是产品设计者陷入误区，被现有的功能困住，而非从实际的用户需求出发。毕竟那些大厂商的产品都是那种模样。

但如果我们甩开那些固有的理论、概念，重新定位面对的问题呢？

面对的问题是什么——是人们如何分析事物？放在企业经营中，就是分析企业的经营状况。

把自己放在一个决策者角度，一个分析师角度，应当如何着手解决这个问题，这个分析过程是如何的？

首先必定是看几个重要的指标，这些指标衡量了企业经营中的重要方面，收入状况，客户发展状况，渠道质量水平等等。

如果一个指标出乎意料之外，接着，需要能够从各种不同的角度去分解这些指标，去进一步探查原因。直至发现从某个角度的指标分解暴露出异常，那可能就是原因。

这就是分析的过程。满足这个需求并不需要cube的概念，或者说用户面临的就是一个大cube，里面包罗所有的分析指标和细分角度。用户的操作步骤是这样的：

1、指定分析指标；

2、在可用的分析角度中选择；

看起来跟传统的还是差不多么，但以往的步骤是这样的：

1、进入分析主题（cube）；

2、指定度量；

3、指定维度；

多了一步，只是一个细小的调整，但没有必要的操作为什么不舍弃呢？每个人大概只会关注几个指标，并没有必要按这些指标区分主题。而且传统的olap，主题定义好了，也很难去进行跨主题的关联分析。

因此，首先我觉得应当破除“分析主题”的概念。这个改进可能主要是用户体验层面的，让用户更方便地进行分析。而另一个改进我觉得应当是方向上的——“自动分析”。既然分析过程是从宏观到微观，从不同角度观察指标，去发现异常，去探寻原因。这种人为的操作为什么不能智能化？为什么不能自动地发掘异常，而要分析者自己拽来拽去的？或者要分析主题的设计者去设计好分析路径？或者让用户自己定义指标的异常范围，以进行突出显示？这些难道不是多余的工作么？多余的操作就得去掉。

传统的olap最好应当变成一种不需要拖拽，不需要指定维度和度量的新型olap，这些操作都只是退而求其次的时候才发生的。

啊哈，也许这是值得庆幸的事情，因为在这块领域，其实还有很多空间可以发力。

[innov...@gmail.com]

很多客户都希望做一个包罗万象的大CUBE，不过越大的CUBE性能也是大问题，而且也不一定能真的满足所有需求。

从QING提到的这点来看，其实不是技术问题，而是管理问题，目前的主流工具对于这些需求已经有一定的支持，就看实施时你是怎么去处理用户需求和用户使
用上。

跨主题的需求经常有，但为啥之前要分主题？我想分主题有2大主要因素，一是性能，独立数据集市可独立物理设备解决性能问题，二是管理方便，信息安全能得
到保证，且个性化需求容易得到满足同时又不影响其他主题使用者的需求。

大概目前主流解决方案：
方案一. 数据集市支持BI。 数据集市依然独立建设，如果有跨主题需求，可以在后台架构中分发到不同的数据集市中
方案二. 加强BI前端设计。BI模型里将每个维、指标进行管理，形成企业级统一的维、指标，对于部分跨主题共享的区域，在权限管理上处理。

当然目前最为灵活的方式还是BI模型设计好，维、指标定义清晰，由用户自己设计分别报表。

但是没有维、指标定义的BI，是不容易管控的BI，如果不指定，用户也不清楚这报表咋做的，分析结果是否适当。一般一个主题的用户很少跨主题分析的，普
通职能部门就关注较为特定的视角，如果要进行全方位跨主题分析，多半是总部某种职能管理人员，他们可以独立设计一个数据集市，包罗各种维、指标，如果定
义都清晰，我想他们去自由组合分析也不是问题。

On 4月29日, 下午1时58分, Qing <happys...@gmail.com> wrote:
> 上次跟老沈的聊天中，提到一个问题，当时没有说清楚，今天试着来沉淀一下。
>
> 那天他给我演示他们的产品，之后，我有一种感慨，为什么每种产品的olap功能几乎都是一样的。分成多个主题（或者叫做cube）都是左边一棵树，两个分叉，一个分叉是度量，另一个是维度。右边，则是数据区域，可以将维度或度量拖拽过来，旋转，诸如此类。而众多产品之间的区别可能是在细微之处，比如操作的简便性、排序，一些小图标之类的。不管如何，大框架极其雷同（以前提到的google

> analytics的多维分析 <http://groups.google.com/group/ttnn/msg/99d8abe60d4b9f00>

[zls...@sina.com]

虽然只是一点点改变，我还是觉得Qing的想法是很有价值的。

这里把BI@Report的解决思路贴出来，供各位大侠批评斧正：
1、以传统模式定义各种业务主题的星型模型（在实际项目中，常常是多星模型）
2、在已有主题模型上，按需抽取部分度量（或度量计算后的派生度量）、维度，生成一个虚拟主题，有些业务用户也把虚拟主题叫做指标库。
3、把这个虚拟主题通过权限管理模块分配给某些业务用户。

有了这些做铺垫，业务用户登陆后，将只看到他熟悉的业务指标和用以分类汇总的维度，然后他可以通过拖拉拽实现任意OLAP分析了。

说半天，不知是否能解决qing的问题。

[daiyan]

近期看ttnn中的不少帖子反映的问题，包括这个帖子，都佐证了我们用户的需求和我们面临的挑战，也佐证了我们提供的解决方案的合理性，准确地说，是现实性。

全企业统一视图的指标、维度，和将这些标准化指标进行合理归类的指标体系，是基础，提供可理解、可信赖的业务元数据。

分析主题的定义是OLAP应用体验的保证。主题定义最好也能够打破企业内各部门的局限，和不同层次的用户相对应，有宽度、深度合适的视野（在一些具有综合管理性质的部门都够实现一部分）。这个需要将业务分析场景进行发掘和抽象，需要大量的分析经验知识。

同是，在目前而言，分析主题是需要建立多维模型实现的，其包含指标、维度、粒度这几个基本的属性，也构成业务元数据的一部分。

上述业务元数据需要主动地向用户很好地开放，增强用户（用户的层次很多，水平也参差不齐）对相关内容的理解，只有理解，才能更好发挥分析主题的价值，才能自分析定义出他们自己的制式报表，并进行调整，或者是得出他们所需要的答案。

这是现实的、投资回报清晰合理的、企业现实中一天也离不了的应用。

2009/4/29 <innov...@gmail.com>

--
---------------------------------------------------------------
---代 严  恭祝万事如意！
---DAI YAN    BEST WISHES！

[Qing]

关于第一个问题“破除分析主题”，我想在元数据层面整合，保持现有的olap cube不变，但把他们屏蔽起来，构建一个统一的维度指标库，相当于老沈说的虚拟主题吧，而物理层面，当用户发出一个分析的时候，后台可以实际从具体一个或者多个cube返回数据。

不知道目前对这种统一维度和指标的管理工具是否是欠缺的。

而关于第二个问题——“自动分析”，有没有什么好解决方案？

2009/4/29 <zls...@sina.com>

[innov...@gmail.com]

个人觉得无论怎么自动分析，你也要让系统知道你的分析规则。感觉这个就有点象另一个帖子里讨论数据质量时，某位仁兄提到的业务质量模型，可以自动判断业
务是否正常运行，可以设计伐门、预警等机制。

不过个人认为目前的BI阶段还是多些人为分析为好，自动的这玩意，在很多时候不符合实际情况的，容易给用户产生误导。只有当某个业务点或者某个角度分析
相当成熟定型，才可以用自动来代替人工，降低重复工作。

On 4月30日, 下午1时23分, Qing <happys...@gmail.com> wrote:
> 关于第一个问题"破除分析主题"，我想在元数据层面整合，保持现有的olap

> cube不变，但把他们屏蔽起来，构建一个统一的维度指标库，相当于老沈说的虚拟主题吧，而物理层面，当用户发出一个分析的时候，后台可以实际从具体一个或者多-个cube返回数据。
> 不知道目前对这种统一维度和指标的管理工具是否是欠缺的。
>
> 而关于第二个问题----"自动分析"，有没有什么好解决方案？

>
> 2009/4/29 <zls...@sina.com>
>
>
>
> > 虽然只是一点点改变，我还是觉得Qing的想法是很有价值的。
>
> > 这里把BI@Report的解决思路贴出来，供各位大侠批评斧正：
> > 1、以传统模式定义各种业务主题的星型模型（在实际项目中，常常是多星模型）
> > 2、在已有主题模型上，按需抽取部分度量（或度量计算后的派生度量）、维度，生成一个虚拟主题，有些业务用户也把虚拟主题叫做指标库。
> > 3、把这个虚拟主题通过权限管理模块分配给某些业务用户。
>
> > 有了这些做铺垫，业务用户登陆后，将只看到他熟悉的业务指标和用以分类汇总的维度，然后他可以通过拖拉拽实现任意OLAP分析了。
>

> > 说半天，不知是否能解决qing的问题。- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[visuallion]

对Qing的想法非常赞同。

[daiyan]

个人浅见，从用户发出的分析经由元数据的支持搜寻到对应的cube，技术上应该是相对容易的问题；最困难的问题是不同cube间如何进行运算——现有Oracle（Essbase+BIEE）和IBM（Cognos）等平台所支持的多个cube间union运算，有那么一点点这方面的“能力”，但局限性很多，几乎没有分析能力，实用价值很低。

2009/4/30 Qing <happ...@gmail.com>

关于第一个问题"破除分析主题"，我想在元数据层面整合，保持现有的olap cube不变，但把他们屏蔽起来，构建一个统一的维度指标库，相当于老沈说的虚拟主题吧，而物理层面，当用户发出一个分析的时候，后台可以实际从具体一个或者多个cube返回数据。

不知道目前对这种统一维度和指标的管理工具是否是欠缺的。

而关于第二个问题----"自动分析"，有没有什么好解决方案？

2009/4/29 <zls...@sina.com>

虽然只是一点点改变，我还是觉得Qing的想法是很有价值的。

这里把BI@Report的解决思路贴出来，供各位大侠批评斧正：
1、以传统模式定义各种业务主题的星型模型（在实际项目中，常常是多星模型）
2、在已有主题模型上，按需抽取部分度量（或度量计算后的派生度量）、维度，生成一个虚拟主题，有些业务用户也把虚拟主题叫做指标库。
3、把这个虚拟主题通过权限管理模块分配给某些业务用户。

有了这些做铺垫，业务用户登陆后，将只看到他熟悉的业务指标和用以分类汇总的维度，然后他可以通过拖拉拽实现任意OLAP分析了。

说半天，不知是否能解决qing的问题。

[AnakinSH]

实际应用下来的结果, Essbase + BIEE 和Cognos 还比不上MS AS好用, 至少"分析"的能力可以比较容易的表现出来。

On 5月3日, 下午8时26分, daiyan <daiyani...@gmail.com> wrote:
> 个人浅见，从用户发出的分析经由元数据的支持搜寻到对应的cube，技术上应该是相对容易的问题；最困难的问题是不同cube间如何进行运算----现有Ora-cle（Essbase+BIEE）和IBM（Cognos）等平台所支持的多个cube间union运算，有那么一点点这方面的"能力"，但局限性很多，几乎-没有分析能力，实用价值很低。
>
> 2009/4/30 Qing <happys...@gmail.com>
>
>
>
>
>
> > 关于第一个问题"破除分析主题"，我想在元数据层面整合，保持现有的olap
> > cube不变，但把他们屏蔽起来，构建一个统一的维度指标库，相当于老沈说的虚拟主题吧，而物理层面，当用户发出一个分析的时候，后台可以实际从具体一个或者多-个cube返回数据。

> > 不知道目前对这种统一维度和指标的管理工具是否是欠缺的。
>
> > 而关于第二个问题----"自动分析"，有没有什么好解决方案？
>
> > 2009/4/29 <zls...@sina.com>
>
> > 虽然只是一点点改变，我还是觉得Qing的想法是很有价值的。
>
> >> 这里把BI@Report的解决思路贴出来，供各位大侠批评斧正：
> >> 1、以传统模式定义各种业务主题的星型模型（在实际项目中，常常是多星模型）
> >> 2、在已有主题模型上，按需抽取部分度量（或度量计算后的派生度量）、维度，生成一个虚拟主题，有些业务用户也把虚拟主题叫做指标库。
> >> 3、把这个虚拟主题通过权限管理模块分配给某些业务用户。
>
> >> 有了这些做铺垫，业务用户登陆后，将只看到他熟悉的业务指标和用以分类汇总的维度，然后他可以通过拖拉拽实现任意OLAP分析了。
>
> >> 说半天，不知是否能解决qing的问题。
>
> --
> ---------------------------------------------------------------
> ---代 严 恭祝万事如意！

> ---DAI YAN BEST WISHES！- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[interstage]

关于Qing的提法，我看法如下：
1，关于破除“分析主题”的概念的提法，如果现实BI中“分析主题”和OLAP的CUBE必须对应起来的话，那这个”破除“的建议，我举双手支持，我在
2年前的“OLAP工具毁了BI”文中也提出过，我一直坚持OLAP概念是对的，但是目前现实中的OLAP工具其实毁了BI的本质内涵。但如果“分析主
题“对应于用户的分析思考方向的话，这个就无法被废除，因为人的思考一定是按照一定的惯性方向展开，一直到这个分析主题思考方向通过数据来证实或者证伪
后结束，所以对于olap功能的展现本身的“分析主题“应该存在。所以，也就是我一直坚持的“分析主题”和“维度”剥离的原理，也是目前OLAP工具中
把“分析主题”等同于“维度“造成的。只是如何剥离，我个人建议利用业务部门和IT部门的分工来实现，当然也有别人提出利用数据仓库架构变化和优化实
现。
2，关于”自动分析“，这个提法，Qing没有展开，我姑且理解为了”拖拽“动作规则被主动记录，形成规则模板，然后自动展开，直到指标异常的出现，该
分析被推荐。如果是这样的”自动分析“，这个其实不是”分析“，是一种”指标异常“的固定统计方式，”分析“的方法只有2种，演绎和归纳，演绎的方法适
合目前的OLAP的方式，就是按照人的一定思路惯性方向展开得到证实或者证伪结果；归纳的方法适合目前的数据挖掘，从选择基础算法方向展开计算得到证实
或者证伪结果。所以， ”自动分析“只能从
演绎和归纳这2种方法上进行优化。
3，对于破除“分析主题”的实现，赞同”元数据层面整合，保持现有的olap cube不变，但把他们屏蔽起来，构建一个统一的维度指标库，相当于老沈
说的虚拟主题吧，而物理层面，当用户发出一个分析的时候，后台可以实际从具体一个或者多 个cube返回数据。 “的提法，这个技术就是我一直所说
的”管理视点“的IT技术基础，当然”管理视点“还包含用户的定义角度和结合报表样式的功能。

说完我以上建议，我还是感觉Qing的提法是值得讨论的，说明至少越来越多的人对目前的OLAP工具在实现BI分析效果产生了质疑，只是Qing的提法
比较温和，叫”改进“或者叫”新型OLAP“，而我比较直接，直接说”毁了“。 的确这个领域，的确存在很多空间，可以找出很多机会。

这段时间深刻体会到”反者道之动“这句话的厉害之处，事情做到一定阶段，除了需要反思本身以外，还需要找到反思的方法。”反者道之动“就是一种反思的方
法。

On 4月29日, 下午1时58分, Qing <happys...@gmail.com> wrote:

> 上次跟老沈的聊天中，提到一个问题，当时没有说清楚，今天试着来沉淀一下。
>
> 那天他给我演示他们的产品，之后，我有一种感慨，为什么每种产品的olap功能几乎都是一样的。分成多个主题（或者叫做cube）都是左边一棵树，两个分叉，一 个分叉是度量，另一个是维度。右边，则是数据区域，可以将维度或度量拖拽过来，旋转，诸如此类。而众多产品之间的区别可能是在细微之处，比如操作的简便性、排序 ，一些小图标之类的。不管如何，大框架极其雷同（以前提到的google
> analytics的多维分析 <http://groups.google.com/group/ttnn/msg/99d8abe60d4b9f00>

> 不属此类）。
>
> 我想这原因可能是产品设计者陷入误区，被现有的功能困住，而非从实际的用户需求出发。毕竟那些大厂商的产品都是那种模样。
>
> 但如果我们甩开那些固有的理论、概念，重新定位面对的问题呢？
>
> 面对的问题是什么——是人们如何分析事物？放在企业经营中，就是分析企业的经营状况。
>
> 把自己放在一个决策者角度，一个分析师角度，应当如何着手解决这个问题，这个分析过程是如何的？
>
> 首先必定是看几个重要的指标，这些指标衡量了企业经营中的重要方面，收入状况，客户发展状况，渠道质量水平等等。
>
> 如果一个指标出乎意料之外，接着，需要能够从各种不同的角度去分解这些指标，去进一步探查原因。直至发现从某个角度的指标分解暴露出异常，那可能就是原因。
>
> 这就是分析的过程。满足这个需求并不需要cube的概念，或者说用户面临的就是一个大cube，里面包罗所有的分析指标和细分角度。用户的操作步骤是这样的：
> 1、指定分析指标；
> 2、在可用的分析角度中选择；
>
> 看起来跟传统的还是差不多么，但以往的步骤是这样的：
> 1、进入分析主题（cube）；
> 2、指定度量；
> 3、指定维度；
>

> 多了一步，只是一个细小的调整，但没有必要的操作为什么不舍弃呢？每个人大概只会关注几个指标，并没有必要按这些指标区分主题。而且传统的olap，主题定义好 了，也很难去进行跨主题的关联分析。
>
> 因此，首先我觉得应当破除“分析主题”的概念。这个改进可能主要是用户体验层面的，让用户更方便地进行分析。而另一个改进我觉得应当是方向上的——“自动分析” 。既然分析过程是从宏观到微观，从不同角度观察指标，去发现异常，去探寻原因。这种人为的操作为什么不能智能化？为什么不能自动地发掘异常，而要分析者自己拽来 拽去的？或者要分析主题的设计者去设计好分析路径？或者让用户自己定义指标的异常范围，以进行突出显示？这些难道不是多余的工作么？多余的操作就得去掉。

[ding xining]

让用户自己去选主题，再自己去选择度量和维度，这样做虽然给人感觉工具的灵活性很强，但实际上隐藏了开发工具的人并不是业务用户这个事实。最近很深切的体会到了Qing说的‘去掉多余’环节的情况。很多用户自己本身有一套分析问题的方法，虽然他们不太懂什么叫上钻、下钻这样概念，但实际上他们的分析问题的方法中已经包含了从总到细，从总到分的步骤；虽然他们不懂什么叫BI，但是早已经在工作中运用‘精细化管理’了。

2009/4/29 Qing <happ...@gmail.com>

上次跟老沈的聊天中，提到一个问题，当时没有说清楚，今天试着来沉淀一下。

那天他给我演示他们的产品，之后，我有一种感慨，为什么每种产品的olap功能几乎都是一样的。分成多个主题（或者叫做cube）都是左边一棵树，两个分叉，一个分叉是度量，另一个是维度。右边，则是数据区域，可以将维度或度量拖拽过来，旋转，诸如此类。而众多产品之间的区别可能是在细微之处，比如操作的简便性、排序，一些小图标之类的。不管如何，大框架极其雷同（以前提到的google analytics的多维分析不属此类）。

我想这原因可能是产品设计者陷入误区，被现有的功能困住，而非从实际的用户需求出发。毕竟那些大厂商的产品都是那种模样。

但如果我们甩开那些固有的理论、概念，重新定位面对的问题呢？

面对的问题是什么----是人们如何分析事物？放在企业经营中，就是分析企业的经营状况。

把自己放在一个决策者角度，一个分析师角度，应当如何着手解决这个问题，这个分析过程是如何的？

首先必定是看几个重要的指标，这些指标衡量了企业经营中的重要方面，收入状况，客户发展状况，渠道质量水平等等。

如果一个指标出乎意料之外，接着，需要能够从各种不同的角度去分解这些指标，去进一步探查原因。直至发现从某个角度的指标分解暴露出异常，那可能就是原因。

这就是分析的过程。满足这个需求并不需要cube的概念，或者说用户面临的就是一个大cube，里面包罗所有的分析指标和细分角度。用户的操作步骤是这样的：

1、指定分析指标；

2、在可用的分析角度中选择；

看起来跟传统的还是差不多么，但以往的步骤是这样的：

1、进入分析主题（cube）；

2、指定度量；

3、指定维度；

多了一步，只是一个细小的调整，但没有必要的操作为什么不舍弃呢？每个人大概只会关注几个指标，并没有必要按这些指标区分主题。而且传统的olap，主题定义好了，也很难去进行跨主题的关联分析。

因此，首先我觉得应当破除"分析主题"的概念。这个改进可能主要是用户体验层面的，让用户更方便地进行分析。而另一个改进我觉得应当是方向上的----"自动分析"。既然分析过程是从宏观到微观，从不同角度观察指标，去发现异常，去探寻原因。这种人为的操作为什么不能智能化？为什么不能自动地发掘异常，而要分析者自己拽来拽去的？或者要分析主题的设计者去设计好分析路径？或者让用户自己定义指标的异常范围，以进行突出显示？这些难道不是多余的工作么？多余的操作就得去掉。