建仓时，如何评估数据模型建的好不好？

编辑：彭文华

来源：大数据架构师

彭友们好，我是老彭。最近有个彭友在建数仓，他问：建仓的时候，怎么判断数据模型建的好不好？

这个问题不太好回答，因为容易引发争论。原因很简单，因为流派众多。脉脉上有好多帖子，都在抨击数仓建模。之前我写过好几篇，感兴趣的可以在文末点开看。

不过终究是要有一个评价标准的，我们今天就来讨论讨论这个问题。

建模的流派

嗯，这里不是要说immon和kimball的流派，因为他俩的建模思想是一致的，都是维度建模。

一般来说，建模有几大类：

1、关系模型（范式建模）

2、维度建模（星型、雪花型）

3、宽表建模（世上本无宽表，互联网搞得多了，也就有了宽表模型）

关系模型一般在业务系统用的比较多，维度建模在数仓里用的比较多。这个不绝对。

但是现在很多互联网公司因为业务变化太快，导致常规的维度建模不适用了，实在是没办法，只能拖宽表应对产品经理疯狂的催促。

你看，这三种流派，各自成体系，可不能用统一的方法来评价。比如宽表，拿啥标准都不行啊~~~都挤成一张饼了。

拿维度建模的标准去评判关系模型，也不行啊，它们各有各的目的，要不整两个流派干啥？

而且，在主题域模型、概念模型、逻辑模型不同层面，其评判标准也不一样。

所以不好说啊。

模型的好坏

怎么才能算是一个好模型？

这得说到数仓建设的核心奥义：解耦。数仓分层也是因为要解耦。以前的数据处理逻辑都写在一起，一个巨大无比的存储过程。

相互之间还不断调用，加上数据的复杂程度，简直难以理解。看懂一个存储过程都要消耗几百亿个脑细胞。

所以，稍微有些架构思维的人都会把程序不断的拆解，不仅在数据领域是这样，在整个软件工程都是这样。高内聚，低耦合。

在模型这边更是这样。一个优秀的模型，应该具有以下特性：

1、稳定性：其实就是低耦合设计带来的特性。一个优秀的模型应该能够支撑上层不断更新的业务需求。

2、可复用：避免与业务绑定过死，导致模型的个性化。比如宽表，可复用性极差。不过这也不绝对，在业务频繁变化的场景，只能选宽表。

3、业务支持：数据是业务的投影。数据模型是业务的成像原理。因此建模时必须与业务贴合。这一条看上去与上一条冲突，其实不然。区别在于支持和完全一致。如同照片和影子的区别：影子可以随着地形的变化而变化，而照片与实体保持高度一致。

4、通用性：一个优秀的模型应该是合理抽象的，因此能够在不同企业的类似场景中通用。比如FSLDM，一个模型吃了几十年了（虽然有更新）。

5、友好：一个优秀的模型应该对数据建模师友好。如果在业内人员眼里都很怪异，那么肯定不能算是好模型。

6、干净：一个优秀的建模师干的活儿如同陕西媳妇揉面一样，三光：手光、面光、盆光。标准统一、规规矩矩，干干净净、一板一眼，顾名思义、不用瞎猜。一个字：合理。

评价

这个评估模型还是很粗糙的，其实可以再细化一些，弄给一个评分表，各自对自己的模型进行打分。

比如最后一个干净，就是卷面分，稳定、复用就是技术分啥的。最好是让别人给自己的打分，然后就知道自己的模型建的咋样了。

好了，今天就分享到这里，明天再见。