数据仓库的发展和软件的发展共性分析

[innovate511]

很久没发分析型帖子了,
在回答ITPUB的一个帖子里,突然想到点, 需要说一下.

做过国外或者外企项目的可能了解过,
数据仓库DW(不含ODS和集市), 在项目往往分为几个阶段,
EDW, CDW和Staging Area, 并不是DW就一块东西,
大型项目这三个层很可能是三个库分三个机器运行,
加上ODS, DM,
也就是说大型数据仓库项目的数据库至少需要5个数据库.
其中EDW, Inmon的理论已经阐述过, 它的全称是Enterprise
Data Warehouse, 在这个库里,
可以采用3NF设计数据库,目的就是进一步清洗、整理数据，面向主题。
CDW全称是Corporate Data Warehouse，由IBM公司最先提出，
它的任务是把EDW的数据按照星型/雪花模型组织数据，最后生成Kimball提出的conform
table。最后Staging Area,
它作为DW到DM的承上启下的层，主要任务是对事实表、维表根据数据集市的需要进行重组，也就是说从这里到数据集市后，客户就可以通过集市直接享用成果了。

当然中小项目不用这么复杂的设计,就想很多小web系统一样,
架构越简单越好。而大家可能会怀疑大项目数据量大，层次太多会不会效率更低。其实这是误解。我把中间的CDW和staging
area比喻成软件项目的中间件，如果把EDW直接建成星型模型，然后放入DM，就有点象以前软件的两层结构，适合小项目。中间件的作用，就是灵活，扩展性强，并能提高效率。在CDW中，完全可以拆分成比较小的事实表逐个ETL，这样的效率将大大提高，因为CDW相对就比较独立了，包括他们的关联，也是用重新设计的代理键，不用非得把一个主题的维和指标都放在一起。因为没有关系，CDW的主要任务是ETL嘛，在Staging
Area可以根据数据集市的需求再组合一下。从这点来看，功能、模式和普通软件项目的中间件一模一样,
上承EDW, 下输出给数据集市。

最后说明一下，未来部门级的数据集市只是过度，因为针对部门的集市局限性很大，而最终决策需要各个部门的数据联合发掘。同时，如果不同的部门建设的话，很多数据是重复的，这样到后来就可能有重复建设了。但是也不得不通过部门级数据集市过度，因为公司对数据仓库未成熟的东西不敢一次性投资是很正常的考虑。

[刘庆]

看上去确实挺复杂地，没有做过国外或外企项目，但对于这五个数据库比较感兴趣。

 

Innovate说得是ODS、EDW、CDW、Staging Area和DM吧，能不能给出他们的确切定义，以及他们在整个架构中起到的作用呢？另外，即便是一个不是那么太大的数据仓库项目，我想也应该面临同样的问题，那么这五个数据库在小型项目中是如何对应的呢？

 

国内的项目，诸如电信行业的，不能说是小项目，不过大多没有分出这5层，大多仅有ODS、DW和DM而已，而且一般来说也都是逻辑上的分离。如此看来，国内项目做的确实没有国外项目那么精细，这是啥原因呢？

 

On 5/13/06, innovate511 <innov...@gmail.com> wrote:

...

做过国外或者外企项目的可能了解过,
数据仓库DW(不含ODS和集市), 在项目往往分为几个阶段,EDW, CDW和Staging Area, 并不是DW就一块东西,大型项目这三个层很可能是三个库分三个机器运行,加上ODS, DM,也就是说大型数据仓库项目的数据库至少需要5个数据库.
...

[innovate511]

因为大项目中一般会采用Inmon的EDW策略，忠实支持者为NCR。EDW根据Inmon的建议，是采用3NF设计，不是以维度建模模式，而数据集市很多都采用Kimball的建议，典型采用这种模式的项目就是eBay。于是就有个问题了，EDW是目前公认的最好的中心数据仓库的思想，而Kimball的数据集市思想也是目前公认最好的，那如何去平衡呢，是一步就从EDW
ETL到数据集市，还是中间过渡呢？

于是IBM于90年代提出了CDW的概念，作为其中的桥梁。只是刚开始失败率比较高，主要是成本提高，工期沿后。但随着项目经验的提高，现在渐渐被接受。CDW是承接EDW的，也是企业级数据仓库，只是是维度建模的方式，数据源来自EDW，而staging
area就是缓冲区，它是面向数据集市的，作为中心数据仓库和数据集市的桥梁，很多特殊的个性化的ETL在缓冲层完成。

这种设计要求很高，首先是项目有建设企业级数据仓库的需要，也就是说企业的部门级数据集市已经不能满足日益增长的分析需求了，而设计者要熟悉Inmon的EDW思想，建设中心数据仓库。其次要了解部门级各部门或总部、分公司的分析需求，以建数据集市模型。然后再考虑CDW的建设。显然，如果中心数据仓库是EDW，数据集市是维度建模型方式的话，ETL会比较复杂，量也会比较大。如果有CDW的组建，将数据量很大，业务复杂的主题，分散ETL，然后再按主题组合成面向主题的事实表，这样要灵活很多。

