数据仓库架构
讲座时间：2012年8月22日晚八点半
本次讲座以本群第一次讲课为基础，添加老师的实战项目讲解。
讲解着：Jimmy 赵坚密
联系方式：[email protected]
讲座预告：
【数据中国】每周三晚八点半在YY 频道85536471免费讲解数据库与商业智能BI 相关知识。详情见http://blog.csdn.net/zhaojianmi1/article/details/7756828
概念
数据仓库之父William H. Inmon在1991年出版的“Building the Data Warehouse”一书中所提出的定义被广泛接受——数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated ）、相对稳定的（Non-Volatile ）、反映历史变化（Time Variant ）的数据集合，用于支持管理决策(Decision Making Support)。
数据库和数据仓库
OLTP 、OLAP
构建数据仓库
数据仓库与数据集市
自顶向下 or 自下而上 （先有仓库 or 先有集市）？
http://www.blogjava.net/mlh123caoer/articles/48206.html
Bill Inmon vs. Ralph Kimball
http://baike.baidu.com/view/3952196.htm
http://baike.baidu.com/view/1332560.htm
标准层次结构
数据源、ODS 、业务核心、多维层
附件
《20120613_J哥语录_第一次课程_数据仓库.docx 》整理者day 梦
数据仓库之父William H. Inmon在1991提出数据仓库的概念
一个面向主题的（Subject Oriented）、集成的（Integrated ）、相对稳定的（Non-Volatile ）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision Making 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 进行编号，然后追加进会员表中，这个东西要怎么实现？ 最后，希望大家能多多讨论，共同进步，最后一起达成所愿。
数据仓库架构
讲座时间：2012年8月22日晚八点半
本次讲座以本群第一次讲课为基础，添加老师的实战项目讲解。
讲解着：Jimmy 赵坚密
联系方式：[email protected]
讲座预告：
【数据中国】每周三晚八点半在YY 频道85536471免费讲解数据库与商业智能BI 相关知识。详情见http://blog.csdn.net/zhaojianmi1/article/details/7756828
概念
数据仓库之父William H. Inmon在1991年出版的“Building the Data Warehouse”一书中所提出的定义被广泛接受——数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated ）、相对稳定的（Non-Volatile ）、反映历史变化（Time Variant ）的数据集合，用于支持管理决策(Decision Making Support)。
数据库和数据仓库
OLTP 、OLAP
构建数据仓库
数据仓库与数据集市
自顶向下 or 自下而上 （先有仓库 or 先有集市）？
http://www.blogjava.net/mlh123caoer/articles/48206.html
Bill Inmon vs. Ralph Kimball
http://baike.baidu.com/view/3952196.htm
http://baike.baidu.com/view/1332560.htm
标准层次结构
数据源、ODS 、业务核心、多维层
附件
《20120613_J哥语录_第一次课程_数据仓库.docx 》整理者day 梦
数据仓库之父William H. Inmon在1991提出数据仓库的概念
一个面向主题的（Subject Oriented）、集成的（Integrated ）、相对稳定的（Non-Volatile ）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision Making 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 进行编号，然后追加进会员表中，这个东西要怎么实现？ 最后，希望大家能多多讨论，共同进步，最后一起达成所愿。