华远智德(北京)科技有限公司 Jupiter Consulting (Beijing) Ltd.
  
技术讲堂


您的位置: 首页 技术讲堂 第二课 系统的功能性需求
        第九讲 OLAP的功能性需求(3)

数据分析讲堂
  
第二课 OLAP系统的功能性需求
  
第九讲 OLAP的功能性需求(3)
  
       速度是OLAP一个至关重要的组成部分,这并不是为了让你吃惊,而是为了跟上你思维的速度。OLAP需要支持任意的查询,其中的一些需要根据要求即时计算。例如,一个人可能会从查询上季度整体产品在北京的利润情况来开始他的分析。当看到利润小于预计值的时候,他可能会深入到各个省区查看整体产品利润情况。这里,他可能发现有些省区的利润明显低于其他省区,于是他自然就会查看这些省区中不同产品组的利润情况,总的目标就是寻找一些比较异常的数据来解释某种现象。第一眼查看的时候可能不会发现什么问题。产品销售的区域完全没有问题,回报和生产成本也是如此。但是经过一番观察之后,就会发现非直接成本在这些地区明显偏高。进一步对这些非直接成本分析可以发现近期对于某些产品的赋明显增加,从而导致影响了最终的利润,因为产品价格除非由于市场竞争的缘故,否则通常是不会发生变化的。

         在这个思考过程中的每一步都会有一个查询。每一个查询在上一个查询的基础上进行,从这个意义上讲它是交互的。任何一个进行这种分析工作的人都会希望保持这种势头。如果对于每个查询的平均响应时间是按照天、小时、甚至是用分钟来计算的话,那么就很难进行这种分析活动。一个经常提到的OLAP系统的目标就是提供平均响应时间在5秒以内,而不管查询的类别或者数据库的大小。

         在过去,分析人员为了取得更快的响应速度,可以将数据库抽取到本地,同时系统以单用户完全占用的方式进行。而对于目前系统的挑战是不仅需要提供对于获取和计算请求的高速响应,同时需要工作在跨网络的多用户环境下并且对大数据集进行处理。有些工具通过对所有的汇总进行预计算来满足以上的要求。但是这样做可能会导致数据爆炸。即使能够保存所有的预计算结果,数据库规模的增加事实上也会抵消因此在响应时间上所获得的提高。为了最优化客户端获取的速度,软件工具需要将预计算和即时计算合理地结合起来。

         虽然多用户支持并不是必须的要求,但是考虑到当前服务器领域OLAP产品所占的主导地位,以及实际运用中对多用户支持的需求,我们还是在这里对其做一个简单的描述。企业是一个相互合作的环境。随着权力的下放和分散化,需要有读写决策分析数据权力的员工数量正处在不断增长中。一个区域销售经理发现的问题可能需要和分销或者生产经理协调以确定合适的解决方案。高层主管正在审批的预测报告可能反映了来自十几个,甚至更多部门的数据。对于一个全国企业来说,其中一些部门甚至可能都不是一个省区的。

           和很多复杂的主题一样,多用户支持并不是一个二元选择,这里有一个度的问题。系统可以支持多个用户同时读取各自缓存中的数据,但是没有一个用户具有回写的能力。这样可以满足一些应用,如制作数据来自操作性系统的销售报表。系统也可以支持多用户读写,并且所有的处理都在服务器上进行。这样可以满足预计算制定要求,其中的预计算都是在服务器上进行中央控制的。系统也可以支持多用户读写,同时数据是分布在服务器和客户端上的,但是这就需求服务器智能地判断什么时候数据应该在服务器上或者客户端上处理,服务器提供的多用户缓存放置在哪里。大多数OLAP供应商的目标是最后一种形式的多用户支持,因为这种形式具有最大的灵活性,同时能够最有效地利用企业的计算资源。

       不管是否使用了计算机,信息处理都是任何企业企业管理的一部分。信息处理的主要分类也反映了企业活动的主要分类:操作型和面向决策的分析。术语OLAP用于代表一组产品的时代,是指基于分析的面向决策的信息处理过程中的描述性建模。当前一些流行的术语如数据仓库、决策支持、商业智能或多或少都可以作为OLAP的同义语。对于OLAP的要求源于两处:信息处理的一般要求和OLAP中描述性建模的挑战。这些挑战又分为核心的和非核心的。对于OLAP的核心要求包括了带有层次引用的丰富维结构、对于维和计算的有效性、灵活性、结构和表现的分离、用以支持任意查询的足够快的速度和多用户支持。
  

        首页   |  公司介绍   |  服务理念   |  经营管理   |  企业管理 【TOP】      
版权所有 © 2015 jupiterst.com