思考: 什么是数据仓库呢?
数据仓库就是一个面向于主题的, 主要用于存储过去历史发送的数据, 对这些数据进行统计分析, 从而对未来进行决策支持 数据仓库最大的特点呢? 既不生产数据, 也不消耗数据, 数据来源于各个数据源 什么是数据分析呢? 其实本质上就是在进行数据查询聚合统计过程, 根据需求得到相关结果 在简单点: 数据查询
思考: 数据仓库四大特征?
1) 面向于主题: 主题指的分析的内容, 要分析什么, 什么就是我们的主题 2) 非易时性: 存储在数据仓库中数据都是过去既定发生过的数据, 这些数据一般不会发生修改的 3) 时变性: 随着时间的推移, 原有的分析的手段可能无法满足未来分析要求, 需要调整分析的方案, 同时随着时间增加, 也需要添加最近刚刚过去的相关数据(数据新增操作) 4) 数据集成性: 数据来源于各个数据源, 数据类型也是多种多样的, 将这些汇总在一起
OLAP和OLTP区别:
OLAP(联机分析处理) : 数据仓库 面向于分析的 面向于主题的 存储历史过去数据 支持决策分析, 提供给决策人员使用 相对响应速度较慢 OLTP(联机事务处理) : 关系型数据库 面向交易业务的事务处理 面向业务 存储最新数据 支持业务处理, 一般是业务人员使用 响应速度更快
数据集市和数据仓库的区别:
数据仓库可以理解是集团的数据中心, 所有的数据都是放置在数据仓库中, 在数据仓库中又按照部门 或者 业务 划分多个不同的区域, 将这个区域称为数据集市 所以说 数据仓库下可以有多个数据集市的 比如说: 在新零售项目中: ods DWd DWB层, 可以理解是集团数据中心, 也就是数据仓库 在之上, 又分为 用户主题,订单主题, 商品主题 基于这些主题对应相关各个层次表, 就是一个数据集市了
维度: 指的是在分析一个问题的时候, 可以从不同角度来看待,而这些角度就是维度, 角度不同决定了维度不同
维度的分类:
定性维度:一般指的 求 每个 各个 等相关维度
在SQL上表示: 一般都是放置group by中
定量维度: 一般表示区间范围 或者具体的值
SQL上表示: 一般是放置在where中
维度的分层和分级: 在根据某一个维度进行统计的时候, 可以对这个维度进行细化分层统计
例如:
按照时间统计: 可以细化 年 季度 月 天 周 小时....
按照地区统计: 可以细化 国家 省份 城市 ...
维度的下钻和上卷:
例如:
比如说: 在统计的时候, 要求以天作为维度进行统计, 在统计过程中要求下钻统计 每个小时,,并且上卷统计 月 和年数据
一般要以一个标准, 往标准细化方向走 一般叫做下钻 往粗粒度方向走 一般称为上卷统计
不管是分层分级还是上卷和下钻 从分析的角度来看, 无非就是增加了一些维度而已
指标: 衡量事务的标准 也叫度量值
常见的度量值: max min count sum avg 比率 同比增长....
指标分类:
绝对数值: 求具体的结果 比如向 max min count sum avg
相对数值: 丢相对的值, 比如说 转换率 流失率 同比 环比....
什么是建模呢? 所谓的建模指的就是如何构建表的操作
如何进行建模呢? 常见建模方式主要二种:
三范式建模:
以业务为导向的, 要求在建表的时候, 表应该是有一个主键的, 在建表的时候, 尽可能避免数据的冗余情况发生...
维度建模法:
以分析为导向的, 构建表的时候, 要求能够满足分析的要求, 设计的时候, 能够让目标分析更加简单, 建模越加合理, 在利于分析的要求下, 允许数据出现一定的
在维度建模中, 提供两种表模型: 事实表 和 维度表
事实表: 指的分析主题所有对应的表 或者需求所对应的表 或者 进行指标计算字段所在表
特点: 一般是由一坨外键(其他表主键)的聚集的表
维度表: 在对事实表根据各个维度进行统计分析的时候, 可能需要关联上其他的表, 此时其他的表一般称为维度表
在一些特殊的情况下, 有一些表 即是当前主题的事实表 又是其他主题的维度表
在数仓发展的过程中, 出现了三种发展模型:
星型模型:
特点: 只有一个事实表, 也就是只有一个分析的主题, 有多个维度表, 多个维度表之间没有任何的关联
这种模型是数仓发展的什么期容易产生模型呢? 初期
雪花模型:
特点: 只有一个事实表, 也就是只有分析的主题, 有多个维度表, 维度表可以接着关联其他的维度表
这种模型是数仓发展的什么期容易产生模型呢? 数仓发展出现了畸形的情况下, 有可能产生模型 这种模型下, 非常不便于维护和分析, 在实际使用尽量避免这种模型出现
星座模型:
特点: 有多个事实表, 也就是有多个分析的主题, 有多个维度表 在条件符合的情况下, 多个事实表之间的维度表可以进行共用
目的: 解决历史数据变更是否需要存储的问题
为什么有时候需要维护历史变化?
原因: 由于需求计算的操作, 如果我们不去维度历史变更行为, 可能会导致分析出现不精确情况 举个栗子: 假设有二个客户 张三和李四, 张三居住在北京, 李四居住在三亚, 这两个哥们每个人今年都花费100w用于购物, 统计每个人在各个地区消费额? 张三 北京 消费了100w 李四在三亚消费了100w 但是后来张三从北京迁移到 三亚. 如果不去维护这个历史变化, 这个时候, 我们数据库中只记录最新的三亚的数据, 此时再次统计张三在各个地区消费额的时候, 变更为 张三在三亚消费了100w 但是明显这个结果是不对的
如何维护呢?
scd1: 直接覆盖, 不保留 不维护历史版本数据, 一般适用于错误数据处理
scd2(拉链表): 当数据发送变更的时候, 首先将之前的数据设置一个截止时间, 表示过期了, 然后新增一条新的数据即可, 新的记录的起始时间就是上一条记录截止时间, 通过像链条一样的方案, 将变更数据串联在一起
优点:
利用维护(实现便利性, 后续查询便利性)
可以保留更多的历史版本
弊端:
存在数据冗余情况
scd3: 当数据发送变更的时候, 首先新增一个新的字段, 记录下其更改的信息即可
优点:
尽最大可能性, 减少数据冗余发生
弊端:
不利于维护操作
不能保存更多历史版本
请问为什么数据 仓库要进行分层呢?
1- 功能划分更加明确
2- 维度更加方便
如何进行数仓分层呢? 最开始讲的分层有三层
ODS层: 源数据层
作用: 对接数据源, 将数据源中数据加载到ODS层中, 形成一张纸的表, 一般和数据源中数据保持相同粒度(数据一致)
DW层: 数据仓库层
作用: 对数据进行统计分析操作,数据来源于 ODS层 从ODS到DW层 这个过程, 也可以称为 ETL操作: 抽取 转换 加载 从ODS层将需要的数据抽取出来, 对数据进行清洗转换处理工作, 将一份利于分析的数据灌入到DW层中
DA|APP|ADS|rpt层: 数据应用层
作用: 对接应用, 从DW层抽取应用需要的数据放置到DA层中 比如说: 后续对接图表, 每个图表需要的数据 都要从DW层抽取, 在DA层中形成多个 结果表, 每一个结果表对应着一个或多个图表数据
在我们后续的保险项目中,也是基于这三层来工作的
强调: 对于这几层的划分 并不是特别清洗, 主要原因是因为采用spark SQL工作, 以及采用代码实时, 保存在spark中完全支持多次不断迭代计算操作, 导致又是一个程序就可以所有的内容, 从而分层架构没有那么明细