[yang...@sina.com]

看了innovate511的再次说明，对这个体系架构还不是很清楚，能否用一个图进行说明，可能比较好些。因为前段时间接触了一下IBM
IIW的东西，对它的体系架构认识仍然比较模糊。还请指点！

[刘庆]

我也有同感，有些晕。

 

我想既然标题是将数据仓库和软件的发展作为类比，是否可以从这方面入手来阐明一下。软件架构中有分层的说法，本话题中数据仓库中ODS、EDW等数据库分离，应该都是基于一种"分层"的理念。系统被水平划分成多层，只有相邻的上下层才会发生交互，例如在软件架构中，数据库、应用服务器、web服务器等等若干层，它讲究web服务器不要和数据库直接打交道，需要向应用服务器请求，由应用服务器作为访问数据库的代理。

 

不过说起来中间件和分层还有些区别，中间件却像是人体器官，它讲究的是"专业化"，自己负责一些别人不太擅长的事情，就像心脏于泵血，别的器官代替不了。因此，消息中间件、事务中间件也都有他们各自的立足之地，中间件的产生，才让整个软件架构变得可以解剖起来，他们有相对标准的接口，就像人的大脑有哪些区域，连了哪些神经一样，只要是个人，都得有那些神经，不然就是秀逗了。

 

如此看，这中间件和ODS、DW、DM的分层有些不相似的地方，但也有相似的。

 

这些单独的概念存在，就必须得有适合生存的环境，得有他们各自的长处。ODS的长处，EDW代替不了，DM也代替不了CDW才是。不然，即使分出来若干层数据库也没有意义。但，他们各自的专长是否已经完全显露出来了呢？

 

譬如说ODS是为了作为从各个数据源获取数据的缓冲，避免数据仓库频繁访问源系统，降低生产风险，这是它的长处。说DM是服务于用户经常变化，对性能颇有的分析需求，这也是DW办不到的。而CDW和Staging Area的长处在什么地方？（我对这两个概念本身就没有多大认识，故此发出此疑问。）
 

On 5/15/06, yang...@sina.com <yang...@sina.com> wrote:

。。。

[innovate511]

我认为这些只有在企业级大项目才会有作用,
部门级的数据集市为中心的项目没有这个必要.
就象一个很小的MIS系统, 业务和数据简单,
就没有必要使用WebSphere或者WebLogic吧.

首先要说,在企业级项目中, 有没有必要一定要建EDW,
如果有必要,是否象Inmon那样, 用3NF模型建设?
这样建设后, 应该是按Inmon说的,
它是历史的、不易变的、面向主题的。那么ODS肯定代替不了EDW。
那么数据集市是面向前端应用的，包括固定报表、即席查询、OLAP、Data
Mining，那么EDW是否能代替数据集市呢？显然也不行，因为即席查询、报表、OLAP等应用，要频繁使用数据库，客户越多，数据库压力越大，特别是复杂查询，3NF模型下需要多表关联，效率始终是个问题，更多更多Kimabll已经阐述过了。

于是剩下的问题就是把EDW的数据拿到数据集市去，数据仓库的设计一般是比较通用的设计，而数据集市则是面向特殊的需求。大家都知道前端工具都含有丰富的SQL功能，能满足你去运算一些客户特定的指标。但是多数人还是不赞成那样，因为这样多了后前端压力很大，而且效率毕竟不如后台，扩展性也差，一旦需求改变和增加，N多固定报表开发或者OLAP开发都得修改，开发维护量非常大。于是数据集市势必要解决绝大多数问题。

然后同一行业不同客户的需求是不同的，很多客户有MTD，QTD，YTD的需求，也就是Month
to
Date这样的，需要数据不定期累加，那么数据仓库肯定没有必要为这些特殊需求而设计，因为数据仓库是代表高一层次的东西，不是针对具体需求的。那么数据集市就需要有对应的事实表去满足这些需求，他们来自哪里？一般建议数据集市不做ETL，为啥，因为很多ETL工作是跨主题的，那么这种情况数据集市就成了数据孤岛，怎么能轻松ETL？那么EDW行不行，显然不行，因为需要一个维度建模方式的DW才行，于是中间层的需求就出现了。

这个中间层要求是以维度建模方式的，也是企业级的数据仓库，IBM称之为Corporate
Data Warehouse.
它继承了EDW的有点，被清洗好了的，面向主题的（不用再重新划分主题），但是建模方式不同。但是它毕竟还是企业级Data
warehouse，并不能满足具体部门级别客户的特殊需求，而不同数据集市也许需要同样的事实表（包括维化事实表），于是针对这些特殊情况，staging
area将在CDW确定后的（不需要ETL）比较分散的事实表合并成面向一个主题的事实表，增加特殊的指标放在事实表里。

