我心目中的数据仓库应用

  作者:姜玲
2007/4/30 14:28:03
本文关键字: ttnn 2006年09期

Happy 20060903

又经历了一个数据仓库项目,又有时间来思考这个问了多少遍的问题。

首先是信息。从数据到信息再到知识,这个过程是现在公认的,是我们做各种分析型应用的目标。知识有点太复杂了,先看看信息。什么叫信息?有这么一种解释:通过对数据进行分析找出其中关系,赋予数据以某种意义和关联,这就形成所谓的信息。那么可以看出组成信息的几个要素:规律、关联、意义。

我们可以通过这三个要素来判断我们数据仓库项目的成败(不同的人对项目成败的看法不同,就不深入讨论了)。我们能提供给客户哪种信息呢?

我想无论是在做需求还是架构设计阶段,都应该带着这个问题来思考。我们总是碰到这种现象:到了项目快要结束的时候,发现需求无法控制,发现需求定义不合理,发现技术架构有问题。我没有太多的项目管理经验,可以有很多种途径来解决和控制这些问题,但是我想:如果从项目开始阶段,让客户、项目组成员都明确我们的项目是为了寻找对客户有用的信息,是为了寻找业务中各种现象的规律、关联、意义,从这一点去控制需求,确定需求范围,设计系统流程,就可以使我们最终项目的结果在一个可控的范围内。

一句话:目标明确!

根据这个思路我们来设计一个流程,这个流程表示我们将如何使用我们的数据仓库系统:

1.      明确客户想要干什么?

2.      明确我们系统能够提供什么信息?

3.      根据这些信息,客户能够完成什么任务?

4.      如果用户是带着问题来的,系统应该提供一个导航功能,通过导航来一步步引导客户自己来发现他们所需要的信息。

导航功能应该是这样的:

1)      用户选择要解决的问题(那么在系统中,应该有个问题分类库)

2)      每一个问题对应一种或者多种解决途径,解决途径包括选择哪些分析方法、包括哪些数据、数据的粒度控制在哪种程度;

3)      根据用户选择的结果生成针对这个问题的数据集市(或者是cube、语义层等)

4)      用户可以选择数据展现的方式(当然可以有缺省方式)

5)      生成结果

6)      用户自己根据结果来判断是否能够解决这个问题

7)      如果还需要继续分析,循环2-6


决策支持是一个高智商的过程,不同的用户根据自己的思路可以设计出不同的解决问题的路径(路径的元素是系统设置的,元素之间不同的组合称之为路径),从而得到不同的结果。每个用户在使用数据仓库系统时应该扮演的是参谋的角色,而不应该只是一个键盘操作人员。我理想中的数据仓库项目不应该像我们现在给客户提供的那样,任何一个人进入到系统中,得到的都是同一个结果。

既然是高智商的过程,那么就应该充分借助于人脑,提供更多、更有效的人机交互能力(数据挖掘就可以看作是高于OLAP分析的信息系统)。我们提供给客户数据仓库解决方案是为了帮助客户发现、分析、解决问题的,如果现在的实现达不到我们心中的目标,我们有两种方法来解决:一是借助更高的技术,比如数据挖掘;二是改变我们现有的实现方式。
      
利用数据挖掘技术,固然是好。首先数据挖掘这个技术本身就可以提供数据仓库不能提供的功能,比如预测、分类、查找关联规则,还可以用来进行反恐。但我感觉数据挖掘对于我们国家现阶段信息化应用的程度来说,还是应该算是比较超前的。难道数据仓库就不能解决我们的问题了吗?为什么不先把数据仓库更好的利用起来呢?
      
改变我们现有实现数据仓库的方式,加入更多的人机交互的功能,为的就是在交互的过程中及时的借助人脑的智慧,而计算机的计算能力只应该是辅助作用。在客户、领导做决策分析时,驾驭者永远应该是人,而不是机器本身。

周剑 20060904

我觉得你的意思,应该是说,在用户使用数据仓库系统的时候,依靠的,应该是一个分析流的概念。而我们坐的,应该是收集、整理或者是拿出我们自己在这方面的东西。

每个用户,每个人,都会有自己的发现问题、分析问题、解决问题的手段的习惯的经验,并能根据自己的这套经验和习惯的效率,来不断调整。

