摘要
本文从几个常见概念入手，介绍模型设计与它们的关系，在列举当前企业模型设计的建设方法，并重点介绍“维度建模”。
1
与几个概念的关系操作型业务系统
对于这个概念大家都不陌生。企业业务赖以运转的交易系统就属于操作型业务系统。因此它是为了保障业务正常运转，能够更快的处理事务。
但是因为它是针对某一特定的意图（例如满足交易业务），它不需要承诺与其他业务系统共享公共数据。因此就出现了适合于企业中交叉应用的ERP、主数据系统。当然对于有建设业务中台的企业来说，基于微服务架构的各个服务中心，能更好的提供可复用统一的公共数据。
不管是面向业务的业务系统、经过数据统一后的主数据系统或者基于微服务架构的服务中心的数据，都是作为数据中台的数据输入源头。我们通过批量同步、归档日志采集等方式，能将数据采集进数据中台，作为ODS层原始数据的一部分。
ETL
英文Extract-Transform-Load的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程。在ODS层的原始数据，需要通过加工处理后，才能进入到构建好的数据模型中。
在模型设计时，需要考虑ETL加工流程，根据逻辑判断，做模型的合理设计。同样对于下游使用数据模型的ETL元数据，也是作为模型设计的输入，可基于下游应用方式做模型的横向和纵向的拆分设计，这就是“元数据驱动模型设计”的理论来源。
因此，无法理解数据开发的模型设计师是不合格的。
数据应用
数据中台提供多种数据应用的形式，包括数据报表、智能数据产品等。将统一汇总加工后的数据或者明细原子数据提供给数据应用，为业务提供数据支撑。
更加合理的数据模型设计，能够给更宽泛的应用提供数据支撑，也能够让业务方更准确无疑义的使用好数据。
2
几种企业常见的建设现状烟囱式
也许大家都不愿意承认，但是绝大部分的企业当前是没有统一、标准、公共、全局的模型设计的，而仅仅是把数据同步上来，然后基于业务需求做烟囱式的数据开发。这种方式也许从短期来看是效率最高的，但是从长期看，不仅仅造成计算存储资源的极大浪费、没有统一可用的数据、大量的重复性的工作。企业的数据就像一团乱麻，根本无法管理。
三范式+数据集市
一些传统大型企业，由于历史原因，原子数仓中以三范式的模型设计方式构建，在各个应用的数据集市中以维度建模方式构建。通过这种方式，在原子数据设计过程中，需要投入较大的资源。
对于业务来说，三范式模型太复杂，用户难以理解和检索。并且对于业务频繁变化的企业，模型的维护成本极高。
企业级维度模型
基于企业全局的角度去构建业务总线矩阵，在此基础上完成维度模型的设计，是当前众多企业选择的方向。从众多互联网企业的数据中台实践经验来看，这也是一个绝佳的各因素平衡后的选择。
后面，我们将从各个角度来思考如何基于维度模型构建企业级数据中台。
3
维度建模初探优势
在数据中台建设经验中，企业级维度模型设计从理解性、扩展性、高性能上都是更适应当前的技术和业务环境的。
首先由于计算和存储成本逐步下降，模型更重要的变成了易于理解，当易用性放在模型设计的重要位置时，维度模型可理解的优势就显现出来了，维度建模一直就是以业务的视角来描述数据。
另外，当新的业务出现时，新的模型不会对已有模型形成冲击，可以无影响的产出新的模型数据。
维度建模会设计部分数据的冗余，通过冗余换来数据检索的高性能。对于数据量极具膨胀的今天，高性能给用户带来了高价值。
事实表
所谓的事实表，就是企业的业务过程事件的度量信息。例如对于支付这个业务过程来说，需要度量支付的商品数、金额等度量。因此，企业的业务过程数据以事实表的形式在模型中呈现出来。
事实表每行都对应了一个度量事件，每行数据是一个特定级别的细节数据。事实表中每个度量都必须是相同的粒度级别。
事实表中的度量的可加性也至关重要，因为业务方往往需要将事实表的数据基于某些维度进行汇总，在度量上需要能够做汇总累加。
事实表还是稀疏的，它仅仅会将发生的业务过程数据放入其中。
维度表
维度表是事实表不可或缺的组成成分，它描述了事实表业务过程度量的环境。用于描述“谁、什么、哪里、何时、如何、为什么”有关的事件。
维度属性是作为查询约束、分组、标识的主要来源，因此它的好坏直接决定了数据的可分析性的差异。维度属性需要是可理解的，因此需要尽量避免“0,1”之类的代码，将代码翻译成更易理解的字符避免业务的误解。
同样，会有一些数值型的可作为维度属性。例如：也许有人会问商品标价适合在事实表还是维度表中？
当用于计算度量时，它应该存在于事实表中；但是当它用于做约束、分组、标识分析时，则需要存在于维度表中。在维度表中，我们往往会把连续的数据换成离散的数值存储，例如：将标价变为价格区间段。这是要根据对业务的理解做进一步设计的。
雪花模型与星型模型
所谓的雪花模型，是当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。
而星型模型则是所有维表都直接连接到事实表上，整个图解就像星星一样，故将该模型称为星型模型。
雪花模型是对星型模型的扩展。
星型模型是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连，不存在渐变维度，所以数据有一定冗余。因为有冗余，所以很多统计不需要做外部的关联查询，因此一般情况下效率比雪花模型高。
但是从可理解性上看，雪花模型是更容易让业务理解的。因为业务可以从模型上看出维度与维度之间的关系。
因此如何平衡查询效率和业务理解？我们在后面的文章中再细细道来。
总线矩阵
总线矩阵，维护的是企业的各个业务过程与一致性维度的关系。是以企业的高度实现的顶层设计。它的存在对于数据中台项目至关重要。
如果数据中台的模型设计就是一本书，那么总线矩阵就是这本书的目录，能从整体上对每个模型有统一的定义。
从项目协调上看，总线矩阵在大型项目中起到举足轻重的地位，整个项目组都能基于这个目录清晰的明白自己在做什么，别人已经做了什么，极大程度上的避免了信息沟通不畅导致的重复定义。
从项目管理上看，也可以基于总线矩阵对模型设计和开发进行有效的优先级排期。
最后，总线矩阵是共同业务人员和技术人员的桥梁，通过总线矩阵在项目沟通中达成一致的语言。
D
结语
通过这篇文章，初浅的对数据中台模型设计发表了一些观点。
在后面的章节中，我们将继续围绕模型设计的技术细节、结合行业的模型设计案例，和数据同仁们做进一步的分享和交流 。
