数据仓库

数仓开发是个不错的选择，事少，不卷

数据仓库概念

基础概念

数据仓库（英语：Data Warehouse，简称数仓、DW）,是一个用于存储、分析、报告的数据系统。

数据仓库是存储数据的仓库, 主要是用于存储过去既定发生的历史数据,

数据仓库的目的是构建面向分析的集成化数据环境，分析结果为企业提供决策支持（Decision Support）。

数据仓库的输入方是各种各样的数据源，最终的输出用于企业的数据分析、数据挖掘、数据报表等方向。

应用场景：满足企业中所有数据的统一化存储，通过规范化的数据处理来实现企业的数据分析应用。

面对人员：一般业务数据库是对外的（客户），数据仓库是对内的（大数据分析人员）

为什么要去做数据分析？

假如你现在手里有2000w,当下的时间点去投资口罩生产，你做不做？能不能赚钱？ => 不一定，需要数据支撑

假如你是公司营销总监，是否愿意招聘女主播进行短视频带货直播销售？ => 不一定，需要数据分析

为什么需要数据仓库

为了更好的==分析数据而来==。正确的废话。

数据仓库是企业发展到一定阶段产生的

企业第一个阶段：增加用户数，业务量、维持企业则正常运转---》业务数据库（MySQL，Oracle，PSQL...）是为了让企业活下来，必须要存在。雪中送碳

企业第二个阶段：企业面临任务增长瓶颈问题，基于历史数据挖掘出有价值的数据，为企业的决策者提供科学决策支持。----》数据仓库，是为了让企业活的更好，理论可有可无。锦上添花

1、公司建立、开展业务
2、业务数据存储（事务支持）---->数据库DB
3、经营发展中想赚更多的钱
4、分析业务数据
5、DB直接分析影响读性能，干扰业务开展，得不偿失
6、其他系统、类型的数据也需要一起分析  彼此异构
7、搭建统一、集成化数据分析平台
8、建立模型和规范 愉快的进行各种分析

数仓的本质

1
2
3

为了对公司业务数据进行分析，建立数仓，其实就是把公司各种业务数据存到HDFS上，将HDFS上的业务数据文件转为Hive表，进行分析。

结论：数据就是存储在HDFS上文件 + Hive创建表     -------->离线数仓

ETL: 抽取转换加载

指的: 数据从数据源将数据灌入到ODS层, 以及从ODS层将数据抽取出来, 对数据进行转换处理工作, 最终将数据加载到DW层, 然后DW层对数据进行统计分析, 将统计分析后的数据灌入到DA层, 整个全过程都是属于ETL范畴

狭义上ETL: 从ODS层到DW层过程

抽取（extract）：业务数据表很多，抽取想要的原始数据

转换（transform）：将格式处理成想要的样子，常见的转换方式有数据类型转换、格式转换、缺失值补充、数据综合等。

加载（load）：将转换后的数据转成hive中的表（数据仓库），一般是按一定的频率装载(Oozie定时调度)

ELT: 抽取加载转换

数据相对规整,可以装载到ODS后再转换

E: 抽取
	1、抽取OLTP的数据
	2、抽取日志数据
	3、通过接口抽取第三方数据
T: 转换
	1、数据清洗
  		丢弃一些异常数据
  		处理一些脏数据
 	 	处理一些重复数据
	2、数据的格式转换
   			日期：
        	crate_time     year   month   day
       		2022-12-23 -->  2022   12      23
       		2022-1-1   -->  2022-01-01
   		字符串转换: 
          "path/list"  -->  path/list
           json数据     -->  解析
L: 加载
	1、全量加载
  		数据全部加载
	2、增量加载
  		每次只加载新增或者修改数据

数仓分层

对数据不断处理的阶段叫做分层，本质是创建不同的数据库达到区分

数据仓库和数据库的区别

数据仓库的出现，并不是要取代数据库

数据库(OLTP): 面向于事务(业务)的 , 主要是用于捕获数据 , 主要是存储的最近一段时间的业务数据, 交互性强一般不允许出现数据冗余
数据仓库(OLAP): 面向于分析(主题)的 , 主要是用于分析数据, 主要是存储的过去历史数据 , 交互性较弱可以允许出现一定的冗余

# OLTP
概念：联机事务处理系统
核心：事务支持
特点
  数据安全
  数据完整
  操作响应效率、时间
  并发支持
  CRUD操作
应用场景
  用户注册，注册信息保存在哪里？
  用户下单，订单数据保存在哪里？很多人同时下单，能不能快速、安全、稳定的保存？
  .......各种业务背后的数据存储。
用户：业务操作人员
典型代表
  RDBMS关系型数据库管理系统，比如MySQL、ORACLE。

# OLAP
概念：联机分析处理系统
核心：分析支持
特点
  数据量大
  事务性要求不高
  支撑满足不同程度分析需求
  查询操作
用户：数据分析人员
典型代表
  数据仓库、数据集市、面向分析的数据库系统

数据仓库和数据集市

数据仓库其实指的集团数据中心: 主要是将公司中所有的数据全部都聚集在一起进行相关的处理操作 (ODS层)

此操作一般和主题基本没有什么太大的关系

数据的集市(小型数据仓库): 在数据仓库基础之上, 基于主题对数据进行抽取处理分析工作, 形成最终分析的结果

一个数据仓库下, 可以有多个数据集市

数仓专注分析

数据仓库本身并不“生产”任何数据，其数据来源于不同外部系统；
同时数据仓库自身也不需要“消费”任何的数据，其结果开放给各个外部应用使用；
这也是为什么叫“仓库”，而不叫“工厂”的原因。

数仓的一切目标都是为了分析数据，给企业提供决策支撑。

数据仓库主要特征

面向主题：我们开展数据分析的时候，需要确定一个主题（或者说业务领域）