这其实,也与其管理水平,管理经验有关。有经验的人,看到报表,能凭直觉发现问题,能根据自己的思维、自己的经验来分析问题、解决问题,通过这种手段,可以提高管理水平、改善企业管理。如果经验达不到的人,面对着我们提供的一大堆的经过整合的面向主题的报表,除了发呆、不用,还能做什么呢。更有甚者,有的领导最希望系统能提供一份文字性的分析报告。

从我们说过来,系统尽可能整合进这些分析经验,比如,告警功能,便是将其判断的经验直接变成我们通过分析判断后的预警提示;又或者,嵌入适宜的行业经验作为预置的分析流。毕竟,对于上面提到的那种没有没有意识和经验的客户,引导他来作需求,耗费的时间和人力,会增加不少,需求调研,也会拖长。

Qing 20060904

西宁总结的这个流程和导航功能,应该就是如周剑所言,是体现一种"分析流",或者说体现一种分析思路吧。
 
但确实也如文中所言,"不同的用户根据自己的思路设计出不同解决问题的路径"。
 
这让我不由想起去年设计的一个玩意儿,名字真的就叫做"分析流"。设计的思想是这样的:市场人员为什么关注数据?是因为有一些指标发生了异动?他要去找这个原因,而常规的,他会从若干几个分析角度去探索原因,例如查看各个地市的指标变化,查看新老用户的变化...这是一个从粗到细的分析过程。这不正是一种流程吗?这个流程就是一种分析思路。
 
并且就用那种类似流程图的方式去实现了"分析流",通过一个分析图表,可以选择下一步分析路径,这有些类似"下钻"的操作,只是它可以选择不同路径而已。
 
然而问题是,分析思路这个玩意儿是个变化太大的东西。即便是当初和市场人员一通确立了这个分析思路,但到交付之后,甚至就在实现过程之中,他们的分析思路已经变了。以至于,交付的"分析流"根本派不上用场。
 
任何感觉变化大的事物,仅仅是因为我们不了解它。对于"分析思路"这个东西,我们就不太了解。我们可以规定业务流程,将它固话下来。可以规定组织结构,将它固定下来。这些东西就是要变化,也不是非常频繁地变化。但对于人的思维,太玄乎了,太具个性化。你没有办法去评判一个人的思路是好的,另一个人是坏的,每个人有自己的习惯,并且也能理直气壮地用自己的习惯去否定别人的思路。
 
有时候,我在想,难道这种分析思路就真的不能固定下来?也许能够。譬如我在一个业务效益好,分析能力强的地市,将他们的分析思路搬到一个落后的地市,这就能够固定下来。但,如何将这种"思路"有形地表达出来呢?通过一种固定流程,也就是上面所言,或者是西宁提到的导航功能,就是一种"有形"的表达。然而,另一方面,如此固化的流程,一定程度上提高了落后地市的分析能力,另一方面,很快,它又成为一种限制。太快了,也许就是过了两个月以后。
 
如此短的蜜月期,让我怀疑,是否还有必要将分析思路用流程、导航的方式表达出来,与其那样,还不如去给分析人员进行培训,启发他们如何去分析数据呢。
 
因此,现在,我已经不大愿意用这种"流程"的方式去表达思路。其实就连自己的思路每个月也在变化。再举个例子,当初做一个专题分析,要设计评估报表,设计几个指标,反映模型效果、活动效果。但你真的就凭这几个指标就能评估营销活动吗?不能,因为模型是不成熟的、活动是不成熟的,这些都需要验证,因此上个月考虑的思路就得变换以下。从一个新的角度去分析。你将结果放在web界面上,做成报表,没人理会。还是手工地做成ppt跟客户说吧。不论是报表,还是ppt,其实都已经包含了分析思路,只是前者是固化的,后者是变化的。
 
是不是有一种放之四海皆准的"分析思路"呢?最原始的它是不变的,但根据非常简单的规则,衍变成新的思路。如此,我们就可以形式化地语言去将它表达出来,并转播出去。再也不是现在这种"只可意会,不可言传"的状态。

也许这个理想的"思路"并不存在,但至少,如果能找到一种放之三海,或两海皆准的,也就凑合了。

责编:姜玲
vsharing微信扫一扫实时了解行业动态
portalart微信扫一扫分享本文给好友

著作权声明:畅享网文章著作权分属畅享网、网友和合作伙伴,部分非原创文章作者信息可能有所缺失,如需补充或修改请与我们联系,工作人员会在1个工作日内配合处理。
畅享
首页
返回
顶部
×
    信息化规划
    IT总包
    供应商选型
    IT监理
    开发维护外包
    评估维权
客服电话
400-698-9918