目录
一、数据仓库、数据集市概述
1. 数据仓库特点
2.数据仓库组件
3. 数据集市
二、数据仓库、数据集市建模
1. 维度建模的基本概念
2. 维度建模的三种模式
3. 三种模式对比
4. 实例：零售公司销售主题的维度建模
三、数据仓库分层
1. 数据运营层（ODS）
2. 数据仓库层（DW）
3. 数据服务层/应用层（ADS）
一、数据仓库、数据集市概述
1. 数据仓库特点
- 面向主题。如基金数据仓库、基金数据集市、投资人数据集市等。
- 集成性。由多个数据源系统集成。
- 随时间变化。反映某一历史时间点的数据快照。
2.数据仓库组件
数据仓库的核心组件有四个：各源数据库，ETL，数据仓库，前端应用。如下图所示：
(1) 业务系统
业务系统包含各种源数据库，这些源数据库既为业务系统提供数据支撑，同时也作为数据仓库的数据源(注：除了业务系统，数据仓库也可从其他外部数据源获取数据)；
(2) ETL
ETL分别代表：提取Extraction、转换Transformation、加载Load。其中提取过程表示操作型数据库搜集指定数据，转换过程表示将数据转化为指定格式并进行数据清洗保证数据质量，加载过程表示将转换过后满足指定格式的数据加载进数据仓库。数据仓库会周期不断地从源数据库提取清洗好了的数据，因此也被称为"目标系统"；
(3) 前端应用
和操作型数据库一样，数据仓库通常提供具有直接访问数据仓库功能的前端应用，这些应用也被称为BI(商务智能)应用；
3. 数据集市
数据集市可以理解为是一种"小型数据仓库"，它只包含单个主题，且关注范围也非全局。
数据集市可以分为两种，一种是独立数据集市(independent data mart)，这类数据集市有自己的源数据库和ETL架构；另一种是非独立数据集市(dependent data mart)，这种数据集市没有自己的源系统，它的数据来自数据仓库。当用户或者应用程序不需要/不必要/不允许用到整个数据仓库的数据时，非独立数据集市就可以简单为用户提供一个数据仓库的"子集"。
二、数据仓库、数据集市建模
ER建模/关系建模/维度建模，重点讨论维度建模。
1. 维度建模的基本概念
维度建模(dimensional modeling)是专门用于分析型数据库、数据仓库、数据集市建模的方法。
它本身属于一种关系建模方法，但和之前在操作型数据库中介绍的关系建模方法相比增加了两个概念：
(1) 维度表(dimension)
表示对分析主题所属类型的描述。比如"昨天早上张三在京东花费200元购买了一个皮包"。那么以购买为主题进行分析，可从这段信息中提取三个维度：时间维度(昨天早上)，地点维度(京东), 商品维度(皮包)。通常来说维度表信息比较固定，且数据量小。
(2) 事实表(fact table)
表示对分析主题的度量。比如上面那个例子中，200元就是事实信息。事实表包含了与各维度表相关联的外码，并通过JOIN方式与维度表关联。事实表的度量通常是数值类型，且记录数会不断增加，表规模迅速增长。
注：在数据仓库中不需要严格遵守规范化设计原则。本文示例中的主码，外码均只表示一种对应关系，此处特别说明。
2. 维度建模的三种模式
(1) 星形模式
星形模式(Star Schema)是最常用的维度建模方式，下图展示了使用星形模式进行维度建模的关系结构：
可以看出，星形模式的维度建模由一个事实表和一组维表成，且具有以下特点
a. 维表只和事实表关联，维表之间没有关联；
b. 每个维表的主码为单列，且该主码放置在事实表中，作为两边连接的外码；
c. 以事实表为核心，维表围绕核心呈星形分布；
(2) 雪花模式
雪花模式(Snowflake Schema)是对星形模式的扩展，每个维表可继续向外连接多个子维表。下图为使用雪花模式进行维度建模的关系结构：
星形模式中的维表相对雪花模式来说要大，而且不满足规范化设计。雪花模型相当于将星形模式的大维表拆分成小维表，满足了规范化设计。然而这种模式在实际应用中很少见，因为这样做会导致开发难度增大，而数据冗余问题在数据仓库里并不严重。
(3) 星座模式
星座模式(Fact Constellations Schema)也是星型模式的扩展。基于这种思想就有了星座模式：
前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。
3. 三种模式对比
归纳一下，星形模式/雪花模式/星座模式的关系如下图所示：
雪花模式是将星型模式的维表进一步划分，使各维表均满足规范化设计。而星座模式则是允许星形模式中出现多个事实表。本文后面部分将具体讲到这几种模式的使用，请读者结合实例体会。
4. 实例：零售公司销售主题的维度建模
在进行维度建模前，首先要了解用户需求。而笔者在数据库系列的第一篇就讲过，ER建模是当前收集和可视化需求的最佳技术。因此假定和某零售公司进行多次需求PK后，得到以下ER图：
随后可利用建模工具将ER图直接映射到关系图：
需求搜集完毕后，便可进行维度建模了。本例采用星形模型维度建模。但不论采取何种模式，维度建模的关键在于明确下面四个问题：
(1) 哪些维度对主题分析有用？
本例中，根据产品(PRODUCT)、顾客(CUSTOMER)、商店(STORE)、日期(DATE)对销售额进行分析是非常有帮助的；
(2) 如何使用现有数据生成维表？
a. 维度PRODUCT可由关系PRODUCT，关系VENDOR，关系CATEGORY连接得到；
b. 维度CUSTOMER和关系CUSTOMER相同；
c. 维度STORE可由关系STROE和关系REGION连接得到；
d. 维度CALENDAR由关系SALESTRANSACTION中的TDate列分离得到；
(3) 用什么指标来"度量"主题？
本例的主题是销售，而销量和销售额这两个指标最能直观反映销售情况；
(4) 如何使用现有数据生成事实表？
销量和销售额信息可以由关系SALESTRANSACTION和关系SOLDVIA，关系PRODUCT连接得到；
明确这四个问题后，便能轻松完成维度建模：
细心的读者会发现三个问题：1. 维表不满足规范化设计(不满足3NF)；2. 事实表也不满足规范化设计(1NF都不满足)； 3. 维度建模中各维度的主码由***ID变成***Key；
对于前两个问题，由于当前建模环境是数据仓库，而没有更新操作，所以不需要严格做规范化设计来消除冗余避免更新异常。
因此虽然可以以雪花模型进行维度建模，如下所示：
但这样会加大查询人员负担：每次查询都涉及到太多表了。因此在实际应用中，雪花模型仅是一种理论上的模型。星座模型则出现在"维度建模数据仓库"中，本文后面将会讲到。
对于第三个问题，***Key这样的字段被称为代理码(surrogate key)，它是一个通过自动分配整数生成的主码，没有任何其他意义。使用它主要是为了能够处理"缓慢变化的维度"，本文后面会仔细分析这个问题，这里不纠结。
三、数据仓库分层
数据分层，每个企业根据自己的业务需求可以分成不同的层次，但是最基础的分层思想，理论上数据分为三个层：数据运营层(ODS, Operation Data Store)、数据仓库层(DWD Data Warehouse Details，DWB Data Warehouse Base，DWS Data Warehouse Service)、数据服务层(ADS, Application Data Service)。基于这个基础分层之上，再提交信息的层次，来满足不同的业务需求。
1. 数据运营层（ODS）
- ODS：Operation Data Store 数据准备区，也称为贴源层。数据仓库源头系统的数据表通常会原封不动的存储一份，这称为ODS层，是后续数据仓库加工数据的来源。
- ODS层数据的来源方式：
- 业务库
- 经常会使用sqoop来抽取，例如每天定时抽取一次。
- 实时方面，可以考虑用canal监听mysql的binlog，实时接入即可。
- 埋点日志
- 日志一般以文件的形式保存，可以选择用flume定时同步
- 可以用spark streaming或者Flink来实时接入
- kafka也OK
- 消息队列：即来自ActiveMQ、Kafka的数据等。
2. 数据仓库层（DW）
DW数据分层，由下到上为DWD，DWB，DWS。
- DWD：data warehouse details 细节数据层，是业务层与数据仓库的隔离层。主要对ODS数据层做一些数据清洗和规范化的操作。
- 数据清洗：去除空值、脏数据、超过极限范围的
- DWB：data warehouse base 数据基础层，存储的是客观数据，一般用作中间层，可以认为是大量指标的数据层。
- DWS：data warehouse service 数据服务层，基于DWB上的基础数据，整合汇总成分析某一个主题域的服务数据层，一般是宽表。用于提供后续的业务查询，OLAP分析，数据分发等。
- 用户行为，轻度聚合
- 主要对ODS/DWD层数据做一些轻度的汇总。
3. 数据服务层/应用层（ADS）
- ADS：Application Data Service应用数据服务，该层主要是提供数据产品和数据分析使用的数据，一般会存储在ES、mysql等系统中供线上系统使用。
- 我们通过说的报表数据，或者说那种大宽表，一般就放在这里
