标签：数仓 拉链 离线 基础知识 订单 日期 维度 数据 select

    声明: 1. 本文为我的个人复习总结, 并非那种从零基础开始普及知识 内容详细全面, 言辞官方的文章
              2. 由于是个人总结, 所以用最精简的话语来写文章
              3. 若有错误不当之处, 请指出

一、概述:

介绍:

数据仓库存放着海量的数据, 并拥有分析计算程序, 计算输出的结果供企业制定决策

输入数据来源:

用户行为数据(前端埋点), 业务数据(MySQL数据库), 爬虫数据

用户行为数据: 用户的动作产生的数据, 比如浏览, 停留, 点击, 点赞, 评论, 收藏

业务数据: 业务流程中产生的数据, 比如登录, 用户, 订单, 支付

输出系统:

报表系统, 用户画像系统, 推荐系统

项目架构:

同比:
与历史同时期比较, 例如 本周三和上周三做比较

环比:
与上一个统计周期比较, 例如 本周三和本周二做比较

T+1模式:

今天凌晨开始去计算昨天的数据

SKU & SPU:

SKU: 一台黑色, 128G内存的iPhoneX手机

SPU: 一台iPhoneX手机

埋点日志:

页面, 曝光, 事件, 启动, 错误

二、数仓分层:

分层的好处:

3. 高层的计算 可以复用 低层计算的中间结果
   当没有分层的时候:

   ​ 比如要统计A, B, C指标, 那么A需要对初始表进行过滤空值 然后再进一步计算, B和C也要重复地去对初始表过滤空值
   而分层后:

   ​ 可以把过滤空值的计算交给dwd层去做一次, 然后ABC都从dwd层里去取过滤好的数据, 复用了dwd层计算的中间结果

4. 业务解耦

5. 层次分明, 便于管理和维护

分为哪些层:

1. ods(原始数据)

   1. 备份初始数据, 保持数据原貌不做任何修改
   2. 创建分区表, 防止后续的全表扫描
   3. 数据采用压缩, 减少占用的磁盘空间

2. dwd(处理初始数据, 如ETL等)

   1. 处理数据:

      1. 过滤掉脏数据(空值, 非法数据)
      2. 对敏感数据进行脱敏, 比如将手机号中的几位变成*
      3. 对一些数据进行加密

   2. 维度退化

      用到维度表时要进行join, 而join操作非常耗时; 所以对于那些分的过细的维度进行退化删除, 减少后续的join

      如: 商品表、spu表、品类表、一级分类、二级分类、三级分类 -> 商品表

      ​ 省份表、地区表 -> 地区表

      维度退化：将维度表和事实表, 合成一张表

      实时数仓里维度退化指的是: 主流要和A, B, C三条流进行维度关联, 干脆让A先关联B, 再去关联C, 最后主流只和A进行关联

   3. 解析用户行为数据, 将其分到不同的dwd层的表

   4. 列式存储

   5. 压缩

3. dim(维度表)

   建立维度表, 比如日期维度, 用户维度

4. dws(聚合)

   当天数据的汇总

5. dwt(聚合)

   最近一段时间数据的汇总, 迄今为止的数据汇总, 首次时间, 末次时间

6. ads(面向需求指标)

   根据各种需求指标, 对dws/dwt层数据做进一步分析

三、数仓建模:

维度字段:

group by的字段, 是看待问题的角度, 如省份, 时间, 年龄段, 职业

度量值:

可以用来聚合的值, 如下单金额, 下单次数

维度表:

是对事实的描述信息, 是宽表(有很多列), 数据不经常变化

组成:

​ id+维度信息, 可能还有其他表的维度字段

事实表:

每行数据代表一个事件(下单, 点赞), 是高表(有很多行), 数据经常变化

由 维度字段+度量值 组成

分类:

1. 周期型快照事实表(同步策略: 全量更新)

   不会保留所有数据, 只会保留固定时间间隔内的数据;

   例如每天或者每月的销售额 或 每月的账户余额, 不关心数据的变化过程, 只关心最终聚合值

2. 事务型事实表(同步策略: 增量更新)

   数据不允许修改

3. 累积型快照事实表(同步策略: 新增及变化)

   用于跟踪业务事实的变化, 数据会不断修改

   例如 商品记录在 生成订单, 运输 和 签收的各个业务阶段状态都会改变

   

站在维度的角度, 去看待度量值: select 聚合(度量值) from dwd_order_info group by 维度字段

同步策略:

1. 全量更新

   适合于 数据量小 的表

2. 增量更新

   适合于 数据量大 & 不变化 的表

3. 新增及变化

   适合于 数据量大 & 变化 的表

4. 只首次同步:

   适合常年数据不变化的表: 如地区表