不同于传统数据库对应于某一个或多个项目，数据仓库根据使用者实际需求，将不同数据源的数据在一个较高的抽象层次上做整合，所有数据都围绕某一主题来组织。
这里的主题怎么来理解呢？比如对于城市，“天气湿度分析”就是一个主题，对于淘宝，“用户点击行为分析”就是一个主题。
再比如：用户主题，销售主题、地域主题、线路主题，征信主题、赔付主题

主题(Subject) 是在较高层次上将企业信息系统中某一分析对象（重点是分析的对象）的数据进行整合、归类并分析的一种范围，属于一个抽象概念。

数据库和数仓对数据的划分
1、数据库:面向业务划分数据  以业务流程为导向组织数据
	财务部门：ERP财务管理系统  https://www.kingdee.com/role/finance  金蝶
		-现金流量数据表
		-汇率调整表
		-凭证事务表	
    客户部门：CRM客户关系管理系统 https://www.salesforce.com/cn/crm/?bc=OTH
    	-客户基本信息表
    	-市场营销计划表
    	-投诉信息表

2、数据仓库:面向主题划分数据  以分析需要为导向组织数据
	 商品主题
	 供应商主题
	 顾客主题
     订单主题

集成性：主题相关的数据通常会分布在多个操作型系统中，彼此分散、独立、异构。需要集成到数仓主题下。同时在数据进入数据仓库之前，必然要经过统一与综合，对数据进行抽取、清理、转换和汇总

数仓的数据往往来自多种数据源，需要将多个数据源的数据(异构数据)进行整合，整合时会面临格式不一致，口径不统一，字段同名不统一、单位不统一、编码不统一等问题，则需要对数据进行处理，这个过程也被称为ETL(Extract抽取  Transform转换 load加载)。

数据仓库不产生数据也不使用数据
只会实现存储和加工

非易失性（稳定性）：数仓是数据分析的平台，而不是数据创造的平台。反映的是一段相当长的时间内历史数据的内容(历史快照)。数据仓库中一般有大量的查询操作，但修改和删除操作很少。

数据仓库基本上是不许允许用户进行修改，删除操作的。大多数的场景是用来查询分析数据。
数仓中的数据一般有一个数据采集周期（天，周，月），在下一个采集周期到来之前，数仓中的数据是不变的。

数仓是分析数据规律的平台 不是创造数据规律的平台。
注意：改指的数据之间的规律不能修改。

时变性：数仓的数据需要随着时间更新，原有的分析手段以及原有数据可能都会出现变化(分析手动更换, 以及数据新增)，以适应决策的需要。

数据仓库会定期接收新的集成数据，反应出最新的数据变化。这和稳定特点并不矛盾。
数仓中的数据在下一个采集周期到来时，需要对数仓的数据进行更新。数仓数据的采集方式是：T+1
比如按天：今天18号，采集的是昨天17号的数据。而18号的数据要等到T+1，也就是19号才能被采集。月等维度同理

数仓是一个持续维护建设的东西。
站在==时间的角度，数仓的数据成批次变化更新==。一天一分析（T+1） 一周一分析（T+7）

当下一个采集周期到来时，我们可以对数仓中的数据进行更新，以反映最新的状况。

数据仓库主流开发语言

SQL => YYDS

虽然SQL语言本身是针对数据库软件设计的，但是在数据仓库领域，尤其是大数据数仓领域，很多数仓软件都会去支持SQL语法；

场景案例：数据仓库为何而来

以中国人寿保险公司（chinalife）发展为例，阐述数据仓库为何而来？

业务数据的存储问题

中国人寿保险（集团）公司下辖多条业务线，包括：人寿险、财险、车险，养老险等。各业务线的业务正常运营需要记录维护包括客户、保单、收付费、核保、理赔等信息。这么多业务数据存储在哪里呢？
联机事务处理系统（OLTP）正好可以满足上述业务需求开展, 其主要任务是执行联机事务处理。其基本特征是前台接收的用户数据可以立即传送到后台进行处理，并在很短的时间内给出处理结果
关系型数据库（RDBMS）是OLTP典型应用，比如：Oracle、MySQL、SQL Server等

目前看好像没有什么问题

分析型决策的制定

随着集团业务的持续运营，业务数据将会越来越多。由此也产生出许多运营相关的困惑：

能够确定哪些险种正在恶化或已成为不良险种？
能够用有效的方式制定新增和续保的政策吗？
理赔过程有欺诈的可能吗？
现在得到的报表是否只是某条业务线的？集团整体层面数据如何？

为了能够正确认识这些问题，制定相关的解决措施，瞎拍桌子是肯定不行的。

最稳妥办法就是：基于业务数据开展数据分析，基于分析的结果给决策提供支撑。也就是所谓的数据驱动决策的制定.

在哪里做数据分析？数据库可以吗?

OLTP环境开展分析可行吗？

可以，但是没必要

OLTP系统的核心是面向业务，支持业务，支持事务。所有的业务操作可以分为读、写两种操作，一般来说读的压力明显大于写的压力。如果在OLTP环境直接开展各种分析，有以下问题需要考虑：

数据分析也是对数据进行读取操作，会让读取压力倍增；
OLTP仅存储数周或数月的数据；
数据分散在不同系统不同表中，字段类型属性不统一；

数据仓库面世

当分析所涉及数据规模较小的时候，在业务低峰期时可以在OLTP系统上开展直接分析。
但为了更好的进行各种规模的数据分析，同时也不影响OLTP系统运行，此时需要构建一个集成统一的数据分析平台。该平台的目的很简单：面向分析，支持分析，并且和OLTP系统解耦合。
基于这种需求，数据仓库的雏形开始在企业中出现了。

数据仓库的构建

