数据集市 数据仓库

来源:互联网 发布:淘宝客服营销案例 编辑:程序博客网 时间:2024/04/29 04:24

       企业规划数据仓库项目的时候,往往会遇到很多数据仓库软件供应商。各供应商除了推销相关的软件工具外,同时也会向企业灌输许多概念。其中,数据仓库和数据 集市是最常见的两个术语了。各个供应商术语定义不统一、销售策略不一样,这往往会给企业带来很大的混淆。最典型的问题是:到底是先上一个企业级的数据仓库 呢?还是先上一个部门级的数据集市?
  对于数据仓库和数据集市的概念有各种不同的版本,这里参照数据仓库之父Inmon的定义予以说明(来自www.billinmon.com词汇表)。
   数据仓库(如图1所示)是一个集成的、面向主题的数据集合,设计的目的是支持DSS(决策支持系统)功能。在数据仓库里,每个数据单元都和特定的时间相 关。数据仓库包括原子级别的数据和轻度汇总的数据,是面向主题的、集成的、不可更新的(稳定性)、随时间不断变化(不同时间)的数据集合,用以支持经营管 理中的决策制定过程。
  图1所示的以数据仓库为基础的决策支持环境,要求数据仓库能够满足所有最终用户的需求。然而,不同最终用户的需求侧重点 是不同的,这就要求数据仓库存储的数据要具有充分的灵活性,以能够适应各类用户的查询和分析;另一方面,最终用户对信息检索要求是高性能—越快越好。但 是,对数据仓库而言,灵活性和性能(速度)是一对矛盾体—要保障灵活性以满足尽可能多用户的查询需求会影响整个数据仓库的性能。为了解决灵活性和性能之间 的矛盾,数据仓库体系结构中增加了数据集市(如图2所示)—一种小型的部门或工作组级别的数据仓库。数据集市存储为特定用户预先计算好的数据,从而满足用 户对性能的需求。

  “仓库”和“集市”的区别

  数据仓库和数据集市之间的区别,可以用图3(来自www.billinmon.com)直观地表示。
  从图中可以看出,数据仓库中数据结构采用规范化模式(关系数据库设计理论),数据集市的数据结构采用星型模式(多维数据库设计理论)。数据仓库中数据的粒度比数据集市的粒度细。图3反映了数据结构和数据内容的两个特征,其他方面的比较则如表1所示。
 

  数据集市能“独立”吗?

   企业规划数据仓库项目的时候,往往会遇到很多数据仓库软件供应商。各供应商除了推销相关的软件工具外,同时也会向企业灌输许多概念。其中,数据仓库和数 据集市是最常见的两个术语了。各个供应商术语定义不统一、销售策略不一样,这往往会给企业带来很大的混淆。最典型的问题是:到底是先上一个企业级的数据仓 库呢?还是先上一个部门级的数据集市?这其实是是否要上独立型数据集市的问题。
 

  数据集市可以分为两种类型—独立型数据集市和从属型数据集市。独立型数据集市直接从操作型环境获取数据,从属型数据集市从企业级数据仓库获取数据,带有从属型数据集市的体系结构如图2所示。
   数据仓库规模大、周期长,一些规模比较小的企业用户难以承担。因此,作为快速解决企业当前存在的实际问题的一种有效方法,独立型数据集市成为一种既成事 实。独立型数据集市是为满足特定用户(一般是部门级别的)的需求而建立的一种分析型环境,它能够快速地解决某些具体的问题,而且投资规模也比数据仓库小很 多。
  独立型数据集市的存在会给人造成一种错觉,似乎可以先独立地构建数据集市,当数据集市达到一定的规模再直接转换为数据仓库。有些销售人员会推销这种观点,其实质却常常是因为建立企业级数据仓库的销售周期太长以至于不好操作。
   多个独立的数据集市的累积,是不能形成一个企业级的数据仓库的,这是由数据仓库和数据集市本身的特点决定的—数据集市为各个部门或工作组所用,各个集市 之间存在不一致性是难免的。因为脱离数据仓库的缘故,当多个独立型数据集市增长到一定规模之后,由于没有统一的数据仓库协调,企业只会又增加一些信息孤 岛,仍然不能以整个企业的视图分析数据。借用Inmon的比喻:我们不可能将大海里的小鱼堆在一起就构成一头大鲸鱼,这也说明了数据仓库和数据集市有本质 的不同。
  如果企业最终想建设一个全企业统一的数据仓库,想要以整个企业的视图分析数据,独立型数据集市恐怕不是合适的选择;也就是说“先独立 地构建数据集市,当数据集市达到一定的规模再直接转换为数据仓库”是不合适的。从长远的角度看,从属型数据集市在体系结构上比独立型数据集市更稳定,可以 说是数据集市未来建设的主要方向。

  数据集市怎么建?

  建立不同规格的数据仓库、数据集市的成本,国外的咨询机构有专门的评估,在一定程度上可以借鉴。但是这些结果在国内也许并不适用,因为国情不同,在国内的构建成本需要专门的调研。以我们为企业构建的客户主题数据集市为例,一般成本在20万元到50万元人民币之间。
   数据仓库(集市)的设计可以采用迭代式的方法。在迭代式开发中,每个迭代为上一次的结果增加了新的功能。功能增加的顺序要考虑到迭代平衡以及尽早发现重 大风险。通俗地说,就是在正式交货之前多次给客户交付不完善的中间产品“试用”。这些中间产品会有一些功能还没有添加进去、还不稳定,但是客户提出修改意 见以后,开发人员能够更好地理解客户的需求。如此反复,使得产品在质量上能够逐渐逼近客户的要求。这种开发方法周期长、成本高,但是它能够避免整个项目推 倒重来的风险,比较适合大项目、高风险项目。
  理论上讲,应该有一个总的数据仓库的概念,然后才有数据集市。实际建设数据仓库(集市)的时候, 国内很少这么做。国内一般会先从数据集市入手,就某一个特定的主题(比如企业的客户信息)先做数据集市,再建设数据仓库。数据仓库和数据集市建立的先后次 序之分,是和设计方法紧密相关的。而数据仓库作为工程学科,并没有对错之分,主要判别方式应该是能否解决目前存在的实际问题,并为今后可能发生的问题保持 一定的可伸缩性。

  “实战”分析

  数据仓库、数据集市到底如何应用呢?让我们从一个例子分析——假设为某银行构建一个分行级别的数据仓库,再为该分行国际业务部构建从属型数据集市。
   数据仓库的数据来源于银行的业务系统,包括储蓄、卡、个贷、外汇宝、中间业务等等,分析的主题包括客户、渠道、产品等。数据仓库的数据粒度根据分析的要 求而定,一般包括具体的历史记录(存款、取款、外汇交易、POS消费、中间业务缴费记录)。然后,将这些记录汇总到天、周、月、季度、年等各个层次,具体 数据粒度由分析的需求而定。另外,数据仓库还存储一些业务逻辑——为分析而计算的一些指标。比如,客户的价值或客户的忠诚度。这些指标的计算不能通过单一 的业务系统取得,它需要从所有业务上综合考虑,这也是数据仓库系统的优点之一。
  假设整个分行有20万个客户,那么数据仓库将包20万个客户所 有业务的历史数据、汇总数据以及数据仓库指标数据,数据量会达到几十甚至数百G(这只是非常小规模的数据仓库)。为了满足全行所有部门用户的查询和分析, 数据仓库只能采用范式化设计。这样,不管用户有什么查询需求,只要有数据存在就能满足所需。
  假设国际业务部门的客户有2万人(使用外汇宝)。 如果不构建数据集市,他们会直接在数据仓库上查询相关的信息,比如外汇宝客户去年一年外汇交易额在各种交易方式(柜台、网上、电话银行等)的分布。这种查 询的效率和性能是非常低的,如果各个部门的所有用户都直接在数据仓库上查询相关的信息,数据仓库的性能会下降,以至于无法满足大多数用户对性能的需求—— 谁都不愿意为一个简单的查询等待数分钟甚至数小时。因此,构建部门级的数据集市是非常必要的,这主要基于性能上的考虑。国际业务部门的数据集市,集中了数 据仓库中与本部门直接相关的业务数据,例如2万个客户外汇交易的历史数据以及汇总。它采用星型模式(雪片或两者混合),可以方便OLAP工具的查询和分 析。

  背景资料:迭代式开发方法已存在很久了,它还拥有其它不同的名称,如“渐进式”(Evolutionary)、“阶段式” (Staged)、“螺旋式”(Spiral)等等。迭代式开发重要问题之一是迭代阶段需要多长。一般的趋势是让每一个周期尽可能地短,这样就能得到频繁 的反馈,及时地知道开发者所处的状况。


原创粉丝点击