数据仓库是面向主题的，集成的，相对稳定的，反映历史变化的数据集合，用于支持管理中的决策制定。
数据仓库的模型架构图：
1.数据处理方式
(1)OLTP
OLTP的全称是On-line Transaction Processing，中文名称是联机事务处理。其特点是会有高并发且数据量级不大的查询，是主要用于管理事务（transaction-oriented)的系统。此类系统专注于short on-line-tansactions 如INSERT, UPDATE, DELETE操作。通常存在此类系统中的数据都是以实体对象模型来存储数据，并满足3NF(数据库第三范式)。
(2)OLAP
OLAP的全称是 On-line Analytical Processing,中文名称是联机分析处理。其特点是查询频率较OLTP系统更低，但通常会涉及到非常复杂的聚合计算。
2.数据建模
1.范式模型（实体关系（ER）模型）
数据仓库之父Bill Inmon推崇从全企业的高度设计一个3NF模型的方法，用实体加关系描述的数据模型描述企业业务架构，在范式理论上符合3NF，站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系抽象。
特点：设计思路自上而下，适合上游基础数据存储，同一份数据只存储一份，没有数据冗余，方便解耦，易维护，缺点是开发周期一般比较长，维护成本高，需要全面了解企业业务、数据和关系。
1NF：属性不可再分，即表中的每个列都不可以再进行拆分。
2NF：在满足1NF的前提下，表中不存在部分依赖，非主键列要完全依赖于主键。(主要是说在联合主键的情况下，非主键列不能只依赖于主键的一部分)
3NF：在满足2NF的前提下，不存在传递依赖。（非主键列不能相互依赖）
2.维度模型
数据仓库领域大师Ralph Kimball倡导，以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能，更直接面向业务。
维度模型建设原则：
1.一致性维度和事实：企业数据仓库应该建立统一的一致性维度和事实，而不是为每个部门建立维度和事实。
2.一致性维度：具有一致的维度关键字、属性列名称，一致的属性定义和属性值。一致性维度要么是统一的，要么是维度的一个子集。
3.一致性事实：即每个事实度量在整个数据仓库中都具有唯一的统计口径，一个度量必须只有唯一的业务术语。
维度模型设计过程：
选定业务过程 -> 确定事实粒度 -> 确定维度 -> 确定事实。
选择业务：选择业务线，如订单，仓库，售后，计费。
声明粒度：一行代表的信息（一条订单？一天的订单？一周的订单？选择最小粒度）
确认维度：选择能够描述清楚业务过程所处的环境的维度信息（谁，什么时间什么地点）
确认事实：选择与业务过程有关的所有事实（度量值：如个数，件数，金额）
(1)维度表的分类
在维度建模中，将度量称为“事实” ，将环境描述为“维度”。
①维度表
1.维度表设计原则
维度的作用一般是查询约束、分类汇总以及排序等，我们在进行维度表设计时，应当提前考虑：
（1）维度属性尽量丰富，为数据使用打下基础
比如苏宁商品维度有几十个维度属性，为下游的数据统计、分析、探查提供了良好的基础。
（2）给出详实的、富有意义的文字描述
属性不应该是编码，而应该是真正的文字。一般是编码和文字同时存在，比如商品维度中的商品ID和商品标题、类目ID和类目名称等。ID一般用于不同表之间的关联，而名称一般用于报表标签
（3）区分数值型属性和事实
数值型字段是作为事实还是维度属性，可以参考字段的一般用途。如果通常用于查询约束条件或分组统计，则是作为维度属性；如果通常用于参与度量的计算，则是作为事实。比如商品价格，可以用于查询约束条件或统计价格区间 的商品数量，此时是作为维度属性使用的;也可以用于统计某类目下商品的平均价格，此时是作为事实使用的。
（4）沉淀出通用的维度属性，为建立一致性维度做好铺垫
有些维度属性获取需要进行比较复杂的逻辑处理，有些需要通过多表关联得到，或者通过单表的不同字段混合处理得到，或者通过对单表的某个字段进行解析得到。此时，需要将尽可能多的通用的维度属性进行沉淀。一方面，可以提高下游使用的方便性，减少复杂度；另一方面，可以避免下游使用解析时由于各自逻辑不同而导致口径不一致。
（5）退化维度（DegenerateDimension）
在维度类型中，有一种重要的维度称作为退化维度。这种维度指的是直接把一些简单的维度放在事实表中。退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，退化维度一般在分析中可以用来做分组使用。例如来源渠道字段。
（6）缓慢变化维（Slowly Changing Dimensions）
维度的属性并不是始终不变的，它会随着时间的流逝发生缓慢的变化，这种随时间发生变化的维度我们一般称之为缓慢变化维（SCD），缓慢变化维一般使用代理健作为维度表的主健。
缓慢变化维的三种处理方式：
① 直接覆盖原值
适用于：不看历史数据，简单粗暴
② 拉链表（新增列）
新增三列维度记录，分配新的代理主键，通常配合有效开始时间、有效结束时间、有效标识使用
③ 增加属性列
新增数据列记录对应列数据变化前数据.
2.维度表设计方法
1.选择维度或新建维度
作为维度建模的核心，在企业级数据仓库中必须保证维度的唯一性。以苏宁商品维度为例，有且只允许有一个维度的定义。
2.确定主维表
此处的主维度表一般是直接与业务系统同步得表。例如苏宁商品的主维表是PCMS(商品中心)的商品数据
3.确定相关维表
数据仓库是业务源系统的数据整合，不同业务系统或者同一业务系统中的表之间存在关联性。根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生产维度属性。以苏宁商品维度为例，根据对业务逻辑的梳理，可以得到商品与品牌、品类等维度存在的关联关系。
4.确定维度属性
本步骤包括两个阶段，其中第一个阶段是从主维度表中选择维度属性或生成新的维度属性；第二个阶段是从相关维表中选择维度属性或生成新的维度属性。
②事实表
表中的每行数据代表一个业务事件。“事实”表示的是业务事件的度量值（可以统计次数、个数、金额等）
事实表分类：
事务事实表
以每个事务或事件为单位，描述业务过程，例如一个销售订单记录，一笔支付记录等，作为事实表里的一行数据。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新
周期快照事实表
以一个周期为时间间隔，来记录事实，一般周期可以是每天、每周、每月、每年等；
累积快照事实
用来描述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点；当过程随着生命周期不断变化时，记录也会随着过程的变化而被修改；比如：创建订单 → 买家付款 → 卖家发货 → 买家确认收货。粒度是一个订单一行数据，创建订单时间，付款时间，发货时间，收货时间，分别作为一个字段，便于计算不同业务过程的时间间隔。
1.事实表设计原则
原则 1：尽可能包含所有与业务过程相关的事实
分析哪些事实与业务过程相关，是设计过程中非常重要的关注点；在事实表中，尽量包含所有与业务过程相关的事实，即使存在冗余，由于事实通常是数字型，存储开销不会太大；
原则 2：只选择与业务过程相关的事实
如：订单的下单这个业务过程，事实表中不应该存在支付金额这个表示支付业务过程的事实；
原则 3：分解不可加性事实为可加的组件
如，订单的优惠率，应分解为订单原价金额与订单优惠金额两个事实存储在事实表中；
原则 4：在选择维度和事实之前必须先声明粒度
粒度用于确定事实表中一行所表示业务的细节层次，决定了维度模型的扩展性；每个维度和事实必须与所定义的粒度保持一致；设计事实表时，粒度定义越细越好，一般从最低级别的原子粒度开始；
原则 5：在同一个事实表中不能有多种不同粒度的事实
原则 6：事实的单位要保持一致
如，订单金额、订单优惠金额、订单运费这3个事实，应该采用统一的计量单位，统一为元或者分，以方便使用；
原则 7：对事实的null值要处理
原则 8：使用退化维度提高事实表的易用性
2.事实表设计方法
1.选择业务过程
选择需要进行分析决策的业务过程。
业务过程可以概括为一个不可拆分的行为事件或者事件的当前状态；比如日志域的曝光、访问、点击、搜索等；
2.声明粒度
在事件分析中，我们需要预判所有分析需要细分的程度，从而决定选择的粒度。粒度是维度的组合。
数据整合的程度，采用“最小粒度原则”，即将度量的粒度设置到最小。
3.确认维度
选择好粒度之后，就需要基于此粒度设计维度表，包括维度属性，用于分析时进行分组和筛选。
4.确认度量
确定分析时候需要衡量的指标。
(2)数据组织类型
按数据组织类型划分可分为星型模型、雪花模型、星座模型。
① 星型模型
是一种多维的数据关系，它由一个事实表（Fact Table）和一组维表（Dimension Table）组成每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。
星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，所以数据有一定的冗余。
② 雪花模型
雪花模型，在星型模型的基础上，维度表上又关联了其他维度表。这种模型维护成本高，性能方面也较差，所以一般不建议使用。尤其是基于hadoop体系构建数仓，减少join就是减少shuffle，性能差距会很大。
③ 星座模型
星座模型，是对星型模型的扩展延伸，多张事实表共享维度表。
(3)总线架构框架
在Kimball的维度建模的数据仓库中，关于多维体系结构（MD）有三个关键性概念：总线架构（Bus Architecture），一致性维度（Conformed Dimension）和一致性事实（Conformed Fact），主导思想是分步建立数据仓库，由数据集市组合成企业的数据仓库。但是，在建立第一个数据集市前，架构师首先要做的就是设计出在整个企业内具有统一解释的标准化的维度和事实，即一致性维度和一致性事实。而开发团队必须严格的按照这个体系结构来进行数据集市的迭代开发。
(4)建设公共层流程
第一步：需求调研
业务调研：确认需求的产业板块、产品线、功能模块以及具体的业务流程；
需求分析：与分析师、业务运营人员确认数据需求，具体到表报形式(维度+指标)。
第二步：确定数据域
确认归属的数据域（如交易域、日志域、会员域等）；
第三步：构建总线矩阵
确认业务过程：业务过程可以概括为一个不可拆分的行为事件或者事件的当前状态；
确认数据粒度：数据整合的程度，采用“最小粒度原则”，即将度量的粒度设置到最小；
确认业务主体：业务主体是维度的分类（如商品、店铺、买家等），以及维度的层次;
第四步：明确指标统计
明确需求的原子指标、派生指标(维度+原子指标的组合)。
第五步：一致性维度度量定义
确认一致性维度：确认一致性维度属性以及对应的维度编码，明确新增维度属性；
确认一致性度量：确认一致性的指标以及对应的指标编码，明确新增指标。
第六步：维度模型设计（DIM）
一致性维度设计(DIM)：根据总线矩阵完成维表设计，维度及属性的规范定义。
第七步：明细模型设计
一致性事实表设计（DWD）：根据总线矩阵的业务过程完成一致性事实表设计，包含单事务事实表和多事务事实表，确认一致性维度，分解不可加性事实为可加的原子事实/度量（如订单优惠率分解为订单原价金额和订单优惠金额）。
第八步：汇总模型设计
公用汇总层模型设计（DWS）：确认业务主体和数据域，根据总线矩阵，面向业务主体建模；确认公用的指标，不可累加的衍生指标(如比率、比例、TOPN等)拆成可累加的指标；DWS可以根据需要分层，比如：第一层当日汇总，第二层周、季、月、年累计等周期需求基于日汇总表进一步处理，或者在ADS层处理；
应用汇总层设计（ADS）：确认业务场景，将同主体的DWS层模型进行组装，生成应用个性化指标以及处理时间修饰的派生指标(如最近7天的销售金额等) 。
3.Data Vault模型
DataVault由Hub（关键核心业务实体）、Link（关系）、Satellite（实体属性） 三部分组成 ，是Dan Linstedt发起创建的一种模型方法论，它是在ER关系模型上的衍生，同时设计的出发点也是为了实现数据的整合，并非为数据决策分析直接使用。
4.Anchor模型
高度可扩展的模型，所有的扩展只是添加而不是修改，因此它将模型规范到6NF，基本变成了K-V结构模型。企业很少使用。
3.数仓总体架构
(1)ODS (Operation Data Store) 原始数据层
该层最接近数据源中数据的一层，是数据仓库准备区，为DWD层提供基础原始数据，可减少对业务系统的影响，与业务系统数据模型保持一致、按主题逻辑划分。
SSA（细节数据临时存储区）System of records Staging Area
SSA层保存源系统每天的增量数据，可根据应用需要保留适当历史周期的数据，不长期保存数据。
SOR（细节数据区）System of Record
存储数据仓库最细节数据，按照业务源系统分类划分。
对数据做结构化处理，业务上对数据做清洗转换处理，排重数据保持业务主键唯一，完整保留所有细节数据。
近源层是整个数据仓库中数据量最大的部分。
(2)DWD (Data Warehouse Detail) 明细数据层
对ODS层的数据做一定的数据清洗和转换（NULL值处理、数据格式统一），提供业务系统细节数据的长期沉淀，为未来分析类需求的扩展提供历史数据支撑
明细数据区面向数据域和业务过程建表，从事实的多种角度(维度)来描述事实（指标）的模型，包含：事务事实表、周期快照事实表、累积快照事实表。
●目的：对外提供的公用明细清单——稳定性、丰富性、易用性、一致性、可塑性
●技术手段：基于最细粒度的事实重新组装(join)+一致性维度下沉+公用业务标签化
(3)DWS (Data Warehouse Service) 服务数据层
公共汇总层主要是将使用频繁的公用数据，通过聚集进行抽象沉淀。根据数据分析的需求，基于通用业务逻辑、指标定义和共性分析的要求，设计汇总表的指标。
●目的：抽象出面向业务主体（商品、买家、店铺等）的使用频繁的公用汇总数据，提升数据查询效率
●技术手段：维度下沉+一致性维度+公共指标建设
(4)DIM（统一维度区）
提供数仓统一维度模型，所有需要使用到的维度表都从此区获取。
(5)ADS (Application Data Store) 应用数据层
该层主要是提供数据产品和数据分析使用的数据，我们说的报表数据就是这一层。
4.为什么要进行数据仓库建模
只有数据模型将数据有序的组织和存储起来之后，大数据才能得到高性能、低成本、高效率、高质量的使用。
性能：良好的模型能帮我们快速查询需要的数据，减少数据的IO吞吐
成本：减少数据冗余、计算结果复用、从而降低存储和计算成本
效率：改善用户使用数据的体验，提高使用数据的效率
质量：改善统计口径的不一致性，减少数据计算错误的可能性
5.数据治理
阿里巴巴的数据治理模式：
数据稳定性与质量治理：解决数据产出及时性和准确性问题
数据规范治理：解决数据口径一致性问题
数据安全治理：解决数据权限控制与数据共享交换问题
数据成本治理：解决数据计算和存储成本高昂问题
1.数据稳定性
针对任务进行优先级，失败重试，告警等配置，出现问题可以及时通知相关人员进行处理，保证数据稳定产出
2.数据质量治理
数据质量直接影响数据价值和加工效率，高质量的数据对完整性、有效性、准确性、唯一性、一致性、合理性等特性有很高的要求。阿里巴巴将这些特性封装成灵活的规则，然后将规则应用到具体的任务，通过调度平台，进行规则巡检和规则执行，并对有问题的任务进行告警或者阻塞处理。其关键特点如下：
质量监控与调度挂钩，第一时间发现问题，避免上游脏数据污染下游数据，大大减小影响面。
40+规则&自定义规则，精细化质量控制。
无需设定阈值，算法自动判断异常值。
故障快速恢复。
3.数据规范治理
数据在实现层面以表为单位进行，阿里巴巴围绕数据生产使用全生命周期，在指标体系设计、数据模型设计、数据处理任务开发、数据服务开放等环节的每个关键阶段都设计具体标准、流程及规范，比如创建指标的时候要配置相应的指标描述，业务口径的描述（比如仓储每日的发货的及时率统计），技术口径的描述（通过相关维度统计已发货单数与总单数的比值），还有指标对应的业务、产品、开发分别是谁等等
4.数据安全治理
创建模型的时候对字段进行敏感等级配置，是否进行加密、脱敏，以及表权限等级的配置
5.数据成本治理
通过设立组织大的成本目标，然后通过培养个人的成本意识，在数据的计算与存储、治理与运营层面建立具体目标去细化和落地，来推进数据治理方面的成本管理。比如阿里巴巴2020年成本治理的目标：数据成本增速不能超过业务增速。