关系建模:

严格遵循三范式, 表分的太细, join起来费时

维度建模:

面向业务, 将业务用事实表和维度表呈现出来

模型分类:

1. 星型模型: 维度表关联只有一层
2. 星座模型: 在星型模型基础上, 多张是事实表可以共享一张维度表
3. 雪花模型: 维度表关联可以有多层

一般采用星座模型, dwd层进行维度退化, 不会有维度表关联多层的情况

建模的流程:

1. 选择业务过程

   要选取MySQL里的哪些表进行导入

2. 声明粒度

   一行数据代表什么含义; 比如是一次的下单金额, 还是一天的下单金额, 还是一周的下单金额

3. 确定维度字段

4. 确定度量值

建模工具: EZDML, 展示表与表之间的依赖关系

业务总线矩阵表:

横轴: 维度字段+度量值

纵轴: 每张事实表

有哪些表:

用户, 商品, 订单, 活动, 优惠券, 购物车

有哪些指标:

留转G复活:

1. 留存率

   今天新增了100个用户, 1天后有80个用户活跃, 那么一日留存率就是80%

2. 转化率

   商品详情 -> 下单 -> 支付

3. GMV(销售总额)

4. 复购率

5. 日活

全部指标:

订单表 VS 订单详情表:

订单表的订单状态会发生变化, 而订单详情表是不变的,

订单表 指向 订单详情表

拉链表:

介绍:

拉链表记录每条信息的生命周期(开始日期, 结束日期), 一旦一条记录的生命周期结束, 就会新开启一个生命周期

如果当前信息至今仍在有效, 则结束日期记为9999-99-99

为什么要做拉链表?

以前有多少数据就存多少行, 而现在只要那个时间段内数据不变, 则只需要存一条数据, 更节省内存

什么样的表适合做成拉链表?

数据会缓慢发生变化的表

制作流程:

以订单表为例:

1. 第一天的初始拉链表: 将每一条数据添加两个字段, 开始日期为当天, 结束日期为9999-99-99

2. 以后的拉链表:

   1. 将原先拉链表记作t1

   2. 获得订单表里当天产生的数据, 记作临时表t2

   3. 用两个select 去union all, 第一个select是 select t2, 所有数据开始日期为当天, 结束日期为9999-99-99

      这部分数据涵盖 当天的新增数据 和 变化后的新状态数据

   4. 第二个select是 用t1 去 left join t2

      • 如果是t1表独有的数据, 就说明此数据没发生变化, 开始日期和结束日期不做修改
      • 如果是t1表和t2表共有的数据, 说明此数据发生变化了, 需要对数据的旧状态结束日期改为(当天日期-1), 开始日期不变

   用这两个select union all后的结果去替换原始拉链表, 就得到了最新的拉链表

如何使用拉链表?

查询2020-06-14号及之前的历史数据:

select * from user where start_date<='2020-06-14' and end_date>='2020-06-14'

四、ADS层指标:

最近连续3周都活跃的用户数

思路: 下面的分层, 对用户每周的登录进行去重; 然后按uid分组, having count(*)=3

​ 获取上周一的日期: date_add(next_day(‘2020-06-14’,‘MO’),-7*2)

最近7天内 连续3天都活跃的用户数

思路: 等差数列(日期-rank排名=开始日期)

五、数据治理:

数据质量:

数据的准确性和可信赖度

监控原则:

1. 单表数据量监控

   一张表的行数 在一个范围内

2. 单表空值检测

   某个字段为空的行数 在一个范围内

3. 单表重复值检测

   某个字段的重复值行数 在一个范围内

4. 单表值范围检测

   某个字段超出 合法数据范围 的行数 在一个范围内

5. 跨表数据量对比

   两张表的数据量相差行数 在一个范围内

权限管理:

Ranger 对大数据组件, 数据库, 表, 字段 进行鉴权拦截

元数据管理:

Atlas可以 生成 表与表 之间的血缘关系图(粒度能细化到字段级别)

用途: 便于梳理表与表之间的关系, 便于评估一张表执行失败后 能影响的范围

六、其他:

数据集市:

是一种微型的数据仓库, 是部门级别的, 小于企业级别

数据湖:

有Hudi, Iceberg, 可以处理任何类型的数据(结构化数据, 非结构化数据), 还有数据挖掘能力

中台:

避免重复造轮子, 对于公共通用的 业务/技术/数据 进行封装

1. 业务中台

   

2. 技术中台

   

3. 数据中台

   

4. 算法中台

   

标签：数仓,拉链,离线,基础知识,订单,日期,维度,数据,select
来源： https://blog.csdn.net/weixin_46141936/article/details/121846412

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。