这样中间层的作用就是继承EDW，去一步步满足数据集市的需求，到数据集市的时候，我们能看到的是干净、功能齐全的维表、事实表，你既然可以把他们再合并成一个含有丰富维信息的大表，也可以再聚合成报表需要的中间表，也能满足即席查询需求，基本上可以说功能齐全。扩展性上，需求定义一旦变化，你改变前面的CDW既可。数据集市也保留了最低粒度，能满足客户最苛刻的即席查询。

[Jerome]

这个五层的架构以前没有接触过，有一些疑问innovate511可以帮忙解释一下吗？

--CDW全称是Corporate Data Warehouse，由IBM公司最先提出，
--它的任务是把EDW的数据按照星型/雪花模型组织数据，
--最后生成Kimball提出的conform table。
如果采用CIF架构来实现数据仓库的话，类似于Kimball的conform
table的功能
在EDW中已经实现了，为什么还要在EDW和DM之间添加一个CDW层来实现这个功能呢？

--最后Staging Area,
它作为DW到DM的承上启下的层，主要任务是对事实表、
--维表根据数据集市的需要进行重组，也就是说从这里到数据集市后，
--客户就可以通过集市直接享用成果了。
如果在CDW和DM间需要这个Staging
Area的话，那么在EDW和CDW之间是否也应该
有一个层，EDW和CDW之间的差别应该更大一些。而在源数据和EDW之间的那个部件
应该叫做什么？

CDW是否保留全部的历史记录呢？
如果建立五层的话，当源数据发生变化时，一般需要多久反映到DM层？
如果建立五层的话，都哪些层可以提供给用户访问呢？

[innovate511]

因为前提是EDW不是按照维度建模的，是3NF方式，所以无论如何，到数据集市都要经过一个模型的转换。
CDW只保持当前的和history表（比如根据实际情况定义当天到1个月的放在当前表，1个月到1年的数据放在history表里），更老的数据由EDW层放到磁带库就行了，没必要每一层都保持所有数据。
数据源到EDW有一层ODS，大家都知道的吧。由于ODS只是缓冲作用，没有必要ODS也是企业级的设计，可以针对不同的数据源设计。
当数据源发生变化时，一般情况是维度变化，在CDW可以轻松通过Kimball对维度变化的方法去完成。

至于是不是每一个项目都需要这样，我看不一定，只有更合适的，没有最合适的，要不然数据仓库界就没有这么多争论了，就一统天下了。

我这里只是介绍给大家一个新的思路，而且用这个新思路的项目我也参加过，仅作参考。这里有国外网站对此的文章，看看人家的看法，也许能多一些理解。
http://www.dmreview.com/article_sub.cfm?articleId=1040087

[BI4Fun]

软件的发展共性 说的内容不够

[Jerome]

--一般建议数据集市不做ETL，为啥，因为很多ETL工作是跨主题的，那么这种情况数据集市就成了数据孤岛，怎么能轻松ETL？

ETL是跨主题的，数据集市就成了数据孤岛吗？那MD架构中的conformed
table和bus architecture
是做什么用的？

--那么EDW行不行，显然不行，因为需要一个维度建模方式的DW才行，于是中间层的需求就出现了。

EDW为什么不行呢，ETL最关键的就是数据的整合和清洗，而EDW就是ETL的结果，在EDW上建立数据集市
应该是最舒服的事了。

--因为前提是EDW不是按照维度建模的，是3NF方式，所以无论如何，到数据集市都要经过一个模型的转换。

Kimball提出的conformed table分为两种，分别是conformed
dimension（一致性维度）
和conformed fact（一致性事实），这两个概念是和bus
architecture（总线结构）
一起提出的，目的性应该很明显。因为Kimball建立数据仓库的方法是先建立数据集市
再合成数据仓库，为了保证能合并成数据仓库而不是一个烟筒集市，需要在Staging
Area
（数据准备区）先分析好整体的结构包括总线矩阵、一致性维度等。这样才能保证在
建立下一个数据集市时保证合成一个企业的视角。
而Inmon的CIF架构中的EDW中已经建立好的整个企业视角的数据，该整合、该清洗的都完成了，
直接建立数据集市就可以，没有必要再添加一个CDW层做中间过渡。
个人感觉CDW应该是数据仓库发展过程中的一个中间概念，和EDW应该指的是一个东西。
当然了，数据仓库的架构每个企业都有自己的实现方式，也一定各有优缺点，既然IBM有这样的
设计，也一定要他的道理。
随便说了几句，欢迎大家拍砖，呵呵。

[innovate511]

Kimball提出的bus
architecture很多人都看过，在设计的时候，是绘制一个直观的图，把data
mart和dimension看看有哪些交叉点，保持一致性是肯定的，但是由于有多个数据集市可能要使用同一个conformed
table，那么在每一个具体的集市去ETL显然不明智的，工作重复了。
就象上面提到的，EDW到数据集市中，在哪里建dimensional
model？显然不能在EDW建，那么在集市中才开始建？那么Kimball
提出的conformed dimension/fact
table在不同集市中各自建（数据集市可能庞大到几十个甚至上百个）？这才是中间过度的需要，要不然IBM当初就成傻帽了。

[刘庆]

