数仓维度建模

维度建模概念

​维度建模是建设数仓模型的一个方法论，与之相对的还有一个范式建模，二者不同的是，维度建模是自下而上的建模方法，也即基于业务需求建模，这种建模方法的优势就是，建模速度快，开发周期短，且无需耗费大量人力，一个健康的维度建模的数仓也是有很强的拓展性的；而范式建模是一种自上而下的建模方法，基于源数据的ER模型来建模，这种建模方法的优势是，维护起来比较简单，数据冗余较少，且是从整个企业角度建模的一种方法，一般来说维度建模适用于大部分中小型互联网公司。ps:这里的自上而下和自下而上是指的数据的流向，数据下游到数据上游

​本文描述的是基于kimball大神的星型模型的维度建模方法，

维度建模设计

​对于企业的数仓建模而言，维度模型首先需要明确维度总线，理论情况维度模型下的所有维度表都是基于维度总线延申下来的，而所有的事实表都是与其同一业务过程下的维度表相关联的；所以，为了后续的建模不会脱离实际情况，开发成只应用于一个部门的数据集市，我们需要明确企业的维度总线，后续开发全需要与总线相关联。

维度建模开发

​当我们明确了企业的维度总线，我们就可以对一些基础业务开发模型了，每到新的业务需求产生的时候，我们就可以根据下面的开发流程来进行维度建模。

1. 确定业务过程
   基于需求确定业务过程
   确定业务过程是维度建模最基本的，所以确定一个业务过程就显得至关重要；业务过程一般是一个行为动词，例如业务过程是：调研商品

2. 声明事实粒度
   解决事实表每行存储的是什么内容
   如果确定了业务过程，那么就需要声明事实粒度了，比如：调研事实表中每个商品每天在各集市的售价用一行表示。

3. 确定业务维度
   维度就是对输出度量的描述，一般是“谁、何时、何处、为何、如何、什么”这一类词汇，比如：调研人员，调研时间，调研地点，调研商品

4. 确定事实度量
   过程的度量，就是一个事实的度量，比如：商品售价

​明确上面四个步骤，我们就完成了一个业务过程一半的维度建模了，为什么说才一半呢？因为维度建模是自下而上的，而连接这个自下而上的数据的下是业务需求，上是业务过程的一系列的业务表。

​基于上面的图片我们其实可以再有一套实践的方法论，每次维度建模的时候，画出业务过程对应的业务表的流程图，以及对应的数仓模型图，二者可以分开，也可以整合在一起。（数仓维度建模规范）

​维度建模核心是维度总线，而每一个业务需求的开发就是维度建模的过程，整个都和业务密不可分，也与业务数据息息相关。而对于我们开发的事实表，维度表以及维度总线应该如何存放，如何命名就是数仓建设的下一步了——数仓分层