数据仓库

108 篇文章 3 订阅

数据仓库的基本介绍

思考: 什么是数据仓库呢?

    数据仓库就是一个面向于主题的, 主要用于存储过去历史发送的数据, 对这些数据进行统计分析, 从而对未来进行决策支持
    
数据仓库最大的特点呢? 既不生产数据, 也不消耗数据, 数据来源于各个数据源
​
什么是数据分析呢? 其实本质上就是在进行数据查询聚合统计过程, 根据需求得到相关结果
    在简单点: 数据查询

思考: 数据仓库四大特征?

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中完全支持多次不断迭代计算操作, 导致又是一个程序就可以所有的内容, 从而分层架构没有那么明细

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值