维度建模基本概念
维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。
维度建模是专门应用于分析型数据库、数据仓库、数据集市建模的方法。数据集市可以理解为是一种"小型数据仓库"。
事实表
发生在现实世界中的操作型事件，其所产生的可度量数值，存储在事实表中。
事实表表示对分析主题的度量。比如一次购买行为我们就可以理解为是一个事实。
图中的订单表就是一个事实表，可以理解他就是在现实中发生的一次操作型事件，每完成一个订单，就会在订单中增加一条记录。
事实表的特征：表里没有存放实际的内容，他是一堆主键的集合，这些ID分别能对应到维度表中的一条记录。事实表包含了与各维度表相关联的外键，可与维度表关联。事实表的度量通常是数值类型（条/个/次），且记录数会不断增加，表数据规模迅速增长。
维度表
维度表示要对数据进行分析时所用的一个量,比如你要分析产品销售情况, 你可以选择按类别进行分析,或按区域分析。这样的按..分析就构成一个维度。上图中的用户表、商家表、时间表这些都属于维度表。这些表都有一个唯一的主键，然后在表中存放了详细的数据信息。
每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键，当然，维度表行的描述环境应与事实表行完全对应。维度表通常比较宽，是扁平型非规范表，包含大量的低粒度的文本属性。
总的说来，在数据仓库中不需要严格遵守规范化设计原则。因为数据仓库的主导功能就是面向分析，以查询为主，不涉及数据更新操作。
事实表的设计是以能够正确记录历史信息为准则。
维度表的设计是以能够以合适的角度来聚合主题内容为准则。
维度建模三种模式
星型模型
星形模式(Star Schema)是最常用的维度建模方式。星型模式是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样。
星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：
a. 维表只和事实表关联，维表之间没有关联；
b. 每个维表主键为单列，且该主键放置在事实表中，作为两边连接的外键；
c. 以事实表为核心，维表围绕核心呈星形分布；
雪花模式
雪花模式(Snowflake Schema)是对星形模式的扩展。雪花模式的维度表可以拥有其他维度表的，虽然这种模型相比星型更规范一些，但是由于这种模型不太容易理解，维护成本比较高，而且性能方面需要关联多层维表，性能也比星型模型要低。所以一般不是很常用。
星座模式
星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。
前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。
数据仓库分层架构
为什么要分层，分层的好处
清晰数据结构：
每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。
方便数据血缘追踪：
简单来说，我们最终给业务呈现的是一个能直接使用业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围。
减少重复开发：
规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。
把复杂问题简单化：
将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
屏蔽原始数据的异常:
屏蔽业务的影响，不必改一次业务就需要重新接入数据
数仓分层思想
数据分层每个企业根据自己的业务需求可以分成不同的层次，但是最基础的分层思想，理论上数据分为三个层，数据运营层、数据仓库层和数据服务层。基于这个基础分层之上添加新的层次，来满足不同的业务需求。
数据运营层（ODS）
Operate data store（操作数据-存储），是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的ETL之后，装入ODS层。本层的数据，总体上大多是按照源头业务系统的分类方式而分类的。
例如：MySQL里面的一张表可以通过sqoop之间抽取到ODS层
ODS层数据的来源方式：
- 业务库
- 经常会使用sqoop来抽取，比如我们每天定时抽取一次。在实时方面，可以考虑用canal监听mysql的binlog，实时接入即可。
- 埋点日志
- 线上系统会打入各种日志，这些日志一般以文件的形式保存，我们可以选择用flume定时抽取，也可以用用spark streaming或者Flink来实时接入，当然，kafka也会是一个关键的角色。
- 消息队列
- 来自ActiveMQ、Kafka的数据等
数据仓库层（DW）
Data warehouse（数据仓库）。在这里，从ODS层中获得的数据按照主题建立各种数据模型。例如以研究人的旅游消费为主题的数据集中，便可以结合航空公司的登机出行信息，以及银联系统的刷卡记录，进行结合分析，产生数据集。在这里，我们需要了解四个概念：维（dimension）、事实（Fact）、指标（Index）和粒度（ Granularity）。
| DW数据分层，由下到上为 DWD,DWB,DWS DWD：data warehouse detail 细节数据层，是业务层与数据仓库的隔离层。 DWB：data warehouse base 基础数据层，存储的是客观数据，一般用作中间层，可以认为是大量指标的数据层。 DWS：data warehouse service 服务数据层，基于DWB上的基础数据，整合汇总成分析某一个主题域的服务数据，一般是宽表。 |
数据服务层/应用层（ADS）
Application Data Service(应用数据服务)。该层主要是提供数据产品和数据分析使用的数据，一般会存放在ES、MySQL等系统中供线上系统使用，也可能会存在Hive或者Druid中供数据分析和数据挖掘使用。
例如：我们经常说的报表数据，或者说那种大宽表，一般就放在这里。
阿里巴巴数据仓库分层架构样例
ODS 数据准备层
功能
ODS层是数据仓库准备区，为DWD层提供基础原始数据，可减少对业务系统的影响
建模方式及原则：
从业务系统增量抽取、保留时间由业务需求决定、可分表进行周期存储、数据不做清洗转换与业务系统数据模型保持一致、按主题逻辑划分
DWD 数据明细层
功能：
为DW层提供来源明细数据，提供业务系统细节数据的长期沉淀，为未来分析类需求的扩展提供历史数据支撑
建模方式及原则：
数据模型与ODS层一致，不做清洗转换处理、为支持数据重跑可额外增加数据业务日期字段、可按年月日进行分表、用增量ODS层数据和前一天DWD相关表进行merge处理
DW(B/S) 数据汇总层
功能：
为DW、ST层提供细粒度数据，细化成DWB和DWS；
DWB是根据DWD明细数据进行转换，如维度转代理键、身份证清洗、会员注册来源清晰、字段合并、空值处理、脏数据处理、IP清晰转换、账号余额清洗、资金来源清洗等；
DWS是根据DWB层数据按各个维度ID进行高粒度汇总聚合，如按交易来源，交易类型进行汇合
建模方式及原则：
聚合、汇总增加派生事实；
关联其它主题的事实表，DW层可能会跨主题域；
DWB保持低粒度汇总加工数据，DWS保持高粒度汇总数据；
数据模型可能采用反范式设计，合并信息等。
Data Market (数据集市)层
功能：
可以是一些宽表，是根据DW层数据按照各种维度或多种维度组合把需要查询的一些事实字段进行汇总统计并作为单独的列进行存储；
满足一些特定查询、数据挖掘应用；
应用集市数据存储
建模方式及原则：
尽量减少数据访问时计算(优化检索)
维度建模，星型模型；
事实拉宽，度量预先计算；
分表存储
ST 数据应用层（ADS层）
功能：
ST层面向用户应用和分析需求，包括前端报表、分析图表、KPI、仪表盘、OLAP、专题等分析，面向最终结果用户；
适合作OLAP、报表模型，如ROLAP,MOLAP；
| 联机事务处理OLTP、联机分析处理OLAP。 OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。 联机分析处理的用户是企业中的专业分析人员及管理决策人员，他们在分析业务经营的数据时，从不同的角度来审视业务的衡量指标是一种很自然的思考模式。例如分析销售数据，可能会综合时间周期、产品类别、分销渠道、地理分布、客户群类等多种因素来考量。 |
根据DW层经过聚合汇总统计后的粗粒度事实表
建模方式及原则：
保持数据量小；
维度建模，星形模型；
各位维度代理键+度量；
增加数据业务日期字段，支持数据重跑；
不分表存储