如数仓定义所说,数仓是一个用于存储、分析、报告的数据系统，目的是构建面向分析的集成化数据环境。我们把这种面向分析、支持分析的系统称之为OLAP（联机分析处理）系统。当然，数据仓库是OLAP系统的一种实现。
中国人寿保险公司就可以基于分析决策需求，构建数仓平台。

维度分析

维度分析: 针对某一个主题, 可以从不同的维度的进行统计分析, 从而得出各种指标的过程

什么是维度

维度一般指的分析的角度, 看待一个问题的时候, 可以多个角度来看待, 而这些角度指的就是维度

比如: 有一份2020年订单数据, 请尝试分析 => 可以从时间, 地域 , 商品, 来源 , 用户….

比如你要分析产品销售情况，你可以选择按类别进行分析,或按区域分析。这样的按…分析就构成一个维度。

每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键，当然，维度表行的描述环境应与事实表行完全对应。

通俗解释:维度就是看待分析问题的角度。
	比如根据区域维度来分析不同区域的产品销量  group  by city
		上海  北京  广州  深圳
		1000  800  900   500 
	再比如根据时间来分析每个月产品的销量     group by month
		1月   2月  3月  4月
		3000 2500 3200 1420
	同一个产品销量指标从不同的维度分析会得出不同的结果。

上面所讲的是从一个维度去分析得出指标。也可以多个维度组合起来进行分析。
	比如根据区域、时间维度来分析产品销量   group by city,month
		上海 1月 1000
		上海 2月 1200
		上海 3月 1150
		北京 1月 3211
		北京 2月 2412

维度的功能

细化指标，更加精确的发现问题

老板说：咱们这个月呀，销售额明显下降了，你去查查什么原因？
我心想：这原因也忒多了。到底是什么原因导致的销售额这个指标跟上个月相比下降了呢？

此时可以考虑从不同的维度，甚至维度的组合来进行分析，比如
	从产品的维度分析，看看哪个产品销售额下降了？
	从地域的维度分析，看看哪个区域的销售额下降了？
	从时间的维度分析，看看这个月哪些天下降了？
	甚至，从时间和地域维度组合分析。

维度的分类

定性维度: 指的计算每天每月各个的维度 , 一般来说定性维度的字段都是放置在group by 中 (不具体)
定量维度: 指的统计某一个具体的维度或者某一个范围下信息, 比如说: 2020年度订单额, 统计20~30岁区间人群的人数 ,一般来说这种维度的字段都是放置在where中（具体）

维度的分层和分级

本质上对维度进行细分的过程
比如按年统计:

按季度
按照月份
按照天
按照每个小时

比如按省份统计:

按市
按县

常见的维度

时间维度：年月天
地域维度：国省市县
产品维度: 高端中端低端
终端维度：PC 移动 windows MAC
……..

从实际分析中, 统计的层级越多, 意味统计的越细化设置维度内容越多

维度的下钻和上卷

以某一个维度为基准, 往细化统计的过程称为下钻, 往粗粒度称为上卷

比如: 按照天统计, 如果需要统计出小时, 指的就是下钻, 如果需要统计季度月年, 称为上卷统计

从实际分析中, 下钻和上卷, 意味统计的维度变得更多了

下钻：当前基于一个大的维度进行分析，要下钻到一个更细的维度进行分析
- 先按年分析
- 然后按照月分析
  
  由粗粒度到细粒度是下钻
上卷：当前我的分析是基于一个小的维度进行分析，要上卷到一个大的颗粒维度来进行分析
- 先按每个小时分析
- 然后按照每天分析
  
  由细粒度到粗粒度是上卷

总结：==维度和指标在SQL层面是一个怎样的关系==？

--指标：聚合统计分析的一个结果，数值

--维度：分组字段

Table:student
	num  name  age  sex  province
	1    james  18  M    shanghai
	2    tony   24  M    shanghai
	3    anna   15  W    beijing

需求：统计每个省男女各有多少人？
select province,sex,count(num) as cnts from student group by province,sex;

--维度：省 性别
--指标：人数

什么是指标

一般可以直观的认为select聚合的字段是指标，group by分组的是维度

指标指的衡量事务发展的标准,对数据统计分析得到的结果，就是度量值，也称为指数

指标的分类

绝对指标: 计算具体的值指标 count() sum() max() min() avg()
相对指标: 计算比率问题的指标 转化率, 流失率, 同比

指标设计

假如业务要求要去分析网站访问情况的好坏情况，请问分析什么？

访问人数？点击次数？搜索次数？

新用户注册率？老用户回头率？

a、指标的概念

==指标是衡量事物发展的标准，也叫度量==，如价格，销量等；指标可以求和、求平均值等计算；

指标分为绝对数值和相对数值：

==绝对数值==反映具体的大小和多少，如价格、销量、分数等； —》普通数字

==相对数值==反映一定的程度，如及格率、购买率、涨幅等。 —》%百分比

对数据统计分析得到的结果，就是指标，是一个度量值，也称为指数。
b、指标的功能

通过指标来衡量事实的结果，反映事实的好坏。

比如：今天的网站访问情况和昨天相比如何？如何比？比什么？

比较指标：新老访客数、回头率、页面点击数

c、常见的指标

每个行业的需求不同，指标也不同
	- 教育行业：旷课率
	- 游戏行业：通关率
	- 金融行业：还款率
	- 电商行业：履单率
	
#基础指标
	比如网站访问分析中，常见的UV（独立访客）、PV（页面访问量）、IP指标（独立IP）
	比如电商购物分析中，常见的下单数、回购率、退单率
	
 张三 192.168.88.80   汽车之家70个页面 
 张三 192.168.88.81   汽车之家60个页面 
 
 李四 192.168.88.91    汽车之家30个页面 
 李四 192.168.88.92    汽车之家40个页面 
  
  UV： 2个用户
  PV： 打开200个网页
  IP： 4个不同的IP地址


