其层次顺序如下图。一般来说还有一个DIM维表层，一般存储维度数据，如城市、省份，客户端等。
只有数据模型将数据有序的组织和存储起来之后，大数据才能得到高性能、低成本、高效率、高质量的使用。
清晰数据结构：让每个数据层都有自己的作用和职责，在使用和维护的时候能够更方便和理解
数据血缘追踪：简单来讲可以这样理解，我们最终给业务诚信的是一能直接使用的张业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围
复杂问题简化：将一个复杂的任务拆解成多个步骤来分步骤完成，每个层只解决特定的问题
统一数据口径：通过数据分层，提供统一的数据出口，统一输出口径
减少重复开发：规范数据分层，开发通用的中间层，可以极大地减少重复计算的工作
ETL (Extraction Transformation Loading)负责将分散的、异构数据源中的数据抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中。ETL 是实施数据仓库的核心和灵魂，ETL规则的设计和实施约占整个数据仓库搭建工作量的 60%～80%
数据抽取(extraction)包括初始化数据装载和数据刷新：初始化数据装载主要关注的是如何建立维表、事实表，并把相应的数据放到这些数据表中；而数据刷新关注的是当源数据发生变化时如何对数据仓库中的相应数据进行追加和更新等维护(比如可以创建定时任务，或者触发器的形式进行数据的定时刷新)。
数据清洗主要是针对源数据库中出现的二义性、重复、不完整、违反业务或逻辑规则等问题的数据进行统一的处理。即清洗掉不符合业务或者没用的的数据。比如通过编写hive或者MR清洗字段中长度不符合要求的数据。
数据转换(transformation)主要是为了将数据清洗后的数据转换成数据仓库所需要的数据：来源于不同源系统的同一数据字段的数据字典或者数据格式可能不一样(比如A表中叫id,B表中叫ids)，在数据仓库中需要给它们提供统一的数据字典和格式，对数据内容进行归一化；另一方面，数据仓库所需要的某些字段的内容可能是源系统所不具备的，而是需要根据源系统中多个字段的内容共同确定。
数据加载(loading)是将最后上面处理完的数据导入到对应的存储空间里(hbase，mysql等)以方便给数据集市提供，进而可视化。
OLAP(On-Line Analytical Processing)：联机分析处理，OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。
OLAP 一般冗余比较多，以查询分析为主，这种一般都是采用反范式设计，以提高查询效率。更新一般是定时大批量数据插入。
OLTP 则是尽可能消除冗余，以提高变更的效率。因为这种应用无时无刻不在频繁变化。
一般来说，根据建模方式OLAP可分为3种类型：关系型联机实时分析系统(Relational-OLAP，ROLAP)，多维联机实时分析系统(Multidimensional-OLAP，MOLAP)，混合型联机实时分析系统(Hybrid-OLAP，HOLAP)。
一种通过在RDMS后端服务和客户前端之间建立中间层的OLAP实现方式。通过RDMS来存储和管理数据仓库数据，而通过OLAP中间件来实现多维数据上的操作映射为标准关系操作。
ROLAP的处理引擎主要有：Presto，Impala，GreenPlum，Clickhouse、Doris。
ROLAP 适用于对查询模式不固定、查询灵活性要求高的场景，但是处理的数据量级受限于引擎性能，对于超大数据量的复杂查询表现不太好
MOLAP一般会根据用户定义的数据维度、度量（也可以叫指标）在数据写入时生成预聚合数据；Query查询到来时，实际上查询的是预聚合的数据而不是原始明细数据，在查询模式相对固定的场景中，这种优化提速很明显。
MOLAP的处理引擎主要有：Druid 和 Kylin
MOLAP 适用于查询场景相对固定并且对查询性能要求非常高的场景，灵活性较差。
HOLAP是 MOLAP 和 ROLAP 的一种融合。当查询聚合性数据的时候，使用MOLAP 技术；当查询明细数据时，使用 ROLAP 技术。
一般商业OLAP引擎是HOLAP架构，以便可以满足不同客户的需求。
OLAP的多维分析操作包括：钻取(Drill-down)、上卷(Roll-up)、切片(Slice)、切块(Dice)以及旋转(Pivot)。
在维的不同层次间的变化，从上层降到下一层，或者说是将汇总数据拆分到更细节的数据，比如通过对2010年第二季度的总销售数据进行钻取来查看2010年第二季度4、5、6每个月的消费数据，如上图；当然也可以钻取浙江省来查看杭州市、宁波市、温州市等这些城市的销售数据。
钻取的逆操作，即从细粒度数据向高层的聚合，如将江苏省、上海市和浙江省的销售数据进行汇总来查看江浙沪地区的销售数据，如上图。
选择维中特定的值进行分析，比如只选择电子产品的销售数据，或者2010年第二季度的数据。
选择维中特定区间的数据或者某批特定值进行分析，比如选择2010年第一季度到2010年第二季度的销售数据，或者是电子产品和日用品的销售数据。
即维的位置的互换，就像是二维表的行列转换，如图中通过旋转实现产品维和地域维的互换。
数仓建模的好处在于下面四个方面：
访问性能：能够快速查询所需的数据，减少数据I/O。
数据成本：减少不必要的数据冗余，实现计算结果数据复用，降低大数据系统中的存储成本和计算成本。
使用效率：改善用户应用体验，提高使用数据的效率。
数据质量：改善数据统计口径的不一致性，减少数据计算错误的可能性，提供高质量的、一致的数据访问平台。
在信息系统中，将事务抽象为“实体”（Entity）、“属性”（Property）、“关系”（Relationship）来表示数据关联和事物描述，这种对数据的抽象建模通常被称为ER实体关系模型。
实体：通常为参与到过程中的主体，客观存在的，比如商品、仓库、货位、汽车，此实体非数据库表的实体表。
属性：对主体的描述、修饰即为属性，比如商品的属性有商品名称、颜色、尺寸、重量、产地等。
关系：现实的物理事件是依附于实体的，比如商品入库事件，依附实体商品、货位，就会有“库存”的属性产生；用户购买商品，依附实体用户、商品，就会有“购买数量”、“金额”的属性产品。
实体之间建立关系时，存在对照关系：
1:1：即1对1的关系
1:n：即1对多的关系
n:m：即多对多的关系
在日常建模中，“实体”用矩形表示，“关系”用菱形，“属性”用椭圆形。ER实体关系模型也称为E-R关系图。
关系模型严格遵循第三范式（3NF），数据冗余程度低，数据的一致性容易得到保证。由于数据分布于众多的表中，查询会相对复杂，在大数据的场景下，查询效率相对较低。
应用场景：
1、ER模型是数据库设计的理论基础，当前几乎所有的OLTP系统设计都采用ER模型建模的方式。
2、Bill Inom提出的数仓理论，推荐采用ER关系模型进行建模。
3、BI架构提出分层架构，数仓底层ods、dwd也多采用ER关系模型进行设计。
维度建模源自数据集市，主要面向分析场景。Ralph Kimball推崇数据集市的集合为数据仓库，同时也提出了对数据集市的维度建模，将数据仓库中的表划分为事实表、维度表两种类型。
事实表：
在ER模型中抽象出了有实体、关系、属性三种类别，在现实世界中，每一个操作型事件，基本都是发生在实体之间的，伴随着这种操作事件的发生，会产生可度量的值，而这个过程就产生了一个事实表，存储了每一个可度量的事件。 事实表包含了与各维度表相关联的外键，并通过JOIN方式与维度表关联。事实表的度量通常是数值类型，且记录数会不断增加，表规模迅速增长。
维度表：
维度，顾名思义，看待事物的角度。比如从颜色、尺寸的角度来比较手机的外观，从cpu、内存等角度比较手机性能。
维度表一般为单一主键，在ER模型中，实体为客观存在的事务，会带有自己的描述性属性，属性一般为文本性、描述性的，这些描述被称为维度。
比如商品，单一主键：商品ID，属性包括产地、颜色、材质、尺寸、单价等，但并非属性一定是文本，比如单价、尺寸，均为数值型描述性的，日常主要的维度抽象包括：时间维度表、地理区域维度表等。
维度建模通常又分为星型模型、雪花模型和星座模型。
星型模型由一个事实表和一组维表组成。每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。强调的是对维度进行预处理，将多个维度集合到一个事实表，形成一个宽表。这也是我们在使用hive时，经常会看到一些大宽表的原因，大宽表一般都是事实表，包含了维度关联的主键和一些度量信息，而维度表则是事实表里面维度的具体信息，使用时候一般通过join来组合数据，相对来说对OLAP的分析比较方便。
维度模型：
大宽表的优点：
业务直观，在做业务的时候，这种表特别方便，直接能对到业务中。
使用方便，写sql的时候很方便。
大宽表的缺点：
数据冗余巨大，在几亿的用户规模下，订单行为会十分恐怖
粒度僵硬，表的可复用性太低。
雪花模式(Snowflake Schema)是对星形模式的扩展，每个维表可继续向外连接多个子维表。下图使用雪花模式对维度建模的关系结构图：
星座模型，是对星型模型的扩展延伸，多张事实表共享维度表。
星座模型是很多数据仓库的常态，因为很多数据仓库都是多个事实表的。所以星座模型只反映是否有多个事实表，他们之间是否共享一些维度表。
星型模型和雪花模型的主要区别在于对维度表的拆分，
维度建模的特点如下：
维度建模的缺点:
在实际项目中，不会刻意地去考虑雪花模型，而是刻意地去考虑星型模型，特别是大数据领域的建模，倾斜于使用数据冗余来提高查询效率，倾向于星型模型；雪花模型只会应用在一些我们要求模型的灵活性，要求保证模型本身稳定性的场景下，但是雪花模型并不是首选
Data Vault是在ER模型的基础上衍生而来，模型设计的初衷是有效的组织基础数据层，使之易扩展，灵活应对业务变化，同时强调历史性、可追溯性和原子性，不要求对数据进行过度的一致性处理，并非针对分析场景所设计。
Data Vault模型是一种中心辐射式模型，其设计重点围绕着业务键的集成模式。这些业务键是存储在多个系统中的、针对各种信息的键，用于定位和唯一标识记录或数据。
Data Vault模型包含三种基本结构：
中心表-Hub：唯一业务键的列表，唯一标识企业实际业务，企业的业务主体集合。
链接表-Link：表示中心表之间的关系，通过链接表串联整个企业的业务关联关系。
卫星表-Satellite：历史的描述性数据，数据仓库中数据的真正载体。
Data Vault是对ER模型更进一步的规范化，由于对数据的拆解更偏向于基础数据组织，在处理分析类场景时相对复杂，适合数仓底层构建，目前实际应用场景较少。
Anchor是对Data Vault模型做了更进一步的规范化处理，初衷是为了设计高度可扩展的模型，核心思想是所有的扩张只添加而不修改，于是设计出的模型基本变成了K-V结构的模型，模型范式达到了6NF。
由于过度规范化，使用中牵涉到太多的join操作，目前没有实际案例，仅作了解。
当前主流建模方法为：ER模型、维度建模。
ER模型常用于OLTP数据库建模，应用到构建数仓时更偏重数据整合，站在企业整体考虑，将各个系统的数据按相似性一致性进行合并处理，为数据分析、决策服务，但并不便于直接用来支持分析。
问题：
a）需要全面梳理企业所有的业务和数据流；
b）实施周期长；
c）对建模人员要求高。
维度建模是面向分析场景而生，针对分析场景构建数仓模型，重点关注快速、灵活的解决分析需求，同时能够提供大规模数据的快速响应性能。针对性强，主要应用于数据仓库构建和OLAP引擎底层数据模型。
维度建模的有优点：
不需要完整的梳理企业业务流程和数据；
实施周期根据主题边界而定，容易快速实现 demo 。
业务直观，结构清晰（表结构一目了然），在做业务的时候，这种表特别方便，直接能对到业务中。
a）数仓模型的选择是灵活的，不局限于某一种模型方法；
b）数仓模型的设计也是灵活的，以实际需求场景为导向；
c）模型设计要兼顾灵活性，可扩展，而对终端用户透明性；
d）模型设计要考虑技术可靠性和实现成本。
数据库：数据库是面向交易的处理系统(业务系统)，它是针对具体业务在数据库联机的日常操作，通常对记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的数据库系统作为数据管理的主要手段，主要用于操作型处理，也被称为联机事务处理 OLTP(On-Line Transaction Processing)。
数据仓库：数据仓库一般针对某些主题的历史数据进行分析，支持管理决策，又被称为联机分析处理 OLAP(On-Line Analytical Processing)。
