目录
1.数据仓库的概念
数据仓库是一个为数据分析而设计的企业级数据管理系统。数据仓库可集中、整合多个信息源的大量数据,借助数据仓库的分析能力,企业可从数据中获得宝贵的信息进而改进决策。同时,随着时间的推移,数据仓库中积累的大量历史数据对于数据科学家和业务分析师也是十分宝贵的。
目前大数据平台的架构有以下三种架构:
① 数据仓库(Data Warehouse)是一个面向主题的(Subject Oriented)、集成的(Integrated)、相对稳定的(Non-Volatile)、反映历史变化的(Time Variant)数据集合,用于支持管理决策和信息的全局共享。
② 数据湖(Data Lake)是一个存储企业的各种各样原始数据的大型仓库,其中的数据可供存取、处理、分析及传输。数据湖是以其自然格式存储的数据的系统或存储库,通常是对象blob或文件。
③ 湖仓一体(Data LakeHouse): 为企业提供一个统一的、可共享的数据底座,避免传统的数据湖、数据仓库之间的数据移动,将原始数据、加工清洗数据、模型化数据,共同存储于一体化的“湖仓”中,既能面向业务实现高并发、精准化、高性能的历史数据、实时数据的查询服务,又能承载分析报表、批处理、数据挖掘等分析型业务。
1.1数据仓库的核心架构
1.2 数据仓库建模的意义
如果把数据看作图书馆里的书,我们希望看到它们在书架上分门别类地放置;如果把数据看作城市的建筑,我们希望城市规划布局合理;如果把数据看作电脑文件和文件夹,我们希望按照自己的习惯有很好的文件夹组织方式,而不是糟糕混乱的桌面,经常为找一个文件而不知所措。
数据模型就是数据组织和存储方法,它强调从业务、数据存取和使用角度合理存储数据。只有将数据有序的组织和存储起来之后,数据才能得到高性能、低成本、高效率、高质量的使用。
高性能:良好的数据模型能够帮助我们快速查询所需要的数据。
低成本:良好的数据模型能减少重复计算,实现计算结果的复用,降低计算成本。
高效率:良好的数据模型能极大的改善用户使用数据的体验,提高使用数据的效率。
高质量:良好的数据模型能改善数据统计口径的混乱,减少计算错误的可能性。
1.2 数据仓库建模方法论
1.2.1 ER模型
数据仓库之父Bill Inmon提出的建模方法是从全企业的高度,用实体关系(Entity Relationship,ER)模型来描述企业业务,并用规范化的方式表示出来,在范式理论上符合3NF。
1)实体关系模型
实体关系模型将复杂的数据抽象为两个概念——实体和关系。实体表示一个对象,例如学生、班级,关系是指两个实体之间的关系,例如学生和班级之间的从属关系。
2)数据库规范化
数据库规范化是使用一系列范式设计数据库(通常是关系型数据库)的过程,其目的是减少数据冗余,增强数据的一致性。
这一系列范式就是指在设计关系型数据库时,需要遵从的不同的规范。关系型数据库的范式一共有六种,分别是第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF)。遵循的范式级别越高,数据冗余性就越低。
3)三范式
省略………………
下图为一个采用Bill Inmon倡导的建模方法构建的模型,从图中可以看出,较为松散、零碎,物理表数量多。
这种建模方法的出发点是整合数据,其目的是将整个企业的数据进行组合和合并,并进行规范处理,减少数据冗余性,保证数据的一致性。这种模型并不适合直接用于分析统计。
1.2.2 维度模型
数据仓库领域的令一位大师——Ralph Kimball倡导的建模方法为维度建模。维度模型将复杂的业务通过事实和维度两个概念进行呈现。事实通常对应业务过程,而维度通常对应业务过程发生时所处的环境。
注:业务过程可以概括为一个个不可拆分的行为事件,例如电商交易中的下单,取消订单,付款,退单等,都是业务过程。
下图为一个典型的维度模型,其中位于中心的SalesOrder为事实表,其中保存的是下单这个业务过程的所有记录。位于周围每张表都是维度表,包括Date(日期),Customer(顾客),Product(产品),Location(地区)等,这些维度表就组成了每个订单发生时所处的环境,即何人、何时、在何地下单了何种产品。从图中可以看出,模型相对清晰、简洁。
维度建模以数据分析作为出发点,为数据分析服务,因此它关注的重点的用户如何更快的完成需求分析以及如何实现较好的大规模复杂查询的响应性能。
1.3维度建模之事实表
事实表是维度建模的核心表和基本表。
它存储了业务过程中的各种度量和事实,而这些度量和事实正是下游数据使用人员所要关心和分析的对象。
目前事实表主要探讨三种:
- · 事务事实表
- · 快照事实表
- · 累计快照事实表
还有一种特殊的事实表——无事实的事实表,最后还将讨论事实表的聚集和汇总。
1.3.1事务事实表
事务事实表是维度建模事实表中最为常见、使用最为广泛的事实表。
事务事实表通常用于记录业务过程的事件,而且是原子粒度的事件。事务事实表中的数据在事务事件发生之后,数据的粒度通常是每个事务一条记录。一旦事务被提交,事实表数据被插入,数据就不再进行更改。
我们通过事务事实表存储单次业务事件 / 行为的细节,以及存储与事件相关的维度细节,用户即可以单独或者聚合分析业务事件和行为。
事务事实表的粒度确定是事务事实表设计过程中的关键步骤,一般都会包含可加的度量和事实。理解概念的最佳途径无疑是实际的例子,因此下面将结合超市零售业务以及维度建模的四个环节来说明事务事实表。
(1)选择业务过程
在超市的零售示例中,业务用户做的事情是更好的理解POS系统记录顾客购买的情况,那么很容易确定业务过程就是POS系统记录的顾客购买情况,即在什么时候、什么商品、哪个收银台、销售了哪些产品等。
(2)定义粒度
顾客单次购买行为的体现是一张购物小票,但是事务事实表应该选择最原子粒度的事件,所以小票的子项(在业务上的动作即为收银员每次扫描的商品条码)应该是超市零售事务事实表的粒度。
(3)确定维度
小票子项的粒度确定后,销售日期、销售商品、销售收银台、销售门店等维度很容易被确定了。另一个不太容易考虑到的是维度是促销行为,但是通过和业务人员交流或者查看报表表头等也能够发现此维度。
(4)确定事实
维度设计的最后一步,是确定哪些事实和度量应该在事实表中出现。对于本例,商品销售数量、销售价格和销售金额很容易确定下来。但是实际上,商品的成本价是确定的,因此可以很容易地确定商品的销售毛利:(商品实际销售价格-商品成本价) 销售数量,基于下游使用便利这一因素,也应该将此放人事务事实表中。
基于毛利润也可以计算出毛利率,那么毛利率这种比例应该放入事务事实表吗?在事实表的设计中,一个常见的原则是只存放比例的分子和分母,因此比例的计算是和业务强,业务逻辑可能非常的复杂,所以一般不加入事实表中。
至此,我们也完成了超市零售事务的事实表和维度表的设计,超市零售事务事实表以及相关的维度表如图所示:
1.3.2快照事实表
在实际的业务活动中,除了关心单次的业务事件和行为外,很多时候还关心业务的状态(当前状态、历史状态)。以超市零售业务为例,管理人员和分析人员除了关心销售情况,还会关心商品的库存情况,例如哪些商品的库存情