只有数据模型将数据有序的组织和存储起来之后,大数据才能得到高性能、低成本、高效率、高质量的使用。
质量:良好的数据模型能改善数据统计口径的不一致性,减少数据计算错误的可能性。
数据模型能够促进业务与技术进行有效沟通,形成对主要业务定义和术语的统一认识,具有跨部门、中性的特征,可以表达和涵盖所有的业务。
大数据系统需要数据模型方法来帮助更好地组织和存储数据,以便在性能、成本、效率和质量之间取得最佳平衡!
下图是个示例,通过统一数据模型,屏蔽数据源变化对业务的影响,保证业务的稳定,表述了数据仓库模型的一种价值:
以下是我们的一种分层设计方法,数据缓冲区(ODS)的数据结构与源系统完全一致。基础数据模型(DWD)和融合数据模型(DWI与DWA)是大数据平台重点建设的数据模型。应用层模型由各应用按需自行建设,其中基础数据模型一般采用ER模型,融合数据模型采用维度建模思路。
前面的分层设计中你会发现有两种设计方法,关系建模和维度建模,下面分别简单介绍其特点和适用场景。
当今的数据处理方式大致可以分成两大类:联机事务处理OLTP(on-line transaction processing)、联机分析处理OLAP(On-Line Analytical Processing)。OLTP是传统的关系型数据库的主要应用,主要是基本的、日常的事务处理,例如银行交易。OLAP是数据仓库系统的主要应用,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。二者的主要区别对比如下表所示
维度模型是数据仓库领域另一位大师Ralph Kimball 所倡导的。维度建模以分析决策的需求出发构建模型,构建的数据模型为分析需求服务,因此它重点解决用户如何更快速完成分析需求,同时还有较好的大规模复杂查询的响应性能,更直接面向业务。
在维度建模的基础上又分为三种模型:星型模型、雪花模型、星座模型。
星座模型与前两种情况的区别是事实表的数量,星座模型是基于多个事实表
基本上是很多数据仓库的常态,因为很多数据仓库都是多个事实表的。所以星座不星座只反映是否有多个事实表,他们之间是否共享一些维度表。所以星座模型并不和前两个模型冲突
星型模型由一个事实表和一组维表组成。每个维表都有一个维作为主键,所有这些维的主键组合成事实表的主键。强调的是对维度进行预处理,将多个维度集合到一个事实表,形成一个宽表。
首先就是星座不星座这个只跟数据和需求有关系,跟设计没关系,不用选择。
星型还是雪花,取决于性能优先,还是灵活更优先目前实际企业开发中,不会绝对选择一种,根据情况灵活组合,甚至并存 (一层维度和多层维度都保存) 。但是整体来看,更倾向于维度更少的星型模型。尤其是Hadoop体系,减少Join就是减少Shuffle,性能差距很大(关系型数据可以依靠强大的主键索引)
选择业务过程→声明粒度→确认维度→确认事实
在业务系统中,挑选我们感兴趣的业务线,比如下单业务,支付业务,退款业务,物流业务,一条业务线对应一张事实表。
数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。
声明粒度意味着精确定义事实表中的一行数据表示什么,应该尽可能选择最小粒度,以此来应各种各样的需求。
如果在DWD层粒度就是每周或者每月,那么后续就没有办法统计细粒度的指标了。所以建议采用最小粒度。
维度的主要作用是描述业务是事实,主要表示的是“谁,何处,何时”等信息。
确定维度的原则是:后续需求中是否要分析相关维度的指标。例如,需要统计,什么时间下的订单多,哪个地区下的订单多,哪个用户下的订单多。需要确定的维度就包括:时间维度、地区维度、用户维度。
维度表:需要根据维度建模中的星型模型原则进行维度退化。
此处的“事实”一词,指的是业务中的度量值(次数、个数、件数、金额,可以进行累加),例如订单金额、下单次数等。
在DWD层,以业务过程为建模驱动,基于每个具体业务过程的特点,构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。
关系模型如图所示,严格遵循第三范式(3NF),从图中可以看出,较为松散、零碎,物理表数量多,而数据冗余程度低。由于数据分布于众多的表中,这些数据可以更为灵活地被应用,功能性较强。关系模型主要应用与OLTP系统中,为了保证数据的一致性以及避免冗余,所以大部分业务系统的表都是遵循第三范式的。
关系建模要从整体进行考虑,也就是说要对业务有全面的了解和把控,要对上游业务系统的进行信息调研,以做到对其业务和数据的基本了解,要做到主题划分,让模型有清晰合理的实体关系体系,以下是方法的示意:
以下是中国移动的概念模型的一种示例,如果没有自顶向下的视野,基本是总结不出来的:
一般来讲,维度模型简单直观,适合业务模式快速变化的行业,关系模型实现复杂,适合业务模式比较成熟的行业,在现在业务快速的发展变化,关系建模来不及快速的响应和改变。
运营商以前都是关系建模,现在其实边界越来越模糊,很多大数据业务变化很快,采用维度建模也比较方便,不需要顶层设计。
维度建模就不说了,只要能理解业务过程和其中涉及的相关数据、维度就可以,但自顶向下的关系建模难度很大,以下是关系建模的三个建设要点。
免责申明:
本文系转载,版权归原作者所有,如若侵权请联系我们进行删除!
《数据治理行业实践白皮书》下载地址:https://fs80.cn/4w2atu
《数栈V6.0产品白皮书》下载地址:https://fs80.cn/cw0iw1
想了解或咨询更多有关袋鼠云大数据产品、行业解决方案、客户案例的朋友,浏览袋鼠云官网:https://www.dtstack.com/?src=bbs
同时,欢迎对大数据开源项目有兴趣的同学加入「袋鼠云开源框架钉钉技术群」,交流最新开源技术信息,群号码:30537511,项目地址:https://github.com/DTStack