文章目录
一、前言
二、数据仓库的定义
三、数据仓库的特点
四、数据仓库的作用
五、数据仓库的架构
六、数据仓库的要求
七 、数据仓库分层
八、数据仓库四个层次的划分
8.1 ODS层
8.2 PDW层
8.3 APP层
九、数据流向
十、数据仓库模型设计基础
10.1 维度数据模型
10.2 维度数据模型建模过程
10.3 维度规范化
10.4 维度数据模型的特点
10.5 星形模型（star schema）
10.6 雪花模型（snowflake schema）
10.7 事实星座模型（Fact Constellation）或星系模型（galaxy schema）
十一、总结
一、前言
最近看了《Hadoop构建数据仓库实践》这本书，收获很多，把一些关于数仓实践的心得我会写出来分享给大家，希望大家伙儿能互相学习，共同进步，☆⌒(*＾-゜)v THX!!
注：本文部分内容摘自《Hadoop构建数据仓库实践》
二、数据仓库的定义
数据仓库是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合，用于对管理决策过程的支持。数据仓库本身并不“生产”任何数据，同时自身也不需要“消费”任何的数据，数据来源于外部，并且开放给外部应用使用。
三、数据仓库的特点
- 面向主题的：数据仓库都是基于某个明确的主题，仅需要与该主题相关的数据，其他的无关细节将会被去掉。
- 集成的：数据仓库里面的数据都是经过ETL（ Extract-Transform-Load 抽取-转换-加载）操作后被集中放到同一个数据源，数据仓库里的数据是来自于各种不同的数据源。
- 随时间变化的：关键数据隐式或者显示地随时间变化而变化。
- 数据相对稳定的：数据装入后一般只是进行查询操作，没有传统数据库的增删改操作。
总结：数据仓库就是整合多个数据源的历史数据进行细粒度的、多维的分析，可以有效地帮助高层管理者或者业务分析人员做出商业战略决策或商业报表。
四、数据仓库的作用
- 可以整合公司的所有业务，建立统一的数据中心。
- 分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果。
- 可以作为各个业务的数据源，形成业务数据互相反馈的良性循环。
- 可以提供数据报表，用于公司的决策等等。
数据处理大致可以分成两大类：
联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。
- OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。
- OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。 OLTP 系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作。OLAP系统则强调数据分析，强调SQL执行市场，强调磁盘I/O，强调分区等。
五、数据仓库的架构
数据采集与分析：数据采集层的任务就是把数据从各种数据源中采集和存储到数据库上，期间有可能会做一些ETL（抽取extra，转化transfer，装载load ）操作。数据源种类可以有多种：
日志：所占份额最大，存储在备份服务器上，业务数据库：如MySQL、Oracle，来自HTTP/FTP的数据：合作伙伴提供的接口，其他数据源：如Excel、CSV等需要手工录入的数据 数据存储与分析。
HDFS是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。
离线数据分析与计算，也就是对实时性要求不高的部分，Hive是不错的选择。
使用Hadoop框架自然而然也提供了MapReduce接口，如果真的很乐意开发Java，或者对SQL不熟，那么也可以使用MapReduce来做分析与计算。
Spark性能比MapReduce好很多，同时使用SparkSQL操作Hive。
数据共享
前面使用Hive、MR、Spark、SparkSQL分析和计算的结果，还是在HDFS上，但大多业务和应用不可能直接从HDFS上获取数据，那么就需要一个数据共享的地方，使得各业务和产品能方便的获取数据。 这里的数据共享，其实指的是前面数据分析与计算后的结果存放的地方，其实就是关系型数据库和NOSQL数据库。
数据应用
报表：报表所使用的数据，一般也是已经统计汇总好的，存放于数据共享层。
接口：接口的数据都是直接查询数据共享层即可得到。
即席查询：即席查询通常是现有的报表和数据共享层的数据并不能满足需求，需要从数据存储层直接查询。一般都是通过直接操作SQL得到。
六、数据仓库的要求
高效率：数据仓库的分析数据一般分为日、周、月、季、年等，可以看出，以日为周期的数据要求的效率最高，要求24小时甚至12小时内，客户能看到昨天的数据分析。由于有的企业每日的数据量很大，如果数据仓库设计的不好，需要延时一到两天才能显示数据，这显然是不能出现这种事情的。
数据质量高：数据仓库所提供的各种信息，肯定要准确的数据。数据仓库通常要经过数据清洗，装载，查询，展现等多个流程而得到的，如果复杂的架构会有更多层次，那么由于数据源有脏数据或者代码不严谨，都可以导致数据不准确或者有错误，如果客户看到错误的信息就可能导致分析出错误的决策，造成损失经济的损失。
扩展性：之所以有的大型数据仓库系统架构设计复杂，是因为考虑到了未来3-5年的扩展性，因为如果在未来需要扩展一些新的功能了，就可以不用重建数据仓库系统，就能很稳定运行。因为重建一个数据创库是比较耗费人力和财力。可扩展性主要体现在数据建模的合理性。
为了达到上述的要求，建立起一个高效率、高数据质量、良好的可扩展性，再加上为了提高建仓的速度，根据在实际生产环境中的经验的总结，于是就提出来了数据仓库的分层概念。
那么到底什么是数据仓库的分层？为什么要分成?数据仓库的分层的好处是什么呢？接下来将介绍关于数据仓库分层的一些概念。
七 、数据仓库分层
分层是数据仓库解决方案中，数据架构设计的一种数据逻辑结构 ，通过分层理念建立的数据仓库，它的可扩展性非常好，这样设计出来的模型架构，可以任意地增减、替换数据仓库中的各个组成部分。
用空间换时间，通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量冗余的数据。
如果不分层的话，如果源业务系统的业务规则发生变化将会影响整个数据清洗过程，工作量巨大。
通过数据分层管理可以简化数据清洗的过程，因为把原来一步的工作分到了多个步骤去完成，相当于把一个复杂的工作拆成了多个简单的工作，把一个大的黑盒变成了一个白盒，每一层的处理逻辑都相对简单和容易理解，这样我们比较容易保证每一个步骤的正确性，当数据发生错误的时候，往往我们只需要局部调整某个步骤即可。
八、数据仓库四个层次的划分
标准的数据仓库分层：ODS（临时存储层），PDW（数据仓库层），MID（数据集市层），APP（应用层）。
ODS：临时存储层，它和源系统数据是同构的，而且这一层数据粒度是最细的，这层的表分为两种，一种是存储当前需要加载的数据，一种是用于存储处理完后的数据。
PDW：数据仓库层，它的数据是干净的数据，是一致的准确的，也就是清洗后的数据，它的数据一般都遵循数据库第三范式，数据粒度和ODS的粒度相同，它会保存bi系统中所有历史数据。
MID：数据集市层，它是面向主题组织数据的，通常是星状和雪花状数据，从数据粒度来讲，它是轻度汇总级别的数据，已经不存在明细的数据了，从广度来说，它包含了所有业务数量。从分析角度讲，大概就是近几年。
APP：应用层，数据粒度高度汇总，但不一定涵盖所有业务数据，只是MID层数据的一个子集。
8.1 ODS层
“面向主题的”，数据运营层是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的ETL之后，装入本层。本层的数据，总体上大多是按照源头业务系统的分类方式而分类的。
例如这一层可能包含的数据表为：人口表（包含每个人的身份证号、姓名、住址等）、机场登机记录（包含乘机人身份证号、航班号、乘机日期、起飞城市等）、银联的刷卡信息表（包含银行卡号、刷卡地点、刷卡时间、刷卡金额等）、银行账户表（包含银行卡号、持卡人身份证号等）等等一系列原始的业务数据。这里我们可以看到，这一层面的数据还具有鲜明的业务数据库的特征，甚至还具有一定的关系数据库中的数据范式的组织形式。
但是，这一层面的数据却不等同于原始数据。在源数据装入这一层时，要进行诸如去噪（例如去掉明显偏离正常水平的银行刷卡信息）、去重（例如银行账户信息、公安局人口信息中均含有人的姓名，但是只保留一份即可）、提脏（例如有的人的银行卡被盗刷，在十分钟内同时有两笔分别在中国和日本的刷卡信息，这便是脏数据）、业务提取、单位统一、砍字段（例如用于支撑前端系统工作，但是在数据挖掘中不需要的字段）、业务判别等多项工作。
8.2 PDW层
数据仓库的主体，在这里从ODS层中获得的数据按照主题建立各种数据模型。例如以研究人的旅游消费为主题的数据集中，便可以结合航空公司的登机出行信息，以及银联系统的刷卡记录，进行结合分析，产生数据集。在这里，我们需要了解四个概念：维（dimension）、事实（Fact）、指标（Index）和粒度（ Granularity）。
PDM层：数据集市，从数据的时间跨度来说，通常是DW层的一部分，按照业务划分，如流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。
8.3 APP层
在这里，主要是提供给数据产品和数据分析使用的数据，一般会存放在es、mysql等系统中供线上系统使用，也可能会存在Hive或者Druid中供数据分析和数据挖掘使用。比如我们经常说的报表数据，或者说那种大宽表，一般就放在这里。
九、数据流向
数据来源层–> ODS层
这里其实就是我们现在大数据技术发挥作用的一个主要战场。 我们的数据主要会有两个大的来源：
业务库：这里经常会使用sqoop来抽取，比如我们每天定时抽取一次。在实时方面，可以考虑用canal监听mysql的binlog，实时接入即可。
埋点日志：线上系统会打入各种日志，这些日志一般以文件的形式保存，我们可以选择用flume定时抽取，也可以用用spark streaming或者storm来实时接入，当然，flume+kafka是企业常用的组合。其它数据源会比较多样性，这和具体的业务相关，不再赘述。
ODS层–> APP层
这里面也主要分两种类型：
每日定时任务型：比如我们典型的日计算任务，每天凌晨算前一天的数据，早上起来看报表。 这种任务经常使用Hive、Spark或者MR程序来计算，最终结果写入Hive、Hbase、Mysql、Es或者Redis中。
实时数据：这部分主要是各种实时的系统使用，比如我们的实时推荐、实时用户画像，一般我们会用Spark Streaming、Storm或者Flink来计算，最后会落入Es、Hbase或者Redis中。
PDW层 --> APP层
pdw分析完的数据，一般借助sqoop传输到关系型数据库如mysql，app层根据业务需要，以可视化的形式展示给决策层（BOSS）。
