20120613数据仓库架构

鉴于CSDN无故删除博文，本博客不再更新，暂时迁至http://www.db365.net

商业智能群199567325，2012年6月13号《数据仓库架构》，讲解者：赵坚密，本文整理者Day梦。

数据仓库之父William H. Inmon在1991提出数据仓库的概念

一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(DecisionMaking Support)。

数据仓库跟普通的数据库不同

不同点在于数据库面向事务

数据仓库面相分析

一般的数据库就是对小数据量（通常是单条记录）进行操作

所以要求很低得响应时间

并且事务控制很严格，以免业务系统出错

而数据仓库是对大数据量进行处理

将数据处理成分析和挖掘需要的结构

面向事务的数据库通常支持得系统称为oltp

面向分析和挖掘的数据仓库支持的系统称为olap

T 就是事务

a就是分析

联机事务处理和联机分析处理

online transaction processing

事务就是一系列操作的集合

具有acid四个特性

1、原子性

2、一致性

3、隔离性

4、持续永久性

自顶向下 or 自下而上（先有仓库 or 先有集市）？

这个问题一直是业内争论的问题

数据仓库之父Bill Inmon给出的是自顶向下得方式构建数据仓库

也就是现有数据仓库后有数据集市

而另一个人Ralph Kimball意见不同，他认为现有数据集市，然后再组织成数据仓库

先有数据仓库前期的调研需要很长时间

并且需要叫上所有相关的人来收集需求

才能最终确定一个统一得数据仓库模型

大家知道如果一个项目过于庞大，失败的可能性会成指数增长

而且经常会有人缺席

所以这样大费周章

这就是它的缺点

下面将先有数据集市得缺点

先有数据集市的话是通过一个一个部门进行调研

容易收集需求，并且系统容易成型

领导很容易看到，过一会儿就出一个功能模块

这样也更容易得到领导的支持

他的问题在于，当数据集市构建完了之后

需要整合

会发现各个数据集市之间数据不一致

数据准确性是数据仓库的生命

如果各个数据及时之间数据不一致的话

可想而知，在开总裁班会议的时候，各个部门总监拿出来的数据不一致

这就没法继续讨论下去了

业务模型早就有了，并且稳定

那么肯定是第一种方式

我在中软做的外管局的项目，用的是第一种

后来在麦包包用的是第二种（或者第三种）

第三种就是两种方式的结合

咱们看第二种，第二种是各个集市互相独立

也就是说可以并行开发得

但是第三种得方式就是先有一个集市，然后后续开发得集市往第一个集市里靠

并且不断修正以前开发的集市

我在买包包就是采用得这种方式

这种方式扬长避短

在业务稳定

并且熟悉业务的时候可以采用自上而下

往第一个集市靠

就是不断往里增加内容

增加的内容必须与第一个集市一致

通常表现为，公用的维度

还有业务口径也要一致

一般都是选择核心业务来做为第一个集市，满足核心需求后，其他的向其靠拢

一般的企业都是核心完成集市后，就不再进行了。。。估计是其他业务不重要

工期太长，集成商不稳定的原因也有

有时候第一个集市也不一定是最核心得

但是第一个集市肯定是最迫切得

有时候主题就是集市

有时候是集市下面包含N多主题

看公司，看部门规模

dw没有主题得概念

会根据功能以及业务流程来构建

通常oltp系统是第三范式

而olap系统是星型模式

工具很多

我一般用powerdesigner

但是数据仓库并非只有olap层

他也需要遵循第三范式

下面我会讲到数据仓库的层次

不同层次遵循不同的设计规范

第一范式：属性不可再分

就是字段A，不能再分成A.filed1，A.filed2

第二范式实在第一范式得基础上

第二范式其实就是要求有主键

通过主键可以唯一确定一行记录

也就是员工表，必须有个员工ID

部门表必须有部门ＩＤ

第三范式实在第二范式得基础上

