☀️ 数仓建模理论，大数据邻域通用的维度建模技巧【建议收藏学习】
文章目录
- 前言：
- 正文：
- 关系建模
- 关系建模的特点
- 维度建模
- 维度建模的特点
- 事实表
- 维度模型的分类
- 各模型的适用场景
- 建模阶段具体的划分
- 1. ODS层 （ 原始数据存储层，直接加载原始日志、数据保持原貌不做处理）
- 2. DWD层 （data warehouse detail, 数仓细节层）
- 3. DWS层（data warehouse service，数仓服务层）
- 4. DM层 （data market，数据集市层）
前言：
十年生死两茫茫，千行代码，Bug何处藏。
纵使产品经理祭苍天，又怎样？
朝令改，夕断肠。
相顾无言，惟有泪千行。
每晚灯火阑珊处，夜难寐，加班狂
正文：
数仓项目开发的流程分为：
业务建模：类似需求分析，将客户的需求进行剥离
领域建模：大体设计一下有几张表，几张源表。哪张表针对哪个主题
逻辑建模：确定库名、确定表明、表里有哪些字段、字段的类型、表与表之间的关系
RDBMS(业务db，存储业务数据)，经常使用到的建模工具是PD (Power designer)物理建模：如何具体的实施，源数据库是Mysql还是Oracle、通过sqoop导入到hive表中去。在数仓部分又会有哪些数据库、哪些表、会如何实施。在各个层有哪些表，表的字段如何统计出来
本文主要介绍维度建模
维度建模为逻辑建模的环节
关系建模
关系建模的特点
1.关系建模表多
2.表与表之间的关系复杂
PS:例如查询下图中 表A与B的关联关系 需要将A、B表之间的所有表进行关联查询
因为查询会进行join操作，join操作又会触发shuffle操作，所以关系建模不太适合hadoop体系
维度建模
维度建模的特点
1.维度建模表少，容易上手
2.表与表之间的关系简单，便于理解
上图中 黄点的表为该模型的事实表
事实表
事实表由外键和度量值构成，外键就是指各个维度表的id，度量值一般为商品数量，消费金额等可以累加的数值
事实表中每一行代表一个业务事件（下单、支付、退款、评价等）。事实表示的就是业务事件中的度量值（可统计次数、个数金额等）
例如：小明5月20日在淘宝花了50元买了一瓶二锅头。
维度表：时间、用户、商品
事实表：50元、1瓶
事实表的特征
- 非常大
- 内容相对较窄（列数少，主要是外键id和度量值）
- 经常发生变化，每天会新增加很多
事实表的分类：
1. 事务型事实表
以每个事务或事件为单位
例如一个销售订单记录，一笔支付记录等，作为事实表里的一行数据。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。
2. 周期快照型事实表
周期型快照事实表中不会保留所有数据,只保留固定时间间隔的数据，例如每天或者每月的销售额，或每月的账户余额等。
例如购物车，有加减商品，随时都有可能变化，但是我们更关心每天结束时这里面有多少商品，方便我们后期统计分析。
3. 累积型快照事实表
累计快照事实表用于跟踪业务事实的变化。
例如﹐数据仓库中可能需要累积或者存储订单从下订单开始，到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。
维度模型的分类
- 星型模型
有一张事实表，周围环绕着一系列的维度表组合而成的表结构。 - 雪花模型
有一张事实表，周围环绕着一系列的维度表，维度表中复杂的字段通过其他的维度表进行详述，将这样组合而成的表结构。 - 星座（星系）模型
有多张事实表，每张事实表周围环绕着一系列的维度表，维度表又可以拥有子维度表，将这样组合而成的表结构。
PS：在真实的数仓项目中，星型模型和雪花模型使用得较多，星座模型使用得较少。
各模型的适用场景
星型模型的适用场景：
优势：
业务简单
效率高
缺点：
数据有冗余 （多余的，重复的，累赘的数据。）
雪花模型的适用场景：
优势：
关系清晰
数据冗余少，甚至没有任何冗余
缺点：
业务比较复杂
效率较低
星座模型的适用场景：
优势：
关系复杂的场合
数据量特别庞大
缺点：
可读性差，关系太复杂，查询的效率较低
模型的选择
星型还是雪花，取决于性能优先，还是灵活更优先。目前实际企业开发中，不会绝对选择一种，根据情况灵活组合，甚至并存（一层维度和多层维度都保存）。但是整体来看，更倾向于维度更少的星型模型。尤其是Hadoop体系，减少Join就是减少Shuffle，性能差距很大。(关系型数据可以依靠强大的主键索引）
数仓和数据库关系：
数据库：传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。(OLTP)
数据仓库：数据仓库系统的主要应用 是OLAP（On-Line Analytical Processing），支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。
建模阶段具体的划分
1. ODS层 （ 原始数据存储层，直接加载原始日志、数据保持原貌不做处理）
ODS层（original data store）可以通过flume采集的日志数据(因为日志是一整条一行的样式，所以ods层的日志表一个字段即可，表命名以ods_xxx为准。)
Sqoop导入业务数据（业务数据因为是结构化数据，所以需要将表结构建立为mysql中对应的业务表结构，表命名同样以 ods_业务表名 命名）
PS：
mysql的业务数据表名为 order_record(订单记录) 导入到hive中命名为 ods_order_record
log日志为操作记录 load到hive表中，表的命名为 ods_operation
ods的作用：一、数据的接收存储 二、数据存根备份
a)通过flume采集到hfds相应目录下的日志文件
b)通过sqoop导入到hdfs的一些业务db中的数据
c)创建ODS层的db, 以及db下相应的表（与rdbms源库中的表名类似，表字段一般同名，类型修改成hive表中的类型）
2. DWD层 （data warehouse detail, 数仓细节层）
DWD层需构建维度模型，一般采用星型模型，呈现的状态一般为星座模型。
维度建模一般按照以下四个步骤:
选择业务过程→声明粒度→确认维度→确认事实
a). 选择业务
在业务系统中，挑选我们感兴趣的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。
如果是中小公司，尽量把所有业务过程都选择。
如果是大公司（1000多张表〉，选择和需求相关的业务线。
b). 声明粒度
数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。
声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以此来应各种各样的需求。
典型的粒度声明如下:
订单事实表中一行数据表示的是一个订单中的一个商品项。
已支付事实表中一行数据表示的是一个支付记录。
1.建库，建表，表中的数据来自于ods层相应表中的数据
2.对数据进行脱敏，按要求清洗掉脏数据
PS：
对ODS层数据进行清洗，去除空值数据（每条数据中id为空的）、脏数据、超过极限范围的数据（订单金额大于最高订单金额）
c).确定维度
维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。
确定维度的原则是:后续需求中是否要分析相关维度的指标。
例如，需要统计，什么时间下的订单多，哪个地区下的订单多，哪个用户下的订单多。
需要确定的维度就包括:时间维度、地区维度、用户维度。
4).确定事实
确定每张表中的度量值，指的是业务中的度量值（次数、个数、件数、金额，可以进行累加的字段），例如订单金额、下单次数等。
在DWD层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。
事实表和维度表的关联比较灵活，但是为了应对更复杂的业务需求，可以将能关联上的表尽量关联上。如何判断是否能够关联上呢?在业务表关系图中，只要两张表能通过中间表能够关联上，就说明能关联上。
3. DWS层（data warehouse service，数仓服务层）
DWS层与DWT层统称为宽表层，意义就是减少重复计算
事实表和维度表的关联比较灵活，但是为了应对更复杂的业务需求，可以将能关联上的表尽量关联上。
如何判断是否能够关联上呢?在业务表关系图中，只要两张表能通过中间表能够关联上，就说明能关联上。
a) 建库，建表，表中的数据来自于dwd层相应表中的数据
b) 表一般是经过轻度聚合之后的结果
（在这层通常会有以某一个维度为线索，组成跨主题的宽表，比如，一个用户的当日的签到数、收藏数、评论数、抽奖数、订阅数、点赞数、浏览商品数、添加购物车数、下单数、支付数、退款数、点击广告数组成的多列表。）
用户行为宽表（60-70个字段）、商品宽表、支付宽表
DWS和 DWT层的区别:
DWS层存放的所有主题对象当天的汇总行为，例如每个地区当天的下单次数，下单金额等
DWT 层存放的是所有主题对象的累积行为，例如每个地区最近7天（15天、30天、60天）的下单次数、下单金额等。
4. DM层 （data market，数据集市层）
表是关于特定主题最终统计后的结果，表中的每个字段就是统计指标。（最终宽表）
建库，建表，表中的数据来自于dwd,dws层相应表中的数据 。
PS：
1.有些公司在建模时会出现DIM层（维度层，方便统一对维度表进行管理）
2.ADS层 也叫 DM层
有收获？希望烙铁们来个三连击，让更多的同学看到这篇文章
1、烙铁们，关注我看完保证有所收获，不信你打我。
2、点个赞呗，可以让更多的人看到这篇文章，后续还会有很哇塞的产出。
本文章仅供学习及个人复习使用，如需转载请标明转载出处，如有错漏欢迎指出
务必注明来源（注明： 来源：csdn ， 作者：-马什么梅-）
☀️ 数仓建模理论，大数据邻域通用的维度建模技巧【建议收藏学习】相关推荐
- 数仓 调度_大数据作业调度
大数据作业调度 云上大数据仓库解决方案 阿里云为企业提供稳定可靠离线数仓和实时数仓的解决方案,包括数据采集.数据存储.数据开发.数据服务.数据运维.数据安全.数据质量.数据地图等完整链路. 离线数仓 ...
- 传统数仓如何转型大数据
大家好,我是一哥,前几天建了一个数据仓库方向的小群,收集了大家的一些问题,其中有个问题,一哥很想去谈一谈--现在做传统数仓,如何快速转到大数据数据呢?其实一哥知道的很多同事都是从传统数据仓库转到大数据 ...
- 从传统数仓到互联网大数据开发，不走弯路很重要
1.自我介绍 二本学校毕业5年,在某已倒闭手机厂商做安卓开发3年,到银行外包写SQL1年,现在在某大厂做大数据开发工作即将一年,月处理数据量PB级别. 2.为什么要转型 转型有两个原因,一个是技术相关 ...
- 双非硕士阿里大数据开发面经(已拿offer)(建议收藏)
推荐阅读: #秋招失利,如何把握春招?(大四.研三) #大三.研二的秋招备战路线(Java.大数据) ------ 自我介绍 感谢群主峰哥秋招过程中的帮助,在年底前对秋招做一个总结分享给其他同学.先说 ...
- 数据中台 第7章 数据体系建设:数仓分层设计、数据建模
数据中台数据体系是在全域原始数据的基础上,进行标准定义及分层建模,数据体系建设最终呈现的结果是一套完整.规范.准确的数据体系,可以方便支撑数据应用. 中台数据体系应具备以下特征: ·覆盖全域数据:数据 ...
- 数分-理论-大数据3-HDFS
数分-理论-大数据3-HDFS(分布式文件系统) (数据分析系列) 文章目录 数分-理论-大数据3-HDFS(分布式文件系统) 1知识点 2具体内容 2.1背景 2.2简介 2.3体系结构 2.4存储 ...
- 融合趋势下基于 Flink Kylin Hudi 湖仓一体的大数据生态体系
简介:本文由 T3 出行大数据平台负责人杨华和资深大数据平台开发工程师王祥虎介绍 Flink.Kylin 和 Hudi 湖仓一体的大数据生态体系以及在 T3 的相关应用场景. 本文由 T3 出行大数据 ...
- 数加平台——阿里大数据OS实践
在云栖计算之旅第5期--大数据与人工智能大会上,阿里云大数据事业部数加平台技术负责人陈廷梁从数加定义.起源.愿景.价值.架构.规划六个方面分享了<数加平台--阿里大数据OS实践>.其中,他 ...
- 写文章 数据嗨客 | 第2期：线性回归 数据嗨客 | 第2期：线性回归 泊数 泊数 1 年前 普林大数据学院——“机器学习”系列 普林大数据学院依托北京大数据研究院和北京大学，为有需求的企业
数据嗨客 | 第2期:线性回归 泊数 1 年前 普林大数据学院--"机器学习"系列 普林大数据学院依托北京大数据研究院和北京大学,为有需求的企业和用户提供线上线下结合大数据培训服务 ...
最新文章
- Flex 布局：语法篇
- java中char是几个字节_Java中char占用几个字节
- python中删除字典中的某个元素_python怎样删除字典中的元素
- java匹配出某单词除外_java正则匹配 指定内容以外的 内容
- Java - 线程安全的 HashMap 实现方法及原理
- arcgis创建剖面线execl文件
- 你应该学习的 20 个 Python 代码段
- perlin噪声函数
- aotu.js 动态运行脚本_素材丨一键生成动态LOGO，3000+个样式随你选！
- 为什么选择 Visual Studio Code
- Java学习系列(十六)Java面向对象之基于TCP协议的网络通信
- 判断图片文件真实类型---通过文件表头判断。
- 多个cpp文件生成so_荐tf_sampling_so.so等文件怎么生成（多种tf版本都可的顺利解决方法）...
- flash 10 android,adobe flash 10.0.0
- 基于SSD1306的OLED的驱动学习(二):SSD1306的寻址方式
- Unity 安装失败原因
- selenium爬虫入门简单实例(获取对分易习题)
- 湖北湖南广州计算机科学大学排行,校友会2018中国大学计算机类专业排名
- 零阶保持模型和一阶保持模型离散的推导
- TLV协议——实现封包与解析