这样干谈太让人犯晕了，不如结合实例说吧，可以来构建一个虚拟的场景。我对电信熟一些，就拿电信业的例子来说吧，当然这不一定有代表性，为了说明自己的观点，大家可以补充这个场景。

 

场景：

X省有C1、C2、C3三个地市，每个地市各自维护自己营帐(A系统)、计费系统(B系统)，分别是A1、A2、A3和B1、B2、B3，现在要在省公司要分析全省的用户发展，实时监控话费。因此需要在省公司建立一个数据仓库系统。数据源就是三个地市的六个系统。

 

需要获取的接口包括（[]给出字段，*标识为主键，>表示该字段有相应代码表。）：

1、用户信息(Userinfo)

[*用户ID、客户ID、用户入网时间、>用户状态]

{每日给出发生数据变化的用户数据}

2、客户信息(CustInfo)

[*客户ID、>性别、年龄、>客户级别、客户注册日期]

{每日给出发生数据变化的客户数据}

3、帐单(Bill)

[*用户ID、客户ID、*帐务月份、*>费用类型、费用]

{每月月初给出上月帐单}

4、通话详单(CDR)

[用户ID、号码、对方号码、通话时间、通话时长、>呼叫类型、>通话地区、通话费、批价时间]

{每隔两个小时给出上两个小时的通话详单}

 

以上四个接口，其中1、2、3接口从每个地市的A系统出，接口4从B系统出。因为各地市的系统独立，编码方式不同，所以诸如用户ID，两个地市可能有重复，而诸如客户级别的编码方式也是不一样。

 

用这个场景来讨论ODS、EDW、CDW、DM都将会是什么样子吧。

[goldenfish3]

ODS区:

   通过数据通路(接口文件或数据库直连,但首选接口文件),存入ODS.

   ODS完成数据合并.其数据结构跟接口需求一致,编码使用类似如下的规范:

  C1的 用户ID = "C1"+C1系统的用户ID

  C2的用户ID ="C2"+C2系统的用户ID 等.

ODS采用文件存储或数据库存储,不保留历史信息.

EDW:

   1.  ODS的数据进入EDW的Staging区. Staging区转换为数据库存储,并在装入时进行数据标准化,如费用类型代码标准化.

   2. 通过ETL,Staging区的数据进入EDW的数据存储区(EDW提供3NF的模型方式存储)

       模型包括: 客户、事件、账务、合约等主题。其中用户信息进入合约主题；客户信息进入客户主 题；帐单信息进入账务主题；通话记录进入事件主题。

       客户主题下可能包含 客户、客户协议历史、客户状态历史、客户轮廓历史（人口地理信息）、客户级别历史等；账务主题包含费用历史等；。。。

CDW：不太认同它作为单独的层次。作为到DM的过渡层次，可以在EDW中通过视图来实现某一时点的数据视图。它为DM的事实表提供基础数据，将分散、致密的3NF模型连接成平面表。实际也就是恢复成例如用户费用表（包含用户ID、用户入网时间、用户状态、号码、对方号码、通话时间、通话时长、>呼叫类型、>通话地区、通话费、批价时间等属性）；

Staging Area：与上面一样作为过渡。

DM： 星型模式

          例如完成用户费用分析

    维度包括：入网时间区间（5年以上、3到5年、1－3年、1年以内）：根据用户入网时间计算；

                       用户状态；

                       通话时长区间（1分钟以内、1－10分钟、10分钟以上等）：根据时长分段；

                       呼叫类型；

                       通话地区（分区内、区间、长途等）；

                      等等；

     度量包括：通话费

   

                                        

 

 

 

 

[Jerome]

我先在这表个态，goldenfish3的架构和建模很好，呵呵。
和CIF的架构方式基本一样，不同的只是名称的不同，
CIF的Staging Area＝goldenfish3的ODS＋Staging区
CIF的ODS goldenfish3没有建立。

