本文将介绍维度建模理论和基于自己经验的实施步骤。数据模型是数据组织和存储的方法，它强调从业务、数据存取和使用角度合理存储数据。只有数据模型将数据有序地组织和存储起来之后，大数据才能得到高性能、低成本、高效率、高质量的使用。

一般业务系统报表开发模式是Java写SQL从业务库算出结果数据，这样可以快速出来结果。但有几个问题：1)对业务库的影响；2)扩展性，比如页面又想加表的范围查询维度；3)当数据需求越来越多时，怎么维护。这时就需要数据仓库来对接源系统，计算结果数据给到应用，将数据分析和业务处理分离。数仓建模描述的就是这么设计数仓里的表和表间关系，和用PowerDesigner做业务系统表设计作用差不多，只不过数仓是面向数据分析(OLAP)而业务系统是面向业务处理的(OLTP)。

数仓中一般描述成：数据模型-->业务过程-->数据域。常见的建模方式有：Inmon提出的ER(3NF)建模，kimball提出的维度建模，datavalidation和anchor模型用得都很少。这里只阐述项目中用到的维度建模。

一、维度建模理论

根据鄙人多年实施经验，上去就干的方法多半会凉凉，表越来越多，重复的，废弃的...所以需要理论指导我们实践，在实践中完善优化理论。《数据仓库工具箱：维度建模权威指南》，链接：https://pan.baidu.com/s/15LL8MrpNl80skIlFvhnIgg 提取码：ypha 这里只阐述项目中用到的部分。

维度建模的优势：以用户容易理解的方式发布数据(过程简单易于实施)和高效的数据查询性能。三个重要概念：总线架构(Bus Architecture),一致性维度(Conformed Dimension)和一致性事实(Conformed Fact)。搭建好大数据平台后，做数仓分层规划，然后就要建立整个企业内具有统一解释的标准化的维度和事实，即一致性维度和一致性事实。然其他需求都按这个体系结构来进行迭代开发。

总线架构是一种结构化的、增量式的构建数仓的方法。上图的日期，产品...就是一致性维度 ,销售，库存就是一致性事实表。理解总线：电脑的IO总线，按约定的标准将鼠标，键盘，USB等串联起来使之可以协同工作。类比过来，数据仓库中的各个表就是IO设备，通过总线架构将这些设备连接起来，实现数据的高效传输。

二、实施步骤

1. 确定业务需求：分析业务流程，明确需要分析的数据对象和指标；

2. 设计维度模型：根据业务需求，确定维度表的结构和字段；

3. 创建维度表并填充数据：使用ER工具或手工创建维度表，并按照设计的维度模型填充数据；

4. 建立总线架构：确定一致性维度和一致性事实表的结构和字段；

5. 创建一致性维度表并填充数据：使用ER工具或手工创建一致性维度表，并按照设计的一致性维度表结构填充数据；

6. 创建一致性事实表并填充数据：使用ER工具或手工创建一致性事实表，并按照设计的一致性事实表结构填充数据；

7. 建立数仓分层规划：根据企业的业务需求和发展计划，制定合理的数仓分层规划；

8. 迭代开发：根据实际需求和项目进展，不断优化和完善数仓模型。

在企业数仓中，通过一致性维度和一致性事实将各个业务动作(如销售、库存、订单)串联起来，以便于分析查询数据。首先，通过总线矩阵梳理出一致性维度和业务过程的关系，分析源系统中的业务过程以及涉及的维度，重要性较高的维度应优先建立。接下来，按照以下步骤构建业务数据分析模型：

1. 选择业务过程：确定用户的核心业务活动，如接收付款、开具发票、下订单等。

2. 声明粒度：精确定义某个事实表中一行的含义，回答“如何描述事实表中的行内容？”。

3. 确认维度：解决“业务人员如何描述来自业务过程量事件的数据”的问题，表示承担每个度量环境中所有可能的单值描述符。

4. 确认事实：解决“过程的度量是什么？”的问题，典型的事实是可加性的数值，需要将数据源和用户需求结合起来。

一个简单的维度建模结果如下：

可以看到这样的结构：

1)可以快速扩展，如添加供应商维度表，便可分析供应商与零售的关系；

2)快速提供结果数据，例如查询每年农历新年的销售数据；

3)结构简单便于理解。

当然，在实施过程中需注意需求对接、维度变化、数仓标准、一致性维度、快照事实表等问题。在业务场景章节会进行实例解析。复杂的模型如Teradata的LDM,是数据分析师和业务专家对业务的深度沉淀，基于该模型能提供财务用户所需的数据信息，指导财务数据分。不用像传统模式那样去调研开发，直接部署灌入自己的数据就分析，这就是优秀模型的优越之处。

二、实施策略

