数仓理论总结

数仓概念

为什么要使用数仓

统一多系统数据，提供一个所有数据的访问点，便于数据分析和计算，为决策提供数据支持

数仓定义

数仓（DataWareHourse），一般缩写为DW，是一个面向主题的、集成的、非易失的且随时间变化的数据集合
面向主题

主题（subject）是在较高层次上将企业信息系统中的数据进行综合、归类和分析利用的一个抽象概念

• 每一个主题基本对应一个宏观的分析领域
• 在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象
  • 例如“销售分析”就是一个分析领域，因此这个数据仓库应用的主题就是“销售分析”

集成

• 数据仓库的数据是从原有的分散的多个数据库、数据文件和数据端中抽取来的
• 数据来源可能既有内部数据又有外部数据
• 集成方法
  • 统一：消除不一致现象
  • 总和：对原有数据进行综合和计算

非易失

• 数据仓库中的数据是经过抽取而形成的分析型数据
  • 不具有原始性
  • 主要供企业决策分析之用
  • 执行的主要是“查询”操作，一般情况下不执行“更新”操作
  • 一个稳定的数据环境也有利于数据分析操作和决策的制定

随时间变化

• 数据仓库以维的形式对数据进行组织，时间维是数据仓库中很重要的一个维度
  • 不断增加新的数据内容
  • 不断删去旧的数据内容
  • 更新与时间有关的综合数据

和RMDB的区别

两者的使用目的不同，使用数据库是为了查询和存储数据，而使用数据仓库是为分析数据

	数据库	数据仓库
本质	数据的集合	数据的集合
定位	事务处理OLTP	数据分析OLAP
面向群体	前端用户	管理人员
操作	增删改查	查询
数据粒度	事件查询	维度
表结构	3NF（三范式）	星型、雪花

OLTP和OLAP的区别

• 联机事务处理OLTP
  • On-Line Transaction Processing
  • OLTP是传统的关系型数据库的主要应用
    • 主要是基本的、日常的事务处理
    • 例如银行交易
• 联机分析处理OLAP
  • On-Line Analytical Processing
  • OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果

对比属性	OLTP	OLAP
读特性	每次查询只返回少量的记录	对大量的记录进行汇总
写特性	随机、低延时写入用户的输入	批量导入
使用场景	用户，JavaEE项目	内部分析师，为决策提供支持
数据表征	最新数据状态	随时间变化的历史状态
数据规模	GB	TB到PB

ETL

数据的ETL

• 抽取（Extract）
  • 从操作型数据源获取数据
• 转换（Transform）
  • 转换数据，使之转变为适用于查询和分析的形式和结构
• 装载（Load）
  • 将转换后的数据导入到最终的目标数据仓库

数仓架构

Inmon架构

左边是操作型系统或者事务系统，有数据库在线系统，有文本文件系统等。这些系统的数据经过ETL的过程，加载数据到企业数据仓库中。

企业数据仓库是企业信息化工厂的枢纽，是原子数据的集成仓库，但是由于企业数据仓库不是多维格式，因此不适合分析型应用程序，BI工具直接查询。他的目的是将附加的数据存储用于各种分析型系统。

数据集市，是针对不同的主题区域，从企业数据仓库中获取的信息，转换成多维格式，然后通过不同手段的聚集、计算，最后提供最终用户分析使用，因此Inmon把信息从企业数据仓库移动到数据集市的过程描述为“数据交付”。

Kimball架构

kimball的维度数据仓库是基于维度模型建立的企业级数据仓库，它的架构有的时候可以称之为“总线体系结构”，和inmon提出的企业信息化工厂有很多相似之处，都是考虑原子数据的集成仓库。

这两种结构的相似之处：

1. 都是假设操作型系统和分析型系统是分离的；
2. 数据源（操作型系统）众多；
3. ETL整合了多种操作型系统的信息，集中到一个企业数据仓库。

最大的不同就是企业数据仓库的模式不同：inmon是采用第三范式的格式，kimball采用了多维模型–星型模型，并且还是最低粒度的数据存储。其次，维度数据仓库可以被分析系统直接访问（这种访问方式毕竟在分析过程中很少使用）。最后就是数据集市的概念有逻辑上的区别，在kimball的架构中，数据集市用维度数据仓库的高亮显示的表的子集来表示。

在kimball的架构中，有一个可变通的设计，就是在ETL的过程中加入ODS层，使得ODS层中能保留第三范式的一组表来作为ETL过程的过度。但是这个思想，Kimball看来只是ETL的过程辅助而已。另外，还可以把数据集市和企业维度数据仓库分离开来，这样多一层所谓的展现层（presentationlayer），这些变通的设计都是可以接受的，只要符合企业本身分析的需求。

数仓分层

为什么要分层