#关键指标/核心指标
	关键指标就是运营管理者（领导层）最关心的指标，比如市场总监提出的产品销量、新增客户等指标；财务经理提出的营业额、利润率等。
	
最近一年客户对汽车之家热度变化情况？

Q：指标体系怎么构建的？谁负责这个事？

https://www.zhihu.com/question/23774081/answer/1191077182

推荐书籍《数据产品经理修炼手册》

案例

需求: 请求出在2020年度, 女性 未婚 年龄在18~25岁区间的用户每一天的订单量?

维度:  时间维度 , 性别, 婚姻状态, 年龄
	定性维度: 每一天
    定量维度: 2020年度,18~25岁,女性,未婚

指标: 订单量(绝对指标) --> count()

select day,count(1)   from  表  where year ='2020' and age between 18 and 25 and 婚姻='未婚' and sex = '女性' group by  day;

数仓建模

决定了数据存储的方式，表的设计。

比如：有哪些表，表中有哪些字段？表之间有什么关系等等。

数仓建模指的规定如何在hive中构建表, 数仓建模中主要提供两种理论来进行数仓建模操作: 三范式建模和维度建模理论

三范式建模: 主要是存在关系型数据库建模方案上, 主要规定了比如建表的每一个表都应该有一个主键, 数据要经历的避免冗余发生等等

维度建模: 主要是存在分析性数据库建模方案上, 主要一切以分析为目标, 只要是利于分析的建模, 都是OK的, 允许出现一定的冗余, 表也可以没有主键

维度建模的两个核心概念：事实表和维度表。

ER模型

ER模型概念

==ER模型==也称==实体-关系图==(Entity Relationship Diagram)，由Peter Chen（陈品山）于1976年提出；

ER模型围绕真实世界的实体和它们之间的关系展开，被认为是设计数据库的好选择。

ER模型三要素
	实体(entity):数据模型中的数据对像。例如，学生，教师，成绩都可以被视为实体。	

	属性(attribute):实体所具有的属性，例如学生具有姓名、学号、年级等属性。

	关系(relationship):用来表现数据对象与数据对象之间的联系，例如学生的实体和成绩表的实体之间有一定的联系，每个学生都有自己的成绩表，这就是一种关系。

ER模型的应用

一般用于==RDBMS系统中来实现业务数据库的建模==。

1
2
3

数据仓库之父Bill Inmon提出的数据仓库建模方法是自上而下的，从全企业的高度设计一个符合3NF的数据模型，用实体关系（Entity Relationship,ER）模型描述企业的业务。

但是这里存在争议，在现实当中，大多数企业的数据仓库系统更接近Ralph Kimball所倡导的方式：数据仓库是企业内所有数据集市的集合，信息总是被存储在多维模型当中。

ER模型的构建流程

step1：找到所有实体，以及每个实体的属性

step2：找到所有实体之间的关系

step3：建表，每个实体与每个关系都是一张表

业务:jack在一品生鲜买了波士顿龙虾4只。

需求:建立表模型把上述业务流程记录下来。


- 实体(维度表)
		 jack：用户实体	
			=用户id	 用户name		用户age		  手机		          密码
   		 	 00001     jack         18          18866886688         password
		 
		 商店：店铺实体
			=店铺id	   	店铺名称			营业执照	  经营范围	  地址
			12300014     一品生鲜浦东旗舰店    shpd_121     生鲜       航都路18号

		 龙虾：商品实体
    		=商品id	  	商品名称		尺寸		颜色		价格
    		 8866225      波士顿龙虾      5斤      红发黑     3元

- 关系(事实表)
		订单：实体之间的购买关系
    		=订单id	用户id	店铺id		   商品id		 订单价格		支付方式	
             1001     jack     一品生鲜浦东旗舰店 波士顿龙虾     50         微信支付

- 建表
  - 实体：用户表、商品表、店铺表
  - 关系：订单表

ER模型优缺点

优点：符合数据库的设计规范，没有冗余数据，保证性能，业务的需求把握的比较全面。
缺点：设计时候非常复杂，必须找到所有实体和关系，才能构建。

维度建模

维度建模概念

维度建模是专门用于分析型数据库、数据仓库、数据集市建模的方法。

维度模型是数据仓库领域大师Ralph Kimall所倡导，他的《数据仓库工具箱》，是数据仓库工程领域最流行的数仓建模经典。

维度建模==以分析决策的需求出发==构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。

在维度建模中，牵扯到两个基本的名词：==维度==，==事实==。

1、事实就是你要关注的内容；
2、维度就是你观察该事物的角度，是从哪个角度去观察这个内容的。

例如，某地区商品的销量。是从地区这个角度观察商品销量的。事实就是销量表，维度就是地区表。

维度建模的构建流程

step1：确定事实表

step2：构建维度表

业务行为：昨天早上张三在京东LV官方店花费20000元购买了一个皮包.

实体： 用户   店铺   商品


业务数据记录：t_order订单表
	orderid   userid   shopid   productid   num  order_price  time
	订单编号    用户编号  店铺编号  商品编号     个数   订单价格      时间
	10010      u001     s0001    p0001      2     50          2022-01-01

订单表的功能：
	记录在现实中发生的一次操作型事件，每完成一个订单，就会在订单表中增加一条记录。

事实表：
	表示对分析主题的度量。当我们分析订单主题时，订单就是我们关注的内容。订单表的数据就不可或缺。
	发生在现实世界中的操作型事件，其所产生的可度量数值（个数、订单价格），存储在事实表中。
	因此上面的订单表就是一个事实表。
	
=事实表单独看不全信息，还需要去找它里面保存的维度信息	
	
维度表：分析事实的角度。
	用户维度
	店铺维度
	商品维度
	时间维度

