数据仓库基础4-搞懂维度

数据仓库基础4-搞懂维度

引言

数仓系列的文章，写到了第三篇，终于开始聊维度了。

维度，这个词非常常见，但也抽象。在数仓、数分场景里，维度到底是什么？来看看这篇吧。

01 维度是什么

不懂就问，维度是什么？我们学习的自然反应，自然是去查阅专业资料。

1）阿里dataphin产品简介-基本概念是这样介绍维度：

人们观察事物的角度，是指一种视角，是确定事物的多方位、多角度、多层次的条件和概念。

2）华为DGC产品介绍-基本概念如此介绍维度：

维度是用于观察和分析业务数据的视角，支撑对数据汇聚、钻取、切片分析，用于SQL中的Group by条件。多数维度具有层级结构，如：地理维度、时间维度。

3）再看看《数据仓库工具箱》怎么说的：

维度能提供围绕某一业务过程所涉及的 “谁、什么、何处、何时、为什么、如何”等背景。维度表包含BI应用所需要的用于过滤及分类事实的描述性属性。牢牢掌握事实表的粒度，就能够将所有可能存在的维度区分开。当与给定事实表进行关联时，任何情况下都应该使维度保持单一值。

4）再看《阿里巴巴大数据之路》怎么说的：

维度是维度建模的基础和灵魂。在维度建模中，将度量称为 “事实” 将环境描述为 “维度” ，维度是用于分析事实所需要的多样环境。

例如，在分析交易过程时，可以通过买家、卖家、商品和时间等维度描述交易发生的环境。

维度所包含的表示维度的列，称为维度属性。维度属性是查询约束条件、分组和报表标签生成的基本来源，是数据易用性的关键。

维度的作用一般是查询约束、分类汇总以及排序。

不知道你第一次看到这些解释作何感想，我的真实的反应是：对方好好地给我讲人话，为什么我听不懂。

说实在的，这些解释，非常专业，也很硬核，但理解起来是有点困难的，没怎么接触过数据的伙伴估计有点懵。

02 维度怎么来的

维度，到底是什么呢？为什么它叫维度呢？

学习新知识的时候，并不只要看权威的书，任何能给你启发、能帮助你理解的书，都是好书。一本书看不懂，多换几本看看，要是看完还不懂，那就尝试回归本质吧。

让我们先忘掉维度模型，忘掉数据，忘掉维度。

来，一起玩个游戏快问快答游戏：在30秒内说出尽可能多的筷子、勺子的相同点和不同点。

看到这个问题，你会如何描述、对比它们呢？

思考过后，我给你加个条件。问题变成：筷子和勺子在使用方式上的相同点和不同点是什么？

看到新问题，你内心是不是有点方向了，觉得更容易回答了？

这其实是《大象·Thinking in UML》里面一个有意思的互动测试，当时我看到这个问题，脑子非常混乱，一时词穷，相同点和不同点我没说出来多少。一方面平时观察得少，另一方面，抽象训练得也少。

作者说：这个问题没有标准答案，这个问题反映你是否会从抽象的方法去看待事物。在不知不觉中，每一组相同点和不同点都来自于你的一个抽象角度。

例如，当从用途的角度去抽象时，他们的相同点是三者都是餐具，而不同点是筷子用于夹，勺子用来舀；从字面上理解，他们都来带了“子”，还有其他的相同、不同点就不多说了，重点是这句：从不同的抽象角度可以得出非常不同的结果。

作者还说，抽象角度的不同，决定了建模方向的不同。我之前讲过什么是建模吗？描述一个东西，就是在建模。

为什么给出分类后，会更容易回答。因为找到了合适的对比分析的角度，问题就会简单很多。

什么是维度，再看看这句话：维度就是观察事物的角度。维度是抽象的对客观事物的描述。

维度本不存在。是人类观察事物、分析问题、分类归纳得来的，每个人都可以创造自己的维度。

维度一直都存在。只是我们发现了它，用某种方式描述了它。

03 维度和粒度的关系

上一篇文章，讲过粒度，那么这里就要将维度和粒度联系起来学习。

1）维度有层级结构，不同层级对应不同的粒度。

地理维度有不同的层级：国家、省/自治州/直辖市、市、县，时间维度也有不同的层级和粒度：年度、季度、月度、星期、天等。

