💎一站式轻松地调用各大LLM模型接口,支持GPT4、智谱、星火、月之暗面及文生图 广告
# 0x00 前言 前一篇已经对常用的几种数据模型做了简单的介绍,本篇主要对其中最常用的维度建模做一个深入的理解。 <!-- more --> # 0x01 什么是维度建模 维度模型是数据仓库领域另一位大师 Ralph Kimball 所倡导,他的《The DataWarehouse Toolkit-The Complete Guide to Dimensona Modeling,中文名《数据仓库工具箱》,是数据仓库工程领域最流行的数仓建模经典。 *按照书中所讲,维度建模并不要求维度模型必须满足第3范式。数据库中强调的 3NF 主要是为了消除冗余。规范化的 3NF 将数据划分为多个不同的实体,每个实体构成一个关系表。比如说订单数据库,开始可能是每个订单中的一行表示一条记录,到后来为了满足 3NF会变成蜘蛛网状图,也许会包含上百个规范化表。而且对于 BI 查询来讲,规范化模型太复杂,用户会难以理解和记录这些模型的使用。 而维度建模解决了模式过分复杂的问题。* 我们换一种方式来解释什么是维度建模。学过数据库的童鞋应该都知道星型模型,星型模型在数据仓库的设计中可以为是一种典型的维度模型。我们在进行维度建模的时候会建一张事实表,这个事实表就是星型模型的中心,然后会有一堆维度表,这些维度表就是向外发散的星星。那么什么是事实表、什么又是维度表吗,下面会专门来解释。 # 0x02 基本概念 维度建模中有一些比较重要的概念,理解了这些概念,基本也就理解了什么是维度建模。 为了便于理解,我们先假设一个业务场景:聊天! 比如短信聊天、软件聊天这些聊天场景。 下图是在聊天场景中我们设计的一个简单的星型模型,里面有三个最常用到的概念:事实表、维度表和度量值。 ![](http://pic.mdjs.info/post/No12_1.png/post) **1. 事实表** > 发生在现实世界中的操作型事件,其所产生的可度量数值,存储在事实表中。从最低的粒度级别来看,事实表行对应一个度量事件,反之亦然。 额,看了这一句,其实是不太容易理解到底什么是事实表的。书中就是这么写的,刚入门的时候看的时候一脸懵逼。 **回到前面的图,最中间那个chat表就是一个事实表,你可以理解他就是在现实中发生的一次操作型事件,我们每次给一个小伙伴发一条信息,就相当于是一个事实,它在表中的体现就是一条记录。** 我们可以回过头再看一下事实表的特征,在维度表里没有存放实际的内容,他是一堆主键的集合,这些ID分别能对应到维度表中的一条记录。 **2. 维度表** > 每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键,当然,维度表行的描述环境应与事实表行完全对应。 维度表通常比较宽,是扁平型非规范表,包含大量的低粒度的文本属性。 我们的图中的围绕在chat表周围的四张表都属于维度表,这些表都有一个唯一的主键,然后在表中存放了详细的数据信息。 **3. 度量值** 度量值是什么?看一下chat表中最后一个字段:内容长度(content_length),它表示我们在短信中的发了多少个字。 度量值是对一次行为的度量,可以是一次短信的文本长度、一次电话的通话时间、一个订单的订单金额。 # 0x03 实践 下面我们将以聊天场景为例,详细讲一下维度建模的建模方式,并举例如果使用这个模型(这点还是很重要的)。 ## 一、业务场景 假设我们在一家通信性质的公司工作,公司需要对业务进行建模,我们首先限定业务场景为聊天,这种场景会有下面几个要素: 1. 一次聊天行为的发起需要有这几个个体的参与:发送消息者、接受消息者、时间、ip、设备。 2. 一个用户可以给多个用户发消息,可以不同时间发很多条。 好,基于这两点,我们来设计我们的模型。 ## 二、模型设计 首先,我想一下如果不按照什么维度建模来设计,我们可以怎么做? 如果是我,我会设计下面这张表。你信不信,我能列出来50个字段! ![](http://pic.mdjs.info/post/No12_2.png/post) 如果按照维度建模的方式来设计的话,我们会得到这张表,也就是前面贴出来的。 ![](http://pic.mdjs.info/post/No12_3.png/post) 其实我个人认为怎么设计这种表都有其合理性,我们不论对错,单说一下两者的优缺点。 先说我们的维度模型: 1. 数据冗余小(因为很多具体的信息都存在相应的维度表中了,比如用户信息就只有一份) 2. 结构清晰(表结构一目了然) 3. 便于做OLAP分析(数据分析用起来会很开心) 4. 增加使用成本,比如查询时要关联多张表 5. 数据不一致,比如用户发起购买行为的时候的数据,和我们维度表里面存放的数据不一致 再说我们这张大款表的优缺点: 1. 业务直观,在做业务的时候,这种表特别方便,直接能对到业务中。 2. 使用方便,写sql的时候很方便。 3. 数据冗余巨大,真的很大,在几亿的用户规模下,他的订单行为会很恐怖 4. 粒度僵硬,什么都写死了,这张表的可复用性太低。 ## 三、使用示例 数据模型的建立必须要为更好的应用来服务,下面我先举一个例子,来切实地感受一下来怎么用我们的模型。 **需求**:求出2017年在广东省每个市的男性分别给女性发过多少字。 **实现**: ![](http://pic.mdjs.info/post/No12_4.png/post) 实现是不是很简单?然后还有各种上钻和下探的操作都可以基于这几张表来实现。 ## 0xFF 总结 维度建模是一种十分优秀的建模方式,他有很多的优点,但是我们在实际工作中也很难完全按照它的方式来实现,都会有所取舍,比如说为了业务我们还是会需要一些宽表,有时候还会有很多的数据冗余。 维度模型在很多开源的系统都中都有支持,比如Kylin,在建模的时候就是用的维度建模中的星型模型,当然在最新版本中也支持了雪花模型。