“道理听了很多，却依旧过不好人生”。这是因为还缺少切实可行的实施策略。很多方法论都太理想，如上去就梳理各个系统业务，做大而全的，画大饼；建议选择最有价值的业务需求或领导最关心的作为切入点，逐步增加。以下是基于OneData结合项目实际调整后的实施步骤：

调整原因：阿里或维度建模理论中没有明确需求的情况下，做一个大而全的数仓，再通过数仓输出数据报表。而我们的情况是有明确需求(有产品原型图)。在资源有限(人力、时间、成本)的情况下，通过需求倒推设计统一维度表和事实表，再结合维度建模的理论形成可扩展的数仓模型。这个策略在之前的项目中有成功的实用实例。

实施步骤：

1. 数据调研：了解企业的业务流程、数据来源和存储方式，为后续建模奠定基础。

产品文档的编写和评审是整个数仓建模过程的关键环节。以下是一个简化版的建模流程：

1. 产品经理与需求评审：由产品经理负责撰写需求文档，包括需求说明、指标说明文档等。在数仓成熟后，可以基于数仓主动为业务提供数据产品。一般会进行需求评审以判断需求的可行性和性价比。

2. ADS层表结构设计：对于比较复杂的指标，需要提供指标说明文档，指导数据开发以及作为产品使用文档的一部分交付客户。数据开发在明确需求后，设计ADS层的表结构，并与后端、产品评审。评审后确认后填充模拟数据。一般用在线文档的模式方便共享，这样后端和前端就可以进行开发调试，后续换成真实数据即可快速上线。

3. 结果表设计：一般的报表是由数据开发、后端开发和前端开发协同完成。为避免后端等待数据的情况，在明确需求后，数据开发设计ADS层的表结构，并与后端、产品评审。评审后确认后填充模拟数据。一般用在线文档的模式方便共享，这样后端和前端就可以进行开发调试，后续换成真实数据即可快速上线。ADS层的原则是让数据应用最高效的查询到所需要的数据，但要注意：ADS层并不是严格的一个报表页面对应一个数据库表，根据实际情况做调整可以一张数据库表支撑多张同类型的报表页面。列名尽量保持与源系统一致。结果表评审内容包括：数据开发对指标定义的理解是否准确、是否有对应的数据支撑、用户量、数据量、什么情况下使用、查询频率、扩展的内容是否合理等。

4. 源表梳理：明确了ADS的输出再反推回来需要哪些源数据。同时要清楚什么业务动作产生，来自于哪些数据库，哪些表。参考第三章相关内容，输出源表-ODS映射。上面收集的信息是通过需要的结果倒推出维度建模的第一步“选择业务过程”，也是指导ETL开发和数据资料的原始资料，随着业务增多考虑用atlas进行管理。

5. 参考公司svn上的产品使用手册、业务系统原型图产品设计文档、业务系统据库设计文档等资料进行学习和讨论，准备具体的有价值的问题参与建模的第二步“声明粒度”。

总结来说，数仓建模过程包括需求文档编写、ADS层表结构设计、结果表设计、源表梳理和参考资料学习等步骤。在整个过程中，要注意遵循数仓规范，确保各个环节的顺利进行。

以下是重构后的内容：

完成ODS层数据表设计文档，建议使用PowerDesigner。主要信息包括表间关系和关联字段，但在没有键约束的情况下，后续要在ODS层新加表之前，要先查询本设计文档，以避免重复抽取。

Step 4. 构建总线矩阵

通过总线矩阵分析业务动作中涉及到的维度信息，将同类型的维度提炼成维度表。完成第三步“确认维度”，即生成对应的维度表。维度表设计有很多技巧，建议阅读原书。将尽可能多的维度信息放入维度表中，方便聚合查询。例如，在日期维度表中加入节假日和是否放假等信息，就能快速统计与节假日相关的数据。

Step 5. 构建指标

对应第四步“确定事实”，简单说：业务过程可以沉淀出哪些可加性指标？把这些指标设计成宽表并关联上一致性维度表，DWD层的明细模型就完成了。例如，在gas_meter上卷一层后从最细的设备id到了用户id,设备id的通气日期汇总后得到接入数(原子字表),计算截止到统计日期的累计值(派生指标)。后面DWS就是基于这一层再加工一次形成汇总模型：更粗粒度的汇总(比如DWD存的是每个每天的接入量),DWS再汇总一次计算每月的接入；ADS直接存结果表记录。

Step 6. 数据开发及上线

1) 开发对脚本以生成以上5步的结果数据。

2) 进行数据验证以确保准确。

3) 部署到调度平台进行调度监控。

交付的是相关脚本及ETL流程说明。

实时表中的描述性信息包括国家、时间和地点等，这些信息可以帮助我们更好地了解数据来源和事件发生的时间和地点。例如，如果我们需要分析某个地区的销售情况，那么知道该地区的国家、时间和地点等信息就非常有用。

如果您需要更多关于这个话题的信息，我可以为您提供一些相关链接。请问您需要吗？