事实表通过外键与维度表进行了关联。

维度建模与ER建模的区别

实体-关系建模是面向应用，遵循第三范式，以消除数据冗余为目标的设计技术。
维度建模是面向分析，==为了提高查询性能可以增加数据冗余==，==反规范化==的设计技术。

事实表

事实表: 事实表一般指的就是分析主题所对应的表,每一条数据用于描述一个具体的事实信息, 这些表一般都是一坨主键(外键)和描述事实字段的聚集

例如: 比如说统计2020年度订单销售情况 

订单事实表：
	orderid   userid   shopid   productid   num  order_price  time
	订单编号    用户编号  店铺编号  商品编号     个数   订单价格      时间
	000001     10086   sp_123   p001     2      12.34     20211010
	000001     10010   sp_211   p002     21     25.25     20211011
  	000001     10010   sp_211   p003     21     25.25     20211011  
  	
引用的维度
	orderid   userid   shopid   productid   time
	
业务过程有关的度量（指标值）
	num  order_price


主题:  订单 
相关表: 订单表(事实表)
思考: 在订单表, 一条数据, 是不是描述一个具体的订单信息呢?  是的
思考: 在订单表, 一般有那些字段呢? 
	订单的ID, 商品id,单价,购买的数量,下单时间, 用户id,商家id, 省份id, 市区id, 县id 商品价格...

进行统计分析的时候, 可以结合 商品维度, 用户维度, 商家维度, 地区维度 进行统计分析, 在进行统计分析的时候, 可能需要关联到其他的表(维度表)

注意:
	一般需要计算的指标字段所在表, 都是事实表

事实表的特点

事实表包含了与各维度表相关联的外键，可与维度表关联；
表里没有存放实际的内容，是一堆主键的集合，这些主键ID分别能对应到维度表中的一条记录；
事实表的度量（指标）通常是数值类型；
事实表记录数会不断增加，表数据规模迅速增长。

事实表比如订单表，一直在增长，但是维度表就不一定了，比如地区维度，相对增长缓慢。

事实表度量（指标）分类

1、可加数值类型
	度量可以按照和事实表关联的任一维度进行汇总。
	比如订单价格，可以按照用户维度、店铺维度汇总平均值和总价格等等。
	A用户平均每单金额、B店铺订单总价格等。

2、半可加数值类型
	度量在某些维度下不可进行汇总，或者说汇总起来没有意义。
	比如说余额，余额在时间维度下的汇总就没有意义。
	记录静态数据（库存数据，金融账户余额）的所有度量针对于日期属性等维度天然具有非可加性，但是例如库存数据针对产品种类或者商店维度进行汇总，是可加的，所以这种数据就是半可加事实。
	时间：1号： 库存1000
	时间：2号： 库存800
	
	那么在时间的维度上：1000+800有什么意义？？ 没有意义
	但是在商店维度就有意义了。
	A店铺：库存8000
	B店铺：库存5000
	从店铺的维度分析总库存：8000+5000
	
	11-1日: 剩下100元
    11-2日: 剩下80元
    
3、不可加数值类型
	度量在所有与该事实表关联的维度下都不可进行汇总。
	比如说比率型数据，对于这种数据，如果确实是有汇总的必要，可以将其分子分母分别存储，然后在最后汇总之后再进行除法操作，从而得到“汇总”后的比率型数据。
	1号： 30%
	2号： 50%

事实表的分类

1、事务事实表:(Transaction fact table)
保存的是最原子的数据，也称“原子事实表”或“交易事实表”。沟通中常说的事实表，大多指的是事务事实表。

事务事实表中的数据在事务事件(增删改)发生后产生，数据的粒度通常是每个事务一条记录；
一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新；

=订单事实表：
	orderid   userid   shopid   productid   num  order_price  time
	订单编号    用户编号  店铺编号  商品编号     个数   订单价格      时间

=每完成一个订单，就会在订单事实表中增加一条记录。

2、周期快照事实表:(Periodic snapshot fact table)
周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，时间间隔如每天、每月、每年等等,典型的例子如销售日快照表、库存日快照表等；
周期表由事务表加工产生

周期快照事实表的粒度是每个时间段一条记录，通常比事务事实表的粒度要粗，是在事务事实表之上建立的聚集表。比如说时间周期是1周，那么这个周期快照事实表的一条记录就是这一周的对于某个度量的统计值。
周期快照事实表的维度个数比事务事实表要少。
周期快照事实表的日期维度通常是记录时间段的终止日，记录的事实是这个时间段内一些聚集事实值。

=销售月快照表
	time   			 total_order   		total_price
	时间     			订单总个数      		订单总价格
	202111             3455                24563
	202112             5412                147855
	
=报名日快照表
	time      java    pd       ui   
	20210202  5000    3000    2000
	20210203  3222    4322    222300
	20210204  235000  223000  2000
	20210205  5000    3000    2000

3、累计快照事实表:(Accumulating snapshot fact table)
完全覆盖一个事务或产品的生命周期的时间跨度，它通常具有多个日期字段，用来记录整个生命周期中的关键时间点，例如订单累计快照事实表会有付款日期，发货日期，收货日期等时间点。

周期快照事实表记录的确定的周期的数据，而累积快照事实表记录的不确定的周期的数据。
事务事实表中一个完整的交易记录会有一系列不同状态的数据来记录整个交易过程；而累积快照事实表只会有一条记录，数据会一直更新直到过程结束。

1
2
3

=订单累积快照事实表
	订单id		提交成功		支付成功	 发货状态	 收货状态		退货状态
	order001 	  12:00          12:30      14:00       18:00        18:30

4、无事实事实表

没有事实发生，没有度量值（指标），都是一堆外键;

作用：梳理==维度之间的对应关系==，并且能更快获得关系数据。

