数据仓库建模篇-维度剑魔
目录
定义
基本要素
维度表
常见的维度表
事实表
什么是事实表？
如何构建事实表？
常见事实表类型？
两种模式
星型模型
雪花模型
总结
实施维度建模
数据矩阵
维度
粒度
事实
总结
定义
上回聊到，业务系统的建模目的是为了实现业务功能，数据建模是为了实现统计分析。数据建模常用维度建模作为方法论来实现，那么维度建模有哪些内容？如何实施呢？（方法论的学习是枯燥且乏味的，但是方法论就像一个武林高手的内功，内功修炼好了，招式才可以千变万化，Come on!）
维度建模：按照事实表、维度表来构建数据仓库模型的方法，称之为维度建模。根据维度表和事实表之间的链接方式，分为星型模型和雪花模型。那么事实表、维度表是什么东西？常听到的业务过程、属性、事实、度量、粒度、指标又都是什么东西？名词太多傻傻分不清。我们看下图
大部分的名词从上面的图中都可以反映出来，但是理解起来还是比较抽象。我们尽量用人话来分析一下。
维度：维度是看数据的角度，一般是业务涉及的实体或者属性，比如用户、商家、商品、城市，甚至于一堆属性的集合都能作为一个单独的维度；
属性：用作描述维度的特征。比如用户维度的年龄、性别、身高、是否秃顶等等~
事实：这个是最抽象的，可以理解成一个或者多个业务动作，比如下单、点赞、评论，这些都是事实，同时为了描述事实，会通过比较下单时间、下单状态等等来体现这个事实；
度量：对事实的衡量，比如下单金额、积分等等
指标：看上去和度量很像，但是一般指标都伴随着维度，所以个人理解，还没构建维度建模之前的衡量叫度量，构建维度建模的时候度量变成了指标，同时指标也可以通过多个度量生成；
粒度：粒度说的是事实表的主键，比如交易域中的订单事实表，一般有两个，一个父订单粒度，一个子订单粒度，为什么呢？因为父订单只关心用户这次下单花了多少钱，实付多少钱。但是子订单关心用户这次下单里面的每个商品多少钱，实付多少钱。这两个粒度是同时存在的，那有同学就要问了，很明显子订单粒度比父订单细，那为什么还需要存在父订单粒度呢？这个啊是因为子订单的原价和实付价不能直接上卷出父订单的原价和实付价，这是为什么呢？因为补贴的存在，补贴有商家补贴、平台补贴、商品补贴，如果是零售行业，还存在配送费补贴，那这时候实付部分的分担就是个问题了。举个栗子：
商品1：原价100，现加价50；
商品2：原价100，现价60；
配送费20，免了；
平台红包5块。
对于父订单粒度：原价100+100+20=220；
实付：50+60-5=105。
对于子订单粒度：商品1：原价：100，实付：50；
商品2：原价：100，实付：60。
无法从子订单粒度累加父订单的度量。
那么有同学就要问了，你这不讲道理，你在子订单粒度上没加配送费和平台红包。ok，确实没加，但是怎么加呢？不管怎么加都是一个口径，那这个口径变了呢？如何维护？所以这两个粒度是同时存在的。是不是觉得不够严谨，那么我们加一句话就好了-仅代表个人观点。Perfect~
基本要素
维度表
维度建模中维度占了两个字，这证明维度表在建模中的地位。那么维度表一般有哪几种呢？
常见的维度表
单值维度
顾名思义，就是只通过一个外键关联并且维度属性没有层级关系，那必须举个栗子：用户维度表，通过用户id关联，用户属性没有层级关系，nice；
|
用户id（主键） |
用户姓名 |
用户性别 |
用户年龄 |
用户身高 |
用户是否秃顶 |
|
666 |
提莫 |
女 |
12 |
102cm |
应该不是 |
多值维度
通过多个外键关联，我们想想怎么编~~对了，商家客服维度：
|
商家id （联合主键） |
客服id （联合主键） |
商家名称 |
客服名称 |
客服状态 |
|
857 |
996 |
老乡别走 |
店大欺客 |
隐身 |
层次维度
这个比较常见的，比如城市：
|
城市id |
省市id |
国家id |
城市名称 |
省市名称 |
国家名称 |
|
1 |
2 |
3 |
杭州 |
浙江 |
中国 |
还有一些不常见的杂项维，这里就不一一列举了，可以参考《大数据之路》。
维度分类以外的那点事
维度分类我们知道了，但是维度表都是从哪儿来的呢？当然一般都是从业务库来的，但是有些维度表比较特殊，比如流量域的入口维度，这个维度本身在业务系统是不存在的，所以只能通过手动来维护，手动维护这个方案一听就比较扯淡，那怎么办呢？可以尝试开发一个小工具，专门维护维度表的上传和变更，这就很舒服。
除了常见的维度表类型以外，我们经常遇到一些常见的场景，比如缓慢变化维的处理、维度的拆解、退化维。不要着急哈，这些场景，村长会在后面的场景篇挨个给大家讲解。
事实表
什么是事实表？
用来描述业务过程的一种数据结构，更加方便统计分析，让我们来看看他是什么玩意。
如何构建事实表？
识别业务过程
选择事实表类型
选定维度及确定粒度
添加度量
冗余度量
常见事实表类型？
|
类型 |
事务性事实表 |
周期快照事实表 |
累计快照事实表 |
|
特点 |
1、通常一条记录表述一个发生的事件或者行为； 2、追加，不更新； 3、还分为单事务事实表和多事务事实表 |
1、一条记录描述一个实体在统计时间的状态或现状‘ 2、统计时间作为分区； 3、一个分区为全量数据 |
1、一条记录累计记录在一个业务流程中发生的多个事件，分别用不同的事件和相关消息描述时间发生时的关键信息； 2、merge更新，整个表的主键不会重复 |
|
应用场景 |
统计事件发生情况 |
统计当前状况或者历史状况平均 |
统计流程节点运转效率 |
|
案例 |
访问记录 |
账户余额快照 |
付费成功记录表 |
事务性事实表
单事务事实表
只有下单这一个业务过程，这种比较适合下游ETL依赖。
|
订单id |
下单时间 |
下单金额 |
|
996 |
20211208 |
10086 |
多事务事实表
一般会把关联度很高的相邻业务过程放在一起作为多事务的事实表，为了区分不同的事务，会通过一些flag标记来区分，比如is_order、is_pay，这种设计，会在不同时间分区中存在同一个订单id，使用的时候需要通过这些flag区分。
|
订单id |
下单时间 |
支付时间 |
是否下单 |
是否支付 |
下单金额 |
ds |
|
996 |
20211208 |
null |
1 |
0 |
100 |
20211208 |
|
996 |
20211208 |
20211209 |
1 |
1 |
100 |
20211209 |
周期快照事实表
这种事实表说的是dws的轻度汇总层，一般都是某个维度的一些基础指标，分区时间作为统计时间。
|
用户id |
累计支付金额 |
分区时间 |
|
857 |
10086 |
20211208 |
累计快照事实表
最常见的就是把多事务事实表和累计快照事实表弄混淆。那么这两个表区别是什么呢？
多事务事实表只包含个别几个业务过程，并且不同分区会存在同一个主键id；
累计快照事实表是包含某个业务的整个生命周期的所有业务过程，并且生命周期范围内的不同分区的主键id不会重复。
注意:我用了一个很严谨的说法：生命周期范围内，而不是所有分区，为什么呢？因为累计快照事实表的设计会把生命周期还没有走完的数据放在同一个分区30001231中，把完结的才会根据完结时间插入对应的分区中，除了那个特殊的分区以外，其他都是以完结时间作为分区时间。
|
订单id |
下单时间 |
支付时间 |
物流时间 |
分区 |
|
996 |
20211208 |
20211209 |
20211209 |
20211209 |
|
997 |
20211208 |
20211209 |
30001231 |
除了上面三种事实表以外，还有一种无事实的事实表。大家如果是做过用户行为数仓，肯定会见过日志数据，有些日志数据里面除了一堆的外键以外没有其他啥东西了，这种就是无事实的事实表，并不常见，知道就好。
两种模式
星型模型
当所有的维度表都是和事实表直接相连的时候，整个图形看上去就像是一个星星，我们称之为星型模型。星型模型是一种非正规化的架构，因为多维数据集的每一个维度都和事实表直接相连，不存在渐变维度，所以有一定的数据冗余，冗余的目的就是在统计情况下，不需要和外表关联进行查询和数据分析，因此效率相对较高。
雪花模型
当有多个维度表没有直接和事实表相连，而是通过其它的维度表，间接的连接在事实表上，其图形就像是一个雪花，因此我们称之为雪花模型，雪花模型的优点是减少了数据冗余，在进行数据统计或分析的时候，需要和其他的表进行关联。换句话说，对星型模型的维度表进行了范式化， 即为雪花模型 。
总结
星型模型和雪花模型最根本的区别就是，维度表是直接连接到事实表还是其他的维度表。
雪花模型的优点：通过最大限度的减少数据量以及连接较小的维度表来实现改善查询的功能，雪花结构减少的数据的冗余。
雪花模型缺点：在雪花模型需要事实表和维度表之间的连接较多，因此查询性能会相对较低，同时雪花模型需要事实表和维度表之间的连接较多，因此查询性能会相对较低
适用情况：星型模型更适用于做指标分析，而雪花模型更适用于做维度分析
实施维度建模
巴拉了那么多的概念和模式，那我们到底该如何下手实施一个维度建模的案例呢？
完整的实施步骤如下（这也是onedata的实施步骤）：
数据矩阵
维度
商家
商品
用户
粒度
交易域一般都是订单、订单商品粒度
事实
交易事务型事实表
某宝的交易事实表是一个多事务事实表，包含了下单、支付和确认收货三个业务过程，如果拆分成单事务事实表，那就是交易下单事务事实表、交易支付事务事实表和交易确认收货事务事实表。
但是在构建表结构的时候，为了快速识别这三个业务过程，会加上3个标签：is_create、is_pay、is_succ。
Is_create=Y，则表示是当天下单的订单，满足这个条件的就是下单这个业务过程所有的数据了，下单相关的度量也就有值了。
Is_pay=Y，同理，是当天支付的订单，满足这个条件可以统计当天支付相关的度量了。
Is_succ=Y，表示当天确认收货的，这里使用succ而不是end，就为了表示这个完结就是确认收货，确认收货则认为这笔订单是成功了的，所以使用succ而没有使用end或者finish。
使用这三个表标签就可以圈定一个业务过程了，如果想同时圈定两个业务过程，比如获取当天下单和当天支付的，则可以使用is_create=Y and is_pay=Y即可。
参考大数据之路的例子如下：
交易全流程表
交易全流程表是交易事务性事实表的扩展，事务表可以方便的统计每个事务的事情，比如拍下订单量、支付金额等，但是一旦要统计时间跨度就不支持了，比如拍下到支付的平均时长、支付到确认收货的平均时长等，基于此，设计了交易全流程表，全流程表是累积型快照事实表的一个实例。累计型快照事实表，一般是以事务性事实表加工而成，也即将事务型事实表的几个事件进行串起来，然后统计时间间隔需求，我们把这个表称作全流程表。
交易全流程表在交易事务表的基础上增加了两个时间，包括退款和发货，这两个也是日常统计比较多的需求，因此作为全流程表的一份子加入，所以全流程表包括下单、支付、退款、发货、确认收货5个事件间的关系。
但是累计型快照事实表每天都需要从30001231和最新数据进行merge更新，所以维护相对比较麻烦。
总结
又到了说再见的时间，村长本篇通过对维度建模相关概念的讲解和实施的例子来让家人们深入了解维度建模，希望对大家有所帮助。
另外还记得上篇中村长提到维度建模是自下而上的，往往是通过结果来反推需要什么，从而实施建模。但是这个也有例外，比如现在互联网行业的电商和零售其实建模思想都比较成熟，很多数据域的划分已经比较固定，所以在这种情况下，其实是可以上来就先把一些基础数据域构建起来，比如交易域、用户域、评价域、咨询域等等，如果是0-1，可以先把这些基础的数据域构建起来，之后再根据数据需求做事实和属性的衍生。
不过相信家人们看完本篇文章之后会对文章中提到的一些场景比较感兴趣，大家放心，后面的建模篇，村长会一一解答连载的，下一篇是模型分层，感谢大家的支持。
关注博主不迷路~
数据仓库建模篇-维度剑魔相关推荐
- 面试问题准备-数据仓库建模篇
1. 什么叫数据仓库?数据仓库的特点? (相信inmon的数据仓库概念的四个特点是最基本的吧,当然需要加上自己的理解) 首先,用于支持决策,面向分析型数据处理,它不同于企业现有的操作型数据库: 其次, ...
- 大数据建模篇--维度建模
维度建模法 维度建模法: 就是按照事实表和维度表来构建数仓 一般在数仓DWD层进行建模. 有星型模型,雪花模型,星座模型. 星形模型:事实表可以关联多个维度表,维度表之间没有关系 雪花模型:事实表关联 ...
- 数据仓库(二)之维度建模篇
概述 维度建模是一种将数据结构化的逻辑设计方法,它将客观世界划分为度量和上下文.度量是常常是以数值形式出现,事实周围有上下文包围着,这种上下文被直观地分成独立的逻辑块,称之为维度.它与实体-关系建模有 ...
- 数据仓库建模方法/范式建模法/维度建模法/事实表/维度表/优缺点/建模流程/概念建模/逻辑建模/物理建模
常见的有 范式建模法.维度建模法.实体建模法等,每种方法从本质上将是从不同的角度看待业务中的问题,不管是从技术层面还是从业务层面,都代表了哲学上的一种世界观. 1 范式建模法(Third Normal ...
- 数据仓库工具箱：维度建模权威指南3
数据仓库工具箱:维度建模权威指南3 零售业务 维度模型设计的4步 选择业务过程 声明粒度 确定维度(列名带有key后缀) 确定事实 零售业务案例研究 可加事实 不可加事实 维度表设计细节 日期维度(还 ...
- 数据仓库-基础知识(维度建模)
一.数据仓库概述 1.1 数据仓库定义 数据仓库:Data Warehouse,是为企业所决策制定过程,提供所有支持类型的数据集合.用于分析性报告和决策支持.数仓是一个面向主题.集成的.相对稳定.反应 ...
- 数据仓库知识点总结（数仓分层建模、维度建模等）
数据仓库知识点总结 推荐学习<华为数据之道><数据仓库工具箱-维度建模权威指南>两本书. 此文档是数据仓库建模的知识点总结文档,在持续更新中(2021-10-13). 文章目录 ...
- 数据仓库(4)基于维度建模的数仓KimBall架构
基于维度建模的KimBall架构,将数据仓库划分为4个不同的部分.分别是操作型源系统.ETL系统.数据展现和商业智能应用,如下图. 操作型源系统,指的就是面向用户的各类系统,如app.网站.E ...
- 数据仓库建模（四）：维度表的设计
数据仓库建模(四):维度表的设计 一.维度表的整体结构 1.1 维度表的结构设计 1.2 维度代理键 1.3 自然键.超久键和超自然键 1.4 下钻与上卷 1.5 维度退化 1.6 非规范化的扁平维度 ...
最新文章
- Docker Caffe部署
- 在服务器托管中对流量和带宽进行限制
- 在emu8086中学习几个汇编语言显示字符串的小例子
- iphone刷基带_iphone7基带坏了怎么办，iphone7基带修复多少钱
- linux libasan.so,Address Sanitizer 用法
- 计算机网络学习笔记：第二章
- 一个人开长途车旅游安全吗？
- 算法导论 思考题2-4
- flask ajax 文件上传,使用ajax上传Python flask文件请求.files空的
- 分布式系统基本原理介绍
- 4 angular 重构 项目_TypeScript项目开发实战 | 撸起来
- 真值表-Python实现
- labview利用USB-6341数据采集卡采集发动机传感器信号（总结篇）
- python金山词霸单词本批量导入
- 6 和 9 组成的最大数字
- Linux-Ubuntu终端命令
- 安装与使用 supervisor（可管理Tomcat进程）
- bool 和_Bool的使用
- QT源码剖析-QT对象通信机制信号槽的绑定具体实现
- swagger2的全新UI组件Knife4j