消除了字段对非主属性得传递依赖

员工表

员工ID，员工姓名，部门ID，部门名称

这个是不允许得

不能有部门名称

部门会有另一张表

标准层次结构

数据源、ODS、业务核心、多维层

ETL

星型模式

数据源、ODS、业务核心、多维层、报表

ODS是数据源的一次拷贝

很少有数据清洗

这一层数据量也是最大得

必须将各大业务系统的数据抽取到ODS

ODS之后有一层叫业务核心层，有的也叫EDW

EDW做了大量的数据清洗

数据整合

是各大业务系统得数据趋于一致

为后面得多维层打下基础

ODS（Operational Data Store）

EDW是Enterprise Data Warehouse

EDW是各大ODS中各大业务系统数据清洗整合后得结果

多维层，为了各个主题而构建得多维立方体结构

层次大致是这样得

可能里面还有EDW1，EDW2

或者还会有细粒度汇总，粗粒度汇总等等

ods和edw只是两个阶段而已，称呼可能不同。也可能混在一起了

ods通常是以增量形式从数据源定时抽取数据

一般为t+1

抽取过来的数据很少做处理或者不作处理

edw是企业级数据仓库

edw分轻度和重度之分

轻度得edw就是把ods层得相同业务表进行整合

如果相同业务表在ods里只有一个，那么不会在edw里出现

举个例子，客户有两个业务系统

一个财务，一个销售

一个采购，一个销售

其中得客户表两个系统里都有，那么edw数据库会把这两个客户表进行整合

而订单表只有销售系统里有

那么edw里不需要整合

订单表也就不会出现在edw层

也就是说edw层得数据不是全得

还有一种重度得edw就会把所有得ods层的表都搞进来

这两种区别很明显了

第一种轻度得，就是说后面的数据会从ods和edw共同来出

重度得，后面的数据，只会从edw层出

目前很多企业都用得是轻度edw层

招行也是这样做得

但是麦包包却在追求用重度edw层

我不太看好

重度得，比较耗时耗力

优缺点比较明显，一种偷懒

一种比较费劲

当你隔三差五就会来个新业务的时候，

轻度edw会让你发疯的。来一个改一套流程。

重度只需要改接口层面就好了

重度得，对架构师要求非常高

不是一般人能做得

像目前麦包包根本没有这样的人来做

多维其实很简单

基本没什么可讲得

数据仓库最简单的层次就是多维层

没有复杂的思想

星型模式

中间事实表，围绕着一圈维度表

星星就是外面连了一层唯独

雪花可以连好几层唯独

比如，事实表，外面连了个员工表

星星

然后，员工表之后还连了个部门维度，甚至班级维度

雪花

星星只有一层维度

雪花可以有多层维度

雪花模式：不管什么原因，当星型模式的维度需要进行规范化时，星型模式就演进为雪花模式。

就是我说的星型模式唯独规范化，就变成雪花了

ETL工具

有很多

Informatica

Datastage

还有oracle也有

值得一提的是开源的kettle

 

 

后记：J哥讲的好，LTD也很牛逼，要学的东西还有很多啊，看了之后有些疑惑，最后维表到底是干啥用的，真正在数据库中，是不是要按照维表来把处理好的数据导入呢？形成一个多维表结构？表与表之间如何关联呢？如果主键和外键都不设置，如何进行数据处理？比如我要对于会员的消费偏好做一个关联分析，就需要用到会员表和消费记录表么，如果主键和外键都不设置，怎么调取这部分信息？

还有就是假如我是个集团用户，我下属很多子公司，每个子公司都有不同的会员ID，如何将这些会员ID整合进一张表中呢？有说可以用mapping表的，里面设置两个字段，SK和BK，每次自动给填充进来的会员ID进行编号，然后追加进会员表中，这个东西要怎么实现？

最后，希望大家能多多讨论，共同进步，最后一起达成所愿。