常被用于回答“什么未发生”这样的问题

=促销范围无事实事实表
=功能：处于促销状态但尚未销售的产品包括哪些？
=总共参与促销的产品有100个，商品编号从1---100。

=表字段：促销范围无事实事实表	
	日期             产品ID
	20201010      1-59,76-78,80-100
	20201011      1-32,88-100
	20201012      1

数仓中以分析为优先，不计较冗余。能将计算的指标都放到一个表就放到一个表，SQL写起来比较方便

维度表

维度表: 指的在对事实表进行统计分析的时候, 基于某一个维度, 这个维度信息可能其他表中, 而这些表就是维度表

1
2
3

维度表并不一定存在, 但是维度是一定存在:
	比如: 根据用户维度进行统计, 如果在事实表只存储了用户id, 此时需要关联用户表, 这个时候就是维度表
	比如: 根据用户维度进行统计, 如果在事实表不仅仅存储了用户id,还存储用户名称, 这个时候有用户维度, 但是不需要用户表的参与, 意味着没有这个维度表

维度表的分类:

高基数维度表: 指的表中的数据量是比较庞大（千万行以上）的, 而且数据也在发送的变化
	例如: 商品表, 用户表

低基数维度表: 指的表中的数据量不是特别多, 一般在几十条到几千条左右,而且数据相对比较稳定
	例如: 日期表,配置表,区域表

维度建模概况总结：

事实表的设计是以能够正确记录历史信息为准则。

维度表的设计是以能够以合适的角度来聚合主题内容为准则。

维度建模的三种模型

第一种: 星型模型

特点: 只有一个事实表, 那么也就意味着只有一个分析的主题, 在事实表的周围围绕了多个维度表, 维度表与维度表之间没有任何的依赖
在代码层面感知模型：比如A关联B，A关联C，A关联D
在数仓发展初期最容易产生模型

第二种: 雪花模型

特点: 只有一个事实表, 那么也就意味着只有一个分析的主题, 在事实表的周围围绕了多个维度表, 维度表可以接着关联其他的维度表
反映数仓发展出现了畸形产生模型, 这种模型一旦大量出现, 对后期维护是非常繁琐, 同时如果依赖层次越多, SQL分析的难度也会加大，这种模型不太容易理解，维护成本比较高，而且性能方面需要关联多层维表，性能也比星型模型要低。所以一般不是很常用。

在代码层面感知模型：比如A关联B，B关联C，C关联D

此种模型在实际生产中,建议尽量减少这种模型产生

第三种: 星座模型

特点: 有多个事实表, 那么也就意味着有了多个分析的主题, 在事实表的周围围绕了多个维度表, 多个事实表在条件符合的情况下, 可以共享维度表
在数仓发展中后期最容易产生模型

整理表和表的关系叫做血缘管理，比如：apache atlas

不同业务线(对应不同业务数据库)梳理关系（数据治理、数据中台、数据湖、血缘管理），事实和事实表什么关系，以谁为主，什么表可以共用，放到数仓中形成星座模型。这个称为模型构建，还是很有挑战性的。

缓慢渐变维（SCD）

也叫缓慢变化维

解决问题: 解决历史变更数据是否需要维护的情况

背景：

比如客户信息，某个客户一开始在A城市，但某时间点之后，搬家到了B城市。在跟踪这个客户的消费行为的时候必然要考虑其在不同地区的差异。因此需要记录客户的之前和现在的状态。

大多数维度表随时间的迁移是缓慢变化的，修改更新个属性字段值啥的，因此在设计维度和使用维度的过程中，就要考虑到缓慢变化维度的处理。

当然也有不变的维度和剧烈变化的维度：例如一个人的相关信息，身份证号、姓名和性别等信息数据属于不变的部分，政治面貌和婚姻状态属于缓慢变化部分，而工作经历、工作单位和培训经历等在某种程度上属于急剧变化字段。

案例引出历史状态丢失问题

顾客信息表，2012年1月1日起，BIWORK居住在北京
2012年3月12日以后搬去了三亚居住，因此该条数据进行了更新
问题来了
- 需要对2012年的居住在北京的数据进行统计，这条数据是否参与统计？必须参加统计
- 但是如果参与统计，数据中这条信息已经没有了，无法统计，因为现在记录的就是住在三亚。
- 历史状态没有了。

SCD三种解决方案

SCD1:直接覆盖, 不维护历史变化数据
- 主要适用于: 对错误数据处理（过去的状态就认为是错误的，也就不要保留统计了）
SCD2:不删除、不修改已存在的数据, 当数据发生变更后, 会添加一条新的版本记录的数据, 在建表的时候, 会多加两个字段(起始时间, 截止时间), 通过这两个字段来标记每条数据的起止时间 , 一般称为拉链表
- 好处: 适用于保存多个历史版本, 方便维护实现
- 弊端: 会造成数据冗余情况, 导致磁盘占用率提升

常见的维护历史状态的做法是：在表中添加两个字段，表示该条数据状态的起始时间、结束时间

| 用户id | 所在的地区 | 时间标记：startTime | 时间标记：endTime |
| ------ | ---------- | --------------- | ------------- |
| 1001   | beijing    | 2018-01-01      | 2020-01-01    |
| 1001   | sanya      | 2020-01-01      | 2021-01-01    |
| 1001   | meiguo     | 2021-01-01      | 2022-01-01    |
| 1001   | yilake     | 2022-01-01      | 9999-12-31    |


--工作中的需求是可以指定日期查询对应的状态
 where startTime >= 2019 and endTime < 2020
--默认应该处理最新的状态：通过9999-12-31，来标记这是最新的状态
 where endTime = 9999-12-31

适用于变化不快的，如果变化很快就会产生很多数据

