深入理解数据仓库建模
数据模型就是数据组织和存储方法，它强调从业务、数据存取和使用角度合理存储数据。Linux的创始人Torvalds有一段关于“什么才是优秀程序员”的话：“烂程序员关心的是代码，好程序员关心的是数据结构和它们之间的关系”，最能够说明数据模型的重要性。
只有数据模型将数据有序的组织和存储起来之后，大数据才能得到高性能、低成本、高效率、高质量的使用。
成本：极大地减少不必要的数据冗余，也能实现计算结果复用，极大地降低存储和计算成本。
效率：在业务或系统发生变化时，可以保持稳定或很容易扩展，提高数据稳定性和连续性。
质量：良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性。
数据模型能够促进业务与技术进行有效沟通，形成对主要业务定义和术语的统一认识，具有跨部门、中性的特征，可以表达和涵盖所有的业务。
大数据系统需要数据模型方法来帮助更好地组织和存储数据，以便在性能、成本、效率和质量之间取得最佳平衡！
下图是个示例，通过统一数据模型，屏蔽数据源变化对业务的影响，保证业务的稳定，表述了数据仓库模型的一种价值：
以下是我们的一种分层设计方法，数据缓冲区（ODS）的数据结构与源系统完全一致。基础数据模型(DWD)和融合数据模型（DWI与DWA）是大数据平台重点建设的数据模型。应用层模型由各应用按需自行建设，其中基础数据模型一般采用ER模型，融合数据模型采用维度建模思路。
三、两种经典的数据仓库建模方法
前面的分层设计中你会发现有两种设计方法，关系建模和维度建模，下面分别简单介绍其特点和适用场景。
当今的数据处理方式大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。二者的主要区别对比如下表所示
1、维度建模 （1）定义维度模型是数据仓库领域另一位大师Ralph Kimball 所倡导的。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能，更直接面向业务。
在维度建模的基础上又分为三种模型：星型模型、雪花模型、星座模型。
星座模型与前两种情况的区别是事实表的数量，星座模型是基于多个事实表
基本上是很多数据仓库的常态，因为很多数据仓库都是多个事实表的。所以星座不星座只反映是否有多个事实表，他们之间是否共享一些维度表。所以星座模型并不和前两个模型冲突
星型模型由一个事实表和一组维表组成。每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。强调的是对维度进行预处理，将多个维度集合到一个事实表，形成一个宽表。
首先就是星座不星座这个只跟数据和需求有关系，跟设计没关系，不用选择。
星型还是雪花，取决于性能优先，还是灵活更优先目前实际企业开发中，不会绝对选择一种，根据情况灵活组合，甚至并存 (一层维度和多层维度都保存) 。但是整体来看，更倾向于维度更少的星型模型。尤其是Hadoop体系，减少Join就是减少Shuffle，性能差距很大(关系型数据可以依靠强大的主键索引)
选择业务过程→声明粒度→确认维度→确认事实
（a）选择业务过程在业务系统中，挑选我们感兴趣的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。
如果是中小公司，尽量把所有业务过程都选择。如果是大公司（1000多张表），选择和需求相关的业务线。 （b）声明粒度数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。
声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以此来应各种各样的需求。
典型的粒度声明如下：- 订单当中的每个商品项作为下单事实表中的一行，粒度为每次。
- 每周的订单次数作为一行，粒度为每周。
- 每月的订单次数作为一行，粒度为每月。
-
如果在DWD层粒度就是每周或者每月，那么后续就没有办法统计细粒度的指标了。所以建议采用最小粒度。
维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。
确定维度的原则是：后续需求中是否要分析相关维度的指标。例如，需要统计，什么时间下的订单多，哪个地区下的订单多，哪个用户下的订单多。需要确定的维度就包括：时间维度、地区维度、用户维度。
维度表：需要根据维度建模中的星型模型原则进行维度退化。
（d）确定事实此处的“事实”一词，指的是业务中的度量值（次数、个数、件数、金额，可以进行累加），例如订单金额、下单次数等。
在DWD层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。事实表可做适当的宽表化处理 。
以下是阿里的OneData的建模工作流
（3）优缺点
优点：技术要求不高，快速上手，敏捷迭代，快速交付；更快速完成分析需求，较好的大规模复杂查询的响应性能
缺点：维度表的冗余会较多，视野狭窄
2、关系建模
（1）定义
关系模型如图所示，严格遵循第三范式（3NF），从图中可以看出，较为松散、零碎，物理表数量多，而数据冗余程度低。由于数据分布于众多的表中，这些数据可以更为灵活地被应用，功能性较强。关系模型主要应用与OLTP系统中，为了保证数据的一致性以及避免冗余，所以大部分业务系统的表都是遵循第三范式的。
它更多是面向数据的整合和一致性治理，正如Inmon所希望达到的“single version of the truth”。
关系建模要从整体进行考虑，也就是说要对业务有全面的了解和把控，要对上游业务系统的进行信息调研，以做到对其业务和数据的基本了解，要做到主题划分，让模型有清晰合理的实体关系体系，以下是方法的示意：
以下是中国移动的概念模型的一种示例，如果没有自顶向下的视野，基本是总结不出来的：
（3）优缺点
优点：规范性较好，冗余小，数据集成和数据一致性方面得到重视，比如运营商可以参考国际电信运营业务流程规范（ETOM），有所谓的最佳实践。
缺点：需要全面了解企业业务、数据和关系；实施周期非常长，成本昂贵；对建模人员的能力要求也非常高，容易烂尾。现在一般企业中大部分都是使用维度建模来进行数仓模型的设计。
3、建模方法比较
一般来讲，维度模型简单直观，适合业务模式快速变化的行业，关系模型实现复杂，适合业务模式比较成熟的行业，在现在业务快速的发展变化，关系建模来不及快速的响应和改变。
运营商以前都是关系建模，现在其实边界越来越模糊，很多大数据业务变化很快，采用维度建模也比较方便，不需要顶层设计。
四、企业建模的三点经验
维度建模就不说了，只要能理解业务过程和其中涉及的相关数据、维度就可以，但自顶向下的关系建模难度很大，以下是关系建模的三个建设要点。
1、业务的理解：找到企业内最理解业务和源系统的人，梳理出现状，比如运营商就要深刻理解三域（O/B/M），概念建模的挑战就很大，现在做到B域的概念建模已经很不容易。
2、数据及关系的理解：各个域的系统建设的时候没有统一文档和规范，要梳理出逻辑模型不容易，比如运营商的事件主题下的逻辑模型就非常复杂。
3、标准化的推进：数据仓库建模的任何实体都需要标准化命名，否则未来的管理成本巨大，也是后续数据有效治理的基础，以下是我们的一个命名规范示例：
总而言之，你可以把这篇文章当成一个指引，具体还是要结合企业的实际去推进，始终要明白的一个原则就是：即数据如何摆布才能提高支撑应用的效率，手段上不用区分什么先进不先进，好用就成。