采用CIF架构设计
1.建立数据准备区（Staging Area），也称集成转化层。
建立临时表，将接口文件导入临时表，进行整合和清洗，导入给数据仓库准备数据的临时表，这部分客户不能访问
整合和清洗的方法略，goldenfish3的方法就很好
2.操作数据存储（ODS），如果有必要的话
操作数据存储的模型和数据仓库基本上是一样的，只是保存的数据量新一些，小一些
根据需要，可以两个小时导入一次（如果源系统能提供的话），保存一天或者一个月或者更多
这部分用户可以访问。
这部分其实我不太清楚，没有在项目中建立过，DW2.0里ODS的概念和以前好像也不一样了，不建议建立ODS。
3.数据仓库（EDW）
将临时表中准备好的数据导入数据仓库（3NF）
对于变化的数据，增加时间标识（开始时间）和原主键共同作为主键，建立新的记录，进一步增加截至时间。
比如前面提到的用户和客户。
对于帐单和通话详单通过发生时间或者记录时间可以和用户、客户表中的开始时间和截至时间相比，找到当时的用户
或者客户信息。
这样生成的数据仓库访问起来不太容易，一般不建议用户访问，对于用户的各种需求，由开发人员将数据仓库中的数据
导入相应的数据集市或者探索仓库
4.建立数据集市
数据集市采用维度建模，对于象用户和客户这样要建立成维度表的信息，根据需求来决定是否反映变化情况，
数据仓库中保存着所有的历史信息和变化情况，有什么样的需求都可以加载到相应的数据集市。
对于在数据仓库和数据集市之间需不需要staging，我觉得没必要，
staging的意思就是将数据写到硬盘上，Staging
area的意思就是我要保存数据，不管是以文件形式还是数据库形式，
这部分如果通过工具或存储过程可以直接将数据导过去，如果中间非要加一层来存临时数据的话，不能说不可以，
但是总觉得没必要。
对于是否有必要建立CDW，我觉得也没必要，这里如果建立CDW，并且不能用户访问的话，其实就是Staging
area。
kimball提出conformed
table目的就是建立多个数据集市时数据要统一，CIF架构中的表本来就是建立在一起的，
也就是说建立多少个数据集市，都是从一个地方出的数据，
如果要保证在每个数据集市中的相同维度显示的文本都要统一的话，可以在数据仓库中直接把描述信息统一就可以了，
没必要非得建立一个象CDW这样一个大的中间层。
dimensional
model直接建立在数据集市中，数据都是在EDW中出，EDW中的数据已经是一致的了。

采用MD架构设计
1.建立数据准备区（Staging Area）
建立临时表，将接口文件导入临时表，进行整合和清洗，导入给数据集市准备数据的表。根据需要来决定保存数据的时间长短。
建立查找表，加载到内存，用来替换代理键。
建立一致性维度，给其他数据集市做准备。
从功能上来说，MD的staging area 相当于 CIF 的staging
area+EDW。
目的是做好不出烟囱集市的准备后就可以直接建立数据集市，不用等所有的数据都进入数据仓库后再建立数据集市。
这部分用户不能访问。
2.建立数据集市
维度建模来实现数据集市，使用一致性维度。
可以和其他的数据集市一起组合成数据仓库。

bty,这个虚拟的场景有点简单，不能很好的区分CIF和MD的差别和优缺点。

[innovate511]

我想Jerome的假设都是建立在比较单一的情况,
如果是单一的情况, 甚至EDW的建设都可以省去.
比如刘庆列举的例子, 大家觉得有必要建设EDW么?
根本建设数据集市就能满足各种分析需求了嘛.

如果是多种情况, 我们不用说太具体的例子,
不然就说太长了. 比如一个500强制造业,
需要一个全方位企业级数据仓库的建设,
数据源有来自ERP的, 有来自CRM的, 有来自OA的,
还有来自手工录入的调查资料等等.
数据内容含盖采购、生产、库存、销售、定单、物流、财务，以及客户关系数据等。同时客户的部门级以及总部的很多需求（假设之前客户采用数据集市的方式分别满足需求，现在需要统一建立中心企业数据仓库）。

就拿大的分析需求方向来讲，每个大区分公司的重点可能是不同的，总公司的关心点也得考虑。为了节约成本，采购、生产、库存、物流肯定都得分析，为了占领市场制高点，销售、客户关系环节非常重要，
而财务则需要综合以上所有因素得出结果。比如产品这个dimensional-fact,
将会贯穿生产、物流、销售、客户关系、财务等多个主题方向；客户/代理商维贯穿物流、销售、客户关系、财务多个主题。当然，时间、地点维贯穿几乎所有主题。

在我们建设企业级数据仓库的时候，这些通用的事实/维是统一集成ETL，他们不再是孤立的。要过度到数据集市，所谓的conformed
table的建设是必要的，这个时候要在多个不同的数据集市各自形成conformed
table是不符合其特点的，也就是说它还是得在企业级环境下形成，最后分发给数据集市。试问，如果有没这层，conformed
table在哪里形成，是在EDW么？那不是显得不伦不类？

[刘庆]

这下清楚多了，试图将三位的观点总结一下，不知道对不对，有误解之处，请指正。

 

Innovate：
接口->ODS->EDW->CDW->Staging Area->DM
 ODS：和接口结构完全一样
 EDW：3NF建模，保存历史，统一编码
 CDW：多维建模，是否保存历史（？ ）
 Staging Area：？
 DM：维度建模

Godenfish：
接口->ODS->Staging Area->EDW->DM
 ODS：和接口结构相同，作一定的统一编码，不保留历史
 Stage Area：？
 EDW：3NF建模，保存历史，统一编码
 CDW：无
 DM：维度建模

Jerome
CIF：
接口->Staging Area->ODS->EDW->DM
 Staging Area：和接口结构完全一样，进行数据清洗
 ODS：不保存历史，统一编码
 EDW：3NF建模，保存历史
 CDW：无
 DM：维度建模，只有一个

总线架构：
接口->Staging  Area->DM
 Staging Area：先建和接口一样的临时表（或者从文件），进行维度建模，统一编码，建立一致维度
 DM：维度建模

 

我也提出一种以往电信经营分析项目中用过架构，当然，几乎是从总线架构派生出来，只是名称不同而已：