SCD3: 通过在增加列的方式来维护历史变化数据
- 好处: 减少数据的冗余, 适用于少量历史版本的记录以及磁盘空间不是特别充足情况
- 弊端: 无法记录更多的历史版本, 以及维护比较繁琐（要改表结构,动数据,表大就不太合适）

面试题:
	1) 在项目中, 如何实现历史变化维护工作的
	2) 如何实现历史版本数据维护, 你有几种方案呢?   三种 
	3) 请简述如何实现拉链表

数仓分层

分层其实不固定，按公司定的标准来就行

按照数据流入流出的过程，数据仓库架构可分为三层——**源数据(Operational Data Store)**、数据仓库(Data Warehouse)、数据应用(DataApplication)

1、数仓的分层是数仓的数据从进来到出去整个数据流向在不同阶段的称呼。
2、每一家公司在数仓分层是不一样的，也没有统一的标准，分层只要适合自己就好
3、分层的好处是在不同的阶段做不同的事情，可以进行明确的阶段分工，提供数据的复用性
4、一般在业界有一个通用的分层标准:
  ODS层：存放采集后原始结构化数据
  DW层： 存放对ODS层处理后的数据
   	DWD层：数据拉链表
   	DWB层：降维
   	DWS层：初级聚合
  APP层：一般存放用于第三方应用的数据

分层为的就是从源数据到目标数据处理的步骤体系不乱。

分层的开发环境：

不分层的开发环境：

原有的基础分层

ODS层: 源数据层

作用: 对接数据源, 和数据源的数据保持相同的粒度(将数据源的数据完整的拷贝到ODS层中)

注意: 如果数据来源于文本文件, 可能会需要先对这些文本文件进行预处理(spark)操作, 将其中不规则的数据, 不完整的数据, 脏乱差的数据先过滤掉, 将其转换为一份结构化的数据, 然后灌入到ODS层

名称:操作型数据存储、源数据层、贴源层、数据暂存层、数据引入层

功能:此层数据无任何更改，直接沿用外围系统数据结构和数据，不对外开放；为临时存储层，是各个数据源数据的临时存储区域，为后一步的数据处理做准备。

说明:在大数据的数仓体系中，更多进行的是ELT的操作。因为数据源的数据不出意外几乎都是结构化的数据了，那么不妨首先将数据load加载至数仓，然后经过层层的T转换。

实际应用:ODS为Hive数仓中的一个逻辑分层，比如专门创建一个database库，名字叫做ods.存储从各个数据源加载过来的数据，做临时存储。

DW层: 数据仓库层

作用: 进行数据分析的操作

名称:数据仓库层

功能:DW层的数据由ODS层数据加工而成,主要完成数据加工与整合。DW层的数据应该是一致的、准确的、干净的数据。

说明:实际应用中，为了更加清晰、明了、便捷的开展数据分析，会对DW层进行更加细化的分层。比如：数仓明细层DWD、数仓基础数据层DWB、数仓服务数据层DWS、数据集市层DM、维度数据层DIM

DW层：数据仓库层细化

概述

在数仓3层的分层架构中，处于中间的DW数据仓库层应该是核心中的核心。

实际应用中，为了更加清晰、便捷、高效的分析数据，会对DW进行更进一步的细化分层。

至于具体再细化几层，怎么细化，则没有统一的标准。

栗子

1．明细层DWD（Data Warehouse Detail）：存储明细数据，此数据是最细粒度的事实数据。该层一般保持和ODS层一样的数据粒度，并且提供一定的数据质量保证。同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。

2．中间层DWM（Data WareHouse Middle）：存储中间数据，为数据统计需要创建的中间表数据，此数据一般是对多个维度的聚合数据，此层数据通常来源于DWD层的数据。

3．业务层DWS（Data WareHouse Service）：存储宽表数据，此层数据是针对某个业务领域的聚合数据，应用层的数据通常来源与此层，为什么叫宽表，主要是为了应用层的需要在这一层将业务相关的所有数据统一汇集起来进行存储，方便业务层获取。此层数据通常来源与DWD和DWM层的数据。

DA层: 数据应用层(APP、ADS)

作用: 存储DW层分析的结果, 用于对接后续的应用(图表, 推荐系统…)

名称:数据应用层

功能:面向最终用户，面向业务定制提供给产品和数据分析使用的数据。

常见的数据应用:数据报表 数据可视化 数据挖掘  即席查询

分层案例

通过此案例，希望能够理解案例中分层设计的实现

电商平台案例

DWD轻度汇总，没有group by 的明细数据（分）

DWM初步打散，有group by 的汇总，（合）

DWS业务汇总，形成不同的主题数据（分）

阿里巴巴数仓分层案例

计算口径不统一：XXX率，保留几位小数? 优良大于多少数值算优良?

2个业务线的字段不统一，比如在业务线A叫empid，业务线B叫emp_id

美团点评酒旅数据仓库建设实践
- https://tech.meituan.com/2017/05/26/hotel-dw-layer-topic.html
携程数仓设计
- https://mp.weixin.qq.com/s/CfxNcMJIl6irunrTNTs25g

每个行业，每家公司都可以根据自己的需求去添加、删除分层的个数。

没有好的分层架构、只有适合自己的架构

它山之石可以攻玉。

教育数仓分层

ODS层: 源数据层

作用: 对接数据源, 和数据源的数据保持相同的粒度(将数据源的数据完整的拷贝到ODS层中)(贴源表)

注意: 如果数据来源于文本文件, 可能会需要先对这些文本文件进行预处理(spark)操作, 将其中不规则的数据, 不完整的数据, 脏乱差的数据先过滤掉, 将其转换为一份结构化的数据, 然后灌入到ODS层

一般放置事实表数据和少量的维度表数据

DW层: 数据仓库层

DWD层: 明细层

