论道数据仓库维度建模和关系建模

作者：傅一平 就职于浙江移动大数据中心
来源：与数据同行


为什么要数据仓库建模呢？
如果把数据看作图书馆里的书，我们希望看到它们在书架上分门别类地放置；如果把数据看作城市的建筑，我们希望城市规划布局合理；如果把数据看作电脑文件和文件夹，我们希望按照自己的习惯有很好的文件夹组织方式，而不是糟糕混乱的桌面，经常为找一个文件而不知所措。
数据模型就是数据组织和存储方法，它强调从业务、数据存取和使用角度合理存储数据。Linux的创始人Torvalds有一段关于“什么才是优秀程序员”的话：“烂程序员关心的是代码，好程序员关心的是数据结构和它们之间的关系”，最能够说明数据模型的重要性。只有数据模型将数据有序的组织和存储起来之后，大数据才能得到高性能、低成本、高效率、高质量的使用，一般可以从四个方面概括数据仓库模型的价值：
性能：良好的数据模型能帮助我们快速查询所需要的数据，减少数据的I/O吞吐，提高使用数据的效。
成本：良好的数据模型能极大地减少不必要的数据冗余，也能实现计算结果复用，极大地降低存储和计算成本。
效率：良好的数据模型在业务或系统发生变化时，可以保持稳定或很容易地实现扩展，提高数据稳定性和连续性
质量：良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性。
那么，数据仓库一般为什么要分层设计呢？
以下是一个示例：
分层设计的好处大致可以概括如下：
清晰数据结构：每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。
数据血缘追踪：能够快速准确地定位到问题，并清楚它的危害范围。
减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。
把复杂问题简单化：将复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。当数据出现问题之后，不用修复所有的数据，只需要从有问题的步骤开始修复
屏蔽原始数据的异常：不必改一次业务就需要重新接入数据。
知道了数据仓库的好处，很多行业和企业也都经历了数据仓库建模，但如果问哪家数据模型建得好，各行业各企业就很难分出个高下了。
但这个问题又很重要，因为有标杆认识到差距才能进步，有伙伴邀笔者去讲讲数据建模，说实话，笔者也不知道怎么讲，因为这个跟企业自己的业务和数据太相关了，所谓的业界的标准建模理论和方法也变得无足轻重。
大神Inmon的《数据仓库》和kimball《数据仓库工具箱》算是两个经典吧，最近出了本很厚的《数据仓库与商业智能宝典》，但也是人家kimball以前经典文章的合集。
关系建模又叫ER建模，是数据仓库之父Inmon推崇的，其从全企业的高度设计一个3NF模型的方法，用实体加关系描述的数据模型描述企业业务架构，在范式理论上符合3NF，其是站在企业角度进行面向主题的抽象，而不是针对某个具体业务流程的，它更多是面向数据的整合和一致性治理，正如Inmon所希望达到的“single version of the truth”。

维度模型则是数据仓库领域另一位大师Ralph Kimball 所倡导的。维度建模以分析决策的需求为出发点构建模型，一般有较好的大规模复杂查询的响应性能，更直接面向业务，典型的代表是我们比较熟知的星形模型，以及在一些特殊场景下适用的雪花模型。

Inmon的ER建模优点体现在规范性较好，冗余小，数据集成和数据一致性方面得到重视，适用于较为大型的企业级、战略级的规划，但缺点是需要全面了解企业业务、数据和关系，对于建模人员要求很高，实施周期非常长，成本昂贵，笔者刚进公司的时候就经历了中国移动的的ER数据仓库项目，的确不是一个新人能短时消化的。
Kimball的维度建模相对能快速上手，快速交付，但缺点是冗余会较多，灵活性比较差，但其实现在看来也没什么，淘宝在大数据之路书中也提到“淘宝数据平台变迁的过程正好解释了二者的不同，最初，淘宝业务单一、系统简单，主要是简单的报表系统；后期数据量越来越大，系统越来越多，尝试用ER建模的数据仓库，但是在实践中发现快速变化的业务之下，构建ER模型的风险和难度都很高，现在则主要采用基于维度建模的模型方法了。”
但Inmon和kimball关于关系建模和维度建模的争论其实也没什么值得探讨的，没有谁更好，在企业内，这两种建模方式往往同时存在，底层用关系建模合适一点，技术的优雅换来了数据的精简，往上维度建模更合适一些，靠数据的冗余带来了可用性，优势互补，都说关系建模不易，概念模型是个坎，其实维度建模也不易，维度的梳理和运营是艰巨的，否则就是烂摊子的活。
在数据建模上，很多人纠结于如何建模，用关系建模、维度建模亦或其它？回过头来也是浮云，其实刚起步的时候没有那么多的循规蹈矩，满足报表和取数的需求即可，尽量做到“高内聚，松耦合”，这是服务的原则，放到数据建模照样适用。
很多企业花了巨大的代价建设了一套数据模型，周期长达1-2年，几年后却推倒重来，问题的根子不在于当初的项目完成的情况如何，包括建模方式是否合理，而在于项目完成了成鸟兽散，缺乏持续的运营。
想想企业的数据仓库模型，有多大的比例在日常的运营中进行了改进呢，有10%吗？阿里在建设数据中台，很大的挑战在于日常运营中对于中台业务的把控能力和持续改进的勇气，数据模型要成为使能者，不是简单的满足需求，也不是为了博得业务人员一时的满意，而是要立足于长远，始终主动、自发和持续的自我进化。
前段时间团队成员说为了满足数据挖掘需求要做一张超级宽表，很能说明问题，任何一个企业的数据模型都会碰到类似的挑战，但这也是混乱的开始，以下是经典的对话：
A：“现在数据挖掘变量准备太慢了，要搞一张大宽表，我们已经梳理了，需要从几十张表中取出字段，这个是这些表的清单？”
B：“跨度这么大，这么多字段，从DWD到DWI，再到DWA，有想过更好的办法吗？”
A：“这个？我们看了，融合模型缺这缺那的，还是再做一张吧，只是为这类数据做的！”
B：“你这张宽表下次会碰到融合模型同样的问题，融合模型是当前平衡做的相对好的，能否去增强融合模型，按字段归属到各融合模型，而不要另起条线，资源也有限的，让这些表的融合模型负责人过来讨论下？”
数据仓库模型的持续提升始终来自于日常朴实无华的需求驱动，数据中台蕴含着企业数据文化的再造，涉及到一系列机制流程的完善，认识到这点很重要。