正如有了要描述的事情，确定了粒度，再去找对应的维度。比如，订单系统，会记录下单的时间信息，时间维度上，粒度会细到秒。学籍系统，学生户籍信息中，要填入地区维度的信息，粒度要细化到省市。

2）维度的组合越多，粒度越细细

客观的世界，是多维的。描述一个客观事物，维度（通常配合相应的度量）越多，粒度越细。

比如一个箱子，我们可以描述其长宽高，还可以描述颜色。不同描述维度组合越多，粒度越细，描述也越细致。

3）随着事物的变化，描述的维度可以增加

一个箱子会经历生产、运输、送货上门等环节，从产地送达到顾客手中。

箱子被生产出来后，没有品牌、产地属性，或者说属性值为空。未经历运输过程的箱子，没有快递公司、配送员属性。

但是人们可以赋予它这些维度，并且填入维度值。维度是基于人类描述客观事物的需要，被创造来的。

4）有的维度，没有直接的数字度量

从客观唯物主义的角度来说，某个实体的存在，长、宽、高这种比较客观的维度属性，是有确定值的。

但某些主观的东西，也是需要被描述的。比如，人的帅气程度。我们就简单分两类：很帅、一般。

这种主观的维度，没有绝对精确的度量值，无法直接和数字划上等号。

但聪明的我们依然可以定性、定量地测算进而描述。比如搞投票，得分超过90为很帅，60-90为一般。

但这种方式，只能估算，没有四海皆准的定值，不同的人群，投票结果不同。

04 两个有意思的维度问题

上面我提到的两本经典书籍里，介绍了非常多维度的问题。这里我只说自己碰到的 2 个我思考很久的问题。

1）维度的角色

维度模型里，很多人不理解什么是维度角色。包括最开始的我自己。

淘宝的业务过程大家应该很熟悉，涉及4个关键步骤：买家下单、买家付款、卖家发货、买家确认收货。

每个过程，都会涉及一个对应的时间，即下单时间、支付时间、发货时间、确认收货时间。

如果只分析其中的一个业务过程，比如买家下单，那只需要一个时间字段即可。

但是分析完整四个过程时，如果还只有一个时间字段，那如何区分其具体含义呢？到底是下单还是支付时间，搞不清楚。

只有一个字段，肯定不够。那必然要有 4 个时间字段。而且我们会给不同的命名，下单、支付、发货、确认收货作为时间的前缀。

这样一来，咱们看的人是能理解各个数字的含义了。但不仅如此，还得让计算机系统也理解。

所以，要弄一个 “维度角色”的字段来标识，以便计算机能理解。

在写SQL脚本的时候，Left join 相同的维度表两次，要给维度表取别名，这样才不会报错。

2）维度和 One data 理论的关系

当我在研究华为的DAYU（现在叫做DGC）产品时，我发现，基于指标生成的SQL，都是 left join 维度表 on 维度表的主键，而且是 group by 维度表的主键。

当时没时间仔细研究，先抄了作业。

后续就碰到不少同事提出疑惑：为什么要如此设计？日期维度表里，还有周、月、年等字段，为什么不能支持按照这些字段进行 group by，一定只能按照维度表的主键的粒度进行汇总？

当我站在数仓层的时候，我无法回答，因为传统数仓，把维度模型建出来就好了。但当我跳到第二层 One data 理论的时候，我仿佛了解了一些（我也不确认自己是否完全懂了）。

我的体会就是：维度表就代表着一种粒度，基于相同统计粒度的指标，才能聚合到同一个表中。

从 SQL 的角度来看，都按照某个维度表主键进行 group by 的指标，能合并到一个表里面，最终能基于维度表的主键，将维度表的非属性字段也冗余到表中。

关于维度，还有很多，缓慢变化维、层次维度、杂项维度等等问题，大家可以自行看经典的书籍或找高人求教~

总结

正如书籍里面所说：维度模型的灵魂，就是维度。

之前看《幕后产品》书中提到陆游的一句诗：汝果欲学诗,功夫在诗外。

学习维度，也是如此。知识不是孤立的，搞清楚维度，要联合粒度、事实等模块去理解，必要的时候，还要结合生活。

本文仅记录自己学习维度模型、实践过程中所踩的坑。如有错误，请各位指教。下一篇，将会分享维度模型中的 “事实”。