我们要明白,对于数据仓库的设计是不能完全依赖于业务的需求,但往往又必须要服务于业务的价值。
因此,在构建数据仓库前,我们往往会通过总线矩阵设计,来快速理解业务并规划数据仓库体系。以求从宏观的角度来描述企业的业务和数据现状,并指导后续的数据仓库建模。
不妨先来看看,祖师爷 Kimball 在书中对总线矩阵的定义:
总线矩阵**:**提供一种分解企业DW/BI规划任务的合理方式,行是业务过程,列是公共维度(一致性维度),图表中的 X 表示的是哪些列与哪些行有关系,也表示这一个业务过程需要有哪些公共维度。
所以,总线矩阵和一致性维度、一致性事实共同组成了 Kimball 的多维体系结构基础。
在这种多维体系结构(MD) 的数据仓库架构中,主导的思想便是分步建立数据仓库,并由数据集市组合成企业的数据仓库。
但是,在建立第一个数据集市前,架构师首先要做的就是设计出在整个企业内具有统一解释的标准化的维度和事实,即一致性维度和一致性事实,而开发团队必须严格的按照这个体系结构来进行数据集市的迭代开发。
如果我们在建立数据仓库之初,只考虑单独的某个业务系统的数据建设,不仅无法满足一致性目标的。还会使相互有联系的系统数据由于维度不同导致关联复杂或者关联不上,数据之间互相成为了孤岛,这对于后期的扩展或者整个数仓的建设都是巨大的阻碍。
一致性维度就好比企业范围内的一组总线,不同数据集市的事实的就好比插在这组总线上的元件。
这也是称之为总线架构的原因。因此实际设计过程中,我们通常把总线架构列表成矩阵的形式,其中列为一致性维度,行为不同的业务处理过程,即事实,在交叉点上打上标记表示该业务处理过程与该维度相关,这个矩阵也称为总线矩阵(Bus Matrix)。
了解总线矩阵设计的必要性,它的作用就很容易理解了。简单来讲无非是以下三点:
- 帮助数据架构师清晰地梳理整个数据体系
- 帮助决策者(Boss)从宏观的角度了解数据仓库的整体情况
- 让所有的数据仓库参与者了解数据仓库的设计
如何编写总线矩阵?
首先,总线矩阵不是代码,也不是纯文档性质。在构建总线矩阵对过程中,也需要完成许多代码开发前期的准备工作。
首先完成横向,即 数据域划分,业务过程的确立。数据域是一种对数据的抽象,通过将联系较为紧密的数据划分在同一数据主题中,方便寻找和使用数据。
比如,制造业中,我们可以将数仓划分为:生产、财务、人力、供应链、交付等数据域,每个域下包含不同的业务过程。如生产域下包括生产计划、实际生产、设备停机等业务。
通常是先确定业务过程有哪些,再按照某个规则将相关的业务划分为同一数据域中,常用的规则有:按业务相关性、按需求方、按应用划分等。也可以将数据域划分为多级主题,比如先按照部门划分一级主题,再按业务划分二级主题。
**数据域的划分没有对错,根据实际情况进行划分,让数据归纳更清晰,更好找易用就是好的数据域划分。**划分数据域时,可参考这些规则:数量不能太多,建议不超过10个;不同主题间无重叠业务过程;具有一定前瞻性,既能涵盖当前所有的业务需求,又能在新业务进入时无影响地被包含进已有的数据域中或扩展新的数据域。
其次完成纵向列,即公共一致性维度的划分以及度量值的确定。**维度是我们看世界的角度,度量则是形容指标的水平,他们都是指标的重要组成。**比如有个指标:“四月交付2000辆车”,“四月”和“车”是维度,“2000”是度量值,“辆”则是度量单位,维度和度量组合在一起形成月度指标。如果没有维度,“交付2000辆”则啥也代表不了。
维度的划分具有行业共同性,比如电商行业通常涉及这些维度:买家、卖家、订单、广告、货运、支付等,制造业中:设备、产线、项目、物料、车型等,还有一些跨行业通用的维度,如城市、日期等。维度的一致性是数据一致性的重中之重,总线矩阵是一致性维度建设的重要文件。从讨论总线矩阵的那刻开始,数仓数据一致性问题就解决了一半。
总线矩阵中的度量通常是原子指标,指业务过程中最基本的原子指标。比如生成计划业务过程中,度量是“件数”,设备停机事件中,度量为“停机时长”。总线矩阵中描述的度量,能够给分析人员直观的了解目前数据具备的分析能力。
最后是确定业务过程同维度间的关联关系。应该分析每个业务过程,尽可能多的关联维度与业务过程,而不仅仅是当前分析需要哪些维度,否则就陷入了面向需求开发的陷阱。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上大数据知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
并且后续会持续更新**