1. 用空间换时间，通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量冗余的数据；
2. 如果不分层的话，如果源业务系统的业务规则发生变化将会影响整个数据清洗过程，工作量巨大
3. 通过数据分层管理可以简化数据清洗的过程，因为把原来一步的工作分到了多个步骤去完成，相当于把一个复杂的工作拆成了多个简单的工作，把一个大的黑盒变成了一个白盒，每一层的处理逻辑都相对简单和容易理解，这样我们比较容易保证每一个步骤的正确性，当数据发生错误的时候，往往我们只需要局部调整某个步骤即可。

如何分层

1、数据运营层：ODS（Operational Data Store）
“面向主题的”数据运营层，也叫ODS层，是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的 ETL 之后，装入本层。本层的数据，总体上大多是按照源头业务系统的分类方式而分类的。

一般来讲，为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可，至于数据的去噪、去重、异常值处理等过程可以放在后面的DWD层来做。

2、数据仓库层：DW（Data Warehouse）
数据仓库层是我们在做数据仓库时要核心设计的一层，在这里，从 ODS 层中获得的数据按照主题建立各种数据模型。DW层又细分为 DWD（Data Warehouse Detail）层、DWM（Data WareHouse Middle）层和DWS（Data WareHouse Servce）层。

2.1、数据明细层：DWD（Data Warehouse Detail）

该层一般保持和ODS层一样的数据粒度，并且提供一定的数据质量保证。同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。

另外，在该层也会做一部分的数据聚合，将相同主题的数据汇集到一张表中，提高数据的可用性，后文会举例说明。

2.2、数据中间层：DWM（Data WareHouse Middle）

该层会在DWD层的数据基础上，对数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工。

直观来讲，就是对通用的核心维度进行聚合操作，算出相应的统计指标。

2.3、数据服务层：DWS（Data WareHouse Servce）

又称数据集市或宽表。按照业务划分，如流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。

一般来讲，该层的数据表会相对比较少，一张表会涵盖比较多的业务内容，由于其字段较多，因此一般也会称该层的表为宽表。

在实际计算中，如果直接从DWD或者ODS计算出宽表的统计指标，会存在计算量太大并且维度太少的问题，因此一般的做法是，在DWM层先计算出多个小的中间表，然后再拼接成一张DWS的宽表。由于宽和窄的界限不易界定，也可以去掉DWM这一层，只留DWS层，将所有的数据在放在DWS亦可。

3、数据应用层：APP（Application）
在这里，主要是提供给数据产品和数据分析使用的数据，一般会存放在 ES、PostgreSql、Redis等系统中供线上系统使用，也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。比如我们经常说的报表数据，一般就放在这里。

4、维表层（Dimension）
最后补充一个维表层，维表层主要包含两部分数据：

高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。

低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万。

建模过程

• 选择业务流程
  • 确认哪些业务处理流程是数据仓库应该覆盖的
  • 记录方式
    • 使用纯文本
    • 使用业务流程建模标注（BPMN）方法
    • 使用同一建模语言（UML）
• 声明粒度
  • 用于确认事实中表示的是什么
  • 选择维度和事实前必须声明粒度
  • 建议从原始粒度开始设计
  • 不同的事实可以有不同的粒度
• 确认维度
  • 说明了事实表的数据是从哪里采集来的
  • 典型的维度都是名词
    • 例如：日期、商店、库存等
  • 维度表存储了某一维度的所有相关数据
    • 例如：日期维度应该包括年、季度、月、周、日等数据
• 确认事实
  • 识别数字化的度量（单位），构成事实表的记录
  • 和系统的业务用户密切相关
  • 大部分事实表的度量都是数字类型的
    • 可累加、可计算
    • 例如：成本、数量、金额

星型模型和雪花模型

星型模型

• 由事实表和维度表组成
• 一个星型模型中可以有一个或多个事实表，每个事实表引用任意数量的维度表
• 星型模型将业务流程分为事实和维度
  • 事实包含业务的度量，是定量的数据
  • 维度是对事实数据属性的描述
• 优点
  • 简化查询
  • 简化业务报表逻辑
  • 获得查询性能
  • 快速聚合
  • 便于向立方体（数据立方体，多维角度分析数据）提供数据
    
• 缺点
  • 不保证数据完整性
  • 对于分析需求来说不够灵活

雪花模型

• 一个多维模型中表的逻辑布局
• 由事实表和维度表所组成
• 将星型模型中的维度表进行规范化处理
  • 把低基数的属性从维度表中移除并形成单独的表
• 一个维度被规范化成多个关联的表
• 优点
  • 一些OLAP多维数据库建模工具专为雪花模型进行了优化
  • 规范化的维度属性节省存储空间
• 缺点
  • 维度属性规范化增加了查询的连接操作和复杂度
  • 不确保数据完整性