![13825820-f87e2d76e9285573.jpg](https://i-blog.csdnimg.cn/blog_migrate/888b739e1ae36bb6c74b19e74e390261.jpeg)
作者 | 傅一平
来源 | 与数据同行
今天跟着我来学学数据仓库的基础知识,希望你结合案例可以把它吃透。
一、数据仓库建模的意义
如果把数据看作图书馆里的书,我们希望看到它们在书架上分门别类地放置;如果把数据看作城市的建筑,我们希望城市规划布局合理;如果把数据看作电脑文件和文件夹,我们希望按照自己的习惯有很好的文件夹组织方式,而不是糟糕混乱的桌面,经常为找一个文件而不知所措。
数据模型就是数据组织和存储方法,它强调从业务、数据存取和使用角度合理存储数据。Linux的创始人Torvalds有一段关于“什么才是优秀程序员”的话:“烂程序员关心的是代码,好程序员关心的是数据结构和它们之间的关系”,最能够说明数据模型的重要性。
只有数据模型将数据有序的组织和存储起来之后,大数据才能得到高性能、低成本、高效率、高质量的使用。
性能:帮助我们快速查询所需要的数据,减少数据的I/O吞吐,提高使用数据的效率,如宽表。
成本:极大地减少不必要的数据冗余,也能实现计算结果复用,极大地降低存储和计算成本。
效率:在业务或系统发生变化时,可以保持稳定或很容易扩展,提高数据稳定性和连续性。
质量:良好的数据模型能改善数据统计口径的不一致性,减少数据计算错误的可能性。数据模型能够促进业务与技术进行有效沟通,形成对主要业务定义和术语的统一认识,具有跨部门、中性的特征,可以表达和涵盖所有的业务。
大数据系统需要数据模型方法来帮助更好地组织和存储数据,以便在性能、成本、效率和质量之间取得最佳平衡!
下图是个示例,通过统一数据模型,屏蔽数据源变化对业务的影响,保证业务的稳定,表述了数据仓库模型的一种价值:
![13825820-801b45e213a5044b.jpg](https://i-blog.csdnimg.cn/blog_migrate/11d902b13d4eabfc9889bc929ea01bf1.jpeg)
二、数据仓库分层的设计
为了实现以上的目的,数据仓库一般要进行分层的设计,其能带来五大好处:
清晰数据结构:每一个数据分层都有它的作用域,这样我们在使用表的时候能更方便地定位和理解。
数据血缘追踪:能够快速准确地定位到问题,并清楚它的危害范围。
减少重复开发:规范数据分层,开发一些通用的中间层数据,能够减少极大的重复计算。
把复杂问题简单化:将复杂的任务分解成多个步骤来完成,每一层只处理单一的步骤,比较简单和容易理解。当数据出现问题之后,不用修复所有的数据,只需要从有问题的步骤开始修复。
屏蔽原始数据的异常:不必改一次业务就需要重新接入数据。
以下是我们的一种分层设计方法,数据缓冲区(ODS)的数据结构与源系统完全一致。基础数据模型(DWD)和融合数据模型(DWI与DWA)是大数据平台重点建设的数据模型。应用层模型由各应用按需自行建设,其中基础数据模型一般采用ER模型,融合数据模型采用维度建模思路。
![13825820-fd64ab067100aa79.jpg](https://i-blog.csdnimg.cn/blog_migrate/aa39e69bd4d61d4ec2541d95481170ae.jpeg)
三、两种经典的数据仓库建模方法
前面的分层设计中你会发现有两种设计方法,关系建模和维度建模,下面分别简单介绍其特点和适用场景。
1、维度建模
(1)定义
维度模型是数据仓库领域另一位大师Ralph Kimball 所倡导的。维度建模以分析决策的需求出发构建模型,构建的数据模型为分析需求服务,因此它重点解决用户如何更快速完成分析需求,同时还有较好的大规模复杂查询的响应性能,更直接面向业务。
典型的代表是我们比较熟知的星形模型:
![13825820-9979017517f28397.jpg](https://i-blog.csdnimg.cn/blog_migrate/592a1525584c21c8ec59eaed5aa12b86.jpeg)
![13825820-2dc73f00ff4a1df7.jpg](https://i-blog.csdnimg.cn/blog_migrate/0e8dafcf85c68db1e67944ce42499a97.jpeg)
<figcaption style="margin-top: 0.66667em; padding: 0px 1em; font-size: 0.9em; line-height: 1.5; text-align: center; color: rgb(153, 153, 153);">维度退化</figcaption>
星型模型由一个事实表和一组维表组成。每个维表都有一个维作为主键,所有这些维的主键组合成事实表的主键。强调的是对维度进行预处理,将多个维度集合到一个事实表,形成一个宽表。
这也是我们在使用hive时,经常会看到一些大宽表的原因,大宽表一般都是事实表,包含了维度关联的主键和一些度量信息,而维度表则是事实表里面维度的具体信息,使用时候一般通过join来组合数据,相对来说对OLAP的分析比较方便。
(2)建模方法
通常需要选择某个业务过程,然后围绕该过程建立模型,其一般采用自底向上的方法,从明确关键业务过程开始,再到明确粒度,再到明确维度,最后明确事实,非常简单易懂。
![13825820-27642e7ac7fdd21e.jpg](https://i-blog.csdnimg.cn/blog_migrate/e002c512d2c356c0daf4c26ae7582289.jpeg)
以下是阿里的OneData的建模工作流,可以参考。
![13825820-4f2090a1b3ff2900.jpg](https://i-blog.csdnimg.cn/blog_migrate/81b10f86d8763de96a3ff68110e21bdd.jpeg)
(3)优缺点
优点:技术要求不高,快速上手,敏捷迭代,快速交付;更快速完成分析需求,较好的大规模复杂查询的响应性能
缺点:维度表的冗余会较多,视野狭窄
2、关系建模
(1)定义
是数据仓库之父Inmon推崇的、从全企业的高度设计一个3NF模型的方法,用实体加关系描述的数据模型描述企业业务架构,在范式理论上符合3NF,站在企业角度面向主题的抽象,而不是针对某个具体业务流程的实体对象关系抽象。
它更多是面向数据的整合和一致性治理,正如Inmon所希望达到的“single version of the truth”。
![13825820-e6185f9f5f818c8b.jpg](https://i-blog.csdnimg.cn/blog_migrate/9eee80850a579ff648be588a2e2f2145.jpeg)
当有一个或多个维表没有直接连接到事实表上,而是通过其他维表连接到事实表上时,其图解就像多个雪花连接在一起,故称雪花模型。
雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化,原有的各维表可能被扩展为小的事实表,形成一些局部的 "层次 " 区域,这些被分解的表都连接到主维度表而不是事实表。
雪花模型更加符合数据库范式,减少数据冗余,但是在分析数据的时候,操作比较复杂,需要join的表比较多所以其性能并不一定比星型模型高。
(2)建模方法
关系建模常常需要全局考虑,要对上游业务系统的进行信息调研,以做到对其业务和数据的基本了解,要做到主题划分,让模型有清晰合理的实体关系体系,以下是方法的示意:
![13825820-19ef8eedb392be61.jpg](https://i-blog.csdnimg.cn/blog_migrate/24df926e16c153c9a558f3bdad3ae487.jpeg)
以下是中国移动的概念模型的一种示例,如果没有自顶向下的视野,基本是总结不出来的:
![13825820-6573390b336b949f.jpg](https://i-blog.csdnimg.cn/blog_migrate/8b98a764e9fd9a33b51f91caf9f30a1a.jpeg)
(3)优缺点
优点:规范性较好,冗余小,数据集成和数据一致性方面得到重视,比如运营商可以参考国际电信运营业务流程规范(ETOM),有所谓的最佳实践。
缺点:需要全面了解企业业务、数据和关系;实施周期非常长,成本昂贵;对建模人员的能力要求也非常高,容易烂尾。
3、建模方法比较
一般来讲,维度模型简单直观,适合业务模式快速变化的行业,关系模型实现复杂,适合业务模式比较成熟的行业,阿里原来用关系建模,现在基本都是维度建模的方式了。
运营商以前都是关系建模,现在其实边界越来越模糊,很多大数据业务变化很快,采用维度建模也比较方便,不需要顶层设计。
![13825820-b333e2de28fc5fe7.jpg](https://i-blog.csdnimg.cn/blog_migrate/cbc4b2b4fc972bf22e4501d2c568a0bd.jpeg)
四、企业建模的三点经验
维度建模就不说了,只要能理解业务过程和其中涉及的相关数据、维度就可以,但自顶向下的关系建模难度很大,以下是关系建模的三个建设要点。
1、业务的理解:找到企业内最理解业务和源系统的人,梳理出现状,比如运营商就要深刻理解三域(O/B/M),概念建模的挑战就很大,现在做到B域的概念建模已经很不容易。
![13825820-abe02938db083119.jpg](https://i-blog.csdnimg.cn/blog_migrate/0ffc57c9004fffea9ae6375276cfee00.jpeg)
2、数据及关系的理解:各个域的系统建设的时候没有统一文档和规范,要梳理出逻辑模型不容易,比如运营商的事件主题下的逻辑模型就非常复杂。
![13825820-00510f89b940a971.jpg](https://i-blog.csdnimg.cn/blog_migrate/ff1f14ef10e420a20a117da5cbefea7d.jpeg)
3、标准化的推进:数据仓库建模的任何实体都需要标准化命名,否则未来的管理成本巨大,也是后续数据有效治理的基础,以下是我们的一个命名规范示例:
![13825820-ec0e20ad85420f0d.jpg](https://i-blog.csdnimg.cn/blog_migrate/c3387615c73bc5bef5b9d42266376bfc.jpeg)
五、推荐三本书
![13825820-8119c78a77c3276a.jpg](https://i-blog.csdnimg.cn/blog_migrate/59412663b9de516cc1880e7485d92a41.jpeg)
总而言之,你可以把我的文章当成一个指引,具体还是要结合企业的实际去推进,但做事的时候要不忘建模的初心:即数据如何摆布才能提高支撑应用的效率,手段上不用区分什么先进不先进,好用就成。
![13825820-3ab1222b45f2cdac.jpg](https://i-blog.csdnimg.cn/blog_migrate/4b310ba3f36a26bd46f199a94ab79cf2.jpeg)
搜索进入我们的小程序,解锁更多新鲜资讯和优质内容,还有很多免费试听课程,不要错过哟!