数据平台维度模型设计十个技巧

注：这是一篇讲述维度数据模型设计的文章，偏向于数据平台而非数据分析，请读者根据自己的兴趣爱好阅读，内容有不妥的地方请联系我（松子）。

了解过数据仓库历史的人都知道Bill Inmon、 Ralph Kimball。 Bill Inmon 代表作《Building the Data WareHouse》 ， Ralph Kimball代表作为 《The DataWarehouse Toolkit》、《The data Warehouse lifecycle》。两位大师对数据模型都分别作了深入阐述，个人理解的数据模型是数据平台的灵魂。数据模型设计好了对数据应用、数据分析支持是非常有帮助的。尤其 kimball 提出的维度模型 ，围绕业务模型能够直观的表达业务数据关系。

关于数据模型概念不多讲，本文与大家分享多维数据模型设计的十个技巧。

技巧一：维度表中应该包含最细的颗粒度。

通常在数据平台做开发的同学，“特麽”经常抱怨 “ 需求怎么又变了，这个需求能不能不要来回的改“，数据建设中会遇到非常不确定性需求，不可预测筛选与汇总。

尤其是在互联网做数据化运营，绝大部分需求几个汇总类指标是无法满足需求，很多时候会沉浸到比较明细、更深层次的细节信息。当然汇总指标是能够概括一些概述数据细节，但只有细节数据才能回答各种不停的业务上数据追问。

技巧二： 围绕业务流程来构建维度。

数据是真实的反应业务活动与成果的，业务流程在不同的阶段所产生数据项也是不一样的。比如说一个用户从寻找App、下载、安装、启动、再启动这个流程，用户在淘宝购物、寻找浏览物品、放入购物车、跳转收银台、支付、完成。

这两个流程背后代表某个业务事件活动，在不同的环节产生的数据项是不同的，如果将流程不同阶段的指标沉淀下来变为可度量的关键指标，如果将这些关键指标根据关系合并与设计到事实表中，就变为支撑业务人员分析、探索业务的细节数据。

为了能够从业务流程上的多维度来探索数据，所涉及到的很多维度最好是业务流程来做设计，比如上图交易现相关，从订单的来源，所属产品、到支付阶段的资金来源，从业务流程上来看，还可以扩展出更多的维度、与度量值。

在不同的业务环节，业务人员都会“很任性”的需求不同指标，但是在需求中往往是与业务流程有很大关系的。

技巧三：尽量保证每张事实表与时间维度有关联

在原则二中描述那两个案例业务永远是与日期有关系的，不管是月、日、年、还是分、秒，财务年、自定义时间事件段等。

每个事实表至少有一个外键能够与日期维度表相连，时间维度能才能反映出存量与流量，才能分析某一时刻、某一时间段的业务流程变化情况。

技巧四：同一张事实表的指标对应维度层级必须一致

一般的事实表有四种类型，粒度事实、周期性快照事实、聚合快照事实、非事实事实表，不管它们的粒度类型，事实表中的每个度量值在颗粒度上必须保持与维度的颗粒度是一致的，否则就等着崩溃吧。

例如原则二给出的案例，要分析一个用户订单支付业务。如果对这个业务进行设计分析模型时，把产品维度粒度定义为产品，但是在度量值金额却是按照不同产品分类做聚合的，那就有意思了。我暂时也没回忆起类似的场景会在什么情况犯错。

技巧五：处理好事实表和维度表之间的多对多关系

在多个维度表的值可以赋给单个事实事务时，事实表和维度表之间通常是多对多关系，比如为了计算写书的作者分成，一本书可能有多个作者， 一个作者可能出版了多本书，这个案例下就是多对多的关系。要考虑到可以计算出每个作者的的分成，中间可以增加一个桥接表。

综上所述，

在这种情况下多个值的维度与事实表直连可以采用桥接表来处理。

技巧六：经常发生变化的维度处理

在设计维度上很多时候都是扁平化处理，业务中普遍的维度关系是一对一的关系，比如例如客户Simmy将自己的地址由原先的Addr1改为Addr2。这时我们需要将这个记录了客户Simmy的记录中的有效截止日期改为现在，并重新添加一条有效截止日期为现在的和一个新的版本号且Address为Addr2的记录。

但是也经常存在一对多的关系，比如大家的购物邮寄地址、个人电话号码等在现实生活中有变化的处理。这种情况可能存在一对多的关系，假如一张维表存在上百万的维度且汇总信息经常在变化，那得注意做缓慢变化、或快速变化处理了。

技巧七：让维度表使用代理键

英文叫SurrogateKey，翻译过来又叫代理键，在建模中通过一些毫无意义键值来代替一些业务键值，有利于维度统一整合。

技巧八：进行一致性维度的处理

一致性维度，又叫统一维度。对于构建企业级数据平台数据模型具有关键的意义，通过在数据转换处理环节一次性处理后，在构建不同数据集市、不同数据层时可以反复被使用。

统一维度在构建多维模型时，可以很便捷能把多种不同类型业务指标进行关联，让使用用户在不同业务间切换分析、还能减少维护工作。

比如数据描述经常不一致性如，同名异义、同物异名，还有口径多样化、编码不统一、命名不统一等。还能处理一些未知、不知道名字、日期待定等一些含

糊的分类。

而然，在实施统一维度时最大的障碍是需要不同的业务部门、IT部门对每个维度属性上达成一致，那就涉及到数据管理、数据治理的范畴了。比如含义相同但名称不同业务术语等。

技巧九：分析功能标签化标签以及过滤器等信息可以当做维度来保存。

其实这也不是什么原则，个人更倾向于归类到技巧中。比如在构建分析型数据产品时，有些功能性的标签、查询类的代码或分类完全可以维度化。

例如某些下拉菜单中筛选标签以及过滤器阈值等、用户的特定群体探索、产品的相关联分析等，都可以维度化并做预处理。

这样做的好处是速度快，把部分分析结果数据做预处理，查询中需要聚合部分变为过滤查询，这样会提高分析查询效率的。

技巧十：大维度的退化处理

所谓的大维度，是指维度数据量特别大，比如现在互联网的URL维度可能几十万上百万，还有客户，产品等等。一个大的企业客户维度往往有上百万记录，每条记录又有上百个字段。而大的个人客户维度则会超过千万条记录，这些个人客户维度有时也会有十多个字段，但大多数时候比较少见的维度也只有不多的几个属性。

这些维度的处理往往采用把大属性转为小属性、退化处理，增加更多的不同分类字段等特殊处理。