数仓理论建模
数据仓库
数据仓库是一个面向主题的、集成的、非易失的且随时间变化的数据集合
数仓的使用
-
结构复杂
业务数据库通常是根据业务操作的需要进行设计的&＃xff0c;遵循3NF范式&＃xff0c;尽可能减少数据冗余。这就造成表与表之间关系错综复杂。在分析业务状况时&＃xff0c;储存业务数据的表&＃xff0c;与储存想要分析的角度表&＃xff0c;很可能不会直接关联&＃xff0c;而是需要通过多层关联来达到&＃xff0c;这为分析增加了很大的复杂度。
举例&＃xff1a;想要从门店的地域分布来分析用户还款情况。基本的还款数据在订单细节表里&＃xff0c;各种杂项信息在订单表里&＃xff0c;门店信息在门店表里&＃xff0c;地域信息在地域表里&＃xff0c;这就意味着我们需要把这四张表关联起来&＃xff0c;才能按门店地域来分析用户的还款情况。
此外&＃xff0c;随着NoSQL数据库的进一步发展&＃xff0c;有许多数据储存在诸如MongoDB等NoSQL数据库中&＃xff0c;另外一些通用信息&＃xff0c;如节假日等&＃xff0c;通常也不会在数据库中有记录&＃xff0c;而是以文本文件的形式储存。多种多样的数据储存方式&＃xff0c;也给取数带来了困难&＃xff0c;没法简单地用一条SQL完成数据查询。如果能把这些数据都整合到一个数据库里&＃xff0c;比如构造一张节假日表。这样就能很方便地完成数据查询&＃xff0c;从而提高分析效率。
-
数据脏乱
因为业务数据库会接受大量用户的输入&＃xff0c;如果业务系统没有做好足够的数据校验&＃xff0c;就会产生一些错误数据&＃xff0c;比如不合法的身份证号&＃xff0c;或者不应存在的Null值&＃xff0c;空字符串等。
-
理解困难
业务数据库中存在大量语义不明的操作代码&＃xff0c;比如各种状态的代码&＃xff0c;地理位置的代码等等&＃xff0c;在不同业务中的同一名词可能还有不同的叫法。
这些情况都是为了方便业务操作和开发而出现的&＃xff0c;但却给我们分析数据造成了很大负担。各种操作代码必须要查阅文档&＃xff0c;如果操作代码较多&＃xff0c;还需要了解储存它的表。来自不同业务数据源的同义异名的数据更是需要翻阅多份文档。
-
缺少历史
出于节约空间的考虑&＃xff0c;业务数据库通常不会记录状态流变历史&＃xff0c;这就使得某些基于流变历史的分析无法进行。比如想要分析从用户申请到最终放款整个过程中&＃xff0c;各个环节的速度和转化率&＃xff0c;没有流变历史就很难完成。
-
大规模查询缓慢
当业务数据量较大时&＃xff0c;查询就会变得缓慢。尤其需要同时关联好几张大表&＃xff0c;比如还款表关联订单表再关联用户表&＃xff0c;这个体量就非常巨大&＃xff0c;查询速度非常慢。美好的青春都浪费在了等待查询结果上&＃xff0c;真是令人叹息。
主题
面向主题
主题&＃xff08;Subject&＃xff09;
将企业信息系统中的数据进行综合、归类和分析利用的一个抽象概念
每一个主题基本对应一个宏观的分析领域
例如“销售分析”就是一个分析领域&＃xff0c;那么这个数据仓库应用的主题就是“销售分析”
采购子系统&＃xff1a;
订单&＃xff08;订单号&＃xff0c;供应商号&＃xff0c;总金额&＃xff0c;日期&＃xff09;
订单细则&＃xff08;订单号&＃xff0c;商品号&＃xff0c;类别&＃xff0c;单价&＃xff0c;数量&＃xff09;
供应商&＃xff08;供应商号&＃xff0c;供应商名&＃xff0c;地址&＃xff0c;电话&＃xff09;销售子系统&＃xff1a;
顾客&＃xff08;顾客号&＃xff0c;姓名&＃xff0c;性别&＃xff0c;年龄&＃xff0c;文化程度&＃xff0c;地址&＃xff0c;电话&＃xff09;
销售&＃xff08;员工号&＃xff0c;顾客号&＃xff0c;商品号&＃xff0c;数量&＃xff0c;单价&＃xff0c;日期&＃xff09;库存管理子系统&＃xff1a;
领料单&＃xff08;领料单号&＃xff0c;领料人&＃xff0c;商品号&＃xff0c;数量&＃xff0c;日期&＃xff09;
进料单&＃xff08;进料单号&＃xff0c;订单号&＃xff0c;进料人&＃xff0c;收料人&＃xff0c;日期&＃xff09;
库存&＃xff08;商品号&＃xff0c;库房号&＃xff0c;库存量&＃xff0c;日期&＃xff09;
库房&＃xff08;库房号&＃xff0c;仓库管理员&＃xff0c;地点&＃xff0c;库存商品描述&＃xff09;人事管理子系统&＃xff1a;
员工&＃xff08;员工号&＃xff0c;姓名&＃xff0c;性别&＃xff0c;年龄&＃xff0c;文化程度&＃xff0c;部门号&＃xff09;
部门&＃xff08;部门号&＃xff0c;部门名称&＃xff0c;部门主管&＃xff0c;电话&＃xff09;主题一&＃xff1a;顾客
固有信息&＃xff1a;顾客号&＃xff0c;姓名&＃xff0c;性别&＃xff0c;年龄&＃xff0c;文化程度&＃xff0c;地址&＃xff0c;电话
购物信息&＃xff1a;顾客号&＃xff0c;商品号&＃xff0c;单价&＃xff0c;数量&＃xff0c;金额&＃xff0c;日期&＃xff0c;...主题二&＃xff1a;供应商
固有信息&＃xff1a;供应商号&＃xff0c;供应商名&＃xff0c;地址&＃xff0c;电话
供应商品信息&＃xff1a;订单号&＃xff0c;供应商号&＃xff0c;总金额&＃xff0c;日期
主题三&＃xff1a;商品
固有信息&＃xff1a;商品号&＃xff0c;商品名&＃xff0c;类别&＃xff0c;颜色&＃xff0c;尺寸&＃xff0c;型号
采购信息&＃xff1a;商品号&＃xff0c;供应商号&＃xff0c;日期&＃xff0c;采购价格&＃xff0c;采购量
库存信息&＃xff1a;商品号&＃xff0c;库房号&＃xff0c;库存量&＃xff0c;日期
销售信息&＃xff1a;顾客号&＃xff0c;商品号&＃xff0c;数量&＃xff0c;单价&＃xff0c;日期
主题四&＃xff1a;订单
固有信息&＃xff1a;订单号&＃xff0c;员工号&＃xff0c;顾客号&＃xff0c;商品号&＃xff0c;数量&＃xff0c;单价&＃xff0c;日期员工信息&＃xff1a;员工号&＃xff0c;姓名&＃xff0c;性别&＃xff0c;年龄&＃xff0c;文化程度&＃xff0c;部门号
顾客信息&＃xff1a;顾客号&＃xff0c;姓名&＃xff0c;性别&＃xff0c;年龄&＃xff0c;文化程度&＃xff0c;地址&＃xff0c;电话
商品信息&＃xff1a;商品号&＃xff0c;商品名&＃xff0c;类别&＃xff0c;颜色&＃xff0c;尺寸&＃xff0c;型号
集成
集成性是指数据仓库中数据必须是一致的
- 数据仓库的数据是从原有的分散的多个数据库、数据文件和数据段中抽取来的
- 数据来源可能既有内部数据又有外部数据
例如F/M&＃xff0c;0/1&＃xff0c;A/B
集成方法&＃xff1a;统一&＃xff08;消除不一致&＃xff09;&＃xff0c;综合&＃xff08;对原有数据进行综合和计算&＃xff09;
非易失&＃xff08;非人为因素&＃xff09;
数据仓库中的数据是经过抽取而形成的分析型数据
- 不具有原始性
- 主要供企业决策分析之用
- 执行的主要是‘查询’操作&＃xff0c;一般情况下不执行‘更新’操作
- 一个稳定的数据环境也有利于数据分析操作和决策的制订
随时间变化&＃xff08;人为删除&＃xff09;
数据仓库以维的形式对数据进行组织&＃xff0c;时间维是数据仓库中很重要的一个维度
- 不断增加新的数据内容
- 不断删去旧的数据内容
- 更新与时间有关的综合数据
数据仓库和数据库的区别
- 数据库是为捕获和存储数据而设计
- 数据仓库是为分析数据而设计
| ** ** | 数据库 | 数据仓库 |
|---|
| 本质 | 数据的集合 | 数据的集合 |
| 定位 | 事务处理OLTP | 数据分析OLAP |
| 面向群体 | 前端用户 | 管理人员 |
| 操作 | 增删改查 | 查询 |
| 数据粒度 | 事件记录 | 维度 |
| 数据粒度 | 事件记录 | 维度 |
OLTP和OLAP的区别
- On-Line Transaction Processing 联机事务处理OLTP
- OLTP是传统的关系型数据库的主要应用
| 对比属性 | OLTP | OLAP |
|---|
| 读特性 | 每次查询只返回少量记录 | 对大量记录进行汇总 |
| 写特性 | 随机、低延时写入用户的输入 | 批量导入 |
| 使用场景 | 用户&＃xff0c;Java EE项目 | 内部分析师&＃xff0c;为决策提供支持 |
| 数据表征 | 最新数据状态 | 随时间变化的历史状态 |
| 数据规模 | GB | TB到PB |
数据仓库的架构
Inmon架构
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GDMJy5si-1614597871664)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20210301095333013.png)]](https://img8.php1.cn/3cdc5/1256d/9f3/46246884cd7b3d94.png?x-oss-process&＃61;image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlYWRlcjMyMQ&＃61;&＃61;,size_16,color_FFFFFF,t_70)
Kimball架构
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-INhRqmwp-1614597871665)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20210301095433914.png)]](https://img8.php1.cn/3cdc5/1256d/9f3/4b3cd3b01a15a683.png?x-oss-process&＃61;image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlYWRlcjMyMQ&＃61;&＃61;,size_16,color_FFFFFF,t_70)
混合型架构
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YstfHoOM-1614597871666)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20210301095510155.png)]](https://img8.php1.cn/3cdc5/1256d/9f3/55a15f10e109eff5.png?x-oss-process&＃61;image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xlYWRlcjMyMQ&＃61;&＃61;,size_16,color_FFFFFF,t_70)
数据仓库的解决方案
-
数据采集
Flume&＃xff0c;Sqoop&＃xff0c;Logstash&＃xff0c;Datax
数据ETL&＃xff08;清洗&＃xff09;
-
抽取&＃xff08;Extract&＃xff09;
从操作型数据源获取数据
-
转换&＃xff08;Transform&＃xff09;
转换数据&＃xff0c;使之转变为适用于查询和分析的形式和结构
-
装载&＃xff08;Load&＃xff09;
将转换后的数据导入到最终的目标数据仓库
-
工具
Oracle&＃xff1a;OWB和ODI
微软&＃xff1a;SQL Server Integration Services
SAP&＃xff1a;Data Integrator
IBM&＃xff1a;InfoSphere DataStage、Informatica
Pentaho&＃xff1a;Kettle
-
数据存储
MySQL&＃xff0c;HDFS&＃xff0c;HBase&＃xff0c;Redis&＃xff0c;MongoDB
-
数据计算
Hive&＃xff0c;Tez&＃xff0c;Spark&＃xff0c;Flink&＃xff0c;Storm
-
数据可视化
Tableau&＃xff0c;Echarts&＃xff0c;Superset&＃xff0c;QuickBI&＃xff0c;DataV
-
任务调度
Oozie&＃xff0c;Azkaban&＃xff0c;Crontab
数据转换
1.统一数据编码: 比如性别字段, 有些是1和0, 有些使用"F"和"M表示", 我们需要给他统一一下
2.预计算: 比如订单信息表里有"订单号, 员工号&＃xff0c;顾客号&＃xff0c;商品号&＃xff0c;数量&＃xff0c;单价&＃xff0c;日期", 这里我们就可以将"数量×单价", 提前做好计算
3.重新排序: 提高查询性能
4.去重: 数据可能会有一些重复的, 会影响到后续的分析, 所以我们需要根据实际情况进行去重
5.行列转置: lateral view explode
数据仓库的建模
数据仓库模型构建
选择业务流程
- 确认哪些业务处理流程是数据仓库应该覆盖的
例如&＃xff1a;了解和分析一个零售店的销售情况 - 记录方式
- 使用纯文本
- 使用业务流程建模标注&＃xff08;BPMN&＃xff09;方法
- 使用同一建模语言&＃xff08;UML&＃xff09;
声明粒度
- 用于确定事实中表示的是什么
例如&＃xff1a;一个零售店的顾客在购物小票上的一个购买条目 - 选择维度和事实前必须声明粒度
- 建议从原始粒度数据开始设计
原始记录能够满足无法预期的用户查询 - 不同的事实可以有不同的粒度
确认维度
- 说明了事实表的数据是从哪里采集来的
- 典型的维度都是名词
例如&＃xff1a;日期、商店、库存等 - 维度表存储了某一维度的所有相关数据
例如&＃xff1a;日期维度应该包括年、季度、月、周、日等数据
确认事实
- 识别数字化的度量&＃xff0c;构成事实表的记录
- 和系统的业务用户密切相关
- 大部分事实表的度量都是数字类型的
- 可累加&＃xff0c;可计算
- 例如&＃xff1a;成本、数量、金额
星型模型
中间一张事实表&＃xff0c;周围一圈维度表构成
优点
简化查询
简化业务报表逻辑
获得查询性能
快速聚合
便于向立方体提供数据
缺点
不能保证数据完整性
对于分析需求来说不够灵活
雪花模型
中间一张事实表&＃xff0c;周围多层维度表构成
优点
一些OLAP多维数据库建模工具专为雪花模型进行了优化
规范化的维度属性节省存储空间
缺点
维度属性规范化增加了查询的连接操作和复杂度
不确保数据完整性
星座表
两张事实表通过一张维度表关联
京公网安备 11010802041100号