数据仓库维度建模的可行性

一、文章概述

由于数据结构的多样性（结构化、半结构化、非结构化），催生了hadoop生态圈技术的快速发展。大数据。。。我们要做数据分层，采用哪种方式建模呢？尽管维度建模方法已经被广泛采用，但误解依然存在。这些错误的断言会给我们工作带来麻烦，特别是想带领团队做一些最佳实践时，可能会出现对选取维度建模方法的质疑和批评，这时我们需要有一套强有力理论以回击那些保守的家伙。

二、维度建模

规划DW/BI系统数据结构需要考虑业务的所有业务过程，以及一些主要的维度描述信息。通常我们可以采用数据仓库矩阵的形式来描述指标。矩阵的潜在好处是提供了一个灵活且更加严谨的主数据管理平台。

数据治理需要考虑主维度级（主数据矩阵）。思考并提炼出描述业务的中心名词，将其放入到来自各个专家团队的数据管理项目列表中。建立这些关键名词的最终目的是开发出一套具有统一一致性，满足业务分析过滤、分组、标识等要求。健壮的维度是后续建立数据中台的基础。

Kimball维度建模思想的基本要素如下：

• 汇总数据只是维度模型的一部分

  
  

由于不能预测业务用户所提出的所有问题，因此必须向业务用户提供对详细数据查询的功能，这样也能够实现数据的上卷操作。维度模型中需要有大量的历史数据，但是具体的历史数据量需要业务需求驱动。

• 维度模型是企业级而非部门级的

  
  

维度建模应该围绕整个业务过程各节点来开展，例如，订单、采购、发货等操作，而不是按照业务部门进行划分的。多个业务部门往往需要分析来自同一个业务过程的相同的度量。数据模型应该避免重复获取同一个数据源的数据，否则会造成数据不一致性。

• 维度模型是易于扩展的

  
  

维度模型天生的优势就是易于扩展。事实表通常包含海量的数据行，规范的数据维度模型中包含详尽的数据关系。这样维护维度模型只需要维护事实表的外键和维度表的主键值即可。

• 维度模型不仅仅用于预测

  
  

将维度模型设计为仅仅关注预定义的报表或者分析是不可取的。维度建模需要把注意力集中在度量事件上，因为与不断变化的数据分析相比较，度量事件还是相对稳定的。

实现灵活查询的灵丹妙药通常是以最细粒度建立事实表。仅仅发布有汇总数据的事实表和维度表是远远不够的。维度模型中正确的做法是以最详细的粒度表达数据，这样才能获得最好的灵活性和可扩展性。

• 维度模型是可以集成的

  
  

如果采用企业数据仓库总线模式，维度模型多数情况下是可以被集成的。一致性维度作为集中的、持续的主数据建立在主ETL系统中。跨维度模型的重用能够实现数据集成和语义一致性。数据集成依赖于标准标识和定义。实现一致性维度非常困难，但是数据建模不能回避困难，必须要建立数据规范化标准并付诸行动。

若展现区的数据如果不采用一致性维度的总线结构，将会产生烟囱式的解决方案。

三、统一一致向前看

打开我们的视野，从全局去观察整个大数据的运作。我们需要对大数据进行分层，数据模型的分层通常可以分为ODS、DWD、DWS、ADS、DIM：

• ODS层：是从业务系统采集过来后，经过数据规范化处理的数据，包含了所有业务的变更过程，是最细粒度的原子数据。
• DWD层：是在ODS层基础上，根据业务过程提炼出来的事实表明细层，提供给下游数据使用。
• DWS层：是在DWD层和ODS层的基础上，根据统一执行性维度建立的一套通用的汇总模型层。提供给下游的数据节点使用，同时需要保证和ODS层、DWD层的数据一致。
• ADS层：通常是根据个性化的需要定制的一些需求表层。这一层和DWS层实质上是并列的，只是计算业务自身关注的维度和指标。
• DIM层：提供公司层面的统一一致性维度和部分个性化维度模型。
  
  
  

在整个大数据链路中，可以分为采集--同步--离线（实时）计算-存储-线上回流节点上。在后续的文章中我们来一一详解。

作者：清和  来源：大数据漫路求索