数据仓库系列哲学建模的艺术:如何完成数仓的维度建模设计??--做好宏观角度考虑维度一致性

Posted N个程序猿的日常

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了数据仓库系列哲学建模的艺术:如何完成数仓的维度建模设计??--做好宏观角度考虑维度一致性相关的知识,希望对你有一定的参考价值。

「写在前面:」 我是「nicedays」,一枚喜爱「做特效,听音乐,分享技术」的大数据开发猿。这名字是来自「world order」乐队的一首HAVE A NICE DAY。如今,走到现在很多坎坷和不顺,如今终于明白「nice day」是需要自己赋予的。「白驹过隙,时光荏苒,珍惜当下」~~ 写博客一方面是对自己学习的一点点总结及记录,另一方面则是希望能够帮助更多对大数据感兴趣的朋友。如果你也对 大数据与机器学习感兴趣,可以关注我的「动态」 https://blog.csdn.net/qq_35050438,让我们一起挖掘数据与人工智能的价值~

阿里大数据之路笔记


  • 数据仓库--维度建模中的维度设计:

    • 一:什么是维度?

    • 二:如何去凭空设计维度?

    • 三:如何判断:是维度?还是维度属性?

    • 四:一致性维度和交叉探查:


数据仓库--维度建模中的维度设计:

一:什么是维度?

维度是描述事实的一种角度

在维度建模中我们将度量作为事实,将环境描述为维度。

刚刚入职如何获取维度与维度属性?

通常我们再未预先设计的情况下,可以在报表中获取,也可以在业务人员交谈中获取,往往语句中的group by的查询中,会得知用户想要观察的维度。

二:如何去凭空设计维度?

维度设计的过程就是「确定维度属性」的过程

数据仓库能力与维度属性的质量与深度成正比

第一步:选择维度

其实我之前一直觉着应该先确定事实,再确定维度,但是工作中,往往客户给你的话术里,最先能确定的都是维度属性,如:我想从月份和产品中查看销售情况。

  • 保证维度的唯一性

第二步:确定主维表

一个维度往往里面会有多表来表示,这就牵扯到星型与雪花模型

  • 确定的主维表一般是ODS表,直接与业务系统同步:

    例如:淘宝商品维度对应商品表就是主维表。

第三步:确定相关维表

主维表也会因为不用业务之间直接或间接有相关关联,所以确定主维表之后仍需要哪些是主维表的相关为表。

  • 例如:商品表与店铺表类目表卖家表等等表或者也有可能是其他维度的主维表存在关联。

第四步:确定维度属性

维度属性需要自己通过经验判断,如商品的属性商品标题,商品内容,商品来源等等。

  1. 从主维表中选择维度属性或生成新的维度属性
  2. 从相关维表中选择维度属性或生成新的维度属性。
数值型维度属性与事实的区别:
  • 如果用于查询的约束条件或分组统计,那它就作为维度属性。
  • 如果用于参与度量的计算,那它就作为事实。

最典型的商品价格:

如果我们统计的是商品价格区间的商品数量--作为维度属性

如果我们统计的是商品的平均价格--作为事实

tips:离散的作为维度属性可能性较大,连续的作为事实度量可能性较大

尽量沉淀通用的维度属性:

例如商品在线是维度属性,但是它是无法像价格一样直接获取的维度属性,可能在web开发人员那边的逻辑往往是需要通过复杂的判断才能得出商品是否存在,例如,要通过商品状态和上架时间等来判断,此时应该封装逻辑,只暴露出商品在线这个通用维度属性。

三:如何判断:是维度?还是维度属性?

我们举个简单的例子:

我们从宏观的概念将商品表作为维度,

与商品相对应得「行业,类别,品牌」 这些名词既可以作为与商品平等得一种维度,也可以作为商品得子类--一种维度属性,

其实「维表设计得精髓得」就在于此:这里得可控范围很大,完全取决于你对业务得理解是否深刻,一整个架构,上下游得需求是否了解,你对开发,运维等等因为你的不同建表方式产生不同具体实操得优劣是否清楚

当维度属性作为维度:

我们称这种建表方式是规范化建表,可以避免数据冗余,让人理得清逻辑,这种建模方式称为雪花模型建模。

唯一的对于OLAP的好处来看:

  • 逻辑清晰,节省一部分存储

当维度属性合并到单个维度:

我们称这种建表方式是反规范化建表,对于大数据量得查询,多表关联得操作使查询性能很低,反规范化简化查询优化速度,这种建模方式称为星型模型建模。

  • 简化查询性能,复杂度降低,信息不丢失

目前对于OLAP系统来说,存「储成本非常低」,处于易用性和性能的考虑,通常采用「星型建模的方式」。下面简单介绍一下两种建模

星型模型:

星型模型特点
  • 由事实表和维度表组成

  • 一个星型模式中可以有一个或多个事实表,每个事实表引用任意数量的维度表

  • 星型模式将业务流程分为事实和维度

    • 如日期、产品、客户、地理位置等是维度
    • 如销售价格、销售数量、距离、速度、重量等是事实
    • 事实包含业务的度量,是定量的数据
    • 维度是对事实数据属性的描述
在这里插入图片描述

雪花模型:

雪花模型特点
  • 一种多维模型中表的逻辑布局
  • 「事实表」和 「维度表」所组成
  • 将星型模式中的维度表进行规范化处理
  • 把低基数的属性从维度表中移除并形成单独的表
  • 一个维度被规范化成多个关联的表
在这里插入图片描述

四:一致性维度和交叉探查:

不同数据域中会可能会有相同的维度,我们对不同数据域的维度合并探查(交叉探查),由于存在重复相同的维度,但维度属性值或维度属性不同,会导致交叉探查结果错误,我们要保证维度在不同域的一致性

哪些情况可以称为维度一致性?

  • 共享维表--两个域里有一模一样的维表

    公共维度建立后共享,在数据仓库中有且只有一个

  • 一致性上卷--两个域的两个维表是包含关系

    当一个维度「的维度属性是另一个维度的维度属性的子集」,且两个维度的「公共维度属性结构和内容相同」

    例如类目维度属性是商品维度的维度属性的子集(商品里记录了类目维度属性),且不仅这个子集的维度属性结构与值也都相同,维度表现为一致性

  • 交叉属性--两个域的两个维表有部分相同的维度属性

    两个维度有部分相同的维度属性

    例如商品维度有类目维度属性,卖家维度也有一个主营类目维度属性,具有部分相同。

由于不同数据域有可能是属于不同业务,不同的开发团队去开发,我们要明确构建企业范围内的维度一致性和事实来构建总线架构。采用迭代式的构建过程。


以上是关于数据仓库系列哲学建模的艺术:如何完成数仓的维度建模设计??--做好宏观角度考虑维度一致性的主要内容,如果未能解决你的问题,请参考以下文章

如何搭建一个数据仓库

热文:如何搭建一个数据仓库

如何深入浅出的理解数据仓库建模?

数据仓库数仓建模之星型模型与维度建模

老司机带带我:数仓建模架构|维度建模剖析与案例演示

老司机带带我:数仓建模架构|维度建模剖析与案例演示