接口->ODS->DW->DM

 ODS：几乎跟接口接口一摸一样，但进行数据清洗和统一编码，代码表完全转换成维表

 DW：维度建模，保存历史

 DM：维度建模

 CDW：无

 Staging Area：无

 

从以上几种架构看，对数据集市，采用维度建模这是没有异议的拉，对于EDW进行3NF并保存历史数据，似乎也是没有异议的。但ODS、DW的功能、特点似乎有些差别。

 

而对于Staging Area，大家都称它为过渡作用，但它究竟是什么，也是很模糊。可以理解为一个数据库，都是放了一些临时表，主要用来存放ETL中间环节的数据。或者它就是文件系统中临时存放中间数据的地方。大家也都认同它不会向最终用户提供访问，那么是否有必要将它作为一个和EDW、DM同一层面的概念呢？从接口到ODS要ETL，就需要Staging Area，从CDW到DM也要ETL，同样需要它。

 

还有godenfish提出来的架构中，为什么在ODS进行一部分统一编码，到EDW中又进行编码标准化的工作？

 

另外，jemore觉得这个场景太简单，不能说明CIF和总线架构的区别，可以改进这个场景啊，当然也能够保证它足够简单。

[goldenfish3]

---

---

首先要说的是，我不认为staing area应该拿出来与ODS/EDW/DM等并列。它位于EDW内的第一层。如果划的更细点，EDW还可以

先landing area（数据降落，就是接口数据落地存储，落地过程中可能会做数据标准化处理）再staing area（登台 文件转入数据库中）。

在ODS中进行统一编码，是说将用户ID等统一编码。而不是编码标准化。例如对于客户类别，

 A1系统中使用  1. 大客户 2.中小客户 区分；

 A2系统中使用 1.大中型客户 2 小客户 区分；

那么在ODS中，对于客户类别可能采用： 1. A1大客户 2. A1中小客户 3.A2大中客户 4  A3小客户 这种代码统一编码方式。

