文章目录
1.1 数据获取与数据分析的区别
信息(或者说是数据)一般有两个目的:
- 记录操作(操作型系统)
- 指定决策(DW/BI系统)
操作性系统一般一次只处理一个事务(获取订单 记录问题等), 如果要优化方向在于让其更快的处理事务, 因此不必维护历史数据, 只需要修改数据来反映最新的状态即可
DW/BI系统会处理成千上万的事务(本周新订单与过去一周进行比较, 并寻找新客户原因), 如果要优化方向在于让其高性能完成用户的查询, 因此需要维护历史数据
1.2 数据仓库和商业智能的目标
-
存取信息方便
内容必须易于理解, 不光是让开发理解, 也要让业务理解.
支持以各种方式分隔和合并数据, 以进行分析.
访问数据的BI工具要简单.
较短时间将查询结果返回(不满足后两点你会被吐槽死) -
一致性
数据可信(数据清洗一定要确保数据质量)
同名同意(名字一样则含义一样) -
适应变化
需求会变, 业务会变, 数据更会变. 对这些变化进行调整时不应该影响已有的数据和应用
如果必须去修改DW, 也应该对用户透明 -
及时性
对时效有一些要求,数据要及时发布出来 -
安全性
数据比较敏感, 必须控制访问权限 -
权威性
DW系统最重要的输出就是基于对数据的分析而产生的决策 -
业务群体接受
要让业务群体接受并积极使用它
1.3 维度建模简介
为什么维度建模是分析数据的首选技术呢?
- 数据业务用户可理解
- 高效的查询性能
什么是3NF, 使用3NF目的是什么?
3NF(三范式)主要的目的是 消除冗余, 将数据划分成不同的实体, 每个实体一张表
请比较下维度模型和3NF?
其实维度模型和3NF模型所包含的信息都是一样子的, 他们的主要区别就是规范化的程度不一样
1.3.1 星型模型和OLAP多维数据库
什么是星型模型, 及OLAP?
在关系数据库管理系统实现的维度模型成为星型模型, 而在多维数据库环境实现的维度模型称为联机分析处理(OLAP)
关系型数据库管理系统 和 多维数据库系统 是什么意思?
关系型数据库是二维表, 多维数据库可以存储两个以上的数据维
1.3.2 用于度量的事实表
事实表存储什么内容?
存储业务过程所产生的度量结果 (销售过程产生的销售额)
同一业务过程产生了多个度量, 怎么存储?
销售过程产生了销售额 销售数量等多个度量, 他们应当存储在同一个维度模型中
业务产生的度量的数据量巨大, 分开存储好不好?
不行, 应当建立单一的集中式数据仓库让多个组织访问, 来确保他们使用的数据是一致的
请解释下粒度?
事实表中的一行就对应了业务过程产生的一个度量. 这一行数据是一个特定级别的细节数据, 称为粒度
举例 : 销售事实表中的一行代表了什么呢?
假设小阳同学去商店买了两瓶酸奶,一个面包 付款之后拿到了一张小票…
因为后期可能要以商品为维度进行数据分析,所以存储结果如下:
日期维度键 | 商品维度键 | 销售额 | 销售数量 |
---|---|---|---|
1 | 1 | 10 | 2 |
1 | 2 | 3 | 1 |
事实表中的事实可分成哪几类?
可加: 销售额, 可从所有维度加和
半可加: 余额, 不能按照时间维度进行加和
不可加: 单价, 所有维度不可加和
数值类型: 存储的事实是数值, 可进一步划分 可加 半可加 不可加
文本类型: 理论上可行, 但是一般会把文本放到维度上以减少空间开销. 除非对事实表的每行文本都市唯一的
事实表的粒度可分成哪几类?
事务 周期性快照 累计快照
1.3.3 用于描述环境的维度表
维度表是做什么的?
用于描述业务过程产生的度量的环境, 一般描述 谁 什么时间 什么地点 做什么 如何做 为什么要做
维度表存储什么内容?
首先声明维度表中的内容一般用于做 查询约束 分组 报表标识等. 那么维度表的内容应该是真是的词汇, 而不是令人迷惑的缩写.
上面不是说维度表不要存一些标识符(操作码), 而是将它们解码成真实的词汇嘛, 那如果我的标识符有业务含义, 我需要用到它去和后台的操作环境进行交互, 这个怎么办?
将标识符存成一列, 然后加一列对这列标识符进行友好的文本描述
我的标识符设计规则是前两列代表区域, 三四列代表类别, 这样的该怎么存储?
拆分成多列, 方便用户进行查询
如何判断一个数值数据是事实还是维度?
包含多个值 且 是计算的参与者 -> 事实
具体指的描述 且 是常量 约束 标识的参与者 -> 维度
连续值数字基本上可以认为是事实, 来自于一个不太大列表的离散数字基本上可以认为是维度
1.3.4 星型模式中维度于事实的连接
1.4 Kimball的DW/BI架构
由四部分组成: 操作型源系统 ETL系统 数据展现 商业智能应用
1.4.1 操作型源系统
处理业务所产生的事务的系统 (销售业务会产生很多的事务, 比如生成订单, 查询商品库存等)
1.4.2 获取-转换-加载(ETL)系统
获取是将数据从操作型源系统导入数据仓库环境, 意味着读取并理解源数据并将需要的数据复制到ETL系统中
转换: 数据清洗(消除拼写错误 解析标准格式等) 合并来自不同数据源的数据等. 反正目的就是将数据标准化不要乱七八糟的. 另外这里可以记录元数据来改进数据质量
加载: 将转换好的数据加载到展现区的维度模型中(这里为什么是维度模型, 规范化结构行吗? 不行, 规范化结构难以满足可理解性和性能两个目标)
1.4.3 用于支持商业智能决策的展现区
存储数据. 支持用户 报表制作者 或者其他BI用用的查询. 展现区必须是维度化的(规范化难以满足简单性和性能)、原子的(存储细节数据)、以业务过程为中心的(不能按照个别部门需要的数据构建)、使用总线结构(公共一致性维度)的数据仓库
1.4.4 商业智能应用
利用展现区为商业用户提供分析决策的能力(很显然, 查询的性能很重要)
1.4.5 以餐厅举例描述下Kimball架构
① 高效: 餐厅人满为患, 我们要尽快把菜做出来, 提前把菜洗好, 或者提前炒好菜不要现炒
② 一致性: 同一份菜味道要一样, 我们把调味酱提前放进菜里, 而不是让顾客自己放
③ 完整性: 不希望顾客中毒或者串味, 所以素菜工作台和肉类工作台要分开
④ 质量: 菜肴要达到一定的标准才能上桌, 否则重做