作用: 用于对ODS层数据进行清洗转换工作 , 以及进行少量的维度退化操作（1-3个）
少量: 将多个事实表的数据合并为一个事实表操作；如果维度表放置在ODS层，一般也是在DWD层完成维度退化

什么叫做维度退化: 是为了减少维度表的关联工作

做法: 将数据分析中可能在维度表中需要使用的字段, 将这些字段退化到事实表中, 这样后续在基于维度统计的时候, 就不需要在关联维度表, 事实表中已经涵盖了维度数据了（多表关联->单表查询）

例如: 订单表, 原有订单表中只有用户id, 当我们需要根据用户维度进行统计分析的时候, 此时需要关联用户表, 找到用户的名称, 那么如果我们提前将用户的名称放置到订单表中, 那么是不是就不需要关联用户表, 而则就是维度退化

好处: 减少后续分析的表关联情况
弊端: 造成数据冗余

DWM层: 中间层

作用: 1) 用于进行维度退化操作 2) 用于进行提前聚合操作(周期快照事实表)

DWS层: 业务层

作用: 进行细化维度统计分析操作

DA层: 数据应用层

作用: 存储基于DWS层再次分析的结果, 用于对接后续的应用(图表, 推荐系统…)

例如: 比如DWS层的数据表完成了基于订单表各项统计结果信息(宽表), 但是图表只需要其中销售额, 此时从DWS层将销售额的数据提取出来存储到DA层(萃取表)

DIM层: 维度层

作用: 存储维度表数据，维度表比较多(>3)的时候放在DIM层，将维度退化工作放在DWM层。

划分逻辑层次结构，主要是为了后续的维护

新零售项目数仓分层

==烂熟于心。能说会道。理解再复述。==

新零售分层架构图

ODS（数据临时存储层）

功能:将各个数据源的原始数据几乎无处理地存放在数据仓库系统中，结构上与源系统基本保持一致，是数据仓库的数据准备区。这一层的主要职责是将基础数据同步至数仓。

做法:Hive数仓创建ODS数据库，逻辑分层。

友情提示:在实时数仓中，常常使用kafka这样的分布式消息队列作为ODS层的存储工具。各个数据源作为生产者把数据写入kafka,然后使用flink等实时计算引擎进行各种ETL，结果保存至诸如Redis、HBase的实时存储中。

DWD（==明细==数据层 Data Warehouse ==Detail==）

1
2
3

功能:数据来自于ODS，一般保持和ODS层数据一样的粒度；并且提供一定的数据质量保证，对来自ODS数据层做一些数据清洗和规范化的操作，提供更干净的数据。

此外: 区分ODS中各个数据到底是属于事实(Fact Table)，还是属于维度(Dimension Table)。

DWB（==基础==数据层 Data Warehouse ==Base==）

1
2
3

功能:基础数据层一般用作中间层。多张表数据关联在一起，降维操作，形成一张大宽表。DWB层表数据量较少，只需要保留一定周期内的数据，当前有效的数据。

说明: 宽表指的的表的字段多。不同表的内容形成一张宽表，已经明显不符合三范式设计要求了。合并成宽表的目的就是提高计算时的效率。（查询多张表和查询一张表的性能差异）

DWS（==服务==数据层 Data Warehouse ==Service== ）

功能: 基于DWB上的基础数据，整合汇总成分析某一个主题域的服务数据，一般是宽表。

作用: 基于分析主题根据相关指标 维度进行提前统计聚合操作(提前聚合), 形成宽表统计结果数据

例如:需要统计每天 每月 每年的 销售总额, 此时为了后续统计分析, 可以在DWS层, 先按照每天将销售总额统计出来即可。这样, 后续在统计每月 每年的时候, 就可以基于每天的结果进行汇总合并即可。
	     
说明: 根据主题划分。

DM（数据集市层 Data Mart）

1	功能职责:进行细粒度统计操作, 基于DWS层, 进行上卷维度统计操作, 形成大的主题统计宽表 (一般来说是一个主题对应一个统计宽表)

RPT（报表应用层 DA）

1	作用: 存储分析的结果表, 会对DM层统计宽表, 根据需求要求, 从宽表中获取想要的数据, 将这些数据灌入到DA层

关注：数据治理+数据中台+数据湖+血缘管理

数据仓库

数据仓库概念

基础概念

为什么需要数据仓库

数仓的本质

ETL: 抽取 转换 加载

ELT: 抽取 加载 转换

数仓分层

数据仓库和数据库的区别

数据仓库和数据集市

数仓专注分析

数据仓库主要特征

数据仓库主流开发语言

场景案例：数据仓库为何而来

业务数据的存储问题

分析型决策的制定

OLTP环境开展分析可行吗？

数据仓库面世

数据仓库的构建

维度分析

什么是维度

维度的功能

维度的分类

维度的分层和分级

维度的下钻和上卷

什么是指标

指标的分类

指标设计

案例

数仓建模

ER模型

ER模型概念

ER模型的应用

ER模型的构建流程

ER模型优缺点

维度建模

维度建模概念

维度建模的构建流程

维度建模与ER建模的区别

事实表

事实表度量（指标）分类

事实表的分类

维度表

维度建模的三种模型

第一种: 星型模型

第二种: 雪花模型

第三种: 星座模型

缓慢渐变维（SCD）

案例引出历史状态丢失问题

SCD三种解决方案

数仓分层

原有的基础分层

ODS层: 源数据层

DW层: 数据仓库层

DW层：数据仓库层 细化

DA层: 数据应用层(APP、ADS)

分层案例

教育数仓分层

ODS层: 源数据层

DW层: 数据仓库层

DA层: 数据应用层

DIM层: 维度层

新零售项目数仓分层

ETL: 抽取转换加载

ELT: 抽取加载转换

DW层：数据仓库层细化