编码的标准化放在了EDW的Staging过程中了，因为ODS是比较薄的一层。要考虑硬件性能等能否支持高效的数据标准化。(如果DW的硬件性能更好，不如放在DW。）当然在ODS进行编码标准化也无不可，也就是将客户类型统一成1.大客户 2 中客户 3 小客户。

也可以有权衡的做法，例如，即记录级的标准化工作在ODS完成，跨记录的标准化在staing area完成。

还有EDW如果与CDW都存在的话，CDW也保留历史，肯定要考虑存储代价。当10T的源数据却需要20T的存储时，决策者很难认同这种方案。也听说过DW采用维度建模而不使用CIF的思路的，只有几个事实表，但有100多个维度。听起来很不可思议，不知道细节是什么样的。

 

[innovate511]

首先CDW只是一个中间层，不然我不会将它比喻为中间件了，当然不会保存历史纪录，只是按照数据集市需求的去从EDW准备待处理数据。在一些英文文档中是这样描述的：CDW
is a temporary layer to extract the data which will be process for XX
layer

所谓staging area,
在这里拿到CDW的dimensional数据，根据数据集市的需要再进行一定的ETL，最后生成大家都知道conformed
tables。要知道一个conformed table,
可不止一个数据集市需要，N多数据集市都可能需要，所以在每个数据集市里去处理，显然很不明智。

再次提到很具体而且必须考虑的问题，试想，如果没有过渡，数据集市需要的conformed
tables怎么去形成？如果这个问题不解决，利用Kimball的思想建设数据集市就是空话。

[dumpedjoe]

这个主题热闹。
CDW是中间层，不好称之为中间件。
对于采用Kimball的维度建模无需引入CDW，CDW是应对传统CIF架构（Inmon对CIF有更新）的EDW和时下流行的MD数据集市有效沟通的一个好的解决方法。
采用CIF构建EDW对各方面要求更高（相对MD），包括对企业全局业务的理解、数据的分布等等，也是时下MD流行的原因。
老外其实很苦啊，当年硬上EDW，没整好（刚上路嘛），IBM聪明啊，搞个CDW，挣钱，不好推倒重来嘛。

[dumpedjoe]

刘庆给出的场景缺少需求，要是加上基于DW的、有需求交叉的多个数据集市的简单需求就能看出MD和EDW引入CDW的区别。比如卡分析和信用风险分析，应该可以看出采用不同方法生成conform
table的不同过程。

[Jerome]

--我想Jerome的假设都是建立在比较单一的情况,
--如果是单一的情况, 甚至EDW的建设都可以省去.
--比如刘庆列举的例子, 大家觉得有必要建设EDW么?
--根本建设数据集市就能满足各种分析需求了嘛.

我想我可能是表达的不太清楚，我只是就着这个例子说几句，没有假设比较单一的情况，呵呵。
觉得单一可能是因为关于数据整合、清洗部分我没有发表言论。
这个例子是比较简单，没必要建立EDW，只是借用这个例子来说明一下架构。
很遗憾，我对电信业务不熟悉，
所以举出的例子中涉及电信业务的内容写不出东西来，
只是泛泛的谈了谈架构。

--再次提到很具体而且必须考虑的问题，试想，如果没有过渡，数据集市需要的conformed

--tables怎么去形成？如果这个问题不解决，利用Kimball的思想建设数据集市就是空话。

innovate511 能详细介绍一下conformed
table要实现的功能或具体的实现方法吗？
我想了解一下为什么在EDW中不能实现同样的功能。
confomed table当然不能在dm中实现，但dimension
model是建立在dm中的。
如果建立EDW的话，不见得要建立confomed
table，但是类似confomed table
的功能是一定要在EDW中实现。
kimball在staging area中就能实现confomed table，
为什么inmon不能在staging
area+edw中实现同样的功能，还要再加一层来实现呢？
如果不考虑费用和复杂性的话，建立CDW当然是一个很好的选择，
可以把这部分功能再细化一下到CDW中。
但是EDW已经够复杂的了，要多大的工程才能允许我们建立更复杂的架构?
个人更倾向于直接建立MD架构。

--Jerome
--CIF：
--接口->Staging Area->ODS->EDW->DM
-- Staging Area：和接口结构完全一样，进行数据清洗
-- ODS：不保存历史，统一编码
-- EDW：3NF建模，保存历史
-- CDW：无
-- DM：维度建模，只有一个
--总线架构：
--接口->Staging Area->DM
-- Staging

Area：先建和接口一样的临时表（或者从文件），进行维度建模，统一编码，建立一致维度

-- DM：维度建模

Staging
Area只是为了处理数据方便建立的一个存储区，建不建立完全看自己的需要，觉得直接能导过去，
就不要staging，觉得中间建立一些表，处理数据方便的话，就可以staging，ETL架构师凭自己的经验来做决定。
当然也可以有一些其他的考虑，如给审计用，保留数据来源的历史记录，导入失败的话重新开始方便一些等。
建不建立要看具体情况，复杂的情况下，可以包括下面几部分，
1.和接口结构一样，装载数据。
1.5中间整合业务等根据需要建立一些表。

2.和EDW结构一样，保存处理好的数据，以便一次性装载入EDW，因为处理的过程有可能是记录级的处理，
一条一条的写入EDW不太好。
简单的情况，就不用staging了。直接用etl工具或写存储过程导。

ODS只是一个可选的。

CIF架构中，DM是不止一个的，在理论上说，数据集市和探索仓库应该是不限数目的。
因为CIF的思想就是，在EDW中是整合好的最全的数据，有什么需要
都可以单独建立数据集市或者探索仓库给他用。

--我也提出一种以往电信经营分析项目中用过架构，当然，几乎是从总线架构派生出来，只是名称不同而已：

--接口->ODS->DW->DM
--
ODS：几乎跟接口接口一摸一样，但进行数据清洗和统一编码，代码表完全转换成维表

-- DW：维度建模，保存历史
-- DM：维度建模
-- CDW：无
-- Staging Area：无

我觉得在这个架构里，ODS就是Staging
Area。只是概念上的不统一。

--首先要说的是，我不认为staing
area应该拿出来与ODS/EDW/DM等并列。它位于EDW内的第一层。如果划的更细点，EDW还可以

--先landing

area（数据降落，就是接口数据落地存储，落地过程中可能会做数据标准化处理）再staing
area（登台 文件转入数据库中）。

把Staging
Area归入EDW，这个只是概念上和物理位置的不同吧。功能应该是一样的。
另外这个ODS是用户可以访问的吗？ODS这个概念尤其的不统一。

--也听说过DW采用维度建模而不使用CIF的思路的，只有几个事实表，但有100多个维度。听起来很不可思议，不知道细节是什么样的。

这怎么可能呢，几个事实表能分析些什么。

[innovate511]

不好意思,可能我也没有完全表达清楚，毕竟一个比较大的讨论.

简单的说,首先建设EDW的项目,到底数据集市是否使用dimensional设计思路,
如果数据集市也是3NF结构,那么我们的讨论点就有很大的出入了,也就没有讨论下去的必要了.

如果数据集市是使用dimensional设计思路,
那么是否把EDW的数据直接影射到数据集市,不需要过度?我想反对者的观点应该是直接把EDW
ETL好的,具有一致性的数据导入数据集市.
我就比较奇怪了,
3NF结构和dimensional结构相差很大,如何能一步到位?

一般来说, 数据集市使用dimensional设计是最好的方法,
现在简单说一下几点不可能直接从EDW到数据集市一步到位的原因:
1. 数据集市需要的很多数据, EDW不能提供,
因为EDW面向企业通用的基本信息,
而数据集市面向客户刁钻的具体应用.
举一个简单的例子,
一家全球性企业需要定义一些特别的时间,
不同国家不同日期为假期, EDW比较难实现,
因为它没有专门的时间维表去记录这些特殊的标志,
如果每个有时间的表都要ETL, 那这个系统估计得死了.
如果直接从EDW到数据集市,
那么放到数据集市去处理如何? 前面我们说过,
由于这是企业级通用的,
应该在数据集市之前就搞定conformed table,
供所有数据集市使用, 不适合数据集市单独使用.
2. EDW不适合使用代理键技术,
因为这个技术是建立在维度建模方式上的.
但如果仅仅在数据集市使用代理键, 那一致性就完了,
也就是说局限了不能使用代理键, 多好的技术呀.

其他的一时没想起来,现在也太晚了,晚上加班才回来看到回帖.
但是如果能解决实际问题,
比如效率、准确性和扩展性, 作为工程,
只要好使就可以, 没有绝对的事情.
但是大项目中加层是很普遍的现象, 因为效率原因,
我们不能让复杂的ETL在海量数据中一步到位,
那是知名的. 但是由于CDW也是面向企业级的,
而又是维度建模方式, 所以显得很特别.

[Jerome]

这个话题讨论到这里也该有个终结了，虽然还遗留的几个颇有争议的问题让人
意犹未尽。在以后的话题中我们还有很多机会来进行更深一步的探讨。
innovate511,goldenfish3,dumpedjoe对数据仓库架构了理解，以及刘庆高度概括的
能力和优美的文笔都让我非常的钦佩。很高兴参与本话题的讨论。

[happy]

看了各位对数据仓库架构的分析，我受益厞浅。有几个问题请教各位：

ODS与EDW一样都采用3NF建模，ODS和接口文件机构相同，那么EDW的结构与ODS有什么不同啊？除了ODS不保存历史记录外，它们各自保存的数据有什么不同？为什么说EDW是面向主题的、集成的？那么与ODS的结构和数据相比，怎么才能做到面向主题且集成？如果哪位可以结合个例子来说就更好了。

我看了inmon关于EDW的解释，说EDW中的数据是light Normalized，是不是可以这么理解：ODS中的数据结构与接口文件和operational data source一样，都是Normalized，数据在ODS中是没有冗余的；而EDW虽然是3NF的，但不是完全按照3NF来进行的，因为对ODS中的数据进行面向主题的组织，并且按照业务进行了集成（具体怎么实现我不会，还要请教大家），所以数据是轻度冗余的。

EDW之后就是DM了，DM是多维模型，数据是冗余的。就这样，数据是逐渐从3NF格式过渡到维度模型的。

不知这样理解对不对？我没有按照EDW来做过项目，还请各位指点！


　　　　　　　　致
礼！


　　　　　　　　happy
　　　　　　　　　　2006-05-22

[innovate511]

这就出现了我前面提到的问题了，我参加过NCR的某省移动的项目，就是采用EDW的方案，但是数据流向DM的时候出现了很多问题，也许这不是NCR的真正实力，DM那块是国内公司去做的。当时的特点就是DM不是维度建模，但是很多东西都是过早汇总，并没有把业务的变化体现在原子粒度上，我想这不是EDW项目的原意吧？

[sean]

"我也提出一种以往电信经营分析项目中用过架构，当然，几乎是从总线架构派生出来，只是名称不同而已：

接口->ODS->DW->DM

 ODS：几乎跟接口接口一摸一样，但进行数据清洗和统一编码，代码表完全转换成维表

 DW：维度建模，保存历史

 DM：维度建模

 CDW：无

 Staging Area：无"

 

 

 

我比较赞同刘庆的观点。层次上越简单越直观越好，具体层次上的扩展可以大点，但层次上尽量扁平化。而且，从目前电信行业的应用来看，即使上10TB的数据量，也应用不到那么复杂的EDW,CDW。

 

和刘庆稍有不同的是，建议在ODS层单独建个用户，存放源数据，即生产系统来的原封不动的数据，做为生产系统数据的快照。结构化存储源数据，有利于提高应用时的速度；另外，建议数据和抽取分离存放，抽取越简单越好，能不用工具最好，我倾向于纯过程ETL。

 

--
sean

[innovate511]

需要补充几点。
看见前面有朋友提到数据集市的问题时候，说采用conformed
tabls建模就可以解决数据集市信息孤岛的问题。要知道Kimball说的conformed
table可不是数据集市层做的，是在数据仓库做的，是面向企业的，不是面向部门的。再重复下他打的比喻，数据仓库好比厨房，各种客户需求的东西都在这里做，数据集市好比餐桌，只是某些特定用户需要的东西，对于这个用户来说，他们要的东西就是孤立的。他们一旦有新的需求，那么就得叫“厨房”帮他们搞定，然后再端上他们的“餐桌”。

正如软件的发展，CS结构不可以么，为啥有的产品或者项目非要用BS结构？结构越来越复杂，并不是搞个花样，而是解决实际的问题。分层处理有几个最大的优点，复杂的业务、海量数据容易处理；新需求容易满足、扩展性强；查询错误容易查询。而且采用conformed
tables模型设计的时候，已经注定企业通用的事实、维是可信的，可重用的，新需求一出来，如果仅仅是部门级特别的需求，可以重用conformed
tables，那么一旦有数据质量问题，我们查询的范围也就缩小了。